Web dev at the end of the world, from Hveragerði, Iceland

On CSS Page Templates

Reasons why I think CSS PGT is a bad idea, off the top of my head, written while I’m sipping my tea and preparing lunch:

  1. Anything not covered by the combination of being able to set a page’s basic styles (backgrounds, borders, margins, etc.) and the CSS WG’s current work (flexbox, regions, grid layout, exclusions, etc.) is an edge case.
  2. My understanding is that the spec is intended for magazines (and not basic reflowable books whose basic design needs still haven’t been covered). CSS PGT will never be implemented outside of the ePub ecosystem. It is irresponsible to tie magazine publishers to one ecosystem with no option for reusability. It is a very bad idea to promote an overly specific, overly complex, solution that cannot be reused by the magazine developers on other platforms.
  3. So important that it bears repeating: The designs you cannot implement with regions, exclusions, and, possibly, one of the layout specs, are very much edge cases. Why go through all of this effort to design a spec for a tiny minority when the design needs of basic reflowable epubs aren’t being covered? We really need the ability to style pages properly: full-bleed backgrounds, borders, and margins. The current model that enforces a constant white margin on every page is intolerable.
  4. It increases stylesheet complexity in an effort to decrease implementation complexity. The expr() addition covers most of the same use cases as calc() but its only major virtue is that it’s simpler to implement in contexts such as browser-based ereaders. Its variables are more complex than (and completely different from) the CSS variables proposal that is emerging from the CSS WG. Its function additions make it more complex to use. The cases that calc() doesn’t address but expr() does are edge cases. The calc() function is being implemented by by Mozilla, IE, and WebKit. The expr() function isn’t being implemented by anybody and is unlikely to ever exist outside of the few ereaders that might end up implementing it.
  5. It borrows concepts from moving specs. The current version of the Regions spec, for example, doesn’t have flow-options, flow-linger, flow-priority. By borrowing concepts from another spec, instead of just telling people to use the other spec, CSS PGT loses out on essential features such as the CSS OM additions while being otherwise more complex (more options = more complexity). Just tell ereader vendors to implement the Regions spec.
  6. I mentioned this in point five but it is a point on its own: CSS PGT’s version of Regions is much more complex with three new properties. This decreases the chance that browser-based ereaders can implement this by just mapping it onto the browser’s Regions support (browsers are unlikely to implement CSS PGT).
  7. The min-page-width and min-page-height properties which are for “selecting a page master based on device dimensions” overlap completely with media queries, which allow you to selectively enable styles based on properties such as device dimensions. PGT’s solution might solve cases where the page’s dimensions aren’t that of the screen (such as cases where the ereader renders two pages in a spread in a landscape orientation) but that would be better solved by simply defining the page to be a window – that the min-width and min-height queries apply to the page. Whatever solution is chosen, it is always better to build on a pre-existing spec than invent your own.
  8. Using the CSS Paged Media spec’s idea of being able to add styles to a @page declaration is the simplest, most logical, solution for the needs of the vast majority of ePub developers out there. This has the added benefit of making it easy for them to reuse those styles for print (which would let them, in many cases, use the ePub as a master for both the ebook and the print book). If people want to style an on-screen page and not a print page, they can simply use the screen media query. Named pages also address many problems the designers of reflowable ebooks are facing today in ways which are hard to solve any other way. If you are going to reuse concepts from other specs, choose a spec that isn’t being actively developed but for which there is a much greater need in the ebook community than in browsers. Creating a new layout spec that competes with active work at the CSS WG is a bad idea.

All in all, I think it’s a bad idea for the IDPF to be designing a CSS layout specification from scratch outside of the CSS WG. Any members who have needs as extensive and complex as this spec is should take their work to the CSS WG. If the CSS WG doesn’t want to look at it then it should be dropped.

This spec also doesn’t address the pressing needs of current ebook developers. We need the ability to style reflowable pages properly, something that is impossible at the moment in every major ereader. Why focus on the needs of the few while ignoring the many?

It’s insane that I can’t tell iBooks or Kobo that a chapter should have a full-bleed grey background, for example, while the IDPF spends its resources and time designing an intricate, untested, and complex layout spec that will be used by a minority of the publishing industry as a whole.

Absolutely bloody insane.

ETA: I've posted a followup here.

You can also find me on Mastodon and Bluesky