SoftMoon WebWare’s MasterColorPicker package delivers five JavaScript™ powered professional quality interactive graphical color-pickers, plus a named-color-table based color-picker framework with seven named-color database files included: Brewer, common, Crayola, HTML, OpenOffice, universal, & X11. Your chosen colors can be returned in the most popular color-space models including hexadecimal-RGB, RGB, HSL, HSB, HCG, or CMYK, or when using named-colors their names can also be returned. The different graphical color-pickers each look at the different available color-spaces in a different way, giving you complete intuitive control over finding the exact color you want. Best of all, you can work with one color-space graphically, while outputting the corresponding conversion value from another color-space. The five interactive graphical color-pickers included are:
- RainbowMaestro Harmonic Color Picker™
- Specializes in color-harmony, shows light/dark shades (monochromatic) of a selected hue and its complement, triadic complements, split-complements, and analogous colors, all in one color-wheel. Includes a “websafe colors” setting; Colorblind assistant shows protan, deutan, & tritan simulations of the palette and selected color.
- Spectral Progressive Color Picker™
- Shows the progression of colors in steps based on the RGB color-space. Works with browsers as far back as Internet Exploder 6.
- BeezEye Color Picker™
- Classic color-wheel shows HSL, HSB, HCG, and CMYK color-spaces (one at a time) with user-controlled Lightness/Brightness/Gray/Black.
- Simple² Color Picker™
- Works with the HSL and HSB color-spaces (both at once) to bring you simple access to the shades of any color from the color to →black, →white, and →gray.
- YinYang NíHóng Color Picker™
- Another classic style, delivers all of the 11,777,216 colors your 24-bit monitor can show within two easy clicks using either the HSL, HSB or HCG color-spaces.
All these graphical color pickers, except for the YinYang NíHóng color picker, are designed to show colors in definite “steps” of progression, allowing you to easily work with gradients (see our Rainbow-Maker projects) and find “matching” colors from other hues/shades. The number of steps, or variety of colors, is user-controllable in real-time, from just a few to “high resolution”.
¡As of late October 2014 August 2015, I have pre-released MasterColorPicker version 2.0.01-alpha.
This version now will almost completely work with newer versions of Firefox (39+) (see below),
and also gives the user the ability to drag & drop the “picker panels”
around the window and/or HTML page the MasterColorPicker is embedded in
(a.k.a. “sticky panels” because the user can “stick” them back-and-forth to either
the window (position: fixed) or page (position: absolute) in real-time).
In addition, several new auxiliary panels are included in the HTML front-end
showing off the features that will be included when
version 2.0-beta is complete and ready to be released.
Only the “color-filter,” “color-space lab,” and “myPalette” features have any integrated working functionality (and “myPalette” is still incomplete),
but this release shows off the latest update to the Picker class which is the
supporting framework for the MasterColorPicker project.
The MasterColorPicker code-set remains largely unchanged at the low-level, however, at a higher level,
the x-ColorPicker class is no longer a simple static-functional class, rather it now
constructs “color picker” objects; this will be necessary to integrate the planned enhancements.
One minor annoyance bug was fixed with the “RainbowMaestro” picker: when you manually type in the
focal-hue degree and press Enter and then click on a color it is now recognized,
whereas before this click needlessly updated the <canvas> as focus was taken from the
focal-hue input, so the onClick event never could occur since the old <canvas>
was discarded before the event could trigger.
For now, if you want to use the MasterColorPicker.php file,
you will want to manually remove the new panels and hide their supporting options in the “options panel”
if you include this update in your own project — see theHTML comments in the file.
The MasterColorPicker_desktop.htm file already has this done.
Also note this update requires updated UniDOM.js and Picker.js files,
and in particular, UniDOM has been completed, updated, and bug-fixed, and is now
a very useful & powerful project in its own right, not merely an included support file of some common functions.
I’m still not sure when I will find time to finish MasterColorPicker 2.0-beta, (but hopefully soon)
so I’m releasing 2.0-alpha just to keep up with the current browser changes, minimal bug-fixes and enhancements.
Note this latest August 2015 release also requires 3 additional files:
JS_toolbox/SoftMoon-WebWare/FormFieldGenie.js,
JS_toolbox/Math+++.js &
JS_toolbox/Stylesheet.js.
Now these ain’t your grandpa’s color pickers, mind you.
The MasterColorPicker project is of a cutting-edge design
that relies on a modern computer that can process the JavaScript™ fast enough,
and a modern browser with HTML5 <canvas> tag support and
HTML5 forms support
for the slider controls to work (sliders are the only real way for this to work well for users in real time).
At the time of the first MasterColorPicker release, only
Google’s® Chrome®,
Apple’s® Safari®,
the Opera® browser,
and Microsoft’s® Internet Exploder 10 had this capability natively.
With earlier versions of Mozilla’s® Firefox®, you were completely lost;
most of the problem resided with bugs in Firefox®, but there was also a bug in the supporting UniDOM file
(it was rushed out and not fully developed or debugged).
At this time of writing (Oct 2014) Firefox® version 33 is out, and although it won’t function at all on my computer
(I get a blank black screen, with nothing in the title-bar or menu-bar of the Firefox® window),
version 32 (and maybe some earlier) supports input sliders and displays the table HTML correctly,
and with the latest (complete & debugged) version of UniDOM, you can pick colors in most of the pickers;
however, ealier Firefox® still has problems delivering the correct {x,y} position of the mouse on the screen
when it is over a “bounding box” of a transform: rotated Element and therefore
the “BeezEye” & “Simple²” pickers still don’t work correctly (note the “bounding box” is larger
than the displayed rotated Element, and is based on the displayed position as well as “untransformed” position).
I’m hoping the folks at Mozilla® get their act together soon, and get a fully working browser up and out,
but in the meantime, you might restyle these two pickers and/or completely rewrite their HTML to get them to work.
Now (Aug 2015) that Firefox® 39 is out (I had to hover-over or right-click and choose “properties” on the
firefox.exe file in the “programs” folder to find the version number!) the only bug I find
is that the event.detail property =1 during mousemove events following a click
event when the specs on the Mozilla® Developers Page says it should be =0.
This did cause a bug, but I overcame it, and now Firefox® seems to be in the lead for full support of MasterColorPicker,
excepting some minor CSS layout discrepencies
(I’ll worry about them in the final stages of development if Mozilla® hasn’t fixed them first).
Opera® 12.16 (out when MasterColorPicker first was released), and as usual has no known bugs
(that couldn’t be overcome with a bit more CSS),
applied styling looks the most elegant overall,
and has the best overall performance tied with older Chrome®,
in terms of speed of page load & color-picker rendering being acceptably fast with an average modern computer.
(Just don’t trust it to keep your bookmarks if you update,
so turn off auto-update and backup, backup, backup!
With the last update happening automatically and again clearing out my bookmarks, I removed Opera from my computer…F them!)
Old versions of Google’s® Chrome® get you there, but it’s still a bit
quirky; don’t try to scroll the main page while the color-picker is displayed in a fixed position!
For that reason, you may want to use JavaScript™ to feed
old Chrome® the same CSS patch file that
MSIE9 uses — or better, simply demand that your users update.
And old Chrome® insists that rotated <input type='range' /> tags
be rendered with a white background, even with inline styles set; not a “problem” just less elegant looking.
With the new Opera® (currently version 25) and
Chrome® (currently version 38) (Oct 2014) now joining forces
to use the new “Blink” browser foundation, both browsers display the default HTML correctly
and work correctly, however, Chrome® is now the fastest of all browsers.
August 2015 note: I ditched Opera® since they deleted all my bookmarks, so no comment there, but
Chrome® works except for it does not update the
CSS :hover conditions as the mouse moves over the page
with the button held down when dragging colors in the “myPalette” panel.
With Safari® on an Apple® Mac®
(untested using Safari® on Windows®)
(also untested on any newer (2014) versions — I don’t (won’t) have an Apple)
<input type='range' /> tags
are rendered only in solid black with a transparent background.
(¡¡New 2014 note: I finally found instructions on how to style a range-bar in CSS!!
But as noted, I don’t have an Apple to test this.
By the time I release MasterColorPicker 2.0 beta, I should have this problem worked out for sure.)
The black-on-black rendered by Safari® is then invisible.
I chose black as the background for the color-pickers because it shows the colors better,
and provides a stark contrast with most web-pages, giving the “pop-up” more of a “panel” feel.
Solutions include wrapping every <input type='range' /> tag with a <span>
and then styling the <span> with a background; forcing Safari®
to use the FD-slider package that MSIE9
needs (see below); or using JavaScript™ to feed in another stylesheet
to alter the color-styling of the “mainPanel”.
I don’t care for superfluous HTML tags added simply for visual styling — that goes against the
principle of separation of content from styling.
But Safari leaves little choice, as a background other that black simply does not seem to work well in the overall picture.
My solution is to use JavaScript™ targeted only for Safari® to
add in all those superfluous <span> tags wrapped around each <input type='range' />
on the mainPanel (fix in version 1.0.4).
With Microsoft’s® Internet Exploder 9,
even though color-picker rendering is slower than molasses in winter when adjusting values,
you might be able to use a JavaScript™ package like the one from
Brian McAllister of frequency-decoder (the FD-slider)
to add the needed <input type='range' /> capabilities; but note that package only works under some
conditions on some browsers.
I enhanced it to work better
with more complicated layouts, and also added the ability to work with rotated sliders,
and included its basics with the MasterColorPicker files.
Never-the-less, it does not work with the basic supplied server-based CSS file which
places the pickers in a fixed-position format in the top-right of the browser window,
but there is a supplied patch-file, that works with some overall page structures
(where you place the MasterColorPicker in the document, and what the parent element is,
and what else it contains, and how you style that parent and the rest of the document),
which you can target to MSIE9.
(see the simple fix which you should target to that browser in the section on
using the MasterColorPicker below).
But these color-pickers are completely flexible and don’t rely on any specific CSS styling.
In fact, except for the Spectral Progressive color-picker and the named-color tables,
the HTML is flexible too: use whatever tags you want/need, with only minimal restriction
on placing tag ids on appropriate wrapper elements.
With all that said, there is even a hack that skips the <input type='range' /> for browsers with at
least <canvas> support, but it’s more of an unfriendly work-around for both users and programmers…
See below for technical details on the HTML
requirements for each individual color-picker,
and the section on registering interface elements.
Finally, if you must have support for older browsers, maybe either the
Raphaël—JavaScript Library
(the way I would go as SVG is even more powerful and universal) or
http://flashcanvas.net/
(I would avoid as Flash® is on its way out!)
can help: but you will at least need to modify MasterColorPicker.js,
a bit more than I have time for right now as I’m looking forward not backward ☺
Desktop vs. Server
The package includes two versions: desktop and server-based. The desktop version can be placed in a folder on your personal computer and used to find the colors of your dream’s desire. But while the desktop version can also be incorporated into your own web page and served from your server, you guessed it, the server-based version requires a server such as Apache for example (you can always put a server on your home machine, of course, and use the server version on your desktop). But the server-based version is much more convenient to use if you plan on adding or deleting named-color database tables on a regular basis. For instance, you might use the server-based package to allow customers to choose the color they want based on the product they are interested in, one table for each product line, and your product line may be dynamic. With the server-based version, you simply create the named-color database file and add it to the proper folder; that’s it. Remove it from the folder when you are done with it. With the desktop version, you must manually add and remove links to each of the named-color tables, whether served with your web-pages, or simply using the desktop tool.
There is another factor in deciding whether to use the desktop or server version when incorporating the
MasterColorPicker into your own website. The named-colors database files are JSON formatted.
With the server based version, these files are loaded using JavaScript™
to make HTTP calls back to the server (think ajax), whereas with the desktop version,
they are themselves JavaScript™ files loaded with an HTML
<script src='colors-filename.js'> tag.
This means that the server version can interpret the files,
whereas in the desktop version the database files are required to be legal JavaScript™.
And this means that the server version has database files that can be used easier with server-side languages,
such as PHP.
PHP has a function, json_decode() that quickly and simply converts
JSON-encoded text-strings. But the desktop version requires that the
JSON Object is assigned to something right there in the database file itself, and
PHP can not natively read this. Of course, with a little ingenuity, you could strip off
the “assignment” within the JavaScript™-based-database file and then parse it
natively using PHP;
more overhead on overworked servers is never a good thing, though, however small.
Named-color tables
Because the named-color database tables are required to be in only slightly different formats,
and many of the files are very long, these database files only come packaged in one format: for the desktop version.
There is an included PHP powered converter which will convert all the files to the server version format.
There is also an instruction file which explains the details on how to do this using the included converter,
and also how to do this by hand.
These two files, convert_palette_formats.php and converting_palette_formats.rtf,
can be found in the color_palettes folder.
Building your own named-color-tables is simple to do using any basic text-editor.
Complete instructions on how to do this can be found in the README.rtf file
in the color_palettes folder.
Using MasterColorPicker in your own project
It’s very easy to incorporate the MasterColorPicker (or even any of its individual pickers) into your own project.
To limit download size, but maximize ease of use, two different but similar files are included.
The desktop version is built with pure HTML (file name MasterColorPicker_desktop.htm),
while the server version is built with embedded PHP (file name MasterColorPicker.php).
The desktop file is a complete HTML page with a head and body, while the server version only contains
the needed HTML for the MasterColorPicker project itself.
The PHP generated HTML is essentially the same as the pure HTML,
except the PHP can keep track of the settings on the individual pickers, and keep them set the
way the user sets them, in between page invocations.
Doing this requires that the color-pickers HTML be either enclosed within a <form method='post'>
tag, or otherwise “attached” to a form, and submitted back to the server.
Generally, if you are picking a color, you will be sending form data anyway.
But you do not need to use the PHP file with the rest of the server version.
(What defines the server-version is the way named-color tables are used:
see Desktop vs. Server).
Simply “cut out” the proper section of HTML from the desktop version file
(the file is commented so you can tell what to cut), and either make it a new file: MasterColorPicker.htm
or simply paste it into your own web-page file; either way you then incorporate the MaterColorPicker HTML
at whatever place in your document you desire.
To use the PHP file with your PHP webpage, simply place
<?php include "color-pickers/SoftMoon-WebWare/MasterColorPicker.php"; ?> in your document at the
appropriate place.
Or you can use your own HTML, with no restriction on the tags used, and minimal requirements on the
structure: just place a few ids on appropriate wrapper elements.
You can use and/or modify the supplied CSS files, or write your own
(see customizing MasterColorPicker below).
Link the main MasterColorPicker.css file in the head of your document if you plan on using it.
If you want to use this file with Internet Exploder 9, you will need conditional comments to load in the
fd-slider_SM-enhanced.js file and its stylesheet.
At this point you should simply also be able to
link the MasterColorPicker_MSIE9-patch.css file; however, this is Microsoft.
They give you a lame hack requiring conditional comments to overcome their lack of commitment to
working CSS, and then that hack they specifically recommend doesn’t work half the time.
CSS means “cascading style sheets”, yet Microsoft developers don’t know how to apply a
simple cascade, even in IE9, 15 years after the concept was introduced.
Open the F12 developers tools, and it shows as all being there………
If you don’t place the MasterColorPicker HTML within the “right” overall page structure
(don’t ask for a definitive answer on what that means or entails!…this is Microsoft!),
or even if you simply add a title attribute to the <link> tag
(a basic standard DOM attribute
which is supposed to give you an easy & definitive interface handle within JavaScript™
to each individual stylesheet, or your code must otherwise “know” the stylesheets’ file names or which order they are linked,
which means hard-coding the answer – bad practice!)
rules may simply be ignored in the patch file.
So, if you find that to be the case, you must manually copy and paste the text of the patch file in to
<style> tags embedded in the head of the document. Low and behold! They now apply!
<!--[if lt IE 10]>
<link rel="stylesheet" type="text/css" media="screen, projection" href="JS_toolbucket/freqdec-fd-slider-01084d3/css/fd-slider_SM-enhanced-compatible.css" />
<script type='text/javascript' src="JS_toolbucket/freqdec-fd-slider-01084d3/js/fd-slider_SM-enhanced.js"></script>
<link rel="stylesheet" type="text/css" media="screen, projection" href="color-pickers/SoftMoon-WebWare/MasterColorPicker_MSIE9-patch.css" />
<style type='text/css'>
………if linking doesn’t work insert copied CSS (¡not linked!) file here (MasterColorPicker_MSIE9-patch.css)………
………and remove the link just above…
</style>
<![endif]-->
<!--[if gte IE 10]>
<style type="text/css">
#MasterColorPicker_mainPanel,
#MasterColorPicker_options {margin-right: 1em;}
</style>
<![endif]-->
<!--[if IE]>
<style type="text/css">
#MasterColorPicker_options.activePickerPanel > div div {display: block;}
#MasterColorPicker_mainPanel table {border-top: none;}
#MasterColorPicker_mainPanel table caption {
border: 1px solid;
border-bottom: none; }
#MasterColorPicker_mainPanel table#BeezEye caption {
border-right: none; }
legend {color: inherit;}
</style>
<![endif]-->
You should also fix the way MSIE handles
table captions and fieldset legends in general as shown above.
For MSIE10, (¡oh no! another nightmare browser for developers! And they were doing so good with MSIE9…
And Windows® 8 takes the cake for user-unfriendliness)
you need to take in account that the browser-window’s scrollbar may randomly appear on the right side of the screen,
covering the browser-window’s content,
whenever Windows® decides the user wants to scroll
(why the user can’t decide this I don’t know, other than the folks at Microsoft are just so arrogant as to think
that they should be in control of your computer,
and you are just a data-mine of personal info and usage statistics).
Without a margin, any scrollbar for the “mainPanel” can be covered by a “ghost” scrollbar for the whole window,
leaving the user unable to control what it is they are trying to scroll.
And of last note, again MSIE fails to apply cascades correctly, and fails to handle
CSS :hover directives correctly,
when you try to use the color-space output <select>.
The attempted hack to fix this at least preserves the pull-down menu!
But the rest of the options panel, including the main body of the <select> disappears
when you hover the mouse over this pull-down!
So sad that leaders of the Human Race do so with make-up and mirrors,
not true leadership or intelligence or even by attempting basic working solutions.
But as the Tao says, nothing lasts…
Anyway, depending on your overall page layout,
you may want to reposition the options panel and/or keep it visible when the MasterColorPicker is active
by modifying the supplied main CSS file instead of cascading with additional styles.
Your HTML (web page) file must be encoded in UTF-8. You should already be using this encoding in all your web page files anyway. JavaScript™ is required to be encoded in UTF-8, and this project uses a character set beyond the standard ASCII characters. Remember, UTF-8 is the #1 international choice for character encoding; it even helps protect your site against cross-site scripting (vs. the default UTF-7).
Using the Picker interface
MasterColorPicker is built on an instance of SoftMoon-WebWare’s Picker interface,
which creates a new input “type:” picker.
Using this interface is easy.
The most simple way to use this project is to place anywhere within your document any number of
<input type='MasterColorPicker' /> tags and/or
<input type='text' pickerType='MasterColorPicker' /> tags.
The MasterColorPicker will find them when the document is fully loaded and automatically “register them,” i.e.
add the necessary event-handlers to interface with the Picker.
Using <input type='color' pickerType='MasterColorPicker' /> tags can work with the MasterColorPicker
also, and with browsers that already support this natively, you will get the native color-picker plus the MasterColorPicker;
but caution: the W3C specs say that <input type='color' /> should limit
the user’s input to basic ways of defining colors, which means that your MasterColorPicker implementation should limit
its output to hexadecimal RGB with a leading # symbol.
If you don’t like non-standard tag attributes, or you otherwise want to link an input tag to the MasterColorPicker,
after the MasterColorPicker.js file is loaded, you can use JavaScript™ to
link the input tag something like this:
<script type='text/javascript'>
myInput=document.getElementById('myMasterColorPickerInput');
MasterColorPicker.registerTargetElement(myInput);
</script>
A registered target element activates the Picker when the user clicks on it, or it otherwise receives “focus”.
Using the “color swatches”
When a color is clicked on, the target element’s value is changed to the color-value-text.
Also, the associated “color swatch” has its background-color changed to the user-selected color,
while its foreground-color becomes either black or white, opposing the background-color’s brightness.
The “color swatch” is either the target element itself when MasterColorPicker.showSwatchAs='background',
or when MasterColorPicker.showSwatchAs='swatch' the color swatch
is determined by the first valid condition in this list:
- If the target is as such:
<input swatchId='myDocumentId' />then the swatch is a document element with an id that matches “myDocumentId” if it exists. - If the target-object has a JavaScript™ property “swatch,” then the swatch is that property’s value.
- If the JavaScript™ Object property
MasterColorPicker.swatchis set, then the swatch is that property’s value. - The document Element that follows the target-input.
Be sure to read the end of the file MasterColorPicker.js
for more details on using the “color swatch”.
Targets other than text <input>s.
You don’t need to use an <input type='text' /> with MasterColorPicker.
<textarea>s, <select>s, <input type='text' list='datalistID' />s,
and even document text-nodes are automatically recognized by the MasterColorPicker.pick() method.
By default, the JavaScript™ value of
MasterColorPicker.dataTarget.value is set when a color is picked.
If no dataTarget is set then the MasterColorPicker.masterDataTarget is used, if any.
The dataTarget and masterDataTarget each may be any
JavaScript™ Object.
Or they may be <input type='hidden'> if you don't care to show the user the dirty color-code,
but want to send the value back to the server with a form-submittal.
To supplement this functionality, add a JavaScript™ function to the
Array of MasterColorPicker.pickFilters.
To replace this functionality, replace the MasterColorPicker.pick method with your own function.
See the file JS_toolbox/SoftMoon-WebWare/Picker.js for more details.
Structuring your own HTML and CSS
The visual presentation of the individual color-pickers is up to you.
There are a few comments within the supplied HTML/PHP files
which will not be repeated here; you should read them.
One general consideration concerns the <canvas> tag widths & heights;
you may modify them, keeping in mind that the color-pickers build their palettes based on the given width
of the <canvas>, so it is best to keep the width/height of the canvases equal
(excepting some of the canvases in the Simple² & YinYang NíHóng pickers).
The important requirements to follow are listed below for each of the color-pickers in the MasterColorPicker project:
RainbowMaestro Harmonic Color Picker™
HTML requirements:
- There must be a “wrapper” tag with an
id='RainbowMaestro'containing:- 4
<canvas>tags - all the corresponding
<input />tags found in the supplied files. - 4 tags with
class='subpalette_swatch'. They will show the color of the hovered-over color for each individual<canvas>.
- 4
- Each
<canvas>tag must be wrapped in its own “wrapper” tag. - The
<input />tags in your file must have the same names, types, & values found in the supplied files. - There should be a tag with
id='RainbowMaestro_indicator'. It will show the text-output for the hovered-over color. It should have text in it by default, if only a blank space, with no other tags, at the beginning. - There should be a “wrapper” tag with
id='RainbowMaestro_hueIndicator'. The last tag within this wrapper will show the hovered-over hue as a value in degrees. - There should be a tag with
id='RainbowMaestro_swatch'. It will show the color-output for the hovered-over color that matches the text-output.
CSS requirements:
none.- There must be a “wrapper” tag with an
Spectral Progressive Color Picker™
HTML requirements:
Do not alter the HTML for this picker.CSS requirements:
none.BeezEye Color Picker™
HTML requirements:
- There must be a “wrapper” tag with an
id='BeezEye'containing:- A
<canvas>tag - all the corresponding
<input />tags found in the supplied files.
- A
- The
<input />tags in your file must have the same names, types, & values found in the supplied files. - There should be a tag with
id='BeezEye_indicator'. It will show the text-output for the hovered-over color. It should have text in it by default, if only a blank space, with no other tags, at the beginning. - There should be a tag with
id='BeezEye_swatch'. It will show the color-output for the hovered-over color that matches the text-output.
CSS requirements:
none.- There must be a “wrapper” tag with an
Simple² Color Picker™
HTML requirements:
- Your file must be encoded in UTF-8.
- There must be a “wrapper” tag with an
id='Simple²'containing:- 5
<canvas>tags - all the corresponding
<input />tags found in the supplied files.
- 5
- The
<input />tags in your file must have the same names, types, & values found in the supplied files. - Each
<canvas>tag must be wrapped in its own “wrapper” tag, and each wrapper tag must have an id corresponding/matching the ones wrapping the canvas tags in the supplied files; be sure to use the proper combinations of caps/lowercase. Note some canvases are filled vertically, others horizontally, so set their height/width appropriately. - There should be a tag with
id='Simple²hue'. It will show the hue in degrees for the displayed colors. It should have text in it by default, if only a blank space, with no other tags, at the beginning. - There should be a tag with
id='Simple²saturation'. It will show the saturation level for the displayed colors. It should have text in it by default, if only a blank space, with no other tags, at the beginning. - There should be a tag with
id='Simple²lvl'. It will show the Brightness/Value/Lightness level for the displayed colors. It should have text in it by default, if only a blank space, with no other tags, at the beginning. - There should be a tag with
id='Simple²_indicator'. It will show the text-output for the hovered-over color. It should have text in it by default, if only a blank space, with no other tags, at the beginning. - There should be a tag with
id='Simple²_swatch'. It will show the color-output for the hovered-over color that matches the text-output.
CSS requirements:
none.YinYang NíHóng Color Picker™
HTML requirements:
- Your file must be encoded in UTF-8.
- There must be a “wrapper” tag with an
id='YinYangNíHóng'containing:- 3
<canvas>tags - all the corresponding
<input />tags found in the supplied files.
- 3
- The
<input />tags in your file must have the same names, types, & values found in the supplied files. - The first
<canvas>tag is the background with the rainbow-ring and main section of the Yin-Yang. The second<canvas>tag is the “hue swathes” (the animated disks of the Yin-Yang). The third<canvas>tag is the monochromatic gradient (the central part of the color-picker). For best results, if you modify the width/height of these canvases, keep them proportional in size to what is given in the supplied files. Also pay heed to the CSS positioning of these canvases, one over the other. - There should be a tag with
id='YinYangNíHóng_indicator'. It will show the text-output for the hovered-over color. It should have text in it by default, if only a blank space, with no other tags, at the beginning. - There should be a tag with
id='YinYangNíHóng_swatch'. It will show the color-output for the hovered-over color that matches the text-output.
CSS requirements:
- Pay heed to the CSS positioning of the 3 canvases, one over the other, based on their size.
When the user clicks on a registered target element or it otherwise receives “focus,”
the MasterColorPicker is activated.
When activated, the MasterColorPicker “main panel” and “options panel” (see the HTML),
as well as the currently selected color-picker,
all receive the classname “activePicker”.
There are other classnames added to various HTML elements in the MasterColorPicker under other various conditions.
For more detailed info on what classnames are applied and when, please see the comments in the
JS_toolbox/SoftMoon-WebWare/Picker.js file.
To modify these used classnames, modify the values of the JavaScript™
properties of MasterColorPicker.classnames.
By understanding when and why these classnames are applied,
you can create your own CSS file to control the dynamic display of the MasterColorPicker.
Adding & removing color-pickers
You may add your own color-pickers to, or remove individual color-pickers from the MasterColorPicker framework.
To remove one or more of the included color-pickers, simply remove its HTML
and JavaScript™ from the given files.
The sections are clearly deliminated with comments.
The x_ColorPicker JavaScript™ Class is universal to
all color-pickers in the MasterColorPicker framework, and should remain.
Don’t forget to lighten the weight of the CSS file, but that is not a requirement.
Adding your own (or someone else’s) color-picker is easy.
Its HTML should be included within the MasterColorPicker_mainPanel (see the supplied files),
and its id should match the choice offered in the palette_select.
You should of course add this choice to the palette_select.
The palette_select choice may have spaces to match the “display name” of your added color-picker,
and these will be removed when matching an id;
for example a choice of “YinYang NíHóng” corresponds to id “YinYangNíHóng”.
To interface another color-picker with the MasterColorPicker framework is easy,
but as powerful things go, this process has details that must be understood to fully utilize.
Most simply, when a color is selected, using JavaScript™,
simply call MasterColorPicker.pick(……colorChoiceText……);
however this bypasses the central x_ColorPicker framework which can
convert the choice to the user’s color-space preferences,
and set the color of “color swatches”.
Using the x_ColorPicker framework is a bit different, as it is “event” oriented.
Please read the comments in the MasterColorPicker.js file regarding the x_ColorPicker framework,
but here are some basic additional notes.
The x_ColorPicker framework offers
a handleMouse method for onmouseover, onmousemove, and onmouseout events,
and a handleClick method for onclick events.
They require two arguments passed in, yet browsers only pass in the first by default: the event object.
So you must either use your own event handler which calls these x_ColorPicker methods,
or, more conveniently, use the UniDOM framework that is included with this package to add these methods
as event handlers.
Take a close look (in the MasterColorPicker.js file at the end of each color-picker’s section)
at how the supplied color-pickers add their event handlers using the
UniDOM framework, and how the args object is passed on to the x_ColorPicker methods
by adding it as a final argument passed to UniDOM.addEventHandler(………).
Building your own color-pickers
SoftMoon-WebWare’s Picker Class framework
on which the MasterColorPicker is based is a powerful tool that creates
an <input /> “type = picker”.
Your color-picker can be as complex as you need it to be, with multiple “interface panels,”
interactive inputs that modify the picker and/or its choices, etc.
Please carefully read the JS_toolbox/SoftMoon-WebWare/Picker.js file and its comments
about “registering” these interface panels and interface elements.
Registering them adds the necessary event handlers for them to work correctly with the MasterColorPicker framework.
All HTML elements that require keyboard “focus”
(such as <input type='text|file|number|etc.' /> <select> <textarea>)
that are part of your picker must be registered
using MasterColorPicker.registerInterfaceElement(……element……).
Note how you can use this feature to replace the <input type='range' /> elements in the supplied files
with <input type='text' /> elements if you register them.
This will allow users to enter illegal or overwhelmingly large values, so to get this to work properly,
you should also add a plethora of JavaScript™ keyboard filters
to make sure that, say, the variety value on the RainbowMaestro isn’t set for 10,000 which would lock up the
display for a few minutes or so (multiply by 5 for MSIE)
while the millions upon millions of calculations are done.
The “options” panel
The HTML options panel may offer your users more control of the returned color than you need them to have.
You may only want values returned as hexadecimal-RGB, or whatever.
The color-pickers included in the MasterColorPicker project all rely on
SoftMoon-WebWare’s JavaScript™ rgb Class for all their
color-space conversion needs.
This class has several flags that you can set
(see the comments in the JS_toolbox/SoftMoon-WebWare/rgb.js file),
and simply remove the options from the HTML options panel.
The palette_mode must remain in the HTML somewhere
(to work with the x_ColorPicker framework),
but it can be reduced to something like:
<input type='hidden' id='palette_mode' value='hex' />.
If you do remove options from the options panel, you may remove some, most, or all of the file
color-pickers/SoftMoon-WebWare/color-space_autoReformatter.js.
The MasterColorPicker_optionsPanel may be moved into the
MasterColorPicker_mainPanel (see the comments in the file) and if using the supplied CSS file,
it will pop-up and pop-down with the main panel, or if you know CSS,
it’s a simple modification to the CSS file to achieve the same result.