Fileformat

It isn't especially mobile-friendly, but the (fake) scrollbar works for me on Android.

Slop warning: it is 100% generated. It is a joke after all...

It is a joke! The data is randomly generated. Any similarity to reality is coincidental.

That said, the numbers are just numbers, and every possible one is in the list, so there is definitely overlap with real cards.

If you want to style RSS, you can just go straight to JavaScript and avoid all the XSLT mishegas.

I made a site with to get people started: https://www.rss.style/

Example RSS feed: https://www.rss.style/changelog.xml

Cross-site is fine by default, though the script is small enough to easily self-host. If you have a content-security-policy, you'll need to allow the host in script-src.

<self promotion>

One thing that would be nice is to have the feed be human readable. It is as easy as adding a single line to the XML and setting the content type [1].

Your feeds are also missing a bunch of the headers that readers use to avoid over-fetching your feeds. I build an feed analyzer [2] to help debug things like this.

[1] https://www.rss.style/

[2] https://www.rss.style/feed-analyzer.html

</self promotion>

RSS.style is my site. I'm currently testing a JavaScript-based workaround that should look just like the current XSLT version. It will not require the XSLT polyfill (which sort-of works, but seems fragile).

One bonus is that it will be easier to customize for people that know JavaScript but don't know XSLT (which is a lot of people, including me).

You'll still need to add a line to the feed source code.

There wasn't free hosting in 2003 when I first made it. I have thought about converting it to static, but it would be a complete rewrite, and there is always some other new shiny thing to play with instead.

The newer things I'm doing (like UnicodeSearch.org) are static, though I don't like forcing everyone to have JavaScript enabled.

I get where you are coming from, and have put some thought into it.

I built the site over 20 years ago, and while it was fun to make, I wouldn't have maintained it this long if is was costing me every month.

I've tried to minimize the intrusiveness: I disabled the pop-up and interstitial ads and I don't serve anything different to people with ad-blockers. And I've stuck with Google Adwords, despite requests from all sorts of questionable alternatives.

I'm not sure about the future: bots are causing all sorts of trouble, and the ad revenue is trending down and is now less than break even.

I run a couple similar sites:

FileFormat.Info[1] has a page per codepoint. It has been around awhile, so the UI isn't as whizzy, but it has all the data and works w/o JavaScript

UnicodeSearch[2] is an updated search UI that uses JavaScript and the excellent Tabulator grid widget.

There are actually a ton of similar sites with a page-per-codepoint. It is all fun to make one, until the bots come along and hammer every page.

[1] https://www.fileformat.info/info/unicode/char/2248/index.htm

[2] https://www.unicodesearch.org/

And these aren't niche/advanced features? I'm using Firefox now, and did not know about them. If I'm using them, it is only accidentally or because they are the defaults.

But I'm agreeing with you! These features are important to you, an advanced user. The more advanced users for Firefox, the better.

I agree with you. But a typical consumer will already be using Chrome, and has no reason to use Firefox.

If one of these advanced/niche technologies takes off, suddenly they will have a reason to use Firefox.

I don't disagree with you, but given (A) how will Firefox ever compete?

One possible way is doing things that Google and Chrome don't (can't).

Catering to niche audiences (and winning those niches) gives people a reason to use it. Maybe one of the niches takes off. Catering to advanced users not necessarily a bad way to compete.

Being a feature-for-feature copy of Chrome is not a winning strategy (IMHO).

Which is why Firefox is steadily losing market share.

If Mozilla wanted Firefox to succeed, they would stop playing "copy Chrome" and support all sorts of things that the community wants, like JpegXL, XSLT, RSS/Atom, Gemini (protocol, not AI), ActivityPub, etc.

Not to mention a built-in ad-blocker...

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!

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.

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.

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.

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/

I think that "market demands" is a bit of a misnomer. RSS was (and remains) too tech-y for the mainstream.

If browser vendors had made it easy for mainstream users, would there have been as much "market demand"?

Between killing off Google Reader and failing to support RSS/Atom, Google handed social media to Facebook et al.

Of course built-in support for RSS would be better. But what are the chances of that happening?

Well, I do agree with you, but...

1. This is pretty difficult for someone who doesn't know about RSS. How would they ever learn what to do with it?

2. Browsers don't do that. There used to be an icon in the URL bar when they detected an RSS feed. It would be wonderful if browsers did support doing exactly what you suggest. I'm not holding my breath.

I'm not looking to replicate my blog via XSLT of the RSS feed: that's what the blog's HTML pages are. I just don't want to alienate non-RSS users.

Huh? How would a static site generator serve both RSS and the HTML view of the RSS from the same file?

To be extra clear: I want to have <a href="feed.xml">My RSS Feed</a> link on my blog so everyone can find my feed. I also want users who don't know about RSS to see something other than a wall of plain-text XML.

I want to use it on an RSS feed: to make it sensible when a new users clicks on an RSS link.

I specifically want it to be served as XML so it can still be an RSS feed: I don't even need the HTML to look that great: I have the actually website for that.

Example: https://www.fileformat.info/news/rss.xml

Because we want RSS to be friendly to new users. If you display a RSS feed as a wall of XML text, no new user will understand. If you just make it so clicking a RSS link brings up a blurb about RSS is & links on how to use, they might understand.

And we have done it for other formats: PDF is now quite well supported in browsers without plugins/etc.

On my blog that uses a static site generator?

1. Everyone who uses a static site generator can add XSLT

2. Everyone who doesn't use a static site generate only has to add the XSLT file and add a single line to the XML. No need to write any code: new code is not a big deal for many HN readers, but not every blog author is a coder.

So... you want newbies to install an extension/plugin before they get a human-readable view of a feed???

That's about as new-user-hostile as I can imagine.

Another point: it is shocking how many feeds have errors in them. I analyzed the feeds of some of the top contributors on HN, and almost all had something wrong with them.

Even RSS wizards would benefit from looking at a human-readable version instead of raw XML.

I ended up writing a feed analyzer that you can try on your feed: https://www.rss.style/feed-analyzer.html

You are probably right, but it is depressing how techies don't see the big picture & don't want to provide an on-ramp to the RSS/Atom world for newcomers.

That's my point: you know all about RSS & feeds and don't need it. But what about someone who hasn't been using them since the beginning?

I think every page with an RSS feed should have a link to the feed in the html body. And it should be friendly to people who are not RSS wizards.

Gotta love the reference to the <link> header element. There used to be an icon in the browser URL bar when a site had a feed, but they nuked that too.