Intent to Ship: Media Queries Level 4 Syntax & Evaluation

[Anders Hartvoll Ruud]

Contact emails

and...@chromium.org

kbab...@microsoft.com

Explainer

None

This article by Bramus may be helpful.

Specification

https://www.w3.org/TR/mediaqueries-4/#mq-range-context

Summary

Allows writing media queries using ordinary mathematical comparison operators, and adds support for or, not, nesting, and the special evaluation of “unknown” features.

Tiny example:

Without this feature: @media (min-width: 100px)

With this feature: @media (width >= 100px)

Blink component

Blink>CSS

TAG review

Probably not needed(?)

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1422225) Except:

• Support for `<general-enclosed>`, due to concerns that are discussed below.

• The `<mf-value> <mf-comparison> <mf-name>` form, due to Issue 2791, which was resolved as no-change.

WebKit: I sent an e-mail to webkit-dev just now. I’ll update if/when I get a response. Related info: @container, which is implemented in Safari TP, uses an almost identical syntax, so there appears to be no fundamental objections, at least.

Web developers: No signals

Other signals:

WebView Application Risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

One significant concern (raised by Emilio) is regarding the “unknown”/<general-enclosed> evaluation. Currently, a media query like @media (unknown: 500kg) will parse to (and serialize as) “@media not all”. (In mediaqueries-3, a media query with unknown parts doesn't fail parsing in the normal sense, but instead becomes “not all”). The concern is that authors compare the parsed result of a media query condition against “not all” in order to detect features. For example:

let prefersContrastSupported = matchMedia("(prefers-contrast)").media != "not all";

With this I2S, prefers-contrast (and any other unknown feature matching <general-enclosed>) will appear to parse successfully, and won’t be converted to “not all” anymore.

To understand the impact of this, I added some use-counters for various APIs which count whenever a media query that would contain <general-enclosed> is serialized:

Window.matchMedia | ~0.1%

MediaList::mediaText | ~0.1%

CSSConditionRule.conditionText | ~0.007%

Note: Chromestatus has a bug where the name does not show up for these counters.

I then queried HTTP Archive for response bodies containing `not all` (in quotes) from sites that hit one of the above use-counters, and the results show that it’s almost entirely coming from the following two scripts [full data]:

• https://mc.yandex.ru/metrika/tag.js

• https://mc.yandex.ru/metrika/watch.js

However, looking at the live version of those files in Chrome (Desktop), I can’t find “not all”. It would appear that they don’t use this technique anymore. (Or I’m not using the right headers/User-Agent in the request).

This research is not perfect, e.g. there could be other ways of doing feature detection that does not involve “not all”, or people could be using .cssText, and I assume not the entire web is in the HTTP Archive. But overall I’m fairly confident that it’s not an exceedingly common practice. The risk seems worth the gain of avoiding future-proofing mistakes for media queries.

Debuggability

The new syntax is automatically visible in devtools.

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

No

The existing WPTs are not sufficient at the moment - I will complete the coverage before shipping. Also some changes to existing tests will be required in relation to the <general-enclosed> handling: tests that verify that some MQ parsed (or didn’t) will now (likely) always appear to have parsed correctly due to <general-enclosed>. These tests probably need to be changed to instead detect whether or not the result is “unknown”.

Flag name

CSSMediaQueries4

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=962417

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5203042742829056

This intent message was generated by Chrome Platform Status (more or less).

[Yoav Weiss]

Thanks for working on this!!

Did you try turning these counters to UKM that would enable you to dig further in that usage? Do we expect those 0.1% to visibly break? (I guess that depends on what they're feature testing for..)

 

CSSConditionRule.conditionText | ~0.007%

Note: Chromestatus has a bug where the name does not show up for these counters.

I then queried HTTP Archive for response bodies containing `not all` (in quotes) from sites that hit one of the above use-counters, and the results show that it’s almost entirely coming from the following two scripts [full data]:

• https://mc.yandex.ru/metrika/tag.js

• https://mc.yandex.ru/metrika/watch.js

However, looking at the live version of those files in Chrome (Desktop), I can’t find “not all”. It would appear that they don’t use this technique anymore. (Or I’m not using the right headers/User-Agent in the request).

This research is not perfect, e.g. there could be other ways of doing feature detection that does not involve “not all”, or people could be using .cssText, and I assume not the entire web is in the HTTP Archive. But overall I’m fairly confident that it’s not an exceedingly common practice. The risk seems worth the gain of avoiding future-proofing mistakes for media queries.

Debuggability

The new syntax is automatically visible in devtools.

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

No

The existing WPTs are not sufficient at the moment - I will complete the coverage before shipping. Also some changes to existing tests will be required in relation to the <general-enclosed> handling: tests that verify that some MQ parsed (or didn’t) will now (likely) always appear to have parsed correctly due to <general-enclosed>. These tests probably need to be changed to instead detect whether or not the result is “unknown”.

Flag name

CSSMediaQueries4

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=962417

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5203042742829056

This intent message was generated by Chrome Platform Status (more or less).

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUp4PiXx57G3-y8BxScG-ecHGSEPQZyZjoYGz8r_ECyipg%40mail.gmail.com.

[一丝]

Does the current implementation support use in `@import`? For example:

`@import url('foo.css') screen and (width <= 1200px);`

[Anders Hartvoll Ruud]

Ah, I'm not familiar with that way of doing compat research. What would we gain from doing that vs. regular use-counter + HTTP Archive?

 

Do we expect those 0.1% to visibly break? (I guess that depends on what they're feature testing for..)

I would not expect that at all based on the HTTP Archive query. If testing against "not all" was commonplace, I'd expect more results beyond the two Yandex scripts. Or, perhaps it is commonplace, but it happens mostly on features that actually *are* supported at the moment.

Just as an example (and to show that "not all" testing isn't a myth), one of the few (non-Yandex-script) sites that did show up was https://ww.sapo.pt, which does the following:

if(rule.mediaText.includes("not all") || ...)

By the looks of it, it's an early-out related to the theme switching, which prevents the code from amending the query if prefers-color-scheme is not supported. Had we not supported prefers-color-scheme, then I think the worst that could happen is that we end up with a more complicated query that still ultimately evaluates to false. Testing the page with the feature enabled (with and without dark mode preference), their color switcher still works normally.

That is just one site though, it's probably theoretically possible to write *something* that breaks. I did try to look at the "sample URLs" for the counters, but I couldn't actually reproduce the counters being hit.

[Emilio Cobos Álvarez]

On 4/11/22 15:02, Anders Hartvoll Ruud wrote:
> Ah, I'm not familiar with that way of doing compat research. What would
> we gain from doing that vs. regular use-counter + HTTP Archive?
>
> Do we expect those 0.1% to visibly break? (I guess that depends on
> what they're feature testing for..)
>
>
> I would not expect that at all based on the HTTP Archive query. If
> testing against "not all" was commonplace, I'd expect more results
> beyond the two Yandex scripts. Or, perhaps it is commonplace, but it
> happens mostly on features that actually *are* supported at the moment.
>
> Just as an example (and to show that "not all" testing isn't a myth),
> one of the few (non-Yandex-script) sites that did show up was

> https://ww.sapo.pt <https://ww.sapo.pt>, which does the following:

>
> if(rule.mediaText.includes("not all") || ...)
>
> By the looks of it, it's an early-out related to the theme switching,
> which prevents the code from amending the query if prefers-color-scheme
> is not supported. Had we not supported prefers-color-scheme, then I
> think the worst that could happen is that we end up with a more
> complicated query that still ultimately evaluates to false. Testing the
> page with the feature enabled (with and without dark mode preference),
> their color switcher still works normally.
>
> That is just one site though, it's probably theoretically possible to
> write *something* that breaks. I did try to look at the "sample URLs"
> for the counters, but I couldn't actually reproduce the counters being hit.

It's a thing that even Google DevRel people have recommended in the
past, ftr :)

https://web.dev/prefers-color-scheme/#supporting-dark-mode

But if you have data to indicate this is not a problem in the wild I'd
be happy to implement it in Gecko after you ship this change.

Cheers,

-- Emilio

[Joe Medley]

Are you aiming for 102?

[Anders Hartvoll Ruud]

On Mon, Apr 11, 2022 at 7:45 PM Joe Medley <jme...@google.com> wrote:

Are you aiming for 102?

That's branching very soon, so definitely not. I'm not really aiming for any particular release. But if you want a prediction anyway, then likely 104. 

Ouch ... 

[Anders Hartvoll Ruud]

Update: support from Webkit: https://www.mail-archive.com/webki...@lists.webkit.org/msg30451.html

[Joe Medley]

Please ping me if it ends up being 103. I don't like missing things in the beta release post.

[Daniel Bratell]

LGTM1, with a careful launch (as usual, but even more so).

The usage counter indicates that the ceiling of breakage is quite high (in the 0.1% magnitude range) but I believe that your analysis of is likely accurate and the real amount of affected sites is likely to be much lower. Furthermore, any breakage has a fair chance of not affecting a sites functionality.

/Daniel

--

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/87a783d4-dbd7-4b0c-8ba1-7a118a87d759n%40chromium.org.

[Anders Hartvoll Ruud]

Yoav asked if I could do another HTTP Archive query to look for sites that hit the counters, contain "not all" and contain at least one media feature that's known to be unsupported in Chrome. The idea would be to then look at what those sites do, check if they break, etc.

Looking at a relevant table in MDN, I then queried for r'(inverted\-colors)|(overflow\-block)|(overflow\-inline)|(prefers\-reduced\-data)|(scripting)'. I found only a single interesting (non-Yandex-metrics) hit, which was https://marselshoes.by/assets/js/ym.js?hash=e427de0e11f74a8a57a8 . The code was obfuscated/minimized, so it was a bit hard to see if something would break from just reading the code. But at least nothing appeared to be broken if I tried to shop for shoes with the feature enabled.

Looking a bit closer today though, I think this is actually the yandex metrics script as well, under a different name. (ym.js = "yandex metrics"?). So maybe there are actually zero interesting results.

[Yoav Weiss]

LGTM2

Since the Yandex scripts are metrics scripts, there's little chance that their use would result in breakage, and the script is most likely doing some sort of "browser fingerprinting" and trying to see if the browser is indeed the one it claims to be. As such, I think that the risk here is low. It'd still make sense to watch out for incoming issues as Daniel suggested.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUoLaQ6BCr2LZEz9KF3cmpj1F09RZGHrrOmrhr%3D4eov1Ww%40mail.gmail.com.

[mkwst via Chromestatus]

LGTM3.

[Mike Taylor]

Bonus LGTM4 (Mike just beat me before I hit send).

On 4/13/22 8:23 AM, Yoav Weiss wrote:

LGTM2

Since the Yandex scripts are metrics scripts, there's little chance that their use would result in breakage, and the script is most likely doing some sort of "browser fingerprinting" and trying to see if the browser is indeed the one it claims to be. As such, I think that the risk here is low. It'd still make sense to watch out for incoming issues as Daniel suggested.

On Wed, Apr 13, 2022 at 2:17 PM Anders Hartvoll Ruud <and...@chromium.org> wrote:

Yoav asked if I could do another HTTP Archive query to look for sites that hit the counters, contain "not all" and contain at least one media feature that's known to be unsupported in Chrome. The idea would be to then look at what those sites do, check if they break, etc.

Looking at a relevant table in MDN, I then queried for r'(inverted\-colors)|(overflow\-block)|(overflow\-inline)|(prefers\-reduced\-data)|(scripting)'. I found only a single interesting (non-Yandex-metrics) hit, which was https://marselshoes.by/assets/js/ym.js?hash=e427de0e11f74a8a57a8 . The code was obfuscated/minimized, so it was a bit hard to see if something would break from just reading the code. But at least nothing appeared to be broken if I tried to shop for shoes with the feature enabled.

Looking a bit closer today though, I think this is actually the yandex metrics script as well, under a different name. (ym.js = "yandex metrics"?). So maybe there are actually zero interesting results.

Yeah, this is just an older version of https://mc.yandex.ru/metrika/tag.js (version: "4uzkmd4e35bv9wjiv", instead of "a8mjecangl5v275zywhk", which Yandex is currently serving. From what I can tell, (most of?) this script is just creating a fingerprint, so I'm less concerned about older versions returning a different result.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXt2WFzLVucGrSmASm4WO%3DzHPqL397%3Dr27%2B7-fUnELwuw%40mail.gmail.com.

[jmedley via Chromestatus]

What version are you hoping to ship this in?

[jmedley via Chromestatus]

You already told me 104. Sorry about that. I have a lot simultaneous conversations like this.