Re: [cssom] draft of color serialization rules

On Tue, Oct 2, 2012 at 10:14 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> 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?


exactly; i think it easier to reach conclusions on consensus about
serialization behavior of computed 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?
>

those are exactly the questions we need to answer if we are to specify
interoperable behavior for serialization of specified values


>
> 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.


agreed; i'll prepare some tests for this