By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,156 Members | 962 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,156 IT Pros & Developers. It's quick & easy.

firefox page element without getComputedStyle

P: n/a
I thought that this was available for all elements in Firefox, but
recently had a page where a div didn't have it. I put in an id style
for it, thinking that would do the trick, but it didn't.

Is that something that isn't there for all elements that are correctly
formed, or possibly something that disappears due to malformed HTML? Or
is there any other code-related reason (i.e., mistake) that causes it to
disappear?
Dec 30 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Steve wrote:
I thought that this was available for all elements in Firefox, but
recently had a page where a div didn't have it. I put in an id style
for it, thinking that would do the trick, but it didn't.
Please post the specific code that failed for you, your subject mentions
getComputedStyle but your post does not show us how you tried to use
that and what exactly failed.
--

Martin Honnen
http://JavaScript.FAQTs.com/
Dec 31 '06 #2

P: n/a
Martin Honnen wrote:
Steve wrote:
>I thought that this was available for all elements in Firefox, but
recently had a page where a div didn't have it. I put in an id style
for it, thinking that would do the trick, but it didn't.

Please post the specific code that failed for you, your subject mentions
getComputedStyle but your post does not show us how you tried to use
that and what exactly failed.

Sorry, I guess I have been misusing getComputedStyle. I have been using
it as elt.getComputedStyle(), which actually works for some elements on
my page, as opposed to document.defaultView.getComputedStyle(elt, null).

I suppose a better original question would have been "Why do some
elements have a getComputedStyle method available" as opposed to the
opposite.

But it doesn't matter anyway, as things turned out; what I wanted to
retrieve was the value of 'top' so I could position a hidden div with a
dialog box-looking form at an appropriate spot, but "auto" just isn't
going to cut it for that purpose.
Jan 1 '07 #3

P: n/a
Steve wrote:
Martin Honnen wrote:
>Steve wrote:
>>I thought that this was available for all elements in Firefox, but
recently had a page where a div didn't have it. I put in an id style
for it, thinking that would do the trick, but it didn't.

Please post the specific code that failed for you, your subject
mentions getComputedStyle but your post does not show us how you tried
to use that and what exactly failed.

Sorry, I guess I have been misusing getComputedStyle. I have been using
it as elt.getComputedStyle(), which actually works for some elements on
my page, as opposed to document.defaultView.getComputedStyle(elt, null).

I suppose a better original question would have been "Why do some
elements have a getComputedStyle method available" as opposed to the
opposite.

But it doesn't matter anyway, as things turned out; what I wanted to
retrieve was the value of 'top' so I could position a hidden div with a
dialog box-looking form at an appropriate spot, but "auto" just isn't
going to cut it for that purpose.
A revised question is: why do some elements in Firefox have their own
getComputedStyle() method, taking no arguments and yielding the
properties for that element, while others do not? (I use it to get the
original display property for a table row, so I can put it back to
unhide it.)

And, a bit of a flame -- I realize that might be some value to the
current behavior of the more global getComputedStyle, but:

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.
Jan 5 '07 #4

P: n/a
VK

Steve wrote:
Sorry, I guess I have been misusing getComputedStyle. I have been using
it as elt.getComputedStyle(), which actually works for some elements on
my page, as opposed to document.defaultView.getComputedStyle(elt, null).
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).font Size;
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.
</speculation>

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

Jan 5 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.