main element was a late addition to HTML 5.0, so late we didn’t even make mention of it in the EPUB Best Practices guide as it had gone to print by the time the element got accepted. The omission left me wondering if there are any cases in ebooks where including the element in publishing contexts would make sense, and I’m still drawing a blank.
Nothing about it seems pertinent to publishing, but it feels weird to say there’s an HTML element to avoid in ebooks. I’m going to see if I can talk my way into some use for it in this post, but I’m not feeling too hopeful right now. If nothing else, you’ll see clear evidence I rarely think my posts through before writing them.
I’d guess that there are still a lot of people who haven’t yet encountered this element, as it has it’s roots in accessibility. But if you’ve ever seen the “jump to content” links at the top of web pages, you’re already more aware of the
main element than you might think.
The common practice with those jump links is/was to slap the id “main” on the first element of primary content in the page so that the reader can bypass all the typical repetitive junk that makes navigation of web pages a pain (logos, banners, menus, ads, etc.).
The WAI-ARIA specification took this practice a step further and made “main” a landmark role, which puts it in the list of primary points of interest a reader using an assistive technology gets access to.
HTML5 then took the next step and created the
main element for the same purpose. Now, instead of relying on IDs and roles, you can just wrap all the primary content in
<main>...</main> and the location is automatically made available to AT.
The element was a contentious add, as I recall, as there was a counter-argument that because HTML5 now includes its various sectioning elements, finding the main content is only a matter of filtering out headers, asides and navs. I only mention this here because primary/secondary content is more central to publishing, and I’ll return to it later.
main was going to be an extension specification, or possibly an HTML 5.1 addition, but at some point the detractors must have lost out as it obviously is in HTML 5.0. I missed those discussions, but I would assume the poor coding habits of HTML folk must have played a role in overcoming any pushback (i.e., it’s nice to think people will tag documents properly, but having a dedicated element removes that unlikelihood).
I’m tempted to say that
main is useless right off the bat because ebooks don’t have a concept of “jump to content” — the book is the content. And while that’s true, sitting in the back of my head is EPUB’s landmarks navigation aid. Adding a jump to the start of the body matter is pretty much mandatory, although we identify the location with the “bodymatter” semantic:
<nav epub:type="landmarks"> <ul> <li><a href="chapter01.xhtml" epub:type="bodymatter">Start reading</a></li> </ul> </nav>
Isn’t this basically the same thing?
Well, yes and no. It’s a similar kind of landmark, but you’re not skipping past superficial content. You’re jumping the reader over all the front matter, and the
main element is supposed to encompass all the primary content (i.e., non-repetitive). I have a tough time buying into the idea that main content excludes the front and back matter, and its definition backs that up.
The main content area of a document includes content that is unique to that document and excludes content that is repeated across a set of documents such as site navigation links, copyright information, site logos and banners and search forms (unless the document or applications main function is that of a search form).
Personal preference aside, the bigger problem is that the EPUB landmarks nav is in a separate document from the content, which is what makes it useful to the reading system presented with a spineful of documents. Adding a
main element won’t have any value without also letting the reading system know up front which content document it’s in.
But by the time you make it to the body matter, having a
main element in the file doesn’t add anything that isn’t already surfaced by having a body.
Logical Reading Order
The bigger problem for ebooks is not how to get past repetitive page headers and navigation, but how to differentiate the primary narrative from all secondary content that gets interspersed within it — sidebars, footnotes, etc. (The problem I said I’d get back to and actually did!)
Surfacing the logical reading order was difficult to do prior to HTML5, but the addition of
figure (in particular) have made it much easier to logically separate the nature of the content. But the bottom line that this content is interspersed in the markup remains true, and will remain true for all but the simplest headings and text publications.
main element doesn’t help solve this problem, and wasn’t designed to, so it’s unfair to compare it.
So have I thought of any uses for
main while rambling off cases where it doesn’t apply? Not really…
If you’re serving your publication online in a web interface, you’d do your readers a favour to wrap the pane where you’re serving the content in a
main element. But that’s not really an ebook-specific context.
Within a book I’m still stumped; publications are structured more tightly than web pages.
Anyway, it remains odd to me that there’s a tag that I have to say is not applicable. Tags that aren’t often used in ebooks, sure, but not applicable… hm, that’s new.
At any rate, it seems if you were to use it as another wrapper inside the body it wouldn’t hurt anything, just not be terribly helpful.
Of course, any lack of applicability for ebooks isn’t meant to suggest that the tag itself becomes useless. It has its home in the world of messy (and even neat) web pages, whatever publishing does.
But I’ve been around the markup block too many times to believe that some future use won’t present itself, or that someone hasn’t already thought of some use I haven’t.
If you’ve found a case for the element in your ebooks, please feel free to enlighten this old coder.