Re: computedStyle of cloneNode

On Tue, 03 May 2016 06:20:09 +0200, L. David Baron <>  

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

I'm looking in to this a bit, test case at

I tried to call getComputedStyle in funny ways as described in  
(plus a document without a browsing context).

When you have an element in a document that is being rendered, Gecko,  
WebKit and Chromium all just use the element's own document's styles,  
regardless of how getComputedStyle is called, as far as I can tell. So the  
spec is just wrong here.

If the #d iframe is display:none, Gecko throws TypeError for, elm). WebKit and Chromium return "".

For a document.implementation.createHTMLDocument()-created doc, Gecko  
returns the style of relevant Realm's doc. WebKit and Chromium return "".

What does Edge do?

I think the behavior of WebKit and Chromium makes more sense -- per CSS  
rules these elements don't have a computed style.

I've found:


...which blocks: [meta] Issues  
that jQuery is working around.

What was the issue for jQuery? Is it still an issue?

Simon Pieters
Opera Software

Received on Thursday, 30 June 2016 11:36:34 UTC