[whatwg] New method for obtaining a CSS property

[Boris Zbarsky]

On 1/28/11 4:01 AM, Brett Zamir wrote:
> Since I'm speaking more or less about a literal match, this would be
> basically the same as you are saying. In any case, I think you get my
> point.

I'm not quite sure I do.  It sounds like you want to piggyback on CSS to 
introduce a variable system of some sort (without changing any CSS 
syntax) that has non-CSS semantics (in that it's not cascading) and hope 
that it magically plays nice with CSS somehow.  Is that a correct 
characterization?

>> Defining these could really get pretty complex, unless you're
>> suggesting that it just be a string compare of the serializations or
>> something.
> Yes, I am suggesting the latter.

OK, that's clear enough.  It seems like it would be a huge footgun, but....

> Here's the way I've been doing it for my own code; remember all I want
> is the text of the property value associated with an exact selector
> match.

Right, this was the part I wasn't getting before, because it seemed so 
bizarre and failure-prone.

>> Why would you need to create a pseudo document?
>
> Since my purpose is only to get the property value for an exact selector
> match, I'm not interested in getting a different match if a particular
> element say matches "E > F.class" rather than just "F.class". A user in
> such a use case does not care about, and probably doesn't want to face
> ambiguities raised by context.

OK, but you can just create a single element, then.  You don't need a 
"pseudo document".

>> Ideally, yes, but setting styles directly from script (as opposed to
>> setting classes that are then styled by the stylesheet) is not exactly
>> "best practices", unless we're looking at different best practices lists.
>
> Sometimes it is not possible to do this, which is the reason for this
> suggestion (even if CSS transitions could reduce the need for this
> somewhat):
>
> var element = document.getElementById('start-transition'),
> successColor = getCSSPropertyValue('.transition-success',
> 'background-color'),
> failureColor = getCSSPropertyValue('.transition-failure',
> 'background-color');
> indicateSuccessOrFail(element, successColor, failureColor);
>
> function doFunkyTransition (element, beginColor, endColor) {
> // Base on RGB values of beginColor and endColor, incrementally
> // set the color style property of the element to the intermediate color
> // in whatever manner one wishes; more advanced cases could
> // be pulsating between colors, etc.
> // We can't practically devise classes for each of the many
> // intermediate steps of our custom transition
> }

This use case seems to be quite easily addressed if you set those 
classes on the element, get computed style to determine those two 
colors, and then interpolate.

And as you said, this is becoming less and less needed as we introduce 
CSS transitions (and the various animation facilities being worked on, 
if you need more timing control).

Transitions will be shipping in a good chunk of UAs way before any 
changes we want to make here would.

I should also note that in _this_ case you might in fact care about the 
context, esp. if the before/after states are supposed to match 
.transition-success and .transition-failure when applied to "element".

-Boris