Criticism, fiction and other writing
Some further thoughts, arising from my recent post, “Writing ‘plain’ text”.
Almost the first thing I posted after I registered my own domain name and set up a static site on GitHub Pages was a piece (which I’ve since deleted) comparing Markdown and HTML. At the time, I was thinking of HTML as cumbersome, full of redundancies and awkward to write, and was in the first flush of early enthusiasm about Markdown, which I had been aware of but hadn’t really used up to that point.
After a few months using GitHub Pages, I decided that it would be easier to write my posts in simple HTML with a rudimentary CSS style sheet than to learn how to modify Jekyll themes. Since then, I’ve been writing all the posts on this site in HTML. It works but there are some little things that irritate me about it.
Most of the tags used in a normal post are going to be for paragraph (<p>) elements, so I just forget about these for the time being and type paragraphs of text separated by blank lines, as in Markdown. For most other things — headings, blockquotes, emphasis, citing book and journal titles, lists, notes (i.e. details/summary), I type the HTML tags out in full. None of these is common enough to make that a problem. Same with links and images: with these, I prefer the HTML approach to Markdown’s, even though it requires me to type straight double quotes (another redundancy: Markdown does fine without them) while I usually write with “smart” quotes turned on.
The resulting document should be valid Markdown, although it doesn’t contain any Markdown syntax. Once I’ve got a complete draft, I change the extension from .txt to .md (if necessary) and open my document in iA Writer, which I use for no other purpose than to convert Markdown to HTML! (I bought the iPad version to try it out, so I might as well do something with it, even if not actual writing.)
I then edit the HTML document in a text editor: adding a stylesheet link and meta description — and occasionally some embedded styles — to the head, and pasting in my standard header at the top of the body.
You may be asking why I don’t use Markdown for the headings, blockquotes, emphasis etc? It would work equally well. The reason is that, having written in Markdown regularly over a period of months, I realized that I’m not very enthusiastic about it. The principle of avoiding HTML’s redundancies appeals to me; the methods chosen don’t. They’re expressly based on plain text email conventions: underscores for emphasis, greater-than to begin a block quote, a blank line to indicate a new paragraph.
In the late 1990s and early 2000s, I used to subscribe to the Milton-L mailing list, a discussion group conducted by email. The thing about Milton-L that used to drive me mad was that there was no way to distinguish the title of a book or journal from the surrounding text. Some people used underscores but I always thought that was an unsatisfactory workaround.
This approach — writing mainly plain text with some HTML tags — works perfectly well if I want (as I usually do) to produce a HTML document to be posted on my site. But it’s getting tantalizingly close to the ideal state of being able to do everything as plain text.
One reason why I avoided HTML for many years was that when I first used it, I had to type a lot of entities to represent non-ASCII characters: ”, ', …, é and — for example. Typing these was unbelievably disruptive to the flow of the writing. The use of UTF-8 encoding has removed this difficulty. As a result, writing HTML is a much less frustrating experience than it used to be.
As it has become possible to type as plain text nearly all the characters I need, it has seemed somehow redundant to have to rely on an external style sheet or document-type specification for presentation and structure. On the other hand, it seems to me that a lot of the documents I write (e.g. a short story) don’t have a very complex visual structure. So, I began to wonder if it wouldn’t be possible to do the whole thing in text, without any additional markup.
The elements that I typically might need to use in a document are these (with, in the third column, my suggestions as to how they might be indicated using only plain text):
| Element | HTML | Plain text equivalent |
|---|---|---|
| Title | <title> | ALL UPPERCASE |
| First level heading | <h1> | Use Title Case if You Don’t Mind |
| Second level heading | <h2> | Short line (no more than 40 characters), with only one line break at the end; text following the line break is treated as a normal paragraph |
| Normal paragraph | <p> | Double line break at the end (unless it’s the last paragraph in the document) |
| Block quote | <blockquote> | Separate from the preceding and succeeding paragraphs with 3 line breaks rather than 2 |
| Line break | <br> | A line break (I don’t put breaks in the middle of paragraphs unless a break is intended, and I invariably have word-wrap turned on) |
| Emphasis | <em> | Try to make it clear from the context when emphasis is intended; if you absolutely, positively must emphasize a word or phrase, put an asterisk immediately before and after it: underscores look messier and less “finished” than asterisks |
| Citaton | <cite> | There’s no way to avoid some markup for this one, I’m afraid: I suggest using braces (curly brackets) as in Henry Fielding, {The History of Tom Jones, a Foundling} or {The New Yorker} |
| Numbered list | <ol> | See list item below |
| List item | <li> | Just put a number at the start of the line: if there are no more than 5 or 6 items, it’s easy to keep track of the numbers; I don’t use bulleted lists very much (I’ve never seen the point), but a suitable nonalphanumeric character will be fine |
| Expandable note | <details> and <summary> | Where possible avoid notes, which are a distraction that at best disrupt the reading experience; (instead, try to incorporate references, asides etc into the text using parentheses if necessary) |
That leaves links and images. To take the latter first, you’re dealing with a text file: any images are necessarily going to be separate. I’d be inclined just to put something in the text like “Figure 1: The author’s family tree” and name the image files to make it clear which goes where. As for links, well, again this is meant to be text, not hypertext. If you’re referring to something the reader can easily search for on Google, DDG, Bandcamp or a relevant app store etc, don’t bother with a link. Your reader is not a helpless infant. If you find it necessary to include a URL, the convention of surrounding it with angle brackets will work just as well here as anywhere else. (I may have more to say about hypertext and links in a follow-up post.)
This approach won’t be ideal for everything, of course. If you’re writing a web page, you might as well go full HTML, with links, images, headers, notes and so on. If you’re producing academic writing, you’re going to need notes and a more robust approach to citation than I recommend here. But for things like email newsletters, or documents that might be opened, read and edited on any system, I believe that my suggestion has something to recommend it. I’m certainly going to try it out myself.
Posted by Art on 11-Sep-2020.