RE: [page][gcpm] should a named page start on a new page?

Also sprach Grant, Melinda:

 > > Consider this markup:
 > >
 > >   <div>...</div>
 > >   <div>...</div>
 > >
 > > combined with this style sheet:
 > >
 > >    div { page: foo }
 > >    @page foo { ... }
 > >    @page foo:first { ... }
 > >
 > > Let's assume that a page break is not generated and that the
 > > second element starts on the page where the first element
 > > ends. If so, will that page be a :first page?
 > 
 > Maybe yes, maybe no... (depending on content and page area size, etc, etc...)

Right.

 > > If the anwser
 > > is yes, the formatter may have to go back and change the
 > > margins/headers/footers of a page that has already been
 > > (partially) laid out.
 > 
 > I don't see why... If it falls on the :first page generated for the
 > first div, the page already has been formatted with the desired
 > layout. What am I missing?

If the start of the second div falls on the :first page generated for
the first div, there is no problem. However, if the start of the
second div falls on any subsequent pages (defined by @page foo), a
problem occurs: does ther formatter have to go back and change the
layout of that page (defined by @page foo:first)?

 > > If not, :first doesn't live up to its promises.
 > 
 > I think that depends on how we define :first and what promises we
 > want it to live up to. Obviously the presence of a 'foo:first' page
 > context should cause elements with a 'page' property of 'foo' to
 > get 'foo:first' styling for the first of a sequence of 'foo' pages.
 > We could additionally say that whenever the scope for such an
 > element is opened (that is, an element with a 'page' property other
 > than 'auto' for which there exists a :first page context), a page
 > break is generated and :first styling applied to the ensuing page.
 > In our example above, that would imply that the second div would
 > necessarily be on a (new) :first page.
 > 
 > That would support our chapter/section use case nicely, but it
 > precludes using :first to style the first of a set of pages if you
 > *don't* want breaks between the elements when they already happen
 > to fall on a :first page. (Probably not a huge loss, but an
 > annoying consequence of overloading :first to control page
 > breaking.)

The solution is neat, but I don't like the overloading; the presence
of a pseudo-class style rule should not add page breaks. 

 > Adding 'page-group' with values of 'scoped', 'auto', and 'start' (as previously suggested in http://www.w3.org/2002/02/mid/763AE400FE923441B74861D534DF25494E4DDC9D26@GVW0433EXB.americas.hpqcorp.net;list=www-style) would I think provide the greatest flexibility along with a simple use model.
 > 
 > Use case 1:
 >         @page chapter { @top-center { content: "Header" }}
 >         @page chapter :first { @top-center { content: none }}
 >         div { page: chapter; page-group: scoped; }
 >         ...
 >         <div>Chapter 1</div>
 >         <div>Chapter 2</div>
 > 
 >         would put each div on its own chapter:first page.
 > 
 > Use case 2:
 > I'm not yet convinced any of our identified options can handle this cleanly (and still behave reasonably for other scenarios).  But we might consider adding a 'first' value to page-break-before and -after, which would cause :first styling for the 'page' property value in effect (if it exists) to be applied to the ensuing page:
 > 
 >         @page chapter { @top-center { content: "Header" }}
 >         @page chapter :first { @top-center { content: none }}
 >         h1 { page: chapter; page-group: start; page-break-before: first }
 >         ...
 >         <h1>The beginning, on a 'chapter:first' page</h1>
 >         <p>The content, continues on the 'chapter:first' page and subsequently a 'chapter' page.</p>
 >         <h1>The conclusion, on a new 'chapter:first' page</h1>
 >         <p>More content, same as prev p.</p>
 > 
 > 
 > Use case 3:
 >         @page rotated { size: landscape }
 >         table { page: rotated }
 >         ...
 >         <div>o blah dee</div>
 >         <table>...</table>
 >         <p>o blah dah</p>
 > 
 >         would generate breaks before and after the 'rotated' table page.
 > 
 > Use case 4:
 >         @page rotated { size: landscape }
 >         table { page: rotated }
 >         ...
 >         <div>stuff</div>
 >         <table>...</table>
 >         <table>...</table>
 >         <div>more stuff</div>
 > 
 >         would generate a break before and after the tables, and would put both of them on the same page if they fit.
 > 
 > Use case 4a:
 >         @page rotated { size: landscape }
 >         table { page: rotated; page-group: scoped }
 >         ...
 >         <div>stuff</div>
 >         <table>...</table>
 >         <table>...</table>
 >         <div>more stuff</div>
 > 
 >         would generate a break before *each* table, putting them on 'rotated' pages.
 > 
 > > I think adding a page break there is simpler, cleaner and I
 > > don't think it affects many pages.
 > 
 > I'd be happy with 'page-group'; ok with overloading :first to
 > always generate a page-break-before upon an open scope; but I don't
 > want to lose UC4 in order to enable UC1. I want it all. ;-)
 > 
 > Also I'm admittedly very resistant to changing the specification of
 > functionality that has been shipping for years and for which we
 > have interoperable implementations and test cases unless absolutely
 > necessary. I think we have other good options here.

I understand your resistance. I think there are two simpler option
that preserves the behavior from CSS2:

1) We can say that foo:first doens't create a page break, but if there
is an explicit page break there alsory, foo:first will apply. So, you
could say:

  @page chapter { ... }
  @page chapter:first { ... }
  div.chapter { page-break-before: always; page: foo }


2) We remove foo:first altogether and use page lists instead. For
example, instead of styling the first page of all chapters with:

   @page chapter { ... }
   @page chapter:first { ... }
   div.chapter { page: chapter }

you write:

   @page chapter { ... }
   @page chapter-first { ... }
   div.chapter { page: chapter-first chapter }

The page definitions could become longer since we're now defining two
independent pages, not just one subclass of another page.

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

Received on Friday, 12 September 2008 10:25:25 UTC