Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"Remove mentions of XSLT from the html spec"

github.com

Post reply on HN
Print view View original

211–220 of 559 posts

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

#211

Post by chrismorgan »

Intent to remove: emergency services dialling (911, 112, 000, &c.)

Almost no one ever uses it: metrics show only around 0.02% of phone calls use this feature. So we’re planning on deprecating and then removing it.

—⁂—

Just an idea that occurred to me earlier today. XSLT doesn’t get a lot of use, but there are still various systems, important systems, that depend upon it. Links to feeds definitely want it, but it’s not just those sorts of things.

Percentages only tell part of the story. Some are tiny features that are used everywhere, others are huge features that are used in fewer places. Some features can be removed or changed with little harm—frankly, quite a few CSS things that they have declined to address on the grounds of usage fall into this category, where a few things would be slightly damaged, but nothing would be broken by it. Other features completely destroy workflows if you change or remove them—and XSLT is definitely one of these.

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

#212

Post by pygy_ »

codedokode wrote: post #68

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…

The old, bug-ridden native XSLT code could also be shipped as WASM along with the browser rather than being deprecated. The sandbox would nullify the exploits, and avoid breaking old sites.

They actually thought about it, and decided not to do it :-/

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

#213

Post by jmull »

thanhhaimai wrote: post #186
spankalee wrote: post #92

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…

The responses of some folks on this thread reminds me of this: https://xkcd.com/1172/

That's more a joke about people coming to rely on any observable behavior of something, no matter how buggy or unintentional.

Here's we're talking about killing off XSLT used in the intended, documented, standard way.

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

#214

Post by xg15 »

spankalee wrote: post #127
spankalee wrote: post #92

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

Sort of like an inverse of the solution that the post mentioned.

The only thing this doesn't fix is sites that are abandoned and won't update or are part if embedded devices and can't update.

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

#215

Post by moritzwarhier »

aidenn0 wrote: post #190
moritzwarhier wrote: post #163

Earlier quoted context omitted.

It would sure be possible to combine a polyfill with a webextension, not sure if XSLT contains any footguns for this approach that would make it hard to do, but if it's solely a single client-side transformation of the initial XML response, this should work fine. Cool example with the recipes page :)

I guess it's time for me to write that webextension; if it gets popular enough I can sell it to someone wearing a black hat for maybe tens of dollars!

haha good point :(

There are also very valid comments in there about why removal would still hurt existing sites and applications, especially for embedded devices.

https://github.com/whatwg/html/pull/11563#issuecomment-31970...

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

#216

Post by sugarpimpdorsey »

kg wrote: post #133
spankalee wrote: post #92

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…

> Representatives from Chrome/Blink, Safari/Webkit, and Firefox/Gecko are all supportive of removing XSLT

Did anybody bother checking with Microsoft? XML/XSLT is very enterprisey and this will likely break a lot of intranet (or $$$ commercial) applications.

Secondly, why is Firefox/Gecko given full weight for their vote when their marketshare is dwindling into irrelevancy? It's the equivalent of the crazy cat hoarder who wormed her way onto the HOA board speaking for everyone else. No.

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

#217

Post by nobleach »

93po wrote: post #154
kg wrote: 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…

When I see "reps from every browser agree" my bullshit alarm immediately goes off. Does it include unanimous support from browser projects that are either: 1. not trillion dollar tech companies or 2. not 99% funded from a trillion dollar tech company. I have long suspected that Google gives so much money to Mozilla both for the default search option, but also for massive indirect control to deliberately cripple Mozil…

Well, every browser engine that is part of WHATWG. That's how working groups... work. The current crop of "not Chrome/Firefox/Webkit" aren't typically building their own browser engines though. They're re-skinning Chromium/Gecko/Webkit.

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

#218

Post by NoGravitas »

spankalee wrote: post #192
xg15 wrote: post #185

Earlier quoted context omitted.

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?

Community feedback is usually very ad hoc. Platform PMs will work with major sites, framework maintainers, and sometimes do discussions and polls on social sites. IOW, they try to go where the community that uses the features are, rather than stay on GitHub in the spec issues.

Although in this case, it seems more like they are trying to go where the community that uses the feature isn't.

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

#219

Post by ummonk »

therealmarv wrote: post #36
ummonk wrote: post #21

Earlier quoted context omitted.

If it's a security issue, shouldn't the browsers just replace C++ code with the JS or WASM polyfill themselves?

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 features.
Post reply on HN