link to ticket where i brought this up: http://bugs.jquery.com/ticket/10373

You're aliasing window.getComputedStyle as a local getComputedStyle variable but that seems needless.
Instead, just check (window.getComputedStyle) in the conditionals and use it straight out within the block.

doing this you'd save another 4 (OMG FOUR!) bytes

@jdalton, how's so? Are you making jQuery document aware? (http://bugs.jquery.com/ticket/8405#comment:10)

@jdalton, just curious... what difference does it make if we're using the getComputedStyle function of the window instead of the same function on the ownerDocument?

I share the same concern as @jdalton.

@jdalton thanks for the heads up, ping me on IRC :)

@davidmurdoch @mikesherov One of the cool things about being document agnostic is that you can have jQuery in one (i)frame/primary document and script elements in other (i)frames w/o also having jQuery loaded in all (i)frames. I'm not sure how much compat jQuery has for this, but I thought it was a rad enough feature to add to my own lib. So basically before:

  // elem is from another iframe so its document, window, & defaultView are different
  elem.ownerDocument.defaultView

Using the primary window's method kills that functionality.
The use of ownerDocument and the private getWindow() function makes me think that at one time cross-frame scripting was considered a feature.

This test confirms that it is iframe safe: http://jsfiddle.net/rwaldron/4NWcY/

@jdalton - Little bit of research here - getComputedStyle doesn't seem to care what window its on...

It doesn't get the same result in FF 3.6; see this test.
The reason this raised red flags for me is normally foreign nodes cause errors to be thrown when inserting/attempting-to-mix-with the primary document's nodes.

Thanks @jdalton ... I just confirmed that FF3.6 is indeed unable to get the computed style unless called from the correct context

Perhaps when FF3.6 is EOL'ed, we can re-open this

lame - but awesome - thanks for finding the hole @jdalton

It doesn't work in Fennec either (produces the same result as FF 3.6)