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

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

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Thu, 2 Jun 2011 01:04:00 +0000
To: Vincent Hardy <vhardy@adobe.com>, "robert@ocallahan.org" <robert@ocallahan.org>
CC: W3C style mailing list <www-style@w3.org>
Message-ID: <D51C9E849DDD0D4EA38C2E53985692841200D618@TK5EX14MBXC213.redmond.corp.microsoft.com>
 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...

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

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:34:53 UTC