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.
"Remove mentions of XSLT from the html spec"
421–430 of 559 posts
Re: "Remove mentions of XSLT from the html spec"
#422Earlier 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.
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"
#423Earlier 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?
Re: "Remove mentions of XSLT from the html spec"
#424A 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.
Re: "Remove mentions of XSLT from the html spec"
#425Earlier 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%?
Re: "Remove mentions of XSLT from the html spec"
#426Earlier 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.
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"
#427Earlier 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.
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"
#428Earlier 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.
Re: "Remove mentions of XSLT from the html spec"
#429Earlier 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.
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"
#430Chrome 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.