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

More [am]

From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Vincent Hardy
Sent: Wednesday, July 13, 2011 1:52 PM
To: Alex Mogilevsky; Anton Prowse; www-style@w3.org
Subject: Re: [css3-regions] Comments on Editor's Draft

[...]

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.

[VH] Yes.

[am] 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...

>> [VH] 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.

[am] 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.