I’ve got a copy of John Ashbery’s Some Trees on my phone, that I sometimes pick at while waiting for a train if I do not have another phone-book going. I read the book some years back in paper ("Dead Trees"), but am always tickled pink by the "Publisher’s Introduction" in this copy, this version, which tells how:

Unlike a printed book, which is stable, an ebook is a shape-shifter. Electronic type may be reflowed across a galaxy of applications and interfaces, across a variety of screens, from phone to tablet to computer. And because the reader of an ebook is empowered to change the size of the type, a poem’s original lineation may seem to be altered in many different ways.

This is, itself, a reach towards a poetry, however schmaltzy. I like the idea of an ebook as a "shape-shifter." I have done enough web development to appreciate, however wryly, the proliferation of devices and screen sizes one must support as a "galaxy." But the point is a fair one, a very true one, and one that can be challenging to get right: how to denote a poem’s lineation should the line extend past the width of the screen? Does one follow most volumes of Whitman (or, if you like, Ginsburg) and hang the first "line" back and indent the rest of it? But how to show this reliably when, for example, the poem in question may itself employ some other indentation, creating ripe circumstances for further confusion?

The problem has — at least to my knowledge, at least for my money — not been satisfactorily solved. There is the same issue with long lines of code — in fact (as we’ll see below), the basic markup strategies are more or less the same for code blocks as they are for poetry — but at least with code, at least in many languages, there are other semantic markers: curly braces, semi-colons, significant single- and double-quotes, backtics, and so on. With poetry — 

The publisher continues, choosing what I’ll call the "Whitman" strategy I mentioned above:

Open Road has adopted an electronic typesetting standard for poetry that ensures the clearest possible marking of both line breaks and stanza breaks, while at the same time handling the built-in function for resizing and reflowing text that all ereading devices possess. The first step is the appropriate semantic markup of the text, in which the formal elements distinguishing a poem, including lines, stanzas, and degrees of indentation, are tagged. Next, a style sheet that reads these tags must be designed, so that the formal elements of the poems are always displayed consistently. For instance, the style sheet reads the tags marking lines that the author himself has indented; should that indented line exceed the character capacity of a screen, the run-over part of the line will be indented further, and all such runovers will look the same.

While I will mention that this doesn’t really get around the obvious challenge of a run-over line immediately followed by an indented line, it does rather pique my interest, specifically as regards to the first step: "the appropriate semantic markup of the text."

Semantic Markup

"Semantic markup" is markup that is meant to capture the meaning of whatever it is that’s being marked up. There are many different kinds of markup, of course (this little essay itself being written in a "lightweight markup" language called asciidoc), but for our purposes here, we’ll narrow our attention to HTML, or the "hyper-text markup language," the markup language that encodes nearly all the content on the internet, and the language that also makes up the text content of an epub, the file-format behind ebooks (I tend to use the terms interchangeably, but I will try to distinguish here the format from the medium). Epubs are essentially zip files that are organized in a specific way and have a few additional metadata files to go alongside the HTML files that contain the actual text of the ebook.

HTML is, I would say, more or less semantic to begin with, and it’s now better than it used to be; a few (many?) years ago a standard called "HTML5" made it much more semantic, giving us tags (the means by which the text and other contents of a web page are "marked up") for things like articles and time. You have tags for things like emphasis and strong emphasis, and paragraphs (of course!), but no explicit handling or standard for poetry. Which is not to say that people haven’t tried.

This publisher makes use of classes, which are essentially ways to additionally mark up one’s markup (note that I have modified the following example to simplify the markup a little):

<h1 id="chap1" class="center"><i>Two Scenes</i></h1>  (1)
<h3 class="center5">I</h3>  (2)
<p class="poem">We see us as we truly behave:</p>  (3)

  1. Here they us an h1 tag for the poem’s title, which makes sense, as it’s a heading. Somewhat charmingly, they use the old i tag for italics instead of the more modern em tag for emphasis (rendered as italics by default).

  2. For the section heading (I picked a poem that has two parts), they use an h3 tag, which is somewhat non-semantic, as it’s technically a secondary header (the DAISY accessibility folks would ding them here), but note the class="center5" tag as a means of styling the sub-heading. I’ll have more to say about this in a moment.

  3. Finally, we have a p or paragraph tag with a "poem" class. I will leave it as an exercise for the reader to decide whether or not it would be more semantic to use a "line" class.

