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

271–280 of 362 posts

Re: Google is killing the open web, part 2

#271

Post by oblio »

meindnoch wrote: post #171
bigyabai wrote: post #167

Earlier quoted context omitted.

Mozilla has proven they can exist in a free market; really and truly, they do compete. Safari is what I'm concerned about. Without Apple's monopoly control, Safari is guaranteed to be a dead engine. WebKit isn't well-enough supported on Linux and Windows to compete against Blink and Gecko, which suggests that Safari is the most expendable engine of the three.

>Mozilla has proven they can exist in a free market; really and truly, they do compete. This gave me a superb belly laugh.

Mozilla used to compete well but that ended... at least 10 years ago?

Re: Google is killing the open web, part 2

#272

Post by Fileformat »

kstrauser wrote: post #256
cpill wrote: post #241

Earlier quoted context omitted.

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) w…

You are absolutely right!!! But...

What about people who don't "1) Know what RSS is"???

And what if you could make it friendly for them in 4 minutes? You could by dropping in a XSLT file and adding a single line to the XML file. I bet you could do it in 3 minutes.

Re: Google is killing the open web, part 2

#273

Post by basscomm »

shadowgovt wrote: post #252
basscomm wrote: post #251

Earlier quoted context omitted.

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

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

Just having users submit links that other users can comment on doesn't make it social media. I can't follow particular users or topics, I can't leave myself a note about some user that I've had a positive or negative experience with, I can't ignore someone who I don't want to read, etc. Heck, usernames are so de-emphasized on this site that I almost always forget that they're there.

Re: Google is killing the open web, part 2

#274

Post by Fileformat »

matthews3 wrote: post #88
James_K wrote: post #83

Earlier quoted context omitted.

I use XSLT because I want my website to work for users with JavaScript disabled and I want to present my Atom feed link as an HTML document on a statically hosted site without breaking standards compliance. Hope this helps.

Could you run XSLT as part of your build process, and serve the generated HTML?

That is not the point: I already have the blog's HTML pages. I want the RSS feed to be an RSS feed, not another version of the HTML.

The XSLT view of the RSS feed so people (especially newcomers) aren't met with a wall of XML text. It should still be a valid XML feed.

Plus it needs to work with static site generators.

Re: Google is killing the open web, part 2

#275

Post by shadowgovt »

basscomm wrote: post #273
shadowgovt wrote: post #252

Earlier quoted context omitted.

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

> The relevant use case is you come here to see links people share and comment on them. That's sufficiently "social" in this context. Just having users submit links that other users can comment on doesn't make it social media. I can't follow particular users or topics, I can't leave myself a note about some user that I've had a positive or negative experience with, I can't ignore someone who I don't want to read, etc…

A rose by any other name. If you'd prefer I'd have said

"But for keeping up to date on news, people use link aggregation boards where other users post links to stuff on the web and then talk to each other about them. 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 Hacker News."

... that would be the same point. RSS, by itself, is a protocol for finding out some site created new content and is just not particularly compelling by itself for the average user when they can use "link aggregation boards where other users post links to stuff on the web and then talk to each othe about them" instead.

Re: Google is killing the open web, part 2

#276

Post by pas »

glenstein wrote: post #237
akerl_ wrote: post #209

Earlier quoted context omitted.

Is it often multi-stakeholder? Debian has bureaucracy and a set group of people with commit permissions. VLC likewise has the VideoLAN organization. LibreOffice has The Document Foundation. It seems like most open source projects either have: 1. A singular developer, who controls what contributions are accepted and sets the direction of the project 2. An in-group / foundation / organization / etc that does the same.…

A lot of the governance structures with "foundation" in their name, e.g. Apache Foundation, Linux Foundation, Rust Foundation, involve some combination of corporate parties, maintainers, independent contributors without any singularly corporate heavy hand responsible for their momentum. I don't know that road maps are any more or less "community driven" than anything else given the nature of their structures, but one…

Chromium can be forked (probably there are already a bunch of degoogled ones) to keep Manifest v2

what's missing is social infrastructure to direct attention to this (and maybe it's missing because people are too dumb when it comes to adblockers, or they are not bothered that much, or ...)

and of course, also maintaining a fork that does the usual convenience features/services that Google couples to Chrome is hard and obviously this has antitrust implications, but nowadays not enough people care about this either

Re: Google is killing the open web, part 2

#277

Post by shadowgovt »

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.

Then the server should supply the right format based on the `Accept` header, be it `application/rss+xml` or `application/atom+xml` or `text/xml` or `text/html`.

Even cheaper than shipping the client an XML and an XSLT is just shipping them the HTML the XSLT would output in the first place.

Re: Google is killing the open web, part 2

#278

Post by Fileformat »

cpill wrote: post #244
James_K wrote: post #83

Earlier quoted context omitted.

I use XSLT because I want my website to work for users with JavaScript disabled and I want to present my Atom feed link as an HTML document on a statically hosted site without breaking standards compliance. Hope this helps.

Yeah, but WHY? If they are on the website, why would they want to look at the feed for the website, on the website, in the browser instead of just looking at the website? If the feed is so amazing, why have the website in the first place? Oh yeah, you need something to make the feed off :D

I don't want the feed to look amazing. I just don't want to present a wall of XML text to non-technical users who don't know what an RSS feed is!

Re: Google is killing the open web, part 2

#280

Post by _heimdall »

akerl_ wrote: post #215
_heimdall wrote: post #213

Earlier quoted context omitted.

By browser vendors, you mean? Yes it seems like they were in agreement and many here seem to think that was largely driven by google though that's speculation. Users and web developers seemed much less on board though[1][2], enough that Google referenced that in their announcement. [1] https://github.com/whatwg/html/issues/11578 [2] https://github.com/whatwg/html/issues/11523

Yes, that's what I mean. In this comment tree, you've said: > google has been the party leading the charge arguing for the removal. and > many here seem to think that was largely driven by google though that's speculation I'm saying that I don't see any evidence that this was "driven by google". All the evidence I see is that Google, Mozilla, and Apple were all pretty immediately in agreement that removing XSLT was t…

In the github issues I have followed, including those linked above, I primarily saw Google engineers arguing for removing XSLT from the spec. I'm not saying they are the sole architects of the spec removal, and I'm not claiming to have seen all related discussions.

I am sharing my view, though, that Google engineers have been the majority share of browser engineer comments I've seen arguing for removing XSLT.

Post reply on HN