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

[cssom] moving forward on .usedStyle

From: Mike Sherov <mike.sherov@gmail.com>
Date: Sun, 13 Oct 2013 19:19:07 -0400
Message-ID: <CAD1Dv_Kk2hdcuVx4_9gPYan8=phfyB0HAAFodrck0-8eD6Mm+w@mail.gmail.com>
To: "www-style@w3.org" <www-style@w3.org>
We're seeing more and more of this pop up: people confusing "computed
value" with "resolved value", because we're still mainly at the mercy of

We have .usedStyle, .rawComputedStyle, and .cascadedStyle...

.cascadedStyle and .rawComputedStyle should be easy enough to implement:
cascaded value is easy, because it's just the result of resolving the
cascade. computed value is also easy enough, considering there's a
normative definition for computed value for every property.

However, there is currently a bit of a stall on implementing the
.usedStyle interface:

I'd like to discuss the current roadblocks for .usedStyle, with the hopes
of reaching conclusions on each blocker so we can move forward.

1. What do we do when a property doesn't apply: For example, 'flex-basis'
only applies to flex items. If you're not a flex item, we can't figure out
what "auto" should resolve to, since you don't have a corresponding flex
container with a 'flex-direction' value.

The current proposals say return empty string, null, or copy the value from
computed value. I believe Tab and myself prefer empty strings.

2. What to do when a property was defaulted or its computed value is
determined by a different property: For example, I set {position:absolute;
left:1px;} and that makes the computed value of "right" be "50px ".

In this case, my opinion would be that the used value would be an empty
string, or "auto". I'd like some feedback on this one.

3. The fact remains that "used value" lacks normative definitions for
specific value types and/or specific properties.

I can say that it seems like any property that has a <length> value type
should have a "px" value as its used value, but again, I'm not confident in
this and I'm calling on this body to help uncover caveats to that statement.

4. There is a yet-to-be-defined values API that Tab and Fantasai have been
mulling over that may obviate the need for .usedStyle at all.

I'm a fan of this, but I'd like to see a draft spec, and contribute in
whatever way I can (tests, etc.). I'm generally concerned that we JS folk
still don't have a good lossless API for style information, and I'm
concerned deferring this API until we get a values API just kicks the can
down the road farther.

Mike Sherov
Chief Technologist
SNAP Interactive, Inc. | Ticker: STVI
http://snap-interactive.com | http://ayi.com
Received on Sunday, 13 October 2013 23:19:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:03 UTC