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

Google is killing the open web, part 2

wok.oblomov.eu

Post reply on HN
Print view View original

131–140 of 362 posts

Re: Google is killing the open web, part 2

#131

Post by Fileformat »

Aurornis wrote: post #16

I have yet to read an article complaining about XSLT deprecation from someone who can explain why they actually used it and why it’s important to them. > I will keep using XSLT, and in fact will look for new opportunities to rely on it. This is the closest I’ve seen, but it’s not an explanation of why it was important before the deprecation. It’s a declaration that they’re using it as an act of rebellion.

Making RSS/Atom feeds friendly to new users is key for its adoption, and for the open web. XSLT is the best way to do that.

I made a website to promote doing using XSLT for RSS/Atom feeds. Look at the before/after screenshots: which one will scare off a non-techie user?

https://www.rss.style/

Re: Google is killing the open web, part 2

#132

Post by shadowgovt »

I don't think I'm plugged into the side of the Internet that considers XML "the backbone of an independent web."

I think XML has some good features, but in general infatuation with it as either a key representation or key transmission protocol has waned over the years. Everything I see on the wire these days is JSON or some flavor of binary RPC like protobuffer; I hardly ever see XML on the wire anymore.

Re: Google is killing the open web, part 2

#133

Post by coldpie »

lunar_mycroft wrote: post #101
coldpie wrote: post #49

Earlier quoted context omitted.

> Browser makers choosing to break that "contract" is bad for the internet regardless of how popular XSLT is. No, this is wrong. Maintaining XSLT support has a cost, both in providing an attack surface and in employee-hours just to keep it around. Suppose it is not used at all, then removing it would be unquestionably good, as cost & attack surface would go down with no downside. Obviously it's not the case that it h…

I want to start out by noting that despite both the linked article the very comment you're replying to pointing out that the security excuse is transparently bad faith, you still trotted it out, again . And no, it really isn't a cost benefit question. Or if you'd prefer, the _indirect_ costs of breaking backwards compatibility are much higher than the _direct_ cost. As it stood, as a web developer you only needed to…

> security excuse is transparently bad faith, you still trotted it out

I don't see any evidence supporting your assertion of them acting in bad faith, so I didn't reply to the point. Sandboxes are not perfect, they don't transform insecure code into perfectly secure code. And as I've said, it's not only a security risk, it's also a maintenance cost: maintaining the integration, building the software, and testing it, is not free either.

It's fine to disagree on the costs/benefits and where you draw the line on supporting the removal, but fundamentally it's just a cost-benefit question. I don't see anyone at Chrome acting in bad faith with regards to XSLT removal. The drama here is really overblown.

> the _indirect_ costs of breaking backwards compatibility are much higher than the _direct_ cost ... If the browser makers can decide to deprecate those standards, developers have to instead attempt to divine whether or not the features they want to use will remain popular.

This seems overly dramatic. It's a small streamlining of an important software, by removing an expensive feature with almost zero usage. No one actually cares about this feature, they just like screaming at Google. (To be fair, so do I! But you gotta pick your battles, and this particular argument is a dud.)

Re: Google is killing the open web, part 2

#134

Post by James_K »

ErroneousBosh wrote: post #102
James_K wrote: post #95

Earlier quoted context omitted.

No because then it would not be an Atom feed. Atom is a syndication format, the successor to RSS. I must provide users with a link to a valid Atom XML document, and I want them to see a web page when this link is clicked. This is why so many people find this objectionable. If you want to have a basic blog, you need some HTML docments and and RSS/Atom feed. The technologies required to do this are HTML for the documen…

> Google is now removing one of those technologies, which makes it essentially impossible to serve a truly static website. How so? You're just generating static pages. Generate ones that work.

You cannot generate a valid RRS/Atom document which also renders as HTML.

Re: Google is killing the open web, part 2

#135

Post by inejge »

zetafunction wrote: post #67
nwellnhof wrote: post #20

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.

https://issues.chromium.org/issues/451401343 tracks work needed in the upstream xml-rs repository, so it seems like the team is working on addressing issues that would affect standards compliance. Disclaimer: I work on Chrome and have occasionally dabbled in libxml2/libxslt in the past, but I'm not directly involved in any of the current work.

