RE: Should IE drop currentStyle/ runtimeStyle?

Thursday, October 08, 2009 Anne van Kesteren <annevk@opera.com>:

Re - your response to Travis Leithead and his original question:

> >We (the IE team) are _considering_ dropping support for currentStyle and  
> >runtimeStyle in our next most "standards compliant" mode. However,  
> >because there is interest in this space (via the CSSOM spec [1], we  
> >wanted to get a feel for whether other browsers are considering  
> >implementing these APIs or not. (We see that Opera has an  
> >implementation.)

Anne, Travis, Sylvain, Sharon,

Firstly, runtimeStyle sees quite a bit of use in JavaScript libraries because a property set using runtimeStyle has more "weight" than one set using style. This is useful in cases where the underlying HTML is unknown and might contain inline styles. It is simply quicker and easier to override the existing value of the affected currentStyle property, whatever it might be, than to find out what it currently is and change it using a style property. Also, if a particular currentStyle property has been set using an !important declaration in the CSS, without runtimeStyle, the developer is stuck with creating a stylesheet containing rules with more specificity to effect the desired changes. With runtimeStyle that isn't necessary. It's more direct.
Further, using style and runtimeStyle in tandem provides a handy storage and fallback mechanism. I've often used the style object to store an element's currentStyle property (or properties) while effecting changes using runtimeStyle. The value of the style property then becomes a kind of "fallback" value to which you can revert either by nulling out the runtimeStyle value or setting it the same as the style property value.
el.style.fontSize=el.currentStyle.fontSize
el.runtimeStyle.fontSize='12px'; // at this point the initial fontSize has been stored in style.fontSize but it's the runtimeStyle.fontSize that is applied.
Also, using a for...in loop with the currentStyle object provides a handy way to grab all the CSS properties applicable and currently being applied to an element. (Not an everyday use-case, but I've done it on occasion.)
As an overarching style-manipulation system, style/currentStyle/runtimeStyle, is extremely easy to understand.
The style and runtimeStyle objects map well mentally to the way the CSS cascading order and specificity work:
*style* is the equivalent of hard-coding an inline style.
*runtimeStyle* has more weight and "overrides" all other settings, including rules using the !important declaration.
*currentStyle* describes itself.

I've often been frustrated that no equivalent to the runtimeStyle object (overrideStyle?) object exists in other browsers besides Opera.
I believe that if an "overrideStyle" object like runtimeStyle was available in Firefox and other browsers it would see substantial use. I also believe that its absence is creating more work for developers since, in many cases, the only recourse is to create a stylesheet and accompanying rules.

I offer this in the hope that any changes you make will not remove any of the existing functionality that these objects provide. And in the hope that equivalent options appear in other browsers besides Opera. Scripters have little enough as it is!

Cheers, 

Rich

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Anne van Kesteren
Sent: Thursday, October 08, 2009 5:09 AM
To: Travis Leithead; www-style CSS
Cc: Sylvain Galineau; Sharon Cohen
Subject: Re: Should IE drop currentStyle/ runtimeStyle?

On Tue, 22 Sep 2009 16:07:30 +0200, Travis Leithead <travil@microsoft.com>  
wrote:
> We (the IE team) are _considering_ dropping support for currentStyle and  
> runtimeStyle in our next most "standards compliant" mode. However,  
> because there is interest in this space (via the CSSOM spec [1], we  
> wanted to get a feel for whether other browsers are considering  
> implementing these APIs or not. (We see that Opera has an  
> implementation.)
>
> I see some benefits to keeping them and a few drawbacks:
>
>
>
> Benefits to keeping currentStyle/ runtimeStyle
>
> * easy to use API (style object directly available via an element)
>
> * [currentstyle] provides a view of the CSS cascaded values that has  
> been identified to be useful (in addition to computed values)
>
> * [runtimestyle] provides an equivalent to getOverrideStyle (not widely  
> implemented)

I agree both are useful. runtimeStyle is quite nice to have for doing  
animations through scripting.


> Drawbacks to keeping currentStyle/ runtimeStyle
>
> * it's an unwanted code branch detection point used to identify IE (and  
> Opera too)
>
> * [currentstyle] is not the same as getComputedStyle values, and  
> translations between the two are hard
>
> * currentStyle/ runtimeStyle cannot handle psuedo-elements (the existing  
> ones and any possible new ones)

I don't think that is much of a problem though I suppose there should be  
some way to access pseudo-elements too. I don't think getComputedStyle is  
the right kind of API in all cases though since pseudo-elements are not  
always specific to elements. E.g. consider ::selection.


> _IF_ we are to drop support for these, we'd want to provide a more  
> "standards compliant" replacement, for which:
>
> runtimeStyle -> getOverrideStyle
>
> currentStyle -> ??
>
> Given existing API design precedent, it seems logical to create a  
> "getCascadedStyle" API that would replace "currentStyle" in the  
> future--it can handle pseudo-elements and would be similar to related  
> style APIs of which web developers are already familiar.
>
> Any strong opinions on this matter?

If we introduce a better API I'd like it to also support some convenient  
API going forward. Though maybe we can do that by making it return objects  
which stringify to the right value.


> [1] http://dev.w3.org/csswg/cssom/ (is there a later version of this  
> editor's draft?)

No, there is not. What is needed is sorting out of getComputedStyle  
including how it works for all the various CSS properties (since computed  
style is no longer the same in CSS 2.1) and filling out most of the red  
boxes. Once that is done I suppose it will be easier to figure out how to  
do additions. I haven't found anyone willing to take up this job though in  
the past two years.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Saturday, 10 October 2009 20:29:48 UTC