So we have a mix here: some built-in semantics, some "custom" semantics. For my money this is not exactly "appropriate" semantic markup, but this may simply be — if you’ll forgive the pun — semantics itself. But let’s look at a poem involving more "degrees of indentation":

<h1 id="chap3" class="center"><i class="calibre4">Eclogue</i></h1>
<p class="poem2"><i class="calibre2">Cuddie:</i> Slowly all your secret is had</p>
<p class="poem3">In the empty day. People and sticks go down to the water.</p>
<p class="poem3">How can we be so silent? Only shivers</p>
<p class="poem3">Are bred in this land of whistling goats.</p>
<p class="poem1"><i class="calibre2">Colin:</i> Father, I have long dreamed your whitened</p>
<p class="poem3">Face and sides to accost me in dull play.</p>

…and here is where they really lose me. While, I suppose, fine class names, poem1, poem2 and so on don’t do it for me: they are not semantic in the sense that, by reading these classes, I learn something (i.e., I learn nothing). I have to go to the stylesheet to see how:

/* note that I'm removing everything except the actual differences */
.poem1 {
    margin-left: 30px;  (1)
    margin-top: 20px;
    text-indent: -30px
    }
.poem2 {
    margin-left: 30px;
    margin-top: 30px;  (2)
    text-indent: -30px
    }
.poem3 {
    margin-left: 60px; (3)
    margin-top: 0;
    text-indent: -30px
    }

  1. Okay, so we have a standard left margin here: fine.

  2. But for poem 2, it’s… the height that’s different? On the "page" this ends up being a stanza break, but it is in fact actually a first line top margin, relative to the title… so poem2 actually precedes poem1, as above.

  3. Here is a proper indented line! Great! But why am I thinking, based on the title, that it’s a third "poem" then?

I think where I get stuck here is that, while the following from the "Publisher’s Introduction" is not untrue:

This combination of appropriate coding choices and style sheets makes it easy to display poems with complex indentations, no matter if the lines are metered or free, end-stopped or enjambed.

It certainly does not read that way in the code. Something even as simple as a stanza class might be clearer; or a indent-1 line instead of poem3 (or even better: double-indent). And I will only mention — as opposed to rant about — the fixation on naming styles for Calibre,[1] which is a perfectly good tool, which is wonderfully open source, and yet: why lock yourself in, especially when the real targets now are mobile phones, e-ink readers? Anyway.

Why do I care.

Poetry, Accessibility

Screen readers don’t read CSS, they don’t read classes (mostly: most will ignore things that are meant to be ignored, i.e., display: none). But as DAISY and other advocacy orgs make the web more broadly accessible (and as publishers begin — slowly — to conform to the standards they’re trying to set), we might eventually get to the point of having "nice to haves," or things like text-to-speech that can be more aware of things like stanza breaks and spacing. This would be a cool future.

But even before that, if I, as a sighted person, wanted to see the decisions a poet was making, would it not be nicer to see how it was marked up in code? As a poet, would it not be nice to be able to communicate that kind of intention?

It’s obviously a hard problem to solve. I don’t have a solution, certainly (this was originally planned as a multi-part essay; we’ll see if I find time for other parts). And as I now no longer work in publishing, the urgency feels a little less. Not gone, but.

I have plans for publishing projects — both in terms of actual publication(s) and in terms of making some better tools for publishers — that are on hold for the time being. But a part of that work — especially the tooling — ideally will address some of these things. One (of many) reason(s) why I had to stop Response was that my ambition — and the ambition of the fabulous writers, artists, and poets who contributed — outstripped the capabilities of the tooling I had built to "one-click publish" a print-ready PDF; going back down into InDesign slowed the process down too much, made the project unsustainable as a one-person-plus-occasional-help-from-friends kind of project.

And I’m realizing that "accessibility" in the header (I wrote the header first: sue me) is also, then, about accessibility for the publishers, for the writers: how can they access better tools? How can we make laying out a poem simpler for college lit mags and lit mags with no budgets (all of them) and for the poets themselves on their websites or self-publishing adventures or whatever else?

There is a privilege, certainly, in being able to code (and despite the increasing efficacy of AI-tools, you still kind of need to know what you’re doing). So how can that be extended, how can the barrier to entry be lowered?

I wonder.

1. Oh shit! I hadn’t realized before that this was by the same guy that develops the Kitty terminal. Neat!