DPUB IG Telco, 2015-07-06: CSS , Houdini, & Pagination

See minutes online for a more detailed record of the discussions. (The header below links into the relevant section of the minutes.)

CSS, Houdini, and Pagination

After some introduction (by Dave Cramer) to the current work at the DPUB IG on these issues, Chris Lilley, technical director of the Interaction Domain at W3C, gave an overview of Houdini.

A feature of the web is using polyfills—so people don't have to wait for features to be added (this term is also used for non-CSS features, but at the moment we concentrate on CSS only). This, sort-of, works but tends not to work if you use a bunch of them together. It ends up doing lots of re-implementation, which is pointless as the browser already knows how to do it. Also there are some things that are really hard to extend as it happens under the hood. The idea of Houdini (and it's named after a magician) because it's trying to remove some of the hand-waving. In contrast to the more declarative nature of CSS, this is more an API based work (done together with the TAG).

To make it less abstract, the plan is to expose the box tree through API-s. Pages appear there as well, which belong to the box tree rather than to the DOM tree.

The discussion that followed concentrated on how this project influences the work of the publishing community, i.e., and how the requirements of that community are better formulated for the CSS WG. The situation is that

• There should be a "traditional" declarative layer in CSS to describe what is needed for pagination; this is used by authors who would not and should not "see" houdini at all
• Reading system implementors, as well as experimentation with the new CSS features, would have to happen through the houdini API. The reading systems should implement polyfills

This interest group should then concentrate on the first: do we have all the features in CSS that publishing authors need in terms of pagination? The answer is (obviously:-) 'no', and a document is in the making that concentrates on this issue (as an outcome of the work that has been happening for the last few weeks). What would be needed is

• an analysis between what is specified and what browsers actually do—CSS has suffered from multiple inconsistent implementations
• an analysis of the features in CSS around pagination to decide which features are actually useful and usable and which should be left behind because it is not really good design.

An important question is how pagination as a whole is seen by many CSS implementers. There is a misconception that pagination is only important for print; as a consequence, it is usually pushed aside by browser vendors as not really important. We have to make it clear that pagination is a much more general and important concept: it includes slide shows, flashcard, cards, tiles, and it may also be an important UI features when very long texts are read. All the documents should make this fact much more visible to raise interest in pagination overall.