5 ms·

The drama around the XSLT stuff is ridiculous. It's a dead format that no one uses[1], no one will miss, no one wants to maintain, and that provides significant

by coldpie 11mo ago

The drama around the XSLT stuff is ridiculous. It's a dead format that no one uses[1], no one will miss, no one wants to maintain, and that provides significant complexity and attack surface. It's unambiguously the right thing to do to remove it. No one who actually works in the web space disagrees. Yes, it's a problem that Chrome has too much market share, but XSLT's removal isn't a good demonstration of that. [1] Yes, I already know about your one European law example that you only found out exists because of this drama.

bryanrasmussen 11mo ago
>Yes, I already know about your one European law example What example is that?
- coldpie 11mo ago
  This page is styled via an XSLT transform: https://www.europarl.europa.eu/politicalparties/index_en.xml https://www.europarl.europa.eu/politicalparties/index_en.xml The drama mongers like to bring it up as an example of something that will be harmed by XSLT's removal, but it already has an HTML version, which is the one people actually use.
Analemma_ 11mo ago
Another bit of ridiculousness is pinning the removal on Google. Removing XSLT was proposed by Mozilla and unanimously supported with no objections by the rest of the WHATWG. Go blame Mozilla if you want somebody to get mad at, or least blame all the browser vendors equally. This has nothing to do with Chrome’s market share.
- troupo 11mo ago
  Google are the ones immediately springing into action. They only started collecting feedback on which sites may break after they already pushed "Intention to remove" and prepared a PR to remove it from Chromium.
  - hn_throwaway_99 11mo ago
    > Google are the ones immediately springing into action. You say that like it's a bad thing. The proposal was already accepted. The most useful way to get feedback about which sites would break is to actually make a build without XSLT support and see what breaks.
- basscomm 11mo ago
  Shouldn't the users of the Web also get a say? There's been a lot of blowback on this decision, so this isn't as cut and dried as it's being made out to be
  - andsoitis 11mo ago
    > Shouldn't the users of the Web also get a say? How?
    - basscomm 11mo ago
      Using the technology and opting in to telemetry, feedback forums, user surveys, newsgroups, letter writing, email campaigns, telnet into a BBS, grass-roots websites, semaphore, Morse code, teletype, fax, etc. Anything is better than nothing, if anyone actually listens to the feedback they get instead of taking it and ignoring it.
troupo 11mo ago
> It's a dead format that no one uses[1], This has to be proven by Google (and other browser vendors), not by people coming up with examples. The guy pushing "intent to deprecate" didn't even know about the most popular current usage (displaying podcast RSS feeds) until after posting the issue and until after people started posting examples: https://github.com/whatwg/html/issues/11523#issuecomment-3152359096 https://github.com/whatwg/html/issues/11523#issuecomment-315... Meanwhile Google's own document says that's not how you approach deprecation: https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?pli=1&tab=t.0#heading=h.83o2xr8ayal6 https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS... Also, "no one uses it" is rich considering that XSLT's usage is 10x the usage of features Google has no trouble shoving into the browser and maintaining. Compare XSLT https://chromestatus.com/metrics/feature/timeline/popularity/79 https://chromestatus.com/metrics/feature/timeline/popularity... with USB https://chromestatus.com/metrics/feature/timeline/popularity/1521 https://chromestatus.com/metrics/feature/timeline/popularity... or WebTransport: https://chromestatus.com/metrics/feature/timeline/popularity/3472 https://chromestatus.com/metrics/feature/timeline/popularity... or even MIDI (also supported by Firerox) https://chromestatus.com/metrics/feature/timeline/popularity/2029 https://chromestatus.com/metrics/feature/timeline/popularity.... XSLT deprecation is a symptom of how browser vendors, and especially Google, couldn't give two shits about the stated purposes of the web. To quote Rich Harris from the time when Google rushed to remove alert/confirm: "the needs of users and authors (i.e. developers) should be treated as higher priority than those of implementors (i.e. browser vendors), yet the higher priority constituencies are at the mercy of the lower priority ones" https://dev.to/richharris/stay-alert-d https://dev.to/richharris/stay-alert-d
- Aurornis 11mo ago
  > Also, "no one uses it" is rich considering that XSLT's usage is 10x the usage of features Google has no trouble shoving into the browser and maintaining. Compare XSLT https://chromestatus.com/metrics/feature/timeline/popularity https://chromestatus.com/metrics/feature/timeline/popularity... with … Comparing absolute usage of an old standard to newer niche features isn’t useful. The USB feature is niche, but very useful and helpful for pages setting up a device. I wouldn’t expect it to show up on a large percentage of page loads. XSLT was supposed to be a broad standard with applications beyond single setup pages. The fact that those two features are used similarly despite one supposedly being a broad standard and the other being a niche feature that only gets used in unique cases (device setup or debugging) is only supportive of deprecating XSLT, IMO
