Re: [css3-regions][css3-gcpm] Thoughts on Plan A and Plan B

On Feb 22, 2012, at 4:37 AM, Håkon Wium Lie wrote:

> Brad Kemper (and David Hyatt in between) wrote:
> 
>>>> I completely agree with this approach. In my view, we almost
>>>> have page masters right now, with @page and its related @rules,
>>>> except that they are only masters for margin boxes and size, and
>>>> not the main content area. 
> 
> Yes. 
> 
>>>> If we added column-related properties
>>>> to the properties that could be used directly with @page, then
>>>> the simple case of having different column numbers, width, etc.
>>>> per named page (or pseudo-class selected page) would immediately
>>>> be available. 
> 
> Yes. Like this, perhaps?
> 
>  @page :first { columns: 3 }
>  @page { columns: 2 }

Yes, that would be the most basic conservative approach to changing the current css3-page spec.

> Another approach is to center around elements:
> 
>  body::first-page { columns: 3 }
>  body { columns: 2 }

That could work too, but I think that named pages would be important. So if we took this approach, I think we would also need:

@page my-chapter-page { ... }
body::named-page(my-chapter-page) { columns:3; }

This approach might be the least disruptive, but feels redundant to me. I'd rather define the rules within the @page rule I created, which already has name or pseudo-class. Less misdirection.

>>>> If we add to that being able to right rule sets
>>>> with selectors within @page (like you can within @region), then
>>>> you would be able to change fonts, colors, widths, etc. of any
>>>> element based on what page it was in. 
> 
> Let's see. We could do:
> 
>  @page :first {
>    h1 { color: red }
>  }

Yes, this is what I had in mind. For h1, I personally prefer this pattern:

h1 { 
    page-break-before: always; 
    page: chapter-start-page; 
    color:red; 
    column-span: all;
    background: /* etc. */
}

Then other elements on that page:

@page chapter-start-page {
   p { font-size: 16px }
   body { columns: 2 }
 }

> But that gets a little messy when we mix in declarations:
> 
>  @page :first {
>    columns: 3;
>    h1 { color: red }
>  }

Right. That is why I was thinking that the bare declarations would not be allowed, but would use a selector like ':page'. I was originally thinking ':root', but I couldn't remember if the root existed on each page. But body should work just as well, I think, if we say that margin boxes inherit from body (which I think they probably should anyway, to pick up font properties, etc. that many authors put on Body).


> Any ambiguities?
> 
> Or, perhaps:
> 
>  @page :first h1 {
>    color: red
>  }

I hadn't considered that. It is less encapsulated than putting the selector insdide though, and I'd have to write '@page <name or pseudo-class>' a lot more times. So I like this version less.

>>>> If you go one step
>>>> further, and add the ability to create an arbitrary number of
>>>> pseudo-elements per page, then you could use 'content' with them
>>>> to put decorations wherever you want on whatever pages you want,
>>>> not just in the margins. I have proposed '@slot()' for this.
> 
> Do you have a pointer to your proposal?

Where I announce I've added to the wiki and include the link (which I haven't further updated since, but should):

http://lists.w3.org/Archives/Public/www-style/2012Feb/0966.html

After I realized the spec didn't mean to actually include some of this already:

http://lists.w3.org/Archives/Public/www-style/2012Feb/1031.html
http://lists.w3.org/Archives/Public/www-style/2012Feb/1033.html

> 
>>>> combining this with regions, and you could have content flow
>>>> from region to region, page to page. You could have your sushi
>>>> column in your example work, by flowing it into a slot that is
>>>> on the title page and the third page, but not the second.
> 
> Perhaps like this?:
> 
> @page 1, 3 {
>  @slot sushi {
>     position: absolute;
>     top: 0;
>     bottom: 0;
>     right: 0;
>     width: 10em;
>  }
> }
> 
> aside { flowto: sushi }

More or less. I was thinking of the existing @page :first and a named page or @page:right for the third, but I like the page number idea somewhat too. 

The way you combine the flow name and the @slot identifier is very nice. I like it.

Some slots could be flow-less, and just have generated content in them. In that case, the slot name is just there so that if you write the @slot rule twice it will cascade correctly.

>>>> Anything that didn't fit in a slot because of page size or other
>>>> constraints would automatically go to the next available page
>>>> with the same 'flow-from'.
> 
>>> Yeah, we are definitely on the same page here. (Haha.) I would
>>> like to see column rules applicable to @page as well as the
>>> ability to define a set of slots for the page that can then be
>>> regions. The placement of the slots should be achievable with
>>> grid layout, floating or positioning.
> 
> Here's a floated sushi:
> 
> @page 1, 3 {
>  @slot sushi {
>     float: right; 
>     width: 10em;
>     height: 100%;
>  }
> }

Cool, except that I generally hate using traditional floats for layout. Your page float idea is what I was thinking would still work here.

> 
> Grid, anyone?

I'll leave that to others more familiar with grid, or who have more time than me right now, but it looked like it would work.

>> Exactly my thinking. Cool. 
>> 
>>>> Combine all that with overflow:paged by making the pages it
>>>> generates obey css3-page, and you've got a complete solution.
> 
> Obey, in what way?

Treat the pages generated by the overflow as full fledged pages that css3-page applies to in every way. Use scroll bars if it creates a page larger than the container. You should see this in the wiki when you take a look.

Received on Wednesday, 22 February 2012 16:42:23 UTC