Re: [css3-page][css3-mediaqueries] Changing element styles on page breaks

On Feb 21, 2012, at 1:02 AM, Simon Sapin <simon.sapin@kozea.fr> wrote:

> Le 21/02/2012 09:00, Brad Kemper a écrit :
>>> 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'.
> 
> Margin boxes were added just fine in the middle of @page. We can add anything at any time, as long as it does not start with an IDENT token (that would be a property name) or one of the 16 at-keywords for margin boxes.
> 
> Of course selectors can start with an IDENT so some kind of marker would be needed. But that can happen at any time.

My point is that I think the way @region uses selectors is a lot more sane that having to add an @select-elements or something. And that as similar as regions and pages are, I would like to see them select items within them in more or less the same way. 

>> 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.
> 
> I understand that these should be considered together but I don’t know how stable/ready the whole thing.

Now is the time to at least plan how they will all interact, as css3-pages matures, css3-regions starts to stabilize and get experimental implementations, and we start getting serious about on-screen paged views and about some sort of way of templating pages. 

> The current css3-page on the other hand adds margin boxes and page counters. These have been a WD for a long time and have many (at least partial) implementations. Here are a few:
> 
> http://weasyprint.org/#sample-output (this one is mine)
> http://www.princexml.com/doc/5.1/page-headers-footers/
> http://www.tufat.com/docs/html2ps/compatibility.css.3.html
> http://www.antennahouse.com/CSSInfo/css_reference.html#css-property-conf-rule
> http://www.realobjects.com/products/pdfreactor/demos-docs/sample-documents/page-layout-samples/
> http://flyingsaucerproject.github.com/flyingsaucer/r8/guide/users-guide-R8.html#xil_40
> http://blog.tallcomponents.com/2011/03/css3-page-counter.html
> 
> I’m sure more careful googling can turn up more. Though not remotely as much as web browsers and not in the same contexts, these implementations *are* in use. Almost all of them have unprefixed WD features.

It seems as though you are telling me this because maybe you believe that I might want to change or do away with margin boxes and page counters. But I don't. If styling the page box meant typing ':page { color:green; }' instead of just 'color:green;' by itself, it need not have an effect on the way margin boxes inherit. Counter-increment could likewise go inside ruleset braces  with a ':page' selector, without any adverse effect.

> The spec needs polish in corner cases (and probably a new algorithm for Margin Boxes Variable Dimension, but that’s another story) but I think it is relatively stable.

That's good. But it is not LC or CR yet, so it can still be changed. I would rather slow it down just a little to bring in line with this capability of regions to style elements with each selected page (selectable region-like container), or at least prepare it for that to come. Even if full-on per-page selecting of elements had to wait for a css4 version, at least wrapping the property declarations in curly braces with a :page selector before them would help future-proof it for adding in a fuller selector-based rules feature later, without later requiring another @rule to enable that feature.

>> 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.
> 
> Choosing a marker to disambiguate the syntax can be pretty quick, but spec’ing precisely how the cascade and layout work is another story. But again I don’t know stable ready it is in the Regions spec.

Regions seems to be moving along at a pretty good clip. 

It just seems crazy to me that @page doesn't already have this! It seems like such an obvious thing, and such a huge win for easily creating page templates.

>  I think that selectors3 do not allow selecting descendants of :first-line (Pseudo-elements are only allowed at the end of a selector.)

Doh. I always forget that weird restriction.

> Is that in selectors4?

Don't know. I hope the restriction gets removed. I don't understand why it needs to be limited that way. If I can set a separate color to the first line of a span of text, why can't I also set a separate color to a the part of an inner span within the 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'.
> 
> This sounds interesting, but please let margin boxes progress without attaching new features to the same spec. Do that in level 4 or in another module like GCPM does.

Hmm.