5 ms·

Presuming this goes ahead, I believe this is the first time a standard, baseline-available feature will be removed. There have been other removals, but few of

Presuming this goes ahead, I believe this is the first time a standard, baseline-available feature will be removed. There have been other removals, but few of them were of even specified features, and I don’t think any of them have been universally available. One of the closest might be showModalDialog <https://web.archive.org/web/20140401014356/http://dev.opera.com/articles/view/showmodaldialog/ https://web.archive.org/web/20140401014356/http://dev.opera....>, but I gather mobile browsers never supported it anyway, and it was a really problematic feature from an implementation perspective too. You could argue Mutation Events from ~2011 qualifies¹; it was supplanted by Mutation Observers within two years, yet hung around for over a decade before being removed. As for things like Flash or FTP, those were never part of the web platform. Nor were they ever anything like universal anyway. And so here they are now planning to remove a well-entrenched (if not especially commonly used) feature against the clearly-expressed will of the actual developers, in a one year time frame. —⁂— ¹ I choose to disqualify Mutation Events because no one ever finished their implementation: WebKit heritage never did DOMAttrModified, Gecko/Trident heritage never did DOMNodeInsertedIntoDocument or DOMNodeRemovedFromDocument. Flimsy excuse, probably. If you want to count it, perhaps you’ll agree to consider XSLT the first time a major, standard, baseline-available feature will be removed?

CamJN 1y ago
Maybe the blink or marquee tags? I’m pretty sure those don’t work anymore...
- chrismorgan 1y ago
  <marquee> still works fine. Better than it used to, honestly, as at least Firefox and Chromium removed the deliberate low frame rate at some point in the last decade. <blink> was never universal, contrary to popular impression: <https://en.wikipedia.org/wiki/Blink_element#:~:text=The%20blink%20element%20type%20was,functional%20blink%20tag. https://en.wikipedia.org/wiki/Blink_element#:~:text=The%20bl...>, it was only ever supported by Netscape/Gecko/Presto, never Trident/WebKit. Part of the joke of Blink is that it never supported <blink>. > Netscape only agreed to remove the blink tag from their browser if Microsoft agreed to get rid of the marquee tag in theirs during an HTML ERB meeting in February 1996. Fun times. Both essentially accusing the other of having a dumb tag.
- bojle 1y ago
  marquee is used religiously by some official Indian websites [1]. It's the primary mechanism they use to deliver news or updates on the websites. [1] For example: https://www.nagpuruniversity.ac.in/ https://www.nagpuruniversity.ac.in/
  - chrismorgan 1y ago
    Extremely popular in Indian government websites, often implemented with <marquee>, but also often implemented by a different mechanism so that it can stop scrolling on mouseover. Indian Rail <https://www.indianrail.gov.in/ https://www.indianrail.gov.in/> has one containing the chart from a mid-2024 train accident, an invitation to contribute a recording of the national anthem from 2021, and a link to parcel booking. Oh, and “NEW!” animated GIFs between the three items.
    - bojle 1y ago
      >Oh, and “NEW!” animated GIFs between the three items. That's gotta be the second most popular web design quirk. Haha
veeti 1y ago
Look, I wouldn't want to be responsible for maintaining anything to do with XML or XSLT either. All the technical arguments outlined for removing support make sense. But can users really call it an "update" if you could view an XML/XSLT document in Internet Explorer 6 or Chrome 1 but not the newest version? I think this sets a concerning precedent for future deprecations, where parts of the web platform are rugpulled from developers because it's convenient for the browser vendors.
- echelon 1y ago
  > maintaining anything to do with XML or XSLT either. These aren't horrible formats or standards. XSLT is actually somewhat elegant.
  - hannob 1y ago
    Counterpoint: XML is a horrible format. Why? Answer this question: how can you use XML in a way that does not create horrible security vulnerabilities? I know the answer, but it is extremely nontrivial, and highly dependent on which programming language, library, and sometimes even which library function you use. The fact that there's no easy way to use XML without creating a security footgun is reason enough to avoid it.
    - da_chicken 1y ago
      That's not any different than JSON, though. Injection, insecure deserialization , etc. can all exist in that format as well. There's plenty of reasons to criticize XML, and plenty more to criticize XSLT. But security being the one you call out feels at least moderately disingenuous. It's a criticism of the library, not the standard or the format.
      - dtech 1y ago
        There's an extremely large difference in that a JSON deserialization vulnerability is almost always a bug in the library. JSON is not an inherently insecure format. XML is so complex that a 100% bug-free compliant library is inherently insecure, and the vulnerability is a "user is holding it wrong" siutation, they should have disabled specific XML features etc. That means XML is an inherently much more insecure format. There's a reason there's name for vulnerabilities like XML External Entity (XXE) injection [1] and they're named after XML, and not "bug in lib/software X". JSON and most other data formats don't have that. [1] https://portswigger.net/web-security/xxe https://portswigger.net/web-security/xxe
