[css-nesting] add note explaining that BEM `&__element` class accumulation isn't supported and why

[Dan503]

CSS nesting spec
https://drafts.csswg.org/css-nesting-1/

There is a very common method of writing BEM classes among FE developers that looks like this when writing in SCSS:

.block {
  &__element {
    // .block__element { ... }
  }
}

The spec currently doesn't seem to explicitly allow for this style of nesting. Providing an example to mention this method is ok is all that would be needed.

Update:

Apparently that syntax isn't actually allowed. 😢

The spec doesn't clearly explain if the syntax is valid or not though.

Please add a clear example stating that this isn't valid and explain why.

[AmeliaBR]

As the spec is currently defined, that selector wouldn't be valid. There's some discussion about why in the original thread: #2701

If you'd like to make this issue a feature request for extending class names in nested selectors, please edit your issue post accordingly.

Otherwise, I guess your issue request should be interpreted as "please add a note clarifying that this isn't possible and why".

Edited to correct the link.
#2937 is also relevant, but for a different reason: it recommends using a syntax without & to avoid conflicts when converting Sass/Less code that does use the BEM-style &__modifier {} selectors.

[Dan503]

I've updated the issue. I'm sad that this isn't making it's way into native CSS. 😢

[jonjohnjohnson]

I think your example selector might actually be valid, but attempting to match an invalid element with type __element. Equivalent to __element.block. 😆

The nesting selector is allowed anywhere in a compound selector, even before a type selector, violating the normal restrictions on ordering within a compound selector. [...] An ampersand is unambiguously separable from an ident, tho, so there is no problem with it preceding a type selector, like &div. - https://drafts.csswg.org/css-nesting-1/#nest-selector

[tabatkins]

Yup, definitely valid, just not what's intended. __element is a perfectly reasonable tagname selector.

I'm happy to add a note that BEM-style accumulation of a classname is explicitly not supported in this proposal, tho.