7 ms·

A few things to note: - This isn't Chrome doing this unilaterally. https://github.com/whatwg/html/issues/11523 https://github.com/whatwg/html/issues/11523 show

A few things to note: - This isn't Chrome doing this unilaterally. https://github.com/whatwg/html/issues/11523 https://github.com/whatwg/html/issues/11523 shows that representatives from every browser are supportive and there have been discussions about this in standards meetings: https://github.com/whatwg/html/issues/11146#issuecomment-2759059949 https://github.com/whatwg/html/issues/11146#issuecomment-275... - You can see from the WHATNOT meeting agenda that it was a Mozilla engineer who brought it up last time. - Opening a PR doesn't necessarily mean that it'll be merged. Notice the unchecked tasks - there's a lot to still do on this one. Even so, give the cross-vendor support for this is seems likely to proceed at some point.

spankalee 1y ago
Also, https://github.com/whatwg/html/issues/11523 https://github.com/whatwg/html/issues/11523 (Should we remove XSLT from the web platform?) is not a request for community feedback. It's an issue open on the HTML spec for the HTML spec maintainers to consider. It was opened by a Chrome engineer after at least two meetings where a Mozilla engineer raised the topic, and where there was apparently vendor support for it. This is happening after some serious exploits were found: https://www.offensivecon.org/speakers/2025/ivan-fratric.html https://www.offensivecon.org/speakers/2025/ivan-fratric.html And the maintainer of libxslt has stepped down: https://gitlab.gnome.org/GNOME/libxml2/-/issues/913 https://gitlab.gnome.org/GNOME/libxml2/-/issues/913
- xg15 1y ago
  I think this discussion is quite reasonable, but it also highlights the power imbalance: If this stuff is decided in closed meetings and the bug trackers are not supposed to be places for community feedback, where can the community influence such decisions?
  - spankalee 1y ago
    Community feedback is usually very ad hoc. Platform PMs will work with major sites, framework maintainers, and sometimes do discussions and polls on social sites. IOW, they try to go where the community that uses the features are, rather than stay on GitHub in the spec issues.
    - deleted 1y ago
      [deleted]
    - NoGravitas 1y ago
      Although in this case, it seems more like they are trying to go where the community that uses the feature isn't.
  - sieabahlpark 1y ago
    [dead]
  - jchw 1y ago
    I think it depends on the spec. Some of the working groups still have mailing lists, some of them have GitHub issues. To be completely honest, though, I'm not sure what people expect to get out of it. I dug into this a while ago for a rather silly reason and I found that it's very inside baseball, and unless you really wanted to get invested in it it seems like it'd be hard to meaningfully contribute. To be honest if people are very upset about a feature that might be added or a feature that might be removed the right thing to do is probably to literally just raise it publicly, organize supporters and generally act in protest. Google may have a lot of control over the web, but note that WEI still didn't ship.
    - bawolff 1y ago
      If people are upset about xslt being removed, step 1 would have been to actually use it in a significant way on the web. Step 2 would have been to volunteer to maintain libxslt. Everyone likes to complain as a user of open source. Nobody likes to do the difficult work.
      - deleted 1y ago
        [deleted]
      - starkparker 1y ago
        Didn't someone step up to volunteer ot maintain libxslt a few weeks ago? https://gitlab.gnome.org/GNOME/libxslt/-/issues/150 https://gitlab.gnome.org/GNOME/libxslt/-/issues/150
        moomin 1y ago
        Knowing our luck it’s probably Jia Tan.
      - rendaw 1y ago
        I'm not that familiar with XSLT but isn't it already quite hobbled? Can it be used in a significant way? Or is this a chicken-egg problem where proving it's useful requires the implementation to be filled out first.
  - mr_toad 1y ago
    WhatWG has a fairly well documented process for feature requests. Issues are not usually decided in closed meetings. But there’s a difference between constructive discussion and the stubborn shameless entitlement that some members of the community are displaying in their comments. https://blog.whatwg.org/staged-proposals-at-the-whatwg https://blog.whatwg.org/staged-proposals-at-the-whatwg
    - troupo 1y ago
      No. WhatWG only has a process for adding and approving features. It has no process for discussing removal of features or for speaking out against a feature
  - 8NNTt8z3QvLT8tp 1y ago
    Fwiw the meetings aren't closed, unlike w3c the whatwg doesn't require paid membership to attend. The bug trackers are also a fine place to provide community feedback. For example there's plenty of comments providing use cases that weren't hidden. But if you read the hidden ones (especially on the issue rather than PR) there's some truly unhinged commentary that rightly resulted in being hidden and unfortunately locking of the thread. Ultimately the way the community can influence decisions is to not be completely unhinged. Like someone else said the other way would be to just use XSLT in the first place.
  - jerf 1y ago
    Honestly, your chance to impact this decision was when you decided what technologies to use on your website, and then statistically speaking [1], chose not to use XSLT in the browser. If the web used it like crazy we would not be having this conversation. Your other opportunity is to put together a credible plan to resource the XSLT implementations in the various browsers. I underline, highlight, bold, and italicize the word "credible" here. You are facing an extremely uphill battle from the visible lack of support for the development; any truly credible offer should have come many years ago. Big projects are well aware of the utility of last-minute, emotionally-driven offers of support in the midst of a burst of publicity, viz, effectively zero. I don't know that the power is as imbalanced as people think here so much as a very long and drawn out conversation has been had by the web as a whole, on the whole the web has agreed this is not a terribly useful technology by vast bulk of implementation work, and this is the final closing chapter where the browsers are basically implementing the will of the web. The standard for removal isn't "literally 0 usage in the entire world", and whatever the standard is, if XSLT isn't on the "remove" side of it, that would just be a sign it needs to be tuned up because XSLT is a complete non-entity on the web. If you are not feeling like your voice is being respected it's because it's one of literally millions upon millions; what do you expect? [1]: I know exceptions are reading this post, but you are exceptions. And not terribly common ones.
    - xg15 1y ago
      That's not completely wrong, but also misses some nuance. E.g. the thread mentions the fact that web support is still stuck at XSLT 1.0 as a reason for removal. But as far as I know, there were absolutely zero efforts by browser vendors before to support newer versions of the language, while there was enormous energy to improve JavaScript. I don't want to imply that if they had just added support for XSLT 3.0 then everyone would be using XSLT instead of JavaScript today and the latest SIMD optimizations of Chrome's XPath pipeline would make the HN front-page. The language is just too bad for that. But I think it's true that there exists a feedback loop: Browsers can and do influence how much a technology is adopted, by making the tech less or more painful to use. Then turning around and saying no one is using the tech, so we'll remove it, is a bit dishonest.
      - 1y ago
  - ttepasse 1y ago
    There isn't one. It's Google's web now. You should be thankful that you are still allowed to use it.
