Comment by account42
8 days ago
> This is exactly the attitude that has left us with only three complete extant implementations of the web, two of which are controlled by an ad company.
No, adding complex new interfaces and then demanding that every browser implement them quickly is what does that. Google is not proposing to reign in that behavior.
> a) freeze the standard
Yes, or rather new features should become rarer over time.
> and with the web as a whole, we are firmly headed towards option c)
Which has nothing to do with backwards compatibility but with Chromes appetite for adding new APIs, presumably with exactly this outcome being their goal.
> No, adding complex new interfaces and then demanding that every browser implement them quickly is what does that.
New interfaces forced into the spec without concern for complexity have led to the demise of existing browser engines.
But the lack of new implementations is also a result of the insistence on keeping all obsolete interfaces, no matter how complex or how little their remaining usefulness, at all cost. (Looking at you, document.write...)
> > a) freeze the standard
> Yes, or rather new features should become rarer over time.
This is far more unrealistic than dropping XSLT support.
Thing is the new APIs added to the web are generally quite well specified with quite good tests. These older legacy APIs sometimes don't even have a standard and almost definitely don't have interoperability (XSLT is an example of one that definitely does not work consistently between WebKit/Blink and Firefox).
For a new browser engine adding some of the new APIs is pretty trivial compared to debugging all the nonsense that comes from these kinds of underspecified legacy APIs. Removing XSLT from the spec and existing browsers means new ones don't feel the need to implement it. They don't need to decide which implementation to go with (use libxslt like chromium and webkit and you might match their behaviour but you also get all the same security vulns).
Frankly a modern engine could probably get by without handling XML entirely (aka no XHTML document support) and get by just fine but that's a separate discussion.