computedStyle of cloneNode

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

computedStyle of cloneNode

Shane Stephens-2
Hi list,

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.

Thoughts?

Cheers,
    -Shane
Reply | Threaded
Open this post in threaded view
|

Re: computedStyle of cloneNode

조은
Hi. Shane.

maybe this will be help you

> Since a computed style is related to an Element node, if this element is removed from the document, the associated CSSStyleDeclaration and CSSValuerelated to this declaration are no longer valid.



2016. 5. 3., 오전 10:39, Shane Stephens <[hidden email]> 작성:

Hi list,

What should 
getComputedStyle(foo.cloneNode(true)).opacity;

Here you clone node.
cloned node does not include in document.

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.


so maybe getComputedStyle does not work.

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

Cheers,
    -Shane

Here is test codes :


Thanks.
Reply | Threaded
Open this post in threaded view
|

RE: computedStyle of cloneNode

Oriol Bugzilla
In reply to this post by Shane Stephens-2
Just a note. According to my tests, Gecko doesn't necessarily return the same styles for the cloned node.

For example, if you have `*{opacity:0.5}`, that will affect both the cloned element and the clone outside the document, so you will get 0.5 for both.

But if you have `body *{opacity:0.5}`, that will only affect the element inside the body, but not to the clone outside the document. So you will get 0.5 for the cloned and the initial 1 for the clone.

So I think in fact there are two different questions:

  - Should getComputedStyle work for elements outside the document?
  - Should selectors in stylesheet match elements outside the document?

-Oriol


From: [hidden email]
Date: Tue, 3 May 2016 01:39:56 +0000
To: [hidden email]
Subject: computedStyle of cloneNode

Hi list,

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.

Thoughts?

Cheers,
    -Shane
Reply | Threaded
Open this post in threaded view
|

Re: computedStyle of cloneNode

L. David Baron
In reply to this post by Shane Stephens-2
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.)

-David

--
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: computedStyle of cloneNode

Rune Lillesveen
On Tue, May 3, 2016 at 6:20 AM, L. David Baron <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: computedStyle of cloneNode

Shane Stephens-2
I'm not sure it makes sense to match rules on out-of-document elements at all. Some rules (like nth-child) are conditional and may match once the element is inserted (plus there's inheritance), so any computed style is not guaranteed to be correct. I'd rather specify that elements must be in the tree to match rules, and either provide no style or provide initial values only for out-of-document elements.

I don't think there are any compatibility issues for open web content as our behavior here is quite divergent.

Cheers,
    -Shane

On Tue, May 3, 2016 at 7:22 PM Rune Lillesveen <[hidden email]> wrote:
On Tue, May 3, 2016 at 6:20 AM, L. David Baron <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: computedStyle of cloneNode