I hope they will also work on speeding it up a bit. I needed to go through 25-30 MB SAML metadata dumps, and an xml-rs pull parser took 3x more time than the equivalent in Python (using libxml2 internally, I think.) I rewrote it all with quick-xml and got a 7-8x speedup over Python, i.e., at least 20x over xml-rs.

Re: Google is killing the open web, part 2

#136

Post by fabrice_d »

Ygg2 wrote: post #73
zetafunction wrote: post #67

Earlier quoted context omitted.

https://issues.chromium.org/issues/451401343 tracks work needed in the upstream xml-rs repository, so it seems like the team is working on addressing issues that would affect standards compliance. Disclaimer: I work on Chrome and have occasionally dabbled in libxml2/libxslt in the past, but I'm not directly involved in any of the current work.

Wait. They are going along with a XML parser that supports DOCTYPES? I get XSLT is ancient and full of exploits, but so is DOCTYPE. Literally poster boy for billion laughs attack (among other vectors).

The billion laughs attack has well known solutions (basically, don't recurse too deep). It's not a reason to not implement DOCTYPE support.

Re: Google is killing the open web, part 2

#137

Post by glenstein »

charcircuit wrote: post #64

>Mozilla bent over to Google's pressure to kill off RSS by removing the “Live Bookmarks” features from the browser They both were just responding to similar market demands because end users didn't want to use RSS. Users want to use social media instead. >This is a trillion-dollar ad company who has been actively destroying the open web for over a decade Google has both done more for and invested more into progressing…

>Google has both done more for and invested more into progressing the open web than anyone else.

One could also make that case about Microsoft with Microsoft office in the '90s. Embrace extend extinguish always involves being a contributor in the beginning.

>Blink is open source and modular. Maintaining a fork is much less effort than the alternative of maintaining a different browser engine.

Yeah and winning Asia Physical 100 is easier than winning a World's Strongest Man competition, and standing in a frying pan is preferable to jumping in a fire.

I'm baffled by appeals to the open source nature of Blink and Chromium to suggest that they're positive indicators of an open web that any random Joe could jump in and participate in. That's only the case if you're capable of the monumental weightlifting that comes with the task.

Re: Google is killing the open web, part 2

#138

Post by Attrecomet »

troupo wrote: post #41
crazygringo wrote: post #12

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…

WebSerial and WebUSB are the best thing to happen to browsers since sliced bread. Just because you can't see why it's amazing that users won't need to give some random, badly supported driver SYSTEM/root privileges to run their specialized hardware -- encompassing hobbyist, educational and professional uses -- doesn't mean it's not obviously useful, and Mozilla's stance on keeping it out of Firefox will just harm their market share in these area -- education probably being the most hurtful.

From what I gather here, XSLT's functionality OTOH is easily replaced, and unlike the useful hardware support you're raging against, is a behemoth to support.

Re: Google is killing the open web, part 2

#139

Post by matwood »

munificent wrote: post #86
ndriscoll wrote: post #53

Earlier quoted context omitted.

> 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 natu…

> XSLT is declarative and builds pretty naturally off of HTML for someone who doesn't know any programming languages. Have you ever met a single non-programmer who successfully picked up XSLT of their own volition and used it productively? I'd be willing to bet good money that the Venn diagram of users that fit the intersection of "authoring content for the web", "care about separating content from HTML", "comfortabl…

> Have you ever met a single non-programmer who successfully picked up XSLT of their own volition and used it productively?

Admittedly this was 20ish years ago, but I used to teach the business analysts XSLT so they could create/edit/format their own reports.

At the time Crystal Reports had become crazy expensive so I developed a system that would send the data to the browser as XML and then an XSLT to format the report. It provided basic interactivity and could be edited by people other than me. Also, if I remember, at the time it only worked in IE because it was the only browser with the transform function.

Re: Google is killing the open web, part 2

#140

Post by croes »

Aurornis wrote: post #109
svieira wrote: 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…

> 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 is an attempt to rewrite history. Early browser like NCSA Mosaic were never even released as Open Source Software. Netscape Navigator made headlines by offering a free version for academic or non-profit use, but they wanted to charge as much a…

The web wasn’t the browser it was the protocols.
Post reply on HN