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

Re: Should IE drop currentStyle/ runtimeStyle?

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Tue, 22 Sep 2009 13:54:46 -0700
Message-ID: <c9e12660909221354t4f1faaf2y159f800fc078446@mail.gmail.com>
To: Travis Leithead <travil@microsoft.com>
Cc: www-style CSS <www-style@w3.org>, Sylvain Galineau <sylvaing@microsoft.com>, Sharon Cohen <sharco@microsoft.com>
On Tue, Sep 22, 2009 at 12:21 PM, Travis Leithead <travil@microsoft.com> wrote:
>> -----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.

OK, so we could have an "IE8" mode, then? I'm not sure I like that
idea, because this has the type of problem where, say, a program might
want to get a feature or bugfix that was in IE9 but can't get that
because it is in IE8 mode.

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

[snip example]

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

There are needs to get a computed value. The value should be
consistent (unit, or otherwise).

A cascaded value could be useful the value is "auto" or "inherit", but
in that case, it would still want to be an absolute value that is

The type of situations I've found useful for reading styles:-
 * animation to a certain value, starting from the current value,
(opacity, color, width, etc)
 * drag and drop: to know the z-index or position values (this allows
the API to be flexible enough to allow for relative or absolute
 * toggle a style value (is the object visible?)
 * read a border width to determine element dimensions (clientTop and
clientLeft are recent additions in some browsers, do not exist in
other browsers, and are only half the picture (no clientBottom or

To perform the above tasks, a program needs to read value that has a
clearly defined unit or value measurement (for things like
font-weight, z-index, border-width). A value "inherit" or "auto" is
bad because it requires the program perform traversal up the parent

To do this, programs can rely on using only px, and this includes in CSS.

The problems with solutions that use currentStyle and
getComputedStyle, as L pointed out, is that reading consistent values
requires using px only in the CSS.

Things like borderWidth, which may result in "medium" in IE. The
problem with that is that the "medium" border width might be a 0 width
border where the borderStyle is none:



For "length" or the unspecified "positive length" (border, padding),
px can mostly work.

Received on Tuesday, 22 September 2009 20:55:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:39 UTC