Live data from Hacker News

"Remove mentions of XSLT from the html spec"

github.com

51–60 of 559 posts

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

#51
post #40

Do we know Webkit, KHTML and Gecko's stand on this? I know this is for security reason but why not update the XSLT implementation instead. And if feature that aren't used get dropped, they might as well do it all in one good. I am sure lots of HTML spec aren't even used.

If it was just for security reasons, they could sponsor FOSS development on the implementation.

I am of the opinion that it is to remove one of the last ways to build web applications that don't have advertising and tracking injected into them.

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

#52
post #32

I had no idea what XSLT even was until today. Reading the submission, the thread linked by u/troupo below, and Wikipedia, I find that it's apparently used in RSS parsing by browsers, because RSS is XML and then XSLT is "originally designed for transforming XML documents into other XML documents" so it can turn the XML feed into an HTML page I agree RSS parsing is nice to have built into browsers. (Just like FTP suppo…

RSS likely isn't the only thing that uses it. XSLT is basically the client side declarative template language for XML/HTML that people always complain doesn't exist (e.g. letting you create your own tags or do includes with no server or build steps).

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 network request log). Maybe it's much more widespread than I knew of. I have never come across it and my job is testing third-party websites for security issues, so we see a different product nearly every week (maybe those sites need less testing because they're not as commonly interactive? I may have a biased view of course)

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

#53
I used XSLT once to publish recipes on the web. The cookbook software my mom used (maybe MasterCook?) could "export as xml" and I wrote an xslt to transform it into readable html. It was fine. It's, of course, also possible to run the XSLT from the command line to generate static html.

The suggestion of using a polyfill is a bit nonsensical as I suspect there is little new web being written in XSLT, so someone would have to go through all the old pages out there and add the polyfill. Anyone know if accomplishing XSLT is possible with a Chrome extension? That would make more sense.

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

#54
post #17

Earlier quoted context omitted.

> It’s another “we listened the community and nobody told us no” moment. Like Go’s telemetry issue. Go changed their telemetry to opt-in based on community feedback, so I'm not sure what point you're trying to make with that example.

No. The official statement from Brian was “I received a couple of personal e-mails from some credible people who stated that their data belonged to them, so we (I) decided to make it opt-in” (paraphrased). I spent days in that thread. That uproar was “a bunch of noisy minority which doesn’t worth listening” for them.

I mean yeah, I too would probably prefer to read a few well-reasoned arguments over email than to wade through hundreds of hateful, vitriolic, accusatory comments from randos in a GitHub thread. Being an open-source maintainer is hard.

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

#55
post #37

This proposal seems to be aimed at removing native support in favor of a WASM-based polyfill (like PDF.js, I guess) which seems reasonable? Google definitely throws its weight around too much w.r.t. to web standards, but this doesn't seem too bad. Web specifications are huge and complex so trying to size down a little bit while maintaining support for existing sites is okay IMO.

Last I checked, it’s a polyfill that Chrome won’t default include - they’re just saying that they’d have a polyfill in JS and it’s on site authors to use. That breaks old unmaintained but still valuable sites.

As a user you can only use the polyfill to replace the XSLTProcessor() JavaScript API. You can't use the polyfill if you're using XSLT for XML Stylesheets ( tags).

(But of course, XML Stylesheets are most widely used with RSS feeds, and Google probably considers further harm to the RSS ecosystem as a bonus. sigh)

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

#57

Earlier quoted context omitted.

How do you think we got into this mess in the first place? First it was Netscape, then Microsoft, now Google.

Yet, the web has been prospering for two decades in spite of the quasi-monopoly state of browsers. It's the living evidence that the dominant browser vendor doesn't has as much power as people imagine.

The web has been prospering?

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

#58
post #32

I had no idea what XSLT even was until today. Reading the submission, the thread linked by u/troupo below, and Wikipedia, I find that it's apparently used in RSS parsing by browsers, because RSS is XML and then XSLT is "originally designed for transforming XML documents into other XML documents" so it can turn the XML feed into an HTML page I agree RSS parsing is nice to have built into browsers. (Just like FTP suppo…

It's much more general purpose than that. RSS is just XML after all. XSLT basically lets you transform XML into some other kind of markup, usually HTML.

I think the principle behind it is wonderful. https://www.example.com/latest-posts is just an XML file with the pure data. It references an XSLT file which transforms that XML into a web page. But I've tried using it in the past and it was such a pain to work with. Representing things like for loops in markup is a fundamentally inefficient thing to do, JavaScript based templating is always going to win out from the developer experience viewpoint, especially when you're more than likely going to need to use JS for other stuff anyway.

It's one of those purist things I yearn for but can never justify. Shipping XML with data and a separate template feels so much more efficient than pre-prepared HTML that's endlessly repetitive. But... gzip also exists and makes the bandwidth savings a non-issue.

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

#59
post #26

I have no opinion on this, just sharing my one-and-only XSLT story. My first job in software was as a software test development intern at a ~500 employee non-profit, in about 2008 when I was about 19 or 20 years old. Writing software to test software. One of my tasks during the 2 years I worked there was to write documentation for their XML test data format. The test data was written in XML documents, then run throug…

My XSLT story:

I wrote my personal website in XML with XSLT transforming into something viewable in the browser circa 2008. I was definitely inspired by CSS Zen Garden where the same HTML gave drastically different presentation with different CSS, but I thought that was too restrictive with too much overly tricky CSS. I thought the code would be more maintainable by writing XSLT transforms for different themes of my personal website. That personal webpage was my version of the static site generator craze: I spent 80% of the time on the XSLT and 20% on the content of the website. Fond memories, even though I found XSLT to be incredibly difficult to write.

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

#60
post #17

Earlier quoted context omitted.

> It’s another “we listened the community and nobody told us no” moment. Like Go’s telemetry issue. Go changed their telemetry to opt-in based on community feedback, so I'm not sure what point you're trying to make with that example.

No. The official statement from Brian was “I received a couple of personal e-mails from some credible people who stated that their data belonged to them, so we (I) decided to make it opt-in” (paraphrased). I spent days in that thread. That uproar was “a bunch of noisy minority which doesn’t worth listening” for them.

It's weird to see you try to make hay out of Google doing the thing you actually wanted them to do.
Post reply on HN