Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"Remove mentions of XSLT from the html spec"

github.com

Post reply on HN
Print view View original

331–340 of 559 posts

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

#331

Post by RadiozRadioz »

Spivak wrote: post #86
ummonk wrote: post #47

Earlier quoted context omitted.

No, that would indeed be reasonable, but the proposal is to remove XSLT from the standard and remove Chrome support for XSLT entirely, forcing websites to adopt the polyfill themselves.

Which is, to me, silly. If you ship the polyfill then there's no discussion to be had. It works just the same as it always has for users and it's as secure as V8, no aging native codebase with memory corruption bugs to worry about.

> It works just the same as it always has for users

No it doesn't. An HTML page constructed with XSLT written 10 years ago will suddenly break when browsers remove XSLT. The webmaster needs to add the polyfill themselves. If the webmaster doesn't do that, then the page breaks.

From a user perspective, it only remains the same as before if the webmaster adopts the polyfill. From the web developer perspective, this is a breaking change that requires action. "shipping the polyfill" requires changes on many many sites - some of which have not needed to change in many years.

It may also be difficult to do. I'm not sure what their proposed solution is, but often these are static XML files that include an XSLT stylesheet - difficult to put JS in there.

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

#332

Post by lucb1e »

jorams wrote: post #301
lucb1e wrote: post #52

Earlier quoted context omitted.

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.

Did you ever use a sitemap as a human? I've only ever seen it recommended for SEO, and search engines are perfectly capable of parsing sitemap.xml without needing it turned into some transformed format, or at least so was my understanding (been a while since I looked into sitemaps or SEO). It seems to only be linked in robots.txt, not to any humans: https://www.sitemaps.org/protocol.html#informing

Every (Wordpress) site with an SEO plugin should be fine, since the search engines can still read it and that's the goal of an SEO plugin

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

#333

Post by jerf »

xg15 wrote: post #318
jerf wrote: post #303

Earlier quoted context omitted.

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…

That's not completely wrong, but also misses some nuance. E.g. the thread mentions the fact that web support is still stuck at XSLT 1.0 as a reason for removal. But as far as I know, there were absolutely zero efforts by browser vendors before to support newer versions of the language, while there was enormous energy to improve JavaScript. I don't want to imply that if they had just added support for XSLT 3.0 then ev…

Javascript was instantly a hit from the day it was released, and it grew from there.

XSLT never took off. Ever. It has never been a major force on the web, not even for five minutes. Even during the "XML all the things!" phase of the software engineering world, with every tailwind it would ever had, it was never a serious player.

There was, at no point, any reason to invest in it any farther.

Moreover, even if you push a button and rewrite history so that even so it was heavily invested in anyhow, I see no reason to believe it would have ever been a major force in that alternate history either. I would personally contend that it has always been a bad idea, and if anything, it has been unduly propped up by the browsers and overinvested in as it is. But perhaps less inflammatorily and more objectively, it has always been a foreign paradigm that most programmers have no experience in, and this was even more true in the "XML all the things!" era which predates the initial Haskell burst that pushed FP forward by a good solid decade, and the prospects of it ever being popular were never all that great.

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

#334

Post by jmull »

magicalist wrote: post #294
jmull wrote: post #207

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

To be completely fair, looking over the lines removed by the PR, there don't appear to be any normative statements requiring HTML handling XSLT unless I missed one. 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.

Their explicit intent is to generally remove XSLT from browsers.

If this was just about, e.g., organizing web standards docs for better separation of concerns, I think a lot of people would be reacting to it quite differently.

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

#335

Post by Pxtl »

So Google is bringing the deprecation treadmill to the web, yay!

Yegge called it:

https://steve-yegge.medium.com/dear-google-cloud-your-deprec...

"""

> Because I sometimes get similar letters from the Google Cloud Platform. They look like this:

>> Dear Google Cloud Platform User,

>> We are writing to remind you that we are sunsetting [Important Service you are using] as of August 2020, after which you will not be able to perform any updates or upgrades on your instances. We encourage you to upgrade to the latest version, which is in Beta, has no documentation, no migration path, and which we have kindly deprecated in advance for you.

>> We are committed to ensuring that all developers of Google Cloud Platform are minimally disrupted by this change.

>> Besties Forever,

>> Google Cloud Platform

> But I barely skim them, because what they are really saying is:

>> Dear RECIPIENT,

>> Fuck yooooouuuuuuuu. Fuck you, fuck you, Fuck You. Drop whatever you are doing because it’s not important. What is important is OUR time. It’s costing us time and money to support our shit, and we’re tired of it, so we’re not going to support it anymore. So drop your fucking plans and go start digging through our shitty documentation, begging for scraps on forums, and oh by the way, our new shit is COMPLETELY different from the old shit, because well, we fucked that design up pretty bad, heh, but hey, that’s YOUR problem, not our problem.

>> We remain committed as always to ensuring everything you write will be unusable within 1 year.

>> Please go fuck yourself,

>> Google Cloud Platform

"""

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

