Re: [csswg-drafts] [css-nesting] request to pick up the css-nesting proposal

> we would need to decide whether a, b { & c {prop:val}} expands as a c, b c {prop: val} or as :matches(a,b) c {prop: val}

The draft currently specifies it as the latter, and I find it very unlikely that we'd change off from that.  Changing would require either actually expanding under the hood (with the attendant multiplicative blowup), or implementing the careful actually-matched-path logic that we explicitly rejected forcing implementors to use for `:matches()`.

> It's worth calling out that Tab's proposed & is less powerful than the SCSS &. 

Agreed, I can add a section to the intro about this.

> Omitting the & for parent-child relationships.

Intentional, as I don't want to privilege the descendant combinator, and I personally think it's less clear what's going on.

> Extending a single selector token, for example to create BEM-style modified classes

Yeah, very intentionally not allowed. It causes parsing issues, for one (you can't arbitrarily split up an ident and be guaranteed that both halves are still idents), and it's grammatically ambiguous with tagname selectors.

> [Relative ordering of declarations and nested rules in a single style rule] looks like something that could be an implementation issue and/or a source of authoring issues:

Yeah, I think I need to change that to sort the declarations to the front. Otherwise I have to reflect the relative ordering of declarations and rules in the OM, which'll be nasty and not compatible with my current plans of just adding a `.childRules` property to `CSSStyleRule`.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2701#issuecomment-395504004 using your GitHub account

Received on Thursday, 7 June 2018 17:36:36 UTC