- xg15 1y ago
  I think this post is useful where the thread author proposed some solutions to the people affected: https://github.com/whatwg/html/issues/11523#issuecomment-3189298594 https://github.com/whatwg/html/issues/11523#issuecomment-318... The main thing that seems unaddressed is the UX if a user opens a direct link to an XML file and will now just see tag soup instead of the intended rendering. I think this could be addressed by introducing a <?human-readable ...some url...?> processing instruction that browsers would interpret like a meta tag redirect. Then sites that are interested could put that line at the top of their XML files and redirect to an alternative representation in HTML or even to a server-side or WASM-powered XSLT processor for the file. Sort of like an inverse of the <link rel="alternate" ...> solution that the post mentioned. The only thing this doesn't fix is sites that are abandoned and won't update or are part if embedded devices and can't update.
  - JimDabell 1y ago
    > I think this could be addressed by introducing a <?human-readable ...some url...?> processing instruction that browsers would interpret like a meta tag redirect. Then sites that are interested could put that line at the top of their XML files and redirect to an alternative representation in HTML or even to a server-side or WASM-powered XSLT processor for the file. HTTP has already had this since the 90s. Clients send the Accept HTTP header indicating which format they want and servers can respond with alternative representations. You can already respond with HTML for browsers and XML for other clients today. You don’t need the browser to know how to do the transformation.
    - youngtaff 1y ago
      Apart from that doesn’t really work for people who are statically hosting their RSS feeds etc.
      - JimDabell 1y ago
        You can use content negotiation with static websites too. Apache has mod_negotiation, for example.
