To learn any programming language is to learn how to debug it. But a malformed command in Python usually returns an error message that keeps the code from running, not something that fails brilliantly yet monstrously, outpacing its creators’ intentions. With HTML, we are all Doctor Frankenstein.
One of my favorite websites of all time is the Embroidery Troubleshooting Guide. These days it’s available only via the Internet Archive, unless (like me) you have a local copy. At the top, it looks like a typical, if somewhat old-fashioned, small-business website. But when you glance down, you immediately notice something strange about it. The text, all center-aligned in alternating red and blue Arial, gradually gets bigger and bigger, with phrases forced to wrap lines or reach the edge mid-word, filling up the screen like Alice trying to squeeze through smaller and smaller doors in Wonderland.
When you view the source code (have any other programs made it so easy to view source like a website?), you’ll quickly discover what’s gone wrong. Each line of centered text begins with <h2> or <h3> header tags that never close. Each header tag—which only establishes a relative size, not an absolute one, part of the semantic richness of the web’s flexible grammar—builds on the last, creating progressively larger nesting dolls. The tag designed for defining textual hierarchy runs amok, creating chaos. The fact that the words themselves are about how and why threads can break makes it poetry.
On its own, the Embroidery Troubleshooting Guide would be a clever enough piece of found conceptual art. But by viewing the source, downloading the file, and replacing the instructions for troubleshooting common sewing problems with any text you like, you can make that artwork your own. I like to put in my favorite poetry, decontextualizing it and forcing myself to read it with new eyes.
“Broken” sites like these upend the great achievement of semantic HTML. As it developed, semantic HTML increasingly separated structure from presentation: Instead of <i> tags, which strictly specify that a text be presented in italics, we use <em> tags to identify emphasis (or <cite> tags for titles of books or movies, etc.). These elements can then be presented as italics on a computer screen but be read with a different intonation by a screen reader. The Embroidery Troubleshooting Guide hijacks a semantic tag and makes it present something unexpected. The same building blocks that allow a single website to be displayed responsively on a tiny phone or enormous television screen can make a website fundamentally undisplayable. This is delightful.
I appreciate the utility of content management systems and complex sites that generate HTML dynamically, but there’s a joy in building sites out of simple HTML files you can edit by hand. I still edit my own website this way, tidying it up so I can see every tag, section, and paragraph break. I even love editing my own ebooks, turning PDFs into nicely formatted HTML-based EPUB files that never get published to anyone: my own private library of self-contained websites. During the height of the pandemic, editing these files and their style sheets by hand was a balm.
Ultimately, even as HTML has become the province of professionals, it cannot be gatekept. This is what makes so many programmers so anxious about the web, and sometimes pathetically desperate to maintain the all-too-real walls they’ve erected between software engineers and web developers. But people who write HTML know that hierarchies were made to be blown up. All it takes is a tag that doesn’t close where you’d expect it to.
What other programmers might say dismissively is something HTML lovers embrace: Anyone can do it. Whether we’re using complex frameworks or very simple tools, HTML’s promise is that we can build, make, code, and do anything we want.
