Starting over at h1 in chapter text

6 posts / 0 new
Last post

Is this considered good structure and semantics for a chapter in a book? I'm specifically wondering about whether there is an epub:type value that should be applied to the nested section. The closest thing I see in the spec would be bodymatter; however, that seems to apply more to the entire body of a book rather than the text of a single chapter. I'm using a nested section because I want the subheadings in the text of the chapter to start over at h1. Does using a nested section and starting over at h1 support accessibility here? I really don't want to have what our editors and copyeditors think of as first-level subheadings within the chapter text map to h2, h3, h4, etc., depending on how many chapter number/title/subtitle elements are present. Examples at suggest such mapping is what IDPF is wanting. It just seems a lot more natural to me to let a nested section element frame a new context for the meaning of h1, h2, h3, etc. What am I overlooking by thinking that way? Thanks.

{section epub:type="chapter"}
{h1}Chapter 1{/h1}
{h2}How to Fry an Egg{/h2}
{h3}The Definitive Guide{/h3}
{h1}Preliminar Considerations{/h1}
{h2}Choosing a Chicken{/h2}
{p}Blah blah blah{/p}
{h2}Getting the Chicken to Lay an Egg{/h2}
{p}Blah blah blah{/p}
{h1}Frying the Egg{/h1}
{h2}Choosing a Pan{/h2}
{p}Blah blah blah{/p}
{h2}Heating Up the Pan{/h2}
{p}Blah blah blah{/p}

Hi Pat,

You're running headlong into the new HTML5 outline alogorithm by adding more than one heading to a section. For example, where you have three headings at the start of your chapter you would get three sections, one for each heading. And then the nested section that follows would be treated as a second level heading and begin nesting again, kind of like this:

1. Chapter 1
   1.1 How to Fry an Egg
      1.1.1 The Definitive Guide
   1.2 Preliminary Considerations
      1.2.1 Choosing a Chicken

Although you can style the markup in a way that might look fine, this kind of markup wreaks havoc on the ability of an AT to render the content for a non-visual reader, or for the reader to navigate it, because of the unwanted leveling that occurs.

Each section can only have a single heading, and the numbering of the headings should be consistent within the file and ideally across the publication.

Instead of using three heading tags to format the first heading and run into the problems it causes, for example, you could use span tags + CSS to format the subheading parts while keeping the full heading together as a single element. You could also use an hgroup element to surround the three headings tags, which would only leave "Chapter 1" in the outline and hide the other pieces, but last I checked hgroup wasn't well supported even by browsers and had a number of open issues.

Also, if there isn't an applicable semantic for the pieces of the chapter, there isn't a requirement to use the attribute. The Structural Semantics Vocabulary does define a "subchapter" term that you could use here for the major subsections, but below that I would personally just leave the sections without a specific semantic. As far as front/body/back matter terms, I would only use once on the containing section. It's not necessary to define every time on each subsection since by default the children are all in the same part of the book as the ancestor.

Based on your example, the following markup would seem to be more appropriate:

<section epub:type="chapter bodymatter">
<h1>Chapter 1
<span class="subheading">How to Fry an Egg</span>
<span class="subheading2">The Definitive Guide</span>
<section epub:type="subchapter">
<h2>Preliminary Considerations</h2>
<h3>Choosing a Chicken</h3>
<p>Blah blah blah</p>
<h3>Getting the Chicken to Lay an Egg</h3>
<p>Blah blah blah</p>
<section epub:type="subchapter">
<h2>Frying the Egg</h2>
<h3>Choosing a Pan</h3>
<p>Blah blah blah</p>
<h3>Heating Up the Pan</h3>
<p>Blah blah blah</p>

Hope this helps!

Oh, wow. I didn't know about that one-heading-per section requirement. I need to read more about HTML5.

