W3C home > Mailing lists > Public > www-style@w3.org > September 2008

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

From: Grant, Melinda <melinda.grant@hp.com>
Date: Fri, 12 Sep 2008 02:28:52 +0000
To: Håkon Wium Lie <howcome@opera.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <763AE400FE923441B74861D534DF254950F9FAD786@GVW0433EXB.americas.hpqcorp.net>


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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:12 GMT