3 ms·
> HTML elements currently require the & symbol in front or being wrapped with :is(). They were so close to capturing how good LESS is, why did they do this?
by jimmaswell 3y ago
> HTML elements currently require the & symbol in front or being wrapped with :is().
They were so close to capturing how good LESS is, why did they do this?
- samwillis 3y agoIt's to do with how the parsers are implemented in browsers I believe. I think I read that it would require a large rewrite of them all and potentially make them slower. Personally I think it good that it makes it more explicit, even for none element nested selectors I'm adding the & to make it clear. So for a class "& .something". Edit: Found it in the spec > Nesting style rules naively inside of other style rules is, unfortunately, ambiguous—the syntax of a selector overlaps with the syntax of a declaration, so an implementation requires unbounded lookahead to tell whether a given bit of text is a declaration or the start of a style rule. > ... that is, the parser might have to hold onto an unknown amount of content before it can tell which way it’s supposed to be interpreting it. CSS to date requires only a small, known amount of lookahead in its parsing, which allows for more efficient parsing algorithms, so unbounded lookahead is generally considered unacceptable among browser implementations of CSS. End of this section: https://www.w3.org/TR/css-nesting-1/#nesting https://www.w3.org/TR/css-nesting-1/#nesting
- foolip 3y agoThe CSS Working Group has resolved to relax the syntax in https://github.com/w3c/csswg-drafts/issues/7961 https://github.com/w3c/csswg-drafts/issues/7961 so what you desire is coming :)
- jimmaswell 3y agoThat'll be great. One wart I'm tired of dealing with in LESS is having to escape every use of calc() or else the preprocessor tries to do it itself.