Re: [css4-images] element() and non-static children

On Jul 30, 2012, at 10:19 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Mon, Jul 30, 2012 at 10:05 AM, Simon Fraser <smfr@me.com> wrote:
>> I think there is a problem here.
>> 
>> Say the source is
>> 
>> <div id="main" style="position: absolute>
>>  <div id="child">
>>    <div id="grandchild" style="position: absolute"></div>
>> </div>
>> </div>
>> 
>> <div style="background-image: element('#child')"</div>
>> 
>> The question is whether "grandchild" would show up in the element() image, when grandchild's containing block is outside the element() subtree. Think about what would happen if "grandchild" were position:fixed.
>> 
>> In WebKit, if we just jumped into the painting code to paint "child", we would not paint "grandchild" because it belongs to a different layer. If you start adding z-index to these, then it gets even more tricky, because you have to decide whether to paint something that belongs to a different stacking context than the target of element().
>> 
>> Tab, to get what you're proposing, I think you need a model where, to paint the contents of element(), you have to back up the tree to some element that encompasses the stacking context ancestor of the element() target (and maybe the containing blocks of all the positioned elements under that target), then paint the subtree, painting nothing which is an ancestor of the target. That's a bit weird.
>> 
>> Basically the definition of element() needs to point to Appendix E and say where it jumps into the painting code.
> 
> There's nothing problematic here spec-wise.  You do precisely what it
> says - paint the element and its descendants.  If you want, you can
> think of it like Andrew outlined - render the document as normal, just
> skip rendering any element that's not the element() target or a
> descendant.
> 
> Now, this might be problematic from an implementation perspective, or
> even from a usability perspective (it might very well not make sense
> to paint abspos children in a different stacking context), in which
> case we can talk about adding limitations to it.  But I still don't
> understand how anything is missing from the spec as it stands. It
> seems like y'all are inventing problems that don't exist if you just
> do what the spec says.  ^_^

I think we would have to implement as Andrew outlined. The problem for
implementors is that painting an element does not necessarily paint all of its descendants,
because of stacking contexts etc.

Simon

Received on Monday, 30 July 2012 17:42:24 UTC