Re: [cssom] draft of color serialization rules

On Tue, Oct 2, 2012 at 10:14 PM, Boris Zbarsky <> 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?
>> = 'black';
>> assert_equals(,**'black');
>> = '#000';
>> assert_equals(,**'#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

Received on Tuesday, 2 October 2012 16:03:56 UTC