W3C home > Mailing lists > Public > www-style@w3.org > December 2014

Re: [cssom] What should happen with getComputedStyle on a node in another document when used values are involved?

From: 段垚 <duanyao@ustc.edu>
Date: Fri, 12 Dec 2014 23:53:32 +0800
Message-ID: <548B0F7C.5000107@ustc.edu>
To: Boris Zbarsky <bzbarsky@mit.edu>, www-style@w3.org
I added more test cases, and reformat the table in pure text as follows:

No. Firefox33   IE11    Chrome39    Conditions
1   self        self    self        element in iframe,no matching rule 
in parent, has matching rule in self
2   self        self    self        element in iframe,has matching rule 
in both self and parent
3   layout      layout  layout      element in iframe,no matching rule 
in both self and parent
4   self        self    self        element in iframe,has matching rule 
in both parent and self, has display:none in self
5   self        self    self        element in iframe,has matching rule 
in both parent and self, parent has display:none in self
6   initial     initial initial     element in iframe,has matching rule 
in parent, no matching rule in self, has display:none in self
7   self        self    self        element in iframe,has matching rule 
in parent and inline rule in self, iframe has display:none
8   parent      self    self        element in iframe,has matching rule 
in both parent and self, iframe has display:none
9   null        self    self        element in iframe,has matching rule 
in both parent and self, iframe has display:none,call iframe's 
getComputedStyle
10  initial     initial empty       element in windowless doc,no 
matching rule in both self and parent
11  parent      self    empty       element in windowless doc,has 
matching rule in both self and parent
12  parent      self    empty       element in windowless doc,has 
matching rule in parent, has inline rule in self
13  initial     self    empty       element in windowless doc,no 
matching rule in parent, has inline rule in self
14  self        self    empty       detached element in iframe,has 
matching rule in parent, has inline rule in self
15  parent      initial empty       detached element in iframe,has 
matching rule in parent, has matching rule in self
16  initial     initial empty       detached element in iframe,no 
matching rule in parent, has matching rule in self
17  self        self    empty       indirectly detached element in 
iframe,has matching rule in parent, has inline rule in self
18  parent      initial empty       indirectly detached element in 
iframe,has matching rule in parent, has matching rule in self
19  initial     initial empty       detached element in normal doc,no 
matching rule in doc
20  self        initial empty       detached element in normal doc,has 
matching rule in doc
21  self        self    empty       detached element in normal doc,has 
inline rule


Notes on the table:

* Tested property is "width", values are specified in px.
* "null" in row 9 means 
el_in_iframe.ownerDocument.defaultView.getComputedStyle(el_in_iframe) 
returns null in firefox, seems a bug.
* "windowless doc" means a doc that doesn't have an assosiated window 
object. It is created by createHTMLDocument(), and previously I called 
it "invisible doc".
* "detached element" means the element's parentNode is null, or one of 
its ancestors' parentNode is null, and that ancestor is not a document node.

Summary of the test:

* Browsers are almost consistent for cross-document getComputedStyle() 
as long as these docs are not windowless, and the element is not 
detached. Exceptions are found in firefox if the iframe has display:none 
set (row 8-9). Maybe we can standardize these cases first.

* Browsers are fragmented for windowless doc and detached node cases.


在 2014/12/12 11:43, Boris Zbarsky 写道:
> On 12/10/14, 1:49 AM, 段垚 wrote:
>> My test results of getComputedStyle() on a foreign element in 3 desktop
>> browsers is as follows:
>
> I think we need to add a few things to the test matrix. Specifically, 
> these may be of interest:
>
> 1)  Node is display:none and in an iframe.
> 2)  Node has a display:none parent and is in an iframe.

Browsers are consistent for these cases, i.e. only rules in the iframe 
are considered, equivalent to 
el_in_iframe.ownerDocument.defaultView.getComputedStyle(el_in_iframe).

> 3)  Node is in an iframe and the <iframe> element is display:none.

In IE and chrome still only rules in the iframe are considered.

Firefox use parent doc's rule unless the node has a inline rule (row 
7/8) - looks strange because this behavior differs from both normal 
iframe cases and windowless doc cases. Even worse, 
el_in_iframe.ownerDocument.defaultView.getComputedStyle(el_in_iframe) 
returns null in firefox in this case.

> 4) Node's ownerDocument is in an iframe but the node is not "in the
>     document" (in that its parentNode chain does not terminate at the
>     document node).

I call such node "detached". In Firefox, inline rule > parent's rule, 
and iframe's rule is not considered; in IE only inline rule is considered;
Chrome doesn't support getComputedStyle on a detached node, no matter it 
is in an iframe or in a root doc.

>
> I think calling the createHTMLDocument() case "invisible doc" is a bit 
> misleading, because it actually has a much stronger constraint on it: 
> it's a document which is not in a browsing context at all. There are 
> various cases of "invisible" documents which are in browsing contexts, 
> and in fact may well have CSS layout happening in them.

Now I call it "windowless doc", is this OK?

>
>> * Browsers are consistent for visible subdoc (i.e. in a frame). That is,
>> parent doc's CSS rules are never considered, and
>> getComputedStyle(el_in_frame)
>> is equivalent to
>> el_in_frame.ownerDocument.defaultView.getComputedStyle(el_in_frame).
>> However this behavior conflicts with current CSSOM spec.
>
> Yep.
>
>> * Browsers are inconsistent for invisible subdoc. Firefox's behavior
>> seems similar to the one defined spec, but layout is not performed to
>> compute used values,
>
> There can't be any layout because there is no browsing context, fwiw. 
> Also, per HTML spec style sheets in such a document must not be loaded 
> (an <style> elements must not be parsed).  So what IE is doing here 
> just doesn't match the HTML spec at all.

I think layout can be done if an initial containing block is known - 
using parent doc's ICB may be an option. However since images in 
windowless doc are not going to be loaded, theirs intrinsic width/height 
are not known.

>
>>    and inline rules are dropped.
>
> Yeah, the data structure we use for CSS-anything in Gecko just doesn't 
> exist in document's without a browsing context.
>
>> Chrome doesn't support getComputedStyle() on invisible subdoc at all.
>
> Here's a question.  If you make that getComputedStyle call, then adopt 
> the element into a document that _is_ in a browsing context, what 
> happens?  Does it matter whether you insert the element so it's "in 
> the document" in the document it was adopted into?

According to the test result above, Chrome also returns empty string 
from ComputedStyle of detached nodes, so merely adopting the element 
into a document that _is_ in a browsing context changes nothing.

>
> -Boris
>

Regards.
   Duan Yao
Received on Friday, 12 December 2014 15:54:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:49 UTC