Stacked headings create invalid EPUB

[rbeezer]

The backmatter figure list and solutions of the epub-sampler has the new stacked headings. But in an EPUB the validator does not like the p.assistive in an h3 (I think). Pinging @mitchkeller so he is aware.

From (possibly):

• https://github.com/rbeezer/mathbook/pull/1603
• https://github.com/rbeezer/mathbook/pull/1625

Thoughts:

• Override the relevant HTML templates for EPUB.
• Use a span, or similar, and style as a block element?

[Alex-Jordan]

Is it specifically the p within the h3 that it objects to? Not so much the .assistive?

[rbeezer]

Yes, it is the p, I believe.

Error message:

ERROR(RSC-005): epub-sampler.epub/EPUB/xhtml/solutions-1.xhtml(84,524): Error while parsing file: 
element "p" not allowed here; expected the element 
end-tag, text, element "a", "abbr", "area", "audio", "b", "bdi", "bdo", "br", "button", "canvas", "cite", "code", "data", "datalist", "del", "dfn", "em", "embed", "i", "iframe", "img", "input", "ins", "kbd", "label", "link", "map", "mark", "meta", "meter", "ns1:switch", "ns2:math", "object", "output", "picture", "progress", "q", "ruby", "s", "samp", "script", "select", "small", "span", "strong", "sub", "sup", "svg:svg", "template", "textarea", "time", "u", "var", "video" or "wbr" (with xmlns:ns1="http://www.idpf.org/2007/ops" xmlns:ns2="http://www.w3.org/1998/Math/MathML") or an element from another namespace

So at line 84, column 524 (during some cover image testing).

[Alex-Jordan]

The problem with using span for the line breaking is that the line breaking won't be accessible. A screen reader user should have some sort of indication that one of the titles has ended and then next one is starting.

Best idea at present is to use br. I'll look into it for accessibility, epub validation, and that it just plain works.

[mitchkeller]

Wait, is p inside h3 valid HTML5? The schema browser for HTML5 isn't as easy to traverse as the PreTeXt one, but my reading suggests the content of h3 can only be phrasing content, and it does not appear that p is phrasing content.

[Alex-Jordan]

I'm changing how the stacked duplicate headings come out in HTML. I've currently got it like:

<h3 class="heading hide-type" title="Section 4: An Interesting Corollary; Subsection 4.2: A Pedagogical Note about Subsection&nbsp;4.1; Subsubsection 4.2.1: Symbolic and Numerical Integrals">
<span class="codenumber">4</span>
<span class="space"> </span>
<span class="title">An Interesting Corollary</span>
<br>
<span class="codenumber">4.2</span>
<span class="space"> </span>
<span class="title">A Pedagogical Note about Subsection&nbsp;4.1</span>
<br>
<span class="codenumber">4.2.1</span>
<span class="space"> </span>
<span class="title">Symbolic and Numerical Integrals</span>
</h3>

I'm listening to Apple VoiceOver, and it's interesting. First, it announces that the heading has "9 items". So it's counting all 9 of those spans. This is not good. The next thing is that after it reads all of the content, it concludes by repeating that we are on a heading level 3, and then it reads the title text. That essentially just repeats the information that we just read.

It does pause with each span. This runs contrary to my previous understanding of how a screenreader sees a span. I'm unsure if the br alone would be enough to induce a pause.

I can only test with Apple VoiceOver. Really, I should be experiencing what JAWS, NVDA, and ChromeVox do too.

Any objection to: a) I turn it into 3 spans instead of 9? (If so, with a new class?) b) I remove the title attribute.

This is all only for duplicate headings that arise in solutions and perhaps in list-of. Lessons learned might help make headings in other places more screen reader friendly.

Stepping back a bit, this suggests we need to be more careful about using @title.

[rbeezer]

Sorry for the delay. Going in multiple directions the past 24 hours.

a) I turn it into 3 spans instead of 9? (If so, with a new class?)

The span.codenumber is used so we can turn off numbers as part of styling. I think they are necessary here. So I think 3 spans would be fine. But I'd rather @davidfarmer checks off, especially if we introduce a new class.

b) I remove the title attribute.

I think that is fine here as well. The purpose is to get tooltips.

Stepping back a bit, this suggests we need to be more careful about using @title.

That's one (opinionated) person eight years ago. ;-) So I'd be interested in more modern recommendations. But what I'd really like to do is use the ARIA scheme to override all the old practices. Maybe UTMOST can support somebody who wants to do that. ;-)

Observation: EPUB will need to be XHTML. Be sure your <br> in example above come out as true empty elements.

[davidfarmer]

  a) I turn it into 3 spans instead of 9? (If so, with a new class?)

The span.codenumber is used so we can turn off numbers as part of styling. I think they are necessary here. So I think 3 spans would be fine. But I'd rather @davidfarmer checks off, especially if we introduce a new class.

I don't see why we would custom style those stacked headings (this is for collected items at the end, right?).

So you can just put what should be there: a space is just a space, not a space in a span.space . A codenumber is just a number which will always be visible.

I think I am saying yes to one span per line.

Not sure about the relative merits of < br > vs. styling those spans as blocks.

[rbeezer]

Not sure about the relative merits of < br > vs. styling those spans as blocks.

The EPUB validator complained about the content of the hN elements surrounding these. Nobody has followed up on Mitch's investigation by actually using an HTML validator to see if it is really an HTML problem.

[Alex-Jordan]

Nobody has followed up on Mitch's investigation by actually using an HTML validator to see if it is really an HTML problem.

I have, and it is an HTML problem too.

Be sure your <br> in example above come out as true empty elements.

I will watch that. I was copy-pasting from the inspector, which may have dropped the closing /.

[Alex-Jordan]

1668 should fix this.

[rbeezer]

Closed via #1668. Just to be certain, checked that EPUB validation problems have gone away. Thanks, @Alex-Jordan!