5 ms·
> 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 pu
by tjansen 2mo ago
> 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?
- chrismorgan 2mo agoHere’s an example of <code> in titles being quite valuable: https://chrismorgan.info/blog/make-and-git-diff-test-harness/ 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.
- tjansen 2mo agoI 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.
- gchamonlive 2mo agoIf html in titles were an opt-in feature from the beginning none of this discussion would be happening
- chrismorgan 2mo ago> 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/ 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 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.
- mcv 2mo agoI 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?