New color-manipulation library

[Chris]

I've just finished a new JS color-manipulation library called
jsColors, available at http://www.outstandingelephant.com/jscolors. It
lets you create color objects and manipulate hue, saturation and
value, as well as the standard RGB channels.

Any comments, suggestions, criticisms, questions are encouraged.

Enjoy.

-- Chris

 

[Chris]

For reasons unknown to me, the demo doesn't run in IE6.

Thanks for the heads up.

IE7 fails too. No one uses either of those, right?

It looks like IE doesn't convert the object to a string here:

element.style.backgroundColor = object;

even though object has a toString() method. If you force the object
into a string context:

element.style.backgroundColor = object + "";

it works fine. FF and Opera are apparently smart enough to say, "Oooh,
I expect a string to be here so I'll convert this value to a string."
Not so IE.

The best I could come up with is to add a method, rgb(), that does the
string conversion explicitly. I'd love to hear any better ideas.

The fade to
black did not work in FireFox.

What OS/FF version are you running? It works for me with FF2 on Linux
and Windows.

-- Chris

 

[Chris]

I checked in:
2.0.0.11 XP

Me too, and it worked fine. You set #ex2's background to be the
complement of #ex1's first? Otherwise the background of #ex2 is
transparent and I don't know what it would do.

What's been your experience on how browsers handle internal color
names. IE6 does everything in 6 bit hex and FireFox uses r,g,b() when
you retrieve an elements color. I haven't checked anything else yet. I
notice you had a regex for triplets which I though as a nice touch.

FWIW, I just checked Opera and it takes the IE path.

I tried to make my constructor as robust as possible, so you could
throw anything at it that looks vaguely like a color and that would be
okay.

I've been upgrading my 10 year old color picker:

<URL:http://websiterepairguru.com/colorpicker_2.htm>

I'm AJAXing it to store chosen colors back on the server. I think it
could prove useful to drop it in a web page and style color schemes that
way.

Hey that's pretty cool. How about adding a couple sliders?

Chris

 

[Thomas 'PointedEars' Lahn]

element.style.backgroundColor = object + "";

I would always prefer String(object) or object.toString() above that.


PointedEars

 

[Chris]

I would always prefer String(object) or object.toString() above that.

Yah, toString() still works fine. It's just not getting called when I
think it should.

I really like the elegance of something like:

heading.style.color = myCalculatedColor;

Adding rgb() (which really is just an alias for toString()) probably
wasn't necessary; my intention was to add something a little easier to
type again and again than toString(), like using $() instead of
document.getElementById().

Chris

 

[Thomas 'PointedEars' Lahn]

Yah, toString() still works fine. It's just not getting called when I
think it should.

Pardon?

element.style.backgroundColor = object.toString();

or

element.style.backgroundColor = String(object);

I really like the elegance of something like:

heading.style.color = myCalculatedColor;

Adding rgb() (which really is just an alias for toString()) probably
wasn't necessary; my intention was to add something a little easier to
type again and again than toString(), like using $() instead of
document.getElementById().

Your reasoning is not logical.

First, the use of identifiers starting with `$' should be restricted to
machine-generated identifiers per the Language Specification. Those who use
them anyway for other purposes have failed to notice or are deliberately
ignoring that, and the obfuscation and ambiguity and risk of being reused in
other contexts that comes with this short an identifier as `$'. See also my
signature.

Second, you are ignoring that you are dealing with a host object left-hand
side, so you can not expect universal automatic type conversion on the value
as the object's implementation may implement its [[Put]] algorithm as the
implementor saw fit.

Third, with implicit type conversion like above you require the definition
of another string value as defined in and, more important, the evaluation of

,-[ECMAScript Ed. 3 Final, section 11.6.1]
|
| [...]
| AdditiveExpression : AdditiveExpression + MultiplicativeExpression

which calls ToPrimitive(GetValue(AdditiveExpression)) and
ToPrimitive(GetValue(MultiplicativeExpression)) [steps 1. to 4.], then tests
the type of the results [4. and 5.], calls ToString() on them if they are
String [7.], applying ToString() to the each operand [12. and 13.], which
calls ToString(ToPrimitive(AdditiveExpression, String)) (section 9.8) which
in the end only calls ToString(AdditiveExpression.toString()) (sections 9.1
and 8.6.2.6).

So it strikes me as being much more efficient to call String() or (better,
but not always applicable) toString() directly.


PointedEars

 

[dhtml]

[...] Thomas 'PointedEars' Lahn [...] wrote:

Second, you are ignoring that you are dealing with a host object left-hand
side, so you can not expect universal automatic type conversion on the value
as the object's implementation may implement its [[Put]] algorithm as the
implementor saw fit.

el.style.zIndex = 10;
el.style.left = 0;

works.

Seems normal to expect the setter would try to convert the rh operand
to a string. At least to me.

 

[Chris]

Seems normal to expect the setter would try to convert the rh operand
to a string. At least to me.

I believe Thomas' point was that the browser is under no _obligation_
to convert the value. The fact that a lot of them do is nice, but we
can't rely on that behavior.

Chris

 

[Thomas 'PointedEars' Lahn]

[...] Thomas 'PointedEars' Lahn [...] wrote:

Second, you are ignoring that you are dealing with a host object left-hand
side, so you can not expect universal automatic type conversion on the value
as the object's implementation may implement its [[Put]] algorithm as the
implementor saw fit.

el.style.zIndex = 10;
el.style.left = 0;

works.

The important question is: Works *where*? Besides, you missed the point.

The `zIndex' style property value is supposed to be a number, so no surprise
there.

As for the `left' style property value being the number 0, that is also
supposed to work as CSS allows the unit of length to be omitted if the value
is 0. If you try that with another value you won't be this successful. For
example, in Firefox 2.0.0.12 (both Quirks Mode and Standards Compliance Mode):

// "Warning:
// Error in parsing value for property 'left'. Declaration dropped."
o.style.left = 1

A subsequent read access reveals that the property value was not changed.

Seems normal to expect the setter would try to convert the rh operand
to a string. At least to me.

You are mistaken.


PointedEars