- From: Håkon Wium Lie <howcome@opera.com>
- Date: Sun, 13 Jul 2008 00:33:15 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: "www-style@w3.org" <www-style@w3.org>
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