| 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 (Again, I suppose this 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
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 (Gemtext is basically Markdown, and doesn't require a title.)
via Gemini at gemini://danq.me/posts/does-a-blog-have-to-be-html
via Spartan at spartan://danq.me/posts/does-a-blog-have-to-be-html
in plain text (Plain text obviously doesn't require a title.)
via Gopher at gopher://danq.me/1/posts/does-a-blog-have-to-be-html
via 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 - has a !
I've implemented it! it's at 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! Here's the code.
LINKS
|