- xvilka 1y ago
  There is a better alternative to libxslt - xee[1][2]. It was discussed[3] on HN before. [1] https://blog.startifact.com/posts/xee/ https://blog.startifact.com/posts/xee/ [2] https://github.com/Paligo/xee https://github.com/Paligo/xee [3] https://news.ycombinator.com/item?id=43502291 https://news.ycombinator.com/item?id=43502291
  - zetafunction 1y ago
    Disclaimer: I work on Chrome/Blink and I've also contributed a (very small) number of patches to libxml/libxslt. It's not just a matter of replacing the libxslt; libxslt integrates quite closely with libxml2. There's a fair amount of glue to bolt libxml2/libxslt on to Blink (and WebKit); I can't speak for Gecko. Even when there's no work on new XML/XSLT features, there's a passive cost to just having that glue code around since it adds quirks and special cases that otherwise wouldn't exist.
    - deleted 1y ago
      [deleted]
  - MallocVoidstar 1y ago
    > Xee implements modern versions of these specifications, rather than the versions released in 1999. My understanding is that browsers specifically use the 1999 version and changing this would break compat
    - colejohnson66 1y ago
      As if removing XSLT entirely won’t break back-compat?
    - jact 1y ago
      XSLT versions are backwards compatible.
- mananaysiempre 1y ago
  > [T]he maintainer of libxslt has stepped down: https://gitlab.gnome.org/GNOME/libxml2/-/issues/913 https://gitlab.gnome.org/GNOME/libxml2/-/issues/913 ... Largely because of lack of help from major users such as browsers.
  - zetafunction 1y ago
    Disclaimer: I work on Chrome and I have contributed a (very) small number of fixes to libxml2/libxslt for some of the recent security bugs. Speaking from personal experience, working on libxslt... not easy for many reasons beyond the complexity of XSLT itself. For instance: - libxslt is linked against by all sorts of random apps and changes to libxslt (and libxml2) must not break ABI compatibility. This often constrains the shape of possible patches, and makes it that much harder to write systemic fixes. - libxslt reaches into libxml and reuses fields in creative ways, e.g. libxml2's `xmlDoc` has a `compression` field that is ostensibly for storing the zlib compression level [1], but libxslt has co-opted it for a completely different purpose [2]. - There's a lot of missing institutional knowledge and no clear place to go for answers, e.g. what does a compile-time flag that guards "refactored parts of libxslt" [3] do exactly? [1] https://gitlab.gnome.org/GNOME/libxml2/-/blob/ca10c7d7b513f334ac52aff88c81661194d919a5/include/libxml/tree.h#L810 https://gitlab.gnome.org/GNOME/libxml2/-/blob/ca10c7d7b513f3... [2] https://gitlab.gnome.org/GNOME/libxslt/-/blob/841a1805a9a9aa959b4eb9c46ba56a84e17cf871/libxslt/variables.c#L166 https://gitlab.gnome.org/GNOME/libxslt/-/blob/841a1805a9a9aa... [3] https://gitlab.gnome.org/GNOME/libxslt/-/blob/841a1805a9a9aa959b4eb9c46ba56a84e17cf871/libxslt/xsltInternals.h#L80 https://gitlab.gnome.org/GNOME/libxslt/-/blob/841a1805a9a9aa...
    - ArchOversight 1y ago
      Sounds like libxslt needs more than just a small number of fixes, and it sounds like Google could be paying someone, like you, to help provide the necessary guidance and feedback to increase the usability and capabilities of the library and evolve it for the better. Instead Google and others just use it, and expect that any issues that come up to be immediately fixed by the one or two open source maintainers that happen to work on it in their spare time. The power imbalance must not be lost on you here... If you wanted to dive into what [3] does, you could do so, you could then document it, or refactor it so that it is more obvious, or remove the compile time flag entirely. There is institutional knowledge everywhere...
