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

Håkon said in http://lists.w3.org/Archives/Public/www-style/2008Sep/0107.html:
> 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...)

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

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.

Best wishes,

Melinda

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

Received on Friday, 12 September 2008 02:31:01 UTC