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

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; 
  } 

In the past, GCPM defined "named page lists":

  http://www.w3.org/TR/2007/WD-css3-gcpm-20070504/#named3

which allowed this (and added for rules for how to ensure/avoid page breaks).

 > 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?

 > 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";
  }

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";
  }

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" }


 > (3) Allow for positioning like we (Apple) use in .ibooks. This is
 > basically just another kind of template.
 > 
 > @page :first { positioned-template: …; }
 > 
 > The positioning-template just names the slots and connects the
 > flows using a shorthand so you can say stuff like:
 > 
 > @page :first { positioned-template: body(col1, col2, col3); }
 > 
 > The above defines three positioned slots named col1, col2 and col3
 > (position:page would be implied for each slot)

(Isn't it cleaner to declare the name/sequence of slots and use normal
declarations to determine their positioning?)

 > a flow thread named
 > body (shorthand for explicitly saying each slot contains a segment
 > of the body flow thread).
 > 
 > We found the shorthand convenient as a way of avoiding having to
 > list a bunch of position:page and flow-into rules in the slot
 > pseudo-elements.
 > 
 > You can then refer to the slots by name in the same way as the ones
 > in the grid template, e.g.,
 > 
 > ::slot(col1) { … }

Ok, so a complete example would be:

  @page afirst {
     slots: foo(bar1, bar2);   /* defines the 'foo' sequence of slots */
     ::slot(bar1) {
       position: page;
       top: 0; right: 0;
       width: 10em; height: 10em;
     }
     ::slot(bar2) {
       position: page;
       bottom: 0; left: 0;
       width: 10em; height: 10em;
     }
  }
  
  article { page afirst arest }
  article p { flow-to: slots }

In this syntax there is no way to define that slots should be on
different pages. Say, slot "bar1" should be on named page "afirst" and
slot "bar2" should be on named page "arest". Hmm.

 > > 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 }


 > 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.

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Thursday, 23 February 2012 15:29:29 UTC