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

± 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.

Alex

Received on Wednesday, 3 August 2011 09:18:32 UTC