Live data from Hacker News

"Remove mentions of XSLT from the html spec"

github.com

301–310 of 559 posts

Re: "Remove mentions of XSLT from the html spec"

#301
post #52

Earlier quoted context omitted.

RSS likely isn't the only thing that uses it. XSLT is basically the client side declarative template language for XML/HTML that people always complain doesn't exist (e.g. letting you create your own tags or do includes with no server or build steps).

I understand that there are more possible uses for the tool, but RSS is the only one I saw someone mention. Are there more examples? It may be that I don't notice when I use it, if the page just translates itself into XHTML and I would never know until opening the developer tools (which I do often, fwiw: so many web forms are broken that I have a habit of opening F12, so I always still have my form entries in the net…

> Are there more examples?

Practically every WordPress site with one of the top two SEO plugins (I'm not familiar with others) serves XML sitemaps with XSLT. It's used to make the XML contents human readable and to add a header explaining what it is.

Re: "Remove mentions of XSLT from the html spec"

#302
post #178

Earlier quoted context omitted.

I kind of agree that little used,[0] non-web-like features is fair to be considered for removal. However I wish they didn't hide behind security vulnerabilities as the reason as that clearly wasn't it. The author didn't even bother to look if a memory safe package existed. "We're removing this for your own good" is the worst way to go about it but he still doubles down on this idea later in the thread. [0] ~0.001% us…

> [0] ~0.001% usage according to one post there This is still a massive number of people who are going to be affected by this. https://news.ycombinator.com/item?id=44938747

I get what you're saying, but following this line of reasoning would mean that successful, wide-spread specifications, standards, and technologies must never drop any features. They would only ever accumulate new features, bloating to the point of uselessness, and die under the weight of their own success.

Re: "Remove mentions of XSLT from the html spec"

#303
post #185

Earlier 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…

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?

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.

Re: "Remove mentions of XSLT from the html spec"

#304
post #133

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…

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 con…

> 0.1% of a billion people

Probably more like 0.0001% these days. I doubt 0.1% of websites ever used it.

Re: "Remove mentions of XSLT from the html spec"

#305
post #77
post #50

Earlier quoted context omitted.

Why flagged? The post was reasonable.

Probably labeling a removal of a format (which is somewhat niche anyway) as "killing the open web" was a bit hyperbolic and not entirely warranted in this case. Imagine that tomorrow, Google announces plans to stop supporting HTML and move everyone to its own version of "CompuServe", delivered only via Google Fiber and accessible only with Google Chrome. What headline would you suggest for that occasion? " Google is…

[deleted]

Re: "Remove mentions of XSLT from the html spec"

#306
post #72

Earlier quoted context omitted.

XSLT was the blockchain, nft, metaverse of the mid?-2000s. Was totally going to solve all of our problems.

Xslt actually solved a lot of problems for me last week in processing json to relational data

Huh! I'm learning a lot here today. Trying to find more info, indeed the top answer on stackoverflow on the "XSLT equivalent for JSON" is XSLT itself: https://stackoverflow.com/a/49011455/. Hard to find how you'd actually use it though, basically all results I get for "xslt json" are about different tools that convert between JSON and XML

Re: "Remove mentions of XSLT from the html spec"

#307
post #52

Earlier quoted context omitted.

RSS likely isn't the only thing that uses it. XSLT is basically the client side declarative template language for XML/HTML that people always complain doesn't exist (e.g. letting you create your own tags or do includes with no server or build steps).

I understand that there are more possible uses for the tool, but RSS is the only one I saw someone mention. Are there more examples? It may be that I don't notice when I use it, if the page just translates itself into XHTML and I would never know until opening the developer tools (which I do often, fwiw: so many web forms are broken that I have a habit of opening F12, so I always still have my form entries in the net…

I use it to maintain our product catalog at work. The server does the final rendering of the complete document but as a page is getting edited the preview is getting rendered in the browser. Back to what everyone is saying, this isn't important enough to move the needle for people making these decisions.

Re: "Remove mentions of XSLT from the html spec"

#308
I love XSLT. I released a client-side XSLT-based PWA last year (https://github.com/ssg/eksi-yedek - in Turkish). The reason I had picked XSLT was that the input was in XML, and browser-based XSLT was the most suitable candidate for a PWA.

Two years ago, I created a book in memory of a late friend to create a compilation of her posts on social media. Again, thanks to XSLT, it was a breeze.

XSLT has been orphaned on the browser-side for the last quarter century, but the story on the server-side isn't better either. I think that the only modern and comprehensive implementation comes with Saxon-JS which is bloated and has an unwieldy API for JavaScript.

Were XSLT dropped next year, what would be the course of action for us who rely on browser-based XSLT APIs?

XSLT, especially 3.0, is immensely powerful, and not having good solutions on JS ecosystem would make the aftermath of this decision look bleaker.

Re: "Remove mentions of XSLT from the html spec"

#309
post #133

Earlier quoted context omitted.

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 con…

> Representatives from Chrome/Blink, Safari/Webkit, and Firefox/Gecko are all supportive of removing XSLT Did anybody bother checking with Microsoft? XML/XSLT is very enterprisey and this will likely break a lot of intranet (or $$$ commercial) applications. Secondly, why is Firefox/Gecko given full weight for their vote when their marketshare is dwindling into irrelevancy? It's the equivalent of the crazy cat hoarder…

> Secondly, why is Firefox/Gecko given full weight for their vote when their marketshare is dwindling into irrelevancy?

Ironic, considering the market share of XSLT.

Re: "Remove mentions of XSLT from the html spec"

#310

If this is in response to Nick Wellnhofers announcement from three months ago to stop embargoing/priorizing libxlst/libxml2 CVEs due to lack of manpower (which I suspect is a consequence of flooding projects with bogus LLM-generated findings from students wanting to butter their profile), wouldn‘t it be possible to ship an emscripten-compiled libxslt implementation instead of libxslt proper?

Or just Xee.
Post reply on HN