RE: [css3-exclusions] ordering exclusions by z-order

>From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan
>Sent: Thursday, May 17, 2012 3:20 AM
>
>The dependency of exclusion order, and hence layout, on z ordering is still a problem for us in Gecko. Currently nothing in CSS makes layout depend on z-order, so >we don't compute z-ordering until paint time. By adding this new dependency you're making a fundamental change to the architecture of CSS and will require us >to make fundamental changes. Maybe there is no alternative, but it sucks.

You're right that layering can be delayed until it's time to paint. However, you don't need to paint in order to figure out the drawing order between two elements in your content tree. Also, the effect of exclusions is scoped to their containing block only and you don't need to make any such comparisons in case there are no exclusions present. The scoping of exclusions actually simplifies things quite a bit and if you think about it, most of the edge case z-index problems won't apply.

>Also, CSS z-ordering is widely agreed to be super-complex and difficult to understand, so making layout depend on it pulls a lot of complexity into layout, and >exclusions specifically. This may be unwise. One of the complexities is that parts of the same element can be interleaved in z-order with parts of other elements, >so in fact section 3.4 is ambiguous. It is not enough to say "exclusions follow the painting order". You probably want to say something about exclusions being >ordered according to the order in which the borders of the exclusion elements would be painted. 

z-ordering being super-complex and difficult to understand is something that we're stuck with I guess. However, for most practical purposes expecting that what paints on top will affect what's behind it (given the element is an exclusion) is very reasonable. Again, scoping makes a huge difference.

You're right about the ambiguity of section 3.4 and I have a task on me to clarify that we're talking higher content layers and not the backgrounds etc.

>When you combine this with CSS multi-column and regions, a block-level exclusion element could break and have multiple border-boxes. This entire spec seems >to be written on the assumption that there will only be one-border box. It might not be too hard to accumulate all border-boxes into the exclusion region, but the >spec needs to be updated to handle that. But worse, with CSS regions, the border-boxes might not all be at the same z-level; I think you could have two exclusion >elements whose border-boxes are interleaved in z-order. (E.g. when an element breaks across region boundaries and the second region uses 'z-index' to land >somewhere else in the z-order.) If so, then ordering exclusion elements by z-order won't work.

I kind of see the assumption of one border box. Specifying the fact that exclusion contexts must be rebuild in each fragmentation context is a valid point and I'll try to add this to the spec.

>Maybe you can rescue the situation by declaring that an exclusion is not an element but something else, that an exclusion element can generate multiple >exclusions (corresponding to its multiple border-boxes), and these exclusions can be ordered independently. (You'd need to audit the spec to make sure that the >distinction between "exclusion" and "exclusion element" is correctly and clearly made everywhere.)

Every element can generate multiple boxes due to fragmentation and exclusion elements are no exception. This is why we try to be consistent in the spec and talk in terms of exclusion boxes and not elements. Do you see something else that is missing here?

>If you do that, you'll need to check carefully to make sure things work when an element's first border-box is an exclusion box for its second border-box and vice >versa...

Good point again. Adding a clarification that exclusion contexts are computed per fragmentation context will resolve this problem.

Thanks,
Rossen

Received on Saturday, 19 May 2012 05:25:59 UTC