- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 Jan 2023 17:02:00 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `CSSOM for nested media query rules`, and agreed to the following:
* ``RESOLVED: properties in a conditional rule get auto-wrapped in `& { ... }` ``
<details><summary>The full IRC log of that discussion</summary>
<fantasai> Subtopic: CSSOM for nested media query rules<br>
<fantasai> github: CSSOM for nested media query rules<br>
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/7850<br>
<fantasai> TabAtkins: Spec as currently defined alllows you to nest conditional rules and other rules directly inside a style rule<br>
<emilio> https://github.com/w3c/csswg-drafts/issues/8356<br>
<fantasai> TabAtkins: in that context, they can have properties directly in them<br>
<fantasai> TabAtkins: so e.g. div { ... @media something { color: blue; } }<br>
<fantasai> TabAtkins: question is, how do we reflect this in the OM<br>
<fantasai> TabAtkins: CSSMediaRule doesn't have .style<br>
<fantasai> TabAtkins: One possibility is to add .style<br>
<fantasai> TabAtkins: other possibility is treat such properties as wrapped in & { .. }<br>
<fantasai> TabAtkins: They would be exposed in their current OM<br>
<fantasai> -><br>
<fantasai> -> https://github.com/w3c/csswg-drafts/issues/7850<br>
<fantasai> TabAtkins: I suggest going with #2, because then we don't need to change the OM for any of these rules<br>
<Rossen_> q?<br>
<fantasai> TabAtkins: And also, if you're clearing out an at-rule, currently you can just replace .cssRules but if we add .style then you have to remember to clear out .style also<br>
<fantasai> TabAtkins: So that's my proposal<br>
<fremy> +1 to the second option<br>
<fantasai> TabAtkins: wrap directly-contained properties with `& { ... }`<br>
<lea> q?<br>
<lea> q+<br>
<fantasai> dbaron: Is there a way to distinguish these rules from real ones written that way?<br>
<fantasai> TabAtkins: No, and they would reserialize out with the & { ... } wrapper<br>
<Rossen_> ack lea<br>
<fantasai> TabAtkins: other than that no author-visible difference<br>
<dbaron> s/they would reserialize/we have a followup issue to discuss whether the reserialize/<br>
<fantasai> lea: I think option 2 is find for reading code, but could we author a shortcot for this sort of thing, e.g. adding .style to the OM<br>
<fantasai> lea: to provide a shortcut for creating this rule if it doesn't exist<br>
<fantasai> lea: if you read back .cssRules, it's fine to have the extra rule<br>
<fantasai> TabAtkins: setting .style sometimes creating a new rule is a bit magic<br>
<emilio> +1 tab<br>
<fantasai> TabAtkins: for any other case would have to manually construct the rule anyway? So I don't think it's worthwhile to have the additional magic for this case<br>
<fantasai> Rossen_: Lea, what you're suggesting can be added later<br>
<fantasai> lea: yes, that's why I don't feel too strongly about it<br>
<fantasai> dbaron: When I asked if they were distinguishable, I felt they should be distinguishable somehow<br>
<fantasai> dbaron: Seems nice if can reserialize in original form<br>
<fantasai> dbaron: also nice to distinguish<br>
<fantasai> TabAtkins: other than serialization, why distinguish?<br>
<fantasai> dbaron: can't think of anything<br>
<fantasai> dbaron: if there was an accessor on the container for this kind of thing ...<br>
<fantasai> dbaron: then you could compare to see if it's different<br>
<fantasai> dbaron: though maybe that's a bad idea<br>
<emilio> q+<br>
<fantasai> Rossen_: sounds like you talked yourself out of it<br>
<patrickangle_> q+<br>
<Rossen_> ack emilio<br>
<fantasai> emilio: Is this rule always need to be the first one?<br>
<fantasai> TabAtkins: that's a great question, I don't have a strong opinion on it<br>
<fantasai> TabAtkins: e.g. do properties outside rules all glom together ?<br>
<fantasai> TabAtkins: I don't have a strong opinion<br>
<dbaron> s/though maybe that's a bad idea/it would also let you do what lea was asking with a single additional access, if the access implicitly created it, though maybe that's a bad idea/<br>
<Rossen_> ack patrickangle_<br>
<fantasai> patrickangle_: Going back 1 step, we'll need to be able to distinguish for developer tools anyway, so will have to support in the engine even if not Web-exposed<br>
<Rossen_> ack fantasai<br>
<Zakim> fantasai, you wanted to point out cascade issues<br>
<TabAtkins> fantasai: question of whether these glom together or not is pretty important bc it chagnes the cascade implications<br>
<TabAtkins> fantasai: can have a selector that has the same specificity as the &, so if you have interleaved decls and they all have the same specificity, where they occur in order is gonna make a difference as to the output of the cascade<br>
<miriam> +1 - I don't think declarations should get merged like that<br>
<TabAtkins> fantasai: so if decls get glommed together and shifted to the top is something that needs to be definitely decided<br>
<fantasai> fantasai: because that impacts the cascade<br>
<fremy> I would not support "moving to the top" the declarations<br>
<TabAtkins> fantasai: I think we should do whatever we do outside of conditional rules<br>
<TabAtkins> fantasai: so if outside this context we glom them all together and handle them as occuring before all other rules, then we should do the same thing insdie of conditional rules<br>
<TabAtkins> fantasai: And if it's not, we shouldn't<br>
<Rossen_> q?<br>
<fantasai> TabAtkins: We do indeed effectively glom all the un-nested declarations together outside of conditional rules, so I suggest we glom them together<br>
<fantasai> fremy: I don't like that. I prefer in both cases we create an & rule<br>
<TabAtkins> today, in `.foo { color: red; & { ... } width: 100px; }`, we treat it as equivalent to `.foo { color: red; width: 100px; & {...}}`<br>
<fantasai> TabAtkins: First proposed resolution, properties in a default style rule get auto-wrapped in `& { ... }`<br>
<fantasai> Rossen_: objections?<br>
<fantasai> RESOLVED: properties in a conditional rule get auto-wrapped in `& { ... }`<br>
<fantasai> TabAtkins: For declarations which are not at the top, do we do the same thing as style rules or do we wrap each bunch independently or move them all to the top?<br>
<fantasai> fremy: another option is to make them invalid<br>
<fantasai> fremy: idk if worth considering<br>
<TabAtkins> 1. Similar to style-rules-in-style-rules, treat all nested props as if they occurred together at the top, before any other rules?<br>
<fantasai> fremy: I find it pretty confusing that you can write something after something else, and it's treated as coming before<br>
<TabAtkins> 2. Wrap properties in the default-style-rule where they stand, letting them interleave.<br>
<fantasai> ??: If serialize with .cssText, then [missed, could be confusing]<br>
<TabAtkins> 3. Treat this as invalid (presumably dropping properties that occur after rules?)<br>
<TabAtkins> s/??/matthieudubet/<br>
<fantasai> TabAtkins: for .cssText, I woudl serialize in canonical form<br>
<fantasai> TabAtkins: assuming we glom together, then if first rule in your .cssRules is & by itself, then we serialize that as naked properties<br>
<fantasai> matthieud: That's what we assume, but then ppl write declarations and then [missed]<br>
<fantasai> matthieud: but maybe it's not an issue?<br>
<fantasai> TabAtkins: My proposed resolution is that we treat interleaved declarations the same way in style rules, i.e. they are all sorted to the top<br>
<fantasai> fremy: Can we resolve to do exactly as for style rules, but then discuss if that's what we actually want for style rules?<br>
<fantasai> TabAtkins: works for me<br>
<miriam> +1<br>
<fantasai> Proposed resolution: do exactly as for style rules wrt sorting of declarations interleaved with style rules<br>
<Rossen_> ack fantasai<br>
<TabAtkins> fantasai: the reason we didn't do it for style rules is we don't have OM ability to support that for style rules<br>
<TabAtkins> fantasai: the expectation is that all decls would be in a .style property, and to do that we can't carea bout their order wrt .cssRules<br>
<TabAtkins> fantasai: So worth pointing out that a .cssRules in a style rule will not contain the naked properties<br>
<TabAtkins> fantasai: So that's different from in conditional rules, which is a little inconsistent.<br>
<TabAtkins> fantasai: So do we really want that inconsistency, or do we want to do something like Lea's proposed magic, or...?<br>
<fantasai> fantasai: but it is inconsistent<br>
<fantasai> TabAtkins: I would have preferred something like this resolution for style rules as well, but for clear legacy reasons we can't do that for style rules -- authors need to be able to manipulate in .style<br>
<fantasai> TabAtkins: but we need to make sure that the cascade is consistently handled<br>
<TabAtkins> fantasai: one thing we could do to keep it consistent is to have .style represent the first &-selector'd rule inside of .cssRules<br>
<TabAtkins> fantasai: and then do that for both style and conditional rules<br>
<Rossen_> ack fantasai<br>
<TabAtkins> fantasai: And all subsequent groups of declarations would each get their own &-rule that would *not* be accessible via .style<br>
<TabAtkins> fantasai: And that would give the same interface for both. It would keep the interleaved order of decls.<br>
<fremy> (what fantasai just described is my preference)<br>
<TabAtkins> fantasai: Not sure if that's what we want, but it would give consistent OM & cascading.<br>
<fantasai> s/cascading/cascading while allowing preserving interleaved order/<br>
<fantasai> plinss: [something]<br>
<fantasai> TabAtkins: Yes<br>
<TabAtkins> plinss: An alternative is, inside conditional rules all properties are wrapped in an &-rule, but in a regular style rule the *first* group of properties is not, but later ones do<br>
<TabAtkins> plinss: so in `.foo { color: red; &{...} color: blue; }`, it's equivalent to `.foo { color: red; &{...} &{color: blue;}}`<br>
<TabAtkins> emilio: perf-wise that seems slightly problematic<br>
<Rossen_> q?<br>
<TabAtkins> emilio: not quite clear how it would work with shorthands<br>
<TabAtkins> emilio: I think coalescing them makes sense<br>
<TabAtkins> emilio: otherwise using shorthands becomes different inside a conditional rule vs in a style rule<br>
<TabAtkins> emilio: I'm not a fan of wrapping everything inside of different rules - it means now you have to selector-match more times<br>
<fremy> I am not sure I understood that, but we are out of time, so we should clarify on thread<br>
<TabAtkins> Rossen_: Objections?<br>
<TabAtkins> fantasai: Seems like there ar emore things to consider than we thought at the start, wouldn't be good to resolve yet<br>
<TabAtkins> Rossen_: Okay, take the rest to the thread<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-1403937203 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 January 2023 17:02:03 UTC