kg 1y ago
Former Mozilla and Google (Chrome team specifically) dev here. The way I see what you're saying is: Representatives from Chrome/Blink, Safari/Webkit, and Firefox/Gecko are all supportive of removing XSLT from the web platform, regardless of whether it's still being used. It's okay because someone from Mozilla brought it up. Out of those three projects, two are notoriously under-resourced, and one is notorious for constantly ramming through new features at a pace the other two projects can't or won't keep up with. Why wouldn't the overworked/underresourced Safari and Firefox people want an excuse to have less work to do? This appeal to authority doesn't hold water for me because the important question is not 'do people with specific priorities think this is a good idea' but instead 'will this idea negatively impact the web platform and its billions of users'. Out of those billions of users it's quite possible a sizable number of them rely on XSLT, and in my reading around this issue I haven't seen concrete data supporting that nobody uses XSLT. If nobody really used it there wouldn't be a need for that polyfill. Fundamentally the question that should be asked here is: Billions of people use the web every day, which means they're relying on technologies like HTML, CSS, XML, XSLT, etc. Are we okay with breaking something that 0.1% of users rely on? If we are, okay, but who's going to tell that 0.1% of a billion people that they don't matter? The argument I've seen made is that Google doesn't have the resources (somehow) to maintain XSLT support. One of the googlers argued that new emerging web APIs are more popular, and thus more deserving of resources. So what we've created is a zero-sum game where any new feature added to the platform requires the removal of an existing feature. Where does that game end? Will we eventually remove ARIA and/or screen reader support because it's not used by enough people? I think all three browser vendors have a duty to their users to support them to the best of their ability, and Google has the financial and human resources to support users of XSLT and is choosing not to.
- segmondy 1y ago
  By your argument, once anything makes it in, then it can't be removed. Billions of people are going to use the web every day and it won't stop. Even the most obscure feature will end up being used by 0.1% of users. Can you name a feature that's supported by all browsers that's not being used by anyone?
  - 1y ago
otterley 1y ago
Also, according to Chrome's telemetry, very, very few websites are using it in practice. It's not like the proposal is threatening to make some significant portion of the web inaccessible. At least we can see the data underlying the proposal here.
- intrasight 1y ago
  Sadly, I just built a web site with HTMX and am using the client-side-templates extension for client-side XSLT. >very, very few websites Doesn't include all the corporate web sites that they are probably blocked from getting such telemetry for. These are the users that are pushing back.
  - strawhatguy 1y ago
    Does that library use the browser's xslt? I'm curious as to the scope of the problem, if html spec drops xslt, what the solutions would be; I've never really used xslt (once maybe, 20 years ago). In addition to just pre-rendering your webpage server-side, I assume another possible solution is some javascript library that does the transformations, if it needed to be client-side? Found a js-only library, so someone has done this before: https://www.npmjs.com/package/xslt-processor https://www.npmjs.com/package/xslt-processor
- mhitza 1y ago
  Looking at the problem differently. Say some change would make Hacker News unusable, the data would support this and show that it practically affects no one.
  - otterley 1y ago
    First, we are an insignificant portion of the web, and it's okay to admit that. Second, if HN were built upon outdated Web standards practically nobody else uses, I'm sure YCombinator could address the issue before the deadline (which would probably be at least a year or two out) to meet the needs of its community. Every plant needs nourishment to survive.
upofadown 1y ago
The implementations are owned by the implementers. Who owns the actual standard, the implementers or the users?
- solardev 1y ago
  I think trying to own a web standard is like trying to own a prayer. You can believe all you want, but it's up to the gods to listen or not...
- mr_toad 1y ago
  Own is not really the right word for an open source project. In practice it is controlled by Apple, Google, Microsoft and Mozilla.
- tsimionescu 1y ago
  As for any standard, the implementers ultimately own it. Users don't spend resources on implementing standards, so they only get a marginal say. Do you expect to contribute to the 6G standards, or USB-C, too?
thanhhaimai 1y ago
The responses of some folks on this thread reminds me of this: https://xkcd.com/1172/ https://xkcd.com/1172/
- jmull 1y ago
  That's more a joke about people coming to rely on any observable behavior of something, no matter how buggy or unintentional. Here's we're talking about killing off XSLT used in the intended, documented, standard way.
