Live data from Hacker News

"Remove mentions of XSLT from the html spec"

github.com

241–250 of 559 posts

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

#241

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, according to Chrome's telemetry, very, very few websites are using it in practice. It's not like the proposal is threatening to make some significant portion of the web inaccessible. At least we can see the data underlying the proposal here.

Looking at the problem differently. Say some change would make Hacker News unusable, the data would support this and show that it practically affects no one.

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

#242

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.

> people who are actually using it

I'd presume that most of those people are using it in some capacity, it's just that their numbers are seen as too minor to influence the decision.

> explain why it's necessary

No feature is strictly necessary, so that's a pretty high standard.

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

#243
post #149

Earlier quoted context omitted.

No need, with exception of Safari, Web is ChromeOS already. All the other alternatives are meaningless, including Firefox. I am one of the few folks on my team that still uses Firefox, all our projects dropped support for it like 5 years ago.

Wow, you’re really pushing this Web=ChromeOS nonsense. Want to support that with something more than your own isolated anecdote?

Hard to find these days, but it remindes me of this [0]:

> "- Google had a plan called "Project NERA" to turn the web into a walled garden they called "Not Owned But Operated". A core component of this was the forced logins to the chrome browser you've probably experienced (surprise!)"

To "not own but operate" seems to go into the direction of the parent comment.

Also this: https://news.ycombinator.com/item?id=28976574

[0]: https://web.archive.org/web/20211024063021/https://twitter.c...

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

#244
post #149

Earlier quoted context omitted.

No need, with exception of Safari, Web is ChromeOS already. All the other alternatives are meaningless, including Firefox. I am one of the few folks on my team that still uses Firefox, all our projects dropped support for it like 5 years ago.

Wow, you’re really pushing this Web=ChromeOS nonsense. Want to support that with something more than your own isolated anecdote?

Chrome and Electron market share, easy to find out.

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

#245
Setting aside the discussion of the linked issue itself (tone, comments, etc), I feel like I need to throw this out there:

I don't understand the point in having a JS polyfill and then expecting websites to include it if they want to use XSLT stuff. The beauty of the web is that shit mostly just works going back decades, and it's led to all kinds of cool and useful bits of information transfer. I would bet money that so much of the weird useful XSLT stuff isn't maintained as much today - and that doesn't mean it's not content worth keeping/preserving.

This entire issue feels like it would be a nothing-burger if browser vendors would just shove the polyfill into the browser and auto-run it on pages that previously triggered the fear-inducing C++ code paths.

What exactly is the opposition to this? Even reading the linked issue, I don't see an argument against this that makes much sense. It solves every problem the browser vendors are complaining about and nothing functionally changes for end users.

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

#246
It's not like the browsers can just switch to some better maintained XSLT library. There aren't any. There are about 1.5 closed-source XSLT 3 implementations, Altova and Saxonica. I don't want to sound ageist, but the latter is developed by the XSLT spec's main author, who is nearing retirement age. This library is developed behind closed doors, and from time to time zip files with code get uploaded to GitHub. Make of that what you will in terms of the XSLT community. For all of its elegance, XSLT doesn't seem very relevant if nobody is implementing it. I'm all for the open web, but XSLT should just be left in peace to slide into the good night.

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

#247
post #6

Earlier quoted context omitted.

Yep, doesn't this make certain pages not work anymore?

it will. It will make old non-updated pages break with same fate as old outdated pages which used MathML in the past and were not updated with polyfills.

FYI, MathML is currently shipping (again, after all these years) in Chrome, Firefox, and Safari[1].

[1] https://mathml.igalia.com/

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

#248
post #62

I don't get the people complaining that they need it on their low-power microcontrollers yet instead of using an XSLT library they'd rather pull in Chromium. With how bloated browsers are right now, good riddance IMO

They are not talking about pulling in Chromium on a microcontroller. Their web server is on a microcontroller, so they want to minimize server side CPU usage and force the browser to do their XSLT transformation. Since it's a microcontroller, modifying that server and pushing the firmware update to users is probably also a pain. Unusual use case, but an reasonable one.

Yeah, I don't think XML + XLST is any better than or allows anything that sending say JSON and transforming it with JS wouldn't. However that would require changing the firmware, which as you mention may be difficult or impossible.

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

#249
post #195

Earlier quoted context omitted.

> ChromeOS is for all practical purposes, the web. Fixed that typo for you.

> > ChromeOS is for all practical purposes, the web I'm very practically using Debian Linux on ChromeOS to develop test and debug enterprise software. I even compile and run some native code. It is very much more than just the web.

That is a VM, and actually maybe eventually it will be on top of Webassembly, how things are going.

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

#250

Earlier quoted context omitted.

The web has been prospering?

"One of the most adopted technologies, the one that is permeating into even native desktop and mobile apps, is not prospering." - HN users, probably.

There's a difference between web technologies and "the web" as an amorphous philosophical construct. Web technologies, as you stated, are obviously doing just fine. I'd argue the latter isn't. To be more specific, the latter as it was envisioned (in a way that I, and I speculate, GP also still subscribe to) 20+ years ago.
Post reply on HN