Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should we remove XSLT from the web platform?

github.com

Post reply on HN
Print view View original

91–99 of 99 posts

Re: Should we remove XSLT from the web platform?

#91

Post by geocar »

ethan_smith wrote: post #24
user____name wrote: post #6

The problem with browsers is that they rely on other standards. If a browser needs to maintain backward compatibility and requires an evolving standard that ALSO requires backward compatibility, this acts like a multiplier on implementation complexity. This also means it becomes increasingly difficult to spin up a new browser engine, and the fewer of those there are, the easier it is for the big ones to just add what…

XSLT adds ~100k lines of specialized code to browser engines with near-zero telemetry usage (<0.01% of page loads), making it a prime example of the maintenance burden vs. utility problem you're describing.

> near-zero telemetry usage (Perhaps without realising it, you are still describing numbers in the hundreds of millions perhaps billions, which isn't even close to zero when you're talking about atoms:

Google does 200$ billion USD in annual ad revenue: At even a mere $1 CPM that's 200 trillion impressions a year.

They put 5 ads on every page and we're at 40 trillion page loads a year that Google knows about.

You tell me that even 0.001% of that is XML/XSLT and we're still talking hundreds of millions of page loads every year.

And that's just the ones Google knows about: Pages without Google ads like say https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih.... should definitely not be included in that telemetry at all, indicating the value should be much higher

Re: Should we remove XSLT from the web platform?

#92

Post by kixiQu »

https://maya.land/blogroll.opml

My blogroll's better-known than my actual site, and it's feed-reader compatible OPML that I've just made fun with additional attributes and XSLT. A server-side transform to vend duplicate OPML and HTML would be a bummer. I'm not an Important Web Platform user or anything, but I wish more people would share their feed-reader exports – and I've thought about trying to share tooling to extend/display them like this. It'll be sad if that ends up impossible.

Re: Should we remove XSLT from the web platform?

#93

Post by 8NNTt8z3QvLT8tp »

chrismorgan wrote: post #70
Avamander wrote: post #68

Earlier quoted context omitted.

I recall FTP support being very widespread. I'm sure JavaScript support has gone through massive changes. There have been other HTML tags deprecated. There's plenty of (security) headers that have been deprecated.

I wouldn’t call FTP part of the web platform—it was never integrated . All you could do was link to it, and then the browser might be able to render it itself (Firefox and Chromium, until a few years ago), or open another app that could (IE and Safari, and Firefox and Chromium probably can still). JavaScript has added things, not removed them. There are other HTML elements and attributes that were never in any spec a…

Mutation Events were once in all 3 moderns engines plus some legacy ones and is now removed from everything.

Third-party cookies are now heavily restricted and while not quite removed everywhere cannot be relied upon.

document.domain is no longer settable by default in Chromium, and other browsers are aligned on matching this.

There's other APIs that have been restricted to secure contexts only.

The list goes on and on, the idea that the web is this unbreakable surface isn't true. It does break things and that is a good thing, if you want the platform to succeed for decades to come they should be able to fix mistakes.

Re: Should we remove XSLT from the web platform?

#94

Post by 8NNTt8z3QvLT8tp »

account42 wrote: post #56
shiomiru wrote: post #20

Earlier quoted context omitted.

> Things can remain backwards compatible forever. This is exactly the attitude that has left us with only three complete extant implementations of the web, two of which are controlled by an ad company. Indeed, to me it seems that at some point, you either have to a) freeze the standard b) drop old stuff c) accept that there is no standard and with the web as a whole, we are firmly headed towards option c). So I find…

> This is exactly the attitude that has left us with only three complete extant implementations of the web, two of which are controlled by an ad company. No, adding complex new interfaces and then demanding that every browser implement them quickly is what does that. Google is not proposing to reign in that behavior. > a) freeze the standard Yes, or rather new features should become rarer over time. > and with the we…

