W3C home > Mailing lists > Public > www-svg@w3.org > January 2006

RE: [SVGMobile12] A.2.7 Color normalization

From: Jon Ferraiolo <jonf@adobe.com>
Date: Tue, 24 Jan 2006 10:40:17 -0800
Message-ID: <6ECA24BE410D994496A2AE995367C5C8642E05@namail3.corp.adobe.com>
To: "Jonathan Watt" <jwatt@jwatt.org>, <www-svg@w3.org>

(Just to be clear, this is *not* an official response from the SVG WG.)

I will point out that Tiny 1.2
provides APIs for color which do in fact provide color values in a
single representation (a triplet of three longs).


-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf
Of Jonathan Watt
Sent: Tuesday, January 24, 2006 9:55 AM
To: www-svg@w3.org
Subject: [SVGMobile12] A.2.7 Color normalization

Dear SVG WG,

I believe that while normalization is advantageous to Tiny implementers,
makes things more difficult for content authors in some cases. As a
result it
will likely require larger and more complex scripts which means larger
which are undesirable for Tiny devices. For example,
http://www.w3.org/TR/SVGMobile12/svgudom.html#ColorNormalization in
A.2.7 says:

   Color normalization "red" may be returned as "rgb(255,0,0)",
   "#ff0000", or other semantically identical form.

As a result script acting on Tiny content will have to be more complex
to deal
with all possible return values. Previously, content could set colors in
format the author chose and then the author's scripts only had to deal
with that
format if it had to parse color codes.

I suggest that if color normalization be allowed so that implementations
have to store the specified value, then implementations at least be
required to
return their internal representation of the value in _one_ format. I
suggest six
digit hex since it can represent all available colors and in my opinion
easiest to parse the components from. So my request is that you change
the text
quoted above to:

   Color normalization: Values may be normalized to their six digit
   hexadecimal representation. E.g. "red" may be returned as "#ff0000".

Note I still object to allowing the values returned from getAttributeNS
to be
normalized, and IMO it would be better if the getTrait functions were
to normalize so that consumers could be sure of what type of value is
expected back.

Received on Tuesday, 24 January 2006 19:14:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:06 UTC