Live data from Hacker News

"Remove mentions of XSLT from the html spec"

github.com

421–430 of 559 posts

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

#421
post #311
post #258

Earlier quoted context omitted.

Users flagged it. We can only guess why users flag things. Perhaps it was the baity title. I've taken the flags off that post now.

Respectfully, there is nothing baity about that title. The body of that article justifies it. XSLT is only about the last third of it.

These things land differently with different readers, of course, but "Google is killing the open web" does seem pretty baity to me. The combo of grand-claim and something-to-get-mad-about usually is. It doesn't take too large a set of provoked readers to get a large enough set of provoked commenters to bump a thread into flamewar mode.

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

#422
post #346
post #313

Earlier quoted context omitted.

> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. (from the guidelines)

Honestly, the guidelines must also include a clause prohibiting those activities. Sometimes the pattern is overwhelming. But it's prohibited to complain about it. Not an ideal situation. Hope you'll give it a serious thought.

Those activities are certainly prohibited. I don't think we don't need a guideline to say that though.

The HN guidelines don't list everything that's prohibited. To publish such a list would be to imply that everything not on the list is ok. That would be a big mistake! It would be carte blanche to the entire internet to find loopholes and wreak havoc with them.

> Sometimes the pattern is overwhelming.

The trouble is that in many cases it feels like such a pattern—and the feeling can be super convincing—yet there turns out to be no evidence for it. Perceptions are awfully unreliable about this.

We ask people not to post about these things in the threads, not to imply that actual astroturfing etc. is at all ok, but because unfounded comments about it vastly outnumber well-founded comments. Worse, they have a way of proliferating and taking over the threads.

Keep in mind that that guideline doesn't say "please don't post and then do nothing". It says "please don't post, but do email us so we can look into it". We do look into it, and on occasions when we find evidence, we act on it. There just needs to be something objective to go on, and in most cases there isn't.

The phenomenon of internet users being far too quick to jump to conclusions about astroturfing, bots, etc., is extremely well established. If there's one phenomenon we've learned about decisively over the years, that's the one. (Well, one of two.)

Btw, I've written about this a ton over the years (https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...). I particularly remember writing these two:

https://news.ycombinator.com/item?id=35932851 (May 2023)

https://news.ycombinator.com/item?id=27398725 (June 2021)

They're long, but they still hold up as descriptions of these phenomena and the moderation approach we take to them.

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

#423

Earlier quoted context omitted.

> Probably there are a handful of legacy corporate users hanging on to it for dear life. Like more or less everyone that hosts podcasts. But the current trend is for podcast feeds to go away, and be subsumed into Spotify and YouTube.

Do people consume RSS feeds directly via XSLT? Not through apps and such that subscribe to the feed?

This came up in some of the comments: https://github.com/whatwg/html/issues/11523#issuecomment-315... if you click the links instead of copy/pasting into your reader you get a page full of raw XML. It's not harmful or anything but it's not a great look. You can't really expect your users to just never click on your links, that's usually what links are for.

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

#424

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.

The people writing, and visiting websites that rely on XSLT are the same users that disable or patch out telemetry.

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

#425
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%?

If the usage/risk of XSLT is enough to remove it, you'd have to remove webusb, webbluetooth, webmidi, webxr, and countless more

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

#426
post #390

Earlier quoted context omitted.

If this is the reason to remove and or not add something to the web, then we should take a good hard look at things like WebSerial/WebBluetooth/WebGPU/Canvas/WebMIDI and other stuff that has been added that is used by a very small percentage of people yet all could contain various security bugs... If the goal is to reduce security bugs, then we should stop introducing niche features that only make sense when you are…

whatever you do with xslt you can do it in a saner way, but whatever we need to use serial/bluetooth/webgpu/midi for there is no other way, and canvas is massively used.

I'd love to see more powerful HTML templating that'd be able to handle arbitrary XML or JSON inputs, but until we get that, we'll have to make do with XSLT.

For now, there's no alternative that allows serving an XML file with the raw data from e.g. an embedded microcontroller in a way that renders a full website in the browser if desired.

Even more so if you want to support people downloading the data and viewing it from a local file.

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

#427

Earlier quoted context omitted.

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

When i first encountered the early GNOME 1 software back in the very late 1990s, and DV (libml author) was active, i was very surprised when i asked for the public API for a library and was told, look at the header files and the source.

They simply didn’t seem to have a concept of data hiding and encapsulation, or worse, felt it led to evil nasty proprietary hidden code and were better than that.

They were all really nice people, mind you—i met quite a few of them, still know some—and the GNOME project has grown up a lot, but i think that’s where libxml was coming from. Daniel didn’t really expect it to be quite so widely used, though, i’m sure.

I’ve actually considered stepping up to maintain libxslt, but i don’t know enough about building on Windows and don’t have access to non-Linux systems really. Remote access will only go so far on Windows i think, although it’d be OK on Mac.

It might be better to move to one of the Rust XML stacks that are under active development (one more active than the other).

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

#428
post #398

Earlier quoted context omitted.

I'm asking this genuinely, not as a leading question or a gotcha trap: why use this client side, instead of running it on the server and sending the rendered output?

For one, in many cases the XML + XSLT is more compact than the rendered output, so there are hosting and bandwidth benefits, especially if you're transforming a lot of XML files with the same XSLT.

That’s fascinating because I wouldn’t have expected it. What’s an example of when they rendered output would be bigger?

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

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

> 0.1% of a billion people Probably more like 0.0001% these days. I doubt 0.1% of websites ever used it.

0.02% of public Web pages, apparently, have the XSLT processing instruction in them, and a few more invoke XSLT through JavaScript (no-one really knows how many right now).

It’s likely more heavily used inside corporate and governmental firewalls, but that’s much harder to measure.

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

#430
post #7

Chrome is a browser – it can’t remove something from the spec. Perhaps this should say Google proposes to remove it from the spec.

Not sure if you missed it, but a few days before this PR, Google did propose removing it from the spec.

But that's my point - Google is proposing removing it from the spec. It's kinda weird to reformulate it for the headline as 'Chrome' is doing it.
Post reply on HN