Document and book content are not web pages. That is because eBooks are designed for people with an
attention span, who have decided to read a whole book and probably want
to spend more time reading than playing with the knobs.
It is emerging as a statistical probability that no Adobe or Apple programmer has ever actually read a book on their respective devices. I mean something with more than 20,000 words without pictures.
smart device producer would expose the rules they use to the world, so
producers can make explicit decisions.Obviously the sages at "Adobe of the
mud hut" or "Apple of the fruit bowl" are not particularly smart in a user
experience way when it comes to actual reading. They both have very
loose edges when it comes to the OPS even though it is based on the
second best browser in the world (just to start a fight).
The recent fiasco with the release of iBookstore 1.1 which now displays PDFs boringly and has the new user controlled justification feature, also known as the LAYOUT DESTROYER obviously needs serious action. It appears to have fallen on me to sort the whole darn mess out.
I have therefore written a simple User Story so the folks at Infinite Loop can stop going in infinite circles, and can grasp the basic set of rules that will give users control AND allow authors, editors and designers to create pretty darn hot ePubs.
If you are an Apple iBookstore developer, it is mandatory for you to read the following. It is optional for the rest of the world.
Instructions for iBookstore Programmers
You are programming for an iBookstore. It is not a website or general application. There are rules that have been developed by intelligent caring people over centuries which you don't have to struggle with or even understand if you follow these simple guidelines.
Reasonably you should try and grasp that the concept of text-alignment and justification (we will leave hyphenation out in this iteration) applies primarily to bodytext, and primarily for linear reading material. If you can't do that, don't worry, just follow the rules.
There are many structures in documents (document is a collective noun that encompasses books) that use paragraphs that should not or must not be justified or have any other forced alignment, because that will destroy the value of the content, and the reader experience. (Yes. It is professional to at least pretend to care).
The rulesThe lists are short to match your attention spans.
following elements may be text-align modified by the user control from
the application interface using your brainless, untested code:
- Any <p> element that does not have a predefined text-align statement
- Any <p> element that has a text-align: left; or text-align-justify; property
- Any <li> element that does not have a text-align statement of its own, or inherited from its <ul> or <ol>. This must also be handled for nested lists.
- Any <p> element in a <div> element that does not have a text-align statement of its own, or inherited from the parent <div>.
Your quick hack, get it out the door code must ensure text-align control is never be applied to the following:
- Any <p> element that has a text-align: center or text-align: right; property.
- Any <li> element that has a text-align: left, right or center property.
- Any <p> or <li> element in a table cell.
- Any <h*> (where * means 1-6 dum-dum)
- Any <span> even if it is display: inline, etc. just don't do it. OK. Leave it alone.
Support for ePub Developers
This of course will be supported by the:
Apple iBookstore Best Practices Guide for ePub Producers
Using the layout power of the Safari
to create compelling user reading experiences
and still let the user fiddle with the knobs
We are committed to empowering you produce superb books that present well and still provide user control when required. To enable ePub producers to create books of the highest standard we have made the following information available.
Please read and understand this helpful, updated, easy to find guide when styling your ePubs for iPad and iBookstore.
It is essential you allow users to control the presentation layout of their book for accessibility and because they have their idea on what is readable. Just because some people are so damn opinionated that they really feel reading the book they purchased, in 10px right-aligned Chancery Cursive is their thing; we say - let-em!
For this reason we have provided a number of user controlled features with clearly stated implementation rules so you can create books of excellence, and still let the obstinate Chancery Cursive brigade do their thing (you have to stop caring so much). The guidelines are:
- Text size. The user can control the relative size of the display fonts. This is a stepped, sizing operation that will maintain the relative layout proportions you have assigned if you have used relative units for your layout. At certain sizes and with certain content this will inevitably cause strange flow things to happen and titles and headers to wrap strangely. Remember it's their iPad, their book, their choice. They are allowed to be stupid. You have to stop worrying. They have already brought the book.
- Font-family. The user can control the default fonts. If you have used a combination of Serif, Sans-serif and monospaced fonts, the user controls will over-ride all your custom font-face settings applied to <p> and <li> elements. Yep, the lot. If you have used named font-families, Zap! The same. Other elements such as <h*> and others will not be affected. This modification is about the reading experience of linear text and we respect your design decisions too.
- Justification or Align-left: Where you put no text-align control, justification or align-left onto any paragraph, the application will allow the user to change the layout presentation. Where you put text-align: center or right, the application will honour and respect your decision because we are assuming you are intelligent and creating a commercial masterpiece, not just practising HTML. This option lets people fiddle and think they are being interactive while only half destroying your design intentions.
Of course this is just a stub document, but should give the lads and lasses at Cappuccino a useful starter kit to get into optimal e-book action.
I have virtually done all the work. Now all they have to do is type the code and publish the documentation.