- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Fri, 17 Feb 2012 15:45:54 -0800
- To: Vincent Hardy <vhardy@adobe.com>, www-style list <www-style@w3.org>
- Message-Id: <4DC49BFA-2AF1-46EB-9A36-A40E554BAFB3@gmail.com>
Resending with proper subject line in new thread. On Feb 15, 2012, at 6:51 PM, Vincent Hardy <vhardy@adobe.com> wrote: > Hello, > > There were two presentations shown during the section on regions: > > - Scope of CSS regions as understood by the editors: http://lists.w3.org/Archives/Public/www-archive/2012Feb/att-0014/CSS_Regions_101_1_.pdf > > - Presentation on page templates requirements: http://vhardy.github.com/presentations/page-template-presentation/index.html#/ > > Kind regards, > Vincent. Thanks for that. The second one with ideas for using a combination of @page and overflow:paged closely matches the loose ideas I had rattling around in my own head. The overflow:paged part would generate new pages that could each have templates defined inside the @page. I think besides having '@page :nth(n)', etc. to define different templates, you could use '@page <identifier>' to define custom page layouts. So, for instance: @page chapter-start-page { <template definition> } h1 { page-break-before: always; page: chapter-start-page; } I think this could be potentially more desirable than '@page conditional', but I'm not sure I understand that fully. It seems like it is approaching the problem from the opposite direction. > howcome: Look at this example (the canon regions example). > howcome: If the screen gets wider, you can't add another column to the right. > Rossen: This is what page templates are going toward. > howcome: But we haven't seen them! We can't evaluate a non-existing spec. > howcome: Right now we have multiple plans, and I think we should talk > about just the declarative stuff right now. > florian: The problem I see is that we're introducing various pieces that > are meant to be combined, but we're not considering them together. > florian: As long as we discuss them separately, we aren't dealing with it. > alexmog: We know we disagree somewhat. Can we move past that? > howcome: We could if we agreed on the declarative approach. > howcome: How does the content get onto the next page? > alexmog: How it gets onto the next page is the next thing we need to write. > florian: That's what we can't accept! How's this: Suppose I have a container element, with a couple flows of content in it. I use something like '@slot' pseudo-elements to generate several regions absolutely positioned (or gridded) in this container. The last slots for each flow are height-constrained because the main container is height constrained (abs pos to the viewport height, let's say). But that container has 'overflow: paged', and the unseen flow content from the last slots is enough to generate new pages in the container. Why? Because the UA knows that there are @pages designed to receive flow from this container's slots. Something like this: HTML, body { height:100%; margin:0; } body { overflow: paged; @page { @slot(1) { flow-from: article-flow; ... } @slot(2) { flow-from: sidebar-flow; ... } } @page chapter-start-page { @slot(1) { flow-from: article-flow; ... } } } article { flow-into: article-flow; } aside { flow-into: sidebar-flow; } article h1 { page-break-before: always; page: chapter-start-page; } The slots could be absolutely positioned, or put into a grid, using properties in @page and each @slot. In this example, if an H1 caused page 2 to use the chapter-start-page @page template, which had no slot 2, then the sidebar-flow would continue on page 3, regardless of whether or not there was anymore article-flow. I'm not sure if this is how others imagined things working, but I like it. I could also imagine and overflow-style that drew the pages along side each other or one under the other, so that they could all be seen at the same time by scrolling the parent (for a slightly less overt, less interactive paging). > sylvaing: without dom elements, you can't receive clicks, etc. That seems like a solvable problem that should be solved for all generated pseudo-elements (like ::before and ::after too). Something like 'getElementsByTagName("body")[0].pseudos.slot[0]'.addEventListener(click, myfunction)'.
Received on Friday, 17 February 2012 23:46:33 UTC