#336

Post by dwoldrich »

The XSLT juice is worth the squeeze, but only to a tiny minority of users, and there's costly rewrites to do to keep XSLT in there (for Chrome, at least.)

Here's what I wish could happen: allow implementers to stub out the XSLT engine and tell users who love it that they can produce a memory-safe implementation themselves if they want the functionality put back in. The passionate users and preservationists would get it done eventually.

I know that's not a good solution because a) new xslt engine code needs to be maintained and there's an ongoing cost for that for very few users, b) security reviews are costly for the new code, c) the stubs themselves would probably be nasty to implement, have security implications, etc. And, there's probably reasons d-z that I can't even fathom.

It sucks to have functionality removed/changed in the web platform. Software must be maintained though; cost of doing business. If a platform doesn't burden you with too much maintenance and chooches along day after day, then it's usually a keeper.

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

#337

Post by zetafunction »

mananaysiempre wrote: post #327
zetafunction wrote: post #281

Earlier quoted context omitted.

Disclaimer: I work on Chrome and I have contributed a (very) small number of fixes to libxml2/libxslt for some of the recent security bugs. Speaking from personal experience, working on libxslt... not easy for many reasons beyond the complexity of XSLT itself. For instance: - libxslt is linked against by all sorts of random apps and changes to libxslt (and libxml2) must not break ABI compatibility. This often constra…

> libxslt is linked against by all sorts of random apps and changes to libxslt (and libxml2) must not break ABI compatibility. This often constrains the shape of possible patches, and makes it that much harder to write systemic fixes. I’m having trouble expressing this in a way that won’t likely sound harsher than I really want, but, uh, yes? That’s the fundamental difference between maintaining a part of the commons…

It's one thing if the library was proactively written with ABI compatibility in mind. It's another thing entirely if the library happens to expose all its implementation details in the headers, making it that much harder to change things.

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

#338

Post by Pxtl »

jmull wrote: post #207

Breaking 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 perverse irony that Google is as responsible as anybody for cramming a crazy amount of new stuff into the HTML/CSS/browser spec that everybody else has to support forever.

If they were one of the voices for "the browser should be lightweight and let JS libs handle the weird stuff" I would respect this action, but Google is very very not that.

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

#339

Post by 93po »

dralley wrote: post #184
93po wrote: post #154

Earlier quoted context omitted.

When I see "reps from every browser agree" my bullshit alarm immediately goes off. Does it include unanimous support from browser projects that are either: 1. not trillion dollar tech companies or 2. not 99% funded from a trillion dollar tech company. I have long suspected that Google gives so much money to Mozilla both for the default search option, but also for massive indirect control to deliberately cripple Mozil…

>I have long suspected that Google gives so much money to Mozilla both for the default search option, but also for massive indirect control to deliberately cripple Mozilla in insidious ways to massively reduce Firefox's marketshare. This has never ever made sense because Mozilla is not at all afraid to piss in Google's cheerios at the standards meetings. How many different variations of Flock and similar adtech orien…

Controlled opposition is absolutely a thing, and to think that people at trillion dollar companies wouldn't do this is naive. I'm not claiming for a fact that mozilla is controlled opposition, i'm just saying it's very feasible that it could be, and i look for signs of it.

You give examples of things they disagree on, and i wouldn't refute that. However i would say that google is going to pick and choose their battles, because ultimately things they appear to "lose on" sort of don't matter. fingerprinting is a great example - yes, firefox provides it, but it's still largely pretty useless, and its impact is even more meaningless because so few people use it. if you have javascript on and arent using a VPN, chances are your anti-fingerprinting isn't actually doing much other than annoying you and breaking sites.

the only real thing to be used for near-complete-anonymity is Tor, but only when it's also used in the right way, and when JavaScript is also turned off. And even then there are ways it could and probably has failed.

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

#340

Post by Pxtl »

foobazgt wrote: post #298
jmull wrote: post #207

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

Nothing lasts forever, and eventually you have to port, emulate, archive or otherwise deal with very old applications / media. You see this all over the place: physical media, file formats, protocols, retro gaming, etc. 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 s…

I can still run windows applications that are decades old. If you don't want to support legacy stuff, don't insinuate yourself into global standards.

If this was just Android that would be an issue between Google and their developers/users, but this is everybody.

Post reply on HN