8 ms·

I don't understand how WHATWG decides to remove XSLT, contradicting the 30+ years of never break the web doctrine... And simultaneously doesn't want to fix the

I don't understand how WHATWG decides to remove XSLT, contradicting the 30+ years of never break the web doctrine... And simultaneously doesn't want to fix the typeof null specification bug because of, wait for it, Microsoft Exchange 2003 relying on that. This makes absolutely no sense. We could've had such a nice language. The efforts for a cleaner language and web platform API were there, but doctrine always said no because of legacy and people have moved on to alternatives now.

masklinn 1y ago
Simple: xslt is a giant attack surface entirely in C, and no browser maintainer cares to expend resources on maintaining that (pretty sure every browser uses libxslt).
- mmastrac 1y ago
  It really should just be compiled to WASM and used with some sort of DOM bridge.
  - masklinn 1y ago
    The big sticking point is not the JS access, that’s mildly easy to implement. It’s that currently you can open an XML file (including feeds) with an associated stylesheet and the stylesheet gets applied, which can be used to render an HTML document on the client side from an xml source like a feed.
  - ioasuncvinvaer 1y ago
    The google people provided exactly that. A WASM polyfill.
    - youngtaff 1y ago
      Not really… it needs a HTML to load the polyfill and transform the XML You can’t have the browser load an XML file and have it transformed automatically as happens now
      - 8NNTt8z3QvLT8tp 1y ago
        Someone's already added a PR to allow exactly that. You just include a script tag within your XML file.
    - lopsotronic 1y ago
      I'm sorry to bug you, but can you link up the docs / news / cite for that? Will they need to replace their XSL with some JS/TS/Whatever, or can you just stick a converter so the XSL gets interpreted as something legal? What do they need serverside? I foresee a LOT of this "Panic Replace XSL" work landing right in my lap and if someone's already done the work I want to know about it.
- em-bee 1y ago
  pretty sure every browser uses libxslt apparently firefox has their own implementation. not that that makes things any better. the firefox implementation appears to be just as bad in shape as the libxslt bindings in chrome. see here for more details: https://news.ycombinator.com/item?id=44910050 https://news.ycombinator.com/item?id=44910050
- troupo 1y ago
  > Simple: xslt is a giant attack surface entirely in C, and no browser maintainer cares to expend resources on maintaining that And yet they have no qualms shoving huge attack surfaces in the form of WebUSB, WebSerial, WebMIDI, WebTransport, WebBluetooth, WebKitchenSink, most of which have as much usage as XSLT: https://chromestatus.com/metrics/feature/timeline/popularity/2029 https://chromestatus.com/metrics/feature/timeline/popularity... or https://chromestatus.com/metrics/feature/timeline/popularity/1521 https://chromestatus.com/metrics/feature/timeline/popularity...
  - cookiengineer 1y ago
    This is actually a great point. I was checking for XSLTProcessor out of curiosity, and most of the top sites seem to be all using Flarum as a software? Found it a nice fun fact: https://chromestatus.com/metrics/feature/timeline/popularity/79 https://chromestatus.com/metrics/feature/timeline/popularity... If you check it though what they're using XSLTProcessor for, it seems to be a fallback for an MSXML polyfill, e.g. when you search for "XSLTProcessor" here you can see it: view-source:http://discuz.turzx.com/assets/forum.js?v=3c534b8a http://discuz.turzx.com/assets/forum.js?v=3c534b8a So in the case of Flarum their DOMParser using alternative would chime in, as that's an additional fallback to the MSXML / ActiveX using polyfill.
  - masklinn 1y ago
    The critical part is “cares to expend resources”. Google really wants these communication protocols for whatever reason and is happy to support them, but clearly does not care about Xslt.
  - JimDabell 1y ago
    > > Simple: xslt is a giant attack surface entirely in C, and no browser maintainer cares to expend resources on maintaining that > And yet they have no qualms shoving huge attack surfaces in the form of WebUSB, WebSerial, WebMIDI, WebTransport, WebBluetooth This is not true. Both Mozilla and Apple rejected WebUSB, WebSerial, and WebBluetooth, and Apple rejected WebMIDI as well. Your list is mostly Blink-only APIs that Google have failed to convince other rendering engines to implement. And they all had lengthy discussions about security beforehand. So yes, browser maintainers definitely do have qualms about shoving those huge attack surfaces in there, and those qualms are a matter of public record you can read at your leisure. > most of which have as much usage as XSLT It doesn’t make sense to compare the usage of proposed features to a feature that has been implemented by all browsers for 25 years. Being available for 25 years and going almost entirely unused is a very strong signal that XSLT is not worth keeping around.
spankalee 1y ago
Easy: The WHAATWG hasn't decided to remove XLST. They are starting the process of deciding now.
bazoom42 1y ago
WHATWG have removed features before, e.g. frameset, font, and applet elements from HTML. All of them were rarely used and had better alternatives available.
- naniwaduni 1y ago
  XSLT uhhh notably doesn't actually have better alternatives available.
  - ioasuncvinvaer 1y ago
    html?
    - youngtaff 1y ago
      How do you create a HTML RSS feed?
      - ioasuncvinvaer 1y ago
        By rendering it on the server and serving it to the client.
        youngtaff 1y ago
        And is that RSS feed is part pf a blog that’s static content?
    - Izkata 1y ago
      You're thinking of XML, not XSLT. XSLT is a language for transforming XML into other structures.
      - ioasuncvinvaer 1y ago
        But why would a server send me xml instead of html? From the thread you can see that the servers already serve html so why is there a second way to present that content via xslt?
