Trouble retrieving CSS properties via Javascript

W

weston

I could swear that I've done this before, but suddenly, I seem to be
unable to retrieve the values of CSS properties via Javascript.

For example, take this document:

http://weston.canncentral.org/web_lab/fetching_css_props_via_js/testcase.html

The document is pretty simple. There's a div id'd as "maindiv". It's
got a few CSS properties set on it via an external stylesheet:

#maindiv {
margin: 5% auto;
width: 200px;
height: 200px;
text-align: center;
font-size: 16px;
font-family: arial;
font-weight: bold;
background-color: white;
}

And what I'd like to be able to do, is grab those properties (say, an
element's CSS-defined height) via javascript, using something like
this:

id = 'maindiv';
emt = document.getElementById(id);
emt_height = emt.style.height;

Except this doesn't seem to be working for me. If you click on the
positioned white div in the above document, and compare the source with
the produced output, you'll see what I mean.

Have I just been imagining that you can retrieve these settings, or is
there something I'm doing wrong in this case?

Thanks,

Weston
 
R

RobG

weston said:
I could swear that I've done this before, but suddenly, I seem to be
unable to retrieve the values of CSS properties via Javascript.

For example, take this document:

http://weston.canncentral.org/web_lab/fetching_css_props_via_js/testcase.html

The document is pretty simple. There's a div id'd as "maindiv". It's
got a few CSS properties set on it via an external stylesheet:

#maindiv {
margin: 5% auto;
width: 200px;
height: 200px;
text-align: center;
font-size: 16px;
font-family: arial;
font-weight: bold;
background-color: white;
}

And what I'd like to be able to do, is grab those properties (say, an
element's CSS-defined height) via javascript, using something like
this:

id = 'maindiv';
emt = document.getElementById(id);
emt_height = emt.style.height;

Except this doesn't seem to be working for me. If you click on the

The element's style object shows the styles that have been applied
directly to the element's style, not those that are inherited. Use
currentStyle for IE and getComputedStyle for other DOM 2 browsers.

There is a Martin Honnen post here that should help:

<URL:http://groups.google.co.uk/group/co...le+currentStyle&rnum=1&hl=en#f7a42159d764d522>


[...]
 
W

weston

Quite helpful indeed. Thank you.

But I'm really more than a little puzzled as to why the IE and Moz
developers chose to multiply entities and store the computed style
somewhere else. If it's going to be computed and stored (as it
obviously has to be for rendering purposes), why not keep it in what
would seem to be the intuitive place -- the style property of the
object?
 
T

Thomas 'PointedEars' Lahn

weston said:
But I'm really more than a little puzzled as to why the IE and Moz
developers chose to multiply entities and store the computed style
somewhere else. If it's going to be computed and stored (as it
obviously has to be for rendering purposes), why not keep it in what
would seem to be the intuitive place -- the style property of the
object?

Because it's *Cascading* Style Sheets.

<http://www.w3.org/TR/CSS2/cascade.html#cascade>


PointedEars
 
T

Thomas 'PointedEars' Lahn

weston said:
But I'm really more than a little puzzled as to why the IE and Moz
developers chose to multiply entities and store the computed style
somewhere else. If it's going to be computed and stored (as it
obviously has to be for rendering purposes), why not keep it in what
would seem to be the intuitive place -- the style property of the
object?

Because it's *Cascading* Style Sheets.

<http://www.w3.org/TR/CSS2/cascade.html>


PointedEars
 
M

Michael Winter

On 21/10/2005 22:25, weston wrote:

[snip]
If [style data is] going to be computed and stored (as it obviously
has to be for rendering purposes), why not keep it in what would seem
to be the intuitive place -- the style property of the object?

The style object of any given element represents the in-line style
declarations applied to that element. It is equivalent to the style
attribute, so it would be inappropriate for it to reflect computed values.

Mike
 
L

Lasse Reichstein Nielsen

weston said:
But I'm really more than a little puzzled as to why the IE and Moz
developers chose to multiply entities and store the computed style
somewhere else.

They didn't. The way to find the computed style of an element, as well
as what the "style" property of an element means, was decided by the
W3C.

