Re: [css4-images] element() syntax (was: First draft of css4-images, feedback requested)

On Wed, Aug 8, 2012 at 2:00 PM, Simon Fraser <smfr@me.com> wrote:
> 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.

Like roc said, it appears the alternatives are worse.  If you want to
avoid the rendering possibly changing, you should make the element a
stacking context generally.

> 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.

I'm inclined to follow whatever the spec ends up doing for transforms
on the element.  Right now, it ignores them, so I prefer ignoring
clipping on the element or its ancestors.

~TJ

Received on Thursday, 9 August 2012 00:11:22 UTC