Comment by jmull | Hacker News Reader

Comment by jmull | Hacker News Reader

Breaking the fundamental promise of the HTML spec is a big deal.

The discussions don't address that. That surprises me, because these seem to be the people in charge of the spec.

The promise is, "This is HTML. Count on it."

Now it would be just, "This is HTML for now. Don't count on it staying that way, though."

Not saying it should never be done, but it's a big deal.

They are removing XSLT just for being a long-tail technology. The same argument would apply to other long-tail web technologies.

So what they're really proposing is to cut off the web's long tail.

(Just want to note: The list of long-tail web technologies will continue to grow over time... we can expect it to grow roughly in proportion to the rate at which web technologies were added around 20 years in the past. Meaning we can expect an explosion of long-tail web technologies soon enough. We might want to think carefully about whether the people currently running the web value the web's long tail the way we would like.)

WHATWG broke this quasi-officially when they declared HTML a "Living Standard". The HTML spec is not a standard to be implemented anymore, it's just a method of coordinating/announcing what the browser vendors are currently working on.

(For the same reason, they dropped the name HTML5 and are only talking about "HTML". Who needs version numbers if there is no future and no past anyway?)

https://whatwg.org/faq#living-standard https://github.com/whatwg/html/blob/main/FAQ.md#html-standar...

Your FAQ stresses the importance of backwards compatibility multiple times.

Seems hard to square removing XSLT with that.

Yeah, that was my impression about their process. They replaced formalized compatibility guarantees through versions with "trust me, bro".

Nothing lasts forever, and eventually you have to port, emulate, archive or otherwise deal with very old applications / media. You see this all over the place: physical media, file formats, protocols, retro gaming, etc.

There's a sweet spot between giving people enough time and tools to make a transition while also avoiding having your platform implode into a black hole of accumulated complexity. Neither end of the spectrum is healthy.

I can still run windows applications that are decades old. If you don't want to support legacy stuff, don't insinuate yourself into global standards.

If this was just Android that would be an issue between Google and their developers/users, but this is everybody.

To be completely fair, looking over the lines removed by the PR, there don't appear to be any normative statements requiring HTML handling XSLT unless I missed one.

I get that people are more reacting to the prospect of browsers removing existing support, but I was pretty surprised by how short the PR was. I assumed it was more intertwined.

Their explicit intent is to generally remove XSLT from browsers.

If this was just about, e.g., organizing web standards docs for better separation of concerns, I think a lot of people would be reacting to it quite differently.

There's a perverse irony that Google is as responsible as anybody for cramming a crazy amount of new stuff into the HTML/CSS/browser spec that everybody else has to support forever.

If they were one of the voices for "the browser should be lightweight and let JS libs handle the weird stuff" I would respect this action, but Google is very very not that.

> They are removing XSLT just for being a long-tail technology. The same argument would apply to other long-tail web technologies.

That's a concise way to put it. IMHO this is also the main problem of the standard.

However I think XSLT isn't only long tail but also a curiosity with just academic value. I've being doing some experimentation and prototyping with XSLT while it was still considered alive. So even if you see some value in it, the problems are endless:

* XSLT is cumbersome to write and read

* XML is clunky, XSLT even more so

* yes there's SLAX, which is okay-ish but it becomes clear very fast that it's indeed just Syntax sugar

* there's XSLT 2.0 but there's no software support

* nobody uses it, there's no network effect in usage

I think a few years ago I stumbled upon a CMS that uses it and once I accidentally stumbled upon a Website that uses XSLT transformation for styling. That's all XSLT I ever saw in the wild being actually used.

All in all XSLT is a useless part of the way to large long tail preventing virtually everyone from writing spec compliant web browser engines.

> The promise is, "This is HTML. Count on it."

I think after HTML4 and XHTML people saw that a fully rigid standard isn't viable, so they made HTML5 a living standard with a plethora of working groups. Therefore the times where this was ever supposed to be true are long over anyway.

So indeed the correct way forward would be to remove more parts of a long tail that's hardly in use and stopping innovation. And instead maybe keeping a short list of features that allow writing modern websites.

(Also nobody is stopping anyone from using XSLT as primary language that compiles to HTML5/ES5/CSS)

Reply on news.ycombinator.com