Live data from Hacker News

"Remove mentions of XSLT from the html spec"

github.com

261–270 of 559 posts

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

#261
post #55
post #37

Earlier quoted context omitted.

Last I checked, it’s a polyfill that Chrome won’t default include - they’re just saying that they’d have a polyfill in JS and it’s on site authors to use. That breaks old unmaintained but still valuable sites.

As a user you can only use the polyfill to replace the XSLTProcessor() JavaScript API. You can't use the polyfill if you're using XSLT for XML Stylesheets ( tags). (But of course, XML Stylesheets are most widely used with RSS feeds, and Google probably considers further harm to the RSS ecosystem as a bonus. sigh )

Moz also has no love for RSS, having removed support for live bookmarks in Firefox 64 (2018) and no longer displaying the RSS icon anywhere in the UI when a website has any tags. If you want to subscribe to feeds you have to jump through a bunch of hoops instead of it being a single click.

Fortunately, Thunderbird still has support for feeds and doesn't seem to have been afflicted by the same malaise as the rest of the org chart. Who knows how long that will last.

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

#262

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…

Apart from that doesn’t really work for people who are statically hosting their RSS feeds etc.

You can use content negotiation with static websites too. Apache has mod_negotiation, for example.

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

#263
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…

[dead]

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

#264
post #219

Earlier quoted context omitted.

I also wondered about that. They probably don't want to do that because of maintaining, fixing and allocating resources to it then. Probably a browser extension on the user side can do the same job if an XSLT relying page cannot be updated.

This seems like the kind of thing that won't require any resources to maintain, other than possible bugfixes (which 3rd parties can provide). It only requires parsing and DOM manipulation, so it doesn't really require any features of JS or WASM that would be deprecated in the future, and the XSLT standard that is supported by browsers is frozen - they won't ever have to dedicate resources to adding any additional fea…

That is an interesting approach, you could suggest it? In general using JS to implement web APIs is very difficult, but using WASM might work especially for the way XSLTProcessor works today.

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

#265

Earlier quoted context omitted.

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

> people who are actually using it I'd presume that most of those people are using it in some capacity, it's just that their numbers are seen as too minor to influence the decision. > explain why it's necessary No feature is strictly necessary, so that's a pretty high standard.

> I'd presume that most of those people are using it in some capacity, it's just that their numbers are seen as too minor to influence the decision.

I think the idea of that is reasonable. If I used XSLT on my tiny, low-traffic blog, I think it's reasonable for browser devs to tell me to update my code. Even if 100 people like me said the same thing, that's still a vanishingly small portion of the web, a rounding error, protesting it.

I'd expect the protests to be disproportionate in number and loudness because the billion webmasters who couldn't care less aren't weighing in on it.

Now, I'm not saying this with a strong opinion on this specific proposal. It doesn't affect me either way. It's more about the general principle that a loud number of small webmasters opposing the move doesn't mean it's not a good idea. Like, people loudly argued about removing back in the day, but that happened to be a great idea.

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

#266
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…

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 XS…

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

Flash was not part of the web platform. It was a plugin, a plugin that was, over time, abandoned by its maker.

FTP was not part of the web platform. It was a separate protocol that some browsers just happened to include a handler for. If you have an FTP client, you can still open FTP links just fine.

Non-HTTPS sites are being discouraged, but still work fine, and can reasonably be expected to continue to work indefinitely, though they are likely to be discouraged a bit harder over time.

XSLT is part of the web platform. And removing it breaks various things.

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

#267

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…

Wasm is ANYTHING but basic.

Fuck javascript, fuck wasm, fuck html, fuck css.

Rebase it all on XML/XPath/XQuery that way you only need ONE parser, one simple engine.

This whole kitchen sink/full blown OS nonsense needs to end.

Edit: You’re clearly a wasm shill, wasm is an abomination that needs to die.

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

#268
post #214

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

You can include a "link" HTTP header similar to a link tag. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...

This would work without special syntax in the XML file.

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

#269
post #214

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

Purely out of curiosity, what are some websites that actually make use of XSLT?

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

#270
post #236

Earlier quoted context omitted.

Yes, PDF documents which are generated using XSL-FO (XSL Formatting Objects) from an xml source document

Ah right, so that wouldn't be affected by this change because it happens all server-side if I understand it correctly?

Looks like someone pointed out in the related thread yesterday[0] that this little known site[1] is using it for client-side templating.

[0] https://news.ycombinator.com/item?id=44909599

[1] https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih....

Post reply on HN