6 ms·

To those who saw a chrome.com link and got triggered: > The Firefox[^0] and WebKit[^1] projects have also indicated plans to remove XSLT from their browser eng

To those who saw a chrome.com link and got triggered: > The Firefox[^0] and WebKit[^1] projects have also indicated plans to remove XSLT from their browser engines. [^0]: https://github.com/mozilla/standards-positions/issues/1287#issuecomment-3227145793 https://github.com/mozilla/standards-positions/issues/1287#i... [^1]: https://github.com/whatwg/html/issues/11523#issuecomment-3149280766 https://github.com/whatwg/html/issues/11523#issuecomment-314...

righthand 11mo ago
In my opinion this is not “we agree lets remove it”. This is “we agree to explore the idea”. Google and Freed using this as a go ahead because the Mozilla guy pasted a pollyfill. However it is very clearly NOT an endorsement to remove it, even though bad actors are stating so. > Our position is that it would be good for the long-term health of the web platform and good for user security to remove XSLT, and we support Chromium's effort to find out if it would be web compatible to remove support1. If it turns out that it's not possible to remove support, then we think browsers should make an effort to improve the fundamental security properties of XSLT even at the cost of performance. Freed et al also explicitly chose to ignore user feedback for their own decision and not even try to improve XSLT security issues at the cost of performance.
- TingPing 11mo ago
  Last I heard for WebKit removing it was the only outcome they saw.
  - righthand 11mo ago
    Yeah all these billion dollar corporations that can’t be bothered see it as the only path forward not because of technological or practical issues, but because none of them can be asked to give a shit and plan it into their budgets. They’re MBAs who only know how to destroy and consolidate as trained.
    - TingPing 11mo ago
      I get the frustration but I don’t believe that’s really accurate. It’s not widely used and modern developers don’t see it as valuable.
      - righthand 11mo ago
        I’m a modern developer and I see it as valuable. Why side with the browser teams and ignoring user feedback? If “modern developers” actually spent time with it, they’d find it valuable. Modern developers are idiots if their constant cry is “just write it in JS”. No idea what’s inaccurate about this. A billion dollar company that has no problem pivoting otherwise, can’t fund open technology “because budgets” is simply a lie.
        shadowgovt 11mo ago
        The dominant user feedback is the hard statistics on how rarely it's used. You can't trim the space of "users" to just "people who already adopted the technology" in the context of the cost of browser support.
        dpark 11mo ago
        “Everyone who uses the blink tag agrees it’s critical functionality.”
        righthand 11mo ago
        Yes excellent way to continue to diminish users of tech you don’t agree with. “The people who actually use it are wrong and don’t matter!”
        shadowgovt 11mo ago
        I'm not personally in the business of maintaining a browser. But if I were, and I were looking to decrease cost of maintenance, "This entire rendering framework that supports a 0.02% use case" would be an outlier for chopping-block consideration. Not all corner-case features match that combination of cost-to-maintain and adoption (after, what, decades at this point?). We wouldn't be arguing the point if the feature in question were fax machine support, right?

righthand 11mo ago

In my opinion this is not “we agree lets remove it”. This is “we agree to explore the idea”. Google and Freed using this as a go ahead because the Mozilla guy pasted a pollyfill. However it is very clearly NOT an endorsement to remove it, even though bad actors are stating so. > Our position is that it would be good for the long-term health of the web platform and good for user security to remove XSLT, and we support Chromium's effort to find out if it would be web compatible to remove support1. If it turns out that it's not possible to remove support, then we think browsers should make an effort to improve the fundamental security properties of XSLT even at the cost of performance. Freed et al also explicitly chose to ignore user feedback for their own decision and not even try to improve XSLT security issues at the cost of performance.

TingPing 11mo ago
Last I heard for WebKit removing it was the only outcome they saw.
- righthand 11mo ago
  Yeah all these billion dollar corporations that can’t be bothered see it as the only path forward not because of technological or practical issues, but because none of them can be asked to give a shit and plan it into their budgets. They’re MBAs who only know how to destroy and consolidate as trained.
  - TingPing 11mo ago
    I get the frustration but I don’t believe that’s really accurate. It’s not widely used and modern developers don’t see it as valuable.
    - righthand 11mo ago
      I’m a modern developer and I see it as valuable. Why side with the browser teams and ignoring user feedback? If “modern developers” actually spent time with it, they’d find it valuable. Modern developers are idiots if their constant cry is “just write it in JS”. No idea what’s inaccurate about this. A billion dollar company that has no problem pivoting otherwise, can’t fund open technology “because budgets” is simply a lie.
      - shadowgovt 11mo ago
        The dominant user feedback is the hard statistics on how rarely it's used. You can't trim the space of "users" to just "people who already adopted the technology" in the context of the cost of browser support.
        dpark 11mo ago
        “Everyone who uses the blink tag agrees it’s critical functionality.”
        righthand 11mo ago
        Yes excellent way to continue to diminish users of tech you don’t agree with. “The people who actually use it are wrong and don’t matter!”
        shadowgovt 11mo ago
        I'm not personally in the business of maintaining a browser. But if I were, and I were looking to decrease cost of maintenance, "This entire rendering framework that supports a 0.02% use case" would be an outlier for chopping-block consideration. Not all corner-case features match that combination of cost-to-maintain and adoption (after, what, decades at this point?). We wouldn't be arguing the point if the feature in question were fax machine support, right?