- 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