Does a blog have to be HTML?

2024-05-03

Terence Eden wrote about his recent experience of IndieWebCamp Brighton, in which he mentioned that somebody - probably Jeremy Keith - had said, presumably to provoke discussion:

A blog post doesn't need a title.

Terence disagrees, saying:

In a literal sense, he was wrong. The HTML specification makes it clear that the element is mandatory. All documents have title.

But I think that's an overreach. After all, where is it written that a blog must be presented in HTML?

Non-HTML blogs

There are plenty of counter-examples already in existence, of course:

Terence's own no-ht.ml (now offline) demonstrated that a website needn't use HTML: no-ht.ml technically does use HTML, but the same content could easily be delivered with an appropriate non-HTML MIME type if he'd wanted. This inspired my own "page with no code", which worked by hiding content in CSS and loading the CSS using HTTP headers. I suppose this also technically required HTML, even if what was delivered was an empty file!

theunderground.blog's content, with the exception of its homepage, is delivered entirely through an XML Atom feed. Atom feed entries do require <title>s, of course, so that's not the strongest counterexample!

This blog is available over several media other than the Web. For example, you can read this blog post:

in Gemtext (basically Markdown, which doesn't require a title) via Gemini at gemini://danq.me/posts/does-a-blog-have-to-be-html or Spartan at spartan://danq.me/posts/does-a-blog-have-to-be-html
in plain text via Gopher at gopher://danq.me/1/posts/does-a-blog-have-to-be-html or Finger at finger://does-a-blog-have-to-be-html@danq.me

But perhaps we can do better...

A totally text/plain blog

We've looked at plain text, which as a format clearly does not have to have a title. Let's go one step further and implement it. What we'd need is:

A webserver configured to deliver plain text files by preference, e.g. by adding directives like index index.txt; (for Nginx). There's no requirement that default files served by webservers are HTML, although it's highly-unsual for that not to be the case.
An index page listing posts by date and URL. Most browser won't render these as "links" so users will have to copy-paste or re-type them, so let's keep them short,
Pages for each post at those URLs, presumably without any kind of "title" (just to prove a point), and
An RSS feed: usually I use RSS as shorthand for all feed types, but this time I really do mean RSS and not e.g. Atom because RSS, strangely, doesn't require that an <item> has a <title>!

I've implemented it! it's at:

https://textplain.blog/

In the end I decided it'd benefit from being automated as sort-of a basic flat-file CMS, so I wrote it in PHP. All requests are routed by the webserver to the program, which determines whether they're a request for the homepage, the RSS feed, or a valid individual post, and responds accordingly.

It annoys me that feed discovery doesn't work nicely when using a Link: header, at least not in any reader I tried. But apart from that, it seems pretty solid, despite its limitations. Is this, perhaps, an argument for my .well-known/feeds proposal?

Anyway, I've open-sourced the entire thing in case it's of any use to anybody at all, which is admittedly unlikely!