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