Re: [css3-regions] Comments on Editor's Draft

On 8/3/11 2:17 AM, "Alex Mogilevsky" <alexmog@microsoft.com> wrote:

>± From: Anton Prowse [mailto:prowse@moonhenge.net]
>± Sent: Saturday, July 23, 2011 2:42 PM
>± To: www-style@w3.org
>± Cc: Alex Mogilevsky; Vincent Hardy
>± Subject: Re: [css3-regions] Comments on Editor's Draft
>± 
>± On 20/07/2011 15:50, Alex Mogilevsky wrote:
>± > On 13/07/2011 15:51, Vincent Hardy wrote:
>± >> On 12/07/2011 11:45, Alex Mogilevsky wrote:
>± >>> On 11/07/2011 20:46, Vincent Hardy wrote:
>± >>>> On 6 Jul 2011 13:00:19 -0700 Anton Prowse wrote:
>± >>>>> Note that the definition doesn't rule out the multicol element
>± >>>>> itself (assuming the wider definition of container); presumably if
>± >>>>> the multicol element is itself a region then any flow associated
>± >>>>> to it fills all columns and cannot be managed on a
>± >>>>> column-by-column basis.
>± >>>>
>± >>>> Yes.
>± >>>
>± >>> what happens if a multicolumn element becomes a region it is
>± >>> ambiguous so far. I think it stops being multicolumn but simply
>± >>> becomes a container. But it is not what is implied here, is it?
>± >>> It sounds potentially useful, and also potentially complicated to
>± >>> implement...
>± >>
>± >> You are correct, this is not what I was implying. I was suggesting
>± >> that the attached flow is subject to the layout of the container it
>± >> is attached to, I.e., multi-column in this case.
>± >
>± > It is a very interesting and useful functionality. We have to realize
>± > that for linked containers it is a very expensive requirement. So far,
>± > only one kind of layout supports pagination - it is the normal flow
>± > layout. Multicolumn is the only one that should naturally be expected
>± > to support pagination as well. But having a fixed-height table invoke
>± > page-breaking code when next row doesn't fit is a totally new concept.
>± >
>± > Although most layout types break across pages, it is different from
>± > being paginating containers. I am not saying it is wrong to propose
>± > this kind of behavior,  just want to make sure it is understood that
>± > it is a big change.
>± 
>± Alex, to ensure that I'm understanding you, are you making the point
>that
>± we can currently break a table across pages but that's a different thing
>± from having, say, two regions established by table,div (such that the
>± table is fixed height) and then flowing a flow into those two regions
>and
>± expecting the table to determine when to cut off the flow and send it
>over
>± to the second region?
>± 
>± And if so, isn't it just a question of trying to generate the next row
>and
>± then abandoning it as soon as it becomes clear that the row will be too
>± tall to fit, and instead sending the flow to the next region?
>± 
>
>I was trying to explain the difference between ability of each layout
>type to be broken (when given limited available space) and the ability to
>manage the available space within a container and trigger breaking
>behavior within its content, if it applies.
>
>In many cases it should be possible to define sensible breaking behavior
>that is specific to each content type. For example I can see a video
>element show a different scene in each video region. But we definitely
>can't count on all layout types to support breaking content just because
>they themselves can be broken when printed.
>
>At this point we (editors) have decided to limit linked-containers
>behavior to containers with normal block flow (block or multiline). That
>can be changed in the future, when we are ready to define in detail how
>it works for each layout type.

Just for the record, this is something the editors proposed to the WG
during the last F2F (last week) and it was accepted. See:

http://lists.w3.org/Archives/Public/www-style/2011Aug/0069.html
RESOLVED: for this version we are limiting regions to be block containers;
will
               add a note that this may be expanded in future levels


Cheers,
Vincent

Received on Wednesday, 3 August 2011 15:33:05 UTC