dang 1y ago
Ok thanks, we've dechromed the title above. (Submitted title was "Chrome intends to remove XSLT from the HTML spec".)
troupo 1y ago
> Even so, give the cross-vendor support for this is seems likely to proceed at some point. Yup. Just like the removal of confirm/prompt that had vendor support and was immediately rushed. Thankfully to be indefinitely postponed. Here's Google's own doc on how a feature should be removed: https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?usp=drivesdk https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS... Notice how "unilateral support by browser vendors" didn't even look at actual usage of XSLT, where it's used, and whether significant parts would be affected. Good times.

spankalee 1y ago

Also, https://github.com/whatwg/html/issues/11523 https://github.com/whatwg/html/issues/11523 (Should we remove XSLT from the web platform?) is not a request for community feedback. It's an issue open on the HTML spec for the HTML spec maintainers to consider. It was opened by a Chrome engineer after at least two meetings where a Mozilla engineer raised the topic, and where there was apparently vendor support for it. This is happening after some serious exploits were found: https://www.offensivecon.org/speakers/2025/ivan-fratric.html https://www.offensivecon.org/speakers/2025/ivan-fratric.html And the maintainer of libxslt has stepped down: https://gitlab.gnome.org/GNOME/libxml2/-/issues/913 https://gitlab.gnome.org/GNOME/libxml2/-/issues/913

xg15 1y ago
I think this discussion is quite reasonable, but it also highlights the power imbalance: If this stuff is decided in closed meetings and the bug trackers are not supposed to be places for community feedback, where can the community influence such decisions?
- spankalee 1y ago
  Community feedback is usually very ad hoc. Platform PMs will work with major sites, framework maintainers, and sometimes do discussions and polls on social sites. IOW, they try to go where the community that uses the features are, rather than stay on GitHub in the spec issues.
  - deleted 1y ago
    [deleted]
  - NoGravitas 1y ago
    Although in this case, it seems more like they are trying to go where the community that uses the feature isn't.
- sieabahlpark 1y ago
  [dead]
- jchw 1y ago
  I think it depends on the spec. Some of the working groups still have mailing lists, some of them have GitHub issues. To be completely honest, though, I'm not sure what people expect to get out of it. I dug into this a while ago for a rather silly reason and I found that it's very inside baseball, and unless you really wanted to get invested in it it seems like it'd be hard to meaningfully contribute. To be honest if people are very upset about a feature that might be added or a feature that might be removed the right thing to do is probably to literally just raise it publicly, organize supporters and generally act in protest. Google may have a lot of control over the web, but note that WEI still didn't ship.
  - bawolff 1y ago
    If people are upset about xslt being removed, step 1 would have been to actually use it in a significant way on the web. Step 2 would have been to volunteer to maintain libxslt. Everyone likes to complain as a user of open source. Nobody likes to do the difficult work.
    - deleted 1y ago
      [deleted]
    - starkparker 1y ago
      Didn't someone step up to volunteer ot maintain libxslt a few weeks ago? https://gitlab.gnome.org/GNOME/libxslt/-/issues/150 https://gitlab.gnome.org/GNOME/libxslt/-/issues/150
      - moomin 1y ago
        Knowing our luck it’s probably Jia Tan.
    - rendaw 1y ago
      I'm not that familiar with XSLT but isn't it already quite hobbled? Can it be used in a significant way? Or is this a chicken-egg problem where proving it's useful requires the implementation to be filled out first.
- mr_toad 1y ago
  WhatWG has a fairly well documented process for feature requests. Issues are not usually decided in closed meetings. But there’s a difference between constructive discussion and the stubborn shameless entitlement that some members of the community are displaying in their comments. https://blog.whatwg.org/staged-proposals-at-the-whatwg https://blog.whatwg.org/staged-proposals-at-the-whatwg
  - troupo 1y ago
    No. WhatWG only has a process for adding and approving features. It has no process for discussing removal of features or for speaking out against a feature
- 8NNTt8z3QvLT8tp 1y ago
  Fwiw the meetings aren't closed, unlike w3c the whatwg doesn't require paid membership to attend. The bug trackers are also a fine place to provide community feedback. For example there's plenty of comments providing use cases that weren't hidden. But if you read the hidden ones (especially on the issue rather than PR) there's some truly unhinged commentary that rightly resulted in being hidden and unfortunately locking of the thread. Ultimately the way the community can influence decisions is to not be completely unhinged. Like someone else said the other way would be to just use XSLT in the first place.
