Re: [css3-gcpm] New Editor's Draft

Dave Cramer wrote:

 > A new editor's draft of GCPM is available at [1].
 > [1]

This is good work, I'm happy to see newfound energy for this inside W3C.

 > 1. Running Headers and Footers
 > ---------------------------------------------
 > The 'string-set' property's content-list now includes an
 > 'attr(<identifier>)' value, so that attribute values may be used as
 > text in running heads. This has been implemented by AntennaHouse
 > and Prince.

Nice to see interoperability here. I'm not sure one needs to add the
'attr()' syntax explicitly, though -- it should be automatically

 > The running element section has been mostly deleted, awaiting a
 > fundamental decision on syntax. Prince uses one approach, and
 > previous versions of GCPM used another.

AntennaHouse and Prince now both support the GCPM syntax:

>From the Prince release notes:

     Support for "position: running(ident)" and "content:
     element(ident)" syntax for flows defined in CSS GCPM module.

 > The previous editor's draft of GCPM used float: footnote to
 > identify an element as a footnote. Where the footnote was actually
 > positioned depended on the float, columns, and column-span
 > properties of the @footnote page region. One current
 > implementation, Prince, uses a somewhat different approach, where
 > the float property on the footnote also helps determine the
 > positioning of the footnote [3]. Current values are footnote
 > (bottom of page), inline-footnote, column-footnote (bottom of
 > column), and inline-column-footnote. @footnote just determines the
 > appearance of the footnote region itself.
 > [3]

Two things are being discussed here: (a) how do we turn elements into
block/inline footnotes, and (b) where is the footnote area, at the
bottom of the column or page?

Prince addresses both these questions by adding keywords for all
combinators of (a) and (b). This leads to many keywords and makes it
hard to add more levers in the future. After dicussions with Prince
developers, I suggest something like:

  span {
    float: footnote; 
    footnote-display: block | inline  /* addresses (a) */
    float-reference: column | page;   /* addresses (b) */

The 'float-reference' property is sketched here:

In this model, one would have several footnote areas: one at the
bottom of the page, and one at the bottom of each column. I think this
is ok, although it becomes harder to define what this means:

  @page { @footnote {
    position: absolute;
    top: 2em; left: 2em; width: 6em;

 > This spec is proposing a somewhat different model for footnotes. 
 > CSS Books does not have the footnote-policy property.

I think footnote-policy is nice to have. It's probably a stretch for
current implementations, but it's good to show that we have thought of
it and that it fits our model.

 > The CSS3 Page Module defines page pseudo-classes for first, left,
 > right, and blank @pages. A major goal of GCPM is to extend this to
 > allow the selection of any document @page. The previous draft of
 > GCPM used the page-group property and the nth() selector to do
 > this. A page group is essentially all the pages generated by an
 > instance of an element (often a section or div), when that element
 > uses a named page (what desktop publishing people would call a
 > master page):
 > section.chapter {
 > page: body;
 > page-group: start;
 > }
 > Prince and previous versions of GCPM used page-group: start to
 > change the behavior of the :first page pseudo-class, so that it
 > would select the first page in the page group instead of the first
 > page of the document. In the above example, @page body:first would
 > select the first page of every chapter, which is really useful.
 > But this changes the meaning of :first, which was defined in CSS
 > 2.1.

I'm nut sure it changes anything, it just describes what happens when
:first is combined with a named page. Like:

  @page chapter:first { .. }

This is useful and the syntax is intuitive. And it is interoperably
supported by Prince and AntennaHouse:

 > I'm proposing to remove the page-group property, by
 > stipulating that assigning a named page to an element automatically
 > creates a page group. 

I agree that it would be good to find a way to automatically identify
page groups. In your example 12, you have a table that suggest an
hierarchical model, where pages can be in several page groups at the
same time? Would there be any inheritance from one page group to another?

Another idea is to rely on explicit page breaks to define page groups;
by setting 'break-before: page' you would start a page group:

   .chapter {
      page: chapter; 
      break-before: page;


              Håkon Wium Lie                          CTO °þe®ª        

Received on Sunday, 2 March 2014 05:40:47 UTC