document.defaultView returns a reference to the semi-mysterious
AbstractView interface - "a base interface that all views shall derive
from"
<
http://www.w3.org/TR/DOM-Level-2-Views/views.html#Views-AbstractView>
So AbstractView (==document.defaultView) is that imaginary container
where HTML element and anything inside of it resides and being viewed
on the screen, something that is contained by nothing by contains
everything. As a "DOM equivalent of God"
it did suppose to know of
how anything looks like at any spot of the viewport.
On practice - as you already discovered - its current
(under)implementation across UA's leaves more to desire.
But even in its current state it may be useful, at least it is much
more useful than IE's currentStyle.
See for example how easy to find - using getComputedStyle - one of the
most important values: the actual pixel equivalent of 1em for the given
container (and compare it with IE's data):
<html>
<head>
<title>Test</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<style type="text/css">
p {
font-size: 1em;
}
</style>
<script type="text/javascript">
function init() {
var p = document.getElementsByTagName('p')[0];
var em = null;
if (document.defaultView) {
em = document.defaultView.getComputedStyle(p,null).fontSize;
alert(em);
}
else if (p.currentStyle) {
em = p.currentStyle.fontSize;
alert(em);
}
else {
'NOP';
}
}
window.onload = init;
</script>
</head>
<body>
<p>M</p>
</body>
</html>
<speculation>
I am not sure where did the elementReference.getComputedStyle support
come from. My guess would be that some producers (W3C?) wanted to
provide a possibility to make the code more "visually close" to IE with
its elementReference.currentStyle.
This attempt though seems as dropped at the middle.
1. it seems pretty useless to anything but internal code for the
browser. Most peoples' in-page code is not going to care that the
result of inheriting down the cascade of styles yields something like
'auto'. Maybe code to snip a element off the tree and put the node
somewhere else might care about things like that, but otherwise I can't
think of code that I would write that would need that information.
There really ought to be a method to do what most people want to do --
calculate the actual resulting positions, colors, etc., that result from
the element being displayed on the page.
So we get forced into things like the nice script available at
http://www.quirksmode.org/js/findpos.html, but that seems to break a
fundamental principle of OOP -- that a programmer should not be
concerned with the inner workings of an object; rather they should be
able to treat it as a "black box". So I shouldn't have to work my way
up the containment tree to find a position. The browser has already done
that; I know, I see the element at a position on the page, and obviously
the browser put it there.
2. getting 'auto' as the result hasn't 'computed' anything, so why the
name of the method? getDerivedStyle or or something like that would
seem to be a better name.
That is a bleeding problem of the current DOM and I do sign under each
word. I do not understand why an everyday obvious task would require
sophisticated programs like the one on Quirksmode or even more
sophisticated (but more robust) at
<
http://www.javascripttoolbox.com/lib/objectposition/>
Iin more than 10 years no one managed to provide anything reasonable on
the matter. It suggests that there is some core problem in how DOM and
graphics context have to communicate with each other: which requires
either write an all new software from the scratch - or to leave
developers with all these crappy and obscure offsetHere/offsetThere
