- 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