epub:type usage

5 posts / 0 new
Last post

Can anyone tell me the proper usage of the bodymatter attribute? Should I use it only once on the first chatper? On every chapter file?
It doesn't specify single usage (as for halftitle etc), so this suggests the later. Is it redundant if I also include the chapter attribute or vice versa?

I don't know that there's an absolute answer to that question. The front/body/back matter semantics are positional in nature moreso than structural, and function like complements to the other section identification semantics. You could maybe assume that certain structures will only occur in certain parts of a book, but I don't know how reliable that is all the time. Tables of contents are usually in the front of English-language publications, but in the back of French, for example.

More reliably determining the transition points was one reason for their existence. I remember an idea floated a long time back was that the first section marked as backmatter could trigger the reading system to show a list of other works by the author, or of a similar nature, on the assumption the reader wasn't going to continue reading back matter. If you don't at least mark the transitions, the reading system is left to less reliable techniques for determining them.

The semantics potentially can serve a number of different uses beyond just content identification, too: they can be used in a landmarks nav to allow the reader to jump to the start of each division of the book; they could also be applied to the toc nav to style the entries (e.g., if you're including the document in the spine).

I don't know of any reading systems at this time that have specialized behaviours based on these three semantics, but that's probably just a reflection of the ongoing development stage we're in. I'd err on the side of richer data than poorer, though, and minimally identify the major transition points and ideally add to each top-level section.

Thanks Matt, that's very helpful. I'm sure I will have more questions as I investigate this further :)

I have a further question Matt. Are the epub:type attributes generally considered as encapsulating content (so if "chapter" is applies to a <body> tag, the chapter is assumed to end at the </body>) or marker points (ie the chapter continues until the reading system encounters the next chapter attribute).

I realise that it is up to individual reading systems as to the behaviour triggered by such mark-up, but which of the two would you recommend?

I ask because often a Part title page will be a seperate xhtml file to the chapters it contains, but placing the epub:type="part" attribute on the body tag of the Part title page would be pointless if it only represented what was contained within the body tag.

The attribute itself is not about the encapsulation of content so much as defining a more precise semantic for the tag it's applied to, but at the same time you can draw better relationships between the container element and its descendent content based on the attribute's presence.

But yes, the semantic, and that relationship, ends wherever the tag it is applied to ends, so it would be at the end of the file in that case.

I tend to avoid adding semantics to the body tag, though. The body is a potentially ambiguous source of meaning, especially now that we have the <section> element available, and typically isn't used for document comprehension/navigation (at least by ATs). Throw in the html5 outlining algorithm that sets absent sectioning based on the headings in the body, and you can wind up with a "chapter" <body> containing a generic <section> containing the first heading's content.

I realize that it means you effectively turn a simple one-heading file into this:

<body>
  <section epub:type="part">
    <h1>Part 1</h1>
  </section>
</body>

But at least here the semantic clearly carries with the section, which is the better definer of structure.

There is no elegant solution at this time to the problem of oversize parts, and splitting them up, that I know of, though. This is also a grand nuisance in terms of the accessible navigation of documents. Sighted readers are never going to think twice about the visual presentation associated with this markup (swipe to the next page and on you go), but someone navigating by TTS potentially loses the ability to effectively navigate the document, at least without pulling up the table of contents every time they want to move around at the marco level.

I was kind of alluding to this problem in another thread, but this is also why we're still recommending numbered headings for accessibility purposes. HTML5 introduces the concept of using h1 as a generic header for all sections (because ideally the section elements should define the document outline levels), and that's great on the Web when a single page typically contains your entire document. The problem you already see coming is that the next file in a part/chapter scenario will also contain a single section with an h1, but it's actually a child of this section and has lost its parent relationship. The reading system now has to be able to look ahead and understand semantic relationships in order to provide document-level navigation for TTS-enabled readers. Even attempts at semantic styling can get messed up when these relationships are no longer clear, so it's not just about accessibility.

Adding the epub:type semantics is a step in the right direction in terms of solving this problem, don't get me wrong, but it only works when clear relationships like "part is parent of chapter" can be established when a document has been broken up. It's not always true that a part contains every chapter that follows it, though (I've run across books that exclude a few final chapters from the last part). It also falls apart when you have less-clear relationships between parent and child (section/subsection/subsubsection).

To try and cut my rambling down now (sorry for the essay!), the semantics are still potentially useful even though the document hierarchy has been broken. In some ways more so, but we're now pushing the problem of reconstructing and navigating the document onto the reading system, and there's no guarantee it will behave as wanted. A bit disheartening, I know, but hopefully we'll see progress in the handling of these semantics over time.

Secondary menu