8NNTt8z3QvLT8tp

It's not pearl clutching to suggest that websites will build around quirks of a specific model and then we'll be stuck with it forever. This is an issue for future Google as much as it is for Mozilla and Apple.

We had WebSQL which defactor relied on a specific DB implementation, sqlite, and I suspect it also essentially couldn't be updated because people relied on the quirks of a specific version of sqlite.

There's something to be said for the security benefits of not having a JIT though. Especially if you've used Rust for the engine you should have pretty solid security.

https://github.com/mfreed7/xslt_polyfill/pull/5 - it will be able to do this soon.

https://github.com/mfreed7/xslt_polyfill/pull/5 - someone's made a PR that looks like it would allow Mason's polyfill to work directly from the XML file.

Someone's already added a PR to allow exactly that. You just include a script tag within your XML file.

Another big example is mutation events which are gone across the board now.

Why is it better to drop users onto the RSS page and say copy the URL in the address bar, rather than just giving a copy button that puts it on the clipboard and say put this in your RSS app?

You've completely disregarded the other examples of breaking changes that have already been made. The open web still survives afterwards. The web isn't immutable no matter how much people might want it to be.

Fwiw the meetings aren't closed, unlike w3c the whatwg doesn't require paid membership to attend.

The bug trackers are also a fine place to provide community feedback. For example there's plenty of comments providing use cases that weren't hidden. But if you read the hidden ones (especially on the issue rather than PR) there's some truly unhinged commentary that rightly resulted in being hidden and unfortunately locking of the thread.

Ultimately the way the community can influence decisions is to not be completely unhinged.

Like someone else said the other way would be to just use XSLT in the first place.

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.

Mutation Events were once in all 3 moderns engines plus some legacy ones and is now removed from everything.

Third-party cookies are now heavily restricted and while not quite removed everywhere cannot be relied upon.

document.domain is no longer settable by default in Chromium, and other browsers are aligned on matching this.

There's other APIs that have been restricted to secure contexts only.

The list goes on and on, the idea that the web is this unbreakable surface isn't true. It does break things and that is a good thing, if you want the platform to succeed for decades to come they should be able to fix mistakes.