On Mon, Apr 11, 2022 at 1:57 PM Yoav Weiss <yoavwe...@chromium.org> wrote:
> Thanks for working on this!! > > On Mon, Apr 11, 2022 at 1:41 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.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>* >> > > Did you try turning these counters to UKM that would enable you to dig > further in that usage? > 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. > > >> >> >> >> >> >> >> >> >> *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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUp4PiXx57G3-y8BxScG-ecHGSEPQZyZjoYGz8r_ECyipg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/CAKFBnUrBZYf06cGLHyq_aomNyQ_3YxFyBxO8k9_UWGQj6gfJcg%40mail.gmail.com.
