RE: [css3-regions] New CSS Regions editor draft

± From: Vincent Hardy
± Sent: Thursday, June 02, 2011 7:44 AM
± 
± On May 31, 2011, at 11:30 AM, Robert O'Callahan wrote:
± 
± > When elements break vertically over containers with different widths and
± heights, it becomes non-obvious what the containing block width and height
± should be for such elements. Can you add something to your draft
± specifying that?
± 
± This is an example of an issue that already exists in paged media (where
± you can have different page size and/or orientation) and you are right, we
± need to define what happens. However, we should also make this consistent
± across the specifications that have the same issue/need.

There is no perfect solution for cases with varying container width with elements that depend on width in a major way (tables for example).

Our approach to this situation is that for elements that are block formatting contexts the width and horizontal position are calculated at the first page where they appear and not changed later. Although not exposed much yet (if ever) in user facing functionality, this is what we have in every layout engine at Microsoft that I am familiar with.

Both decisions (picking first page and triggering this behavior on BFC) are somewhat arbitrary. The reasoning for this approach is driven by principles that

	* simple cases should just work
	* complex cases should be predictable

Simple case here would be flowing body text into varied-width pages.

Note that using BFC as trigger has a couple of problems;

	1) It is unclear if root element is BFC or not. It has been proposed recently that it is (not sure where it ended up in CSS2.1).
	2) Multicolumn element flowing through regions should probably adjust width and number of columns (which won't happen if it gets fixed width).

I think we will need a new block category here (close to BFC, but not including root and multicolumn). It would be great to avoid having  a new category, but I don't quite see how...

Alex

Received on Thursday, 2 June 2011 01:04:31 UTC