[csswg-drafts] [mediaqueries] Consider `@media supports()` (#9375)

zcorpan has just created a new issue for https://github.com/w3c/csswg-drafts:

== [mediaqueries] Consider `@media supports()` ==
See https://github.com/whatwg/html/issues/7540#issuecomment-1722080008 and following comments

@zcorpan 

> I think if we want `supports()` to apply to all `media=""` attributes, it should be part of MQ. But processing a media query list instead returns two booleans (supports result, MQ result), so that we can avoid fetching stylesheets where supports is false but do load them when supports is true (regardless of the MQ result).
> 
> This would make `supports()` consistently available (`Link` header, various HTML elements, `@import`, `@media`, constructable stylesheets options bag). Also makes the integration for HTML simpler, and less surgery needed in CSSOM. See [w3c/csswg-drafts#9361](https://github.com/w3c/csswg-drafts/issues/9361)
> 
> Maybe the `supportsText` for `CSSImportRule` wouldn't be needed anymore if it's part of the `MediaList`.

@emilio 

> @zcorpan what does that give you that renaming [this](https://drafts.csswg.org/css-cascade-5/#typedef-import-conditions) to `<style-sheet-condition>` or so and referencing that everywhere doesn't?
> 
> With your proposal it feels rather weird to be able to do `@media supports()`, and you'd need to track the "supports" result across the whole condition tree, which is a bit odd. So we'd need to convert the media query evaluation to track not only true/false/unknown as it does now, but something like always-true/always-false/true/false/unknown.
> 
> To be clear, I think that's doable, but it's probably less straight-forward than the alternative?

@zcorpan 

> I guess my main concern is consistency for web developers about where `supports()` works, and how to expose it in the CSSOM. So maybe first we need to decide whether `@media supports()` should be a thing.



Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9375 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 18 September 2023 17:06:00 UTC