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

Happy to see this moving forward into deeper discussion!

But as I review @tabatkins draft, here are some issues that jump out to me:

1. Based on the recent decision to change how `:matches()` specificity works (#1027), 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}` (which could for some values of `a` and `b` result in different specificity than how it works with pre-processors).  Then, all examples would need to be updated to consistently use one expansion or the other.

2. It's worth calling out that Tab's proposed `&` is less powerful than the SCSS `&`.  I understand [the parsing reasons](https://tabatkins.github.io/specs/css-nesting/#nesting) for the limitations, but it means you won't be able to blindly convert all SCSS nesting code to plain nested CSS.

  Some examples of SCSS features which wouldn't be supported in the proposal (P.S. [Useful reference to SCSS nesting, for comparison](https://css-tricks.com/the-sass-ampersand/)):

  * Omitting the `&` for parent-child relationships.

  * Allowing the `&` anywhere in the selector, like:

        :link { .container & {/* link styles inside that container */} }

    In Tab's proposal, you could create this functionality with an explicit `@nest` rule: 

        :link { @nest .container & {/* link styles inside that container */} }

  * Extending a single selector token, for example to create BEM-style modified classes like:

        .block { &__elem { &--modifier { /*styles*/ } } }

    which in SCSS compiles to a single class:

        .block__elem--modifier { /* styles */ }

    I don't think this would be supported at all in Tab's proposal, since it requires merging tokens after parsing.

3. [This](https://tabatkins.github.io/specs/css-nesting/#mixing) looks like something that could be an implementation issue and/or a source of authoring issues:

  > The relative ordering of nested style rules and other declarations is important; it’s possible for a given style rule and a nested style rule within it to match the same element, and if the specificity of the two rules is otherwise equivalent, the relative order in the stylesheet of the applicable declarations determines which declaration "wins" the cascade.

  CSS in many places requires a very clear ordering of individual rules. For example, you can't `@import` one stylesheet halfway through another one, because _all_ the rules in one need to be before or after _all_ the rules in.  This would create half of a style rule having lower precedence than another rule, and half of it having higher precedence.

  It also would create another situation where the result with preprocessors (which must always turn nested rules into sibling rules) would be different from the result with the new syntax.

  An intentionally trivial example, to be sure that the two selectors have equal specificity:

  ```scss
  body { 
    color: indigo;
    * & { 
      color: cyan;
      background-color: red; 
    }
    background-color: blue;  
  }
  ```

  In SCSS, the nested rule compiles to come after the outer rule, and the page is cyan text on red. In Tab's proposal it would be cyan text on blue.


Points 1 and 3 of that list can probably be discussed as proper issues as soon as [css-nesting] is converted to a proper draft spec. Point 2 is more of a head's-up for anyone getting excited about Sass nesting coming to CSS.







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

Received on Thursday, 7 June 2018 01:02:45 UTC