Relevant links on this:

https://twitter.com/LeaVerou/status/1580215877705687040, a poll about this specific matter (with links to other relevant polls which on the surface contradict this one).

https://github.com/w3c/csswg-drafts/issues/7834#issuecomment..., on this exact matter (chosen as a convenient starting point, after matters were already settled, but the whole issue is about it). By the time this poll was done, they had already decided not to consider mandatory-&, though I don’t really understand why (it’s pretty obvious to me that dividing into 3a and 3b would have been much more interesting than a couple of the other options which were straw men that no one was capable of taking seriously even if they tried).

https://github.com/w3c/csswg-drafts/issues/7961, about doing away with & in all cases for descendant selector (… which would be terrible for complexity and worst-case performance, and is only being considered because they already made things inconsistent by making & optional in every other case).

(I don’t like where it’s ended up, and consider requiring the & in all cases to be obviously materially superior, for both machine and human handling, and that there’s clear concrete advantage in having the requirement as an actual language rule rather than only a linter-enforced choice. People are far too hung up on exactly Sass syntax.)

> it would only make the parser's job easier

Mind you, it’s not a big difference; it’s just “if there’s no & in the selector, insert one and a descendant combinator at the start” in some shape, which could be as little as half a dozen lines of code net.

It's not a lot of code to implement, but it greatly simplifies usage by eliminating ambiguity:

- Easier for human readers (the "&" is an unmistakable visual indicator)

- Easier for human writers (fewer decisions; there's Only One Way To Do It)

- Easier for syntax colouring

I agree with the rest, but requiring & won’t make it easier for syntax highlighting, because that & can be anywhere in the selector, not just the start; the & affects nothing in determining whether it’s a rule or a property.

I'm saying the "&" should be required _at the start_.

Perhaps controversial, I know. I realize this eliminates use cases like

    em {
      color: green;
      li & {
        color: red;
      }
    }

It's okay not to support these use cases. They're confusing because they break encapsulation; the rule that appears to be nested inside (in this case, color: red) is affected by an element on the outside (in this case, <li>).

Compare:

    li {
      color: blue;
    }
    em {
      color: green;
      li & {
        color: red;
      }
    }

To:

    em {
      color: green;
    }
    li {
      color: blue;
      & em {
        color: red;
      }
    }

The second structure is easier to understand, and in my opinion, the syntax should bias you toward writing it that way.

This functional limitation was eliminated from consideration long ago: it’s very common to want that functionality. There were options considered for still denoting nesting, e.g. start all nested chunks with @nest, but this was decided to be inconveniently verbose. I think & is safe from being inconveniently verbose, but you can’t sanely use that without the functional limitation.

On your example: nesting is not about the sort of encapsulation you think it is—that’s incidental at best. It’s perfectly reasonable to say “this chunk of styles is about <em> elements; and when they’re inside <li>, do this”. The specific example you’ve given is also unrealistic with all three rules touching the same property in this way and two mutually exclusive (that is, li and em cannot both match, in any DOM), and I wouldn’t want it written with nesting at all, but rather like this, for much-increased clarity:

  li {
      color: blue;
  }
  em {
      color: green;
  }
  li em {
      color: red;
  }

Hmm, thanks for the food for thought. In my use of CSS, I rarely come across situations that would call for this, but I'll pay more note to the possibility they might come up.

I remember the main argument against this is that you can always enforce this with a linter and either way it's not a slower parser, maybe slightly more complex.

Personally I do agree and I like the explicitness of always having the &

Yeah that's fair and I admit don't actually know anything about the parsing implications. I guess really I'm just looking for an excuse to convince my coworkers to adopt this practice without coming off like I'm bikeshedding haha

I think you could argue for the clarity (code is read more than written) and consistency (why do I need this here and not in other places?)

> Hard to see the use-cases for sass in 2024

Possibly mixins, loops, and variables, which, unlike CSS variables, can be used in media queries.

>Possibly mixins, loops, and variables, which, unlike CSS variables, can be used in media queries.

Please god no. CSS is intended to be completely declarative. Loops and conditional logic were the very worst ideas SASS ever had.

People want freedom (as seen by the down-votes comment above seems to have gathered) and I do remember the old times when I was very excited for the creativity SASS allowed me.

Then in-between then and now, I did a lot of consulting work, and now I'm strongly feeling that the more DRY you try to make CSS, the more you end up writing, and unmaintainable CSS at that. Random example:

https://github.com/primefaces/primeflex/blob/master/_sass/li...

SASS is too powerful for its own good.

TL;DR: I wholeheartedly agree with the above comment.

yes, mixins. even just static sets of declarations would be a great start, e.g., wanting to apply the same set of base rules to both an entity and various classes without error-prone repetition (which you typically separate to have control over cascading and specificity).

css variables in media queries would be helpful too, but mixins to me is the next big step after :has() (oh so useful, come on firefox!) and this nested css syntax. unfortunately, it may be years for us to see it in browsers. there's no consensus yet on mixin syntax or where in the css lifecycle it would be implemented (there are potentially serious performance implications apparently).

> Hard to see the use-cases for sass in 2024

Modules make writing CSS much less of a naming game. Anything you can do to reduce one of the 2 hardest problems in CS is worth it.

Or build a design system with good names and take advantage of the global nature of standard CSS.

Making sure that the top-level classes of components are unique isn't difficult. Making sure the inner classes are unique (yet still follow a consistent naming convention) is only possible with a methodology like BEM, which is clunky. And you want inner classes to be unique so that you can nest components safely without having outer components accidentally styling the innards of inner components.

How, exactly? Naming aside, splitting things into separate files is often useful, and making the browser fetch multiple files for the base stylesheet is always going to be worse than packing it into a single file.

Global means more reach, local means more specifity. Design systems are global by nature. Has nothing to do with file splitting / packing.

> Web developers responded to the poll with great clarity. Option 3 won in a landslide.

Because there was no “none of the above” option, which developers asked for.