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

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

From: Anton Prowse <prowse@moonhenge.net>
Date: Sat, 23 Jul 2011 16:41:37 -0500
Message-ID: <4E2B4011.4040709@moonhenge.net>
To: "www-style@w3.org" <www-style@w3.org>
CC: Alex Mogilevsky <alexmog@microsoft.com>, Vincent Hardy <vhardy@adobe.com>
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?

Anton Prowse
Received on Saturday, 23 July 2011 21:42:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:02 UTC