41–50 of 559 posts
Despite rather heated discussion just three weeks they started just two weeks prior https://github.com/whatwg/html/issues/11523
i thought that HTML spec is immutable.
Which Chrome has transmuted into "we do whatever we want to do". Remember their attempt to remove confirm/prompt?
I had no idea what XSLT even was until today. Reading the submission, the thread linked by u/troupo below, and Wikipedia, I find that it's apparently used in RSS parsing by browsers, because RSS is XML and then XSLT is "originally designed for transforming XML documents into other XML documents" so it can turn the XML feed into an HTML page I agree RSS parsing is nice to have built into browsers. (Just like FTP suppo…
Chrome is a browser – it can’t remove something from the spec. Perhaps this should say Google proposes to remove it from the spec.
That being said, I'm not against removing features but neither this or the original post provide any substantial rationale on why it should be removed. Uses for XSLT do exist and the alternative is "just polyfill it" which is awkward especially for legacy content.
I love how one company can do whatever they want. This is perfect.
This proposal seems to be aimed at removing native support in favor of a WASM-based polyfill (like PDF.js, I guess) which seems reasonable? Google definitely throws its weight around too much w.r.t. to web standards, but this doesn't seem too bad. Web specifications are huge and complex so trying to size down a little bit while maintaining support for existing sites is okay IMO.
Last I checked, it’s a polyfill that Chrome won’t default include - they’re just saying that they’d have a polyfill in JS and it’s on site authors to use. That breaks old unmaintained but still valuable sites.
I completely understand the security and maintenance burdens that they're bringing up but breaking sites would be unacceptable.
This proposal seems to be aimed at removing native support in favor of a WASM-based polyfill (like PDF.js, I guess) which seems reasonable? Google definitely throws its weight around too much w.r.t. to web standards, but this doesn't seem too bad. Web specifications are huge and complex so trying to size down a little bit while maintaining support for existing sites is okay IMO.
Earlier quoted context omitted.
> It’s another “we listened the community and nobody told us no” moment. Like Go’s telemetry issue. Go changed their telemetry to opt-in based on community feedback, so I'm not sure what point you're trying to make with that example.
No. The official statement from Brian was “I received a couple of personal e-mails from some credible people who stated that their data belonged to them, so we (I) decided to make it opt-in” (paraphrased). I spent days in that thread. That uproar was “a bunch of noisy minority which doesn’t worth listening” for them.
So the libxml/libxslt unpaid volunteer maintainer wants to stop doing 'disclosure embargo' of reported security issues: https://gitlab.gnome.org/GNOME/libxml2/-/issues/913 Shortly after that, Google Chrome want to remove XSLT support.
Coincidence?
Source (yawaramin): https://news.ycombinator.com/item?id=44925104
PS: Seems libxslt which is used by Blink has an (unpaid) maintainer but nothing going on there really, seems pretty unmaintained https://gitlab.gnome.org/GNOME/libxslt/-/commits/master?ref_...
PS2: Reminds me all of this https://xkcd.com/2347/ A shame that libxml and libxslt could not get more support while used everywhere. Thanks for all the hard work to the unpaid volunteers!
Previously: Should we remove XSLT from the web platform? – 4 days ago (89 comments): https://news.ycombinator.com/item?id=44909599 XSLT – Native, zero-config build system for the Web – 27th June 2025 (328 comments): https://news.ycombinator.com/item?id=44393817
Also related, now flagged: https://news.ycombinator.com/item?id=44949857 Google is killing the open web, today, 127 comments