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.
"Remove mentions of XSLT from the html spec"
241–250 of 559 posts
Re: "Remove mentions of XSLT from the html spec"
#242So 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.
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"
#243Earlier 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?
> "- 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"
#244Earlier 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?
Re: "Remove mentions of XSLT from the html spec"
#245I 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"
#246Re: "Remove mentions of XSLT from the html spec"
#247Earlier 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.
Re: "Remove mentions of XSLT from the html spec"
#248I 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.
Re: "Remove mentions of XSLT from the html spec"
#249Earlier 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.
Re: "Remove mentions of XSLT from the html spec"
#250Earlier 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.