- From: Simon Fraser <smfr@me.com>
- Date: Wed, 08 Aug 2012 14:00:20 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Rik Cabanier <cabanier@gmail.com>, www-style list <www-style@w3.org>
On Aug 7, 2012, at 1:54 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Tue, Aug 7, 2012 at 1:49 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>> Hi Tab,
>>
>> are you going to include language that creates a stacking context out of a
>> reference element?
>> Also, it seems that example 11 has a broken image link.
>
> Yes, the consensus seems to be that we should treat the referenced
> element as a stacking context while rendering it for element().
I'm not a fan of this; I don't want to have to mutate our internal data structures
for the element() paint.
It also means that the appearance of descendants of the element() target
may change when rendering for element(), because of z-order. Consider:
<div id="box" style="position: absolute; background-color: blue;">
<div style="background-color: green; position: absolute; z-index: -1"></div>
</div>
<div style="background: element('#box')"></div>
The original #box will look like a blue square, but when rendered for element()
it will show green.
Another questions about element(); does clipping via overflow or clip
on the target element or any ancestor affect the element() rendering? I could imagine
a use case where the original element has overflow:hidden, but when rendered via
element() it displays unclipped.
Simon
Received on Wednesday, 8 August 2012 21:01:15 UTC