[cssom-values] Possibility of patching existing CSS strings into Values objects?

I've been thinking about the CSSOM Values API today, since SVG is
wanting to do essentially the same thing for its attributes.  One of
the downsides of it is that we need to expose the Value objects as
something separate, because we currently always return strings.

How realistic is it to change the type of attributes like
el.style.color from DOMString to a CSSValue, where CSSValue has a
stringifier and the attribute has a [PutForwards] on it?

This would preserve most of the interactions that you can have today.
You can set attributes to a string still, or compare them with a
string literal.  If you do anything that coerces the value into a
string first, you can then operate on it with string operations.

Things you lose:
1. You can't directly compare the object anymore - "el.style.color ==
el.style.backgroundColor" will be guaranteed false, as they're
different objects.
2. You can't use string operations directly on the object -
"el.style.color.slice(5, 10)" will fail.
3. If, for some reason, you're directly type-testing the value, it'll
fail, as you now have an object rather than a string.

I think #2 actually has some good compat risk, but we can get around
it by directly adding all the String methods to CSSValue, defined as
operating on the string representation and returning strings, and by
adding indexed getters that retrieve characters from the string
representation.  This feels hacky, but we do this kind of manual
core-class emulation already in WebIDL with [MapClass]; adding a
[StringClass] might not be too bad of an idea.

TC39 is also looking into adding operator overloading to JS, so you
can change equality.  This might be something we can hook into when
that happens.

Thoughts?

~TJ

Received on Thursday, 8 August 2013 23:19:06 UTC