Description
(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?