The IE developers did make the computed style available on the element
as the "currentStyle" property. The Mozilla developers just followed
the W3C standard (W3C DOM level 2 Style, ECMAScript binding).
If it's going to be computed and stored (as it obviously has to be
for rendering purposes), why not keep it in what would seem to be
the intuitive place -- the style property of the object?

Because the "style" property of DOM elements corresponds to the "style"
attribute of HTML elements, and that's not the same as the computed
style.

/L
 
W

weston

Lasse said:
They didn't. The way to find the computed style of an
element, as well as what the "style" property of an
element means, was decided by the W3C.

OK. So the developers didn't decide it... the W3C did.
I'm still struggling with the rationale -- it still seems
like an uneccesary multiplication of entities to me.

And multiplication of entities gives browser builders
opportunities to do more things differently. ;)

Michael said:
It is equivalent to the style attribute, so it would be
inappropriate for it to reflect computed values.

It might break that particular meaning somewhat, but it
would be very convenient and more compact.

And I'm not convinced the one-to-one equivalence of that meaning
is particularly important. I see the scope of the correspondence
now that it's been pointed out to me, but I didn't have any trouble
concieving the style object as holding *all* the styles applied
to and computed for the element. In fact, that seems to be the
most intuitive reading to me.

The only really good reason I can think of for separating
the two is if there would be some kind of mismatch or collision
between computed/applied styles and inline styles. Is there
a case where this happens?
Because it's *Cascading* Style Sheets.

I'm missing the meaning of the koan, perhaps. :)
 
L

Lasse Reichstein Nielsen

weston said:
The only really good reason I can think of for separating
the two is if there would be some kind of mismatch or collision
between computed/applied styles and inline styles. Is there
a case where this happens?

Several.

If the inline style is, e.g., "margin-left: auto", the computed style
will have a margin-left that is the actual pixel count that the
computation yields.

Likewise, a relative size like "font-size:120%", will be computed to a
fixed font-size based on the inherited value that 120% is relative to.


If a style higher in the cascade has a rule like:
body { font-size: 1em !important; }
and the inline style is
<body style="font-size:80%">
then the computed style will have a font-size of 100% (actual example,
I have that rule in my user stylesheet, and too many pages to count
tries to make the body font smaller).


/L
 
W

weston

Makes sense. I'm convinced.

Even though I still find the whole affair inconvenient. *sigh*
 
T

Thomas 'PointedEars' Lahn

weston said:
I'm missing the meaning of the koan, perhaps. :)

The cascade makes all the difference, as Lasse explained.
You would have known if you had followed the link.


PointedEars
 
W

weston

RobG said:
The element's style object shows the styles that have been applied
directly to the element's style, not those that are inherited. Use
currentStyle for IE and getComputedStyle for other DOM 2 browsers.

There is a Martin Honnen post here that should help:
<URL:http://groups.google.co.uk/group/co...le+currentStyle&rnum=1&hl=en#f7a42159d764d522>

Hmmm. OK, now I'm trying to get the computed height of a div that has
no height explicitly set. Using getComputedStyle on the DOM 2 browsers,
I'm able to retreive this, but under IE, currentStyle seems to be
giving me 'auto'.

I've sortof solved the problem in a stopgap manner by using IE's
offsetHeight property, but I'm wondering if there's a better way.

Here's the functions in which I've buried the
currentStyle/getComputedStyle details. If I'm mis-using currentStyle or
there's a better way, let me know.

function getCompdStyles(emt)
{
var ownerDoc,defaultView;
var returnVal = false;

if(emt)
{
if(emt.currentStyle) // IE
{ returnVal = emt.currentStyle; }
else if ( // DOM 2
(ownerDoc = emt.ownerDocument) &&
(defaultView = ownerDoc.defaultView) &&
(defaultView.getComputedStyle)
)
{ returnVal = defaultView.getComputedStyle(emt,''); }
}

return returnVal;
}

function getCompdStyle(emt,cssprop)
{
var compdStyleObj = getCompdStyles(emt);
if(compdStyleObj)
return compdStyleObj[cssprop];
else
return null;
}
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top