Recap of #eprdctn feedback and queries

One important part of the Readium CSS project is collecting feedback and queries from the e-production community (CSS authors).

I think it is important to make a recap so that this information is available to implementers and authors can weigh in—I know there’s an issue #1 for this but it has gone way out of focus and quite difficult to parse.

CSS Authors’ typical profile

The typical CSS author has been doing e-production for 3 years or more (76%), is primarily concerned about interoperability (80%) and feels like he/she gets at least CSS fundamentals (88%). Also, most of his/her queries are related to layouts you can do in print that you can’t in ebooks yet.

So, I know there is no average, there are extremes (and the middle will take care of itself), but from experience, I can tell that is a pretty common profile in the eprdctn community. Same for queries, as publishing is still a print-first industry (and print layouts are “the gold standard”).

A few personal notes:

interoperability implies Kindle, back to Mobi7 (which was ± HTML 3.2);
from the samples we could collect, there were (a few) specific versions of EPUB files for iBooks, which is an issue partly related to distribution (authors don’t know the app the reader will use and don’t want risking rendering issues);
sometimes, specific versions mean authors (and/or software) will fall back to EPUB 2 files, in order to get around support uncertainty;
one key is probably progressive enhancement techniques, but that’s more of an education/evangelization issue—we quickly discussed this with @HadrienGardeur and the lack of pragmatic docs, best practices, etc. indeed can be a practical issue.

Workflow and authoring

Workflow is still print-centric

DTP software is still prevalent (more than 2/3 of answers), but automation is a thing (XML and even Node.js).

This means that should we provide new design options, change won’t happen overnight. Authors would have to add them to their workflow first (manual editing or automation upgrade), then authoring software would have to support them.

What’s interesting is that most authors would appreciate having such design options (more than 75%, on two polls), but if there isn’t any side-effects in other apps (cf. interoperability). Of course that would require production moving to EPUB 3 (EPUB 2 still makes up roughly 70% of all incoming content @ Kobo).

So once again, we have an education/evangelization issue there.

Authoring practices

CSS authoring varies greatly—and this shows in our samples, we’ve even found a file in which InDesign generated styles were inlined.

Almost 2/3 of authors use a custom stylesheet that they adjust for every book, very few actually rely on the styles output by their DTP tools. As a consequence, there’s no consensus when it comes to the CSS selectors authors use. It can be:

p
.class
p.class
div.class p.class
[epub|type=""] p
super-specified selectors with or without combinators (from samples).

Reasons include:

ease of use;
complexity and variety of the publication contents;
semantics (especially with epub:type);
“that’s how the conversion vendor does it.”

To me, it means that if we want to solve the user settings issue well, we’ll have to find clever and inventive ways, selectors specificity being a dead-end in practice.

There’s a proposal for user agent properties, a draft for customization, etc. and I feel like they have some potential—for upcoming files, what’s already distributed is probably lost—, should EPUB have a “do not touch my CSS” mechanism at some point. E.g, with user agent properties, authors could design user-centric stylesheets (in theory, RS could not override styles at all and just set values for those properties).

In the meantime, we have to “emulate” the cascade (see issue #5) and resolve to !important. So that’s trying to make a not-so-perfect mechanism into something more elegant, which requires a lot of fine-tuning.

Worries and issues

Worries

What bothers authors the most:

the app overriding styles without asking/user’s explicit demand (a.k.a. user setting)
the complete lack of control over page layout (margins, background, etc.)
user overrides which are all or nothing

Interestingly, reading modes’ adjustments and user settings feedback are not priorities—which doesn’t mean they aren’t concerns. There’s two assumptions I could make there:

providing readers with images filters in night mode (cf. issue #7) is probably the best first step we can make as a significant part of authors might not use extra markup to deal with it on an image-per-image basis (especially if no other RS supports it);
user settings feedback is probably one of the best practical ways to deal with non-binary user settings and overrides (cf. user agent properties proposal) so, once again, education/evangelization kicks in.

Issues

Top issues in order of priority:

images’ sizing e.g. author’s sizing is not respected, image is cut-off (we have a safeguard for that);
broken media queries (which makes responsive design impossible);
lack of support for modern CSS;
Math.

I guess this won’t surprise anyone, those are long-standing issues in need of solutions (media queries don’t work in columned-content) and fixes (flexbox, grid, and modern layout specs have a lot of bugs in columns’ implementations). Our best bet there is collaborating with the CSS-multicol spec editors since we’re probably one of the major use cases for this spec.

Popular requests

Unsurprisingly, a lot of requests are about layouts possible in print that you can’t do in e-.

full bleed (container, image, background-color)
support for paged-media (running header/footer, float figures top/bottom, etc.)
vertical centering and alignment
floated shapes (wrapping the image and not its bounding box)
possibility to use margins for icons
baseline grid
force chapter title as running header
proper support of page-breaks
media queries for reading modes (sepia, night, etc.)
stylable popup footnotes

Interoperability issues reported

We care deeply about interoperability. Although Readium CSS has been designed from scratch, a lot of research has been put into other Reading Systems in order to improve interop (and not introduce breaking changes/side-effects). To my knowledge, we’re even the first project openly tackling EPUB implementations’ interoperability.

Let’s say that one of our major goal is to provide authors with a solid bedrock, so that Readium CSS does not become an issue for them.

A few interop issues have been reported, and I guess it’s worth listing them:

page margins: some apps/devices have huge page margins, others don’t have any, it’s really hard for authors to know what they should be doing here (margin: 0 or margin: value);
support the stuff that already exists, don’t create custom namespaces/metadata (the issue being that some existing specs are really really hard to implement well in practice);
image optimization (I guess this can be related to picture and srcset);
font obfuscation isn’t implemented everywhere.

readium / readium-css