bawolff 1y ago
> As for things like Flash or FTP, those were never part of the web platform. Nor were they ever anything like universal anyway. I feel like there is a bit of a no true scotsman to this. XSLT was always kind of on the side. If FTP or flash weren't part of the web platform than i dont know that xslt is either. Flash might not be "standard" but it certainly had more users in its heyday than xslt ever did. Does removal of tls 1.1 count here? Its all kind of a matter of definitions. Personally i always thought the <keygen> tag was really cool.
- chrismorgan 1y ago
  XSLT is an integrated part of the web platform: browsers can load XML documents that use an XSLT stylesheet, and even inside HTML documents XSLTProcessor is available. FTP was never integrated: it just so happened that some platforms shipped a protocol handler for it, and some browsers included an FTP protocol handler themselves. But I don’t believe you could ever, say, fetch("ftp://…"). Flash, like applets, was even more clearly not part of the web platform. It was a popular third-party extension that you had to go out of your way to install… or wait for it to be installed by some shady installer Adobe paid off. Though I have a vague feeling Chrome shipped with Flash at some point? I don’t remember all the history any more, this is a long time ago. Older versions of TLS is definitely a more interesting case. It’s a different kind of feature, but… yeah, I might consider it. <keygen> was an interesting concept that in practice went nowhere.
  - bawolff 1y ago
    > FTP was never integrated: it just so happened that some platforms shipped a protocol handler for it, and some browsers included an FTP protocol handler themselves. But I don’t believe you could ever, say, fetch("ftp://…"). I never tried, but i believe the relavent spec said it should work, until it was deprecated and removed from the standard https://github.com/whatwg/fetch/pull/1166 https://github.com/whatwg/fetch/pull/1166 With flash - that might all be true, but there was a time when many websites required it. It might not have been a de jure standard but it was a de facto standard. To the point where a browser not supporting it was considered broken. Apple refusing to support it was incredibly controversial at the time.
om2 1y ago
XSLT is also a really problematic feature from an implementation perspective (albeit in a different way than showModalDialog or MutationObservers). I’m not a Chrome dev but I think they have decent reasons for going this way.
- sam_lowry_ 1y ago
  1.1 is not that complex to implement
  - om2 1y ago
    Implementing it without tons of security bugs is apparently pretty hard.
bartread 1y ago
Yeah… on the one hand I don’t care about XSLT, haven’t used it in more than 20 years, and never intend to use it again. On the other… I’m still a bit uncomfortable with the proposed change because it reads as another example of Google unilaterally dictating the future of the web, which I’ve never liked or supported. Feeling quite conflicted.
- righthand 1y ago
  "It didn't affect me so I didn't care." Is usually how control is amassed by Google (or authoritarians).
  - bartread 1y ago
    Very fair point, and that cuts to the root of why I’m uncomfortable with it. I mean, presumably they have the usage stats… except that plenty of enterprises deployed XSLT apps back in the day - it was on a massive portion of the job ads I was looking at in 2000 to 2002 - and I’d bet a chunk of those legacy systems are still running. I’d also bet a good chunk of those systems are running in the sort of orgs that won’t allow submission of telemetry to Google, so Google’s usage stats underreport real world usage. To me it looks like zero effort has been made to engage with Mozilla, Apple, etc., on the right way forward here - just Google high-handedly making moves and abusing their position as per usual.
    - jsnell 1y ago
      > To me it looks like zero effort has been made to engage with Mozilla, Apple, etc., on the right way forward here - just Google high-handedly making moves and abusing their position as per usual. What would make you think that? The submission links prominently to the whatwg proposal github issue, which is the forum where that engagement would happen. It explicitly deep-links to Mozilla's and Apple's posts in that thread. It has the usage stats that you just presume exist. It's like you just made up a scenario and posted it as facts with zero effort to verify any of it.
