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

251–260 of 362 posts

Re: Google is killing the open web, part 2

#251

Post by basscomm »

shadowgovt wrote: post #246
basscomm wrote: post #231

Earlier quoted context omitted.

> But for keeping up to date on news, people use social media. RSS isn't the missing piece of the puzzle for changing that, an app on top of RSS is. And in the absence of Reader, nothing has shown up to fill that role that can compete with just trading gossip on Facebook. I guess if you don't use social media or facebook you're out of luck?

I don't see why. You can always subscribe to a newspaper. Or just use RSS and a subscription tool since it didn't just go away. What I'm saying, though, is if you don't use social media at this point you're already an outlier (I am, it should be noted, using the term broadly: you are using social media. Right now. Hacker News is in the same category as Facebook, Twitter, Mastodon, et. al. in this context: it's a plac…

> You can always subscribe to a newspaper.

The circulation for my local newspaper is so small that they now get printed at a press a hundred miles away and are shipped in every morning to the handful of subscribers who are left. I don't even know the last time I saw a physical newspaper in person.

> Hacker News... it's a place you go to get information instead of using a collection of RSS feeds

No, it's a place I go to _in addition_ to RSS feeds. An anonymous news aggregator with web forum attached isn't really social media. Maybe some people hang out here to socialize, but that's not a use case for me

Re: Google is killing the open web, part 2

#252

Post by shadowgovt »

basscomm wrote: post #251
shadowgovt wrote: post #246

Earlier quoted context omitted.

I don't see why. You can always subscribe to a newspaper. Or just use RSS and a subscription tool since it didn't just go away. What I'm saying, though, is if you don't use social media at this point you're already an outlier (I am, it should be noted, using the term broadly: you are using social media. Right now. Hacker News is in the same category as Facebook, Twitter, Mastodon, et. al. in this context: it's a plac…

> You can always subscribe to a newspaper. The circulation for my local newspaper is so small that they now get printed at a press a hundred miles away and are shipped in every morning to the handful of subscribers who are left. I don't even know the last time I saw a physical newspaper in person. > Hacker News... it's a place you go to get information instead of using a collection of RSS feeds No, it's a place I go…

The relevant use case is you come here to see links people share and comment on them. That's sufficiently "social" in this context.

Contrasting the other use case you dabble in (that makes you an outlier) of pulling content from specific sources (I'm going to assume generating original content, not themselves link aggregators, otherwise this topic is moot) via RSS. Most people see that as redundant if they have access to something like HN, or Fark, or Reddit, or Facebook. RSS readers alone, in general, don't let you share your thoughts with other people reading the article, so it's not as popular a tool.

Re: Google is killing the open web, part 2

#253

Post by koakuma-chan »

ErroneousBosh wrote: post #111
koakuma-chan wrote: post #69

Earlier quoted context omitted.

I worked for a company where I had to make screenshots every minute and upload them via FTP for review to get paid. If there was multiple screenshots with the same thing on the screen, there would be questions.

Did you do any work besides taking screenshots and trying to figure out why FTP was broken this time? Your old job's broken workflow is not a good reason for keeping a fundamentally broken protocol that relies on allowing Remote Code Execution as a privileged user around.

I wrote a tool that took screenshots automatically and used FileZilla to upload :) And my comment is in support of removing FTP because it was lame.

Re: Google is killing the open web, part 2

#254

Post by ErroneousBosh »

kuschku wrote: post #173
shadowgovt wrote: post #165

Earlier quoted context omitted.

So put them on separate pages because they are separate protocols (HTML for the browser and XML for a feed reader), with a link on the HTML page to be copied and pasted into a feed reader. It really feels like the developer has over-constrained the problem to work with browsers as they are right now in this context.

> So put them on separate pages because they are separate protocols Would you also suggest I use separate URLs for HTTP/2 and HTTP/1.1? Maybe for a gzipped response vs a raw response? It's the same content, just supplied in a different format. It should be the same URL.

> Would you also suggest I use separate URLs for HTTP/2 and HTTP/1.1? Maybe for a gzipped response vs a raw response?

The difference between HTTP/2 and HTTP/1.1 is exactly like the difference between plugging your PC in with a green cable or a red cable. The client neither knows nor cares.

> It's the same content, just supplied in a different format. It should be the same URL.

So what do I put as the URL of an MP3 and an Ogg of the same song? It's the same content, just supplied in a different format.

Re: Google is killing the open web, part 2

#255

Post by kuschku »

ErroneousBosh wrote: post #254
kuschku wrote: post #173

Earlier quoted context omitted.

> So put them on separate pages because they are separate protocols Would you also suggest I use separate URLs for HTTP/2 and HTTP/1.1? Maybe for a gzipped response vs a raw response? It's the same content, just supplied in a different format. It should be the same URL.

> Would you also suggest I use separate URLs for HTTP/2 and HTTP/1.1? Maybe for a gzipped response vs a raw response? The difference between HTTP/2 and HTTP/1.1 is exactly like the difference between plugging your PC in with a green cable or a red cable. The client neither knows nor cares. > It's the same content, just supplied in a different format. It should be the same URL. So what do I put as the URL of an MP3 an…

> The difference between HTTP/2 and HTTP/1.1 is exactly like the difference between plugging your PC in with a green cable or a red cable. The client neither knows nor cares.

Just like protocol negotiation, HTTP has format negotiation and XML postprocessing for exactly the same reason.

> So what do I put as the URL of an MP3 and an Ogg of the same song? It's the same content, just supplied in a different format

