Skip to content

[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

Closed
LeaVerou opened this issue Feb 2, 2017 · 7 comments
Closed

[css-nesting] Status? #998

LeaVerou opened this issue Feb 2, 2017 · 7 comments
Assignees

Comments

@LeaVerou
Copy link
Member

LeaVerou commented Feb 2, 2017

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

@jonathantneal
Copy link
Contributor

jonathantneal commented May 5, 2017

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

@jkrems
Copy link

jkrems commented Aug 14, 2017

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.

@tobireif
Copy link

tobireif commented Apr 13, 2018

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.

@tobireif
Copy link

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; }

@tobireif
Copy link

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

@tobireif
Copy link

Related: #2701 .

@tobireif
Copy link

tobireif commented Jul 5, 2018

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants