Hacker News Reader

Comment by shiomiru | Hacker News Reader

> Things can remain backwards compatible forever.

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.

Indeed, to me it seems that at some point, you either have to

a) freeze the standard

b) drop old stuff

c) accept that there is no standard

and with the web as a whole, we are firmly headed towards option c). So I find the short-sightedness of all people pushing back against this proposal unfortunate.

(Also note that dropping a barely-used Turing-complete language from the web is not comparable to removing deprecated HTML elements. The latter typically requires just a few lines of CSS in the UA style sheet, so I doubt anybody is considering doing that.)

View on HN

As if oligopolization of the browser space wasn't a deliberate objective of the WHATWG.

I would rather have them deprecate the HTML syntax, which is a nightmare to parse, nightmare to escape for ( https://sirre.al/2025/08/06/safe-json-in-script-tags-how-not... ), and nightmare to securely transform (CVE-2020-26870). Now that MSIE is dead, all mainstream browsers support XHTML just fine; compared to HTML, XML is much, much simpler to make a new implementation of; and few people generate markup by printf any more.

> As if oligopolization of the browser space wasn't a deliberate objective of the WHATWG.

So why is it that when once in a blue moon the WHATWG tries to do something that also happens to help new implementations, web devs come in to cry bloody murder? Maybe there are co-conspirators to the scheme? :)

> 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.

Reply on news.ycombinator.com