- spiffytech 1y ago
anal_reactor 1y ago
> As for things like Flash or FTP, those were never part of the web platform. Nor were they ever anything like universal anyway. Flash was the web technology.
- chrismorgan 1y ago
  The web technology… that didn’t come out of the box, wasn’t supported on all platforms, and didn’t integrate?

CamJN 1y ago

Maybe the blink or marquee tags? I’m pretty sure those don’t work anymore...

chrismorgan 1y ago
<marquee> still works fine. Better than it used to, honestly, as at least Firefox and Chromium removed the deliberate low frame rate at some point in the last decade. <blink> was never universal, contrary to popular impression: <https://en.wikipedia.org/wiki/Blink_element#:~:text=The%20blink%20element%20type%20was,functional%20blink%20tag. https://en.wikipedia.org/wiki/Blink_element#:~:text=The%20bl...>, it was only ever supported by Netscape/Gecko/Presto, never Trident/WebKit. Part of the joke of Blink is that it never supported <blink>. > Netscape only agreed to remove the blink tag from their browser if Microsoft agreed to get rid of the marquee tag in theirs during an HTML ERB meeting in February 1996. Fun times. Both essentially accusing the other of having a dumb tag.
bojle 1y ago
marquee is used religiously by some official Indian websites [1]. It's the primary mechanism they use to deliver news or updates on the websites. [1] For example: https://www.nagpuruniversity.ac.in/ https://www.nagpuruniversity.ac.in/
- chrismorgan 1y ago
  Extremely popular in Indian government websites, often implemented with <marquee>, but also often implemented by a different mechanism so that it can stop scrolling on mouseover. Indian Rail <https://www.indianrail.gov.in/ https://www.indianrail.gov.in/> has one containing the chart from a mid-2024 train accident, an invitation to contribute a recording of the national anthem from 2021, and a link to parcel booking. Oh, and “NEW!” animated GIFs between the three items.
  - bojle 1y ago
    >Oh, and “NEW!” animated GIFs between the three items. That's gotta be the second most popular web design quirk. Haha

veeti 1y ago

Look, I wouldn't want to be responsible for maintaining anything to do with XML or XSLT either. All the technical arguments outlined for removing support make sense. But can users really call it an "update" if you could view an XML/XSLT document in Internet Explorer 6 or Chrome 1 but not the newest version? I think this sets a concerning precedent for future deprecations, where parts of the web platform are rugpulled from developers because it's convenient for the browser vendors.

echelon 1y ago
> maintaining anything to do with XML or XSLT either. These aren't horrible formats or standards. XSLT is actually somewhat elegant.
- hannob 1y ago
  Counterpoint: XML is a horrible format. Why? Answer this question: how can you use XML in a way that does not create horrible security vulnerabilities? I know the answer, but it is extremely nontrivial, and highly dependent on which programming language, library, and sometimes even which library function you use. The fact that there's no easy way to use XML without creating a security footgun is reason enough to avoid it.
  - da_chicken 1y ago
    That's not any different than JSON, though. Injection, insecure deserialization , etc. can all exist in that format as well. There's plenty of reasons to criticize XML, and plenty more to criticize XSLT. But security being the one you call out feels at least moderately disingenuous. It's a criticism of the library, not the standard or the format.
    - dtech 1y ago
      There's an extremely large difference in that a JSON deserialization vulnerability is almost always a bug in the library. JSON is not an inherently insecure format. XML is so complex that a 100% bug-free compliant library is inherently insecure, and the vulnerability is a "user is holding it wrong" siutation, they should have disabled specific XML features etc. That means XML is an inherently much more insecure format. There's a reason there's name for vulnerabilities like XML External Entity (XXE) injection [1] and they're named after XML, and not "bug in lib/software X". JSON and most other data formats don't have that. [1] https://portswigger.net/web-security/xxe https://portswigger.net/web-security/xxe

