Re: [CSSWG] Minutes and Resolutions Paris F2F 2012-02-06 Monday Afternoon: Functional Notation, Values and Units, Regions Scope

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