"Remove mentions of XSLT from the html spec"

Post by mananaysiempre » Tue, Aug 19, 2025, 5:28 PM UTC

spankalee wrote: post #127

spankalee wrote: post #92

A few things to note: - This isn't Chrome doing this unilaterally. 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-275... - You can see from the WHATNOT meeting agenda that it was a Mozilla engineer who brought it up last time. - Opening a…

Also, 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 exploi…

Post by cholantesh » Tue, Aug 19, 2025, 5:28 PM UTC

notatoad wrote: post #188

BoiledCabbage wrote: post #113

So if in reading the two threads correctly essentially Google asked for feedback, essentially all the feedback said "no, please don't". And they said "thanks for the feedback, we're gonna do it any way!"? The other suggestions ignored seemed to be "if this is about security, then fund the OSS, project. Or swap to a newer safer library, or pull it into the JS sandbox and ensure support is maintained." Which were all m…

>essentially all the feedback said "no, please don't". And they said "thanks for the feedback, we're gonna do it any way!"? this is a perfectly reasonable course of action if the feedback is "please don't" but the people saying "please don't" aren't people who are actually using it or who can explain why it's necessary. it's a request for feedback, not just a poll.

Post by youngtaff » Tue, Aug 19, 2025, 5:30 PM UTC

JimDabell wrote: post #237

xg15 wrote: post #214

Earlier quoted context omitted.

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-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 processing instruction that browsers would inter…

> I think this could be addressed by introducing a 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 indicati…

Post by tannhaeuser » Tue, Aug 19, 2025, 5:33 PM UTC

Post by LegionMammal978 » Tue, Aug 19, 2025, 5:34 PM UTC

intrasight wrote: post #180

LegionMammal978 wrote: post #159

Earlier quoted context omitted.

There's ways to reduce attack surface short of tearing out support. Such as, for instance, taking one of those alleged JS polyfills and plugging it into the browser, in place of all the C++. But if attack surface is your sole concern, then one of those options sounds much easier than the other, and also ever-so-slightly superior. In any case, there's no limit on how far one can disregard compatibility in the name of…

It is a balance (compatibility vs attach surfaces). The issue with XSLT (which I am still a strong advocate for) is that nobody is maintaining that code. So vulnerabilities sit there undetected. Like the relatively recent discovery of the xsl:document vulnerability.