Side navigation
#10373 closed enhancement (fixed)
Opened September 28, 2011 09:18PM UTC
Closed June 18, 2012 05:27PM UTC
Last modified July 18, 2013 04:25PM UTC
`document.defaultView` => `window`
Reported by: | paul.irish | Owned by: | rwaldron |
---|---|---|---|
Priority: | low | Milestone: | 1.8 |
Component: | css | Version: | git |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
grabbing getComputedStyle
off of defaultView has been commonplace for many years, but its unnecessary.
the same function has worked off the global window object all the way back, AFAICT.
I posted about this on g+ ...
oftentimes you see document.defaultView.getComputedStyle used instead of the getComputedStyle that's on the window object. I imagine that's because the spec'd "interface" that getComputedStyle was defined for defaultView before it was decided that the global object inherited the defaultView interface. http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-OverrideAndComputed
Regardless, we now have a lot of code with this defaultView
action, but I feel like its unnecessary. Funnily enough, check out this confused code example from PPK:
else if (window.getComputedStyle) var y = document.defaultView.getComputedStyle(x,null).getPropertyValue(styleProp);
~via http://www.quirksmode.org/dom/getstyles.html
Does anyone know the last browser that had gCS available on d.dV but not on window?
and david baron responded...
>> I don't think there were any. I'd guess the whole defaultView business was some combination of (1) not wanting to write a spec for window and (2) making an API that was also usable in Java.
grabbing the more convenient gCS will kill off a lot of bytes and some extra conditional complexity.
Attachments (0)
Change History (8)
Changed September 28, 2011 09:27PM UTC by comment:1
component: | unfiled → css |
---|---|
milestone: | None → 1.next |
owner: | → rwaldron |
priority: | undecided → low |
status: | new → assigned |
Changed September 28, 2011 10:25PM UTC by comment:2
Changed May 14, 2012 05:08PM UTC by comment:3
milestone: | 1.next → 1.8 |
---|
can you please resubmit this now that FF3.6 is gone?
Changed June 11, 2012 10:01PM UTC by comment:4
In at least a few places, it seems we're doing this because the element we're interrogating may be in another frame. So it's not the global window object. There isn't a lot to be gained in any case, since there are very few uses at this point. I would be happy with this just being closed if there isn't a compelling reason to make changes.
Changed June 18, 2012 05:27PM UTC by comment:5
resolution: | → fixed |
---|---|
status: | assigned → closed |
Update document.defaultView.getComputedStyle. Fixes #10373
Changeset: f7ee1f6e59f0b465f5f64bf6ac52108e445efaac
Changed November 07, 2012 05:29PM UTC by comment:6
This breaks for a test framework I work on: FuncUnit. FuncUnit opens a popup window with the application under test, and the parent window runs commands in that window. In IE, window.getComputedStyle(elem) breaks, because window is the opener window, but elem is in the popup window. elem.ownerDocument.defaultView.getComputedStyle(elem) works fine, because it gets the relevant document. Can the window part of this commit be reverted for this reason?
Changed November 08, 2012 01:52AM UTC by comment:7
@brian, can you create a new ticket for this? It seems like it would be reasonable. A simple test case would help as well.
Changed July 18, 2013 04:25PM UTC by comment:8
Replying to [comment:7 dmethvin]:
@brian, can you create a new ticket for this? It seems like it would be reasonable. A simple test case would help as well.
I've just created a ticket which I believe describes this behaviour -