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