I guess I would go for that span-oriented solution. It does mean adding yet another thing to the transformation when dumbing down for Mobi7, but what's one more? When I first read the EPUB 3.0 spec last year, I somehow got the impression that the epub:type attribute would have wider use, such that in a situation like your span example one could still denote meaning via epub:type (i.e., {span class="subheading" epub:type="chaptertitle"}How to Fry an Egg{/span}). Do you see it developing further in a direction like this?

Thanks again.

Oh, absolutely!

I'm hoping to see more terms become available in the structure vocab as we move along. I would have prefered to have recommended semantic styling on the headings in the example I wrote (i.e., CSS selector on the epub:type attribute), but there isn't a good match in the vocab right now. The title terms we have are oriented to the work as a whole, but I can see a missing need at the part/chapter/section heading level to more clearly identify the purpose (it would help disambiguate multiple h# headings in an hgroup, too).

I'd definitely recommend opening an issue if you find gaps like this that would be widely useful to implement.

This is a serious and interesting issue.

We had this problem when we processed FX to epub:type. We couldn't specify a section title because it was hard defined to the work and the validator would not let us assign it to section titles. It it was liberated an e-Reader can use sections in a very flexible manner.

In our FX tagging we state that h1 is a generic title based on section inheritance. IE. an h1 is the title of its parent named and controlled section. That means work title or section title depending on the parent object. ePub3 doesn't regard a section title as significant, just its container.

For consistency h1 really needs to be reserved as the title element for long-term content trustworthiness and that is not addressed by the dynamic webiness of HTML5 with nested Headings. The HTML5 approach is a high-value content disaster waiting to to smack publishers down in the near future. What I am saying is h1 in a book title page is the work title. In a section page (Eg Chapter) h1 is the chapter title. Fluidity in the definition of "what is a title" is a digital content disaster in the making.

The work-centric approach as opposed to section (chapter) orientation is a major epub:type definition flaw that needs to be corrected. The value of digital content is defined by the minimum semantic section - chapter/lesson/poem/act/recipe/etc.; whatever is the container for the content. Not the encompassing work, which is a metadata parent container of the content, NOT a controller of the content. The current approach is too heavily print oriented, and reflects ePub3's major weakness; it does not understanding a work is a collection of highly valuable, reusable sections, it's just a rigid container.

Sadly I can see the thinking pattern trend will become the old lazy Baker and Taylor model that states h1 is reseved for work title, and section/Chapter/Act/Lesson/etc. is h2. What is needed in an inheritance approach rather than an hierarchical approach. IE. First h1 child of a section is the title of the parent.

The issue becomes can ePub3 define the structural containers of a document!? If it can put requirements like the 2003 archaic CFI definition into the arena, it can do anything.

XHTML2 was charting the right course in finally getting rid of the whole numbering business; HTML5's h1 approach to generic headings brings baggage along with it.

From a purely AT viewpoint, numbered headings are prefered at this time as support for HTML5's suggested use of h1 as a generic heading isn't widely supported, leaving no way for a reader to navigate by heading (but even that is complicated by whether the AT understands headings in an hgroup aren't to be traversed).

I fully expect the stated preference to change as support for sectioning and semantics grows, since the number of a heading is typically irrelevant and introduces unnecessary content management issues.

Looking back, I was skimming the followup when I responded. I don't see "chaptertitle", per se, being a definable semantic we'd need. As you say, that's inferred by the container. But I think when you have multiple title types within the container element you need a way to differentiate, and there isn't much in the way of those semantics other than "this is some other subheading with a lower number in an hgroup". That's what I was more responding to; that we lack a way of differentiating subheadings (even if embedded within the primary heading to avoid an hgroup).

But the generic heading approach to content has its flaws in the container context, too. When you split content into separate files, you lose the original hierarchy of the publication. Trying to rebuild it by semantics alone is problematic at best (especially when dealing with generic section/subsection/subsubsection/etc. which is the default when no epub:type is applied). It all depends on how consistent the chunking of the file is. When numbering is used consistently, you can at least reliably rebuild/navigate to the sixth level.

But I don't follow your final question. How is the addition of epub:type and the structural semantics vocabulary not already charting this course?

Secondary menu