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

On Fri, Jul 11, 2008 at 2:48 PM, H�kon Wium Lie <howcome@opera.com> wrote:

> Also sprach Tab Atkins Jr.:
>
>  > :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>
>

I meant it to be the same as your (2), I was just making explicit what I
believe is the current method of defining a page group - solely through
changes in page name.

 > 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.
>

Ah, okay.  I thought that this was meant to act *completely* like a new page
group as such things are treated now, with an implicit page break.  If it
just establishes a page group, but implicit page breaks are still defined by
an actual change in page names, then it's not nearly so weird of a
proposal.  That still leaves some possible questions, though.  Are there any
other properties that would apply to page groups, and if so, do they make
more sense to apply to page groups as you define them or to actual page-name
changes (like the implicit page-break algorithm uses)?  What about future
properties, which are hinted at in the Paged Media spec?  Should we define a
page-name-group as a useful concept to work with?  Frex, James' email that
just came in asks about a :last pseudoclass; I think that if such a property
existed it would make the most sense for it to apply to your page groups
rather than a full page-name-group.  Are there any others that might make
sense to apply to the page-name-group instead?

Also, how does this treat children of a named-page element who have the same
page-name?  This'll be questioned further in a bit.


>  > 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.


Sorry, I meant Jacob.  My mind switched over to using Jason partway through
for some reason.

What are the 3 page groups that you see, and exactly how did you arrive at
them?  The only possible parsing of that fragment into three page groups
that I can see is pretty inconsistent with what's been discussed so far.

I see a possible 4-group parsing, where each entire <div> is a page group
and the second and third <p>s are page groups, but that's now a *very*
different model of page groups than currently exists.  It would make page
groups hierarchical rather than linear, which I don't think is at all
intuitive.

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?



> > 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.


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

~TJ