W3C home > Mailing lists > Public > www-style@w3.org > October 2012

Re: [cssom] draft of color serialization rules

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 02 Oct 2012 10:14:31 -0400
Message-ID: <506AF6C7.7000907@mit.edu>
To: www-style@w3.org
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:01 GMT