On Mon, Apr 11, 2022 at 1:40 PM Anders Hartvoll Ruud <andr...@chromium.org> wrote:
> 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.* > Update: support from Webkit: https://www.mail-archive.com/webkit-dev@lists.webkit.org/msg30451.html > > > *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/CAKFBnUooymNwgbatr3fBmXHe9RA8atBQFLkPVCMxBC9wtYhhOA%40mail.gmail.com.
