Re: [css3-regions] regions forming stacking contexts

On Feb 3, 2012, at 5:03 PM, Robert O'Callahan wrote:

> On Fri, Feb 3, 2012 at 10:16 AM, Robert O'Callahan <robert@ocallahan.org> wrote:
> You're quite right that this is not defined now, I'm just asking for it to be defined. I'm not 100% sure what you just proposed, but it sounds like in my example you would say that all content flowing into the regions gets R1 as the default containing block for abs-pos elements. That's probably workable, but it definitely needs to be specced, and it may surprise authors that abs-pos content flowing into R2 is positioned in R1 even if R2 is also position:relative. Rendering content positioned relative to R1 in the stacking context for R2 may be interesting.
> 
> In fact, this gets very interesting. Suppose region R1 has a transform T1 on it, R2 has a different transform T2, and A is an abs-pos element whose parent P is flowed into R2, and P has 'opacity' on it. A's containing block is R1. Which effects are applied to A?

I can tell you what I implemented in WebKit, since I'm not sure it really matches what has been described in spec so far (but I think makes a lot of sense).

In WebKit, the contents of regions are represented via a flow thread. The flow thread is a block that is roughly analogous to the root element for the main document, i.e., its purpose is to hold all of the flow thread content that will be split across multiple regions. The ICB for a flow thread can be thought of as matching the content dimensions of the first region in which the flow thread will appear, but it isn't really the region itself.

When talking about containing blocks for an element, a positioned object's containing block isn't really the regions themselves… it is the flow thread ICB. Conceptually, you can either think of the flow thread as being split up into multiple blocks that are sized to each region, or you can think of it as a single block whose width is variable in each region. In WebKit, we opt for the latter approach in order to not get into the hell of splitting and rejoining render objects, but it amounts to the same thing.

Therefore saying A has a containing block of "R1" is not really an accurate way of talking about it. A has a containing block that is the flow thread itself, and the ICB for a flow thread may match the dimensions of R1, but it isn't actually R1 itself. It's the flow thread.

To provide an analogy, you don't think of the containing block of a positioned element when printing as being "page one." You think of it as being "the ICB that happens to match the dimensions and placement of page 1."

When rendering a region, we simply paint the entire flow thread into the region (we've already applied appropriate clipping, transforms, effects that applied to the region element itself), and have a hint that constrains the painting so that you know which region is rendering (and thus know how to ignore contents that aren't actually supposed to render in that region).

This means that in your example above in WebKit, A would in fact render with opacity applied to it from P in all regions in which it appears. The transforms in the two regions would be respected as well.