Intent to Implement and Ship: CSS calc() in media queries

[Chris Nardi]

Contact emails Chris Nardi (cna...@chromium.org) Spec https://drafts.csswg.org/css-values-4/#calc-notation

Summary

According to the CSS Values 4 spec, math functions such as calc() should be allowed wherever individual CSS values such as numbers are allowed. However, calc() expressions are not currently parsed in media queries. This change would introduce support for parsing calc() expressions inside of media queries.

The bug for this change is https://crbug.com/421909.

Motivation Web developers expect calc() to work wherever they need it -- including inside of media queries. See e.g. https://stackoverflow.com/questions/23667208/calc-not-working-within-media-queries. Blog posts such as https://peterwilson.cc/media-queries-calc/ (written three years ago) suggest ways to work around the lack of support, but this is an inadequate solution.

Risks

Interoperability and Compatibility

There should be no compatibility risk, as only previously invalid code would be parsed.

Edge: No signals

Firefox: Shipped in Firefox 59 (https://bugzilla.mozilla.org/show_bug.cgi?id=1256575)

Safari: Shipped (https://bugs.webkit.org/show_bug.cgi?id=181716)

Web developers: Positive

Ergonomics

n/a

Activation

The syntax for calc() is already preexisting, so it should be easy for developers to use.

Debuggability

No changes to DevTools should be needed.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Is this feature fully tested by web-platform-tests?

Yes, there are tests both in https://wpt.fyi/css/mediaqueries and https://wpt.fyi/css/css-values.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5643732019838976

Requesting approval to ship?

Yes.

[Rick Byers]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXZydeioBcP-Ug6jVkxZcW8GAYirsV5v189rJ3%2BNpb9djeU0Q%40mail.gmail.com.

[TAMURA, Kent]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-7dM5QHb3-nmuGdaqr0GbntZ7L2Jn5Fe78065VyOtBgA%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

[flo...@rivoal.net]

Hi,

I'm the co-editor of Media Queries, and I totally approve of this.

Just one quick note: there are indeed tests for this in WPT, but I would not describe that test suite as full. I don't think we have tests for how calc-within-media-queries serializes if you observe it back from the CSSOM. We probably should.

I encourage you to write such tests as you implement it, and to share them on WPT. Ping me when you do so, and I'll be happy to review.

—Florian

[Philip Jägenstedt]

LGTM3

What Florian says raises and important point, namely that existing tests in wpt might not be very good or complete. It's hard to always notice this as a reviewer, and there's a risk that we end up not testing some important corners of the feature, especially error handling.

I currently can't see any other fix than careful review, but if was really easy to see code coverage from running a set of tests that might give some clues for CL authors and reviewers...

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/17393ab8-e168-4a32-ae99-488f36ed3325%40chromium.org.

[Florian Rivoal]

> existing tests in wpt might not be very good or complete. It's hard to always notice this as a reviewer, and there's a risk that we end up not testing some important corners of the feature, especially error handling.

I think a first good approximation is to ask the spec's editor(s). They are not always the authors or reviewers of the existing tests, but they generally have a reasonable idea of how good or complete the existing tests are.

It's not fool proof, but it's a start.

As for automating code coverage analysis of specs, that'd be awesome, but that seems like an AI-complete problem to me. That said, imperfect-but-still-useful solutions may be more attainable.

—Florian

[Rick Byers]

Thanks Florian, I like the idea of getting the habit of getting spec editor feedback on the test suite quality.  We should totally ask devs to fill any major gaps as part of shipping.

At the same time, our bar should of course not be total coverage.  As with all testing there's a tradeoff to be made and we should expect to have some test holes, where the important ones tend to be filled by regression testing as bugs are fixed.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/36D0F5F7-0941-4E74-AAA5-E30A9AFE1F2C%40rivoal.net.

[Emilio Cobos Álvarez]

Just for reference, when implementing this in Gecko I did raise an issue
with the CSSWG to clarify serialization of calc in media queries[1],
which is itself the reason why I didn't write WPT tests for it.

Just wanted to drop that link, and thank Florian for pushing on getting
that issue sorted out :)

-- Emilio

[1]: https://github.com/w3c/csswg-drafts/issues/1968

On 01/24/2018 03:55 AM, flo...@rivoal.net wrote:
> Hi,
>
> I'm the co-editor of Media Queries, and I totally approve of this.
>
> Just one quick note: there are indeed tests for this in WPT, but I would
> not describe that test suite as full. I don't think we have tests for
> how calc-within-media-queries serializes if you observe it back from the
> CSSOM. We probably should.
>
> I encourage you to write such tests as you implement it, and to share
> them on WPT. Ping me when you do so, and I'll be happy to review.
>
> —Florian
>
> On Wednesday, January 24, 2018 at 9:44:06 AM UTC+9, Chris Nardi wrote:
>
> Contact emailsChris Nardi (cna...@chromium.org

> <javascript:>)Spechttps://drafts.csswg.org/css-values-4/#calc-notation
> <https://drafts.csswg.org/css-values-4/#calc-notation>
> *Summary*

> According to the CSS Values 4 spec, math functions such as calc()
> should be allowed wherever individual CSS values such as numbers are
> allowed. However, calc() expressions are not currently parsed in
> media queries. This change would introduce support for parsing
> calc() expressions inside of media queries.
>
> The bug for this change is https://crbug.com/421909.

> MotivationWeb developers expect calc() to work wherever they need it

> -- including inside of media queries. See
> e.g. https://stackoverflow.com/questions/23667208/calc-not-working-within-media-queries

> <https://stackoverflow.com/questions/23667208/calc-not-working-within-media-queries>.

> Blog posts such as https://peterwilson.cc/media-queries-calc/
> <https://peterwilson.cc/media-queries-calc/> (written three years
> ago) suggest ways to work around the lack of support, but this is an
> inadequate solution.
>
> Risks
>
> Interoperability and Compatibility
>
> There should be no compatibility risk, as only previously invalid
> code would be parsed.
>
>
> Edge: No signals
>
> Firefox: Shipped in Firefox 59

