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

411–420 of 559 posts

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

#411

Post by ttepasse »

xg15 wrote: post #185
spankalee wrote: post #127

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?

There isn't one. It's Google's web now. You should be thankful that you are still allowed to use it.

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

#412

Post by jmull »

xg15 wrote: post #378
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…

WHATWG broke this quasi-officially when they declared HTML a "Living Standard". The HTML spec is not a standard to be implemented anymore, it's just a method of coordinating/announcing what the browser vendors are currently working on. (For the same reason, they dropped the name HTML5 and are only talking about "HTML". Who needs version numbers if there is no future and no past anyway?) https://whatwg.org/faq#living-…

Your FAQ stresses the importance of backwards compatibility multiple times.

Seems hard to square removing XSLT with that.

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

#413

Post by thro1 »

kg wrote: post #133
spankalee wrote: post #92

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…

> Why wouldn't the overworked/underresourced Safari and Firefox people want an excuse to have less work to do?

Because otherwise everybody has to repeat same work again and again, programming how - instead of focusing on what, declarative way.

Then data is not free, but caged by processing so it can't exist without it.

I just want data or information - not processing, not strings attached.

I don't see any need to run any extra code over any information - except to keep control and to attach other code, trackers etc. - just, I'm not Google, no need to push anything (just.. faster JS engine instead of empowering users somehow made a browser better ? (no matter how fast, you can't) - for what ? (of what I needed) - or instead of something, that they 'forgot' with a wish they could erase it ?)

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

#414

Post by notnullorvoid »

There are better candidates to remove from the spec than XSLT, like HTML. The parsing rules for HTML are terrible and it hinders further advancement of the spec more than anything. The biggest mistake of HTML was back peddling on the switch to XHTML.

Removal of anything is problematic though, better off freezing parts of the spec to specific compatibility versions and getting browsers to ship optional compatibility modes that let you load and view old sites.

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

#415

Post by ttepasse »

tsimionescu wrote: post #368
basscomm wrote: post #314

Earlier quoted context omitted.

> If I used XSLT on my tiny, low-traffic blog, I think it's reasonable for browser devs to tell me to update my code. I _do_ use XSLT on my tiny, low-traffic blog, and I _don't_ think that it's reasonable for browser devs to tell me to update my code. Also, it's real easy to manufacture a situation where adoption of a thing is low when the implementation is incomplete and hasn't had significant updates for decades.

The web has grown a thousand fold over those decades, in spite of no support for XSLT. No browser has failed (or gained market traction) by missing support for (or adding more support for) XSLT. It's an irrelevancy, even if you did like it once. Lots of content was lost when Flash was removed as well - much, much more than the amount of content that will be lost if XSLT is removed. And yet the web continued.

... in a diminished state.

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

#416

Post by Spivak »

RadiozRadioz wrote: post #331
Spivak wrote: post #86

Earlier quoted context omitted.

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…

I meant the browser shipping the polyfill themselves. I'm in agreement with you.

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

#417

Post by colejohnson66 »

MallocVoidstar wrote: post #360
xvilka wrote: post #235

Earlier quoted context omitted.

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

> Xee implements modern versions of these specifications, rather than the versions released in 1999. My understanding is that browsers specifically use the 1999 version and changing this would break compat

As if removing XSLT entirely won’t break back-compat?

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

#418

Post by jerf »

ndriscoll wrote: post #350
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…

Statistically, how many websites are using webusb? I'm guessing fewer than xslt, which is used by e.g. the US Congress website. I have a hard time buying the idea that document templating is some niche use-case compared to pretty much every modern javascript api. More realistically, lots of younger people don't know it's there. People constantly bemoan html's "lack" of client side includes or extensible component sys…

You seem to be assuming that I would argue against removing webusb. If it went through the same process and the system as a whole reached the same conclusion, I wouldn't fight it too hard personally.

There's probably half-a-dozen other things that could stand serious thought about removal.

There is one major difference though, which is that if you remove webusb, the functionality is just gone, whereas XSLT can be done through Javascript/WebASM just fine.

Document templating is obviously not a niche case. That's why we've got so many hundreds of them. We're not lacking in solutions for document templating, we're drowning in them. If XSLT stands out in its niche, it is as being a particularly bad choice, which is why nobody (to that first approximation we've all heard so much about) uses it.

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

#419

Post by [deleted] »

zetafunction wrote: post #299
xvilka wrote: post #235

Earlier quoted context omitted.

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

Disclaimer: I work on Chrome/Blink and I've also contributed a (very small) number of patches to libxml/libxslt. 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 a…

[deleted]

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

#420

Post by cxr »

jerf wrote: post #303
xg15 wrote: post #185

Earlier quoted context omitted.

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…

> If the web used it like crazy we would not be having this conversation.

It's been a standard part of the Web platform for years. The only question should be, "Is _anyone_ using it?", not whether it's being "used like crazy" or not.

Don't break the Web.

Post reply on HN