I agree that to succeed RSS must be properly managed right in the browser. The problem is that it was not properly implemented inside Firefox, so I personaly didn't want to use that system.

What I want is a simple counter that show how many new posts there are of the RSS, and that's it. I only click for new content.

I am not talking about RSS, I am talking about plain old bookmarks. Browser never would give you notification when something you bookmarked changed.

The RSS feature was always kind of useless, since it required that the website provided a RSS feed to begin with, which most don't. The implementation in Firefox was also horrible on top.

HTML is a markup language, with header, datetime and article tags, parse that and do something useful with it, we don't need yet another format that duplicates the information that is already on the website.

I guess you are vastly underestimating the complexity of parsing HTML and extracting the relevant information out of it. It might seem trivial nowadays, but it falls well within https://xkcd.com/1425/ territory if you take into account that the majority of web pages are basically producing non-spec conforming (X)HTML.

And if you respond with "well, I don't care about the actual content, I just want to receive a notification when the page has changed at all", think how long would it take for every marketer use that "feature" to simply make minimal changes in the site to trick their viewers into inflating their page view numbers...

> if you take into account that the majority of web pages are basically producing non-spec conforming (X)HTML

That part is a non-issue since Browsers need to be able to turn that tag soup into a sane DOM already. And these days how to do that is well specified.

Mozilla had half a billion dollars each year to work with, I am sure they could have figured something out if they cared. But hey, instead of fixing some HTML tags lets reinvent a completely new format and require every singe website on the planet to adopt that, that'll sure work out well...

A publisher does not want countless browsers scraping arbitrary web pages just to see if they’ve changed when they can instead offer a single lightweight end point specifically for content that is intended to be updated. If browsers started doing this scraping I can only imagine the arms race.

I can only see this happening as a service. A company crawls the web—probably a search company. Their LLM classifies changes. Their users can subscribe to individual sites or pages.

Even then there are downsides to publishers including loss of some tracking information and users spending less time on their sites being subjected to advertisements.

This was part of the technical justification for RSS: concentrate all the redundant page hits in once place. But another reason was that parsing an article list from messy tables-based HTML was harder than it is today with HTML5. There's even a feed attribute `h-feed` available today, which effectively turns list pages into feeds. Nobody uses it.

The problem with the "single lightweight endpoint" is that it has to be maintained. RSS is literally a whole shadow site, with finicky XML validation to worry about on top. I've worked on multiple projects where the RSS endpoint was broken much of the time. It's both fragile and not very visible.

A solution involving client parsing of semantic markup at least has the benefit of requiring zero maintenance.

> A solution involving client parsing of semantic markup at least has the benefit of requiring zero maintenance.

This is a pipe dream. In reality your HTML markup needs just as much maintenance if not more - at least the separate feed is unbothered by design changes to the HTML site.

> There's even a feed attribute `h-feed` available today, which effectively turns list pages into feeds.

Are you referring to the microformats tags? They were never standard, and they were never meant to "turn pages into things".

Microformats, while nice and useful, were never meant to be more as compilation of certain adopted practices by the indieweb crowd.

OK I won't dispute that. The problem is that they would function nicely as a pragmatic solution to the underlying problem. Maintaining a few HTML attributes on an existing webpage is significantly easier than maintaining an RSS XML endpoint.

RSS 1.0 was created in 2000. We are talking about a time where the browser that dominated the market was Internet Explorer 5, where virtually no website would render on strict standards mode, and MS refused to introduce any significant changes if it meant breaking its compatibility mode. People realized that that asking the whole web to adopt XHTML fully would never happen, so a new XML-based format hat was separate from the webpages was needed.

(Also, a bit of a side rant: now that I am working on ActivityPub stuff I'm finding less and less sympathy for those that jump into code and push for "pragmatic" solutions. The ActivityPub spec is not perfect, but it's incredible how almost everyone implementing ActivityPub ignores JSON-LD and RDF and just want to wing with the JSON messages. It gets to the point where perfectly valid JSON-LD will get refused to anything that is not called Mastodon, because everyone else is just parsing the JSON they receive and completely ignoring @context directives)

> Also, a bit of a side rant: now that I am working on ActivityPub stuff I'm finding less and less sympathy for those that jump into code and push for "pragmatic" solutions. The ActivityPub spec is not perfect, but it's incredible how almost everyone implementing ActivityPub ignores JSON-LD and RDF and just want to wing with the JSON messages. It gets to the point where perfectly valid JSON-LD will get refused to anything that is not called Mastodon, because everyone else is just parsing the JSON they receive and completely ignoring @context directives

Maybe making everyone who wants to interact with the fediverse deal with all that complexity isn't such a great idea after all. What we really should have gotten was RSS++ with optional push notifications for new content instead of this mess. But it wouldn't be the web without reinventing the wheel for every new "standard" I guess.

But this wouldn't give you two-way interactivity, and RSS and ATOM are just different ways to go about representing RDF.

I could entertain the argument that we don't need two way interactivity, and that most of the applications would be fine by implementing their own ad-hoc API. This is exactly what is happening in the Fediverse now, where every microblogging project ends up implementing Mastodon's API and every Lemmy client goes straight up to Lemmy's API instead of getting the data from "raw" ActivityPub.

Yep I know the history, I was building sites at the time. And my own unfashionable take is that "pragmatic" HTML5 was a cop-out, it was still early days for the web and XHTML would have been worth the initial breakages.

Interesting rant about ActivityPub, you have my sympathy.

> But hey, instead of fixing some HTML tags lets reinvent a completely new format and require every singe website on the planet to adopt that, that'll sure work out well...

It worked amazingly well! It worked so well that it became a problem for the publishers when they realized the standard for syndication has become so widely adopted that people were not visiting the websites anymore and they had lost control of content gatekeeping.

> Mozilla had half a billion dollars each year to work with, I am sure they could have figured something out if they cared.

I agree with you that Mozilla has shown that they don't really care about an open web, but I think you are reversing cause and effect. RSS was already a reality when Google had to kill (*) it, and Mozilla went along with it because they never managed to get out of Google's money tit.

* Not really kill it, but just taking all the steam out of it so it wouldn't destroy their own business.