5 ms·

This. If the WHATWG does not want to be brigaded while they destroy the web, they need to provide a clear venue for people to indicate whether or not the commun

This. If the WHATWG does not want to be brigaded while they destroy the web, they need to provide a clear venue for people to indicate whether or not the community is accepting of a change. The web is ours, not theirs. And I think we should rightfully set fire to the WHATWG's implementation discussions until they recognize that fact. One of the things I learned about Google during the AMP4Email fiasco is that the standards-development folks there... do not know the word no. There is no process to tell them that something should not be done. If you do, you broke the code of conduct, because they're Googlers and they Know Better. People like Mason Freed in the XSLT thread are sad that people trying to tell him no are getting in the way of him talking to people who will tell him yes. At the point where the courts have determined that Google abuses it's monopoly control of the web, honestly, there's a question why Google is involved in standards-setting as opposed to being relegated to an advisory position required to implement standards as-designed by everyone else.

deleted 1y ago
[deleted]
samdoesnothing 1y ago
> while they destroy the web Don't you think you're being a little bit dramatic? The chances of anybody who isn't an ubernerd caring about XSLT's removal is exactly 0.
- th0ma5 1y ago
  XSLT specifics? Yes, ubernerd ... Person who can't get a doctor's appointment because the interactive voice menu which is somehow now based on a browser engine and has a subtle bug caused by this change could be anyone.
  - joshuamorton 1y ago
    Is there some specific reason you think xslt removal is likely to cause this (because it is used in interactive voice menus)? Or is your complaint here reducible to "changes in browsers can cause bugs, and bugs can harm consumers" for which the solution is "browsers must never change anything", which is of course also harmful to consumers (like when an xslt parser bug is used to steal my bank details)
    - th0ma5 1y ago
      I have personally witnessed web technology related components in the critical path of complex enterprise insurance systems. Setting aside things like the whole of .NET being steeped in web browser components, and the added complexity of being forced to isolated these components by the court, things like Selenium are used for getting around integration and licensing problems. It isn't right, it isn't efficient, it will be a year long project to change them... We've already seen outages caused by XML engines dereferencing domains that aren't available anymore causing subtle and hard to find bugs. People don't realize that we built a lot of cool stuff on XML and semantic web stuff that all works and is all needed in various ways! It would not surprise me if web browser automation is not central to a ton of backend integration and automation for absolute sure.
      - joshuamorton 1y ago
        You understand that XSLT isn't xml, right? This change will probably have a 0% impact on selenium or similar browser automation.
        dragonwriter 1y ago
        > You understand that XSLT isn't xml, right? XSLT is XML, but XML isn't XSLT.
        th0ma5 1y ago
        Well they meant that I was conflating two things, and I was, because you can reference stylesheets to transform XML from one form to another, you can use it to render XML into HTML (or anything within limits), and that was the part that I was referring to specifically. That process can happen in a browser, on the command line, inside of Java dependency injection, build systems... It's in a lot of things because for what it is and what it can do it is pretty broadly applicable. It just isn't sexy front end or clear isolated backend so maybe that's the confusion here. I'm talking IBM, Oracle software acquired over decades from smaller companies that tried it all. And taking it out of a browser engine breaks these systems as well. A browser is used for testing, literal hack glue using tools like Selenium for systems integration, end users interacting with the system or administrators interacting with them... And again, some systems use browsers programmatically... XSLT is huge in mid 2000s report generation. The more I think about it, it does feel like a mini Y2K to touch the HTML rendering pipeline in this way. I think it could have subtle and hard to find consequences, and it doesn't feel extreme, maybe making a whole thread does about it though lol
  - bawolff 1y ago
    [flagged]
    - th0ma5 1y ago
      You can certainly use XSLT with https://www.w3.org/TR/voicexml20/ https://www.w3.org/TR/voicexml20/ have you built software on any Linux platform? XSLT is required in so much stuff.
      - bawolff 1y ago
        And did you render it in chrome? Nobody is killing xslt in general, just the web browser bindings.
        th0ma5 1y ago
        I mentioned it elsewhere but tons of enterprise backend automation and integration has web browsers and web browser components in the critical path, yes.
    - tomhow 1y ago
      Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes. When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
      - bawolff 1y ago
        That's fair. The better phrased version of my criticism is that voice menus are generally not rendered using a web browser and thus deprecating xslt in web browsers cannot possibly affect them.
