CSS Nesting: @nest

[andruud]

Request for Mozilla Position on an Emerging Web Specification

• Specification title: CSS Nesting
• Specification or proposal URL (if available): https://drafts.csswg.org/css-nesting/
• Explainer URL (if available):
• Proposal author(s) (@-mention GitHub accounts): @tabatkins
• Caniuse.com URL (optional): https://caniuse.com/css-nesting
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=1648037
• Mozillians who can provide input (optional): @emilio
• WebKit position: CSS Nesting: @nest WebKit/standards-positions#337

Other information

Basically this proposal from Tab.

I am a bit reluctant to ship this since we have a major open issue about how it should appear in CSSOM (w3c/csswg-drafts#10234), but apparently the CSSWG wants to ship @nest as currently specified now, then consider any additional changes later (w3c/csswg-drafts#10234 (comment), w3c/csswg-drafts#10234 (comment)).

So I am specifically asking for a position on shipping the (possibly intermediate) state of @nest as it's currently specified, despite w3c/csswg-drafts#10234 not being resolved.

[LeaVerou]

Thanks for filing this @andruud! To add context, @nest will resolve this major current issue with CSS Nesting: w3c/csswg-drafts#8738 by providing implementations a way to represent interleaved declarations and rules in the OM.

The major open issue is about the specifics of this new rule (does it serialize as a rule? Can authors write @nest {...} or is it an internal CSS OM detail?) but we have consensus that:

1. It is much easier to change the specifics of this rule than fix the CSS Nesting issue later as the current behavior becomes more entrenched.
2. Even the wrong @nest behavior (whatever that is) is better than hoisting interleaved declarations up in CSS Nesting, which is not only unexpected, but creates roadblocks for future tech like mixins.

[emilio]

I'm ok with the current @nest definition, I think it's the most straight-forward thing to do, and the best over-all.

One particularity that I mentioned on the call (or the issue?) that might have gotten overlooked is that I think there's no reason it needs to be a CSSGroupingRule tho.

If you don't write it, it will never contain anything else than declarations, correct? It seems then that @nest could be "leaf" rules?

I think CSSGroupingRule probably makes sense, to make it similar to a CSSStyleRule, but only if we're sure that's the final design (which, IMO, it should be, but @LeaVerou and @mdubet at least disagreed). If we're open to changing stuff, making it a grouping rule introduces unnecessary risks / API surface.

Wdyt @tabatkins @andruud? All in all, I think I'm supportive of this, though I think we should not try to change this later, specially if we ship it with the grouping behavior.

[tabatkins]

Yeah, it's currently a CSSGroupingRule just to be similar to CSSStyleRule, but I think it would be just fine to make it a leaf node and only contain a .style attribute.

[andruud]

I didn't realize it was specified as a CSSGroupingRule. IMO it should be:

<@nest> = @nest { <declaration-list> }

and

interface CSSNestRule : CSSRule { ... }

I don't see the point in giving it any more capabilities than that.

[LeaVerou]

@andruud @tabatkins can you please move the design discussion back into the CSS WG? Thanks.