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…
Purely out of curiosity, what are some websites that actually make use of XSLT?
"Remove mentions of XSLT from the html spec"
291–300 of 559 posts
Re: "Remove mentions of XSLT from the html spec"
#292Re: "Remove mentions of XSLT from the html spec"
#293Earlier quoted context omitted.
My XSLT story: I wrote my personal website in XML with XSLT transforming into something viewable in the browser circa 2008. I was definitely inspired by CSS Zen Garden where the same HTML gave drastically different presentation with different CSS, but I thought that was too restrictive with too much overly tricky CSS. I thought the code would be more maintainable by writing XSLT transforms for different themes of my…
Another fellow soul! My first rewrite of my site, as I moved it away from Yahoo, into my own domain was also in XSLT/XML. Eventually I got tired of keeping it that way, and rewrite the parsing and HTML generation into PHP, but kept the site content in XML, to this day. Every now and then I think about rewriting it, but I rather do native development outside work, and don't suffer from either PHP nor XML allergies. Do…
Re: "Remove mentions of XSLT from the html spec"
#294Breaking the fundamental promise of the HTML spec is a big deal. The discussions don't address that. That surprises me, because these seem to be the people in charge of the spec. The promise is, "This is HTML. Count on it." Now it would be just, "This is HTML for now. Don't count on it staying that way, though." Not saying it should never be done, but it's a big deal. They are removing XSLT just for being a long-tail…
I get that people are more reacting to the prospect of browsers removing existing support, but I was pretty surprised by how short the PR was. I assumed it was more intertwined.
Re: "Remove mentions of XSLT from the html spec"
#295Re: "Remove mentions of XSLT from the html spec"
#296A 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…
The implementations are owned by the implementers. Who owns the actual standard, the implementers or the users?
Re: "Remove mentions of XSLT from the html spec"
#297Earlier quoted context omitted.
> This is actually not a bad idea. Why should the browser contain a specific template engine, like XSLT XSLT is a specification for a "template engine" and not a specific engine. There are dozens of XSLT implementations. Mozilla notably doesn't use libxslt but transformiix: https://web.mit.edu/ghudson/dev/nokrb/third/firefox/extensio... > and not Jinja for example? Jinja operates on text, so it's basically document.w…
> Sort of. JS is much slower than the native XSLT transform, and the XSLT result is cacheable. That's huge. Nobody is going to process million of DOM nodes with XSLT because the browser won't be able to display them anyway. And one can write a WASM implementation.
You're right nobody processes a million DOM nodes with XSLT in a browser, but you're wrong about everything else: WASM has a huge startup cost.
Consider applying stylesheet properties: XSLT knows exactly how to lay things out so it can put all of the stylesheet properties directly on the element. Pre-rendered HTML would be huge. CSS is slow. XSLT gets you direct-attach, small-payload, and low-latency display.
Re: "Remove mentions of XSLT from the html spec"
#298Breaking the fundamental promise of the HTML spec is a big deal. The discussions don't address that. That surprises me, because these seem to be the people in charge of the spec. The promise is, "This is HTML. Count on it." Now it would be just, "This is HTML for now. Don't count on it staying that way, though." Not saying it should never be done, but it's a big deal. They are removing XSLT just for being a long-tail…
There's a sweet spot between giving people enough time and tools to make a transition while also avoiding having your platform implode into a black hole of accumulated complexity. Neither end of the spectrum is healthy.
Re: "Remove mentions of XSLT from the html spec"
#299Earlier quoted context omitted.
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…
There is a better alternative to libxslt - xee[1][2]. It was discussed[3] on HN before. [1] https://blog.startifact.com/posts/xee/ [2] https://github.com/Paligo/xee [3] https://news.ycombinator.com/item?id=43502291
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.
Re: "Remove mentions of XSLT from the html spec"
#300Earlier quoted context omitted.
Ah right, so that wouldn't be affected by this change because it happens all server-side if I understand it correctly?
Looks like someone pointed out in the related thread yesterday[0] that this little known site[1] is using it for client-side templating. [0] https://news.ycombinator.com/item?id=44909599 [1] https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih....
(but I take your point that there exists at least government in the world that uses it)