[css-cascade-6] Add a `media()` function for `@import` #10972

romainmenke · 2024-09-28T13:19:15Z

Media query lists can be partially valid.

This means that any @import that has both a media query list of at least two parts and any unknown condition will just swallow that unknown part as if it were an invalid media query.

https://codepen.io/romainmenke/pen/QWebVmp

@import url("foo.css") screen, screen does-not-exist();
@import url("foo.css")  does-not-exist() screen, screen;

In either case screen does-not-exist() forms an invalid media query and the media query list will always be a singular screen.

Ideally we want unknown parts to invalidate the entire @import, not the first or last media query in a media query list.

Proposal

Should we have a media() function to mirror scope(), supports(), ... ?
Wrapping it in a function makes it unambiguous what is part of a media query and what is not.

@import statements with both a media() function and a bare media query list should not be allowed. Bare media queries could even be marked as a "legacy syntax" and authors could be advised not to use it.

This function itself would suffer from the same problem it is trying to address but this would be a short term pain.

Because it is purely syntactic sugar we can transpile with tooling and authors could adopt this quickly.

Workaround

Any media query list can be split into multiple import statements:

@import url("foo.css") screen;
@import url("foo.css") screen does-not-exist();

/* two imports for `screen` don't make sense in practice, but imagine something more creative and useful */

I think this is also fine and we can have tooling to help authors (lint rules, ...)
Drawback is that it isn't obvious that you sometimes need to do this and authors shouldn't need to use tool.

Even less obvious when you can clean this up.
At some point all end users of a project will support the newly added syntax and the statements can be joined again.

I prefer a new media() function as this doesn't have any sharp edges and gives a nice parallel between the other import conditions.

The text was updated successfully, but these errors were encountered:

andruud · 2024-11-07T13:34:00Z

+1 to this.

@import statements with both a media() function and a bare media query list should not be allowed.

Additionally, I assume we'd probably want to not allow mixing of "new stuff" (just scope(), at the moment) and bare MQ.

Without media(), we'll at least need to say that MQs always go last, although I think media() is a better solution.

cc @mirisuzanne

tabatkins · 2024-11-08T00:29:06Z

Yeah, I'll have to squint at the grammar to make sure that's enforceable, but if we could just branch it so an import either has a bare MQ or has all the new things (including media()), that would be ideal.

This CL implements the ability to scope an entire stylesheet on import, via the new scope() function. The CSSWG has resolved to add the scope() function, but there is no spec yet. The WPTs are therefore marked as tentative for now. Note that this CL intentionally does not have parse-validity tests, such as scope() combined with other features of the @import prelude (e.g. layer(), media queries). This is because scope()'s "position" in the prelude grammar has not been defined, and the WG instead resolved allow full reordering of the conditions. This opens a new problem, tracked by Issue 10972 [1]. In other words, parsing tests are deferred until that issue is resolved. The WPTs in this only use @import scope(...)", which is assumed to be valid regardless of the outcome. Since regular top-level selectors are not relative selectors, they are not guaranteed to contain either '&' or ':scope' like selector parsing nested under CSSNestingType::kNesting or CSSNestingType::kScope (respectively). This means that selectors at the top-level of an imported stylesheet are not guaranteed to be scope-containing, so we need another way of enforcing the in-scope [2] requirement of scoped selectors. This is effectively done by always treating the last selector in a complex selector as scope-containing. Due to the same absence of '&' and ':scope' in the imported stylesheet, rules can also be incorrectly handled as "easy" or "covered by bucketing" even though they match in the context of a scope. Addressed this by disabling the optimization when context.style_scope is set. [1] w3c/csswg-drafts#10972 [2] https://drafts.csswg.org/css-cascade-6/#in-scope Bug: 369876911 Change-Id: I75bc3514d959c6762232bc769f844682ed4a50fd