Whatever you want? If I access example.org/example.png, most websites will return a webp or avif instead if my browser supports it.

Similarly, it makes sense to return an XML with XSLT for most browsers and a degraded experience with just a simple text file for legacy browsers such as NCSA Mosaic or 2027's Google Chrome.

Re: Google is killing the open web, part 2

#256

Post by kstrauser »

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?!

I just checked and I’ve had 3 hits for my blog’s RSS feed from a legit-looking browser user agent string this year. Almost literally no one reads my site via RSS in the browser. Quite a few people fetch the feed from separate clients.

I wouldn’t spend 5 minutes making that feed look pretty for browser users because no one will ever see it. I don’t know who these mythical visitors are who 1) know what RSS is and 2) want to look at it in Chrome or Safari or Firefox.

Re: Google is killing the open web, part 2

#257

Post by troupo »

kstrauser wrote: post #46
Aurornis wrote: post #22

Earlier quoted context omitted.

> Also, "no one uses it" is rich considering that XSLT's usage is 10x the usage of features Google has no trouble shoving into the browser and maintaining. Compare XSLT https://chromestatus.com/metrics/feature/timeline/popularity ... with … Comparing absolute usage of an old standard to newer niche features isn’t useful. The USB feature is niche, but very useful and helpful for pages setting up a device. I wouldn’t e…

Furthermore, you can’t polyfill USB support. It’s something that the browser itself must support if it’s going to be used at all, as by definition it can’t run entirely inside the browser. That’s not true for XSLT, except in the super-niche case of formatting RSS prettily via linking to XSLT like a stylesheet, and the intersection of “people who consume RSS” and “people who regularly consume it directly through the b…

> Furthermore, you can’t polyfill USB support.

You can't polyfill many things. Should we just dump everything into the browser? Well, Google certainly thinks so. But that makes the question about "but this feature is unused, why support it" moot.

And Google has no intention to support a polyfill, or ship it with the browser. The same person who didn't even know that XSLT is used on podcast sites scribbled together some code, said "here, it's easy", and that's it.

And the main metric they use for deprecations is the number of sites/page uses. So even that doesn't work in favor of all the hardware APIs (and a few hundred others) that Google just shoved into the browser.

At least there's consensus on removing XSLT, right? But there are many, many objections about USB, HID, etc. And still that doesn't stop Google from developing, shipping and maintaining them.

Basically, the entire discussion around XSLT struck a nerve partly because all of the arguments can immediately be applied to any number of APIs that browsers, and especially Chrome, have no trouble shipping. And that comes on top of the mismanaged disaster that was the attempt to remove alert/confirm several years ago (also, "used on few sites", "security risk", "simpler code", "full browser consensus" etc.)

Re: Google is killing the open web, part 2

#258

Post by troupo »

coldpie wrote: post #70
troupo wrote: post #15

Earlier quoted context omitted.

> It's a dead format that no one uses[1], This has to be proven by Google (and other browser vendors), not by people coming up with examples. The guy pushing "intent to deprecate" didn't even know about the most popular current usage (displaying podcast RSS feeds) until after posting the issue and until after people started posting examples: https://github.com/whatwg/html/issues/11523#issuecomment-315... Meanwhile Go…

> This has to be proven by Google (and other browser vendors), not by people coming up with examples What, to you, would constitute sufficient proof? Is it feasible to gather the evidence your suggestion would require?

> What, to you, would constitute sufficient proof? Is it feasible to gather the evidence your suggestion would require?

Let me quote from my comment, again:

--- start quote ---

The guy pushing "intent to deprecate" didn't even know about the most popular current usage (displaying podcast RSS feeds) until after posting the issue and until after people started posting examples

--- end quote ---

I would like to see more evidence than "we couldn't care less, remove it" before a consensus on removal, before an "intent to deprecate" and before opening a PR to Chrome removing the feature.

Funnily enough, even the "browser consensus" looks like this: "WebKit is cautiously supportive. We'd probably wait for one implementation to fully remove support": https://github.com/whatwg/html/issues/11523#issuecomment-314...

BTW. Literally the only "evidence" originally presented was "nearly 100% of sites use JS, while 1/10000 of those use XSLT.": https://github.com/whatwg/html/issues/11523#issuecomment-315... which was immediately called into question: https://github.com/whatwg/html/issues/11523#issuecomment-315... and https://github.com/whatwg/html/issues/11523#issuecomment-315... and that's before we account for google's own docs saying they have a blind spot in the enterprise/corporate setting where people suspect the usage may be higher.

Also, as I say. I think the main issue isn't XSLT itself. XSLT is a symptom.

Re: Google is killing the open web, part 2

#259

Post by crabmusket »

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.

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.

Re: Google is killing the open web, part 2

#260

Post by kstrauser »

basscomm wrote: post #242
et1337 wrote: post #76

I’m no Google fan, but deprecating XSLT is a rare opportunity to shrink the surface area of the web’s “API” without upsetting too many people. It would be one less thing for independent browsers like Ladybird to worry about. Thus actually weakening Google’s chokehold on the browser market.

> but deprecating XSLT is a rare opportunity to shrink the surface area of the web’s “API” without upsetting too many people There's a lot of back and forth on every discussion about XSLT removal. I don't know if I would categorize that as 'without upsetting too many people'

We are largely the nerds that other nerds picked on for being too nerdy. I’d bet that a hugely disproportionate share of all the people in the world who care about this subject at all are here in these conversations.
Post reply on HN