W3C home > Mailing lists > Public > www-style@w3.org > June 2012

Re: [css3-page][css3-background] Canvas background painting and positioning area

From: Peter Moulder <peter.moulder@monash.edu>
Date: Wed, 13 Jun 2012 12:59:39 +1000
To: www-style@w3.org
Message-id: <20120613025939.GB470@bowman.infotech.monash.edu.au>
On Mon, Jun 11, 2012 at 01:06:14PM -0700, fantasai wrote:

> Ok, so the current spec says the painting order is:
> 
>   0. Page Background (entire page, including page margins)
>   1. Page Border
>   2. Margin Boxes
>   3. Document Canvas
>   4. Document Content
> 
> Note: z-index can be used to change the relative position of the margin
> boxes and the document.
> 
> How about we change the spec to say:
> 
>   0. Page Background
>   1. Document Canvas
>   2. Page Border
>   3. Document Content
>   4. Margin Boxes

I don't often use stacking contexts for their layering effects, so I can't
evaluate the proposal overall, but here are some comments on some aspects of
the proposed change.

Regarding the relative ordering of document content and page-margin-boxes:
I thought that it was quite deliberate and reasonable for document content to
be drawn over the top of page-margin-boxes, on the grounds that it's probably
more important to read the main document content than to read the page number,
page heading, associated borders etc.

One response might be to move page-margin-boxes to between 0 and 1.  However,
it seems reasonable for page-margin-boxes to be on top of the page border by
default, to allow a page-margin-box to have an opaque background and a border
similar to the page border, to give an interesting stylistic effect.  (I think
I've seen this style used, in paper rather than digitial documents at least.)

Having document canvas be above page border & page-margin-boxes in the original
model did seem a bit surprising on first reading, though I thought it might be
a bit more convenient from an implementation perspective to have document
canvas and content adjacent to each other in z order, and (relatedly) maybe
it had advantages in compatibility with existing implementations.

pjrm.
Received on Wednesday, 13 June 2012 03:00:07 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:55 GMT