Re: computedStyle of cloneNode

On Tue, May 3, 2016 at 6:20 AM, L. David Baron <dbaron@dbaron.org> wrote:
> On Tuesday 2016-05-03 01:39 +0000, Shane Stephens wrote:
>> What should
>> getComputedStyle(foo.cloneNode(true)).opacity;
>> be?
>>
>> Gecko returns the same value as getComputedStyle(foo).opacity, while WebKit
>> and Blink return empty strings. Edge returns "1" regardless of foo's
>> opacity.
>>
>> It seems to me that returning the computed style of the cloned node is
>> wrong as the clone isn't in the document and therefore doesn't match the
>> same rules as the original. However, I can't find any specification text
>> that confirms this.
>
> The Gecko code currently falls largely into the same codepath for
> the content not being in a document, and the content being in a
> display:none subtree (and thus not having a box/frame/rendering
> object with current style), which is to run selector matching on the
> element (and its ancestors) until it finds an element with a
> box/frame/rendering object.  (Though I suppose the handling of not
> in a document is more similar to being in a document not currently
> being presented (e.g., in a display:none iframe), in that in those
> cases we won't even try looking for a rendering object.)
>
> The Gecko behavior there for content not in a document isn't
> particularly sensible, and I'd be happy to get rid of it if it's not
> Web-compatible.  (I didn't realize that other implementations didn't
> do the same.)
>
> One question is whether there are Web-compatibility constraints as
> to what getComputedStyle should do on elements in a display:none
> iframe (either with the getComputedStyle being from the window of
> the iframe's parent or the iframe's window).  (Gecko may have other
> bugs in handling win1.getComputedStyle(element in win2) relative to
> what the spec says.)

The Gecko behavior looks sane from what I've tested:

https://jsfiddle.net/csujdtsn/

If the root element in [1] can be the root of a detached subtree, it
means we'll just inherit the initial values for such roots as well.
Since elements not in the document do not generate boxes, it follows
that they behave as if they were descendants of display:none elements
in the document for resolved values [2].

Based on the comment in [3], it seems it's not implemented in
Blink/WebKit due to lack of machinery, but I don't think it would be
particularly hard to implement.

[1] https://www.w3.org/TR/css-cascade-3/#inheriting
[2] https://drafts.csswg.org/cssom/#resolved-values
[3] http://bit.ly/1SIEqfz

-- 
Rune Lillesveen

Received on Tuesday, 3 May 2016 09:23:03 UTC