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

Re: [css3-page][css3-mediaqueries] Changing element styles on page breaks (was: Page size conflicts)

From: Brad Kemper <brad.kemper@gmail.com>
Date: Tue, 21 Feb 2012 00:00:33 -0800
Message-Id: <57C18690-32F5-4D12-93EA-7AEE5ADAF985@gmail.com>
Cc: "www-style@w3.org" <www-style@w3.org>
To: Simon Sapin <simon.sapin@kozea.fr>


Sent from my iPad

On Feb 20, 2012, at 6:10 PM, Simon Sapin <simon.sapin@kozea.fr> wrote:

> Le 21/02/2012 01:44, Simon Sapin a écrit :
>> I first thought this was a loophole due to unforeseen interactions
>> between the 'size' property and media queries. But if this is a feature
>> we want, the behavior need to be spec’ed much more precisely.
> 
> If styling elements differently on different pages is a feature, going through media queries to do it is quite contrived. I can already see authors doing this:
> 
>    @page { size: 210mm 297mm }
>    h1 { page: chapter-title }
>    /* I don’t really want to change the page size */
>    @page chapter-title { size: 209.99mm 297mm }
>    @media print and (width: 209.99mm) {
>        p { /* Style for text on first page of the chapter */ }
>    }
> 
> Why not go all the way and allow full element selectors in @page?
> 
>    @page { size: 210mm 297mm }
>    h1 { page: chapter-title }
>    @page chapter-title {
>        p { /* Style for text on first page of the chapter */ }
>    }

Yes, this is precisely what was in mug head that I only recently realized wasn't in the spec.

> The semantics would be similar to regions, but there is a syntax problem to disambiguate @page properties and type selectors.
> 
> This is a big feature, and I wouldn’t want it to delay what is already in css3-page (especially margin boxes.) So how about this keeping full selectors for level 4?

I don't see how it could be bolted on later without at least making allowances for it now. I don't think you could have 'a:link' (an element and a pseudo-class) in the same place where you could have 'color:green' (a property and value). I think the way to disambiguate would be to not have properties directly within @page, but rather have a selector to set the page box. I think :root could work, but if that is problematic, then maybe just ':page'.

Also, I share Håkon's feeling that regions should not proceed too far without giving more thought to  how they can be used without requiring markup for each region box (ie, I'd say generate pseudo-elements that could be regions instead). Similarly, I think regions, pages, page masters, overflow:paged, and columns all need to be considered together, in terms of how they can and should affect each other, and how consistent they are, or could/should be, at solving the same sort of problems. It doesn't seem right for regions to be fast tracked possibly ahead of pages with the ability to style individual region content differently without giving a similar ability to pages. There is certainly use cases for that power to be in pages. In fact, the purpose of regions is to be able to do magazine-like layouts. Magazine layouts are very much layouts of multiple pages. How can we consider linking regions without considering how to link them from one page to the next with different page designs? That should really be something that css3-page is ready for. I'd rather that happen now than later. 

Adding selectors inside @page is not that much more to consider. It should be no worse than @region, or of selecting descendants of :first-line. My @slot goes further, but it is not much more than what we have with ::before and ::after, or with margin boxes, except to have an arbitrary number of them per paged page, and let them use 'flow-from'. 

> In that case, I’m not sure how should level 3 behave for "changing" media queries...

Yeah... I'll try to express my thoughts on that in a separate post. Have to sleep first.
Received on Tuesday, 21 February 2012 08:01:06 GMT

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