Comment by xg15
3 months 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-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.
> 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.
This is breaking the web though.
If they are so worried, then have the xslt support compiled to wasm and sandboxed.
This is not breaking the web, stop being so needlessly hyperbolic. XSLT use is absolutely tiny. If you removed it, >99.9% of the web wouldn’t even notice.
3 replies →
Apart from that doesn’t really work for people who are statically hosting their RSS feeds etc.
You can use content negotiation with static websites too. Apache has mod_negotiation, for example.
3 replies →
I actually found that particular response to be quite disappointing. It should give pause to those advocating removal of XSLT that these three totally disparate use cases could already be gracefully handled by a single technology which is:
* side effect free (a pure data to data transformation)
* stable, from a spec perspective, for decades
* completely client-side
Isn't this basically an A+ report card for any attempt at making a powerful general tool? The fact that the suggested solution in the absence of XSLT is to toil away at implementing application-specific solutions forever really feels like working toward the wrong direction.
Purely out of curiosity, what are some websites that actually make use of XSLT?
Skechers used to :)
https://thedailywtf.com/articles/Sketchy-Skecherscom
Also world of warcraft used to.
Can’t think of recent examples though.
Many sitemaps and RSS feeds use XSL to seamlessly present human readable content.
Isn't this theoretically already supported by the standards? The client supplies an Accept content type, and if that is html not xml the server should render it appropriately.
You can include a "link" HTTP header similar to a link tag. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...
This would work without special syntax in the XML file.
Any solution that requires any change to the websites affected, no matter how small, is not a solution at all. DO. NOT. BREAK. THE. WEB.
Ah how easy is it to bloviate when you're not actually the one having to maintain the web, huh?
Google doesn't have to maintain the web, they chose to. They also chose to make the web infinitely more complicated so that others are less likely to "compete" for that responsibility. You don't get to insert yourself into that position and then only reap the benefits without putting int the required effort.