Re: [SVGMobile12] A.2.7 Color normalization

Hello www-svg,

Jonathan Watt <jwatt@jwatt.org> wrote:
> 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.

Note however that they can use trait accessors to remove the need for
doing their own parsing entirely. So in this case, getRGBColorTrait
will return an SVGRGBColor, which has three unsigned longs - for red,
green, and blue. There is no need to mess about with string
representations.

Not only is this easier for content authors when dealing with their own
code, its also easier when dealing with, or integrating, code from
multiple people.

> 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

(in fact, no. only the rgb() form can represent *all* colors because the
values can have arbitrary precision rather than being quantised to 8
bits and trimmed to a 0.0 ... 1.0 range).

>  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".

As explained above that would be both undesirable and also not actually
a help.

> 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.

They don't need to mess with string values for colors anyway.

-- 
 Chris Lilley                    mailto:chris@w3.org
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Tuesday, 6 June 2006 18:21:03 UTC