Styling for the complete book

9 posts / 0 new
Last post

Content Documents 3.0, section defines only alternative styling for XHTML and only
a few specific class list values, however both for XHTML and SVG content element styling
can be provided as well with XML processing instructions without a class attribute, therefore
this approach seems to be pretty incomplete.

Therefore I suggest to introduce a mechanism to provide stylesheets for the complete book, including alternative styling.
If the author on the other hand wants to exclude some files from the book styling, this needs
a mechanism too, maybe the usual approach of allow and deny lists in the OPF document for
each alternative styling.

Another approach could be to require, that once a style with a title is chosen by the reader and
other documents within the books have styles with the same title, user agents should be
required to use the style with the chosen title and not the default, if alternative styles are present.

In both cases the alternatives are not limited to a few styles, authors can provide an arbitrary number of styles with appropriate naming in the language of the content of the book.

The other advantage of both approaches compared to the current situation is, that the alternative style can be chosen for the complete book once and as well for SVG and XHTML content documents, independently how the stylesheet is referenced or embedded.

Why is this relevant for embedded SVG documents as well?
Typically it is not easy to apply the same style for an embedded SVG document as for the embedding XHTML oder SVG document, but this can be relevant for example for comic like
books with the option to adjust the fill or stroke of paths or background shapes to the styling of the embedding document. The current solution is to put the SVG fragment directly into the
main XHTML document, but this is suboptimal, if the SVG is used more than once in the book.
Still one can reuse fragments of SVG documents with SVG intrinsic methods, but this requires
some advanced implementations of SVG viewers. The behaviour of implementations is usually
more predictable and relyable for authors, if simply a complete SVG document is embedded.

Thanks for the suggestions. Re: a global style sheet, I don't understand what is in practice hard for either content authors or Reading Systems about having, if desired, a de facto global style sheet that is referenced from every content document that wants it. And, EPUB already defines an alternate style sheet mechanism (for example for "day" vs. "night" styles). I agree that the current situation results in resolution of specific style sheet selection per content document but that doesn't seem like a big burden in terms of implementation performance and it provides more flexibility to content authors and keeps EPUB aligned with the broader Open Web Platform. But perhaps you can be more clear on what you find sub-optimal in practice about the current situation. Re: SVG, that seems more challenging, but again wrt alignment of EPUB with the overall Web Platform I'm not sure it woudl be advisable to tackle specially for EPUB harmonization of styling across SVG and XHTML (and I believe SVG WG is actively working on this).

Currently, if you can switch between alternative styles in viewers at all for one document, typically
you have the problem, that it switches back to default, if you go to the next document.
This is already suboptimal for webpages (effectively to be predictable one can use for example
PHP here and a get parameter for the style in each link to preserve the selected style), but
for EPUB you do not have something like PHP to align such things with the selection of the reader, but it is clearly given by the author, what belongs to each other in this one book, therefore it is easy to define, which styles are applicable for all documents, that the reader does not have to select the desired style for each separate document again - especially if it is an embedded document, in most viewers there is not even an option to select an alternative stylesheet.

Concerning SVG - there are ideas to be able to set parameters for SVG documents, however this can be still a problem, if the reader switches the style of the embedding document to switch
such parameters in the link to the embedded SVG document as well in a declarative way.
Therefore for such applications it is not just consistent, but useful as well to be able to apply the
same alternative style for all content documents of a book, no matter how they are referenced,
embedded or used in the book.

To resume, because a digital book in EPUB is a collection of documents, it is obvious, that if
a reader selects one preferred style, that this should be applicable for the complete book, not just for one document, therefore it is reasonable either to define a method in the OPF document to specify such book wide applicable alternative style or to require user agents to
use styles with the same title/name for all content documents, once this is selected by the user for one document. The advantage of this title method is, that it is already available for all methods to refer to stylesheets, one just has to require user-agents to use this available information, if it is the same in the next document and the current document.

For webpages the user-agent would have to guess, what belongs together, but for EPUB archives this is already known, therefore much simpler to do - the situation is quite different.
XML, XHTML and SVG do not exclude to identify applicable alternative stylesheets by exploring the title attributes, this is just difficult to implement for arbitrary content, but simple for EPUB archives. And it is already better defined now than to explore the meaning for a class
list item, no available for for all methods at all.

The current idea in EPUB 3 to do it with a class attribute list item makes EPUB somehow
special, because such class values have no semantical meaning at all, neither in XHTML nor in SVG, but the title attribute already has this specific semantical meaning in general.

