Hacker News Reader

>essentially all the feedback said "no, please don't". And they said "thanks for the feedback, we're gonna do it any way!"?

this is a perfectly reasonable course of action if the feedback is "please don't" but the people saying "please don't" aren't people who are actually using it or who can explain why it's necessary. it's a request for feedback, not just a poll.

> people who are actually using it

I'd presume that most of those people are using it in some capacity, it's just that their numbers are seen as too minor to influence the decision.

> explain why it's necessary

No feature is strictly necessary, so that's a pretty high standard.

> I'd presume that most of those people are using it in some capacity, it's just that their numbers are seen as too minor to influence the decision.

I think the idea of that is reasonable. If I used XSLT on my tiny, low-traffic blog, I think it's reasonable for browser devs to tell me to update my code. Even if 100 people like me said the same thing, that's still a vanishingly small portion of the web, a rounding error, protesting it.

I'd expect the protests to be disproportionate in number and loudness because the billion webmasters who couldn't care less aren't weighing in on it.

Now, I'm not saying this with a strong opinion on this specific proposal. It doesn't affect me either way. It's more about the general principle that a loud number of small webmasters opposing the move doesn't mean it's not a good idea. Like, people loudly argued about removing <marquee> back in the day, but that happened to be a great idea.

True, a small number of vocal opponents does not automatically make something a bad idea. But in these cases of compatibility, especially with something as big as the Web, the vast majority of those affected who do care will be completely silent. There's no hotline to call up the entire world and tell them to update their code.

(And if you did want to tell the entire world to update their code, and have any chance of them following through with it, you'd better make sure there's an immediate replacement ready. Log4Shell would probably still be a huge issue today if it couldn't be fixed in place by swapping out jar files.)

> If I used XSLT on my tiny, low-traffic blog, I think it's reasonable for browser devs to tell me to update my code.

I _do_ use XSLT on my tiny, low-traffic blog, and I _don't_ think that it's reasonable for browser devs to tell me to update my code.

Also, it's real easy to manufacture a situation where adoption of a thing is low when the implementation is incomplete and hasn't had significant updates for decades.

The web has grown a thousand fold over those decades, in spite of no support for XSLT. No browser has failed (or gained market traction) by missing support for (or adding more support for) XSLT. It's an irrelevancy, even if you did like it once.

Lots of content was lost when Flash was removed as well - much, much more than the amount of content that will be lost if XSLT is removed. And yet the web continued.

... in a diminished state.

The web is straight up a weaker, worse more closed off experience post-flash, so I'm not sure that this engenders the kind of response you had envisioned but now I'm worried about xslt.

You're literally commenting on a thread full of those explanations that were handwaved away.

Well, no; the reasonable course of action is to solicit feedback from the right people instead.

yeah! they should only ask for feedback from people who love XSLT, other people's opinion doesn't matter.

Google's own document says numbers don't show the full picture: https://news.ycombinator.com/item?id=44956267

They didn't even do the tiniest bit of research, as people in the discussions clearly showed, and there are high impact sites that would be affected by this including Congress and Library of Congress: https://news.ycombinator.com/item?id=44958929

Part of the reason I stopped was lack of higher than 1.0 in browsers.

The other reason is that SVG took a very long time to get good, and when it did I wanted to use XSL and SVG together.

Now SVG has got good and they are removing it :(

It would be incredible if we could pull it into the javascript/wasm sandbox and get xslt 3.0 support. The best of both worlds, at the cost of a performance hit on those pages, but not a terrible cost.

This is clearly the Right Thing. So what do you suppose the chance of it happening is?

There's even a JS implementation of XSLT 3.0 already (SaxonJS).

That's pretty cool, its too bad the license is a bit confusing about whether bundling with Chrome or Firefox would be permissible under the license.

Not really, because that would add a dependency on Javascript whereas, at the moment, XSLT works without Javascript enabled.

Not necessarily. The idea is that this is browser-internal, so presumably it would still work even if JS from external sources is disabled.

No. The idea is that website authors do the work. The proposal suggests the browsers wholesale remove support and forget about it.

https://github.com/whatwg/html/issues/11523#issuecomment-315...

Oh, I understand that that's the WHATWG proposal. I'm talking about webstrand's idea.

It comes with the XML territory that things have versioned schemas and things like namespaces, and can be programmed in XSLT. This typically means that integrations are trivial due to public, reliable contracts.

Unlike your average Angular project. Building on top of minified Typescript is rather unreasonable and integrating with JSON means you have a less than reliable data transfer protocol without schema, so validation is a crude trial and error process.

There's no elegance in raw XML et consortes, but the maturity of this family means there are also very mature tools so in practice you don't have to look at XML or XSD as text, you can just unmarshal it into your programming language of choice (that is, if you choose a suitable one) and look at it as you would some other data structure.

Google tells you what they're going to do to the web with a question mark on the end.

It's called uptalking.

Web is for all practical purposes ChromeOS, but then people complain about Apple not playing ball.

> ChromeOS is for all practical purposes, the web.

Fixed that typo for you.

> > ChromeOS is for all practical purposes, the web

I'm very practically using Debian Linux on ChromeOS to develop test and debug enterprise software. I even compile and run some native code. It is very much more than just the web.

That is a VM, and actually maybe eventually it will be on top of Webassembly, how things are going.

> That is a VM...

So is WSL on Windows. I wouldn't call Windows "just the web".

There's also nothing stopping me from building and running local desktop GUI software on the VM.

In fact, a VM is better in that I can back up and restore the image easily.

WSL and other VMs are the Year of Desktop Linux finally coming true, nothing to do with Web.

> WSL and other VMs are the Year of Desktop Linux finally coming true, nothing to do with Web.

Just like the Linux VM on ChromeOS.

Which eventually will be a VM on top of WebAssembly, given the hype.

https://webvm.io/

> Which eventually will be a VM on top of WebAssembly,

I'm not sure how that supports the argument that ChromeOS is only "the web". It's running a native VM for Linux today. What would be the advantage of porting it to WebAssembly?