firefox getComputedStyle().width returning auto

[petermichaux]

Hi,

I'm curious why the follow little HTML page produces "auto" for
JavaScript output. I thought that getComputedStyle() was supposed to
return integer px values for lengths. Is this a problem specific to
firefox?

Thanks,
Peter


<ul>
<li style="display:inline;" id="id1">test</li>
</ul>
<script>

document.write(window.getComputedStyle(document.getElementById('id1'),null).width);
</script>

 

[Jonas Raoni]

Hi,

I'm curious why the follow little HTML page produces "auto" for
JavaScript output. I thought that getComputedStyle() was supposed to
return integer px values for lengths. Is this a problem specific to
firefox?

Thanks,
Peter


<ul>
<li style="display:inline;" id="id1">test</li>
</ul>
<script>

document.write(window.getComputedStyle(document.getElementById('id1'),null).width);
</script>

I don't think it's a Firefox mistake, since the objective of this
"getComputedStyle" is to retrieve the CSS value, and the width value is
"auto" on this case, since you haven't specified anything for it ;]

To get the width in pixels, use:

element.offsetWidth

 

[petermichaux]

I've read several places that getComputedStyle() is a way to determine
the pixel location of an element relative to the window. However the
following produces "auto".

<p id='id1'>tester</p>
<script>
document.write(window.getComputedStyle(document.getElementById('id1'),
null).top);
</script>

What's happening?

Thanks,
Peter

 

[Michael Winter]

On 23/02/2006 05:43, (e-mail address removed) wrote:

[snip]

I thought that getComputedStyle() was supposed to return integer px
values for lengths.

The computed style object is supposed to return absolute values.
Strictly speaking, pixels are relative units (they vary with hardware
and settings), but generally, yes.

Is this a problem specific to firefox?

Perhaps, but that's irrelevant, really. Fx certainly isn't wrong in its
behaviour, here.

<ul>
<li style="display:inline;" id="id1">test</li>
</ul>

The width CSS property doesn't apply to non-replaced, in-line elements.
Therefore, as there isn't actually a value to apply here, 'auto' is
reasonable. Consider:

<p id="paragraph">Some
<span id="mark"
style="width: 1000px;">marked</span>
text.</p>

Clearly, the width of that SPAN element won't be a thousand pixels wide:
the word 'marked' simply isn't long enough, and as I already stated,
that particular declaration shouldn't be applied anyway. However,
obtaining the computed value for that property in Fx will return '1000px'.

If one uses the getComputedStyle method to obtain the width of the P
element, a length value will be returned. The difference here is that as
a non-replaced, block-level element, the width property is applicable
and though its actual value is 'auto', its width can be computed using
the algorithm described in section 10.3.3[1] of the CSS 2 Specification[2].

<script>

This is an example, I know, but still the type attribute is required.

document.write(window.getComputedStyle(document.getElementById('id1'),null).width);

^^^^^^^
There is some debate whether getComputedStyle method should be
referenced using the window (global) object. I would suggest sticking to
the defaultView object, a property of the document object:

document.defaultView.getComputedStyle(..., ...)

Mike


[1] <http://www.w3.org/TR/REC-CSS2/visudet.html#q7>
[2] <http://www.w3.org/TR/REC-CSS2/>

 

[Michael Winter]

I've read several places that getComputedStyle() is a way to
determine the pixel location of an element relative to the window.

In some cases it can be used for that purpose, but not always.

However the following produces "auto".

<p id='id1'>tester</p>
<script>
document.write(window.getComputedStyle(document.getElementById('id1'),
null).top);
</script>

What's happening?

Again, this is a matter of applicability. The offset properties (top,
right, bottom, and left) do not apply to statically positioned elements.
If that P element was relatively or absolutely positioned, one could
obtain a computed value.

Mike