W3C home > Mailing lists > Public > www-style@w3.org > June 2016

Re: computedStyle of cloneNode

From: Simon Pieters <simonp@opera.com>
Date: Thu, 30 Jun 2016 13:36:00 +0200
To: "Shane Stephens" <shans@google.com>, "L. David Baron" <dbaron@dbaron.org>
Cc: "www-style list" <www-style@w3.org>, "Mike Sherov" <mike.sherov@gmail.com>, "Greg Whitworth" <gwhit@microsoft.com>
Message-ID: <op.yjvbuamlidj3kv@simons-mbp>
On Tue, 03 May 2016 06:20:09 +0200, 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.)

I'm looking in to this a bit, test case at  
https://github.com/w3c/csswg-drafts/issues/219#issuecomment-229633398

I tried to call getComputedStyle in funny ways as described in  
https://html.spec.whatwg.org/multipage/webappapis.html#realms-settings-objects-global-objects  
(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  
c.getComputedStyle.call(d, 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:

https://bugs.webkit.org/show_bug.cgi?id=122416

and

https://bugs.chromium.org/p/chromium/issues/detail?id=304700

...which blocks:

https://bugs.chromium.org/p/chromium/issues/detail?id=176671 [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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:47 UTC