As a reminder for people who love xslt.
Nothing is stopping you from using content negotiation to do it server side.
"Remove mentions of XSLT from the html spec"
351–360 of 559 posts
Re: "Remove mentions of XSLT from the html spec"
#352Earlier 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…
> Representatives from Chrome/Blink, Safari/Webkit, and Firefox/Gecko are all supportive of removing XSLT Did anybody bother checking with Microsoft? XML/XSLT is very enterprisey and this will likely break a lot of intranet (or $$$ commercial) applications. Secondly, why is Firefox/Gecko given full weight for their vote when their marketshare is dwindling into irrelevancy? It's the equivalent of the crazy cat hoarder…
Maybe because Edge is just a wrapper around Blink?
Re: "Remove mentions of XSLT from the html spec"
#353Earlier quoted context omitted.
Bring back VRML! Seriously though, if I were forced to maintain every tiny legacy feature in a 20 year old app... I'd also become a "former" dev :) Even in its heyday, XSLT seemed like an afterthought. Probably there are a handful of legacy corporate users hanging on to it for dear life. But if infinitely more popular techs (like Flash or FTP or non HTTPS sites) can be deprecated without much fuss... I don't think XS…
> But if infinitely more popular techs (like Flash or FTP or non HTTPS sites) can be deprecated without much fuss... I don't think XSLT has much of a leg to stand on... Flash was not part of the web platform. It was a plugin, a plugin that was, over time, abandoned by its maker. FTP was not part of the web platform. It was a separate protocol that some browsers just happened to include a handler for. If you have an F…
I don't think that distinction makes much of a difference for the users and devs affected...
Re: "Remove mentions of XSLT from the html spec"
#354Earlier quoted context omitted.
Bring back VRML! Seriously though, if I were forced to maintain every tiny legacy feature in a 20 year old app... I'd also become a "former" dev :) Even in its heyday, XSLT seemed like an afterthought. Probably there are a handful of legacy corporate users hanging on to it for dear life. But if infinitely more popular techs (like Flash or FTP or non HTTPS sites) can be deprecated without much fuss... I don't think XS…
> 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"
#355Earlier quoted context omitted.
I think it depends on the spec. Some of the working groups still have mailing lists, some of them have GitHub issues. To be completely honest, though, I'm not sure what people expect to get out of it. I dug into this a while ago for a rather silly reason and I found that it's very inside baseball, and unless you really wanted to get invested in it it seems like it'd be hard to meaningfully contribute. To be honest if…
If people are upset about xslt being removed, step 1 would have been to actually use it in a significant way on the web. Step 2 would have been to volunteer to maintain libxslt. Everyone likes to complain as a user of open source. Nobody likes to do the difficult work.
Didn't someone step up to volunteer ot maintain libxslt a few weeks ago? https://gitlab.gnome.org/GNOME/libxslt/-/issues/150
Re: "Remove mentions of XSLT from the html spec"
#356Earlier quoted context omitted.
Disclaimer: I work on Chrome and I have contributed a (very) small number of fixes to libxml2/libxslt for some of the recent security bugs. Speaking from personal experience, working on libxslt... not easy for many reasons beyond the complexity of XSLT itself. For instance: - libxslt is linked against by all sorts of random apps and changes to libxslt (and libxml2) must not break ABI compatibility. This often constra…
Sounds like libxslt needs more than just a small number of fixes, and it sounds like Google could be paying someone, like you, to help provide the necessary guidance and feedback to increase the usability and capabilities of the library and evolve it for the better. Instead Google and others just use it, and expect that any issues that come up to be immediately fixed by the one or two open source maintainers that hap…
or, the downstream users who use it and benefit directly from it could step up, but websites and their users are extremely good at expecting things to just magically keep working especially if they don't pay for it. it was free, so it should be free forever, and someone set it up many moons ago, so it should keep working for many more magically!
// of course we know that, as end-users became the product, Big Tech [sic?] started making sure that users remain dumb.
Re: "Remove mentions of XSLT from the html spec"
#357Earlier quoted context omitted.
Counterpoint: most websites are not useful. If we only count useful websites a much higher percentage of them are using XSLT. But useful websites are much less likely to be infested by the all consuming Goo admalware.
[Citation needed] Seriously, i doubt this.
I secondly doubt this. Would love a succinct list of "important" websites.
Re: "Remove mentions of XSLT from the html spec"
#358Earlier quoted context omitted.
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.
Looking at the problem differently. Say some change would make Hacker News unusable, the data would support this and show that it practically affects no one.
First, we are an insignificant portion of the web, and it's okay to admit that.
Second, if HN were built upon outdated Web standards practically nobody else uses, I'm sure YCombinator could address the issue before the deadline (which would probably be at least a year or two out) to meet the needs of its community. Every plant needs nourishment to survive.
Re: "Remove mentions of XSLT from the html spec"
#359Earlier quoted context omitted.
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%?
That same argument applies to numerous web technologies, though. Applied to each individually it seems to make sense. However the aggregate effect is kill off a substantial portion of the web. In fact, it's an argument to never add a new web technology: Should 100% of web users be made vulnerable to bugs in a new technology that 0% of the people are currently using? Plus it's a false dichotomy. They could instead add…
depends entirely on which technologies are acctively addressing current and future vulnerabilities.
Re: "Remove mentions of XSLT from the html spec"
#360Earlier 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…
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