Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Trouble retrieving CSS properties via Javascript

12 views
Skip to first unread message

weston

unread,
Oct 20, 2005, 8:52:56 PM10/20/05
to
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

RobG

unread,
Oct 20, 2005, 9:39:49 PM10/20/05
to
weston wrote:
> 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/comp.lang.javascript/browse_frm/thread/f64ec492a152de81/f7a42159d764d522?q=getcomputedstyle+currentStyle&rnum=1&hl=en#f7a42159d764d522>


[...]


--
Rob

Danny

unread,
Oct 19, 2005, 3:09:36 AM10/19/05
to

Ditto to what RobG said, use getComputedStyle() for mozilla ->
http://developer.mozilla.org/en/docs/Gecko_DOM_Reference:Examples#Example_6:_getComputedStyle
and OBJHERE.runtimeStyle.PROPERTYHERE for IE.


Danny

weston

unread,
Oct 21, 2005, 5:25:23 PM10/21/05
to
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?

Message has been deleted

Thomas 'PointedEars' Lahn

unread,
Oct 21, 2005, 5:37:34 PM10/21/05
to
weston wrote:

Because it's *Cascading* Style Sheets.

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


PointedEars

Michael Winter

unread,
Oct 21, 2005, 6:07:17 PM10/21/05
to
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

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Lasse Reichstein Nielsen

unread,
Oct 21, 2005, 6:11:00 PM10/21/05
to
"weston" <notsew-reversePrec...@canncentral.org> writes:

> 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
--
Lasse Reichstein Nielsen - l...@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

weston

unread,
Oct 21, 2005, 6:58:39 PM10/21/05
to
Lasse Reichstein Nielsen wrote:
> 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 Winter wrote:
> 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?

Thomas 'PointedEars' Lahn wrote:
> Because it's *Cascading* Style Sheets.

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

Lasse Reichstein Nielsen

unread,
Oct 21, 2005, 7:14:35 PM10/21/05
to
"weston" <notsew-reversePrec...@canncentral.org> writes:

> 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).

weston

unread,
Oct 21, 2005, 7:41:29 PM10/21/05
to
Makes sense. I'm convinced.

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

Thomas 'PointedEars' Lahn

unread,
Oct 22, 2005, 7:24:52 AM10/22/05
to
weston wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Because it's *Cascading* Style Sheets.
>
> 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
--
In the First World War, 13 million people were killed. In the Second
World War, 40 million people were killed. I think that if a third war
takes place, nothing is going to be left on the face of earth.
-- Shakira, 2003-02-05 @ MTV.com

weston

unread,
Nov 7, 2005, 8:12:51 PM11/7/05
to
RobG wrote:

> 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/comp.lang.javascript/browse_frm/thread/f64ec492a152de81/f7a42159d764d522?q=getcomputedstyle+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;
}

0 new messages