Live data from Hacker News

"Remove mentions of XSLT from the html spec"

github.com

201–210 of 559 posts

Re: "Remove mentions of XSLT from the html spec"

#201

So if in reading the two threads correctly essentially Google asked for feedback, essentially all the feedback said "no, please don't". And they said "thanks for the feedback, we're gonna do it any way!"? The other suggestions ignored seemed to be "if this is about security, then fund the OSS, project. Or swap to a newer safer library, or pull it into the JS sandbox and ensure support is maintained." Which were all m…

It comes with the XML territory that things have versioned schemas and things like namespaces, and can be programmed in XSLT. This typically means that integrations are trivial due to public, reliable contracts.

Unlike your average Angular project. Building on top of minified Typescript is rather unreasonable and integrating with JSON means you have a less than reliable data transfer protocol without schema, so validation is a crude trial and error process.

There's no elegance in raw XML et consortes, but the maturity of this family means there are also very mature tools so in practice you don't have to look at XML or XSD as text, you can just unmarshal it into your programming language of choice (that is, if you choose a suitable one) and look at it as you would some other data structure.

Re: "Remove mentions of XSLT from the html spec"

#202
post #148

How do we feel about this concern in general? Not just specific to XSLTs > my main concern is for the “long tail” of the web—there's lots of vital information only available on random university/personal websites last updated before 2005 It's a strong argument for me because I run a lot of old webpages that continue to 'just work', as well as regularly getting value out of other people's old pages. HTML and JS have a…

It seems like they've already created a browser extension that'll act as as polyfill [0]. Chrome just don't want to ship it & maintain it. Which is very similar to Ruffle.

[0]: https://chromewebstore.google.com/detail/xslt-polyfill/hlahh...

Re: "Remove mentions of XSLT from the html spec"

#203

This is actually not a bad idea. Why should the browser contain a specific template engine, like XSLT, and not Jinja for example? Also it can be reimplemented using JS or WASM. The browsers today are too bloated and it is difficult to create a new browser engine. I wish there were simpler standards for "minimal browser", for example, supporting only basic HTML tags, basic layout rules, WASM and Java bytecode. Many th…

Compare webkit to UDK (The unreal development kit for game dev) to consider why there is so much bloat in the browser. People have wanted to render more and more advanced things, and the webkit engine should cater to all of them as best it can. For better or worse, http is no longer just for serving textual documents.

Maya is the go to example of bloat for me for many of the same reasons.

Re: "Remove mentions of XSLT from the html spec"

#204

This is actually not a bad idea. Why should the browser contain a specific template engine, like XSLT, and not Jinja for example? Also it can be reimplemented using JS or WASM. The browsers today are too bloated and it is difficult to create a new browser engine. I wish there were simpler standards for "minimal browser", for example, supporting only basic HTML tags, basic layout rules, WASM and Java bytecode. Many th…

Why should the browser contain a specific scripting language, like JavaScript, and not ActiveScript for example?

The browser could use Java or .NET bytecode interpreter - in this case it doesn't need to have a compiler and you can use any language - but in this case you won't be able to see a script's source code.

Re: "Remove mentions of XSLT from the html spec"

#205

A few things to note: - This isn't Chrome doing this unilaterally. https://github.com/whatwg/html/issues/11523 shows that representatives from every browser are supportive and there have been discussions about this in standards meetings: https://github.com/whatwg/html/issues/11146#issuecomment-275... - You can see from the WHATNOT meeting agenda that it was a Mozilla engineer who brought it up last time. - Opening a…

Also, according to Chrome's telemetry, very, very few websites are using it in practice. It's not like the proposal is threatening to make some significant portion of the web inaccessible. At least we can see the data underlying the proposal here.

Sadly, I just built a web site with HTMX and am using the client-side-templates extension for client-side XSLT.

>very, very few websites

Doesn't include all the corporate web sites that they are probably blocked from getting such telemetry for. These are the users that are pushing back.

Re: "Remove mentions of XSLT from the html spec"

#206
post #133

Earlier quoted context omitted.

