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

171–180 of 559 posts

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

#171

Post by spankalee »

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…

Another way to look at this is:

Billions of people use the web every day. Should the 99.99% of them be vulnerable to XSLT security bugs for the other 0.01%?

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

#172

Post by WorldMaker »

arccy wrote: post #138
redwall_hp wrote: post #88

Earlier quoted context omitted.

The W3C spec was. But WHATWG and HTML5 represent a coup by the dominant browser corporations (read: Google). The biggest browser dictates the "living standard" and the W3C is forced into a descriptivist role. The W3C's plan was for HTML4 to be replaced by XHTML. What we commonly call HTML5 is the WHATWG "HTML Living Standard."

the old sages in ivory towers handed us a spec engraved in stone and expected is to live by it no wonder they were sidelined

They weren't sidelined because they had bad ideas (XHTML 2.0 had a lot of great ideas, many of which HTML5 eventually "borrowed"), they were sidelined because they still saw the web as primarily a document platform and Google especially was trying to push it as a larger application platform. It wasn't a battle between the ivory tower and practical concerns, it was a proxy battle in the general war between the web as a place optimized to link between meaningful, accessibility-first documents and the web as a place to host generalized applications with accessibility often an afterthought. (ARIA is great, but ARIA can only do so much, not as much of it by default/a pit of success as XHTML 2.0 once hoped to be.)

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

#173

Post by intrasight »

codedokode wrote: post #68

This is actually not a bad idea. Why should the browser contain a specific template engine, like XSLT, and not Jinja for example? Also it can be reimplemented using JS or WASM. The browsers today are too bloated and it is difficult to create a new browser engine. I wish there were simpler standards for "minimal browser", for example, supporting only basic HTML tags, basic layout rules, WASM and Java bytecode. Many th…

>Why should the browser contain a specific template engine, like XSLT

Because XSLT is part of the web standards.

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

#174

Post by moritzwarhier »

paulvnickerson wrote: post #156

I support the html and browser spec being greatly simplified in general. Makes it easier to develop competing browsers.

But at the same time, people don't want web pages and web apps to become all fully opaque like Flutter web or complex, minified JS-heavy sites. Even the latter have many a11y benefits of markup.

I think that's a tradeoff.

Simplest approach would be to just distribute programs, but the Web is more than that!

Another simple approach would be to have only HTML and CSS, or even only HTML, or something like Markdown, or HTML + a different simple styling language...

and yet nothing of that would offer the features that make web development so widespread as a universal document and application platform.

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

#175

Post by geocar »

codedokode wrote: post #68

This is actually not a bad idea. Why should the browser contain a specific template engine, like XSLT, and not Jinja for example? Also it can be reimplemented using JS or WASM. The browsers today are too bloated and it is difficult to create a new browser engine. I wish there were simpler standards for "minimal browser", for example, supporting only basic HTML tags, basic layout rules, WASM and Java bytecode. Many th…

> This is actually not a bad idea. Why should the browser contain a specific template engine, like XSLT

XSLT is a specification for a "template engine" and not a specific engine. There are dozens of XSLT implementations.

Mozilla notably doesn't use libxslt but transformiix: https://web.mit.edu/ghudson/dev/nokrb/third/firefox/extensio...

> and not Jinja for example?

Jinja operates on text, so it's basically document.write(). XSLT works on the nodes itself. That's better.

> Also it can be reimplemented using JS or WASM.

Sort of. JS is much slower than the native XSLT transform, and the XSLT result is cacheable. That's huge.

I think if you view XSLT as nothing more than ancient technology that nobody uses, then I can see how you could think this is ok, but I've been looking at it as a secret weapon: I've been using it for the last twenty years because it's faster than everything else.

I bet Google will try and solve this problem they're creating by pushing AMP again...

> The browsers today are too bloated

No, Google's browser today is too bloated: That's nobody's fault but Google.

> and it is difficult to create a new browser engine

I don't recommend confusing difficult to create with difficult to sell unless you're looking for a reason to not do something: There's usually very little overlap between the two in the solution.

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

#176

Post by mx7zysuj4xew »

JimDabell wrote: post #111
Y_Y wrote: post #19

> @whatwg whatwg locked as too heated and limited conversation to collaborators Too heated? Looked pretty civil and reasonable to me. Would it be ridiculous to suggest that the tolerance for heat might depend on how commenters are aligned with respect to a particular vendor?

> Why do people create such joke PRs? > We didn't forgot your decade of fuckeries, Google. > You wanted some heated comment? You are served. > the JavaScript brainworm that has destroyed the minds of the new generation > the covert war being waged by the WHATWG > This is nothing short of technical sabotage, and it’s a disgrace. > breaking yet another piece of the open web you don't find convenient for serving people…

[flagged]

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

#177

Post by microtonal »

spankalee wrote: post #171
kg wrote: 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…

Another way to look at this is: Billions of people use the web every day. Should the 99.99% of them be vulnerable to XSLT security bugs for the other 0.01%?

Solutions have been proposed in that threads, including adding the XSLT polyfill to the browser (which would run it in the Javascript VM/sandbox).

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

#178

Post by geocar »

fngjdflmdflg wrote: post #135
codedokode wrote: post #68

This is actually not a bad idea. Why should the browser contain a specific template engine, like XSLT, and not Jinja for example? Also it can be reimplemented using JS or WASM. The browsers today are too bloated and it is difficult to create a new browser engine. I wish there were simpler standards for "minimal browser", for example, supporting only basic HTML tags, basic layout rules, WASM and Java bytecode. Many th…

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

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

#179

Post by solardev »

upofadown wrote: post #170
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…

The implementations are owned by the implementers. Who owns the actual standard, the implementers or the users?

I think trying to own a web standard is like trying to own a prayer. You can believe all you want, but it's up to the gods to listen or not...

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

#180

Post by intrasight »

LegionMammal978 wrote: post #159
timmg wrote: post #121

Earlier quoted context omitted.

> their desire to minimize attack surface trumps any tendency to leave well enough alone. Is that a good thing or a bad thing? Technical people like us have our desires. But the billions of people doing banking on their browsers probably have different priorities.

There's ways to reduce attack surface short of tearing out support. Such as, for instance, taking one of those alleged JS polyfills and plugging it into the browser, in place of all the C++. But if attack surface is your sole concern, then one of those options sounds much easier than the other, and also ever-so-slightly superior. In any case, there's no limit on how far one can disregard compatibility in the name of…

It is a balance (compatibility vs attach surfaces). The issue with XSLT (which I am still a strong advocate for) is that nobody is maintaining that code. So vulnerabilities sit there undetected. Like the relatively recent discovery of the xsl:document vulnerability.
Post reply on HN