- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Wed, 22 Feb 2012 08:41:47 -0800
- To: Håkon Wium Lie <howcome@opera.com>
- Cc: David Hyatt <hyatt@apple.com>, "www-style@w3.org Style" <www-style@w3.org>
On Feb 22, 2012, at 4: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 } Yes, that would be the most basic conservative approach to changing the current css3-page spec. > Another approach is to center around elements: > > body::first-page { columns: 3 } > body { columns: 2 } That could work too, but I think that named pages would be important. So if we took this approach, I think we would also need: @page my-chapter-page { ... } body::named-page(my-chapter-page) { columns:3; } This approach might be the least disruptive, but feels redundant to me. I'd rather define the rules within the @page rule I created, which already has name or pseudo-class. Less misdirection. >>>> 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 } > } Yes, this is what I had in mind. For h1, I personally prefer this pattern: h1 { page-break-before: always; page: chapter-start-page; color:red; column-span: all; background: /* etc. */ } Then other elements on that page: @page chapter-start-page { p { font-size: 16px } body { columns: 2 } } > But that gets a little messy when we mix in declarations: > > @page :first { > columns: 3; > h1 { color: red } > } Right. That is why I was thinking that the bare declarations would not be allowed, but would use a selector like ':page'. I was originally thinking ':root', but I couldn't remember if the root existed on each page. But body should work just as well, I think, if we say that margin boxes inherit from body (which I think they probably should anyway, to pick up font properties, etc. that many authors put on Body). > Any ambiguities? > > Or, perhaps: > > @page :first h1 { > color: red > } I hadn't considered that. It is less encapsulated than putting the selector insdide though, and I'd have to write '@page <name or pseudo-class>' a lot more times. So I like this version less. >>>> 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? Where I announce I've added to the wiki and include the link (which I haven't further updated since, but should): http://lists.w3.org/Archives/Public/www-style/2012Feb/0966.html After I realized the spec didn't mean to actually include some of this already: http://lists.w3.org/Archives/Public/www-style/2012Feb/1031.html http://lists.w3.org/Archives/Public/www-style/2012Feb/1033.html > >>>> 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 } More or less. I was thinking of the existing @page :first and a named page or @page:right for the third, but I like the page number idea somewhat too. The way you combine the flow name and the @slot identifier is very nice. I like it. Some slots could be flow-less, and just have generated content in them. In that case, the slot name is just there so that if you write the @slot rule twice it will cascade correctly. >>>> Anything that didn't fit in a slot because of page size or other >>>> constraints would automatically go to the next available page >>>> with the same 'flow-from'. > >>> Yeah, we are definitely on the same page here. (Haha.) I would >>> like to see column rules applicable to @page as well as the >>> ability to define a set of slots for the page that can then be >>> regions. The placement of the slots should be achievable with >>> grid layout, floating or positioning. > > Here's a floated sushi: > > @page 1, 3 { > @slot sushi { > float: right; > width: 10em; > height: 100%; > } > } Cool, except that I generally hate using traditional floats for layout. Your page float idea is what I was thinking would still work here. > > Grid, anyone? I'll leave that to others more familiar with grid, or who have more time than me right now, but it looked like it would work. >> Exactly my thinking. Cool. >> >>>> Combine all that with overflow:paged by making the pages it >>>> generates obey css3-page, and you've got a complete solution. > > Obey, in what way? Treat the pages generated by the overflow as full fledged pages that css3-page applies to in every way. Use scroll bars if it creates a page larger than the container. You should see this in the wiki when you take a look.
Received on Wednesday, 22 February 2012 16:42:23 UTC