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

On Feb 9, 2012, at 10:08 AM, Brad Kemper wrote:

> 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. 

I don't see this as much of a restriction. If you wanted to position content relative to the page or viewport, you simply wouldn't put it in the flow thread. The only reason to put it in the flow thread and behave as you suggest is if you wanted to have unique per-fragment positioning schemes for a positioned object that is paginated across multiple regions. That would be extremely difficult to implement in WebKit, and I don't really understand what the use case would be for such a feature. It would complicate implementations considerably.

I don't understand why you would ever want to put positioned content into a flow thread only to have it break out of the regions its flowing through. That seems pointlessly confusing and doesn't make sense structurally from an HTML perspective. Why wouldn't you just put the positioned object closer structurally to the place you really want to position it? If that's the page or viewport, why would you ever lump the content in with the flow thread content?

> 
>> 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.

This assumes that the regions genuinely contain the child flow thread content. I think that's a dangerous assumption to make, since it greatly complicates the implementation of regions. Once you begin to think of the contents of regions as being actual children of the regions, then you get into this line of thinking where you can pull the flow thread contents higher up in the region's containing block hierarchy. That is a massive complication for implementations.
> 
>> 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.

Then don't put them in the flow thread in the first place. Again, I don't understand why you'd put a positioned object into a flow thread if all you wanted to do was position it relative to a region or something that enclosed the region. Just put it there instead. And as I said above, if the goal is to allow the positioned object to split across regions while having unique positioning schemes in each, I think that's just crazy complicated and not something we should be pursuing.

dave
(hyatt@apple.com)

Received on Thursday, 9 February 2012 19:00:23 UTC