8/2/2026 at 9:08:22 AM
I agree that Atom is easier to use and better defined in some ways. But why on earth would you want to put unrestricted HTML in the title in the first place? How is a reader supposed to handle that? It's just a weird thing to allow.In practice, the differences between the syndication formats don't really matter. Today even less than when they were created, as a solution for most of the differences is just a prompt away.
In my humble opinion, JSON feed (https://www.jsonfeed.org/version/1.1/) is the most practical format. By a small margin, but still...
- it's really simple and doesn't use XML
- it doesn't allow stupid things like HTML in titles (which I guarantee >50% of all implementations can't handle correctly)
- JSON Feed allows feeds to have a <favicon> and a (square!) <icon>, which is a very practical thing for readers. You can use the <favicon> in lists of feeds, and the <icon> to present a single feed. Atom has a small square icon and a <logo> which is supposed to use a 2:1 aspect ratio. 2:1 is completely useless. No site has a logo in 2:1. It's also useless for most full-name logos, like 'New York Times'. (RSS is, of course, even worse; it doesn't even recommend an aspect ratio, practically guaranteeing that RSS readers can look bad)
You can see that JSON feed has been designed from a feed consumer's point of view: what does an RSS reader need to make a feed look good? While Atom and RSS have been written from an abstract publisher's point of view, making everything possible and allowing maximum flexibility. Especially RSS, which has shown its flexibility in becoming the de facto format for podcasts. And both Atom and RSS are really old, written at a time when it probably wasn't clear how RSS would eventually be used.
In the end, no matter which format a feed uses, users won't notice any difference (as long as publishers are smart enough to use square images!). So any feed is a win, no matter whether RSS, Atom, or JSON feed.
by tjansen
8/2/2026 at 10:30:42 AM
Consider the title of my article: “Atom is better than RSS, in ways that matter”. That emphasis belongs there, and it’s mildly bad to lose it. (For presentation on my own site, I also control the line break position on larger screens; but that wouldn’t be appropriate for feeds, where you can’t control the presentation.)We accept that sentences can have formatting, and headings can have formatting, so why shouldn’t titles? When you look at titles that get used on platforms like YouTube, there’s obviously a desire for formatting. People use Unicode shenanigans to work around the deficit frequently. (And they do so in ways that are mostly only available for the English script, quite inequitable for other scripts.) Even if you were to restrict it to ASCII, people GLEEFULLY abuse capital letters FOR EMPHASIS!!!!1!
Especially once you get to coding topics, titles need to support <code>, which is important semantics.
(My biggest disappointment with Atom is that text constructs are single-type-only. I wish you could provide distinct text and HTML representations, like email does with the multipart/alternative MIME type. In some places where I use <code> in titles, I’d just drop the <code>…</code> wrapping, in other places I’d turn it into `…`.)
I will write a proper article about all this some time soonish, encouraging people to use markup in titles.
by chrismorgan
8/2/2026 at 10:46:07 AM
> We accept that sentences can have formatting, and headings can have formatting, so why shouldn’t titles?1. Because there are things you can obviously not put in a headline. Like a large image, a YouTube video, or a paragraph. Defining an HTML subset would make it somewhat usable. But letting each consumer of the Atom feed decide which subset they support will make such a title look bad on at least those renderers that don't support the same subset. No renderer can allow it completely (<script>...). HTML sanitation/injection becomes a much bigger problem when it's not limited to a text body that can be relatively easily sandboxed.
2. If you allow every feed to define its own font style or even color, that makes a list of posts look like a 2005 MySpace page. :)
It is producing bad UIs. Renderers can't really render it as plain text, as they might lose a part of the meaning. But they also can't really allow it because it might make their output look like trash. In the end, that would force renderers to develop complex heuristics of which elements and styles to allow, which to modify (do your HTML titles support dark mode? accessibility?), and which to filter out.
3. I don't see the practical value of having <code> in a headline. If it shouldn't be rendered in a different way for obvious reasons, and XML is not designed for human consumption, what is it good for? Who is the consumer of the <code> tag? AI?
by tjansen
8/2/2026 at 11:03:09 AM
Here’s an example of <code> in titles being quite valuable: https://chrismorgan.info/blog/make-and-git-diff-test-harness....Inferior plain text: Using make and git diff for a simple and powerful test harness
Better plain text: Using `make` and `git diff` for a simple and powerful test harness
Better HTML: Using <code>make</code> and <code>git diff</code> for a simple and powerful test harness
I use the second for the <title> and og:title on my site, and the third in the <h1> and feeds. It will unfortunately be turned into the first by some feed readers, but that’s their problem. (Some feed readers do accept a subset of HTML phrasing content.)
> If it shouldn't be rendered in a different way for obvious reasons
I don’t perceive your obvious reasons.
by chrismorgan
8/2/2026 at 12:56:15 PM
I agree that it makes sense on that page. But only because the rendering of the page is completely under the control of the author, and the page shows only that one page. It's different if the text is rendered by an RSS reader in a different context. You don't know the font, color, or text weight it is rendered with in an RSS reader (which also depends on the context, like unread posts being bold). Imagine the same title in a list of post titles. I think it would stick out and make the list much harder to read.by tjansen
8/2/2026 at 3:03:03 PM
> Imagine the same title in a list of post titles.Sounds wonderful. I think you aren’t realising that it’s already easy to abuse this stuff, with uppercase and exotic Unicode letters <https://yaytext.com/> and such. But people don’t abuse it in feeds.
I’m not talking about allowing <font face=Impact style=color:red>, just some relevant semantic HTML elements like <code>, <em> and <kbd>, which are pretty harmless to add, and useful.
Perhaps I should have gone with the MATHEMATICAL MONOSPACE characters for my plain text title. Alas, HN strips them. Demo in https://temp.chrismorgan.info/2026-08-02-titles.html. Doesn’t look any good for me with my specific fonts, would look better for some people.
by chrismorgan
8/2/2026 at 1:16:07 PM
If html in titles were an opt-in feature from the beginning none of this discussion would be happeningby gchamonlive
8/2/2026 at 3:30:42 PM
I would really strongly prefer titles to work the same way they do in html, which means plain text. Why should feed titles need a different standard than html titles?by mcv
8/2/2026 at 12:57:29 PM
There is precedent. The HTML title element cannot contain markup. Titles may be cited in many places and formatting may not be available. If a title requires formatting to convey its meaning it's a bad title.(Not that I want to defend RSS. In early versions valid RSS wasn't necessarily even valid XML. It is very poor.)
by masfuerte
8/2/2026 at 7:27:09 PM
Because the title appears next to a bunch of other titles.It should be consistent, or else compromise browsing.
The content has no such situation.
by paulddraper
8/3/2026 at 9:58:01 AM
You haven’t engaged with my second paragraph, or my responses to other responses in this thread. Meaningful inconsistency is already easy with just Unicode, nor does limited HTML make things materially inconsistent.by chrismorgan
8/3/2026 at 2:18:09 PM
While it’s true Unicode pushes the boundaries of “plain text” having a consistent font face, font size, font weight, letter spacing, font color, text wrapping, etc is good.I don’t want one title 16pt and another 28pt.
Or one Helvetica and the other Arial.
by paulddraper