Should reading systems honor inline formatting in nav doc?

[dauwhe]

I've been looking at what happens to an italic word in an EPUB Navigation document. This is not uncommon:

<li><a href="chapter1.html">The launching of the <i>Titanic</i></a></li>

Of the reading systems I've tested so far, only AZARDI preserves the italics. They are discarded by iBooks, Google Play Books, Kobo, and Kindle/Mac. The spec is typically noncommittal about a reading system's obligations:

When requested by a user, it MUST provide access to the links and link labels in the nav elements of the EPUB Navigation Document in a fashion that allows the user to activate the links.

[BluefireMicah]

As an RS dev, my take is that metadata that is expressed in RS UI should be malleable to the functionality, accessibility, and usability goals of the app creator. Indenting and italics and other visual tools for making a TOC more usable are useful tools, but should be consistent from book to book. The full expressiveness of HTML would be problematic in this regard. A subset would be useful (e.g. the equivalent of markdown) but clearly it is pragmatically difficult to open the door just a crack. Thus, using HTML markup seem particularly problematic to me in this use case. Something more "meta" that indicates hierarchy and classes such as "title" or "author" makes more sense (the XML'y approach). Of course, this is unlikely to satisfy various constituents. So, we'll probably end up with limited and inconsistent RS support for the most common HTML markup in TOC, eventually creating a kind of informal subset spec. Which works, in its messy painful dominance.

[JayPanoz]

To put my feedback very short, imagine the Reading System below didn’t follow this rule.

(And it’s a valid EPUB file, automated checks wouldn’t have caught the inline script in the nav.)

[dauwhe]

Counterexample:

<nav epub:type="toc">
<ol>
<li><a href="content_001.xhtml">the names of these states in arabic are <span dir="rtl">مصر</span>, <span dir="rtl">البحرين</span> and <span dir="rtl">الكويت</span> respectively.</a></li>
</ol>
</nav>

This displays incorrectly in every reading system I've tried so far (which admittedly is not many). The inline markup is necessary. HTML has tremendous power to display content to the user as the author intended. Taking the text value has the potential to throw away meaning.

I don't have an answer here. Obviously processing script inside nav is bad. And reading systems should be able to style the content as they see fit. But inline markup conveys meaning as well as styling.

[JayPanoz]

Oh yeah for sure I was not trying to imply otherwise. I’ve spent 3 months researching i18n too so I’m well aware of this example.

Remember I’m kinda spanning Authors and User Agents and as frustrating as this may well be as an Author, I’m not willing and can’t afford to take any risk as a User Agent – I’ll be, and put other people, in huge trouble otherwise.

My biggest worry is that as long as “security-related issues” will not be tackled/fixed, the current conundrum will slow down progress on authoring/interoperability/compatibility/etc. But people already know my point of view on this subject (cf. origin/localStorage/etc.).

This is not a hill I will die on though, I don’t want to be the guy barking “origin, origin” at clouds.

[murata2makoto]

iBooks appear to support vertical writing and ruby in navigation documents.

[laudrain]

As a matter of fact, many publishers (among them Hachette Livre France) don't ask the nav document to fulfill the goal of displaying exhaustively the TOC.
They use a spine HTML content document for that purpose in their EPUB3 files. That content document for TOC is mandatory in their RFP.

[dauwhe]

Closing because reading systems seem to have little interest in providing a better user experience ;)