I see some value in both perspectives here. Certainly Word (for example), generates css and html with a lot of boilerplate code. For purposes of conversion to ePub, one could eliminate most of that. And if you are trying to edit the raw code, it is arguably simpler to use the deprecated tags, and the result is much clearer at the local code level. However, if an ePub document uses well-chosen CSS boilerplate, it becomes much easier to globally modify important settings across the scope of the entire book. I think this is the direction we'd like the industry to take (and the direction we should take in authoring ePub books ourselves.)
Here's why I say that: as I'm reading this and some similar threads on other forums, there is a lot of interest in being able to personalize ebooks. Some people prefer wide margins (like physical books); others want little or no margin (minimize page turns). Some people like serif fonts; others not. Indented paragraphs versus space-separated paragraphs. Left justification versus full justification. Running page headers versus none.
For these features to be easily configured by a savvy reader, they need to be set in a standardized way in the CSS code so that we can quickly unpackage, tweak, and repackage an ePub (assuming this is not DRM-blocked.) Let's call this re-authoring personalization.
To be easily configured by a mainstream reader, they also need to be set in a standardized way in the CSS code so that the reader software/firmware knows exactly what to override at reading time. Let's call this runtime personalization.
Personalization may only be an "enthusiast" issue, however, the new B&N PC reader software actually exposes several of these choices as Settings-->Reading Preferences, and this suggests that there is broader interest in personalizing the reading experience (well beyond, say, the Sony software's size option):
Font
Text Size
Line Spacing
Margin (Slider)
Full Justification (Checkbox)
Underline Links (Checkbox)
Text Color
Selection Color
This raises two questions:
1) Can any nook owners say which if any of these personalization features are exposed on the reader device?
2) Has anyone experimented with how these settings interact with CSS and HTML settings? I suspect they simply override the book content, and while this will work for a lot of content, it may break some cases (e.g., if a user's chosen font is proportional and some of the content requires a non-proportional font.) To provide a better experience, the runtime personalization should be defined to only impact some set of identifiable styles.
Having a great cross-platform personalization story is going to require another full round of standardization around how to use CSS. The reading platforms (both hardware and software) will have to synch up on what features should be configurable, and the publishers will have to agree on how those features are driven by CSS, and then author conformant content. In the interim I can well imagine different vendors offering a variety of personalization options that are implemented by overriding book content.
Some of the folks on these forums are involved in both implementing reader software and authoring content. Would it make sense for them to come up with a strawman personalization proposal that developers and publishers could opt into using?
Steve
|