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

Re: [cssom] draft of color serialization rules

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 2 Oct 2012 12:35:55 -0700
Message-ID: <CAAWBYDDaAU4xwV0m10VPPi8E5=9tEOz=AV4gt7EKZWMNXu+TEQ@mail.gmail.com>
To: Sylvain Galineau <sylvaing@microsoft.com>
Cc: Glenn Adams <glenn@skynav.com>, W3C Style <www-style@w3.org>
On Tue, Oct 2, 2012 at 12:31 PM, Sylvain Galineau
<sylvaing@microsoft.com> wrote:
>>The question is how much to we want to break working pages/content? For example, if I thought that were feasible, I would >specify that no space followed commas, e.g., rgb(0,0,0) instead of rgb(0, 0, 0).
>>However, my understanding of the goals of CSSOM is that, all things considered, it should try to capture current practice >when it appears there is significant consensus towards a common behavior. At present, that common behavior seems use rgb() >rather than rgba() for opaque colors.
> Code that handles both correctly wouldn't be affected by choosing one result over the other. And new code would be simpler.
> You're of course right about code that assumes rgb() strings: that could suddenly start breaking.

I know from experience that, if you're using jQuery to get color
values, and you want your website to work on IE, you have to be able
to parse *all* of the variants - rgb/a(), hsl/a(), 3 and 6 digit hex,
and named colors.  I had to add several of those parsing modes to an
old project. :/

Because of this, I suspect that most working parsers can handle quite
a bit, so we can choose what representation we'd like.  I'm less
confident about their ability to handle the presence/absence of spaces
between components.

Received on Tuesday, 2 October 2012 19:36:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:22 UTC