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

On 8/3/11 2:17 AM, "Alex Mogilevsky" <> wrote:

> From: Anton Prowse []
> Sent: Saturday, July 23, 2011 2:42 PM
> To:
> 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
> 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
> expecting the table to determine when to cut off the flow and send it
> to the second region?
> And if so, isn't it just a question of trying to generate the next row
> 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:
RESOLVED: for this version we are limiting regions to be block containers;
               add a note that this may be expanded in future levels


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