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

Re: Proposal: getStyleAs(property, primitiveValue)

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Tue, 22 Sep 2009 18:08:57 -0700
Message-ID: <c9e12660909221808q35d7eaddj382a7f1b79ef31b3@mail.gmail.com>
To: Travis Leithead <travil@microsoft.com>
Cc: www-style <www-style@w3.org>
On Tue, Sep 22, 2009 at 11:51 AM, Travis Leithead <travil@microsoft.com> wrote:
>> 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".

The API would be capable of converting. The native conversion should
be faster than doing the calculation manually.

When the value was set as "auto" or "inherit", and the program wants
some sort of calculated value (in em, px, etc), the program is faced
with either changing the CSS or trying to make determination of what
the value is, in that unit.

In the case of reading a style value in the unit it was set (the
common case), how would that be any less performant than reading the
"cascaded" value?

What I mean is, given:

  div#breem {
    width: 100px;
  }

  var breem = document.getElementById("breem");
  document.defaultView.getCascadedStyle(breem, "").width; // [1].
  breem.getStyleAs("width", "px"); // [2].

Can you explain the performance benefit that [1] could leverage which
would be unavailable to [2]?

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

A discussion about long method names came up, and the issue was enough
to warrant a discussion for consideration of creating alias for
"targ.addEventListener" to "targ.listen", saving 11 characters.

The document.defaultView.getComputedStyle does seem longer than
necessary. It also puts the focus on a "document.defaultView"
middleman. It also requires another call to [[Get]].

I agree that it is not as strong an argument as the argument the first
one, though I do think it is completely invalid (which is why I
mentioned it).

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

I am not either.

>>  * 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?

Yes, though another approach might be instead have a method right on
CSSStyleDeclaration. For example:

x.style.getValueAs("z-index", "NUMBER");

> I also assume that getStyleAs can return a plethora of possible values from strings to other interfaces...
>

I was thinking it would return a string although |asNumber| param
might a possibility:-

x.getStyleAs("length", "px", "number");

Returns a number representing the length, in css pixels.

Garrett
Received on Wednesday, 23 September 2009 01:09:38 GMT

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