th0ma5 1y ago
Some of what your saying could be confusion on the part of many people about what a standard is and isn't... And I think that while I don't necessarily agree that Google shouldn't be involved, I think this confusion is in the neighborhood of your concerns. It used to be much more the case, and indeed with other standards work it is the case, that a corporate entity was just another schmoe and people didn't necessarily have so much reflexive deference perhaps? Thank you for posting this honest opinion.
spankalee 1y ago
I think there's a fundamental misunderstanding of what standards are here. The web is what the engines implement and what sites use. Always has been. A standard that's not implemented isn't worth anything. Web standards exist to help browsers be interoperable. Before them one browser would implement something, and if another liked it they would too. That can still happen, but standards mediate the process to be less chaotic and more reliable. Web standards cannot force browsers to do anything. If a browser doesn't implement a standard - and there are lot of unimplemented "standards" out there - then it just doesn't. As a user then you have the choice to use browsers that offer better or different standards support. If you require XSLT support, and Firefox removes it, you can use Safari, or Chrome. If Chrome removes it, you can hopefully use an Blink engine that keeps the feature on (usually they're removed with a flag far before they're actually deleted with code). And this is the real problem with a lack of browser diversity: Users need to be able to vote with their feet. But... if all the vendors agree on something, as a user good luck with finding an alternative. I seriously doubt Opera, Brave, or Vivaldi is going to do the work and take the security risk to add back XSLT. Servo and Ladybird aren't going to come to the rescue here either. They most likely would love to have less to implement.
- ocdtrekkie 1y ago
  > A standard that's not implemented isn't worth anything I agree, but this is not about that. XSLT is implemented. Websites use it. I would argue the barrier to remove it should be incredibly high, not "we don't want to financially support the dude who maintains the library". Web standards should be close to permanent, which is why we should not add stupid ones left and right. The problem I have in particular with how Google uses it's incredible clout to mismanage the web is it actively chips away at the web's stability. The goofiness the CA/B is up to is similar: Over 80% of organizations have outages every year due to certificate issues, and some absolutely clueless folks think 47 day certificate lifetimes is a good decision. The web in 2025 is incredibly fragile, and all signs lead to Google continuing to try to make it more fragile. You could pull in dozens of examples of centralizing forces that ensure one engineer pushing a bad configuration at one company takes down 40% of the web. The Web is not Android. Apps on it should not break because you didn't submit a new version which updates to the latest platform framework within the last six months. Something on the web should, ideally, continue to work in perpetuity, unless acted on by an outside force (most likely by the site owner failing to continue paying the bill). XSLT exists, it's supported by every major browser right now, and it should be nearly illegal to remove it.
spankalee 1y ago
Also, Mason is one if the nicest guys I know, and this is his job. I really don't think he's sad about a bunch of people misinterpreting what's going on and freaking out about it.
bawolff 1y ago
> they need to provide a clear venue for people to indicate whether or not the community is accepting of a change. The venue is the right to fork. The standard is made by people who write code implementing web browsers. Rando freeloaders who don't put in the work don't get a vote. This is how the internet has always worked, to pataphrase a different standards body - running code and loose consensus.

deleted 1y ago

[deleted]

samdoesnothing 1y ago

> while they destroy the web Don't you think you're being a little bit dramatic? The chances of anybody who isn't an ubernerd caring about XSLT's removal is exactly 0.

th0ma5 1y ago
XSLT specifics? Yes, ubernerd ... Person who can't get a doctor's appointment because the interactive voice menu which is somehow now based on a browser engine and has a subtle bug caused by this change could be anyone.
- joshuamorton 1y ago
  Is there some specific reason you think xslt removal is likely to cause this (because it is used in interactive voice menus)? Or is your complaint here reducible to "changes in browsers can cause bugs, and bugs can harm consumers" for which the solution is "browsers must never change anything", which is of course also harmful to consumers (like when an xslt parser bug is used to steal my bank details)
  - th0ma5 1y ago
    I have personally witnessed web technology related components in the critical path of complex enterprise insurance systems. Setting aside things like the whole of .NET being steeped in web browser components, and the added complexity of being forced to isolated these components by the court, things like Selenium are used for getting around integration and licensing problems. It isn't right, it isn't efficient, it will be a year long project to change them... We've already seen outages caused by XML engines dereferencing domains that aren't available anymore causing subtle and hard to find bugs. People don't realize that we built a lot of cool stuff on XML and semantic web stuff that all works and is all needed in various ways! It would not surprise me if web browser automation is not central to a ton of backend integration and automation for absolute sure.
    - joshuamorton 1y ago
      You understand that XSLT isn't xml, right? This change will probably have a 0% impact on selenium or similar browser automation.
      - dragonwriter 1y ago
        > You understand that XSLT isn't xml, right? XSLT is XML, but XML isn't XSLT.
        th0ma5 1y ago
        Well they meant that I was conflating two things, and I was, because you can reference stylesheets to transform XML from one form to another, you can use it to render XML into HTML (or anything within limits), and that was the part that I was referring to specifically. That process can happen in a browser, on the command line, inside of Java dependency injection, build systems... It's in a lot of things because for what it is and what it can do it is pretty broadly applicable. It just isn't sexy front end or clear isolated backend so maybe that's the confusion here. I'm talking IBM, Oracle software acquired over decades from smaller companies that tried it all. And taking it out of a browser engine breaks these systems as well. A browser is used for testing, literal hack glue using tools like Selenium for systems integration, end users interacting with the system or administrators interacting with them... And again, some systems use browsers programmatically... XSLT is huge in mid 2000s report generation. The more I think about it, it does feel like a mini Y2K to touch the HTML rendering pipeline in this way. I think it could have subtle and hard to find consequences, and it doesn't feel extreme, maybe making a whole thread does about it though lol
