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