- From: 段垚 <duanyao@ustc.edu>
- Date: Fri, 12 Dec 2014 23:53:32 +0800
- 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