- jerf 1y ago
  Honestly, your chance to impact this decision was when you decided what technologies to use on your website, and then statistically speaking [1], chose not to use XSLT in the browser. If the web used it like crazy we would not be having this conversation. Your other opportunity is to put together a credible plan to resource the XSLT implementations in the various browsers. I underline, highlight, bold, and italicize the word "credible" here. You are facing an extremely uphill battle from the visible lack of support for the development; any truly credible offer should have come many years ago. Big projects are well aware of the utility of last-minute, emotionally-driven offers of support in the midst of a burst of publicity, viz, effectively zero. I don't know that the power is as imbalanced as people think here so much as a very long and drawn out conversation has been had by the web as a whole, on the whole the web has agreed this is not a terribly useful technology by vast bulk of implementation work, and this is the final closing chapter where the browsers are basically implementing the will of the web. The standard for removal isn't "literally 0 usage in the entire world", and whatever the standard is, if XSLT isn't on the "remove" side of it, that would just be a sign it needs to be tuned up because XSLT is a complete non-entity on the web. If you are not feeling like your voice is being respected it's because it's one of literally millions upon millions; what do you expect? [1]: I know exceptions are reading this post, but you are exceptions. And not terribly common ones.
  - xg15 1y ago
    That's not completely wrong, but also misses some nuance. E.g. the thread mentions the fact that web support is still stuck at XSLT 1.0 as a reason for removal. But as far as I know, there were absolutely zero efforts by browser vendors before to support newer versions of the language, while there was enormous energy to improve JavaScript. I don't want to imply that if they had just added support for XSLT 3.0 then everyone would be using XSLT instead of JavaScript today and the latest SIMD optimizations of Chrome's XPath pipeline would make the HN front-page. The language is just too bad for that. But I think it's true that there exists a feedback loop: Browsers can and do influence how much a technology is adopted, by making the tech less or more painful to use. Then turning around and saying no one is using the tech, so we'll remove it, is a bit dishonest.
    - 1y ago
- ttepasse 1y ago
  There isn't one. It's Google's web now. You should be thankful that you are still allowed to use it.
xg15 1y ago
I think this post is useful where the thread author proposed some solutions to the people affected: https://github.com/whatwg/html/issues/11523#issuecomment-3189298594 https://github.com/whatwg/html/issues/11523#issuecomment-318... The main thing that seems unaddressed is the UX if a user opens a direct link to an XML file and will now just see tag soup instead of the intended rendering. I think this could be addressed by introducing a <?human-readable ...some url...?> processing instruction that browsers would interpret like a meta tag redirect. Then sites that are interested could put that line at the top of their XML files and redirect to an alternative representation in HTML or even to a server-side or WASM-powered XSLT processor for the file. Sort of like an inverse of the <link rel="alternate" ...> solution that the post mentioned. The only thing this doesn't fix is sites that are abandoned and won't update or are part if embedded devices and can't update.
- JimDabell 1y ago
  > I think this could be addressed by introducing a <?human-readable ...some url...?> processing instruction that browsers would interpret like a meta tag redirect. Then sites that are interested could put that line at the top of their XML files and redirect to an alternative representation in HTML or even to a server-side or WASM-powered XSLT processor for the file. HTTP has already had this since the 90s. Clients send the Accept HTTP header indicating which format they want and servers can respond with alternative representations. You can already respond with HTML for browsers and XML for other clients today. You don’t need the browser to know how to do the transformation.
  - youngtaff 1y ago
    Apart from that doesn’t really work for people who are statically hosting their RSS feeds etc.
    - JimDabell 1y ago
      You can use content negotiation with static websites too. Apache has mod_negotiation, for example.
