Live data from Hacker News

"Remove mentions of XSLT from the html spec"

github.com

481–490 of 559 posts

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

#481
post #214

Earlier quoted context omitted.

I think this post is useful where the thread author proposed some solutions to the people affected: https://github.com/whatwg/html/issues/11523#issuecomment-318... The main thing that seems unaddressed is the UX if a user opens a direct link to an XML file and will now just see tag soup instead of the intended rendering. I think this could be addressed by introducing a processing instruction that browsers would inter…

> I think this could be addressed by introducing a processing instruction that browsers would interpret like a meta tag redirect. Then sites that are interested could put that line at the top of their XML files and redirect to an alternative representation in HTML or even to a server-side or WASM-powered XSLT processor for the file. HTTP has already had this since the 90s. Clients send the Accept HTTP header indicati…

This is breaking the web though.

If they are so worried, then have the xslt support compiled to wasm and sandboxed.

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

#482
post #468

Earlier quoted context omitted.

> Of course someone would have to make that change. Of course. And yet none of the people from Google even seem to be aware of > The congress one appears to be the first legit example i have seen. There are more. E.g. podcast RSS feeds are often presented on the web with XSLT: https://feeds.buzzsprout.com/231452.rss Again, none of the people from Google even seem to be aware of these use cases, and just power through…

You're naming Google specifically, when it's not just Google. This seems like a you thing, separate to the actual issue at hand.

Well, it's Google who jumped at the opportunity citing their own counters and stats.

Just like they did the last time when they tried to remove confirm/prompt[1] and were surprised to see that their numbers don't paint the full picture, as literally explicitly explained in their own docs: https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS...

You'd think that the devs of the world's most popular browser would have a little more care than just citing some numbers, ignoring all feedback, and moving forward with whatever they want to do?

Oh. Speaking, of "not just Google".

The question was raised in this meeting: https://github.com/whatwg/html/issues/11146#issuecomment-275... Guess what.

--- start quote ---

dan: even if the data were accurate, not enough zeros for the usage to be low enough.

brian: I'm guessing people will have objections... people do use it and some like it

--- end quote ---

[1] See, e.g. https://gomakethings.com/google-vs.-the-web/

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

#483
post #86

Earlier quoted context omitted.

Which is, to me, silly. If you ship the polyfill then there's no discussion to be had. It works just the same as it always has for users and it's as secure as V8, no aging native codebase with memory corruption bugs to worry about.

At the moment, XSLT in a browser doesn't depend on Javascript, so works even if JS is turned off. Using a polyfill instead will mean that XSLT will only work if JS is turned on.

That depends how the browsers implement it, no? Much of modern browser's user interface is also built using web technologies including JS and that doesn't break if you "disable JS".

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

#484
post #468

Earlier quoted context omitted.

At first glance the library of congress link appears to be using server side XSLT, which would not be affected by this proposal. The congress one appears to be the first legit example i have seen. At first glance the congress use case does seem like it would be fully covered by CSS [you can attach CSS stylesheets to generic xml documents in a similar fashion to xslt]. Of course someone would have to make that change.

> Of course someone would have to make that change. Of course. And yet none of the people from Google even seem to be aware of > The congress one appears to be the first legit example i have seen. There are more. E.g. podcast RSS feeds are often presented on the web with XSLT: https://feeds.buzzsprout.com/231452.rss Again, none of the people from Google even seem to be aware of these use cases, and just power through…

> Of course. And yet none of the people from Google even seem to be aware of

I don't see any reason to assume that. I don't think anyone from google is claiming the literal number of sites is 0, just that it is insignificant.

I am very sure the people at google are aware of the rss feed usage.

Don't confuse people disagreeing with you with people not understanding you.

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

#485
post #468

Earlier quoted context omitted.

> Of course someone would have to make that change. Of course. And yet none of the people from Google even seem to be aware of > The congress one appears to be the first legit example i have seen. There are more. E.g. podcast RSS feeds are often presented on the web with XSLT: https://feeds.buzzsprout.com/231452.rss Again, none of the people from Google even seem to be aware of these use cases, and just power through…

> Of course. And yet none of the people from Google even seem to be aware of I don't see any reason to assume that. I don't think anyone from google is claiming the literal number of sites is 0, just that it is insignificant. I am very sure the people at google are aware of the rss feed usage. Don't confuse people disagreeing with you with people not understanding you.

> I am very sure the people at google are aware of the rss feed usage.

No. No they aren't. As you can see in the discussion: https://github.com/whatwg/html/issues/11523 where the engineer who proposed this literally updates his "analysis" as people point out use cases he missed.