zarzavat 1y ago
> typeof null specification bug What is the typeof null specification bug? You mean that typeof null === 'object'? That's not a bug. It's also not WHATWG's responsibility, it's part of ECMAScript.

masklinn 1y ago

Simple: xslt is a giant attack surface entirely in C, and no browser maintainer cares to expend resources on maintaining that (pretty sure every browser uses libxslt).

mmastrac 1y ago
It really should just be compiled to WASM and used with some sort of DOM bridge.
- masklinn 1y ago
  The big sticking point is not the JS access, that’s mildly easy to implement. It’s that currently you can open an XML file (including feeds) with an associated stylesheet and the stylesheet gets applied, which can be used to render an HTML document on the client side from an xml source like a feed.
- ioasuncvinvaer 1y ago
  The google people provided exactly that. A WASM polyfill.
  - youngtaff 1y ago
    Not really… it needs a HTML to load the polyfill and transform the XML You can’t have the browser load an XML file and have it transformed automatically as happens now
    - 8NNTt8z3QvLT8tp 1y ago
      Someone's already added a PR to allow exactly that. You just include a script tag within your XML file.
  - lopsotronic 1y ago
    I'm sorry to bug you, but can you link up the docs / news / cite for that? Will they need to replace their XSL with some JS/TS/Whatever, or can you just stick a converter so the XSL gets interpreted as something legal? What do they need serverside? I foresee a LOT of this "Panic Replace XSL" work landing right in my lap and if someone's already done the work I want to know about it.
em-bee 1y ago
pretty sure every browser uses libxslt apparently firefox has their own implementation. not that that makes things any better. the firefox implementation appears to be just as bad in shape as the libxslt bindings in chrome. see here for more details: https://news.ycombinator.com/item?id=44910050 https://news.ycombinator.com/item?id=44910050
troupo 1y ago
> Simple: xslt is a giant attack surface entirely in C, and no browser maintainer cares to expend resources on maintaining that And yet they have no qualms shoving huge attack surfaces in the form of WebUSB, WebSerial, WebMIDI, WebTransport, WebBluetooth, WebKitchenSink, most of which have as much usage as XSLT: https://chromestatus.com/metrics/feature/timeline/popularity/2029 https://chromestatus.com/metrics/feature/timeline/popularity... or https://chromestatus.com/metrics/feature/timeline/popularity/1521 https://chromestatus.com/metrics/feature/timeline/popularity...
- cookiengineer 1y ago
  This is actually a great point. I was checking for XSLTProcessor out of curiosity, and most of the top sites seem to be all using Flarum as a software? Found it a nice fun fact: https://chromestatus.com/metrics/feature/timeline/popularity/79 https://chromestatus.com/metrics/feature/timeline/popularity... If you check it though what they're using XSLTProcessor for, it seems to be a fallback for an MSXML polyfill, e.g. when you search for "XSLTProcessor" here you can see it: view-source:http://discuz.turzx.com/assets/forum.js?v=3c534b8a http://discuz.turzx.com/assets/forum.js?v=3c534b8a So in the case of Flarum their DOMParser using alternative would chime in, as that's an additional fallback to the MSXML / ActiveX using polyfill.
- masklinn 1y ago
  The critical part is “cares to expend resources”. Google really wants these communication protocols for whatever reason and is happy to support them, but clearly does not care about Xslt.
- JimDabell 1y ago
  > > Simple: xslt is a giant attack surface entirely in C, and no browser maintainer cares to expend resources on maintaining that > And yet they have no qualms shoving huge attack surfaces in the form of WebUSB, WebSerial, WebMIDI, WebTransport, WebBluetooth This is not true. Both Mozilla and Apple rejected WebUSB, WebSerial, and WebBluetooth, and Apple rejected WebMIDI as well. Your list is mostly Blink-only APIs that Google have failed to convince other rendering engines to implement. And they all had lengthy discussions about security beforehand. So yes, browser maintainers definitely do have qualms about shoving those huge attack surfaces in there, and those qualms are a matter of public record you can read at your leisure. > most of which have as much usage as XSLT It doesn’t make sense to compare the usage of proposed features to a feature that has been implemented by all browsers for 25 years. Being available for 25 years and going almost entirely unused is a very strong signal that XSLT is not worth keeping around.

spankalee 1y ago

Easy: The WHAATWG hasn't decided to remove XLST. They are starting the process of deciding now.

bazoom42 1y ago

WHATWG have removed features before, e.g. frameset, font, and applet elements from HTML. All of them were rarely used and had better alternatives available.

naniwaduni 1y ago
XSLT uhhh notably doesn't actually have better alternatives available.
- ioasuncvinvaer 1y ago
  html?
  - youngtaff 1y ago
    How do you create a HTML RSS feed?
    - ioasuncvinvaer 1y ago
      By rendering it on the server and serving it to the client.
      - youngtaff 1y ago
        And is that RSS feed is part pf a blog that’s static content?
  - Izkata 1y ago
    You're thinking of XML, not XSLT. XSLT is a language for transforming XML into other structures.
    - ioasuncvinvaer 1y ago
      But why would a server send me xml instead of html? From the thread you can see that the servers already serve html so why is there a second way to present that content via xslt?

zarzavat 1y ago

> typeof null specification bug What is the typeof null specification bug? You mean that typeof null === 'object'? That's not a bug. It's also not WHATWG's responsibility, it's part of ECMAScript.