lunar_mycroft 11mo ago
The fact that people didn't realize that a site used XSLT before the recent drama is meaningless. Even as a developer, I don't know how most of the sites I visit work under the hood. Unless I have a reason to go poking around, I would probably never know whether a site used react, solid, svelte, or jquery. But it ultimately doesn't matter either way. A major selling point/part of the "contract" the web platform has with web developers is backwards compatibility. If you make a web site which only relies on web standards (i.e. not vendor specific features or 3rd party plugins), you can/could expect it to keep working forever. Browser makers choosing to break that "contract" is bad for the internet regardless of how popular XSLT is. Oh, and as the linked article points out, the attack surface concerns are obviously bad faith. The polyfil means browser makers could choose to sandbox it in a way that would be no less robust than their existing JS runtime.
- coldpie 11mo ago
  > Browser makers choosing to break that "contract" is bad for the internet regardless of how popular XSLT is. No, this is wrong. Maintaining XSLT support has a cost, both in providing an attack surface and in employee-hours just to keep it around. Suppose it is not used at all, then removing it would be unquestionably good, as cost & attack surface would go down with no downside. Obviously it's not the case that it has zero usage, so it comes down to a cost-benefit question, which is where popularity comes in.
  - lunar_mycroft 11mo ago
    I want to start out by noting that despite both the linked article the very comment you're replying to pointing out that the security excuse is transparently bad faith, you still trotted it out, again. And no, it really isn't a cost benefit question. Or if you'd prefer, the _indirect_ costs of breaking backwards compatibility are much higher than the _direct_ cost. As it stood, as a web developer you only needed to make sure that your code followed standards and it would continue to work. If the browser makers can decide to depriciate those standards, developers have to instead attempt to divine whether or not the features they want to use will remain popular (or rather, whether browser makers will continue to _think_ they're popular, which is very much not the same thing).
basscomm 11mo ago
I've been running a small hobby site using XML and XSLT for the last five or so years, but Google refused to index it because Googlebot doesn't execute XSLT. I can't be the only one, but good luck Googling it
- andsoitis 11mo ago
  > but good luck Googling it Link?
  - basscomm 11mo ago
    https://wyrm.org/index.xml https://wyrm.org/index.xml I migrated to an Org-mode-based workflow a couple of weeks ago because I can see the writing on the wall, but most of the XML and XSLT files are still in place because cool URIs don't change(1). Who knows how many other XML and XSLT-based sites still exist on the internet because Google refuses to index that content 1. https://www.w3.org/Provider/Style/URI https://www.w3.org/Provider/Style/URI

by coldpie 11mo ago

bryanrasmussen 11mo ago

>Yes, I already know about your one European law example What example is that?

coldpie 11mo ago
This page is styled via an XSLT transform: https://www.europarl.europa.eu/politicalparties/index_en.xml https://www.europarl.europa.eu/politicalparties/index_en.xml The drama mongers like to bring it up as an example of something that will be harmed by XSLT's removal, but it already has an HTML version, which is the one people actually use.

Analemma_ 11mo ago

Another bit of ridiculousness is pinning the removal on Google. Removing XSLT was proposed by Mozilla and unanimously supported with no objections by the rest of the WHATWG. Go blame Mozilla if you want somebody to get mad at, or least blame all the browser vendors equally. This has nothing to do with Chrome’s market share.

troupo 11mo ago
Google are the ones immediately springing into action. They only started collecting feedback on which sites may break after they already pushed "Intention to remove" and prepared a PR to remove it from Chromium.
- hn_throwaway_99 11mo ago
  > Google are the ones immediately springing into action. You say that like it's a bad thing. The proposal was already accepted. The most useful way to get feedback about which sites would break is to actually make a build without XSLT support and see what breaks.
basscomm 11mo ago
Shouldn't the users of the Web also get a say? There's been a lot of blowback on this decision, so this isn't as cut and dried as it's being made out to be
- andsoitis 11mo ago
  > Shouldn't the users of the Web also get a say? How?
  - basscomm 11mo ago
    Using the technology and opting in to telemetry, feedback forums, user surveys, newsgroups, letter writing, email campaigns, telnet into a BBS, grass-roots websites, semaphore, Morse code, teletype, fax, etc. Anything is better than nothing, if anyone actually listens to the feedback they get instead of taking it and ignoring it.

troupo 11mo ago

