Bug 14563 - getComputedStyle() returns an empty style declaration for detached elements
: getComputedStyle() returns an empty style declaration for detached elements
Status: NEW
: WebKit
HTML DOM
: 523.x (Safari 3)
: Macintosh Mac OS X 10.4
: P2 Normal
Assigned To:
:
: GoogleBug, InRadar, NeedsReduction, R...
:
: 110007
  Show dependency treegraph
 
Reported: 2007-07-08 14:11 PST by
Modified: 2013-08-06 19:58 PST (History)


Attachments
Example of the getComputedStyle bug (466 bytes, text/html)
2008-08-07 10:43 PST, Jon Emerson
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2007-07-08 14:11:31 PST
getComputedStyle() returns an empty style declaration for detached elements. Firefox returns a full style declaration including inherited properties (starting from the root of the detached element's tree).
------- Comment #1 From 2008-08-07 10:21:46 PST -------
I'm also running into this bug.  It affects Windows Safari, both on the latest Safari release and the WebKit nightly.

I have a 20-line HTML file that exercises the bug if you'd like me to send you it.

Thanks!

Jon Emerson
Google
------- Comment #2 From 2008-08-07 10:33:28 PST -------
Jon, please attach your test case reduction.  Thanks!
------- Comment #3 From 2008-08-07 10:33:58 PST -------
<rdar://problem/6132967>
------- Comment #4 From 2008-08-07 10:43:20 PST -------
Created an attachment (id=22698) [details]
Example of the getComputedStyle bug

The attached HTML file exercises the bug.  In Firefox, you correctly get an alert of '10px'.  In Safari, you get ''.  You can uncomment the appendChild call to see that getComputedStyle acts as intended in both Firefox and Safari if the element is appended to the document body.
------- Comment #5 From 2008-08-07 12:31:37 PST -------
Isn't this "expected" based on our implementation?  We use the resolved style for computing this.  So we'd have to do a manual style-resolve in this case, since a detached element is going to have no renderer.

SVG had to do some manual style resolution.  I guess for a detached element it's relatively easy, since you're resolving w/o a parent, so only #id selectors and * selectors apply.
------- Comment #6 From 2008-08-07 14:01:06 PST -------
We could fix this I suppose, but it's kind of odd that someone is depending on this.  It's not like any style changes you make will have any meaningful effect while detached, so what are you checking for anyway? :)
------- Comment #7 From 2008-08-08 02:29:47 PST -------
I don't have the original code any more, but if I remember correctly, this was my use case : 

I was creating a bunch of elements dynamically, throughout the lifetime of the page (as opposed to once on page load).   Whenever I inserted them, I needed to find their dimensions (using getComputedStyle) in order to position them correctly.

Which would be fine, except it turns out that getComputedStyle is pretty slow.  So I created some prototype elements on startup that I could run getComputedStyle on, cached the results, and used the precalculated values every time after that.  Which was fine in Firefox, but obviously broken in Safari given the prototype elements were never inserted into the page.

I guess I ended up inserting them into a hidden div to get the style, then deleting them again.
I'm sure there was some reason why I couldn't just do it on the first time I added an element, but nothing's coming to mind...
------- Comment #8 From 2008-08-08 15:17:04 PST -------
Per spec, getComputedStyle() returns the computed style, and a node that isn't a document by definition doesn't have a computed style. Whether that's desireable or not is another story; maybe we should redefine getComputedStyle()... that's Anne's spec, I believe.
------- Comment #9 From 2008-08-19 02:47:01 PST -------
In our application, we render our pages off-screen before attaching them to the document because in a couple popular browsers the performance of off-screen (detached) DOM creation is an order of magnitude greater than on-screen (attached) DOM creation.  Part of our rendering involves manually setting the width and heights on certain elements to fill the screen.  (We do this manually for cross-browser compatibility.)  If we can't know the margins of elements, then we can't size other elements appropriately.

Please fix this bug!  Thanks.
Jon
------- Comment #10 From 2010-07-14 06:56:34 PST -------
The spec has changed to expect the Firefox behavior: http://dev.w3.org/csswg/cssom/#extensions-to-the-window-interface
------- Comment #11 From 2011-04-08 01:23:27 PST -------
*** Bug 39250 has been marked as a duplicate of this bug. ***
------- Comment #12 From 2012-01-07 21:02:50 PST -------
The spec has indeed changed:
http://dev.w3.org/csswg/cssom/#resolved-value
http://www.w3.org/TR/css3-values/#computed-value

This shows that disconnected nodes should still resolve to computed values for disconnected nodes, with the computed value defined as: "the result of resolving the specified value insofar as possible without formatting the document, as defined in the "Computed value" line of the property definition tables."

Indeed, Firefox resolves this correctly now, but alas IE9 and Opera do this incorrectly according to the spec.

FWIW, It's also reared its head as a bug reported in jQuery: http://bugs.jquery.com/ticket/9338
------- Comment #13 From 2012-10-12 13:11:43 PST -------
*** Bug 83867 has been marked as a duplicate of this bug. ***
------- Comment #14 From 2012-10-12 13:14:20 PST -------
Related CSSWG discussion http://lists.w3.org/Archives/Public/www-style/2012Oct/0362.html.
------- Comment #15 From 2013-08-06 19:58:56 PST -------
Just faced this issue today as I wanted to know the default style applied to a certain kind of element (tagName). For info, my webkit fix is to insert the element into the HEAD hoping it doesn't trigger any relayout nor too many observable effects.