bawolff 1y ago

> As for things like Flash or FTP, those were never part of the web platform. Nor were they ever anything like universal anyway. I feel like there is a bit of a no true scotsman to this. XSLT was always kind of on the side. If FTP or flash weren't part of the web platform than i dont know that xslt is either. Flash might not be "standard" but it certainly had more users in its heyday than xslt ever did. Does removal of tls 1.1 count here? Its all kind of a matter of definitions. Personally i always thought the <keygen> tag was really cool.

chrismorgan 1y ago
XSLT is an integrated part of the web platform: browsers can load XML documents that use an XSLT stylesheet, and even inside HTML documents XSLTProcessor is available. FTP was never integrated: it just so happened that some platforms shipped a protocol handler for it, and some browsers included an FTP protocol handler themselves. But I don’t believe you could ever, say, fetch("ftp://…"). Flash, like applets, was even more clearly not part of the web platform. It was a popular third-party extension that you had to go out of your way to install… or wait for it to be installed by some shady installer Adobe paid off. Though I have a vague feeling Chrome shipped with Flash at some point? I don’t remember all the history any more, this is a long time ago. Older versions of TLS is definitely a more interesting case. It’s a different kind of feature, but… yeah, I might consider it. <keygen> was an interesting concept that in practice went nowhere.
- bawolff 1y ago
  > FTP was never integrated: it just so happened that some platforms shipped a protocol handler for it, and some browsers included an FTP protocol handler themselves. But I don’t believe you could ever, say, fetch("ftp://…"). I never tried, but i believe the relavent spec said it should work, until it was deprecated and removed from the standard https://github.com/whatwg/fetch/pull/1166 https://github.com/whatwg/fetch/pull/1166 With flash - that might all be true, but there was a time when many websites required it. It might not have been a de jure standard but it was a de facto standard. To the point where a browser not supporting it was considered broken. Apple refusing to support it was incredibly controversial at the time.

om2 1y ago

XSLT is also a really problematic feature from an implementation perspective (albeit in a different way than showModalDialog or MutationObservers). I’m not a Chrome dev but I think they have decent reasons for going this way.

sam_lowry_ 1y ago
1.1 is not that complex to implement
- om2 1y ago
  Implementing it without tons of security bugs is apparently pretty hard.

bartread 1y ago

Yeah… on the one hand I don’t care about XSLT, haven’t used it in more than 20 years, and never intend to use it again. On the other… I’m still a bit uncomfortable with the proposed change because it reads as another example of Google unilaterally dictating the future of the web, which I’ve never liked or supported. Feeling quite conflicted.

righthand 1y ago
"It didn't affect me so I didn't care." Is usually how control is amassed by Google (or authoritarians).
- bartread 1y ago
  Very fair point, and that cuts to the root of why I’m uncomfortable with it. I mean, presumably they have the usage stats… except that plenty of enterprises deployed XSLT apps back in the day - it was on a massive portion of the job ads I was looking at in 2000 to 2002 - and I’d bet a chunk of those legacy systems are still running. I’d also bet a good chunk of those systems are running in the sort of orgs that won’t allow submission of telemetry to Google, so Google’s usage stats underreport real world usage. To me it looks like zero effort has been made to engage with Mozilla, Apple, etc., on the right way forward here - just Google high-handedly making moves and abusing their position as per usual.
  - jsnell 1y ago
    > To me it looks like zero effort has been made to engage with Mozilla, Apple, etc., on the right way forward here - just Google high-handedly making moves and abusing their position as per usual. What would make you think that? The submission links prominently to the whatwg proposal github issue, which is the forum where that engagement would happen. It explicitly deep-links to Mozilla's and Apple's posts in that thread. It has the usage stats that you just presume exist. It's like you just made up a scenario and posted it as facts with zero effort to verify any of it.
spiffytech 1y ago

anal_reactor 1y ago

> As for things like Flash or FTP, those were never part of the web platform. Nor were they ever anything like universal anyway. Flash was the web technology.

chrismorgan 1y ago
The web technology… that didn’t come out of the box, wasn’t supported on all platforms, and didn’t integrate?