Does the current implementation support use in `@import`? For example:
`@import url('foo.css') screen and (width <= 1200px);`在2022年4月11日星期一 UTC+8 19:57:12<yoav...@chromium.org> 写道： > Thanks for working on this!! > > On Mon, Apr 11, 2022 at 1:41 PM Anders Hartvoll Ruud <and...@chromium.org> > wrote: > >> Contact emails >> >> >> *and...@chromium.orgkbab...@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? Do we expect those 0.1% to visibly break? (I guess > that depends on what they're feature testing for..) > > >> >> >> >> >> >> >> >> >> *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+...@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/c5d13ddf-1d9b-458a-9f5b-30bad002064an%40chromium.org.
