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

RE: Should IE drop currentStyle/ runtimeStyle?

From: Travis Leithead <travil@microsoft.com>
Date: Tue, 22 Sep 2009 19:21:28 +0000
To: Garrett Smith <dhtmlkitchen@gmail.com>
CC: www-style CSS <www-style@w3.org>, Sylvain Galineau <sylvaing@microsoft.com>, Sharon Cohen <sharco@microsoft.com>
Message-ID: <49142F02149340458FDD20841AD0AD5621D6FAC3@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com>
> -----Original Message-----
> From: Garrett Smith [mailto:dhtmlkitchen@gmail.com]
> On Tue, Sep 22, 2009 at 7:07 AM, 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.)
> >
> [...]
> >
> > 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.
> >
> 
> document.defaultView.getCascadedStyle?
> As in:
> http://lists.w3.org/Archives/Public/www-dom/2000AprJun/0112.html
> 
> ?

Exactly that.

> 
> >
> >
> > Any strong opinions on this matter?
> >
> 
> A strong opinion can be formed by making observations. Using google code
> search to find existing code can reveal usage patterns. When analyzing
> existing code, one can formally or informally write a program with the new
> feature. Often it is obvious just from looking at the code.
> 
> Dropping support for currentStyle and runtimeStyle would break Microsoft-
> only sites and applications.

True, but IE handles legacy compatibility by versioning.

> Gecko, Webkit, Opera, IE all have no implementation of
> document.defaultView.getCascadedStyle. It would just make more work for
> all involved. Those involved included: Microsoft, for working to implement
> getCascadedStyle, Microsoft's business customers, for having to update their
> code, the w3c (who would presumably write up a spec), and the rest of the
> web, .
> 
> Consider how existing code that uses currentStyle (only) would have to
> change to still try to function:-
> 
> var value = "";
> if(document.defaultView) {
> 
>  /// this fails in IE9 and Safari 1 (Safari 1 had a broken implementation).
>   value = document.defaultView.getComputedStyle(el, "").height; } else
> if(el.currentStyle) {
>   value = el.currentStyle.height;
>   }
> }
> 
> to:-
> 
> var value = "";
> if(document.defaultView) {
>   if(document.defaultView.getComputedStyle) {
>     value = document.defaultView.getComputedStyle(el, "").height;
>   } else if(document.defaultView.getCascadedStyle) {
>     value = document.defaultView.getCascadedStyle(el, "").height; } else
> if(el.currentStyle) {
>     value = el.currentStyle.height;
>   }
> }
> 

This makes it seem like developers just want "some" value for a style, but aren't looking specifically for a computed/cascaded value. That's actually what I want to discover--is this true? Are there specific needs to get both the computed value and the cascaded style? Or do developer care?

> 
> Benefits:
> Officially part of a new standard.
> 
> Drawbacks:
> Breaks many sites in ways that probably cannot be easily fixed.
> Makes developing cross-browser applications a lot more work.
> 
> Dropping both runtimeStyle would make it harder for code that attempts to
> make conversion between em|ex|pt|in| to px.
> 
> Garrett
Received on Tuesday, 22 September 2009 19:22:22 GMT

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