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