Rune Lillesveen
On Tue, May 3, 2016 at 12:57 PM, Shane Stephens <[hidden email]> wrote:
> I'm not sure it makes sense to match rules on out-of-document elements at
> all. Some rules (like nth-child) are conditional and may match once the
> element is inserted (plus there's inheritance), so any computed style is not
> guaranteed to be correct. I'd rather specify that elements must be in the
> tree to match rules, and either provide no style or provide initial values
> only for out-of-document elements.

I didn't understand what you meant by :nth-child and the computed
style not being correct. :nth-child would never match detached
elements which do not have a parent element, the same way document
root elements never match :nth-child. Descendants would match as
usual.

> I don't think there are any compatibility issues for open web content as our
> behavior here is quite divergent.

No, probably not. I don't know if there are any obvious use cases here.

--
Rune Lillesveen

Reply | Threaded
Open this post in threaded view
|

Re: computedStyle of cloneNode

L. David Baron
In reply to this post by Rune Lillesveen
On Tuesday 2016-05-03 11:22 +0200, Rune Lillesveen wrote:
> The Gecko behavior looks sane from what I've tested:
>
> https://jsfiddle.net/csujdtsn/

Gecko's behavior is weird in at least the case of calling
win1.getComputedStyle(element in win2):

 * if win2 is being presented, this will use the styles from win2's
   document

 * if win2 is not being presented (e.g., it's for an iframe that is
   in a display:none subtree or in an iframe that is not in a
   document), this will use the styles from win1's document.

-David

--
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: computedStyle of cloneNode

Shane Stephens-2
In reply to this post by Rune Lillesveen


On Tue, May 3, 2016 at 9:13 PM Rune Lillesveen <[hidden email]> wrote:
On Tue, May 3, 2016 at 12:57 PM, Shane Stephens <[hidden email]> wrote:
> I'm not sure it makes sense to match rules on out-of-document elements at
> all. Some rules (like nth-child) are conditional and may match once the
> element is inserted (plus there's inheritance), so any computed style is not
> guaranteed to be correct. I'd rather specify that elements must be in the
> tree to match rules, and either provide no style or provide initial values
> only for out-of-document elements.

I didn't understand what you meant by :nth-child and the computed
style not being correct. :nth-child would never match detached
elements which do not have a parent element, the same way document
root elements never match :nth-child. Descendants would match as
usual.

Right, that's what I mean. The computed style of the detached element can't be "correct" in general as it might be modified by context when inserted into the document. Given that, what would a computed style on a detached element actually represent, and what use cases would there be to have one?

Cheers,
    -Shane
 

> I don't think there are any compatibility issues for open web content as our
> behavior here is quite divergent.

No, probably not. I don't know if there are any obvious use cases here.

--
Rune Lillesveen
Reply | Threaded
Open this post in threaded view
|

Re: computedStyle of cloneNode

Garrett Smith


On May 3, 2016, at 2:49 PM, Shane Stephens <[hidden email]> wrote:

I didn't understand what you meant by :nth-child and the computed
style not being correct. :nth-child would never match detached
elements which do not have a parent element, the same way document
root elements never match :nth-child. Descendants would match as
usual.


Right, that's what I mean. The computed style of the detached element can't be "correct" in general as it might be modified by context when inserted into the document. Given that, what would a computed style on a detached element actually represent, and what use cases would there be to have one?

Wrong. What might or might not happen to a detached node is irrelevant. (If a bear decides to shit in the woods...) If the node is not in the defaultView, it has no computed style information. Or at least that used to be the case. Apparently AVK fixed it up in CSSOM, first moving getComputedStyle from defaultView to window, and then appeasing the rest. https://drafts.csswg.org/cssom/#extensions-to-the-window-interface

"All longhand properties that are supported CSS properties, in lexicographical order, with the value being the resolved value computed for obj using the style rules associated with doc."

Fantastic.

This was probably the result of JavaScript library developers and users complaining about not being able to get style info from detached nodes, probably even filing bugs about it.

The behavior defined by CSSOM seems unreasonable. Should it be removed entirely?

Thank you,
Reply | Threaded
Open this post in threaded view
|

Re: computedStyle of cloneNode

Shane Stephens-2
Bringing this back on track...

(1) several of us have now stated that computed style for detached nodes doesn't really make sense. Rune may disagree with this stance but I'm not sure?

(2) if this were a general rule then we'd have an answer for the initial question (what to do with computed style of a cloned node) - as the clone would not be in-document, it wouldn't have a computed style.

Can we either resolve that there should not be a computed style for detached nodes, or resolve on a consistent behavior for cloned nodes?

Thanks,
    -Shane
Reply | Threaded
Open this post in threaded view
|

Re: computedStyle of cloneNode

Anne van Kesteren-4
On Wed, May 4, 2016 at 2:46 AM, Shane Stephens <[hidden email]> wrote:
> (1) several of us have now stated that computed style for detached nodes
> doesn't really make sense. Rune may disagree with this stance but I'm not
> sure?

It's resolved, not computed, for what it's worth. Pretty sure it was
specified this way because content relies on it being this way. Maybe
that's no longer true?


> (2) if this were a general rule then we'd have an answer for the initial
> question (what to do with computed style of a cloned node) - as the clone
> would not be in-document, it wouldn't have a computed style.

Agreed, cloning should have no material effect one way or another here.


--
https://annevankesteren.nl/

Reply | Threaded
Open this post in threaded view
|

Re: computedStyle of cloneNode

Rune Lillesveen
In reply to this post by Shane Stephens-2
On Wed, May 4, 2016 at 2:46 AM, Shane Stephens <[hidden email]> wrote:
> Bringing this back on track...
>
> (1) several of us have now stated that computed style for detached nodes
> doesn't really make sense. Rune may disagree with this stance but I'm not
> sure?

I don't argue the usefulness of it, just that it can be spec'ed and
implemented in a way consistent with computed style in display:none
subtrees and resolved values.

> (2) if this were a general rule then we'd have an answer for the initial
> question (what to do with computed style of a cloned node) - as the clone
> would not be in-document, it wouldn't have a computed style.

Yes, a cloned node would be no different than a node created with say
document.createElement() not in-document in this sense.

--
Rune Lillesveen

Reply | Threaded
Open this post in threaded view
|

Re: computedStyle of cloneNode

Shane Stephens-2
In reply to this post by Anne van Kesteren-4


On Wed, May 4, 2016 at 4:08 PM Anne van Kesteren <[hidden email]> wrote:
On Wed, May 4, 2016 at 2:46 AM, Shane Stephens <[hidden email]> wrote:
> (1) several of us have now stated that computed style for detached nodes
> doesn't really make sense. Rune may disagree with this stance but I'm not
> sure?

It's resolved, not computed, for what it's worth. Pretty sure it was
specified this way because content relies on it being this way. Maybe
that's no longer true?

If there's no computed style, there's no resolved style either :) Probably better to talk about computed style though, so we capture the correct behavior in the new typed OM as well.

I'm skeptical that anything relies on this in practice as there's a total lack of interoperability between implementations.
 
> (2) if this were a general rule then we'd have an answer for the initial
> question (what to do with computed style of a cloned node) - as the clone
> would not be in-document, it wouldn't have a computed style.

Agreed, cloning should have no material effect one way or another here.


--
https://annevankesteren.nl/
Reply | Threaded
Open this post in threaded view
|

Re: computedStyle of cloneNode

Simon Pieters-3
In reply to this post by L. David Baron
On Tue, 03 May 2016 06:20:09 +0200, L. David Baron <[hidden email]>  
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