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

As far as I understand the current specification, any element that's not a 
child of the element's target MUST NOT be rendered.

The notion of element() doesn't care about the real rendering of the element 
in the context of the page; it's just like if you add a SVG document embeded 
on your page and you decided to use it as a background somewhere else. Now, 
instead of repainting the SVG element in a Canvas, you can just reference it 
using the element() function. Whether or not an element overlap that 
referenced SVG element in the page rendering should have no impact on the 
background returned by the element() function.







-----Message d'origine----- 
From: Simon Fraser
Sent: Monday, July 30, 2012 7:05 PM
To: Tab Atkins Jr.
Cc: Andrew Fedoniouk ; www-style@w3.org
Subject: Re: [css4-images] element() and non-static children

On Jul 29, 2012, at 2:58 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Sun, Jul 29, 2012 at 1:16 PM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>> On Sun, Jul 29, 2012 at 12:38 PM, Tab Atkins Jr. <jackalmage@gmail.com> 
>> wrote:
>>> On Sun, Jul 29, 2012 at 12:04 PM, Andrew Fedoniouk
>>> <news@terrainformatica.com> wrote:
>>>> What is the z-index value of such element then?
>>>> Let's assume that element used in element() (let it be A element) is in
>>>> some container that has z-index:10 and the A element has children:
>>>> B with z-index:1 and C with z-index:20. What would be the rendering
>>>> order of this setup:
>>>> 1. B -> A -> C or
>>>> 2. A -> B -> C ?
>>>> (note that element A is position:static by itself)
>>>
>>> I don't understand the question.  You just draw it like normal.  The
>>> spec is very clear about how this works.
>>
>> It's my turn then to ask: what "draw it like normal" means in this
>> case?
>>
>> Is your "normal" close to this:
>>
>> For the purpose of element() rendering take rendering tree of the
>> whole document and render it in its normal order but skip all elements
>> that are not the element itself or are not its descendants (DOM).
>>
>> ?
>>
>> This definition will cover positioned children with negative and positive
>> z-indexes.
>>
>> This statement here [1] :
>>
>> "The image is constructed by rendering the referenced element and its
>> descendants"
>>
>> can be read as render the element and *then* its descendants.
>> Usually "render element" includes rendering of its content, that's why
>> my question.
>
> I'm not sure how this is ambiguous.  It means exactly what it says,
> not anything weird or different.  If I meant anything other than
> "render as normal", I would have said so.  Just... draw the element
> and its descendants in the normal way, following Appendix E, over an
> infinite transparent canvas.

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.

Simon

Received on Monday, 30 July 2012 17:22:52 UTC