Variables (since they are not just constants), flex and grid all allow doing things that were previously not possible or at least not reasonably. Nesting is a pure syntax change that is already solved via a preprocessing step. So yes, we should weight what this adds in convenience vs. the cost of the adding this to all browsers, maintaining support for it forwever, the impact it has on future additions as well as new websites using this not working on older browsers. Note the should - I'm perfectly aware that the web dev ecosystem already often ignores many of these.

We kind of had variables with preprocessing before. Or a simple sed ‘s/str/replace’.

But true support is convenient. One of the best places to write CSS is the browser’s dev tools. Having CSS variables work there is awesome.

If it can be parsed almost as fast, I say go for it.

Those are constants. CSS variables are more powerful than that since they can be changed at runtime which allows e.g. minesweeper in pure HTML and CSS: https://github.com/propjockey/css-sweeper

Scoping and nesting are two things that would solve 99% of problems when it comes to organising CSS (and components). They should definitely be on the browser level and not "solved by preprocessors".

I disagree. Given the enormous complexity browsers have aggregated already, we should strive to make browsers "player apps" (like MP3 players): a relatively simple front end with huge versatility in server apps and back ends, rather than, like, everything for everybody. I'm aware that ship has sailed a long time ago, but piling ever more not-so-well-motivated stuff onto browsers just means the next generation has to start over with a clean slate; actually I think this is inevitable already.

CSS nesting is clearly serving the use case of components in web apps, as opposed to mere content-driven web sites. IMO a sensible approach would be to give web app developers powerful ways to tie into rendering and layout programmatically (a la Houdini API) when those apps will require JavaScript, and in many cases use CSS-in-JS anyway, rather than burden browser cores with ever more questionable CSS features.

"Would solve 99% of use cases" also sounds like famous last words ;)

> a relatively simple front end with huge versatility in server apps and back ends

Define "relatively simple"?

Nesting and scoping in CSS don't make frontend any more complex. CSS has had problems with it's flat top-level structure since the very beginning of its existence. Approaches like BEM didn't appear out of thin air.

> CSS nesting is clearly serving the use case of components in web apps, as opposed to mere content-driven web sites.

Even a content-driven web site has a plethora of repeating and/or complex elements that are a pain to define and maintain.

> Would solve 99% of use cases" also sounds like famous last words

Google has poured hundreds of millions of dollars into web components whose primary use case (that is, what they are being used for in reality) could've been solved by scoping and nesting.

Same goes for all the CSS-in-JS abominations.

AFAIK, this is just syntactic sugar. A shortcut.

It’s not scoping in the inheritance sense. The C in CSS is for cascading. Inheriting is the natural way to be for CSS

Casacading !== inheritance. These are very different things. I wish we had inheritance (or traits) in CSS.

Well tell me the difference then. We have cascading inheritance, that’s what CSS is all about.

Unless we’re using different definitions of the term

Casacading alpplies to all elements in the cascade. Whether you want it or not.

At the same time it's impossible to say "hey, I want to inherit from that particular style", and not have the cascade apply to it. For example, I want a button and I don't want anything in the hierarchy above overriding its borders, or colors, or fonts, or...

Oh, I see. Arbitrary non hierarchical opt-in inheritance. Or perhaps a cascading inheritance opt-out, and you could add classes back as you please. That would be cool.

Not sure how it would impact browser parsing and drawing, but it sure would be useful.