xvilka 1y ago
There is a better alternative to libxslt - xee[1][2]. It was discussed[3] on HN before. [1] https://blog.startifact.com/posts/xee/ https://blog.startifact.com/posts/xee/ [2] https://github.com/Paligo/xee https://github.com/Paligo/xee [3] https://news.ycombinator.com/item?id=43502291 https://news.ycombinator.com/item?id=43502291
- zetafunction 1y ago
  Disclaimer: I work on Chrome/Blink and I've also contributed a (very small) number of patches to libxml/libxslt. It's not just a matter of replacing the libxslt; libxslt integrates quite closely with libxml2. There's a fair amount of glue to bolt libxml2/libxslt on to Blink (and WebKit); I can't speak for Gecko. Even when there's no work on new XML/XSLT features, there's a passive cost to just having that glue code around since it adds quirks and special cases that otherwise wouldn't exist.
  - deleted 1y ago
    [deleted]
- MallocVoidstar 1y ago
  > Xee implements modern versions of these specifications, rather than the versions released in 1999. My understanding is that browsers specifically use the 1999 version and changing this would break compat
  - colejohnson66 1y ago
    As if removing XSLT entirely won’t break back-compat?
  - jact 1y ago
    XSLT versions are backwards compatible.
mananaysiempre 1y ago
> [T]he maintainer of libxslt has stepped down: https://gitlab.gnome.org/GNOME/libxml2/-/issues/913 https://gitlab.gnome.org/GNOME/libxml2/-/issues/913 ... Largely because of lack of help from major users such as browsers.
- zetafunction 1y ago
  Disclaimer: I work on Chrome and I have contributed a (very) small number of fixes to libxml2/libxslt for some of the recent security bugs. Speaking from personal experience, working on libxslt... not easy for many reasons beyond the complexity of XSLT itself. For instance: - libxslt is linked against by all sorts of random apps and changes to libxslt (and libxml2) must not break ABI compatibility. This often constrains the shape of possible patches, and makes it that much harder to write systemic fixes. - libxslt reaches into libxml and reuses fields in creative ways, e.g. libxml2's `xmlDoc` has a `compression` field that is ostensibly for storing the zlib compression level [1], but libxslt has co-opted it for a completely different purpose [2]. - There's a lot of missing institutional knowledge and no clear place to go for answers, e.g. what does a compile-time flag that guards "refactored parts of libxslt" [3] do exactly? [1] https://gitlab.gnome.org/GNOME/libxml2/-/blob/ca10c7d7b513f334ac52aff88c81661194d919a5/include/libxml/tree.h#L810 https://gitlab.gnome.org/GNOME/libxml2/-/blob/ca10c7d7b513f3... [2] https://gitlab.gnome.org/GNOME/libxslt/-/blob/841a1805a9a9aa959b4eb9c46ba56a84e17cf871/libxslt/variables.c#L166 https://gitlab.gnome.org/GNOME/libxslt/-/blob/841a1805a9a9aa... [3] https://gitlab.gnome.org/GNOME/libxslt/-/blob/841a1805a9a9aa959b4eb9c46ba56a84e17cf871/libxslt/xsltInternals.h#L80 https://gitlab.gnome.org/GNOME/libxslt/-/blob/841a1805a9a9aa...
  - ArchOversight 1y ago
    Sounds like libxslt needs more than just a small number of fixes, and it sounds like Google could be paying someone, like you, to help provide the necessary guidance and feedback to increase the usability and capabilities of the library and evolve it for the better. Instead Google and others just use it, and expect that any issues that come up to be immediately fixed by the one or two open source maintainers that happen to work on it in their spare time. The power imbalance must not be lost on you here... If you wanted to dive into what [3] does, you could do so, you could then document it, or refactor it so that it is more obvious, or remove the compile time flag entirely. There is institutional knowledge everywhere...

kg 1y ago

