RE: thoughts on page templates

Created a wiki page: http://wiki.csswg.org/spec/css3-region-templates 

Will respond to your notes next.

Alex

-----Original Message-----
From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] 
Sent: Wednesday, November 09, 2011 3:27 PM
To: Alex Mogilevsky
Cc: www-style@w3.org list
Subject: Re: thoughts on page templates

On Sat, Nov 5, 2011 at 10:42 AM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> 1.       Element-per-region
>
> Peter’s template design [1] relies on region functionality where a 
> region consumes exactly one element from flow. This is close to what 
> would have happen if there was a forced break after each element, but 
> region auto sizing doesn’t work that way now.

I've looked over the document, but I'm not sure I understand why this functionality is required.  Can you give an example?


>      region-type: page | column | box | slot | frame | auto
>      (initial: auto)
>
> Region types have this meaning:
>
>                 page – paginate the flow (“region-overflow:break”); 
> “break-*:page” treats region as a page
>
>                 column – same as page, but “break-*:column” moves to 
> next region and content can be balanced (TBD how to tell which columns 
> are on same page)
>
>                 box – consuming one element at a time from the flow. 
> No pagination, layout works as if the element from flow was the only 
> child of the region
>
>                 slot – same as ‘box’ but the element from flow 
> replaces the region. Useful for incompatible containers (e.g. region 
> is <p> and element is <div>). TBD how region and content properties are merged.
>
>                 frame – consume all of the flow content, layout as if 
> it was actual content
>
>                 auto – page (if content doesn’t fit) or frame (if it 
> does) – as defined currently for “region-overflow:auto”

This is pretty interesting.  It avoids us having to define a third model for how breaks happen, and instead rely on the existing paged and multicol break models.

'box' and 'slot' should not be distinct values.  This should instead be controlled through a property on the region container itself that removes it from the box tree while keeping its children in.


> 1.1. ‘flow-into’: element vs. content
>
> The issue of nested containers in regions (“region-type:box” vs.
> “region-type:slot”) can also be addressed by named flow source element 
> sending its content to the flow, e.g. like this:

I like the idea of having a display value that takes the element out of the box tree but leaves its children.  This was previous suggested by me (and maybe others? I forget now) as "display: transparent".

> And of course this is a way to solve the problem of <iframe> special
> behavior:
>
>
>
>      <iframe style=”flow-into:article; ”> -- iframe is named flow
>
>      <iframe style=”flow-into:article; display:content”> -- iframe 
> content is named flow
>
>      <iframe style=”display:content”> -- similar to “seamless” iframe, 
> but not transparent for dom and styles.

These don't work - iframes have no children as far as CSS is concerned.  If they do, this would show their DOM children, not the referenced page.


> Effect on replaced elements is undefined, but at least should reset 
> any non-default properties.

I don't understand what this means.


> 2.       Template from named flow
>
> This should work without any new features:
>
> <div style=”flow-into:template”>
>      <div style=”flow-from:header; region-type:frame;”></div>
>      <div style=”flow-from:page; region-type:page;”></div>
>      <div style=”flow-from:footer; region-type:frame;”></div> </div>

Could you provide an example of what you're trying to accomplish with this?


> 3.       Page view with generated pages
>
> There may be many ways to generate pages from templates, but the 
> outcome is reasonable to expect to be something like this:
>
> <div id=”page-view”>
>      <!-- custom UI for page fiew -->
>      <div id=”page-container”>
>            <!-- generated pages, may or may not be in DOM -->
>            <div id=”page1”></div>
>            <div id=”page2”></div>
>            ...
>            <div id=”pageN”></div>
>      </div>
> </div>
>
> 3.1. GC option – pages as generated content
[snip]
> 3.2. Script option – pages in DOM
[snip]

I don't understand what any of this is supposed to do.  ;_;  Can you give a more detailed explanation?  Are you using the word "pages" to refer to something other than the auto-generated things that happen when you used paged media?


> 6.       Wiki?
>
> There is  a lot of options in all of the above. If any of the above 
> sounds promising I can put it on wiki and see if it can evolve into 
> something implementable.

I definitely suggest doing this, so things can be expanded and refined in-place.  ^_^

~TJ

Received on Saturday, 10 December 2011 02:46:28 UTC