[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 18:08:49 UTC