Re: [css3-gcpm] [css3-page] Named page lists

Also sprach Tab Atkins Jr.:

 > Please indulge me in allowing me to repeat this in my own terms, as I've
 > been trying to understand the page-layout voodoo magic for a while, and am
 > just now getting a decent grasp of it (I hope).
 > 
 > Page boxes are purely linear, without a hierarchical structure at all.  Any
 > hooks into them (such as :first and :left/:right) are determined solely by
 > the adjacent page boxes -

Right.

 > :first is defined as matching any page of that
 > name which is directly preceded by a page of a different name.

That's what we are discussing. There are (at least) two options:

 1) :first matches only the first page in a document
 2) :first can be used with named pages and matches the first page in a page group

Your wording is, in fact, a third option. I'm arguing for 2) because I
want to style the first page of every chapter in a book, with this kind of markup:

 <div style="page: chapter">...</div>
 <div style="page: chapter">...</div>

 > As long as a
 > piece of content has the same page name as the previous piece of content
 > (using the normal tree descent algorithm), it will fit into the same page
 > box, generating new page boxes as necessary when there is too much to fit in
 > a single box.
 > 
 > So, this fragment:
 >  <div style="page: chapter"/>
 >  <div style="page: chapter"/>
 > just generates a succession of pages named "chapter" without any way to
 > distinguish between the page boxes generated by the first div and the page
 > boxes generated by the second div (assuming the content of either div
 > doesn't have any content with a different page specified).  In fact, the
 > first bit of content from the second div is likely to show up in the *same*
 > page box as the last bits of content from the first div.

Yes. But it's also likely that explicit page breaks are set on these elements.

 > Jacob seems to want there to be some way to distinguish the two, so that the
 > second div establishes a *new* block of page boxes which create a page break
 > between them and generate an additional match for the :first pseudo-class.
 > In effect, he'd be asking for algorithm that groups together page boxes to
 > *not* be based on page names, but merely on the *declaration* of a page
 > name.  Any page-name declaration would generate a new group of page boxes.

This is also an option, and it could be a good one. This way one would
avoid having to set the explicit page breaks. It's a more radical
proposal, though, as it would introduce page breaks where CSS2 didn't
have them.

 > This does cause obvious problems with declarations like this, of course:
 > <div style="page: chapter">
 >    <p></p>
 >    <p style="page: chapter"></p>
 >    <p style="page: chapter"></p>
 >    <p></p>
 > </div>
 > <div style="page: chapter"></div>
 > How many different groups of page boxes are generated (and thus, how many
 > page boxes would match a :first rule)?  Traditionally, just one.  A naive
 > reading of Jason's rule would generate 5 (from first div to second p, second
 > p itself, third p itself,  fourth p to end of first div, second div). There
 > are a few similar ways of excluding this case (treating some named page
 > values as "auto" when an ancestor has the same page name), but I found upon
 > writing them up that the differences are both subtle and significant (that
 > is, hard to see but *important* to see), and so instead I'll just let Jason
 > say how he would assume this example would render.

I'm neither Jason not Jacob, but I'd say 3 if we go along with Jacob's
proposal as you have written it up above.

 > I think, though, that the complexity this adds in to the workings of page:
 > is probably a bit excessive when you start trying to deal with children who
 > may have the same page name.  Explicitly grouping page boxes a la
 > prince-page-group (in addition to the standard page box grouping defined
 > purely by page name) is probably the correct solution, unless we find that
 > the algorithm for excluding this is simple and serves virtually all cases,
 > but doesn't break existing stuff.

Indeed, the Prince solution has been implemented and seems to work
fine if one can stomach another property. It's not very elegant, though.

 > Currently, though, I'm with Fantasai in stating that as written this extra
 > page box grouping goes directly against the current handling of page box
 > groups.

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Friday, 11 July 2008 19:49:00 UTC