- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Apr 2023 16:35:52 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-nesting-1] CSSOM for nested media query rules`, and agreed to the following:
* `RESOLVED: If naked property declarations inside @media become a thing, they are wrapped in a & {} rule.`
<details><summary>The full IRC log of that discussion</summary>
<fantasai> TabAtkins: last discussed in January<br>
<fantasai> ... basic question was, given that we allow nesting @media rule, and then you can put naked declarations inside, how do we expose that in the OM?<br>
<fantasai> ... currently CSSMediaRule only exposes child rules<br>
<fantasai> TabAtkins: The current proposal is if you have naked properties, they are effectively wrapped in a nested style rule with the & selector<br>
<fantasai> ... and are exposed that way<br>
<fantasai> ... This rule is the first rule in @media's child rules<br>
<fantasai> ... and only exists if it needs to<br>
<fantasai> TabAtkins: there were two further suggestions<br>
<fantasai> ... one was to add .style accessor that roots to this first style rule<br>
<fantasai> ... and/or to change parsing of all nested rules to wrap in & {} as well<br>
<fantasai> TabAtkins: there was mild opposition to both ideas, but ran out of time<br>
<fantasai> ... some concern about adding more rules to large stylesheet<br>
<fantasai> TabAtkins: suggestion that all nested @rules that accept style rules usually, wrap in & {}<br>
<fantasai> astearns: we could do things later?<br>
<fantasai> TabAtkins: we couldn't do the second thing, but adding .style is still possible in the future<br>
<fantasai> plinss: Some concern with ability to put raw declarations inside an @media rule that's nested<br>
<fantasai> ... because we get yet another situation where you can mix declarations and rules, but defaulting differently<br>
<fantasai> TabAtkins: ...<br>
<fantasai> plinss: @media contains rules, so it's in rule error recovery<br>
<fantasai> ... if you have stuff in side ...<br>
<fantasai> TabAtkins: using same error recovery in all places<br>
<fantasai> ... parser will fail rule parsing if it encounters ; before the block<br>
<fantasai> ... today if trying to parse a rule, it will encounter the ;, stop there, throw it out, and then start parsing fresh<br>
<fantasai> TabAtkins: semicolons have never been valid in the front of rules before, no expectation that this would break anything<br>
<fantasai> plinss: if we have declaration top-level with braces, then something that follows braces?<br>
<fantasai> TabAtkins: generally fine, some restrictions that we want to obey for future compatibility concerns, but very minor<br>
<fantasai> ... part of larger issue<br>
<fantasai> ... same effect here as anywhere else<br>
<fantasai> ... won't affect current stuff, because nothing looks like that today<br>
<fantasai> ... and in the future, you'll have the same set of restrictions everywhere, which are extremely minimal<br>
<fantasai> ... but that's the larger parsing issue, same issue; only concern here is whether existing @media would be parsed differently, and I think the answer is "no in practice"<br>
<fantasai> plinss: I accept it's part of the other issue<br>
<fantasai> ... also concerned about older browsers parsing new content<br>
<fantasai> TabAtkins: if you do nesting in an older browser, things will be very screwed up, misparsing is the least of your concerns<br>
<fantasai> astearns: in the interest of moving forward, perhaps we can resovle to wrap things in an implicit & rule if we allow naked declarations inside an @media rule<br>
<fantasai> plinss: I'm ok with that. I'm concerned about requiring &{} wrapping, ok if OM is same either way<br>
<fantasai> RESOLVED: If naked property declarations inside @media become a thing, they are wrapped in a & {} rule.<br>
<fantasai> emilio: Is this anonymous rule well-defined? it's at the beginning?<br>
<fantasai> TabAtkins: details in the issue, always at the beginning if it's needed<br>
<fantasai> plinss: If mix of declarations and rules, all the declarations sort to the beginning?<br>
<fantasai> TabAtkins: yes<br>
<fantasai> matthieudubet: if they actually write & { ... } explicitly, do we group with that?<br>
<fantasai> TabAtkins: no<br>
<fantasai> TabAtkins: if they explicitly write a rule, that's their rule, we don't do anything magic with that<br>
<fantasai> matthieudubet: OK, that's not what Safari Tech Preview is doing right now<br>
<fantasai> ... it tries to show the smallest representation with the same semantics<br>
<fantasai> ... so it removes it<br>
<heycam> @media (...) { & { color: red; } color: green; } /* element would be red */ ?<br>
<fantasai> TabAtkins: This isn't in the spec yet, so it's not tested yet, so Safari will discover if it's doing the wrong thing<br>
<fantasai> emilio: You can't just merge them because the order matters<br>
<fantasai> heycam: So just want to clarify that all the bare declarations get hoisted to the top of the rule<br>
<fantasai> ... so it might be a little confusing, about the order they'll applied<br>
<fantasai> TabAtkins: it's the same behavior you get in ordinary nested style rules, though<br>
<fantasai> ... all your naked declarations are sorted before all of the style rules<br>
<fantasai> fremy: we resolved that we would be consistent, and maybe discuss what to do (but nobody filed an issue about that)<br>
<fantasai> fremy: I think it's weird that they move, but should be consistent<br>
<fantasai> plinss: if I have a bare red and then two wrapped blue, and then bare green, I expect it to be green and it will be blue<br>
<fantasai> fremy: we discussed in the past, if we agree, we should file an issue about that<br>
<fantasai> TabAtkins: this is a minor issue for compat purposes, so we can adjust this<br>
<fantasai> TabAtkins: I think the answer is, don't put naked things after rules; but no reason to ban them<br>
<fantasai> ... either way it's confusing<br>
<fantasai> ... but I don't care which way we go<br>
<fantasai> ... but aside from that, that would be a separate issue, I think we're done with this issue<br>
<fantasai> astearns: resolution makes us consistent for the moment, but we can look at general issue on what to do with general declarations<br>
<fantasai> ACTION: fremy or plinss to file issue about whether naked declarations get sorted to the top of the list or not<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7850#issuecomment-1497794190 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 5 April 2023 16:35:54 UTC