W3C home > Mailing lists > Public > www-style@w3.org > September 2009

RE: Proposal: getStyleAs(property, primitiveValue)

From: Travis Leithead <travil@microsoft.com>
Date: Tue, 22 Sep 2009 18:51:32 +0000
To: Garrett Smith <dhtmlkitchen@gmail.com>, www-style <www-style@w3.org>
Message-ID: <49142F02149340458FDD20841AD0AD5621D6F9C7@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com>
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On
> Behalf Of Garrett Smith
> 
> Travis Leithead recently brought up the issue of reading styles again and it
> certainly is a pain point. There really is no good API for reading a style value.
> 
> Scripts frequently have to deal with this task and use a combination of the
> "standard" method and the "IE/currentStyle" approach to (try
> to) get a style value consistent across browsers and often make use of IE's
> |runtimeStyle| property to do conversion of whatever currentStyle returns
> to px.
> 
> A solution that is based on two different APIs does not work very well. The
> standard document.defaultView.getComputedStyle and IE currentStyle both
> have problems of their own.
> 
> * document.defaultView.getComputedStyle
>   * Too generic. The "absolute value" description is not nailed down.

I thought that the CSS 2.1 spec made this pretty clear for each property.

>   * Not flexible enough: A program that wants the unit in px or em or rgb or
> hex, etc, does not have that option.

True. Being able to get the value type that you want from the engine might use useful... I just don't know if its possible (or rather performant) to compute that data as it doesn't cache to a state of the CSS cascade very well (CSS cascades down from these relative units to absolute units--your API appears to want to extract an arbitrary value type from an "actual value".

>   * Too verbose. The defaultView is unrelated to the Element (the DOM spec
> says: "a computed style is related to an Element node").

I don't find this to be a strong argument, since the element is passed as param 0 to the existing "standards-based" style APIs that are not on an element. For frequent uses, just create an alias or wrapper to the API name.

> Verbosity is not such a problem with operations that don't occur frequently
> throughout the code. Reading styles is a common task.
> 
> * currentStyle.
>  * Not flexible enough. A program gets the value set in the stylesheet. If the
> stylesheet has EM or auto or %, then that value
>   is returned.

Also, no pseudo-element support (not sure how crucial this is)...

>  * simple and directly on the element.
> 
> New Proposal:
> var height = x.getStyleAs("height", "px"); height = parseInt(height, 10);
> 
> For color:-
> var color = x.getStyleAs("color", "rgba");
> if(!color) {
>   // failed.
>   color = x.getStyleAs("color", "rgb");
> }

I assume x == Element?
I also assume that getStyleAs can return a plethora of possible values from strings to other interfaces...

> 
> This addresses the problem of reading a style value. The primitiveValue is
> defined in the relevant CSS specification for the property.
> 
> A corresponding method to set a value would not seem to be necessary, as
> any value could be set with:
> 
> x.style.color = "papayawhip";
> 
> Garrett
> 
Received on Tuesday, 22 September 2009 18:52:27 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:21 GMT