-
Notifications
You must be signed in to change notification settings - Fork 710
[css-nesting] Status? #998
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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:
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:
is equivalent to this:
|
Is hope this will get specd (instead of telling people to use Houdini 😀). It's a handy feature, thoroughly prototyped in Sass. |
Related: #2701 . |
From #2701
Perhaps this ticket here can be closed? |
(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:@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?
The text was updated successfully, but these errors were encountered: