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

Re: Should IE drop currentStyle/ runtimeStyle?

From: Anne van Kesteren <annevk@opera.com>
Date: Thu, 08 Oct 2009 11:08:58 +0200
To: "Travis Leithead" <travil@microsoft.com>, "www-style CSS" <www-style@w3.org>
Cc: "Sylvain Galineau" <sylvaing@microsoft.com>, "Sharon Cohen" <sharco@microsoft.com>
Message-ID: <op.u1g408ug64w2qv@annevk-t60>
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 Thursday, 8 October 2009 09:09:36 GMT

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