W3C home > Mailing lists > Public > www-style@w3.org > November 2011

Re: thoughts on page templates

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 9 Nov 2011 15:27:20 -0800
Message-ID: <CAAWBYDCPY_i=HFN0Bhh9244eYMpsvX-ayG-gxguc2Xmwq+3odg@mail.gmail.com>
To: Alex Mogilevsky <alexmog@microsoft.com>
Cc: "www-style@w3.org list" <www-style@w3.org>
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
> 3.2. Script option – pages in DOM

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.  ^_^

Received on Wednesday, 9 November 2011 23:28:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:52 UTC