- Hi Ryan,
The rationale behind having wrappers for the style interface
(Dom.setStyle, Dom.getStyle) is because getting the initial style values
can be difficult. When a style is set via the "style" property
(element.style.width = '20em'), the style property always returns the
actual value. The same goes for styles set inline (<div
style="width:10em"...). However, if a style is not set via either
"element.style" or "<element style=...", an empty string is returned.
Our only choice at this point is to either parse the stylesheet or get
using some other method(s). Parsing the stylesheet has performance
limitations, so we really can only rely on other methods; namely
currentStyle and computedStyle.
CurrentStyle enables embedded or linked/imported styles to be queried in
the same fashion (what you set is what you get, regardless of setter
interface). As you point out, one downside is that it does not compute
values for unset style properties the way that computedStyle does, and
returns 'auto' in some cases. This also introduces browser
inconsistencies which may require some additional work to resolve.
ComputedStyle returns the computed value that the browser uses to render
the style. Although this may be helpful in some cases, I would argue
that it is not really what we want from getStyle.
Opera 9 has complicated this by adding support for currentStyle, but
unlike IE, it returns computed values rather than actual values. Also,
as your example demonstrates, when the "height" property is not set,
Opera returns "-2147483648px" rather than "auto".
I agree that we should protect against this by ensuring that Opera
always return computedStyle. However, if Opera 9 emulated IE by
returning the actual style values regardless of setter interface, I
would argue in favor of continuing to check currentStyle first.
Thanks for bringing this up.
Ryan Cannon wrote:
>I've searched through the archives a little bit, and haven't found
>much, but I've had a difficult time getting around problems with the
>Dom.getStyle function. Specifically, el.currentStyle and
>document.defaultView.getComputedStyle *do not* return the same kinds
>of values when some properties are not explicitly set. Right now
>I'm working on a patch/workaround for my own site, but I do have one
>When I grok the code for Dom.getStyle, it appears the script does the
>check if node.style[property] exists, and uses it if it does;
>that failing, it looks for node.currentStyle[property] (IE DOM
>that failing, it looks for document.defaultView.getComputedStyle
>(node) (W3C DOM)
>Why is the non-standard DOM extension checked first? It supplies
>values, such as 'auto'. Browsers that support both functions (Opera,
>have the ability to avoid these headaches (and the extra cycles to
>get around them)
>but don't because of the order in which they are checked.