Former Mozilla and Google (Chrome team specifically) dev here. The way I see what you're saying is: Representatives from Chrome/Blink, Safari/Webkit, and Firefox/Gecko are all supportive of removing XSLT from the web platform, regardless of whether it's still being used. It's okay because someone from Mozilla brought it up. Out of those three projects, two are notoriously under-resourced, and one is notorious for constantly ramming through new features at a pace the other two projects can't or won't keep up with. Why wouldn't the overworked/underresourced Safari and Firefox people want an excuse to have less work to do? This appeal to authority doesn't hold water for me because the important question is not 'do people with specific priorities think this is a good idea' but instead 'will this idea negatively impact the web platform and its billions of users'. Out of those billions of users it's quite possible a sizable number of them rely on XSLT, and in my reading around this issue I haven't seen concrete data supporting that nobody uses XSLT. If nobody really used it there wouldn't be a need for that polyfill. Fundamentally the question that should be asked here is: Billions of people use the web every day, which means they're relying on technologies like HTML, CSS, XML, XSLT, etc. Are we okay with breaking something that 0.1% of users rely on? If we are, okay, but who's going to tell that 0.1% of a billion people that they don't matter? The argument I've seen made is that Google doesn't have the resources (somehow) to maintain XSLT support. One of the googlers argued that new emerging web APIs are more popular, and thus more deserving of resources. So what we've created is a zero-sum game where any new feature added to the platform requires the removal of an existing feature. Where does that game end? Will we eventually remove ARIA and/or screen reader support because it's not used by enough people? I think all three browser vendors have a duty to their users to support them to the best of their ability, and Google has the financial and human resources to support users of XSLT and is choosing not to.

segmondy 1y ago
By your argument, once anything makes it in, then it can't be removed. Billions of people are going to use the web every day and it won't stop. Even the most obscure feature will end up being used by 0.1% of users. Can you name a feature that's supported by all browsers that's not being used by anyone?
- 1y ago

otterley 1y ago

Also, according to Chrome's telemetry, very, very few websites are using it in practice. It's not like the proposal is threatening to make some significant portion of the web inaccessible. At least we can see the data underlying the proposal here.

intrasight 1y ago
Sadly, I just built a web site with HTMX and am using the client-side-templates extension for client-side XSLT. >very, very few websites Doesn't include all the corporate web sites that they are probably blocked from getting such telemetry for. These are the users that are pushing back.
- strawhatguy 1y ago
  Does that library use the browser's xslt? I'm curious as to the scope of the problem, if html spec drops xslt, what the solutions would be; I've never really used xslt (once maybe, 20 years ago). In addition to just pre-rendering your webpage server-side, I assume another possible solution is some javascript library that does the transformations, if it needed to be client-side? Found a js-only library, so someone has done this before: https://www.npmjs.com/package/xslt-processor https://www.npmjs.com/package/xslt-processor
mhitza 1y ago
Looking at the problem differently. Say some change would make Hacker News unusable, the data would support this and show that it practically affects no one.
- otterley 1y ago
  First, we are an insignificant portion of the web, and it's okay to admit that. Second, if HN were built upon outdated Web standards practically nobody else uses, I'm sure YCombinator could address the issue before the deadline (which would probably be at least a year or two out) to meet the needs of its community. Every plant needs nourishment to survive.

upofadown 1y ago

The implementations are owned by the implementers. Who owns the actual standard, the implementers or the users?

solardev 1y ago
I think trying to own a web standard is like trying to own a prayer. You can believe all you want, but it's up to the gods to listen or not...
mr_toad 1y ago
Own is not really the right word for an open source project. In practice it is controlled by Apple, Google, Microsoft and Mozilla.
tsimionescu 1y ago
As for any standard, the implementers ultimately own it. Users don't spend resources on implementing standards, so they only get a marginal say. Do you expect to contribute to the 6G standards, or USB-C, too?

thanhhaimai 1y ago

The responses of some folks on this thread reminds me of this: https://xkcd.com/1172/ https://xkcd.com/1172/

jmull 1y ago
That's more a joke about people coming to rely on any observable behavior of something, no matter how buggy or unintentional. Here's we're talking about killing off XSLT used in the intended, documented, standard way.

dang 1y ago

Ok thanks, we've dechromed the title above. (Submitted title was "Chrome intends to remove XSLT from the HTML spec".)

troupo 1y ago

> Even so, give the cross-vendor support for this is seems likely to proceed at some point. Yup. Just like the removal of confirm/prompt that had vendor support and was immediately rushed. Thankfully to be indefinitely postponed. Here's Google's own doc on how a feature should be removed: https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?usp=drivesdk https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS... Notice how "unilateral support by browser vendors" didn't even look at actual usage of XSLT, where it's used, and whether significant parts would be affected. Good times.