[Seaside-dev] Issue 88 in seaside: Updated ColorValue>>fromString: to support 3-digit notation

[Stefan Schmiedl]

On Sat, 05 Jul 2008 00:58:09 -0700
codesite-noreply at google.com wrote:

>  self assert: (ColorValue fromString: 'ff0000') = ColorValue red.
>  self assert: (ColorValue fromString: 'FF0000') = ColorValue red.
>  self assert: (ColorValue fromString: '#ff0000') = ColorValue red.
>  self assert: (ColorValue fromString: '#FF0000') = ColorValue red.
>  self assert: (ColorValue fromString: 'f00') = ColorValue red.
>  self assert: (ColorValue fromString: 'F00') = ColorValue red.
>  self assert: (ColorValue fromString: '#f00') = ColorValue red.
>  self assert: (ColorValue fromString: '#F00') = ColorValue red.
>  self assert: (ColorValue fromString: 'red') = ColorValue red.
>  self assert: (ColorValue fromString: 'RED') = ColorValue red.
>  self assert: (ColorValue fromString: '#red') = ColorValue red.
>  self assert: (ColorValue fromString: '#RED') = ColorValue red.

I'm wondering if ColorValue>>fromString is trying to be too clever.

From the tests I'd expect it to recognize both hex color values
in three and six digits and color names.

What are you going to do if a color named "dee" (named to honor the
designer's girlfriend) becomes the latest vogue and everybody wants to
use it, but its hex value is not #ddeeee?

Or: Maybe color specs will allow an alpha value given as final digit or
pair. What would
	ColorValue fromString: 'face'
answer?

I'd feel more comfortable if this method interpreted strings
starting with '#' as hex values and other strings as color names.
Makes things unambiguous.

s.