> It's a dead format that no one uses[1], This has to be proven by Google (and other browser vendors), not by people coming up with examples. The guy pushing "intent to deprecate" didn't even know about the most popular current usage (displaying podcast RSS feeds) until after posting the issue and until after people started posting examples: https://github.com/whatwg/html/issues/11523#issuecomment-3152359096 https://github.com/whatwg/html/issues/11523#issuecomment-315... Meanwhile Google's own document says that's not how you approach deprecation: https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?pli=1&tab=t.0#heading=h.83o2xr8ayal6 https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS... Also, "no one uses it" is rich considering that XSLT's usage is 10x the usage of features Google has no trouble shoving into the browser and maintaining. Compare XSLT https://chromestatus.com/metrics/feature/timeline/popularity/79 https://chromestatus.com/metrics/feature/timeline/popularity... with USB https://chromestatus.com/metrics/feature/timeline/popularity/1521 https://chromestatus.com/metrics/feature/timeline/popularity... or WebTransport: https://chromestatus.com/metrics/feature/timeline/popularity/3472 https://chromestatus.com/metrics/feature/timeline/popularity... or even MIDI (also supported by Firerox) https://chromestatus.com/metrics/feature/timeline/popularity/2029 https://chromestatus.com/metrics/feature/timeline/popularity.... XSLT deprecation is a symptom of how browser vendors, and especially Google, couldn't give two shits about the stated purposes of the web. To quote Rich Harris from the time when Google rushed to remove alert/confirm: "the needs of users and authors (i.e. developers) should be treated as higher priority than those of implementors (i.e. browser vendors), yet the higher priority constituencies are at the mercy of the lower priority ones" https://dev.to/richharris/stay-alert-d https://dev.to/richharris/stay-alert-d

Aurornis 11mo ago
> Also, "no one uses it" is rich considering that XSLT's usage is 10x the usage of features Google has no trouble shoving into the browser and maintaining. Compare XSLT https://chromestatus.com/metrics/feature/timeline/popularity https://chromestatus.com/metrics/feature/timeline/popularity... with … Comparing absolute usage of an old standard to newer niche features isn’t useful. The USB feature is niche, but very useful and helpful for pages setting up a device. I wouldn’t expect it to show up on a large percentage of page loads. XSLT was supposed to be a broad standard with applications beyond single setup pages. The fact that those two features are used similarly despite one supposedly being a broad standard and the other being a niche feature that only gets used in unique cases (device setup or debugging) is only supportive of deprecating XSLT, IMO

lunar_mycroft 11mo ago

The fact that people didn't realize that a site used XSLT before the recent drama is meaningless. Even as a developer, I don't know how most of the sites I visit work under the hood. Unless I have a reason to go poking around, I would probably never know whether a site used react, solid, svelte, or jquery. But it ultimately doesn't matter either way. A major selling point/part of the "contract" the web platform has with web developers is backwards compatibility. If you make a web site which only relies on web standards (i.e. not vendor specific features or 3rd party plugins), you can/could expect it to keep working forever. Browser makers choosing to break that "contract" is bad for the internet regardless of how popular XSLT is. Oh, and as the linked article points out, the attack surface concerns are obviously bad faith. The polyfil means browser makers could choose to sandbox it in a way that would be no less robust than their existing JS runtime.

coldpie 11mo ago
> Browser makers choosing to break that "contract" is bad for the internet regardless of how popular XSLT is. No, this is wrong. Maintaining XSLT support has a cost, both in providing an attack surface and in employee-hours just to keep it around. Suppose it is not used at all, then removing it would be unquestionably good, as cost & attack surface would go down with no downside. Obviously it's not the case that it has zero usage, so it comes down to a cost-benefit question, which is where popularity comes in.
- lunar_mycroft 11mo ago
  I want to start out by noting that despite both the linked article the very comment you're replying to pointing out that the security excuse is transparently bad faith, you still trotted it out, again. And no, it really isn't a cost benefit question. Or if you'd prefer, the _indirect_ costs of breaking backwards compatibility are much higher than the _direct_ cost. As it stood, as a web developer you only needed to make sure that your code followed standards and it would continue to work. If the browser makers can decide to depriciate those standards, developers have to instead attempt to divine whether or not the features they want to use will remain popular (or rather, whether browser makers will continue to _think_ they're popular, which is very much not the same thing).

basscomm 11mo ago

I've been running a small hobby site using XML and XSLT for the last five or so years, but Google refused to index it because Googlebot doesn't execute XSLT. I can't be the only one, but good luck Googling it

andsoitis 11mo ago
> but good luck Googling it Link?
- basscomm 11mo ago
  https://wyrm.org/index.xml https://wyrm.org/index.xml I migrated to an Org-mode-based workflow a couple of weeks ago because I can see the writing on the wall, but most of the XML and XSLT files are still in place because cool URIs don't change(1). Who knows how many other XML and XSLT-based sites still exist on the internet because Google refuses to index that content 1. https://www.w3.org/Provider/Style/URI https://www.w3.org/Provider/Style/URI