> (_https://bugzilla.mozilla.org/show_bug.cgi?id=1256575
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1256575>_)
>
> Safari: Shipped (https://bugs.webkit.org/show_bug.cgi?id=181716
> <https://bugs.webkit.org/show_bug.cgi?id=181716>)

>
> Web developers: Positive
>
>
> Ergonomics
>
> n/a
>
>
> Activation
>
> The syntax for calc() is already preexisting, so it should be easy
> for developers to use.
>
>
> Debuggability
>
> No changes to DevTools should be needed.
>
>
> Will this feature be supported on all six Blink platforms (Windows,
> Mac, Linux, Chrome OS, Android, and Android WebView)?
>
> Yes.
>
>
> Is this feature fully tested by web-platform-tests

> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?

>
> Yes, there are tests both in https://wpt.fyi/css/mediaqueries

> <https://wpt.fyi/css/mediaqueries> and https://wpt.fyi/css/css-values <https://wpt.fyi/css/css-values>.

>
>
> Link to entry on the feature dashboard <https://www.chromestatus.com/>
>

> _https://www.chromestatus.com/feature/5643732019838976
> <https://www.chromestatus.com/feature/5643732019838976>_

>
>
> Requesting approval to ship?
>
> Yes.
>

> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/17393ab8-e168-4a32-ae99-488f36ed3325%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/17393ab8-e168-4a32-ae99-488f36ed3325%40chromium.org?utm_medium=email&utm_source=footer>.

[Florian Rivoal]

> On Jan 25, 2018, at 1:27, Rick Byers <rby...@chromium.org> wrote:
>
> Thanks Florian, I like the idea of getting the habit of getting spec editor feedback on the test suite quality. We should totally ask devs to fill any major gaps as part of shipping.
>
> At the same time, our bar should of course not be total coverage. As with all testing there's a tradeoff to be made and we should expect to have some test holes, where the important ones tend to be filled by regression testing as bugs are fixed.

I agree complete coverage should not be the goal. Some adaptation of the Boy Scout rule seems appropriate "Always leave the test suite in better shape than you found it".

—Florian