CSS3 and HTML5 are not meaningful semantic version numbers anymore and haven’t been for over a decade.

Both CSS and HTML are considered “living standards” now and no longer use version numbers: https://html.spec.whatwg.org/multipage/introduction.html#is-...?

Nesting in CSS became broadly supported in Chromium and other evergreen browsers a few months ago. This is a feature that developers have had to use inside of some kind of tool that compiles down to “regular” CSS since 2006. That’s 17 years. 17 YEARS.

And there was no major announcement when it became supported, just a blog post: https://developer.chrome.com/articles/css-nesting/

Even now, it’s not supported by older versions of iOS/mobile Safari which could easily be 15-20% of a large US based websites’ traffic.

> Nesting in CSS became broadly supported in Chromium and other evergreen browsers a few months ago.

Firefox hasn’t shipped it yet. https://caniuse.com/css-nesting shows it landing in 117 next month.

> Even now, it’s not supported by older versions of iOS/mobile Safari which could easily be 15-20% of a large US based websites’ traffic.

Yeah, actual global support is probably still below ⅔—caniuse.com is showing global support at 72.89%, and its methodology is hopelessly broken for mobile browsers (treats all mobile Chrome/Android WebView as the latest version, which is wildly wrong), quite apart from excluding browsers that block the StatCounter script, leading to particularly heavy undercounting of Firefox and general undercounting of more conservative or unusual configurations; so the true numbers on newish features are always much worse than it suggests.

For these sorts of features, if all browsers ship around the same time, you’ll normally want to wait for about another two years before you start depending on it. (When shipped out of sync, it depends—you’ll encounter two-year-old Safari more commonly than six-month-old desktop Chrome, for example.)

Thanks, that analysis was worth adding. You're saying 2 years, I've heard other people say they would maybe consider relying on this in 5. It's really dependent on the software you work on.

So an estimate of around 20 years from the time people started using things like variables and nesting to improve writing CSS to being able to actually write real CSS using those features and actually being able to count on broad browser support.

Then I think about things like JavaScript modules, and how completely fucked up that entire ecosystem is for so many reasons.

And then condescending comments in the parent like "I think they just don't understand what can be done with just HTML/CSS these days, they're so used to complexity" - people who have clearly never worked in front-end development as their day job. It's insulting and reductive.

I am glad that this stuff made it into the spec, and I know that over the next 5 years, things like native CSS variables and nesting will become more common until Sass/PostCSS is scarce, but they will probably still be being used inside of abstractions like SPA frameworks. And all of the JavaScript will unfortunately probably be written in TypeScript.

To me, the holy grail end game of front-end development is the elimination of a build step. And for that to happen before I hit retirement we have to find some way of decreasing the lead time of innovation -> spec implementation -> browser support from 20 years to < 5 years. Obviously, browsers becoming evergreen and Internet Explorer finally dying will help. Already, simpler tooling is becoming more prominent than the dark days of Webpack. But there's still a long, long way to go. This is all assuming Google doesn't finally figure out a way to destroy the open web all together before this happens.

i've played with nesting on firefox and, much like the :has() selector, it seems good enough for the 80% case, so i wish they'd unflag it so we could get the clock started on having it be commonplace in a year or two to use it confidently.

That would require accepting that the complexity merchants sold them a lie.

> complexity merchants

I have never heard of this term before. But I do think it is quite apt. Is this an established concept (can I read more about it somewhere)? Or did you come up with it on the fly?

Someone else coined the term and there was a HN post. I cannot find it though.

Part of the slow adoption of ultra modern HTML tags might be that the divorce from Internet Explorer 6 to 10 finished so recently that no one has bothered to update their knowledge yet. In my corporate environment, IE 11 was removed only last year.

But with just a little JS you can have a full SPA. You don't need a virtual dom to manage some HTML tags. You don't need UI libraries to render a UI. You don't need complex state management hook flow whatevs to manage some state. You don't need routing frameworks to read and write the URL. And so on.

With just HTML and CSS you can get a very long way. And if that last mile is truly a requirement, DOM APIs and a few lines of JS (or TS) have it covered. Only when all that grows wieldy do you need npm, frameworks and complex trees of dependencies.

But it does seem that no one enjoys actually building MPAs and that force is currently winning right now.

Using your favorite language, a simple http listerner+routing and what ever HTML templating engines are supported, MPAs are simple and enjoyable to build.

I think product people enjoyed pretending they were facebook for a while and decided the world needed more infinitely scrolling SPAs and forced a lot of people into having to use react and other frontend heavy frameworks to try to wrangle all the (often times brittle) javascript involved to juggle client state. I don't think we're better off as users or developers because of this.

It's rather easy to add infinite scrolling to an MPA too, though. A few lines of JS is all you need.

I'd argue this is simpler and easier than investing in a full blown ui library and state manager or painting yourself into some corner of today's JS framework.