[mediaqueries] Consider @media supports()

[zcorpan]

See whatwg/html#7540 (comment) 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

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 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.

[bleper]

This proposal duplicates the existing functions of the language, and such an illogical mixture of syntax is harmful to the future.

To mix the logic on media and support, there is https://drafts.csswg.org/css-conditional/#when-rule. For conditional import from documents, there is https://drafts.csswg.org/css-cascade/#at-import.

The web platform provides the corresponding tools on the CSS side. Responsibility for insufficient parity in HTML lies with the WHATWG.

[romainmenke]

Also important to take any future conditions into account.
At this time scope() is also accepted to be added as an import condition.

So @media (scope(...)) should then also be a thing.

[zcorpan]

For HTML we're reconsidering whether to use supports() in the media attribute, and may instead use a separate supports attribute. See whatwg/html#7540 (comment)

[mirisuzanne]

At this time scope() is also accepted to be added as an import condition.

Not quite. The scope() feature is planned as an addition to CSS imports alongside layer(), but they are not part of the 'import-condition' production. Scope and layer don't determine if the style sheet should be applied, but rather how it is applied.

---

To summarize the two options being discussed: in both cases, layer and scope and other import modifiers can be added to HTML as new attributes. The issue then is giving authors a way to add support-conditions while those new attributes are poorly supported. For that, we need a way to define support queries in HTML.

1. If we want these support conditions to work on browsers that pre-date the new syntax, then we need to build on an existing conditional attribute. We've discussed rel and type, but media seems to me like a clear winner. It might not be the ideal name for the thing, but it's also not an arbitrary mix of features – we would be defining the 'media' attribute to use the CSS 'import-condition' syntax. It's a syntax production that already exists in a well-defined space, and it already combines both media and support. But that's a tradeoff. How much do we care about failing the import in legacy browsers?
2. Alternately, we can decide (as the WHATWG suggests) that the legacy support issue is temporary, and in the long term we would prefer to have distinct attributes for each type of import condition. The media attribute continues to be media-specific, and we add a supports attribute. For now authors will need to polyfill that supports attribute, but that's entirely possible with a little bit of JS, and down the road we get a more clear syntax.

I think either option is a fairly reasonable tradeoff, depending what we want to prioritize. Option 1 gives us better legacy support. Option 2 is a cleaner syntax, but less useful in the short-term.

Looking ahead 5 years, I think the WHATWG is probably right that we don't need to overthink the transition period. Let's go with the cleaner separation of new attributes (option 2). The polyfill would be light-weight and temporary.

[bramus]

I’d rather see option 1 land, as with 2 we’ll have the same problem again whenever some new condition gets introduced.

Say – for some weird reason – a dayofweek condition gets added. We’d then need a new attribute for it and we’d be doing this whole dance all over again.

---

Taking a step back, you could say the following, since they’re all conditions:

• @supports translates to @if supports(…)
• @media translates to @if media(…)
• @media (prefers-* …) translates to @if prefers(…)

Say there wasn’t any way yet to apply these conditions via HTML yet, I’d come up with a [condition] attribute.

condition="supports(…) prefers(…)"
condition="media(…)"
condition="dayofweek(…)" 🤪

Lacking such an attribute today, we could reuse [media] (which might need a rename over time?) for it instead?

media="supports(…) prefers(…)"
media="media(…)"

And yes, media="media(…)" is redundant, but over time [media] would get renamed to [condition] in what I’m suggesting – I see a period of time where UAs would support both to then eventually deprecate [media].

[zcorpan]

I would be ok with adding a condition attribute and use a CSS-defined import condition, separately from the media attribute. This would make it easier to extend import conditions with new things in the future since HTML and CSSOM wouldn't need to be changed again. I like it, actually! Let's call this Option 3.

I don't think extending the media attribute is good long-term, nor is having two attributes with the same processing.

[bramus]

I don't think extending the media attribute is good long-term, nor is having two attributes with the same processing.

My suggestion is to make them aliases for a while and then eventually deprecate media in favor of the condition name, so you wouldn’t be able to use both at the same time. This maybe wasn’t clear in my post.

This aliasing is to cater for the time period in which browsers that don't understand [condition] would erroneously load the linked to file as they simply ignore that attribute.

Admittedly, a little of JS like Miriam suggested could plug this.

UPDATE: I see what you’re aiming at though: keep [media] for what does right now, and use [condition] to place all import conditions in. So yeah, maybe the aliasing I was suggesting isn’t needed after all.

[mirisuzanne]

That approach makes sense to me. To clarify: media queries would be allowed in both the existing media attribute and the new condition="media()" function (since that function is part of the css import-condition? I think that would be better than trying to exclude media conditions from the new condition attribute - even though it does allow for some duplication.

[css-meeting-bot]

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.

The full IRC log of that discussion

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

[mirisuzanne]

I tagged this as closed accepted by resolution. I'm not sure there's anything left to do here on the CSS side. We may also be able to close the issue? This is a signal of CSSWG support for a particular resolution of whatwg/html#7540

The secondary discussion topic that came up is how should media and condition attributes interact when both are specified? Do we need a new issue in the CSSWG for that, or can that be explored on the WHATWG issue?

[valtlai]

I’m not sure, but would when be a better name for the new attribute (instead of condition)? It would be consistent with the @when at-rule which takes similar (or the same?) syntax.

[mirisuzanne]

I like that. I think name is also open to bikeshedding - but probably best to discuss that in the WHATWG issue as well. They will have to make the final call on that.

[valtlai]

Okay, I copied the comment there.

[zcorpan]

Thanks all. I think we can close this issue with the resolution

RESOLVED: Do not add supports() to @media.

What to do when both are specified was discussed in the HTML issue iirc (failed condition means don't load, no-match media means load but don't apply).