getComputedStyle - Why window member function?

[Axel Dahmen]

At +ACI-http://www.howtocreate.co.uk/tutorials/javascript/domcss+ACI- I just read
that the getComputedStyle() DOM Level 2 Style member function of the ViewCSS
interface is a member of the window object.

I wonder how it works on a frames based webpage.

Why isn't this interface being applied to the Document object?

Thanks for enlightening me.

Axel Dahmen

[Boris Zbarsky]

At "http://www.howtocreate.co.uk/tutorials/javascript/domcss" I just
read that the getComputedStyle() DOM Level 2 Style member function of
the ViewCSS interface is a member of the window object.
I wonder how it works on a frames based webpage.

Each frame has its own Window object, for what it's worth.

Why isn't this interface being applied to the Document object?

Why would it be? How is that better than the Window?

In any case, the DOM spec doesn't define which object the defaultView is
for a Document. It also doesn't define anything about Window objects at
all. The fact that the defaultView is the Window is a historical
accident, but at this point it's a de-facto standard, probably going to
be documented de-jure in HTML5.

-Boris

[Axel Dahmen]

I see. So each window will find only the styles of the elements of that
particular window then. I understand.

+AD4- Why would it be? How is that better than the Window?

Because styles are not a window's property but a document's property. It
wouldn't come up my mind to search in the cupboard for motor oil, either.
That's why.

But I understand that it's been a design accident. However, it wouldn't harm
to also add this interface to the Document class, too.

Best regards,
Axel



----------------
+ACI-Boris Zbarsky+ACI- schrieb im Newsbeitrag
news:SLOdnZzjEu4Fyc7QnZ2dnUVZ+AF8-gydnZ2d+AEA-mozilla.org...

On 2/9/11 5:45 PM, Axel Dahmen wrote:
+AD4- At +ACI-http://www.howtocreate.co.uk/tutorials/javascript/domcss+ACI- I just
+AD4- read that the getComputedStyle() DOM Level 2 Style member function of
+AD4- the ViewCSS interface is a member of the window object.
+AD4-
+AD4- I wonder how it works on a frames based webpage.

Each frame has its own Window object, for what it's worth.

+AD4- Why isn't this interface being applied to the Document object?

Why would it be? How is that better than the Window?

In any case, the DOM spec doesn't define which object the defaultView is
for a Document. It also doesn't define anything about Window objects at
all. The fact that the defaultView is the Window is a historical
accident, but at this point it's a de-facto standard, probably going to
be documented de-jure in HTML5.

-Boris

[Neil Deakin]

Post by Axel Dahmen
Because styles are not a window's property but a document's property. It
wouldn't come up my mind to search in the cupboard for motor oil,
either. That's why.

I think the original intent was that a document might be presented in
multiple ways. For instance, Firefox used to (theoretically) support
displaying the same document in both regular and print preview mode at
the same time. One document, but different styles used for each mode.

Some implementation might also want to replicate that, which is why
getComputedStyle is defined on a 'view' rather than on a document.

[Martin Honnen]

Post by Neil Deakin

Post by Axel Dahmen
Because styles are not a window's property but a document's property. It
wouldn't come up my mind to search in the cupboard for motor oil,
either. That's why.

I think the original intent was that a document might be presented in
multiple ways. For instance, Firefox used to (theoretically) support
displaying the same document in both regular and print preview mode at
the same time. One document, but different styles used for each mode.
Some implementation might also want to replicate that, which is why
getComputedStyle is defined on a 'view' rather than on a document.

And you can have a pure in memory DOM document that is not rendered
anywhere, like an responseXML document or one created from DOMParser or
one created with document.implementation.createDocument. As computing
styles on such documents does not make much sense I think the
document.defaultView
(http://www.w3.org/TR/DOM-Level-2-Views/views.html#Views-AbstractView)
was introduced and that is null for documents like I listed above. For
rendered documents implementors mapped document.defaultView to the
window object. I don't know whether that was the intention of the
authors of the "Document Object Model Views" spec. But it certainly make
sense not to have getComputedStyle exposed on all kind of documents.

[Axel Dahmen]

+AD4- And you can have a pure in memory DOM document that is not rendered
+AD4- anywhere, like an responseXML document or one created from DOMParser or
+AD4- one created with document.implementation.createDocument. As computing
+AD4- styles on such documents does not make much sense I think the
+AD4- document.defaultView
+AD4- (http://www.w3.org/TR/DOM-Level-2-Views/views.html+ACM-Views-AbstractView)
+AD4- was introduced and that is null for documents like I listed above. For
+AD4- rendered documents implementors mapped document.defaultView to the
+AD4- window object. I don't know whether that was the intention of the
+AD4- authors of the +ACI-Document Object Model Views+ACI- spec. But it certainly make
+AD4- sense not to have getComputedStyle exposed on all kind of documents.

Shouldn't this function then return 'undefined' in those cases?

[Boris Zbarsky]

Post by Axel Dahmen
Because styles are not a window's property but a document's property.

That's not true. The same document has different styles depending on
presentation (e.g. when viewing on scree and printing).

-Boris

[Axel Dahmen]

I see... OK, I just wanted to make sure my point of view didn't make sense.

Thanks for enlightening me!