- From: Jon Ferraiolo <jonf@adobe.com>
- Date: Tue, 24 Jan 2006 10:40:17 -0800
- To: "Jonathan Watt" <jwatt@jwatt.org>, <www-svg@w3.org>
Jonathan, (Just to be clear, this is *not* an official response from the SVG WG.) I will point out that Tiny 1.2 (http://www.w3.org/TR/SVGMobile12/svgudom.html#svg::SVGRGBColor) provides APIs for color which do in fact provide color values in a single representation (a triplet of three longs). Jon -----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, it 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 documents which are undesirable for Tiny devices. For example, http://www.w3.org/TR/SVGMobile12/svgudom.html#ColorNormalization in section 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 the 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 don't 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 is 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 *required* to normalize so that consumers could be sure of what type of value is expected back. Regards, Jonathan
Received on Tuesday, 24 January 2006 19:14:12 UTC