Live data from Hacker News

Google is killing the open web, part 2

wok.oblomov.eu

51–60 of 362 posts

Re: Google is killing the open web, part 2

#51

This page makes some wild claims, like Google wants to deprecate MathML, even though it basically just landed. Yeah, the Chrome team wasn't prioritizing the work and it came through Igalia, but the best time for Chrome to kill MathML would have been before it was actually usable on the web. The post also fails to mention that all browsers want to remove XSLT. The topic was brought up in several meetings by Firefox re…

I was all in on the concept of XHTML back in the day because it seemed obviously superior to chaotic, messy HTML. Nothing got me off that bandwagon as effectively as me converting a web app to emit pristine, validated XHTML and learning that no 2 browsers could process it the same way. Forget pixel-perfect layout and all that jazz. I couldn’t even get them to display the whole page reliably.

Re: Google is killing the open web, part 2

#52
I don't disagree that Google is killing the open web. But XSLT is a pretty weak argument for showing that. It is an extremely complicated feature that is very seldom used. I am very doubtful dropping support is some evil political decision. It is much more likely they just don't want to sink resources into maintaining something that is almost never used.

For the specific use case of showing RSS and Atom feeds in the browser, it seems like a better solution would be to have built-in support in the browser, rather than relying on the use of XSLT.

Re: Google is killing the open web, part 2

#53

In part 1 of this article, the author wrote, "XSLT is an essential companion to RSS, as it allows the feed itself to be perused in the browser" Actually, you can make an RSS feed user-browsable by using JavaScript instead. You can even run XSLT in JavaScript, which is what Google's polyfill does. I've written thousands of lines of XSLT. JavaScript is better than XSLT in every way, which is why JavaScript has thrived…

> JavaScript is better than XSLT in every way

Obviously not in every way. XSLT is declarative and builds pretty naturally off of HTML for someone who doesn't know any programming languages. It gives a very low-effort but fairly high power (especially considering its neglect) on-ramp to templated web pages with no build steps or special server software (e.g. PHP, Ruby) that you need to maintain. It's an extremely natural fit if you want to add new custom HTML elements. You link a template just like you link a CSS file to reuse styles. Obvious.

The equivalent Javascript functionality's documentation[0] starts going on about classes and callbacks and shadow DOM, which is by contrast not at all approachable for someone who just wants to make a web page. Obviously Javascript is necessary if you want to make a web application, but those are incredibly rare, and it's expected that you'll need a programmer if you need to make an application.

Part of the death of the open web is that the companies that control the web's direction don't care about empowering individuals to do simple things in a simple way without their involvement. Since there's no simple, open way to make your own page that people can subscribe to (RSS support having been removed from browsers instead of expanded upon for e.g. a live home page), everyone needs to be on e.g. Facebook.

It's the same with how they make it a pain to just copy your music onto your phone or backup your photos off of it, but instead you can pay them monthly for streaming and cloud storage.

[0] https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...

Re: Google is killing the open web, part 2

#54
post #44

Removing XSLT from browsers was long overdue and I'm saying that as ex-maintainer of libxslt who probably triggered (not caused) this removal. What's more interesting is that Chromium plans to switch to a Rust-based XML parser. Currently, they seem to favor xml-rs which only implements a subset of XML. So apparently, Google is willing to remove standards-compliant XML support as well. This is a lot more concerning.

> Removing XSLT from browsers was long overdue > Google is willing to remove standards-compliant XML support as well. > They're the same picture. To spell it out, "if it's inconvenient, it goes", is something that the _owner_ does. The culture of the web was "the owners are those who run the web sites, the servants are the software that provides an entry point to the web (read or publish or both)". This kind of "well…

Can you cite where this "servant-oriented" mentality is from? I don't recall a part of the web where browser developers were viewed as not having agency about what code they ship in their software.

Re: Google is killing the open web, part 2

#56
post #25

Earlier quoted context omitted.

It’s interesting to see the casual slide of Google towards almost internet explorer 5.1 style behavior, where standards can just be ignored “because market share”. Having flashbacks of “ ”

The standards body is deprecating XSLT with support from Mozilla and Safari (Mozilla first proposed the removal). Not sure how you got from that to “Google is ignoring standards”.

Probably if Mozilla didn't push for it initially XSLT would stay around for another decade or longer.

Their board syphons the little money that is left out of their "foundation + corporation" combo, and they keep cutting people from Firefox dev team every year. Of course they don't want to maintain pieces of web standards if it means extra million for their board members.

Re: Google is killing the open web, part 2

#57
post #41

Earlier quoted context omitted.

No, the idea is that "political decision" is used in opposition to a decision based on rational tradeoffs. If there isn't enough usage of a feature to justify prioritizing engineering hours to it instead of other features, so it's removed, that's just a regular business-as-usual decision. Nothing "political" about it. It's straightforward cost-benefit. However, if the decision is based on factors beyond simple cost-b…

> If there isn't enough usage of a feature to justify prioritizing engineering hours to it instead of other features, so it's removed, that's just a regular business-as-usual decision. Nothing "political" about it. It's straightforward cost-benefit. Then why is Google actively shoving multiple hardware APIs into the browser (against the objection of other vendors) if their usage is 10x less than that of XSLT? They ha…

You have to keep developing new things to see what proves useful in the long-run.

When you have something that's been around for a long time and still shows virtually no usage, it's fine to pull the plug. It's a kind of evolution. You can kill things that are proven to be unpopular, while building things and giving them the time to see if they become popular.

That's what product feature iteration is.

Re: Google is killing the open web, part 2

#58

In part 1 of this article, the author wrote, "XSLT is an essential companion to RSS, as it allows the feed itself to be perused in the browser" Actually, you can make an RSS feed user-browsable by using JavaScript instead. You can even run XSLT in JavaScript, which is what Google's polyfill does. I've written thousands of lines of XSLT. JavaScript is better than XSLT in every way, which is why JavaScript has thrived…

JavaScript is ever evolving and it means you need to stick to one of the two browsers (WebKit or Firefox) and keep upgrading. XSLT hasn't changed in years. It's an actual standard instead of an evolving one.

I know that other independent browsers that I used to use back in the day just gave up because the pace of divergence pushed by the major implementations meant that it wasn't feasible to keep up independently.

I still miss Konqueror.

Re: Google is killing the open web, part 2

#59
post #54
post #44

Earlier quoted context omitted.

> Removing XSLT from browsers was long overdue > Google is willing to remove standards-compliant XML support as well. > They're the same picture. To spell it out, "if it's inconvenient, it goes", is something that the _owner_ does. The culture of the web was "the owners are those who run the web sites, the servants are the software that provides an entry point to the web (read or publish or both)". This kind of "well…

Can you cite where this "servant-oriented" mentality is from? I don't recall a part of the web where browser developers were viewed as not having agency about what code they ship in their software.

I cannot imagine a time when browsers were "servant-oriented".

Every browser I can think of was/is subservient to some big-big-company's big-big-strategy.

Post reply on HN