- 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>
> -----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 UTC