Hacker News Reader

Comment by grumbel | Hacker News Reader

Meanwhile if put a podcast URL into my Webbrowser I just get a bunch of raw XML. I never liked that RSS, while having some nice properties, exists as this awkward thing next to the Web, but isn't really part of the Web.

What RSS is doing feels like something that should be done with just a few extra HTML tags, not a completely new format. But the idea of HTML as markup language feels kind of lost these days.

View on HN

While it’s not necessarily simple to do so, having a raw unstyled xml feed is a choice not a requirement. You _can_ style rss feeds: https://darekkay.com/blog/rss-styling/

Oh boy does that bring back memories. Yahoo’s “portal” used to compose itself based on a bunch of RSS (or was it ATOM) feeds, both user submitted and in-house. If you build your feed in just the right way, yahoo would transform it using your XSLT and display the output. Bam, now you could make your feed look all cool and custom inside Yahoo portal.

And boy does this bring back the memories of XSLT. I’m kinda glad I forgot about that abomination.

> if put a podcast URL into my Webbrowser I just get a bunch of raw XML

And if I put a web URL into my telnet client I just get a bunch of raw HTTP! Not everything on the internet is part of the web. There have always been other protocols: IMAP/SMTP for email, IRC for chat, NNTP for newsgroups, XMPP for instant messaging, and RSS for subscriptions.

The idea that everything has to be done over the web is what’s really undermined “the idea of HTML as a markup language”. If HTML is a markup language, why would you use it for all these other use cases, most of which were handled with much better performance on hardware from twenty years ago?

The difference is that every computer comes with a app where you can copy-paste that URL and see the full website. With RSS, you first need to find and install a 3rd party software to view it and/or create an account on a website.

This was one feature I really liked about the old Opera. I seem to recall being able to look at an RSS feed and it applied a basic style to it from the get-go, as it had baked-in RSS support.

That’s mostly because tech companies have been trying to kill open protocols like RSS in order to lock people into their proprietary platforms.

That doesn't answer why Firefox doesn't have RSS support anymore though (removed in 2018)

I don’t think Firefox continuing to support RSS would have made a difference. It makes sense for Mozilla to prioritize features that users actually want over trying to maintain some idealistic vision that was already dead.

Not disagreeing entirely, but don't forget that you used to be able to type ftp://example.com and gopher://example.com into the url to access sites. I think there were others as well. Most browsers have removed those protocols.

As you point out, ftp and gopher were, at one point in time, also used to transfer websites, so the inclusion was supportive of the web directive.

But have browsers ever widely attempted to be anything other than web browsers? A couple of vendors tried including RSS support at one point, but I don't recall it catching on across the industry.

Media (images, audio, video) browsers, maybe. Technically that is not HTML, but still rendered by most browsers. However, as that content can also be embedded in HTML, requiring browser support to be present anyway, it is a bit grey area.

Late versions of Netscape and early versions of Mozilla included email clients. Mozilla later split the email client and web browser into two separate programs, Thunderbird and Firebird. Firebird became Firefox.

And Usenet! That never caught on either, though. We've had more web browsers with RSS support than web browsers with email support.

Didn’t they also include calendaring at some point?

Didn’t JZW once famously say all software grows until it eventually has an email client?

You're thinking of Mozilla Sunbird.

https://en.wikipedia.org/wiki/Mozilla_Sunbird

Netscape Communicator included a calendar at one point.

Opera was also a mail client and IRC client at one point.

> As you point out, ftp and gopher were, at one point in time, also used to transfer websites, so the inclusion was supportive of the web directive.

for blogging, RSS is a mechanism to transfer webpages. so shouldn't this apply?

Last time I looked at RSS the transfer was bound to happen over HTTP. RSS is more like a web alternative. You can link from RSS to web pages, sure, but you can also link to web pages from Word documents. Perhaps browsers should all natively support .docx too?

Although you ultimately raise a good point. Most browsers do support PDF. That's the wide attempt to be something other than a web browser that I was forgetting about earlier. So, there you go, there is precedence.

Although there is still that pesky problem of most people not wanting to use RSS. Apple had good in-browser support for RSS there for a while but they found nobody used it. If Apple can't convince Average Joe to use something, it isn't likely anyone can. RSS has remained relevant for podcasts only because it has found a place in server-to-server syndication. Average Joe isn't visiting Harmony Harold's personal website to subscribe to his podcast either.

I have a vague recollection of putting rss urls into Netscape and it would style it in a readable form by default. It’s too bad that feature was lost.

Safari used to do that too. It was so nice being able to use Safari as my RSS reader—I would actually click on the original post link in each new story to read it on the original site which helped retain the personality of the blogs. It made me sad when Safari dropped that functionality.

Ye Firefox had a reasonable viewer too.

https://evertpot.com/firefox-rss/

If someone adds a reference to XSLT template to their RSS feed's header, they can style the page however they want. I rarely see anyone doing that, but if consumers of podcast RSS feeds were asking for something different, it is fairly trivial for the producers to style it.

Are they distributed with "http://" despite not following that protocol? I don't know what goes into making a new protocol specifier, but if podcast thingy is a protocol that we like then maybe we ought to do something like podcast:// so the right app can be summoned rather than having your browser do its best.

Despite the name, for over 95% of its existence, HTTP has served way more than just HTML

I'm aware, but maybe that should change. It's not really suited for much if what it is used for.

The Indieweb called "sidefiles" an antipattern, mostly because a strong allergy to DRY. I find it a little bit overblown and sometimes suspect it is a result of Tantek Çelik’s CMS.

https://indieweb.org/sidefile-antipattern

But of course there were ideas to embed the feed data structure directly in HTML as attributes.

In the indieweb/microformats corner there is h-feed which could simply be extended with rel=enclosure links for an embedded podcast feed.

https://indieweb.org/h-feed

And more formal side you could use RFDa/Microdata and the schema.org vocabulary to annotate the HTML with the logical properties of a feed and podcast episodes:

https://schema.org/PodcastEpisode

Of course there aren’t any podcatchers with understand these vocabularies.

...

I’m a little bit torn. I love good minimal markup and have a soft spot for the idea of RDFa. An early 2000s idealist. But the real world is different.

Netscape’s original RSS came out of a clear need: the markup for table layout of the late 90s was shit and not generally parsable. Which is the same thing today: Today’s markup a wastelands of nested divs which are not generally parsable and often generated by tools nobody really has control over. Just today I had to wade through a Wordpress site builder plugin and its crappy visually generated HTML. That’s the majority of the web, sadly.

Reply on news.ycombinator.com