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

341–350 of 559 posts

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

#341

Post by [deleted] »

mr_toad wrote: post #304
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…

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

[deleted]

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

#342

Post by joquarky »

krapp wrote: post #166
rebolek wrote: post #152

Earlier quoted context omitted.

Why should the browser contain a specific scripting language, like JavaScript, and not ActiveScript for example?

It's a consequence of javascript being "good enough." Originally, the goal was for the web to support multiple languages (I think one prototype of the tag had a "type=text/tcl") and IE supported VBScript for a while. But at the end of the day, you only really need one, and the type attribute was phased out of the script tag entirely, and Javascript won.

BTW, over a third of court case management software in the US is run on VBScript hosted in IE7 compatibility mode.

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

#343

Post by joe_the_user »

kstrauser wrote: post #284
geocar wrote: post #175

Earlier quoted context omitted.

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

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?

I think the obvious answer is that client side mapping would let the browser give different view of the data to the client. The obvious problem is that downloading all the data and then transforming is inherently inefficient (and sure, despite this, download-then-process is a common solution used for many problems - but it's problematic to specify the worst solution before you know the problem).

Perhaps there's an alternative universe where javascript lost and an elegant, declarative XSLT could declaratively present data and incrementally download only what's needed, allowing compact and elegant websites.

But in our universe today, this mapping language wound-up a half-thought-idea that just kicked around for a long time in the specs without ever making sense.

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

#344

Post by SoftTalker »

solardev wrote: post #208
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…

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…

XSLT was awesome back in the day. You could get a block of XML data from the server, and with a bit of very simple scripting, slice it, filter it, sort it, present summary or detail views, generate tables or forms, all without a server round trip. This was back in IE6 days, or even IE5 with an add-on.

We built stuff with it that amazed users, because they were so used to the "full page reload" for every change.

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

#345

Post by joquarky »

codedokode wrote: post #132
dehrmann wrote: post #114

Earlier quoted context omitted.

> Why should the browser contain a specific template engine, like XSLT, and not Jinja for example? Historic reasons, and it sounds like they want it to contain zero template engines. You could transpile a subset of Jinja or Mustache to XSLT, but no one seems to do it or care.

Adding XSLT support is as absurd as adding React into a browser (especially given that it's change detection is inefficient and requires lot of computation). Instead, browsers should provide better change tracking methods for JS objects.

Knockout.js may be off the radar these days, but has robust handling for this.

Still the best framework I've ever worked with.

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

#346

Post by goku12 »

maratc wrote: post #313
garganzol wrote: post #295

Earlier quoted context omitted.

[flagged]

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

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

#347

Post by kstrauser »

joe_the_user wrote: post #343
kstrauser wrote: post #284

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?

I think the obvious answer is that client side mapping would let the browser give different view of the data to the client. The obvious problem is that downloading all the data and then transforming is inherently inefficient (and sure, despite this, download-then-process is a common solution used for many problems - but it's problematic to specify the worst solution before you know the problem). Perhaps there's an al…

My gut instinct is to agree with every bit of that. I admit that I might be missing something, but I've never wanted to send the data once and then have the client view it in multiple transformed ways (minus simple presentation stuff like sorting a table by column and things like that).

And using it to generate RSS as mentioned elsewhere in the comments? That makes perfect sense to me on the server. I don't know that I've ever even seen client-side generated RSS.

But again, this may all be my own lack of imagination.

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

#348

Post by arp242 »

BoiledCabbage wrote: post #113

So if in reading the two threads correctly essentially Google asked for feedback, essentially all the feedback said "no, please don't". And they said "thanks for the feedback, we're gonna do it any way!"? The other suggestions ignored seemed to be "if this is about security, then fund the OSS, project. Or swap to a newer safer library, or pull it into the JS sandbox and ensure support is maintained." Which were all m…

[flagged]

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

#349

Post by bawolff »

o11c wrote: post #328
jerf wrote: post #303

Earlier quoted context omitted.

Honestly, your chance to impact this decision was when you decided what technologies to use on your website, and then statistically speaking [1], chose not to use XSLT in the browser. If the web used it like crazy we would not be having this conversation. Your other opportunity is to put together a credible plan to resource the XSLT implementations in the various browsers. I underline, highlight, bold, and italicize…

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.

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

#350

Post by ndriscoll »

jerf wrote: post #303
xg15 wrote: post #185

Earlier quoted context omitted.

I think this discussion is quite reasonable, but it also highlights the power imbalance: If this stuff is decided in closed meetings and the bug trackers are not supposed to be places for community feedback, where can the community influence such decisions?

Honestly, your chance to impact this decision was when you decided what technologies to use on your website, and then statistically speaking [1], chose not to use XSLT in the browser. If the web used it like crazy we would not be having this conversation. Your other opportunity is to put together a credible plan to resource the XSLT implementations in the various browsers. I underline, highlight, bold, and italicize…

Statistically, how many websites are using webusb? I'm guessing fewer than xslt, which is used by e.g. the US Congress website.

I have a hard time buying the idea that document templating is some niche use-case compared to pretty much every modern javascript api. More realistically, lots of younger people don't know it's there. People constantly bemoan html's "lack" of client side includes or extensible component systems.

Post reply on HN