Re: [css3-regions] issue: is first region initial containing block

On Feb 9, 2012, at 9:51 AM, David Hyatt wrote:

> On Feb 8, 2012, at 8:44 PM, Brad Kemper wrote:
> 
>>> 
>>> I kind of covered this in another message, but I don't think regions themselves should be containing blocks for flow thread content. Rather the ICB for a flow thread should simply match the dimensions of the first region. This is analogous to how the ICB for the root element matches the dimensions of the viewport (or the first page when printing). The ICB for flow thread contents should not be the region itself though. I don't think that makes any sense at all.
>> 
>> I still don't see what is so wonderful about the first region, or of something with the same dimensions and placement, that it must be the ICB. Why not let an author use the normal root of the window viewport as the ICB, if all ancestor elements are position:static? This is different from printed pages, where there is no page parent to position against.
> 
> It depends on what you believe is happening when positioned elements are placed in a flow thread. I dislike the idea that the positioned object "busts out" of the flow thread if authors don't do something to the regions themselves (e.g., position:relative) to contain them. What you're essentially saying is that if somebody tries to paginate content by putting it into regions that the positioned content just isn't going to paginate unless something is done to contain it.

I prefer to think of it as giving authors the choice to decide for themselves whether or not their positioned objects should be positioned relative to the regions or relative to something containing the regions (such as the page or viewport). What you're essentially saying is that if somebody tries to paginate content by putting it into regions, that anything flowing into that region can never be positioned relative to some ancestor of the region. That seems like a huge restriction to me, and unnecessary. 

> We have two other examples to use as a guide. Printing and columns. In the printing case, positioned objects do get paginated. In the columns case, they don't. I think of regions as being more like printing, though, in that the author explicitly shunted the positioned content into the flow thread, and in my opinion by doing so, we should use a model where this positioned content paginates by default.

With printed pages, there is no other possibility, because the page does not have any ancestors. The region does (maybe even regions inside of other regions). The limitations of printed pages should not limit the increased flexibility of regions.

> Otherwise we're effectively ignoring the request to put the content into the flow thread in the first place.

We're not ignoring it, we're providing an option for how the author wants the content to be positioned. Absolutely positioning elements takes them out of the flow, even without regions. Position:relative applied ancestors is a standard way for authors to decide what that abspos is relative to. 

> If you accept that the positioned content is respecting pagination, then using the first region's dimensions as an ICB (e.g., if someone says bottom:0) makes sense in that it matches printing. If you don't accept that the positioned object should paginate, then I can see your objection.

I accept that author would often want positioned objects to paginate, but not always, when the pages have ancestors that can sometimes be a better choice.

Received on Thursday, 9 February 2012 18:09:19 UTC