I’d personally get rid of the damned NCX all together and add a simple multi-level TOC section to the OPS file after the spine. Something like:

…

Also, there needs to be a way to create asian style vertical R-to-L text.

Finally, the epub spec should require that all reading systems be able to display the full Unicode character set by default. I hate having to embed my own Japanese fonts in an epub to use it on my Sony Reader. It just makes the epubs bloated (like 14mb each…13mb which is the font).

Unfortunately there hasn’t been a newer “official” build of the validator since 1.0.3, so that is what is in use on the validation site still. You could get the correct behavior by running your own version from svn locally.

We should have paragraph numbers divided into chapters and other divisions for finer navigation (grouped into 10s; i.e. 1-10, 11-20 etc.,). At least that could be tied into a full electronic reference system — edition ID:1.10.

That’s why any software or specs get modularized: to more easily identify blocks of features that should or shouldn’t be used in different contexts.

Unless you think that EPUB should support frames, client-side image maps, server-side image maps and all those other XHTML 1.0 features…

1. CSS layout and good typography just don’t go together. Don’t get me wrong, it is a huge improvement over plain HTML, but it is nowhere near for what is the minimal acceptable level for printed books. The most frustraiting part from the implementation standpoint is that you have to implement all sorts of the functionalities and complexities in the engine, but CSS exposes them in handicapped fasion that makes impossible to make a good use of them. For instance you have automatic numbering for lists, but it cannot be used for chapters and chapter references. Line hight calculation is a total mess which means that line gap is CSS in unpredictable for any complex case. CSS3 only makes things worse, as far as I can tell – just look at the paged media – it is absolutely pathetic!

2. CSS cascade is expensive and useless. If you have p element with class foo you can address it as p, .foo or p.foo and multitude of even more obscure ways. Unfortunately people do that and drain their device batteries repeating the same cascades over and over again. Styling system should have been simple and efficient.

3. Remove all presentational HTML attributes. XHTML 1.1 does it to some extent, but all attributes like align or frame just duplicate CSS and should not have been used.

Now, if I put my authoring hat for a moment, I would:

1. Add XSL:FO and XSLT support to process arbitrary XML markup. CSS has very little traction in pBooks for a reason. Perhaps invent a technology similar to XBL which could be used to define custom tags instead of defining completely custom grammar.

2. Add styling (or add CSS extensions) so that we can mimic word processing programs style inheritance. (CSS cascade idea is just a bad hack from authoring perspective as well and IMHO should be avoided. I cannot image an intuitive WYSIWYG program that would expose CSS cascade to the user)

3. Have a way to do conditional and dynamic styling. CSS3 does conditional styling to some extent (media queries) and dynamic styling (using calc “function” in values and units), but these are not powerful enough and introduce two new (and different) expression languages. I’d rather do XPath.