> "I think it's important to realize that removing cruft is virtually impossible."
With a browser from 1995 probably 95% of the popular websites are not usable. Truth is that backwards compatibility mostly reaches only a couple of revisions into the past as itβs the case with the web standards. And given how easy it is nowerdays to update a system, I wonder why it is not considered to make a clean cut and introduce a modern standard. The standards will simply co-exist for a couple of years until the new standard reaches a critical usage share.
The issue isn't whether old browsers can display new content, it's whether new browsers can display old content (or even old content mixed into new content).
If a new standard were to replace the old one, it would mean losing access to use swathes of the internet. Just look at how hard comparatively trivial upgrades of IPv6 or HTTP v2 are - and there you merely need to deal with ultimately replaceable machines - upgrading content formats just isn't easy.
Sure, as a webdev it's nice to focus on the shiny new stuff, but I'm under no illusions that the old stuff is going away any time soon.
Sure. That's basically the extend, not replace strategy. Then you can choose various ways to extend.
* You could pick a completely different approach, and define interop points. This tends to have a steep learning curve. E.g. python interops with C very well, yet most people nevertheless avoid interop.
* You could define the old system in terms of the new system or vice versa. That way, you eventually have clear path to use only one system completely. However, it also means you need to at least support all the various crufty bits you may not otherwise care about. It's also not easy to learn.
* You could just extend the old system. You don't get to clean things up by hiding them behind interop or a layer of translation, but at least the learning curve isn't so bad - you only touch what you want.
That last bit is the basically the strategy that wins. Adding a new system is just such a pain unless it entire replaces the old system (which is almost impossible in practice if only for reasons of momentum), that it's really hard to go half way. Also, don't forget that "mere" interop is far from trivial since it's not just CSS, but also javascript's interaction with DOM+CSS that you'd need to emulate/interop with.
So that leaves us with things like flexbox: new techniques, but integrated into what we have rather than side-by-side with complex interop.
With a browser from 1995 probably 95% of the popular websites are not usable. Truth is that backwards compatibility mostly reaches only a couple of revisions into the past as itβs the case with the web standards. And given how easy it is nowerdays to update a system, I wonder why it is not considered to make a clean cut and introduce a modern standard. The standards will simply co-exist for a couple of years until the new standard reaches a critical usage share.