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

261–270 of 362 posts

Re: Google is killing the open web, part 2

#261

Post by troupo »

amarant wrote: post #118
Aurornis wrote: post #36

Earlier quoted context omitted.

I don’t get the comparison. The XSLT deprecation has support beyond Google.

It's just ill-informed ideological thinking. People see Google doing anything and automatically assume it's a bad thing and that it's only happening because Google are evil. HN has historically been relatively free of such dogma, but it seems times are changing, even here

Safari is "cautiously supportive", waiting for someone else to remove support.

Google does lead the charge on it, immediately having a PR to remove it from Chromium and stating intent to remove even though the guy pushing it didn't even know about XSLT uses before he even opened either of them.

XSLT is a symptom of how browser vendors approach the web these days. And yes, Google are the worst of them.

Re: Google is killing the open web, part 2

#262

Post by troupo »

akerl_ wrote: post #54
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…

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.

It's literal W3C policy: https://www.w3.org/TR/html-design-principles/#priority-of-co...

--- start quote ---

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once.

--- end quote ---

However, the needs of browser implementers have long been the one and only priority.

Oh. It's also Google's own policy for deprecation: https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS...

--- start quote ---

First and foremost we have a responsibility to users of Chromium-based browsers to ensure they can expect the web at large to continue to work correctly.

The primary signal we use is the fraction of page views impacted in Chrome, usually computed via Blink’s UseCounter UMA metrics. As a general rule of thumb, 0.1% of PageVisits (1 in 1000) is large, while 0.001% is considered small but non-trivial. Anything below about 0.00001% (1 in 10 million) is generally considered trivial. There are around 771 billion web pages viewed in Chrome every month (not counting other Chromium-based browsers). So seriously breaking even 0.0001% still results in someone being frustrated every 3 seconds, and so not to be taken lightly!

--- end quote ---

Re: Google is killing the open web, part 2

#263

Post by akerl_ »

crabmusket wrote: post #259
akerl_ wrote: post #54

Earlier quoted context omitted.

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.

https://datatracker.ietf.org/doc/html/rfc8890 > The Internet is for End Users > This document explains why the IAB believes that, when there is a conflict between the interests of end users of the Internet and other parties, IETF decisions should favor end users. It also explores how the IETF can more effectively achieve this.

It feels like maybe the disconnect here is with what "servant" means, and with this quote: "the servants are the software that provides an entry point to the web (read or publish or both)".

The RFC8890 doesn't suggest anything that overlaps with my understanding of what the word "servant" means or implies. The library in my town endeavors to make decisions that promote the knowledge and education of people in my town. But I wouldn't characterize them as having a "servant-mindset". Maybe the person above meant "service"?

FWIW, Google/Mozilla/Apple appear to believe they're making the correct decision for the benefit of end users, by removing code that is infrequently used, unmaintained, and thus primarily a security risk for the majority of their users.

Re: Google is killing the open web, part 2

#264

Post by rhdunn »

overgard wrote: post #175

This guy seems pretty focused on XML based standards, but I think the reason XML based standards are dying is because people don't like working with XML.

The entire publishing and standards industries are built around XML (JATS and other XML formats). They use XSLT to generate HTML, PDF, EPUB, and other format files.

I don't see the XML-based SVG image format going anywhere.

The ODF, EPUB, and other formats also use XML. Those are not dying.

Re: Google is killing the open web, part 2

#265

Post by akerl_ »

troupo wrote: post #262
akerl_ wrote: post #54

Earlier quoted context omitted.

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.

It's literal W3C policy: https://www.w3.org/TR/html-design-principles/#priority-of-co... --- start quote --- In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight…

I put this in a parallel thread, but maybe this is a linguistic gap between "servant", a person who does what they are told and has very limited agency within the bounds of their instructions, and "service", where you do things for the benefit of another entity.

None of the above reads like a "servant-oriented mindset". It reads like "this is the framework by which we decide what's valuable". And by that framework, they're saying that keeping XSLT around is not the right call. You can disagree with that, but nothing you've quoted suggests that they're trying to prioritize any group over the majority of their users.

Re: Google is killing the open web, part 2

#266

Post by altmind »

ErroneousBosh wrote: post #107
altmind wrote: post #9

Do you remember that chrome lost FTP support recently? The protocol was widely used and simple enough.

"Was" is the key here. FTP has been obsolete for 20 years.

People are confusing obsolete with stable and feature complete.

Re: Google is killing the open web, part 2

#267

Post by altmind »

chb wrote: post #19
altmind wrote: post #9

Do you remember that chrome lost FTP support recently? The protocol was widely used and simple enough.

Widely used? By whom? Devs who don't understand rsync or scp? Give me a practical scenario where a box is running FTP but not SSH. Edit: then account for the fact that this rare breed of content uploader doesn't use an FTP client... there's absolutely no reason to have FTP client code in a browser. It's an attack surface that is utterly unnecessary.

People who navigate ftp storage maybe? Like Linux repos?

Re: Google is killing the open web, part 2

#268

Post by Fileformat »

cpill wrote: post #241
Fileformat wrote: post #131

Earlier quoted context omitted.

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/

yes, but why??? Your on the website and you have a link to the syndicated feed, for the website your on, and you want to make they feed look good in the browser... so they can click the link to the website _you are already on_??? The argument you should be looking at the feed XML in the browser instead of the website is bonkers. They are not meant to replace the website coz if they were why have the website?!

But you are tech-savvy and know about RSS & feed readers and such like!

Think about it from a non-technical user's perspective: they click on a RSS link and get a wall of XML text. What are they going to do? Back button and move on. How are they ever going to get introduced to RSS and feed readers and such like?

I think a lot of feeds never get hit by a browser because there isn't a hyperlink to them. For example: HN has feeds, but no link in the HTML body, so I'm pretty confident they don't get browser hits. And no one who doesn't already know about feeds will ever use them.

Re: Google is killing the open web, part 2

#269

Post by spankalee »

zzo38computer wrote: post #239
spankalee wrote: post #45

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…

XHTML does have some advantages compared with ordinary HTML, such as the parsing being more consistent, since the file will specify where literal text is used and which commands are or are not a block that is expected to contain other things. (It could still try to render in case of an error, but display the error message as well, perhaps.)

HTML parsing is specified, including what to do for various errors, and very consistent across browsers. XML parsing may be more regular, but that's not really an advantage to users in any way, while HTML's resiliency is.

Re: Google is killing the open web, part 2

#270

Post by righthand »

kuschku wrote: post #199
matthews3 wrote: post #196

Earlier quoted context omitted.

> Which build process are you talking about? The one in the comment I replied to.

Fair, but that shows the issue at hand, doesn't it? XSLT is a general solution, while most alternatives are relatively specific solutions. (Though I've written repeatedly about my preferred alternative to XSLT)

> (Though I've written repeatedly about my preferred alternative to XSLT)

Link to example?

Post reply on HN