Csswg-drafts: [css-nesting] Status?

Created on 2 Feb 2017  ·  7Comments  ·  Source: w3c/csswg-drafts

(apologies if this was discussed in the Seattle F2F, haven't caught up with the Minutes yet!)

According to this, out of a sample size of 1838 authors, 32% cite nesting as their Number 1 reason for still using a preprocessor, same percentage as variables.

Perhaps it's time to revisit nesting? Tab drafted a proposal a while ago but it seems to not have collected significant WG interest.

Delegating nesting to preprocessors produces CSS with long, repetitive, slow chains of selectors and ridiculous specificity. These days, authors are even resorting to patterns like BEM which abolish descendant and child selectors altogether and put the descendant information in the class attribute (like <li class="header--navigation_item"> on every single item). Such patterns cannot possibly be the solution we support: they are only maintainable with tools and templating systems that generate the markup and they do not reduce the duplication in the CSS at all, they just put it in a different selector type.

Nesting in CSS would free authors from preprocessors, it could allow performance optimizations in browsers (any implementors want to weigh in on this?) and we might be able to do something more reasonable for specificity. Furthermore, nesting makes CSS code easier to read compared to descendant selectors.

A while ago, @tabatkins told me that he's not working on the proposal because this can be done with a Houdini @rule anyway. I don't know if he still stands by that, but this would be a rather suboptimal solution:

  • We already know that authors use nesting. Just look in any Sass stylesheet. There's no point of a trial period with Houdini, like features whose utility we're unsure about.
  • Doing this with an @rule is a verbose solution, for a feature whose entire point is to eliminate verbosity! Verbosity is not only slower to type (autocomplete helps there), but also delays code comprehension, and code might be written once but is read many times. Requiring an & before each selector might be more verbose than preprocessors, but still acceptable.

So, what's the status on this spec? If there are no blockers, could we move it to drafts.csswg.org? If there is consensus that it should move forward, I could do it. Tab, are you still interested in working on it?

unknowfuture spec

Most helpful comment

Does nesting have “_champion_”? Has it been formally presented to the csswg? Any updates here?

All 7 comments

Does nesting have “_champion_”? Has it been formally presented to the csswg? Any updates here?

Just discovered while investigating some internal developer questions. There's definitely some confusion on this issue (not necessarily caused by the CSS WG itself). E.g. nesting is currently being advertised as a "tomorrow's CSS feature" - http://cssnext.io/. I'd love to see it in the CSS spec itself since moving away from "everyone's using their own semi-standard language" definitely seemed to be healthy for the JS ecosystem.

In a recent project

https://tobireif.com/demos/grid/

I had to write ".layout1" many times:

/* 2 lines containing ".layout1": */
.layout1 .page {
  grid-template-rows: repeat(3, auto) 1fr;
  grid-template-columns: 1.14fr 1fr;
}
.layout1 .page .heading {
  grid-row: 2;
  grid-column: 1;
}
/* 33 more lines containing ".layout1" */

Having something like Sass's Nesting

https://sass-lang.com/guide#topic-3

would allow me to write the string ".layout1" only once (ditto for the string ".layout2" and ".layout3").

Regarding https://tabatkins.github.io/specs/css-nesting/ :

I think I'd prefer a syntax like that of Sass

https://sass-lang.com/guide#topic-3

where it's not necessary to add the ampersand.

In Sass, the ampersand is available (but not required - that's what I want).

https://sass-lang.com/documentation/file.SASS_REFERENCE.html#parent-selector

One of their examples:
(plus my comments)

#main {
  color: black;
  /* ampersand not required: */
  a {
    font-weight: bold;
    /* ampersand can be used when necessary: */
    &:hover { color: red; }
  }
}

is equivalent to this:
(the second part of their example) (their formatting)

#main {
  color: black; }
  #main a {
    font-weight: bold; }
    #main a:hover {
      color: red; }

Is hope this will get specd (instead of telling people to use Houdini 😀). It's a handy feature, thoroughly prototyped in Sass.

From #2701

The Working Group just discussed css nesting, and agreed to the following:

RESOLVED: add css-nesting as an ED, Tab Atkins as editor, file issues until ppl are overall kinda happy with what it's like before we consider FPWD

Perhaps this ticket here can be closed?

Was this page helpful?
0 / 5 - 0 ratings