I may not be following what's being striven for here, but isn't the point of alt style tags to provide a programmatically determinable means of comprehending alternate style sheets, beyond the human-readable titles that people might give them?
I'll always grant that microformats are a poor man's semantics, but that was the mechanism available that works with HTML5. It was also proposed by the CSS folks, so I'm hardly one to argue against it.
Maybe I've been misreading that spec, but having predictable class values allows a reading system to automatically select one of the provided alternate style sheets and apply it to all the content documents if that's the user's preference. It does say right in the intro that the specification was developed so that "[t]hese class names can be used by a UA to offer special UI access to such tagged style sets."
I don't think the intention was ever that the user would have to keep reselecting the style sheet(s) over and over as they move through spine items, but that their preferences could be matched to the alternate style sheets automatically whenever available.
Granted, the same could be done per ebook on a title basis, and that's not forbidden. You would hope that the reading system would be smart enough, in providing access to alternate styles in the first place, to keep the user selection across documents, provided titles match. I just don't see why the specification would get into enforcing that.
Tags expand the functionality out so that reading systems don't get bogged down in the vagaries of titles. You can draw a parallel to the landmarks nav element, if you like, where the epub:type provides the machine processable value and the link a human readabale selection.

Right and there's a question about whether user-selected style preferences should be persisted across content documents and/or across publications. Individual content documents have no special semantics in EPUB, at least not for reflowable content where they may not necessarily conform to any particular boundary like chapter so I would think that user-selected style preferences *should* be persisted by a reading system in this case (unless, perhaps, the applicable style being overriden was changed in a subsequent content document within the publication). That we don't explicitly say so anywhere in our specs, even as a non-normative note or better yet a normative "should", could be considered a minor spec bug as it would improve practical interop if we were clear about recommended behavior. In the case of publications I consider it more just a Reading System decision whether to interpret a user selection of say a larger font size as applicable to just the publication being read or as a global override preference. As far as user styles for SVG and in general user style overrides on FXL content I'm skeptical of the usability and realistic implementability. Once you are laying out text with explicit positions IMO the text properties and even unrelated things like stroke widths on line art can't be changed without mangling the results.

Well, in the EPUB viewers I tested, even if alternative stylesheets can be selected at all by the user, typically one has to do it for each single document again and one cannot do it for embedded documents. Therefore it would be an important hint for implementors to care about it for reader convenience.

Readium for example seems to have some day/night switch, but if fails as well, even if such classes are noted correctly. Even worse, if SVG fragments are embedded in XHTML, the result can be a disaster - but due to other bugs Readium often fails to present SVG fragments anyway in a meaningful way (it often cuts through the graphics, resulting in two arbitrary parts) , therefore maybe not a good viewer for EPUB at all, maybe not a good example to discuss this issue.

Are there implementations of these day/night classes at all?
I haven't seen any viewer with a proper implementation of this feature.
And because the feature is not applicable for SVG content documents, it is of limited use anyway - at least for some more complex content like comics or some more complex poetry and text, where position and presentation matters for understanding - because XHTML does
not cover such use cases (indeed, finally no poetry at all), SVG is a good choice for this, but
because it has no link element, these day/night classes do not apply and one cannot provide
a unique styling for the book including switchable alternatives.
Currently these classes do not even apply to the style element, available both in XHTML and SVG - there seems to be no effort to get a consistent behaviour, no surprise, that this seems
not to be implemented at all.
Obviously still the title approach is more useful and consistent - a hint for implementors might help to get it really applicable for more readers.

I'm not sure Readium is the best option for testing any more. Development of the chrome extension seems to have stalled around the time that the work on the SDK began, or at least has gone underground. I haven't seen a new version in more than half a year, at least, which seems like a lifetime.

The day/night reading option in Readium is an example of being able to manually pick based on the tags, but I don't see the problem you state of the styling changing between documents. If I add a custom night style sheet it persists across documents in the spine. It doesn't seem much different from the general theme options reading systems provide, which they persist through the documents (and I'm sceptical of alt style tags catching on because of the built-in options).

The result doesn't look particularly nice depending on your styling choices, as I found it exposes the actual content area unless you match the default black background. But what a reading system is supposed to do in periphery when author/user styling changes is a problem that pops up routinely (we deferred in 3.0.1 and it's still being looked at, I believe, for guided navigation). Readium appears to apply its own night reading mode before applying the alternate style sheet.

As far as embedded content goes, my expectation is that if the author has included alternate style sheet declarations in the child content, the reading system in rendering the document should apply the preferred styling to both the parent and the child. If you only add declarations for the parent, it would seem to suggest that the author intent is to not propagate down.