Former Mozilla and Google (Chrome team specifically) dev here. The way I see what you're saying is: Representatives from Chrome/Blink, Safari/Webkit, and Firefox/Gecko are all supportive of removing XSLT from the web platform, regardless of whether it's still being used. It's okay because someone from Mozilla brought it up. Out of those three projects, two are notoriously under-resourced, and one is notorious for con…

Another way to look at this is: Billions of people use the web every day. Should the 99.99% of them be vulnerable to XSLT security bugs for the other 0.01%?

Isn't this something that could be implemented using javascript?

I don't think anyone is arguing that XSLT has to be fast.

You could probably compile libxslt to wasm, run it when loading xml with xslt, and be done.

Does XSLT affect the DOM after processing, isn't it just a dumb preprocessing step, where the render xhtml is what becomes the DOM.

Re: "Remove mentions of XSLT from the html spec"

#207
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.)

Re: "Remove mentions of XSLT from the html spec"

#208
post #133

A few things to note: - This isn't Chrome doing this unilaterally. https://github.com/whatwg/html/issues/11523 shows that representatives from every browser are supportive and there have been discussions about this in standards meetings: https://github.com/whatwg/html/issues/11146#issuecomment-275... - You can see from the WHATNOT meeting agenda that it was a Mozilla engineer who brought it up last time. - Opening a…

Former Mozilla and Google (Chrome team specifically) dev here. The way I see what you're saying is: Representatives from Chrome/Blink, Safari/Webkit, and Firefox/Gecko are all supportive of removing XSLT from the web platform, regardless of whether it's still being used. It's okay because someone from Mozilla brought it up. Out of those three projects, two are notoriously under-resourced, and one is notorious for con…

Bring back VRML!

Seriously though, if I were forced to maintain every tiny legacy feature in a 20 year old app... I'd also become a "former" dev :)

Even in its heyday, XSLT seemed like an afterthought. Probably there are a handful of legacy corporate users hanging on to it for dear life. But if infinitely more popular techs (like Flash or FTP or non HTTPS sites) can be deprecated without much fuss... I don't think XSLT has much of a leg to stand on...

Re: "Remove mentions of XSLT from the html spec"

#209
post #185

Earlier quoted context omitted.

Also, https://github.com/whatwg/html/issues/11523 (Should we remove XSLT from the web platform?) is not a request for community feedback. It's an issue open on the HTML spec for the HTML spec maintainers to consider. It was opened by a Chrome engineer after at least two meetings where a Mozilla engineer raised the topic, and where there was apparently vendor support for it. This is happening after some serious exploi…

I think this discussion is quite reasonable, but it also highlights the power imbalance: If this stuff is decided in closed meetings and the bug trackers are not supposed to be places for community feedback, where can the community influence such decisions?

I think it depends on the spec. Some of the working groups still have mailing lists, some of them have GitHub issues.

To be completely honest, though, I'm not sure what people expect to get out of it. I dug into this a while ago for a rather silly reason and I found that it's very inside baseball, and unless you really wanted to get invested in it it seems like it'd be hard to meaningfully contribute.

To be honest if people are very upset about a feature that might be added or a feature that might be removed the right thing to do is probably to literally just raise it publicly, organize supporters and generally act in protest.

Google may have a lot of control over the web, but note that WEI still didn't ship.

Re: "Remove mentions of XSLT from the html spec"

#210
post #175

Earlier quoted context omitted.

> This is actually not a bad idea. Why should the browser contain a specific template engine, like XSLT XSLT is a specification for a "template engine" and not a specific engine. There are dozens of XSLT implementations. Mozilla notably doesn't use libxslt but transformiix: https://web.mit.edu/ghudson/dev/nokrb/third/firefox/extensio... > and not Jinja for example? Jinja operates on text, so it's basically document.w…

> I've been looking at it as a secret weapon: I've been using it for the last twenty years because it's faster than everything else. Serving a server-generated HTML page could be even faster.

> Serving a server-generated HTML page could be even faster.

Except it isn't.

Lots of things could be faster than they are.

Post reply on HN