I know this is a silly question and probably argued already over the years.

But can't and shouldn't this be solved by some mechanism? Like, some umbrella "native-web-1" meaning that any project without that tag renders 2020 and below whilst anything with it as a brand new shiny implementation.

It would also help prevent the relentless "wow I really like that 2024 feature, lets make a shit version now today and another 7 over the years so that everyone is stuck with a dependency which doesn't even follow the specification" (promises etc)

Although a nice idea in principle I think you'll just end up with horribly convoluted and hacky if/else logic throughout your code - much like the era of nasty IE6 kludges.

That's a good question. That <!DOCTYPE> things is that such mechanism, isn't it? (Or it was supposed to be.)

Perhaps the problem is that shipping, for example, two different Javascript engines would be too bad for browsers?

I want to know.

The WHATWG's philosophy for the HTML standard is never to sway too far from what browsers currently do, mainly to make sure that the browsers can keep up: https://whatwg.org/faq?#living-standard

The browsers seem to like that, so it's probably unlikely that we'll get a wildly different HTML6 anytime soon, if ever.

Yeah exactly. I can't even really find what I am trying to say, but Doctypes had some other piece of data with it. Was it a link or string to a spec? Like XHTML vs HTML4. Randomly I am sure that if you omit it, then it is "html5".which is random, shouldn't they have forced a spec HTML5?

That choice basically says to me that the idea of partitioning, or whatever those doctypes were for, is now abandoned.

I don't understand all this need for backward compatibility. Most of the web is rotting anyway. When can we just wrap it up, say ad acta, name it "web 1.0" (congratulate everyone) and put it away? Lessons learned. No more updates to browsers, html, css or js, not even bug fixes. Just document everything and live with it for existing sites. And then we can work on a tabula rasa, clean new technologies, this time with some thought put into it. This probably means not letting MS or Brendan anywhere near.

> And then we can work on a tabula rasa, clean new technologies, this time with some thought put into it.

I'm sorry - that just seems a bit...naive.

If "we" did as you are saying, twenty years would pass and we'd be having this same conversation again.

History is rife with examples of trying to fix things by wholesale rebooting, and people thinking "this time it will be perfect!"

...except it never is.

I think engineers of all stripes understand this; we've never seen this (yet...) in industries like aerospace or automobiles, or other kinds of hands-on engineering. For one, if it were done, people would probably die. But mainly, I think, because engineers know that throwing the baby out with the bathwater is a bad idea in general; that the institutional knowledge built into the outputs and practices are worth having in place and examining - both to learn what works right, as well as what doesn't.

Your suggestion is akin to a "not invented here" mindset, where rather than using existing frameworks and/or libraries, a developer instead opts to "go at it alone", to prove their implementation is better. Sometimes it is; sometimes it does advance things in a good way. But those tend to be outliers; "your implementation" likely won't be that case.

Also, to be honest, many of those "game changing" libraries and such are "built on top of" earlier stuff and package it better (with cleanup and tweaks added too). This isn't to denigrate either; in fact it's part of the process (and also show's why "first mover advantage" can sometimes be a fallacy as well).

Sounds like Plan 9 after Unix was soiled by all and sundry.