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

On Feb 23, 2012, at 7:28 AM, Håkon Wium Lie <howcome@opera.com> wrote:

> David Hyatt wrote:
> 
>>> Yes. Like this, perhaps?
>>> 
>>> @page :first { columns: 3 }
>>> @page { columns: 2 }
>>> 
>>> Another approach is to center around elements:
>>> 
>>> body::first-page { columns: 3 }
>>> body { columns: 2 }
>> 
>> I would favor an approach that centers around the pages and not the
>> elements. If you look at typical magazine layouts, what you see is
>> a set of page designs for articles. On the order of 8-10 unique
>> page templates are used in the Economist iPad app for example. I
>> think that's a more intuitive way to think about the design of
>> magazine articles, i.e., what template you're using on each page.
> 
> I see your point. It adds one level of indirection, but may be worth
> it. And we already have the concept of named pages. One requirement I
> have is that elements can dictate what kind of pages it should be laid
> out onto. Say, if you have several articles in a magazine:
> 
>  <article>...</article>
>  <article>...</article>
>  <article>...</article>
> 
> Each article must be able to say that its first page should be of type
> x and that it should continue on type y. For example:
> 
>  @page afirst { columns: 3 }
>  @page arest { columns: 2 }
> 
>  article { 
>    page: afirst arest; 
>  } 

You could write that as this:

@page article-pages:first { columns: 3 }
@page article-pages { columns: 2 }

 article { 
   page: article-pages; 
 }  

That is, the first page of each consecutive 'article-pages' page would have 3 columns.  However, it seems better here to only select the element based on where it starts (and if it floats where it starts, then the floating continues to all pages it touches, btw). So if there was only one article, and it matched the :first class, then it would only match the :first class page, not the other pages. But you would still get what you want with this:

@page article-pages:first { columns: 3 }
@page article-pages { columns: 2 }

 article, article > *  { 
   page: article-pages; 
 }  


>> I would favor a double nested approach, but I'm flexible. If we
>> think it's ok to just have them not be nested I guess that's fine
>> also. Nesting would look something like this though:
>> 
>> @page :first {
>>    columns: 3
>> 
>>    @in-region {
>>        h1 { color: red }
>>    
>>        /* Slot rules could be in here too. */
>>        ::slot(1) { … }
>>    }
>> }
>> 
>> I like the idea of just using the same primitive for styling stuff
>> that occurs on the page as the one we use for regions… hence
>> something like @region or @in-region inside the @page rule would be
>> my preference.
> 
> I don't understand what @in-region does in your example. It defines a
> region? Isn't that what ::slot does, too? I thought slot/regions were
> comparable?

I think so too. I suppose maybe David was thinking of slots inheriting from @in-region, but I think they should just inherit from @page. 

Actually, I was thinking that if you wanted to preserve the way there are bare declaration blocks in @page, but still be able to write selectors for what appears on that page, you could do so inside a single @slot. I'd say, with a single un-named slot,  it doesn't actually need a 'flow-from' to receive general non-region flow, and it would take up the whole page area without setting position or grid or anything. 

Having more than one @slot might be problematic if they weren't positioned or gridded. Maybe that should not be allowed for named slots. 

>> My own proposal would be for the following:
>> 
>> (1) Allow column properties to work as you have already described, e.g.,
>> 
>> @page :first { columns: 2 }
> 
> Right.
> 
>> (2) Allow the grid-template property to work, so that you can just say:
>> 
>> @page :first { grid-template: ….; }
>> 
>> This would allow for the definition of a grid layout of slots. Then
>> you'd address the slots inside the region styling (as I listed
>> above). I think defining a grid-template would supersede any
>> columns rules obviously.
> 
> Let's see. Here's a named page with 'grid-template':
> 
> @page afirst {
>   grid-template: "ta"
>                  "sa"
>                  "bb"
>                  "cc";
> }
> 
> How would this be used? Say we have:
> 
>  h1 {
>     grid-cell: "t";
>  }

I was thinking more along the lines of this:

@slot(article-flow) {
    grid-cell: "t";
}

> Would the H1 element somehow request the page "afirst" to be used?
> Or
> would this have to be called out specifically:
> 
>  h1 {
>     page: afirst; 
>     grid-cell: "t";
>  }

That should also work, in my view. 

> Or, would we simply say that: if the element ends up on a page with a
> grid cell that happens to match, the elemen goes there. Otherwise it
> goes into it natural position. Then we could do:
> 
>  article { page: afirst }
>  article h1 { grid-cell: "t" }

This seems reasonable. 

>>> Perhaps like this?:
>>> 
>>> @page 1, 3 {
>>> @slot sushi {
>>>    position: absolute;
>>>    top: 0;
>>>    bottom: 0;
>>>    right: 0;
>>>    width: 10em;
>>> }
>>> }
>>> 
>>> aside { flowto: sushi }
>> 
>> Yeah or you create a named page master with the slot rules and then
>> somehow identify pages 1 and 3 as pointing to that template.
> 
> Perhaps:
> 
>  @page fishy {
>     @slot sushi; 
>        position: absolute;
>        top: 0; bottom: 0;
>        right: 0; width: 10em;
>     }
>  }
>  @page meaty { ... }
> 
>  article { page: fishy meaty fishy }
>  aside { flowto: sushi }

Or this:

 @page fishy {
    @slot(sushi) {
       position: absolute;
       top: 0; bottom: 0;
       right: 0; width: 10em;
    }
    @slot() article { margin-right: 11em; }
 }
 @page { ... }
 aside { flowto: sushi }

The article would flow into the unnamed page normally. The fishy page has an unnamed slot, so the article would also flow into that. '@slot() article' selects that article in that general use slot, with declarations giving it some margin to make room for the sushi sidebar. 

>> I think it's an open question of whether @page should act as the
>> template definition or if we want page templates to be something
>> different, e.g., @page-template.
> 
> Yes. One reason for using @page is that we avoing having to describe
> how @page and @page-template interact.

Agreed. So far, I don't see a need for a separate @page-template. If you want your overflow: paged pages to have a separate template than the page they are on, just assign them a different named @page, via the 'page' property.