New color-manipulation library
Chris
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
Jeff
For reasons unknown to me, the demo doesn't run in IE6. The fade to
black did not work in FireFox.
Last night, I almost posted a question on converting hex to HSL here but
figured it was a bit arcane for anyone to know how to do it! Your
library would have saved me a couple hours...
Colors are so weird.
Jeff
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
Jeff
> On Feb 6, 9:58 pm, Jeff <jeff@spam_me_not.com> wrote:
>
>> 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 + "";
Yeah, I can see how that's a little awkward!
>
> 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.
I checked in:
2.0.0.11 XP
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.
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.
Jeff
>
> -- Chris
Chris
> > What OS/FF version are you running? It works for me with FF2 on Linux
> > and Windows.
>
> 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
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Chris
wrote:
> > element.style.backgroundColor = object + "";
>
> 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
> [...] Thomas 'PointedEars' Lahn [...] wrote:
>>> element.style.backgroundColor = object + "";
>> 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.
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
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
dhtml
wrote:
> Chris wrote:
> > [...] 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:
>> Chris wrote:
>>> [...] 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
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16