This CL implements the ability to scope an entire stylesheet on import, via the new scope() function. The CSSWG has resolved to add the scope() function, but there is no spec yet. The WPTs are therefore marked as tentative for now. Note that this CL intentionally does not have parse-validity tests, such as scope() combined with other features of the @import prelude (e.g. layer(), media queries). This is because scope()'s "position" in the prelude grammar has not been defined, and the WG instead resolved allow full reordering of the conditions. This opens a new problem, tracked by Issue 10972 [1]. In other words, parsing tests are deferred until that issue is resolved. The WPTs in this only use @import scope(...)", which is assumed to be valid regardless of the outcome. Since regular top-level selectors are not relative selectors, they are not guaranteed to contain either '&' or ':scope' like selector parsing nested under CSSNestingType::kNesting or CSSNestingType::kScope (respectively). This means that selectors at the top-level of an imported stylesheet are not guaranteed to be scope-containing, so we need another way of enforcing the in-scope [2] requirement of scoped selectors. This is effectively done by always treating the last selector in a complex selector as scope-containing. Due to the same absence of '&' and ':scope' in the imported stylesheet, rules can also be incorrectly handled as "easy" or "covered by bucketing" even though they match in the context of a scope. Addressed this by disabling the optimization when context.style_scope is set. [1] w3c/csswg-drafts#10972 [2] https://drafts.csswg.org/css-cascade-6/#in-scope Bug: 369876911 Change-Id: I75bc3514d959c6762232bc769f844682ed4a50fd Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6012179 Commit-Queue: Anders Hartvoll Ruud <[email protected]> Reviewed-by: Rune Lillesveen <[email protected]> Cr-Commit-Position: refs/heads/main@{#1383152}

…hind a flag, a=testonly Automatic update from web-platform-tests [@scope] Support '@import scope(...)' behind a flag This CL implements the ability to scope an entire stylesheet on import, via the new scope() function. The CSSWG has resolved to add the scope() function, but there is no spec yet. The WPTs are therefore marked as tentative for now. Note that this CL intentionally does not have parse-validity tests, such as scope() combined with other features of the @import prelude (e.g. layer(), media queries). This is because scope()'s "position" in the prelude grammar has not been defined, and the WG instead resolved allow full reordering of the conditions. This opens a new problem, tracked by Issue 10972 [1]. In other words, parsing tests are deferred until that issue is resolved. The WPTs in this only use @import scope(...)", which is assumed to be valid regardless of the outcome. Since regular top-level selectors are not relative selectors, they are not guaranteed to contain either '&' or ':scope' like selector parsing nested under CSSNestingType::kNesting or CSSNestingType::kScope (respectively). This means that selectors at the top-level of an imported stylesheet are not guaranteed to be scope-containing, so we need another way of enforcing the in-scope [2] requirement of scoped selectors. This is effectively done by always treating the last selector in a complex selector as scope-containing. Due to the same absence of '&' and ':scope' in the imported stylesheet, rules can also be incorrectly handled as "easy" or "covered by bucketing" even though they match in the context of a scope. Addressed this by disabling the optimization when context.style_scope is set. [1] w3c/csswg-drafts#10972 [2] https://drafts.csswg.org/css-cascade-6/#in-scope Bug: 369876911 Change-Id: I75bc3514d959c6762232bc769f844682ed4a50fd Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6012179 Commit-Queue: Anders Hartvoll Ruud <[email protected]> Reviewed-by: Rune Lillesveen <[email protected]> Cr-Commit-Position: refs/heads/main@{#1383152} -- wpt-commits: 8c083dd5f5cf5801b2ae298bec62fc55e9226d74 wpt-pr: 49178

Note that the Media Query part still needs to appear last in the grammar due to w3c#10972.

