- From: David Hyatt <hyatt@apple.com>
- Date: Wed, 22 Feb 2012 15:56:07 -0600
- To: Håkon Wium Lie <howcome@opera.com>
- Cc: Brad Kemper <brad.kemper@gmail.com>, "www-style@w3.org Style" <www-style@w3.org>
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 UTC