Contact emails
*andr...@chromium.org <andr...@chromium.org>kbabb...@microsoft.com <kbabb...@microsoft.com>*Explainer *NoneThis article by Bramus <https://www.bram.us/2021/10/26/media-queries-level-4-media-query-range-contexts/> may be helpful.*Specification *https://www.w3.org/TR/mediaqueries-4/#mq-range-context <https://www.w3.org/TR/mediaqueries-4/#mq-range-context>*Summary *Allows writing media queries using ordinary mathematical comparison operators <https://drafts.csswg.org/mediaqueries-4/#typedef-mf-range>, and adds support for or <https://drafts.csswg.org/mediaqueries-4/#typedef-media-or>, not <https://drafts.csswg.org/mediaqueries-4/#typedef-media-not>, nesting <https://drafts.csswg.org/mediaqueries-4/#typedef-media-in-parens>, and the special evaluation of “unknown” <https://drafts.csswg.org/mediaqueries-4/#:~:text=The%20result%20is%20unknown> features.Tiny example:Without this feature: @media (min-width: 100px)With this feature: @media (width >= 100px)*Blink component *Blink>CSS <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>*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 <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 <https://github.com/w3c/csswg-drafts/issues/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 signalsOther 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” <https://drafts.csswg.org/mediaqueries-3/#:~:text=when%20one%20of%20the%20specified%20media%20features%20is%20not%20known.>). 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% <https://chromestatus.com/metrics/feature/timeline/popularity/4082>MediaList::mediaText | ~0.1% <https://chromestatus.com/metrics/feature/timeline/popularity/4083>CSSConditionRule.conditionText | ~0.007% <https://chromestatus.com/metrics/feature/timeline/popularity/4084>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://docs.google.com/spreadsheets/d/1z6HaTSgV1jVpJvQbTvYObUlaMYpgbvfzqmy-NESuHKw/edit?usp=sharing>]: - https://mc.yandex.ru/metrika/tag.js <https://mc.yandex.ru/metrika/tag.js>- https://mc.yandex.ru/metrika/watch.js <http://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 <https://wiki.csswg.org/ideas/mistakes#:~:text=Selectors%20have%20terrible%20future%2Dproofing> for media queries.*Debuggability *The new syntax is automatically visible in devtools.*Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> ? *NoThe 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” <https://drafts.csswg.org/mediaqueries-4/#:~:text=The%20result%20is%20unknown>.*Flag name *CSSMediaQueries4*Requires code in //chrome? *False*Tracking bug *https://bugs.chromium.org/p/chromium/issues/detail?id=962417 <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 <https://chromestatus.com/> (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+unsubscr...@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.
