[csswg-drafts] [css-nesting] Status?

LeaVerou has just created a new issue for 
https://github.com/w3c/csswg-drafts:

== [css-nesting] Status? ==
(apologies if this was discussed in the Seattle F2F, haven't caught up
 with the Minutes yet!) 

According to 
[this](https://twitter.com/LeaVerou/status/806936438797307904), 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](https://tabatkins.github.io/specs/css-nesting/) a while ago
 but it seems to not have collected significant WG interest.

Delegating nesting to preprocessors produces long, repetitive, slow 
chains of selectors in CSS with ridiculous specificity. These days 
authors are even resulting in patterns like [BEM](http://getbem.com/) 
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).

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.

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?

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/998 using your GitHub 
account

Received on Thursday, 2 February 2017 03:21:56 UTC