Thing is the new APIs added to the web are generally quite well specified with quite good tests. These older legacy APIs sometimes don't even have a standard and almost definitely don't have interoperability (XSLT is an example of one that definitely does not work consistently between WebKit/Blink and Firefox).

For a new browser engine adding some of the new APIs is pretty trivial compared to debugging all the nonsense that comes from these kinds of underspecified legacy APIs. Removing XSLT from the spec and existing browsers means new ones don't feel the need to implement it. They don't need to decide which implementation to go with (use libxslt like chromium and webkit and you might match their behaviour but you also get all the same security vulns).

Frankly a modern engine could probably get by without handling XML entirely (aka no XHTML document support) and get by just fine but that's a separate discussion.

Re: Should we remove XSLT from the web platform?

#95

Post by myaccountonhn »

miki_oomiri wrote: post #5

The quality of the github comments: accusing developers of being dictators, being overly emotionally, the hate towards people who actually made the web happen (Smaug, Anne, Emilo, etc…), the "why not just…" or "hire more people" remarks... For a browser developer, this is depressing. I've worked on Gecko for 10+ years, and we were constantly called names for absolutely any change we would do. Insulted and accused of…

It sucks, people just doing their job should be treated with respect.

That said I can also feel like the technocratic decision making process make it so some people aren't given any voice nor choice. Its whatever the US tech giants want that decides for the rest of us.

Re: Should we remove XSLT from the web platform?

#96

Post by NoGravitas »

account42 wrote: post #38

How is the answer to any question "Should we remove X from the web platform?" where X wasn't introduced in the last week an has actual users not a resounding "No, WTF is wrong with you.".

That was the actual answer, but those comments got hidden and the discussion locked.

Re: Should we remove XSLT from the web platform?

#97

Post by mx7zysuj4xew »

dev0001 wrote: post #78
miki_oomiri wrote: post #5

The quality of the github comments: accusing developers of being dictators, being overly emotionally, the hate towards people who actually made the web happen (Smaug, Anne, Emilo, etc…), the "why not just…" or "hire more people" remarks... For a browser developer, this is depressing. I've worked on Gecko for 10+ years, and we were constantly called names for absolutely any change we would do. Insulted and accused of…

> the hate towards people who actually made the web happen (Smaug, Anne, Emilo, etc…) The vast majority of comments on https://github.com/whatwg/html/issues/11523 are polite and respectful. Also, "Smaug, Anne, Emilo" did not "make the web happen." They have influenced how the web has developed, in particular favouring functionality and uses that are dependent on Javascript, and neglecting to ensure parity of opportun…

In my own personal experience on dealing with him, Anne is an arrogant douche who quite frankly hasn't been yelled at enough

A lot of the hate is actually justified (with the exception of hixxie)

Re: Should we remove XSLT from the web platform?

#99

Post by bryanrasmussen »

I tried to comment on this just now but I was blocked as the thread has been limited to collaborators, their word not mine, but wow.

So I guess I'll put it here assuming someone reads.

Given the various comments people have about the dependencies on XSLT that various standards, applications and workflows have. I believe that the default display of XML documents in Chrome, Firefox, and I suppose Edge is handled by an XSLT.

It used to be that MSXML shipped with an XSLT (and even earlier a wd-xsl document) as a resource that was used to style any XML document for display if the XML document did not have an associated stylesheet when you opened it in IE or other views that used IE for rendering.

I believe this same thing is done by the browsers mentioned, or at least it used to be

https://stackoverflow.com/questions/9463402/default-xml-styl...

which is why when you open an XML document without styling information in those documents it is represented as a tree view with expandable collapsible nodes.

I suppose they will just implement a default rendering for XML using some other code rather than running an XSLT upon it, but this applies as well as all these edge cases of handling RSS feeds etc.

Safari does not have a stylesheet rendering for unstyled XML which is why it just shows the text nodes of the document and nothing else.

Post reply on HN