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

On Sat, Jul 12, 2008 at 5:33 PM, Håkon Wium Lie <howcome@opera.com> wrote:

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


Good, that makes sense then.  It does feel slightly weird (auto elements may
or may not merge into named page groups depending on their nearest named
ancestor), but it's a logical parsing and works out simply in practice.


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


Makes sense.  I just wanted to be explicit here.


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

With the current state of the proposed spec, I'm thinking that we can avoid
using the Prince solution and just rely on the implicit construction of page
groups as we did before.  The only reason to retain Prince's explicit
grouping would be if page-name-groups are ever expected to be useful for
anything other than implicit page breaks (their current only use).  Any
thoughts on that?  Otherwise, I'm happy with it.

~TJ