W3C home > Mailing lists > Public > www-style@w3.org > February 2010

Re: [cssom] serializing <color>

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 15 Feb 2010 11:38:19 -0500
Message-ID: <4B79787B.1080001@mit.edu>
To: Anne van Kesteren <annevk@opera.com>
CC: CSS WG <www-style@w3.org>
> Gecko uses different serialization algorithms. System colors and color
> keywords are preserved for e.g. the .style.color case but not for
> <canvas>.

This isn't a serialization difference as much as a difference in what's 
stored.  In the .style case the keyword or system color is stored (and 
converted to RGBA when converting specified styles to computed styles); 
in the canvas case only an RGBA color is stored to start with.

> (The keywords are returned in lowercase, not in the case
> specified by the specification. I personally like this.)

Since CSS is case-insensitive, there is no "case specified by the 
specification", actually.

> Also, instead of #rrggbb it uses rgb() for .style.color, though not for <canvas>.

Yep, these serialization codepaths are just totally different (since the 
.style one has to handle keywords).

> Gecko also uses a slightly different parser for <canvas> it seems. E.g.
> I found it accepts "red garbage" and treats that the same as "red"
> whereas .style.color will not.

The difference seems to be that the canvas parser just parses the input 
as a color but doesn't make sure all the input is consumed; the CSS 
property parser makes sure that there's a property end after the color. 
  Looks like a bug to me, pure and simple.

> Personally I quite prefer the way Opera handles this, though preserving
> system colors might be valuable. Not sure.

It's a requirement to not have dataloss in any sort of CSS editor, no? 
Heck, so is preserving the named colors that always map to the same 
color, from a human-readability point of view...

Received on Monday, 15 February 2010 16:38:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:43 UTC