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

Also sprach Tab Atkins Jr.:

 > >  > 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'd say 3 if we go along with Jacob's
 > > proposal as you have written it up above.

 > What are the 3 page groups that you see, and exactly how did you arrive at
 > them?

Sorry, I meant 4 -- each element with a non-auto value on the 'page'
property starts a new page group.

 > Hmm, looking again I see another 4-group parsing, with the groups as: first
 > <div> to second <p>, second <p> itself, third <p> to end of first <div>,
 > second <div> itself.  This brings us back to a linear model like we would
 > expect, but it requires that the fourth <p> (with a page name of auto) use
 > the pseudo-inheritance that Jacob and you talked about where it *acts* like
 > it's page name is "chapter" (as that's the page name of its nearest ancestor
 > with a page name), and thus can merge into the page group generated by the
 > third <p>.  Is this what you mean?

Yes. 

 > > Indeed, the Prince solution has been implemented and seems to work
 > > fine if one can stomach another property. It's not very elegant, though.
 > 
 > Nodnod.  It seems to me to breakdown to two issues:
 > 1)  Are page-name-groups useful outside of implicit page breaking?  If yes,
 > then we should go with Prince's strategy of explicitly specifying page
 > groups, so that the page: property doesn't pick up any weird interactions
 > and can stay devoted to creating page-name-groups.  If no, then it's likely
 > fine to work things as you suggest.
 > 2)  How are children handled when they have the same page-name as the
 > nearest ancestor with a page-name?  

They still start a new page group. One must presume that the value has
been set for a reason.

 > Depending on how this is intended to
 > work, it may be easier and more intuitive to go with Prince's explicit
 > page-group property.

Perhaps.

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

Received on Saturday, 12 July 2008 22:34:02 UTC