…hind a flag, a=testonly Automatic update from web-platform-tests [@scope] Support '@import scope(...)' behind a flag This CL implements the ability to scope an entire stylesheet on import, via the new scope() function. The CSSWG has resolved to add the scope() function, but there is no spec yet. The WPTs are therefore marked as tentative for now. Note that this CL intentionally does not have parse-validity tests, such as scope() combined with other features of the @import prelude (e.g. layer(), media queries). This is because scope()'s "position" in the prelude grammar has not been defined, and the WG instead resolved allow full reordering of the conditions. This opens a new problem, tracked by Issue 10972 [1]. In other words, parsing tests are deferred until that issue is resolved. The WPTs in this only use @import scope(...)", which is assumed to be valid regardless of the outcome. Since regular top-level selectors are not relative selectors, they are not guaranteed to contain either '&' or ':scope' like selector parsing nested under CSSNestingType::kNesting or CSSNestingType::kScope (respectively). This means that selectors at the top-level of an imported stylesheet are not guaranteed to be scope-containing, so we need another way of enforcing the in-scope [2] requirement of scoped selectors. This is effectively done by always treating the last selector in a complex selector as scope-containing. Due to the same absence of '&' and ':scope' in the imported stylesheet, rules can also be incorrectly handled as "easy" or "covered by bucketing" even though they match in the context of a scope. Addressed this by disabling the optimization when context.style_scope is set. [1] w3c/csswg-drafts#10972 [2] https://drafts.csswg.org/css-cascade-6/#in-scope Bug: 369876911 Change-Id: I75bc3514d959c6762232bc769f844682ed4a50fd Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6012179 Commit-Queue: Anders Hartvoll Ruud <[email protected]> Reviewed-by: Rune Lillesveen <[email protected]> Cr-Commit-Position: refs/heads/main@{#1383152} -- wpt-commits: 8c083dd5f5cf5801b2ae298bec62fc55e9226d74 wpt-pr: 49178

cdoublev · 2024-11-28T08:52:49Z

As noted in #11237 (comment), defining <media()> = media(<media-query-list>) could be useful.

I do not know if if() intentionally uses media(<media-query>) but color: if(media(unknown): green) would be invalid, but not with media(<media-query-list>), if I am not mistaken. edit: never mind, the query is syntactically valid and evaluates to false (like, media(1), which would become media(not all)).

css-meeting-bot · 2025-04-02T17:50:54Z

The CSS Working Group just discussed [css-cascade-6] Add a `media()` function for `@import` , and agreed to the following:

RESOLVED: Expand supports term of @import production to a boolean tree that supports a media function, and figure out download stuff as we go

The full IRC log of that discussion

