Readium CSS Update — Pagination implementation
This article was written by Laurent Le Meur, CTO of European Digital Reading Lab, and Jiminy Panoz. Starting July 3, Jiminy will work on the Readium 2 CSS and be one of your privileged interlocutors throughout the process.
We have made good progress since our call to participation.
First and foremost, we have a brand new repository for this project. It’s called Readium CSS and you are warmly welcome to join in.
You will probably see that we’ve already collected User Agents Stylesheets (Chrome, Firefox, Safari, Edge), validated them against HTML5 Suggested Rendering, have implemented pagination, safeguards and page margins in a dedicated branch, and have created some issues and a wiki. That is quite a start.
If you take a look at pagination, you’ll see it’s using CSS columns—and you may be a little bit disappointed. To put it simply, we need a cross-platform solution which is reliable and fast. We took a look at paged overflow, custom elements and the shadow DOM, and CSS regions, but their support is either terrible (overflow: paged-x
) or not widespread enough. In other words, we can’t reasonably use them yet.
The most important though is that we’re designing everything from scratch, so we can revisit how things have been done so far, review existing implementations, try to fix long-standing issues and leverage some powerful specs for which support is now widespread.
Obviously, we’ll need feedback and (a lot of) tests to make sure the solutions being currently designed can be sustainable. Readium CSS is a baseline any Reading System will be able to use. It will also ship with recommendations and best practices, therefore we must guarantee it won’t create side effects. And we need your samples to make sure we’re doing this right.
We’re also willing to find solutions which can open up the possibility of new design options for authors. But it is critical that:
- we check it won’t impact in any negative way the millions of ebooks already available;
- we can prove there is a use case for those options: if authors don’t speak up, there will be no visible incentive for implementing them.
Although we’re doing our best to make sure those design options can be managed at the CSS level, it will be a little bit of extra work for implementers. They have complex issues to deal with (performance, support, user settings, etc.) so we have to prove them there is a strong demand for such options.
We’ve opened an issue so that authors can list their needs but feel free to use the readium-css(at)edrlab(dot)org mail address if you don’t want to use github or prefer to provide private feedback.
Speaking of design options, our current page margins’ implementation could allow for interesting design solutions, like full-width images, background-colored headers and code snipppets. And it would be as easy as adding a custom attribute in your markup and letting the Reading System take care of everything. Other Reading Systems could probably try to find ways to implement that in their current design, should a lot of authors use it.
The thing is we’re not sure we’ll end up with this implementation, and we’ll need authors’ feedback as well as implementers’.
Our current implementation can be discussed on the dedicated issue. It has been documented so that you can have all the information in hand before commenting. Once again, feel free to use the readium-css(at)edrlab(dot)org mail if you prefer private feedback.
We will start working on default styles (for unstyled books) soon. Feel free to join the #readium-css Slack channel if you want to weigh in.