Live data from Hacker News

"Remove mentions of XSLT from the html spec"

github.com

151–160 of 559 posts

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

#151
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…

By your argument, once anything makes it in, then it can't be removed. Billions of people are going to use the web every day and it won't stop. Even the most obscure feature will end up being used by 0.1% of users. Can you name a feature that's supported by all browsers that's not being used by anyone?

Yes. That is exactly how web standards work historically. If something will break 0.1% of the web it isn't done unless there are really really strong reasons to do it anyway. I personally watched lots of things get bounced due to their impact on a very small % of all websites.

This is part of why web standards processes need to be very conservative about what's added to the web, and part of why a small vocal contingent of web people are angry that Google keeps adding all sorts of weird stuff to the platform. Useful weird stuff, but regardless.

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

#152

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 scripting language, like JavaScript, and not ActiveScript for example?

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

#153

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…

Compare webkit to UDK (The unreal development kit for game dev) to consider why there is so much bloat in the browser. People have wanted to render more and more advanced things, and the webkit engine should cater to all of them as best it can.

For better or worse, http is no longer just for serving textual documents.

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

#154
post #133

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…

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 Mozilla in insidious ways to massively reduce Firefox's marketshare. And I have long predicted that Google is going to make the rate of change needed in web standards so high that orgs like Mozilla can't keep up and then implode/become unusable.

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

#155
post #130
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…

Almost every single government organization uses it to publish their official documents. Lots of major corporations too. As much of a monopoly as Chrome is, if they actually try to remove it they're likely to get a bunch of government web pages outright stating "Chrome is unsupported, please upgrade to Firefox or something".

Huh? I mainly see official government documents as annoying PDFs. Thankfully someone had the bright idea to turn the national law's text into a proper webpage and not use an image-like format for that. (I think regional governments also publish laws as PDF though.) Double checking now, yes: that's definitely HTML and not a transformed XML

Which government or governmental organizations are you talking about?

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

#157
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.

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

#158
post #110

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…

While this sounds crazy at first, I could warm for several incremental layers of features, where browsers could choose to implement support for only a set of layers. The lowest layer would be something like HTTP with plain text, the next one HTML, then CSS with basic selectors, then CSS with the full selector set, then ECMA and WASM, then device APIs, and so forth. Would make it possible to create spec-compliant brow…

You can set the doctype in the document to the spec you want to use, which is basically what you're asking for. Try setting

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

#159
post #121

Oh hey, that thing happened that one could easily see was going to happen [0]. The writing was on the wall for XSL as soon as the browsers tore out FTP support: their desire to minimize attack surface trumps any tendency to leave well enough alone. I wonder what the next step of removing less-popular features will be. Probably the SMIL attributes in favor of CSS for SVG animations, they've been grumbling about those…

> 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 security. Just look at the situation on Apple OSes, where developers are kept on a constant treadmill to update their programs to the latest APIs. I'd rather not have everything trend in that direction, even if it means keeping shims and polyfills that aren't totally necessary for modern users.

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

#160

Oh hey, that thing happened that one could easily see was going to happen [0]. The writing was on the wall for XSL as soon as the browsers tore out FTP support: their desire to minimize attack surface trumps any tendency to leave well enough alone. I wonder what the next step of removing less-popular features will be. Probably the SMIL attributes in favor of CSS for SVG animations, they've been grumbling about those…

> The writing was on the wall for XSL as soon as the browsers tore out FTP support When did they do that? Can I not still ftp://example.com in the url bar?

FTP support was completely removed from Chrome with the release of Chrome 88, which was released in January 2021
Post reply on HN