<kbabbitt> TabAtkins: the @import grammar is a mess because we have to assume whatever follows is a MQ
<kbabbitt> ... we have some workarounds to put a support after it
<kbabbitt> ... it's a little weird
<kbabbitt> .. question here is if we could add a media function like supports function
<kbabbitt> ... and then change grammar of @import such that it first checks for a boolean expression
<kbabbitt> ... and if not parse it as an MQ per legacy behavior
<kbabbitt> ... that will allow authors to get full good boolean behavior, even with MQs
<kbabbitt> ... without breaking naked MQs following import
<kizu> +1, sounds reasonable
<kbabbitt> astearns: trying to load this into my mind
<kbabbitt> ... if what we get is not a boolean, are you sure it's always going to be good to parse it as a MQ function?
<kbabbitt> TabAtkins: that's what we do today
<kbabbitt> ... grammar for @import will try to parse as a MQ
<kbabbitt> ... which is a broad syntax
<kbabbitt> ... will eat a lot of things and turn them into unknown MQs
<kbabbitt> astearns: wondering whether... we're doing this for media function, any others we might want to add in the future?
<kbabbitt> TabAtkins: problem right now is that imports take bare MQ right now
<kbabbitt> ... we also have a proposal for supports function
<kbabbitt> ... this is makeing it so we can do either a bare MQ or dual function with supports
<kbabbitt> astearns: OK
<kbabbitt> ... any other questions?
<emilio> Yeah, @import ... supports() is a thing already
<dbaron> +1
<bkardell> q+
<emilio> +1
<kbabbitt> TabAtkins: proposed: add a media function alongside supports function to @import
<kbabbitt> ... and switch grammar around so that we first try to match as boolean expression with these functions
<miriam> q+
<astearns> ack bkardell
<kbabbitt> ... and if not, treat as bare MQ
<kbabbitt> bkardell: any preprocessor that tries to enable this?
<kbabbitt> TabAtkins: I don't think there's one currently
<kbabbitt> ... just that especially when media type is involved in query, parsing is wider than you think and confusing in some corner cases
<kbabbitt> bkardell: are there bugs where people are running into this?
<kbabbitt> TabAtkins: don't know
<lea> +1, seems reasonable to me too
<kbabbitt> bkardell: curious how this came up? is there demand?
<kbabbitt> miriam: roman brought it up and works on a preprocessor
<astearns> ack miriam
<kbabbitt> miriam: this has no impact on order of things, right?
<kbabbitt> ... layer and scope have to come first, then conditions?
<kbabbitt> TabAtkins: yes because those are not part of boolean syntax
<astearns> ack fantasai
<Zakim> fantasai, you wanted to ask for the proposed grammar
<kbabbitt> fantasai: tab can you type in proposed grammar?
<kbabbitt> TabAtkins: replace MQ list term with a boolean of the tests we use in if
<fantasai> @import [ <url> | <string> ]
<fantasai> [ layer | layer(<layer-name>) ]?
<fantasai> [ supports( [ <supports-condition> | <declaration> ] ) ]?
<fantasai> <media-query-list>? ;
<kbabbitt> TabAtkins: MQ list would become a boolean
<kbabbitt> dbaron: was part of the intent to allow and and or between media?
<TabAtkins> @import <url> layer? <boolean [<supports> | <media>] >?
<bkardell> oh - layers right...
<kbabbitt> TabAtkins: MQless version as an alternative if first presents parsing error
<bkardell> yeah seems reasonable
<kbabbitt> fantasai: OK I think I understand
<dbaron> I think s/MQless/MQ/
<kbabbitt> ...basically like added conditional syntax
<fantasai> s/added/@if/
<kbabbitt> TabAtkins: right now you can't do supports or MQ
<TabAtkins> TabAtkins: you have to do both
<kbabbitt> astearns: Proposed resolution is to add media function to the @import syntax
<kbabbitt> dbaron: I think there's maybe one grammar alternative
<kbabbitt> ... maybe a boolean in a different way
<kbabbitt> ... could turn current supports function into boolean supports media
<kbabbitt> .. and leave backcompat media term after it
<kbabbitt> ... would in theory allow both
<kbabbitt> ... might be simpler form parsing perspective
<kbabbitt> TabAtkins: think that might be better because media function doesnt allow media type, just feature
<kbabbitt> ... e.g. print, not expressible as a feature
<dbaron> dbaron: ... not sure if it's better or worse.
<kbabbitt> ... could still put it at the end
<kbabbitt> TabAtkins: Proposed: expand supports term to be a boolean tree that also supports media function
<kbabbitt> fantasai: new grammar that was not posted?
<kbabbitt> TabAtkins: exactly as current except replace supports by supports or media
<kbabbitt> fantasai: supports(foo) or media(bar)
<kbabbitt> ... and print
<kbabbitt> ... is print then intersected with supports?
<fantasai> s/and//
<kbabbitt> TabAtkins: yes both must be true
<emilio> q+
<kbabbitt> astearns: same condition in both, it may or may not match?
<kbabbitt> ... conflicting things won't match
<kbabbitt> TabAtkins: example?
<kbabbitt> astearns: media function can only express features
<kbabbitt> ... there's a subset of old production which can be expressed infunction
<kbabbitt> ... you can now have import statements that have media feature conditions in both places
<kbabbitt> TabAtkins: theoretically
<fantasai> @import "style" supports(foo) or media(bar) print; /* intersects { supports(foo) or media(bar) } and { print } */
<kbabbitt> astearns: we need to know how to process
<kbabbitt> TabAtkins: MQ list at end would be AND-ed with other conditions
<TabAtkins> Proposed: expand supports term to be a boolean tree that also supports media function
<kbabbitt> fantasai: [points to example above]
<kbabbitt> astearns: objections?
<astearns> ack emilio
<kbabbitt> emilio: not sure about mixing support and media
<kbabbitt> ... as in allowing you to write arbitrary bool expressions with them
<kbabbitt> ... because supports has different failure semantics than media
<kbabbitt> ... when supports doesn't match, doesn't applyu at all
<kbabbitt> ... whereas media can dynamically match
<kbabbitt> ... a bit weird when you start to mix them
<kbabbitt> .. could define that it doesn't do anything if supports condition doesn't match
<kbabbitt> ... but it's weird since you can also negate them
<kbabbitt> fantasai: good point
<kbabbitt> ... maybe media stuff in boolean means that it doesn't download
<kbabbitt> emilio: but that's bad
<kbabbitt> dbaron: you could use tristate boolean logic to solve this
<kbabbitt> emilio: MQ s are also a tristate
<kbabbitt> TabAtkins: can you elaborate why it's bad if a media function in supports term starts blocking downloading when false?
<kbabbitt> emilio: because then it goes past 6pm and your computer goes to sleep, download doesn't happen (?)
<kbabbitt> dbaron: condition changed but you're offline now and can't download
<kbabbitt> TabAtkins: I don't think we designed this behavior originally to support offline pages
<kbabbitt> ... we wanted to make sure print media could start wuickly without waiting for network
<kbabbitt> emilio: Not just print, also resizing
<kbabbitt> ... don't want intermediate state where page goes below threshold and now have to wait for another download
<kbabbitt> emilio: suddenly you have an FOUC
<kbabbitt> dbaron: I'm with emilio that we need to solve this correctly
<kbabbitt> ...l think it's doable but might need to work out in issue
<kbabbitt> emilio: could prove that a thing will never match but need to write algo for that
<kbabbitt> dbaron: the "should we download" algo is "every media function evaluates to unknown"
<kbabbitt> dbaron: if your top level result is unknown or ture, download
<kbabbitt> dbaron: but unknown and false is false
<kbabbitt> TabAtkins: yup
<kbabbitt> emilio: that works but it's a bit confusing with unknown MQ where that wouldn't ever match
<kbabbitt> dbaron: two different unknowns
<kbabbitt> ... known unknowns and unknown unknowns
<kbabbitt> emilio: that may need to get worked ouyt
<kbabbitt> ... not blocking on goal of this but speccing and implementing will be more fun
<dbaron> s/known unknowns and unknown unknowns/just don't call them known unknows and unknown unknowns :-)/
<kbabbitt> astearns: are we taking previous resolution and then working out download sematics?
<dbaron> (important substitution because that was a joke about the Rumsfeld quote)
<kbabbitt> TabAtkins: I'm fine with that
<TabAtkins> (i would like to avoid a 4-state boolean logic...)
<kbabbitt> astearns: Proposed: Expand supports term of @import production to a boolean tree that supports a media function
<kbabbitt> ... and figure out download stuff as we go
<kbabbitt> ... objections?
<kbabbitt> RESOLVED: Expand supports term of @import production to a boolean tree that supports a media function, and figure out download stuff as we go
<dbaron> (I think the two different unknowns *might* be at different stages of the processing pipeline...)
<TabAtkins> (i dont' think so, based on what emilio was saying about distinguishing between MQs we dont' know the value of, and MQs we dont' recognize)

romainmenke · 2025-04-04T09:23:37Z

@tabatkins Is it correct that this resolution is to extend the syntax for @import so that these for example becomes valid syntax:

@import "foo.css" supports(width: 10px) or media(color);
@import "foo.css" media(min-width: 200px) or media(color);

If so, I am not sure if there is a use case for that 🤔
Might be interesting but wasn't really what I had in mind :)

Does this allow anything that would not be possible by only adding a media() function that accepts a media query list?

Is it also correct that media types would not be allowed in media()?
If so, does it then still solve the original issue?

If CSS authors still have a reason to write bare media query lists they will still encounter the original issue, that unrelated parts might get ignored as an invalid media query.

e.g. @import "foo.css" media(color) print, something-we-havent-invented-yet;

Or do we already know that the list of types is not going to change going forwards?
With print and screen being the only ones that actually have purpose.

tabatkins · 2025-04-04T14:56:11Z

it correct that this resolution is to extend the syntax for @import so that these for example becomes valid syntax:

Yes, matching the syntax used for if() tests and the proposed @when generic-conditional rule. There's no reason to invent multiple slight variants of these syntaxes.

Is it also correct that media types would not be allowed in media()?
If so, does it then still solve the original issue?

Yes, media type is not allowed.

The resolution we ended up taking is that the trailing MQ is still allowed, so you can use a media type there if needed. Aside from that, tho, my and @frivoal's intention has always been to ensure that media features deprecate the need for media types, and at least in the case of print that should be sufficiently addressed by now.

Or do we already know that the list of types is not going to change going forwards?
With print and screen being the only ones that actually have purpose.

Correct, we consider media types to be a bad design and will not be extending the list further.

romainmenke · 2025-04-04T15:11:26Z

Sounds good!
Thank you 🙇

fantasai added css-cascade-5 css-cascade-6 labels Oct 7, 2024

andruud added the Agenda+ label Nov 7, 2024

chromium-wpt-export-bot mentioned this issue Nov 14, 2024

[@scope] Support '@import scope(...)' behind a flag web-platform-tests/wpt#49178

Merged

andruud added a commit to andruud/csswg-drafts that referenced this issue Nov 18, 2024

[css-cascade-6] "Add @import scope()" syntax, allow reordering

017b4d7

Note that the Media Query part still needs to appear last in the grammar due to w3c#10972.

andruud added a commit to andruud/csswg-drafts that referenced this issue Nov 18, 2024

[css-cascade-6] "Add @import scope()" syntax, allow reordering

d4a3a00

Note that the Media Query part still needs to appear last in the grammar due to w3c#10972.

astearns moved this to FTF agenda items in CSSWG January 2025 meeting Jan 22, 2025

astearns added this to CSSWG January 2025 meeting Jan 22, 2025

astearns moved this from FTF agenda items to Regular agenda items in CSSWG January 2025 meeting Jan 22, 2025

astearns moved this to Regular agenda in CSSWG April 2025 meeting agenda Mar 27, 2025

astearns added this to CSSWG April 2025 meeting agenda Mar 27, 2025

astearns moved this from Regular agenda to Tuesday Morning in CSSWG April 2025 meeting agenda Mar 27, 2025

astearns moved this from Tuesday Morning to Wednesday Afternoon in CSSWG April 2025 meeting agenda Mar 29, 2025

css-meeting-bot removed the Agenda+ label Apr 2, 2025

mozilla-apprentice mentioned this issue Apr 2, 2025

[css-cascade-6] Add a media() function for @import mozilla/wg-decisions#1882

Open

chromium-helper mentioned this issue Apr 2, 2025

[css-cascade-6] Add a media() function for @import chromium-helper/csswg-resolutions#766

Closed

css-meeting-bot mentioned this issue Apr 3, 2025

[selectors][css-conditional] Pseudo-class or combinator that is syntactic sugar for wrapping in an @rule #11969

Closed

romainmenke mentioned this issue Apr 4, 2025

Add specific parsing for a media query csstools/postcss-plugins#1590

Open

mirisuzanne added the Needs Edits label Apr 4, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-cascade-6] Add a `media()` function for `@import` #10972

[css-cascade-6] Add a `media()` function for `@import` #10972

romainmenke commented Sep 28, 2024

andruud commented Nov 7, 2024

tabatkins commented Nov 8, 2024

cdoublev commented Nov 28, 2024 •

edited

Loading

css-meeting-bot commented Apr 2, 2025

romainmenke commented Apr 4, 2025

tabatkins commented Apr 4, 2025

romainmenke commented Apr 4, 2025

[css-cascade-6] Add a media() function for @import #10972

[css-cascade-6] Add a media() function for @import #10972

Comments

romainmenke commented Sep 28, 2024

Proposal

Workaround

andruud commented Nov 7, 2024

tabatkins commented Nov 8, 2024

cdoublev commented Nov 28, 2024 • edited Loading

css-meeting-bot commented Apr 2, 2025

romainmenke commented Apr 4, 2025

tabatkins commented Apr 4, 2025

romainmenke commented Apr 4, 2025

[css-cascade-6] Add a `media()` function for `@import` #10972

[css-cascade-6] Add a `media()` function for `@import` #10972

cdoublev commented Nov 28, 2024 •

edited

Loading