W3C home > Mailing lists > Public > www-style@w3.org > February 2012

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

From: David Hyatt <hyatt@apple.com>
Date: Wed, 22 Feb 2012 15:56:07 -0600
Cc: Brad Kemper <brad.kemper@gmail.com>, "www-style@w3.org Style" <www-style@w3.org>
Message-id: <887172E1-FD75-4AD9-B855-8D50FAA6F858@apple.com>
To: Håkon Wium Lie <howcome@opera.com>
On Feb 22, 2012, at 6: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 }
> 
> 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.

> 
>>>> 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 }
>  }
> 
> But that gets a little messy when we mix in declarations:
> 
>  @page :first {
>    columns: 3;
>    h1 { color: red }
>  }
> 
> Any ambiguities?
> 
> Or, perhaps:
> 
>  @page :first h1 {
>    color: red
>  }
> 

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.

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

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 }

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

I would expect this to just stay in sync with the grid template stuff in CSS3 Grid Layout, and just be applicable to a page.

(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), 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) {  … }

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

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

dave
(hyatt@apple.com)
Received on Wednesday, 22 February 2012 21:56:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:51 GMT