Raphaël Colorwheel (Color picker implemented with Raphaël)
J. Weir
After being a bit disappointed by existing color pickers I created my
own.
It uses Raphaël, of course, and also jQuery(to simplify event
handling).
Being in Raphaël, the color picker can be scaled to suite your design.
Let me know what you think, if you see any bugs, or if the math behind
the colors is off.
http://jweir.github.com/colorwheel
Cheers,
John
Clifford Heath
> After being a bit disappointed by existing color pickers I created
> my own.
Nice. However I expected after picking a hue to be able to click on the
dot in the saturation/luminance square and drag it. Instead I must click
elsewhere in the square, and the dot moves there and tracks it. A click
on the dot doesn't start a drag. Not a biggie, but it feels like a bug.
Clifford Heath.
J. Weir
dragged.
Does it behave more like it expect now?
Clifford Heath
After a shift-reload, yes. Thanks!
Clifford Heath.
Daniel Friesen
We used http://www.eyecon.ro/colorpicker/ in the last version of the
app, but it gave us issues with it's requirement of clicking the button
to cause a change.
Perhaps I'll adapt your color picker to roll something nice and simple
into v3.
I would prefer choice between the three or so different types of color
inputs, so perhaps I'll expand on your idea of using Raphael and add
setups for the other types of color input ui.
By the way, instead of continually firing the onchange event (a counter
to it's common behavior) perhaps you could instead adapt the oninput
event and fire onchange when the user stops dragging, much like how the
onchange event normally works.
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#common-event-behaviors
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
J. Weir wrote:
> Hello all,
>
> After being a bit disappointed by existing color pickers I created my
> own.
>
> It uses Rapha�l, of course, and also jQuery(to simplify event
> handling).
>
> Being in Rapha�l, the color picker can be scaled to suite your design.
svg_nerd
this an open source or commercial project, does it use raphael?
On 17 Feb, 06:42, Daniel Friesen <nadir.seen.f...@gmail.com> wrote:
> Interesting. I was going to need a color picker for Kommonwealth eventually.
> We usedhttp://www.eyecon.ro/colorpicker/in the last version of the
> app, but it gave us issues with it's requirement of clicking the button
> to cause a change.
> Perhaps I'll adapt your color picker to roll something nice and simple
> into v3.
> I would prefer choice between the three or so different types of color
> inputs, so perhaps I'll expand on your idea of using Raphael and add
> setups for the other types of color input ui.
>
> By the way, instead of continually firing the onchange event (a counter
> to it's common behavior) perhaps you could instead adapt the oninput
> event and fire onchange when the user stops dragging, much like how the
> onchange event normally works.http://www.whatwg.org/specs/web-apps/current-work/multipage/common-in...
Daniel Friesen
commercial aspect hasn't been completely decided yet.
On the plus side a more open stance is being taken. Hosting is a
possibility, but sites can be exported as static html which can be
modified by other tools for free. And rather than building in CMS
capabilities we're integrating with external services. Allowing sites to
be exported as WordPress skins, integrating data from external blogs, etc...
I made a post about work before:
http://blog.danielfriesen.name/2010/01/31/projects-at-work/
However we've been releasing any part of the code which isn't part of
the actual system and can be extracted as a library under an open source
license.
So far I released a mongo-rhino driver wrapper for mongodb. And I'll
probably be releasing a ContentEditable library when I finish it (every
WYSIWYG editor uses designMode so I'm rolling our own simple library
that'll use contentEditable).
Work also lead me to do some browser research for html5's oninput event:
http://blog.danielfriesen.name/2010/02/16/html5-browser-maze-oninput-support/
We're also using some of my own open-source projects, as well as 3rd
party open-source libraries.
We are using Raphael for two small but critical components inside of v3
of Kommonwealth (different UI than the one you see in the demo video,
that was from v2). It also generates the content bubble graphics in
Kommonwealth and My Voice Site. We're also using Raphael heavily in the
advanced ui for My Voice Site.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
J. Weir
I too was using http://www.eyecon.ro/colorpicker/ and wanted to use
Farbtastic, but the author wasn't interested in commercially licensing
it.
I'm not quiet sure I understand what you are saying about oninput or
onchange.
The onchange is fire(it is has been set) any time the color is
changed, whether that be a drag, a change to a bound input, or
via .color(value). All of these are changes, so it seems the simplest
method. I'm not sure what oninput would be.
But, maybe I am missing something.
On Feb 17, 6:42 am, Daniel Friesen <nadir.seen.f...@gmail.com> wrote:
> Interesting. I was going to need a color picker for Kommonwealth eventually.
> We usedhttp://www.eyecon.ro/colorpicker/in the last version of the
> app, but it gave us issues with it's requirement of clicking the button
> to cause a change.
> Perhaps I'll adapt your color picker to roll something nice and simple
> into v3.
> I would prefer choice between the three or so different types of color
> inputs, so perhaps I'll expand on your idea of using Raphael and add
> setups for the other types of color input ui.
>
> By the way, instead of continually firing the onchange event (a counter
> to it's common behavior) perhaps you could instead adapt the oninput
> event and fire onchange when the user stops dragging, much like how the
> onchange event normally works.http://www.whatwg.org/specs/web-apps/current-work/multipage/common-in...
Daniel Friesen
onchange probably would have been better named something like oncommit
rather than onchange.
Here's an example to explain:
If you select a text input and then type "asdf" into it then leave the
input. There are six different parts to this. You activate the input
(focusing it), you make separate inputs into the element for "a", "s",
"d", and "f", and finally when you leave the input you "commit" the change.
In the dom this is represented (ignoring the multitude of click and key
events) with an onfocus event, followed by 4 oninput events fired each
time value= changes, and finally an onblur and a onchange event.
oninput is the event fired when the value of the input changes. onchange
is an event that fires when the input is actually committed. In the case
of text input the content of the input has not changed until the user
has made it clear they are no longer entering data into the field (in
other words when they leave it). While oninput fires while the user is
making changes, or in other words "inputting" into the input. Key note
is that oninput and onchange are only fired when value= is changed
according to the scope of their event. oninput will fire if you type f
changing "asd" into "asdf", however if you go to the start of the "asdf"
and hit delete leaving it at "asdf" it will not fire. Likewise onchange
is only relevant to the difference between when you enter the input and
you leave it. So if you enter into the input, delete the sd from "asdf"
turning it into "af", then type sd back in turning it back into "asdf"
and then leave the input, because this is the same as what it was when
you first entered the input onchange will NOT fire.
((best I can explain it, spec makes requirements a little more complex))
Likewise what you have is a color input. The user clicks on the input,
drags the pointer along, and releases it at a color that has been
chosen. As events are concerned the user has not committed their change
to the input until they let go of the handle. In other words this action
is broken up into multiple oninput events as the user drags the input
along, and finally an onchange when the user releases the handle
committing their change. However onchange should not fire if the color
is the same as the color the input started with.
((This is pretty much how a compliant html5 <input type=color> will behave))
Additionally one more important note, events are only for user actions
on the input. An input that was programmically triggered (ie: By calling
.color()) should not fire events (thats in part where custom triggering
of events comes into play).
What I'm basically suggesting is that you align the events your library
fires to match how html inputs actually send out events to avoid causing
trouble with event bound code that expects events to be fired the way
they are defined in the spec.
Here's an example of practical example use of oninput and onchange events:
Take a text area where a preview of the text is displayed below it, and
when the input's content is changed it submits to the server.
You'd bind two events to this input for practical use. An oninput which
when fired updates the preview text. And an onchange which when fired
makes an ajax call to the server with the new value.
As you type into the text input the oninput events will be fired, and as
they fire the preview will be updated live based on the text you are
typing in.
When you are finally finished with the input and exit it the onchange
event will be fired, this will trigger the update of the data on the server.
((And I'm not really talking about a theoretical example here, I'm
talking about practical use being put in play by any good edit in place
pattern. This is basically what we're doing in Kommonwealth's style
editor)).
Now apply that to a color input. oninput events firing as the user
drags, and onchange events firing when the user lets go of the handle if
the color is not the same as when they grabbed it.
The user experience would be similar. As the user drags the handle
oninput events fire causing the preview area to be updated with the
color currently being hovered over. When the user releases the handle an
onchange fires and the color they left it on is submitted to the server.
Note that a app using events the way the spec defines them that throws
the color wheel into the mix will instead get a pile of onchange events
firing instead of oninput causing the browser to send a slew of ajax
posts to the server as the user drags. (In the interface this would
manifest itself as a slow interface always talking to the server, and
glitches with data not "sticking" because the order of the ajax calls
finishing is not guaranteed causing some of the earlier calls to finish
last in some cases upading the color to the wrong value).
antimatter15
Math.PI?
> > I too was usinghttp://www.eyecon.ro/colorpicker/and wanted to use
> > Farbtastic, but the author wasn't interested in commercially licensing
> > it.
>
> > I'm not quiet sure I understand what you are saying about oninput or
> > onchange.
>
> > The onchange is fire(it is has been set) any time the color is
> > changed, whether that be a drag, a change to a bound input, or
> > via .color(value). All of these are changes, so it seems the simplest
> > method. I'm not sure what oninput would be.
>
> > But, maybe I am missing something.
>
> > On Feb 17, 6:42 am, Daniel Friesen <nadir.seen.f...@gmail.com> wrote:
>
> >> Interesting. I was going to need a color picker for Kommonwealth eventually.
> >> We usedhttp://www.eyecon.ro/colorpicker/inthe last version of the
Dmitry Baranovskiy
I wanted to create such a thing for a long time, was too busy. But
now, when you done all the work, I will refactor it and submit you a
patch at github. I give a promise. In fact I already started.
> --
> You received this message because you are subscribed to the Google
> Groups "Raphaël" group.
> To post to this group, send an email to raph...@googlegroups.com.
> To unsubscribe from this group, send email to raphaeljs+...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/raphaeljs?hl=en-GB
> .
>
charles thomas
| Daniel it looks beautiful. However my only slightly negative comment is not it's functionality (100%) or it's performance (100%). It's the integration with jquery. How much of jquery is it using? If you used jquery for the easy event programming why couldn't you have used the implicit event programming available with Raphael? Here is a working example of the default event's that are available.. http://www.irunmywebsite.com/raphael/additionalhelp.html?q=usingelementevents Regards Charles --- On Wed, 2/17/10, Daniel Friesen <nadir.s...@gmail.com> wrote: |
|
|
Get the name you've always wanted ! @ymail.com or @rocketmail.com.