One important part of the Readium CSS project is collecting feedback and queries from the e-production community (CSS authors). This is a summary.
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%). Most of his/her queries are related to layouts you can do in print but you can’t in ebooks yet.
A few notes:
From the feedback we could get, 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 for instance).
So once again, we have an education/evangelization issue to deal with there.
CSS authoring varies greatly.
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:
If we want to solve the user settings issue well, we’ll probably have to find clever and inventive ways, selectors specificity being a dead-end in practice.
There’s a proposal for user agent properties and a draft for customization, they have some potential for upcoming files if EPUB gets a “do not touch my CSS” flag at some point – what’s already distributed is probably lost. With user agent properties, authors could design user-centric stylesheets so, 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 and resolve to
!important. So that’s trying to make an unperfect mechanism into something more elegant, which requires a lot of fine-tuning.
What bothers authors the most:
Interestingly, reading modes’ adjustments and user settings exposure are not priorities – which doesn’t mean they aren’t concerns. There are two assumptions we could make:
Top issues are, in order of priority:
This shouldn’t come as a surprise; those are long-standing issues in need of practical 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.
Unsurprisingly, a lot of requests are about layouts possible in print but not (yet) in e-books:
A few notes:
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 our knowledge, we’re even the first project openly tackling EPUB implementations’ interoperability. Indeed, one of our main goals is to provide authors with a solid bedrock so Readium CSS should not become an issue for them.
A few interop issues have been reported: