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

Re: Should IE drop currentStyle/ runtimeStyle?

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Mon, 12 Oct 2009 16:57:35 -0700
Message-ID: <c9e12660910121657o2c2d4a2kd3d4d9bf210d0522@mail.gmail.com>
To: Travis Leithead <travil@microsoft.com>
Cc: "rfink@readableweb.com" <rfink@readableweb.com>, Anne van Kesteren <annevk@opera.com>, www-style CSS <www-style@w3.org>, Sylvain Galineau <sylvaing@microsoft.com>, Sharon Cohen <sharco@microsoft.com>
On Mon, Oct 12, 2009 at 9:54 AM, Travis Leithead <travil@microsoft.com> wrote:
> Thanks for all the discussion. After this external feedback, as well as internal feedback, it looks like currentStyle and runtimeStyle will stick around for the foreseeable future.
>

You did not answer any of the questions and you top posted.

Hardly seems like a discussion to me.

Garrett

>
> -----Original Message-----
> From: Richard Fink [mailto:rfink@readableweb.com]
> Sent: Saturday, October 10, 2009 1:21 PM
> To: 'Anne van Kesteren'; Travis Leithead; 'www-style CSS'
> Cc: Sylvain Galineau; Sharon Cohen
> Subject: RE: Should IE drop currentStyle/ runtimeStyle?
>
> Thursday, October 08, 2009 Anne van Kesteren <annevk@opera.com>:
>
> Re - your response to Travis Leithead and his original question:
>
>> >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.)
>
> Anne, Travis, Sylvain, Sharon,
>
> Firstly, runtimeStyle sees quite a bit of use in JavaScript libraries because a property set using runtimeStyle has more "weight" than one set using style. This is useful in cases where the underlying HTML is unknown and might contain inline styles. It is simply quicker and easier to override the existing value of the affected currentStyle property, whatever it might be, than to find out what it currently is and change it using a style property. Also, if a particular currentStyle property has been set using an !important declaration in the CSS, without runtimeStyle, the developer is stuck with creating a stylesheet containing rules with more specificity to effect the desired changes. With runtimeStyle that isn't necessary. It's more direct.
> Further, using style and runtimeStyle in tandem provides a handy storage and fallback mechanism. I've often used the style object to store an element's currentStyle property (or properties) while effecting changes using runtimeStyle. The value of the style property then becomes a kind of "fallback" value to which you can revert either by nulling out the runtimeStyle value or setting it the same as the style property value.
> el.style.fontSize=el.currentStyle.fontSize
> el.runtimeStyle.fontSize='12px'; // at this point the initial fontSize has been stored in style.fontSize but it's the runtimeStyle.fontSize that is applied.
> Also, using a for...in loop with the currentStyle object provides a handy way to grab all the CSS properties applicable and currently being applied to an element. (Not an everyday use-case, but I've done it on occasion.)
> As an overarching style-manipulation system, style/currentStyle/runtimeStyle, is extremely easy to understand.
> The style and runtimeStyle objects map well mentally to the way the CSS cascading order and specificity work:
> *style* is the equivalent of hard-coding an inline style.
> *runtimeStyle* has more weight and "overrides" all other settings, including rules using the !important declaration.
> *currentStyle* describes itself.
>
> I've often been frustrated that no equivalent to the runtimeStyle object (overrideStyle?) object exists in other browsers besides Opera.
> I believe that if an "overrideStyle" object like runtimeStyle was available in Firefox and other browsers it would see substantial use. I also believe that its absence is creating more work for developers since, in many cases, the only recourse is to create a stylesheet and accompanying rules.
>
> I offer this in the hope that any changes you make will not remove any of the existing functionality that these objects provide. And in the hope that equivalent options appear in other browsers besides Opera. Scripters have little enough as it is!
>
> Cheers,
>
> Rich
>
> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Anne van Kesteren
> Sent: Thursday, October 08, 2009 5:09 AM
> To: Travis Leithead; www-style CSS
> Cc: Sylvain Galineau; Sharon Cohen
> Subject: Re: Should IE drop currentStyle/ runtimeStyle?
>
> 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 Monday, 12 October 2009 23:58:12 GMT

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