The CSSOM draft defines a whole lot more serialization details now, though I have not filled in all the red boxes yet. In part this is because it is somewhat boring work, but there are also some open questions. E.g. whether to serialize <color> values as it is done for the <canvas> element (using the hexadecimal notation) or using the rgb() notation so we can represent more than 255 values per component.
Another thing I have wanted to start tackling for a while now is CSS value APIs (see also W3CTP: CSSOM). The initial idea was to invent some new kind of DOMString, but a long discussion with the ECMAScript guys ruled that out. It would likely break too much deployed scripts.
The new idea is to introduce a values attribute on CSSStyleDeclaration that returns a CSSStyleDeclarationValue object which is in all respects equivalent to CSSStyleDeclaration except that the CSS property attributes return CSSValue objects. Potentially special CSSValue objects if it is deemed worth of a proper interface. E.g. for the 'color' property a CSSValue object would be returned that also implements CSSColorValue. The eventual result is something like this:
elt.style.values.color.alpha -= .1(There are quite a few problems to be sorted out before this is done. Hopefully I can make some progress on that tomorrow.)
Thanks for working on this stuff!
Would be great, in fact.
In ECMAScript everything is a potential object.
Why not make elt.style.color a CSSColor object?
CSSColor {
toString() { returns value }
red: integer
green: integer
blue: integer
alpha: floating
}
See the long discussion referenced in the post. That was the initial plan, but it was deemed that it would break too much. E.g. instanceof or the in operator.