Re: Calling for a massive revamp of Paged Media and GCPM

On Sun, Jan 13, 2013 at 12:46:12PM +0100, Daniel Glazman wrote:

> 1,3,4.
>    the Paged Media and Generated Content for Paged Media specs do not
>    allow content-rich headers and footers at this time.
>    ...
>    should live in the markup side of the document
>    ...
>    too weak to [...] persist across the pages of a given section
>    ...
>    content() [...] only allows to retrieve the textual contents
>    of a given element without capturing its richness

The way the above is written seems to ignore
http://www.w3.org/TR/css3-gcpm/#running-elements .
(EPUB uses a broadly similar approach, viz. display: oeb-page-head or -foot.)

That's not to oppose the idea of trying to use grid, flexbox etc. stuff for
pages if that makes implementation or stylesheet creation easier, I'm just saying
that I don't think header content richness or persistence across a section are
reasons for it.


I'm also not sure I understood the point about bookmarks.  Are you merely
saying that slots could be used, or that they are advantageous?

The existing css3-gcpm functionality currently called "bookmarks" closely
matches PDF "document outline" functionality, where these bookmarks form a tree
(hence bookmark-level), and each item label is limited to plain text, and each
parent item can specify whether or not it initially shows its children
(bookmark-state).  Consequently, implementing the existing css3-gcpm approach
for rendering to PDF might be described as "simple, efficient, rich, clean".
[I wonder whether tree formation or target specification could be simplified,
but neither of those ponderings make me think of slots.]

How would a slot-based approach work for supplying the tree, or the
initially-open value for each parent?

(The text-only restriction might be another problem: no worse than rendering to
a text-only UA, but it might not be much better either.  Try disabling images
in your web browser for a few days to see how well that works in practice.)

Perhaps these are the wrong questions: perhaps a slot-based or other
content-based approach (e.g. html5 <nav>) should supplement css3-gcpm bookmark
functionality rather than have just one or the other.

pjrm.

Received on Monday, 14 January 2013 06:14:51 UTC