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

The CSS Working Group just discussed ``[mediaqueries] Consider `@media supports()` ``, and agreed to the following:

* `RESOLVED: add  a new condition= attribute that takes <import-condition> syntax`
* ``RESOLVED: Do not add `supports()` to @media.``

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> bramus: For @import we have a bunch of conditions we can tag onto it, MQs and supports()<br>
&lt;TabAtkins> bramus: You can use @supprots in your stylesheet, but we wanted a way to add it into &lt;link rel=stylesheet><br>
&lt;TabAtkins> bramus: Proposal's evolved a bit. Currently proposal is a `condition=""` attribute<br>
&lt;TabAtkins> bramus: This new attribute is future proof; if we just add &lt;link supports> then what about the next condition<br>
&lt;miriam> q+<br>
&lt;TabAtkins> bramus: I was thinking the syntax would be `condition="supports(...) and media(...)"`<br>
&lt;TabAtkins> bramus: You have the same problem as with any new attribute, browsers that dont' udnerstand the attr will ignore it and apply the stylesheet<br>
&lt;TabAtkins> bramus: So followup, maybe `media=""` can accept these? And we can add `condition=""` as a synonym?<br>
&lt;astearns> ack miriam<br>
&lt;emilio> q+<br>
&lt;TabAtkins> miriam: some context, we discussed at TPAC in meeting with WHATWG<br>
&lt;TabAtkins> miriam: We'd proposed extending `media=""` to accept all import conditions<br>
&lt;TabAtkins> miriam: the WHATWG did not like that<br>
&lt;TabAtkins> miriam: advantage of using `media` is that it would be backcompat, it already fails if it's got unknown stuff<br>
&lt;TabAtkins> miriam: They'd prefer us to think about the future; it's only a small polyfill to work around this for now<br>
&lt;TabAtkins> miriam: So new proposal is the new attribute. I think Bramus's idea of a new generic condition attribute is fine.<br>
&lt;TabAtkins> miriam: No need to define what goes into it, it should match @import<br>
&lt;TabAtkins> miriam: taking the &lt;import-condition> syntax, which is already defined<br>
&lt;astearns> ack emilio<br>
&lt;TabAtkins> q+<br>
&lt;TabAtkins> emilio: I'm not totally opposed to new attr, but it feels like a much bigger endeavor<br>
&lt;TabAtkins> emilio: media is used on more things, &lt;meta>, &lt;source>,e tc<br>
&lt;TabAtkins> emilio: I guess we can figure out if all of those need condition or can be just media, but that feels weird<br>
&lt;TabAtkins> emilio: We also need to figure out how media nad condition interact<br>
&lt;TabAtkins> emilio: And iirc, media attribute ends up in CSSSTyleSheet.media in th OM<br>
&lt;bramus> q+<br>
&lt;TabAtkins> emilio: So do we need to reflect condition into the stylesheet? Only if it's an MQ?<br>
&lt;TabAtkins> emilio: Seems okay in theory but it's a lot more work<br>
&lt;TabAtkins> emilio: than just reusing media<br>
&lt;astearns> ack TabAtkins<br>
&lt;miriam> q+<br>
&lt;fantasai> TabAtkins: I think that the 'condition' attribute is fine<br>
&lt;fantasai> TabAtkins: agree that re-using &lt;import-condition> is right<br>
&lt;fantasai> TabAtkins: a) everything that takes media= should take condition= ; no reason to restrict<br>
&lt;fantasai> TabAtkins: b) interaction between media= and condition= should be imo, in presence of condition= media= is ignored<br>
&lt;bramus> CLEVER!<br>
&lt;fantasai> TabAtkins: that helps with the polyfill, because you can put a guaranteed failing media condition in<br>
&lt;fantasai> TabAtkins: c) for media query in stylesheet, don't think it's particularly needed. We can always add later if we feel it's necessary<br>
&lt;astearns> ack bramus<br>
&lt;emilio> wfm<br>
&lt;TabAtkins> bramus: I think my concern is addressed by Tab's (b)<br>
&lt;fantasai> bramus: my concern addressed by saying media= gets ignored<br>
&lt;TabAtkins> bramus: But then why don't we just upgrade media= to accept import conditions?<br>
&lt;TabAtkins> astearns: I can see the parsimony of just updating media=<br>
&lt;TabAtkins> astearns: But we can take this as designing a well-rounded condition attribute without worrying about the cruft of media=<br>
&lt;fantasai> TabAtkins: parsing of raw media query is pretty weird, because of media types<br>
&lt;fantasai> TabAtkins: having new attribute with media() function helps<br>
&lt;fantasai> TabAtkins: also addresses question of reflection into stylesheet<br>
&lt;fantasai> TabAtkins: if in media= have to say how it reflects, but new attribute can just not<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: disagree with TAb about media vs condition<br>
&lt;TabAtkins> fantasai: Think both should apply when both specified<br>
&lt;TabAtkins> fantasai: But think we can add a keyword to media that says "go look at condition=", which'll be invalid on downlevel clients<br>
&lt;bramus> q+<br>
&lt;TabAtkins> fantasai: I think if someone wrote an MQ they shouldn't have to duplicate that into condition=<br>
&lt;TabAtkins> fantasai: We've also had discussions about @layer<br>
&lt;TabAtkins> fantasai: It's not a conditional, and it has to be reflected in the OM<br>
&lt;TabAtkins> fantasai: So would this new condition attr take in things like that?<br>
&lt;TabAtkins> fantasai: Or would that have to be an additional attribute?<br>
&lt;TabAtkins> miriam: This would not take layer()<br>
&lt;TabAtkins> miriam: Just the import conditions<br>
&lt;TabAtkins> miriam: WHATWG was very open to new attributes for things like @layer<br>
&lt;TabAtkins> miriam: We wanted to solve this first so you can add layer= *and* have a way to make it fail if layer wasn't supported<br>
&lt;TabAtkins> miriam: This solves that, you can fail it with a support query<br>
&lt;astearns> ack miriam<br>
&lt;TabAtkins> miriam: That leads into my next , I agree with Elika on how media/condition should interact<br>
&lt;dbaron> also +1 to fantasai's proposal on interaction<br>
&lt;TabAtkins> miriam: Main consideration for emilio's q about putting this on more media= things<br>
&lt;TabAtkins> miriam: If we define this as &lt;import-condition>, which is defined around stylesheets, will this be an issue later?<br>
&lt;TabAtkins> miriam: Like an import condition that makes sense for images, specifically?<br>
&lt;TabAtkins> miriam: And is that even an issue? Or would you just ignore/fail on the other elements?<br>
&lt;TabAtkins> TabAtkins: I think we'd just fail queries that didn't apply to that type of import, yeah<br>
&lt;TabAtkins> miriam: Would we define these new kinds of queries in &lt;import-condition>?<br>
&lt;TabAtkins> TabAtkins: Maybe. Or we'd extract the grammar ot an independent spec and just ref it in @import.<br>
&lt;astearns> ack bramus<br>
&lt;TabAtkins> bramus: I'm less sure about media= and condition= both declared<br>
&lt;TabAtkins> bramus: I see authors moving to using only condition= with media()<br>
&lt;TabAtkins> bramus: So for migration/polyfill I lean toward Tab's idea, but I need to give it more thought<br>
&lt;TabAtkins> astearns: I think we can open separate issue<br>
&lt;TabAtkins> TabAtkins: Yeah, I don't feel strongly about this, but would like to discuss it a bit more. Do it off the call<br>
&lt;TabAtkins> fantasai: I see authors probably still using media= just becuase it's shorter, why type more<br>
&lt;TabAtkins> astearns: Do we ahve an issue about other elements using media=? Or should we just resolve it today?<br>
&lt;TabAtkins> fantasai: Well we don't control HTML but can make a proposal.<br>
&lt;TabAtkins> fantasai: Thinking about what would be a reasonable resolution...<br>
&lt;TabAtkins> fantasai: Can resolve to explore condition=<br>
&lt;TabAtkins> fantasai: Can definitely resolve to reject media=supports()<br>
&lt;TabAtkins> astearns: Proposed is we solve the use-cases with a new condition= attribute that takes &lt;import-condition> syntax<br>
&lt;fantasai> also @media supports(), which is the title of the issue<br>
&lt;fantasai> 100% not accepted<br>
&lt;TabAtkins> astearns: Any objections?<br>
&lt;TabAtkins> RESOLVED: add  a new condition= attribute that takes &lt;import-condition> syntax<br>
&lt;TabAtkins> TabAtkins: should we resolve to reject @media supports()?<br>
&lt;TabAtkins> astearns: yeah. objections?<br>
&lt;TabAtkins> RESOLVED: Do not add `supports()` to @media.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9375#issuecomment-1854458821 using your GitHub account


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

Received on Wednesday, 13 December 2023 18:00:15 UTC