Comment by chrismorgan | Hacker News Reader

Comment by chrismorgan | Hacker News Reader

Parent Full thread

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.

> 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?

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.

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.

If html in titles were an opt-in feature from the beginning none of this discussion would be happening

> 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.

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?

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.)

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.

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.

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.

I already addressed that in this ancestor thread.

Reply on news.ycombinator.com