Quote:

--- start quote ---

albertobeta: there is a real-world and modern use case from the podcasting industry, where I work. Collectively, we host over 4.5 million RSS feeds. Like many other podcast hosting companies, we use XSLT to beautify our raw feeds and make them easier to understand when viewed in a browser.

mfreed7, the Googler https://github.com/whatwg/html/issues/11523#issuecomment-315... : Thanks for the additional context on this use case! I'm trying to learn more about it.

--- end quote ---

And then just last week: https://github.com/whatwg/html/issues/11523#issuecomment-318...

--- start quote ---

Thanks for all of the comments, details, and information on this issue. It's clear that XSLT (and talk of removing it) strikes a nerve with some folks. I've learned a lot from the posts here.

--- end quote ---

> Don't confuse people disagreeing with you with people not understanding you.

Oh, they don't even attempt to understand people.

Here's him last week adding a PR to remove XSLT from the spec: https://github.com/whatwg/html/pull/11563

Did he address any of the issues? Does he link to any actual research pointing out how much will be broken, where it's used etc.?

Nope.

But then another Googler pulls up, says "good work, don't forget to remove it everywhere else". End of discussion.

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

#486
post #481

Earlier quoted context omitted.

> I think this could be addressed by introducing a processing instruction that browsers would interpret like a meta tag redirect. Then sites that are interested could put that line at the top of their XML files and redirect to an alternative representation in HTML or even to a server-side or WASM-powered XSLT processor for the file. HTTP has already had this since the 90s. Clients send the Accept HTTP header indicati…

This is breaking the web though. If they are so worried, then have the xslt support compiled to wasm and sandboxed.

This is not breaking the web, stop being so needlessly hyperbolic. XSLT use is absolutely tiny. If you removed it, >99.9% of the web wouldn’t even notice.

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

#487
post #318
post #303

Earlier quoted context omitted.

Honestly, your chance to impact this decision was when you decided what technologies to use on your website, and then statistically speaking [1], chose not to use XSLT in the browser. If the web used it like crazy we would not be having this conversation. Your other opportunity is to put together a credible plan to resource the XSLT implementations in the various browsers. I underline, highlight, bold, and italicize…

That's not completely wrong, but also misses some nuance. E.g. the thread mentions the fact that web support is still stuck at XSLT 1.0 as a reason for removal. But as far as I know, there were absolutely zero efforts by browser vendors before to support newer versions of the language, while there was enormous energy to improve JavaScript. I don't want to imply that if they had just added support for XSLT 3.0 then ev…

>while there was enormous energy to improve JavaScript

What was the point of it though? People transpile from other languages anyway and pull megabytes of npm dependencies.

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

#488

Earlier quoted context omitted.

[Citation needed] Seriously, i doubt this.

A lot of very old SPA like heavy applications use XSLT. Basically, enterprise web applications (not websites) that predate fetch, rest, and targeted or still target Internet Explorer 5/6. There was a time where the standard way to build a highly interactive SPA was using SOAP services on the backend combined with iframes on the front end that executed XSLT in the background to update the DOM. Obviously such an approa…

I ran xslt in foreground, it was fast enough for that even on celeron and 128mb RAM. Imagine running modern web 2.0 on 128mb RAM.

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

#489
post #468

Earlier quoted context omitted.

At first glance the library of congress link appears to be using server side XSLT, which would not be affected by this proposal. The congress one appears to be the first legit example i have seen. At first glance the congress use case does seem like it would be fully covered by CSS [you can attach CSS stylesheets to generic xml documents in a similar fashion to xslt]. Of course someone would have to make that change.

> Of course someone would have to make that change. Of course. And yet none of the people from Google even seem to be aware of > The congress one appears to be the first legit example i have seen. There are more. E.g. podcast RSS feeds are often presented on the web with XSLT: https://feeds.buzzsprout.com/231452.rss Again, none of the people from Google even seem to be aware of these use cases, and just power through…

They are easy to understand :) Modern browsers became such bloatware beyond salvation, they start to feel all the tech debt.

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

#490

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…

>essentially all the feedback said "no, please don't". And they said "thanks for the feedback, we're gonna do it any way!"? this is a perfectly reasonable course of action if the feedback is "please don't" but the people saying "please don't" aren't people who are actually using it or who can explain why it's necessary. it's a request for feedback, not just a poll.

Part of the reason I stopped was lack of higher than 1.0 in browsers.

The other reason is that SVG took a very long time to get good, and when it did I wanted to use XSL and SVG together.

Now SVG has got good and they are removing it :(

Post reply on HN