Re: [css3-page][css3-mediaqueries] Page size conflicts

On Feb 20, 2012, at 4:44 PM, Simon Sapin wrote:

>>> But note that both Regions and Selectors (for ::first-line and
>>> ::first-letter) defined a limited set of properties that can be
>>> used in such contexts.
>> 
>> So does css3-page.
> 
> It does for the page context and the page margin context. I was talking about properties in "normal" rulesets (on elements) inside media queries that vary across pages. (We really need a name for that.)
> But for property that should not change across pages, maybe we can just keep the value of the first fragment, as you suggested below for floats.
> 
> 
>>> For example, it would not make sense for fragments of the same
>>> element to have different values for the 'display' property.
>>> 
>>> While it would be technically possible to have the same kind of
>>> behavior for page breaks (different style across pages like above)
>>> I think it is a bad idea.
>> 
>> It is a core feature of @page and that entire spec. You can have
>> different styles (within limits) for the first page, left page, right
>> page, and arbitrary named pages, than what you have in general for
>> all other pages.
> 
> Within limits. As I understood them, the limits were that anything inside @page could change but not the elements on the page. I spent quite some time on css3-page but it never occurred to me that the page content (elements) could be styled differently. The spec does not mention it.

Ah, well, it looks like my mind did take it further than the spec does, in a way that seemed natural to me.

The spec has declarations that can be put directly into the @page block, which affect the page box. The first such property mentioned in the spec other than margin is in example 8, where 'color: green' is declared for '@page :first'. Example 9 has 'font-size: 14pt'. Both of these are inheritable properties that I assumed would style regular elements that are within that page, if the elements did not have a higher specificity. I see now that the authors of this spec probably only intended the content-affecting properties (color, font properties, etc.) directly within @page were to affect the other @rules within them, but that wasn't part of my preconception, so I didn't preciously consider that.

In regions, there is @region, which exists to contain selectors for styling elements within individual regions. I started becoming more interested in @page after becoming interested in regions, so I suppose that colored my expectations. Still, pages and regions are very similar, and if regions can do that, why not @page? I would really like to see that added to @page (selectors within the @page rule). It just seems like a huge lost opportunity for a really useful power, otherwise. They could follow the same pattern as with @region. You would have to use something else to select the page itself (I'm thinking :root), so as to avoid confusion between selectors and properties. Not only would this bring us closer to my vision of how page masters should work (see my other e-mail involving @slot, and the wiki about overflow:paged), but it would help make regions and pages more consistent. Although, I suppose if we did have @slot accepting a region flow, then that would be enough, as you could then just size one @slot to be full page and then use @region to style it. I just thought it would be a little more simple and direct to be able to put selector rules directly inside @page if you didn't need multiple regions or multiple page divisions.

The idea behind @slot, is that you wouldn't have just the 16 margin boxes to style differently per page and differentiate different page designs, but could also have an arbitrary number of pseudo-elements within the page area to style differently per page, to even further differentiate each page, and that they could accept region flows.

Received on Tuesday, 21 February 2012 06:51:51 UTC