4 ms·

There are so many nice new things in CSS, along with :has() and :nth-last-child there is also :is(), :not() and the new nested syntax. All make working with raw

There are so many nice new things in CSS, along with :has() and :nth-last-child there is also :is(), :not() and the new nested syntax. All make working with raw css much more pleasant. No more SASS/LESS, and (hopefully) soon no more PostCSS hopefully! :is() - https://developer.mozilla.org/en-US/docs/Web/CSS/:is https://developer.mozilla.org/en-US/docs/Web/CSS/:is :not() - https://developer.mozilla.org/en-US/docs/Web/CSS/:not https://developer.mozilla.org/en-US/docs/Web/CSS/:not CSS nesting - https://developer.chrome.com/articles/css-nesting/ https://developer.chrome.com/articles/css-nesting/ Interestingly nested css is implemented as a syntactic sugar over :is() in order to achieve the correct specificity.

ozzmotik 3y ago
x
paavohtl 3y ago
Little nitpick, but :not() is not a new feature by most definitions of new. It has been in browsers for over a decade (closer to 15 in browsers not related to IE), which is an eternity in the world of web technology.
- samwillis 3y ago
  Correct, although :not() had a massive upgrade only a couple of years ago with complex selectors support. Prior to the change you could only pass a "simple selector" that only matched against the one node, such as :not(.something). However you can now do :not(ul > li p.something)
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 ago
  It'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 ago
  The 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 ago
    That'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.
hanniabu 3y ago
I've gone vanilla css since variables were added
Waterluvian 3y ago
Agreed. This really feels like an ES6 moment for CSS.
porker 3y ago
> No more SASS/LESS, and (hopefully) soon no more PostCSS hopefully! I keep running my CSS through SASS just so I can use single line comments. If they'd add those to CSS natively... Can't wait to drop PostCSS as I've had its plugins, extensions, whatever they're called break my stack (through subtle bug or breaking changes) more often than Webpack plugins, and that's saying something.

ozzmotik 3y ago

paavohtl 3y ago

Little nitpick, but :not() is not a new feature by most definitions of new. It has been in browsers for over a decade (closer to 15 in browsers not related to IE), which is an eternity in the world of web technology.

samwillis 3y ago
Correct, although :not() had a massive upgrade only a couple of years ago with complex selectors support. Prior to the change you could only pass a "simple selector" that only matched against the one node, such as :not(.something). However you can now do :not(ul > li p.something)

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 ago
It'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 ago
The 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 ago
  That'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.

hanniabu 3y ago

I've gone vanilla css since variables were added

Waterluvian 3y ago

Agreed. This really feels like an ES6 moment for CSS.

porker 3y ago

> No more SASS/LESS, and (hopefully) soon no more PostCSS hopefully! I keep running my CSS through SASS just so I can use single line comments. If they'd add those to CSS natively... Can't wait to drop PostCSS as I've had its plugins, extensions, whatever they're called break my stack (through subtle bug or breaking changes) more often than Webpack plugins, and that's saying something.