- bawolff 1y ago
  [flagged]
  - th0ma5 1y ago
    You can certainly use XSLT with https://www.w3.org/TR/voicexml20/ https://www.w3.org/TR/voicexml20/ have you built software on any Linux platform? XSLT is required in so much stuff.
    - bawolff 1y ago
      And did you render it in chrome? Nobody is killing xslt in general, just the web browser bindings.
      - th0ma5 1y ago
        I mentioned it elsewhere but tons of enterprise backend automation and integration has web browsers and web browser components in the critical path, yes.
  - tomhow 1y ago
    Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes. When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
    - bawolff 1y ago
      That's fair. The better phrased version of my criticism is that voice menus are generally not rendered using a web browser and thus deprecating xslt in web browsers cannot possibly affect them.

th0ma5 1y ago

Some of what your saying could be confusion on the part of many people about what a standard is and isn't... And I think that while I don't necessarily agree that Google shouldn't be involved, I think this confusion is in the neighborhood of your concerns. It used to be much more the case, and indeed with other standards work it is the case, that a corporate entity was just another schmoe and people didn't necessarily have so much reflexive deference perhaps? Thank you for posting this honest opinion.

spankalee 1y ago

I think there's a fundamental misunderstanding of what standards are here. The web is what the engines implement and what sites use. Always has been. A standard that's not implemented isn't worth anything. Web standards exist to help browsers be interoperable. Before them one browser would implement something, and if another liked it they would too. That can still happen, but standards mediate the process to be less chaotic and more reliable. Web standards cannot force browsers to do anything. If a browser doesn't implement a standard - and there are lot of unimplemented "standards" out there - then it just doesn't. As a user then you have the choice to use browsers that offer better or different standards support. If you require XSLT support, and Firefox removes it, you can use Safari, or Chrome. If Chrome removes it, you can hopefully use an Blink engine that keeps the feature on (usually they're removed with a flag far before they're actually deleted with code). And this is the real problem with a lack of browser diversity: Users need to be able to vote with their feet. But... if all the vendors agree on something, as a user good luck with finding an alternative. I seriously doubt Opera, Brave, or Vivaldi is going to do the work and take the security risk to add back XSLT. Servo and Ladybird aren't going to come to the rescue here either. They most likely would love to have less to implement.

ocdtrekkie 1y ago
> A standard that's not implemented isn't worth anything I agree, but this is not about that. XSLT is implemented. Websites use it. I would argue the barrier to remove it should be incredibly high, not "we don't want to financially support the dude who maintains the library". Web standards should be close to permanent, which is why we should not add stupid ones left and right. The problem I have in particular with how Google uses it's incredible clout to mismanage the web is it actively chips away at the web's stability. The goofiness the CA/B is up to is similar: Over 80% of organizations have outages every year due to certificate issues, and some absolutely clueless folks think 47 day certificate lifetimes is a good decision. The web in 2025 is incredibly fragile, and all signs lead to Google continuing to try to make it more fragile. You could pull in dozens of examples of centralizing forces that ensure one engineer pushing a bad configuration at one company takes down 40% of the web. The Web is not Android. Apps on it should not break because you didn't submit a new version which updates to the latest platform framework within the last six months. Something on the web should, ideally, continue to work in perpetuity, unless acted on by an outside force (most likely by the site owner failing to continue paying the bill). XSLT exists, it's supported by every major browser right now, and it should be nearly illegal to remove it.

spankalee 1y ago

Also, Mason is one if the nicest guys I know, and this is his job. I really don't think he's sad about a bunch of people misinterpreting what's going on and freaking out about it.

bawolff 1y ago

> they need to provide a clear venue for people to indicate whether or not the community is accepting of a change. The venue is the right to fork. The standard is made by people who write code implementing web browsers. Rando freeloaders who don't put in the work don't get a vote. This is how the internet has always worked, to pataphrase a different standards body - running code and loose consensus.