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.
As the spec is currently defined, that selector wouldn't be valid. There's some discussion about why in the original thread: https://github.com/w3c/csswg-drafts/issues/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.
https://github.com/w3c/csswg-drafts/issues/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.
I've updated the issue. I'm sad that this isn't making it's way into native CSS. 馃槩
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
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.
Most helpful comment
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.