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

On Fri, Jul 11, 2008 at 12:46 PM, fantasai <fantasai.lists@inkedblade.net>
wrote:

>
> Håkon Wium Lie wrote:
>
>> Also sprach Refstrup, Jacob Grundtvig:
>>
>>  > Therefore when checking for <named-page>:first you'd have to go
>>  > back to the nearest ancestor with a page valid other than 'auto'
>>  > and match first iff the current page is the first page for that
>>  > ancestor to appear.
>>
>> I ran out of memory trying to parse that sentence :)
>>
>> In my mind, which is arguably quite simple, it appears easier. Here's
>> a pseudo-algorithm:
>>
>>  n = element.page;
>>
>>  if (n == auto) then p = ancestor.page; /* and so forth until a non-auto
>> value, or the root element is found */
>>
>>  if (n != name-of-the-current-page) then {
>>     page-break();
>>     create-new-page(n);     name-of-the-current-page = n;
>>  }
>>
>> When a new page is created, all the rules set on that page --
>> including left, right and first -- must be applied.
>>
>> Does this make sense?
>>
>
> Yes, it makes sense. :) But it doesn't answer the question of
> how to deal with
>
>  <div style="page: foo"/>
>  <div style="page: foo"/>
>
> which currently don't trigger (n != name-of-the-current-page), vs.
> your example of
>
>  <div style="page: chapter"/>
>  <div style="page: chapter"/>
>
> which you you seem to want to trigger that condition.
>
> ~fantasai
>
>
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 - :first is defined as matching any page of that
name which is directly preceded by a page of a different 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.

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

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.

~TJ