Re: [cssom] draft of color serialization rules

On 10/1/12 11:00 PM, Glenn Adams wrote:
> Frankly, I'm more concerned about defining the value returned for
> specified values rather than computed values.

Unfortunately, web developers most often work with computed values 
(because they're all using JQuery's css() and whatnot)...  So I think 
it's actually more important to define the behavior for computed values.

Or did you mean that there are just more open questions for specified 
values?

> What degree
> of canonicalization do we want for serialization of non-computed, but
> specified value, e.g., should the following hold (for specified style
> set/get)? Or should some canonicalization apply?
>
> elt.style.color = 'black';
> assert_equals(elt.style.color,'black');
> elt.style.color = '#000';
> assert_equals(elt.style.color,'#000');

The real questions here seem to be along the lines of:

1) Do we want to force UAs to store the original string in addition to 
whatever representation they parse into?
2) Do we want to force UAs to parse into an internal representation 
instead of doing so lazily and keeping the original string until they do?

Basically, how much are we willing to overconstrain memory and 
performance characteristics of implementations here?

It would be interesting to know what current implementations do.  As a 
start, Gecko parses into an internal representation (for colors, an RGBA 
32-bit integer or a string color name (canonicalized?) for named colors) 
and completely forgets the original string.

-Boris

Received on Tuesday, 2 October 2012 14:15:07 UTC