I think I now understand your issue better, at least, as, yes, this method only works with XHTML content documents. xml-stylesheet declarations lack a class attribute that could be used to mimic the functionality for standalone SVG documents, and the spec is quite rigid about not allowing other pseudo-attributes. That effectively makes it impossible to port this functionality across, at least without a modification to the Associating Stle Sheets spec. Maybe that change is necessary, though, to match the new link element.

I'm not sure if SVG handling wasn't included because no one was pressing for it, because it couldn't be handled using this method, or because it wasn't considered. The specification was a bit of a side development to 3.0, so I can't provide any context, at least. Considering the lack of implementation, it might be a hard sell to grow the functionality. You can still use titles in the interim, all that is lacking is the potential auto-application of style sheets based on user preference... and reading systems that give access to them. It's just not terribly consistent from a spec-wide perspective.

Concerning the problem with readium - my current examples are works from Wilhelm Busch (an early and famous german comic writer (1832/1908) - the vectorised versions of the graphics require only paths with a fill. This can be considered as a prototype test case both for uncolored,
stylable comics and classical poetry.

If you embed such a graphic as a fragment for example inside the xhtml:figure
element, it is simple to apply the styling both to the poetry text written in XHTML, using an ops:prefix and ops:type to mark up the poetry with a semantical meaning (LML)
and to the SVG fragment with the same CSS document.
The default for fill is black, usually if no style is applied, user-agents use black text on white background, therefore everything ok, if the user decides to use no CSS at all (but could be still improved by explicitly setting the fill presentation attribute to currentColor).
My first (default) style uses dark blue color for the fill property and the color property and a light brown/yellow background for the day mode. For the night mode it uses almost the opposite - almost white color and fill on dark blue-green background. In readium the day mode is still readable, but for night you get dark blue fill on black background - it clearly ignores styling with the result of inaccessible content.
Even more, it seems to ignore the fact, that the svg element has width and height of 100% of
the available viewport, gets its own size and puts typically an upper part on one pages and
the rest on the next page - what is nonsense for a single graphic.
And even worse, in combination with newer versions of chromium it does not display anything,
if the computer is not online - currently I assume, this is broken software.

Another alternative works better for online-readium: Forget about XHTML and do all the content into SVG files, fortunately this is allowed in EPUB3, for the background I chose a very large circle.
Readium applies the styling of circle background and fill from the default styling, but one cannot
switch to an alternative styling or no styling, as one can do for example with more advanced
viewers like EPUBreader or lucifox for mozilla/gecko based viewers.
Unfortunately the mozilla/gecko based viewer Azardi seems to fail to display EPUB 3 books
completely, it only displays a stupid error message - maybe it does not like SVG for cover images or something like that - this would align to the funny kindlegen, that has problems with
SVG as well, especially with SVG cover images - broken, needless software as well.

What I learned from the about 30 books I created manually up to now - and some more rough test books with 193 tests for EPUB 2, the support of viewers for EPUB 2 and 3 is pretty incomplete and disappointing, if one wants or needs to provide more than simple text markup soup. EPUB looks promising and at least after fixing some issues like this one with styling, once
this could be a good format. But with no viewers for it, it is currently still the best approach for
users to unzip the book again and to view it with a normal browser like Opera up to version 12 or a Gecko, not sure about webKit/blink browsers, because they seem to have more missing essential features.

Still not sure, if I should publish some of my own works in EPUB, currently this is done online with XHTML, SVG, CSS dynamically generated with PHP - and this really works for the user including style switching, because this is done with the help of PHP in a reliable way.
Due to the restriction, that one cannot include animated SVG in EPUB (I have a lot of animated
SVG), EPUB is not a general alternative anyway (I considered already to provide some extension for EPUB 3 to cover my content ;o)

There remains no advantage for EPUB, especially if viewers like readium seem to require now, that users need to be online anyway to be able to read an EPUB book for whatever reason - this looks like an obfuscation of the idea of a digital book, that currently seems to be typical for EPUB viewers inside webKit/blink browsers - it applies as well to MagicScroll, Lektz and the readium clone EMS Epub Reader ;o)

Yes, image handling in Readium has always been a bit harsh. No one added scaling handling, it seemd, but setting CSS max-height to 100% will stop that weird spillover. I've seen it chunk a single large cover image in four pieces without.

Animations came up again during the 3.0.1 revision, but at this time support is still not viewed as stable by the reading systems developers. Without consistency, opening the door would just lead to the other complaint that EPUB implementations are unpredictable. Support is not included not because it's never wanted and will never be allowed in, but you're going to have to wait at least another revision.


Secondary menu