-
Notifications
You must be signed in to change notification settings - Fork 60
-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should reading systems honor inline formatting in nav
doc?
#1191
Comments
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. |
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.) |
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. |
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. |
iBooks appear to support vertical writing and ruby in navigation documents. |
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. |
Closing because reading systems seem to have little interest in providing a better user experience ;) |
I've been looking at what happens to an italic word in an EPUB Navigation document. This is not uncommon:
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:
The text was updated successfully, but these errors were encountered: