Posts Tagged ‘colorpicker’

Firefox DevTools Experiment – Pixel Inspector

Monday, September 2nd, 2013

Heather and I spent some of our @FirefoxDevTools team meetup working together on an experiment we named the Pixel Inspector. The idea is to focus on an individual region of the page with an eyedropper to pick colors and a zoom feature to debug tricky alignment issues. You can get separate programs that do some of this, such as Digital Color Meter, or addons like ColorZilla, but it would be great to have something built into the developer tools to do this. Here is how it works:

  • Open the panel with a keyboard shortcut or by clicking a button in DevTools.
  • Move your mouse around the page to the location you want to inspect. Click on the pixel to lock it in place.
  • Use the zoom slider to increase the size of each individual pixel.
  • Press the ‘Copy’ button to copy the color to your clipboard, or use the format dropdown to change the color format.

See the screencast and screenshot below to check it out. Would this be a useful feature to add to DevTools?

pixel inspector

How does it work?

Pixel Inspector makes use of the drawWindow canvas method (which is only available with “chrome only”, meaning a script running with elevated privileges that has access to browser internals). There is an additional flag, named context.mozImageSmoothingEnabled = false; that allows the image to get the pixelated effect we want. Most of the code can be seen in this file:

Devtools Colorpicker Palette

Saturday, February 2nd, 2013

I’m still trying to figure out how to get a list of all the colors in use on a page from within devtools, but I’ve been hacking together a little demo with a custom Web Inspector frontend that loads a color palette on the side.

When you click one of the swatches, it sets the current color of the element. The idea is that it would include all the colors in your page, maybe ordered by most used. Possibly could even get more advanced and suggest a set of complementary or analagous colors based on your current selection.

A prototype implementation of a palette using color swatches within devtools

A prototype implementation of a palette using color swatches within devtools

Devtools Colorpicker

Monday, July 2nd, 2012

It is great that so many important platforms that we use on the web are open source, and open to contributions from anyone.

It took a lot of work, but it was worth it. I’ve been doing some web design work recently, and love how much easier it is to play with different colors in a design.

Now I’m thinking of different ways that design work could be further improved with the colorpicker. A couple of ideas right now: (a) an eyedropper to select a color from the screen and (b) a color palette consisting of currently used and recommended colors.

Chrome DevTools Colorpicker Screencast

Thursday, April 19th, 2012

I put together a screencast explaining the colorpicker functionality recently added into WebKit Web Inspector (aka Chrome DevTools for brevity). For some backstory on how this got implemented, check out my initial colorpicker concept video or the description of the implementation.

Here is a quick screencast showing off the colorpicking functionality (currently running in Chrome Canary):

Unable to display content. Adobe Flash is required.

Oh, and the jQuery plugin I am working with is called unmodal.

Input Type=Color Polyfill

Friday, April 6th, 2012

My jQuery Colorpicker – Spectrum now has a mode that acts as a polyfill to input type=color.

What this means

Now that the color input is supported in Chrome nightlies, along with Opera, people may want to start using this cool new form element.

While you can still customize the colorpicker and bend it to your will, if you’d like to use this new mode just include the HTML:

<input type='color' value='#4499f0' />

Along with a reference to spectrum.js and spectrum.css:

<link rel='stylesheet' href='spectrum.css' />
<script type='text/javascript' src='spectrum.js'></script>


See the color input polyfill demo page for more info!

Chrome Developer Tools Colorpicker Implementation

Saturday, February 25th, 2012

A few months ago, I posted about my developer tools concept colorpicker implementation. After that, I was contacted on the devtools mailing list and got some initial feedback. I pulled the jQuery dependency out of a branch on my JavaScript colorpicker using jsfiddle plus the mailing list. From there, I submitted a patch to the WebKit project.

From there, I opened a development case, entitled Web Inspector: Add colorpicker functionality to color swatches in Styles Sidebar. 50+ comments and 10 patches later, the case landed in WebKit. This is really exciting, since it will improve the development experience for Chrome and Safari users. Thanks to all the WebKit developers who helped me along the way with getting the code and UI ready for committing (I needed all the help I could get).

I am planning on sharing more of the technical details and hurdles I had as a first time contributor to the WebKit project in a coming post.

Colorwheel 1K

Sunday, February 12th, 2012

I decided to make an HSV colorpicker for the js1k contest. Here is a demo of the colorpicker and the source code.

Getting Started

I found a great start for actually drawing the wheel at the canvas color wheel post from Ariya Hidayat. I modified that code and got the wheel on the screen in no time.

Also, I had written TinyColor, a JavaScript color parsing library, so the HSV to RGB conversion function was pretty easy to grab (though I did have to make some changes to shrink the function size, more on that later). This let me remove some of the code from the color wheel function that I also needed on mouse move events.

I tied together some buggybasic bounds checking on the circle for mousemove events and printed out the current RGB using the conversion function above, and I had a cool little demo – weighing in at around 2K.

Smaller… Much Smaller

So I needed to drop about half the weight of the project. I learned that you could use ~~x instead of Math.floor(x) provided that the number is positive, so that helped. And there are always tricks about passing in assignments to functions to save a semicolon, storing references to global objects, commonly used math functions, and so on. But it was not quite the time for dropping individual bytes, I needed some big changes.

First, DOM and CSS rules take up a lot of bytes. b.appendChild(d.createElement("input")) is just huge and cannot really be minified beyond what is there. My takeaway was that I needed less DOM elements. I was originally using a container div with a width equal to that of the canvas (400px) and had a little ‘spot’ div that was absolutely positioned based on the current X and current Y value. All of these lines are problems when are you trying to squeeze an ‘application’ into 1k:

container = b.appendChild(doc.createElement("div"));
spot = b.appendChild(doc.createElement("b"));'position:absolute;width:400px;margin:auto''position:relative;height:5px;width:5px'

By moving this functionality into the canvas drawing method (with fillRect, and later fillText), I dropped a couple hundred more bytes.

Next, the hsvToRgb conversion function got an overhaul (it went from 291 bytes to 205, and 33 of those are for the CSS color rule needed for the RGB background color). Takeaway here is that case statements have a lot of control characters, and this particular one was nicely shrunk down using 3 arrays.

// 291 bytes <a href=''>minified</a>.
function hsvToRgbBIG(h, s, v) {
    var r, g, b;
    var i = math.floor(h * 6);
    var f = h * 6 - i;
    var p = v * (1 - s);
    var q = v * (1 - f * s);
    var t = v * (1 - (1 - f) * s);
    switch(i % 6) {
        case 0: r = v, g = t, b = p; break;
        case 1: r = q, g = v, b = p; break;
        case 2: r = p, g = v, b = t; break;
        case 3: r = p, g = q, b = v; break;
        case 4: r = t, g = p, b = v; break;
        case 5: r = v, g = p, b = q; break;
    return { r: r * 255, g: g * 255, b: b * 255 };
// 205 bytes <a href=''>minified</a>.
// Also includes the css color rule as the final return value.
function hsvToRgbSMALL(h, s, v) {
    var i = ~~h,
        f = h - i,
        p = v * (1 - s),
        q = v * (1 - f * s),
        t = v * (1 - (1 - f) * s),
        mod = i % 6,
        r = [v, q, p, p, t, v][mod] * two55,
        g = [t, v, v, q, p, p][mod] * two55,
        b = [p, p, t, v, v, q][mod] * two55;
    return [r, g, b, "rgb("+ ~~r + "," + ~~g + "," + ~~b + ")"];

From there, it was mostly reorganizing and adding hacks to make the code smaller. A tip for anyone trying to do this: I wrap all the code into a executing function, so that minifiers will use one letter names for variables (rather than assuming they are global). Then I run the code through Closure Compiler online frequently when making changes to see how effective changes are. Don’t forget to remove the wrapper from the minified file, though!

(function() {
    var oneHundred = 100;
    // All code goes inside here


I finally got to 1024 bytes! It was a fun project, I will probably to it again when another js1k comes along.

Keep Aspect Ratio With HTML and CSS

Wednesday, September 28th, 2011

When working on my javascript colorpicker, one of the things I thought would be really cool is if you could resize it and have the colorpicker automatically respond to different widths. When I first made it, I had basically defined static widths with the thought that there could be different themes (small, normal, large) which defined different widths.

This turned out to be a pain, since you had to manually figure out what each width needed to be for the total size. To complicate things further, I wanted to have a different percentage width when accessing the colorpicker via an iPhone. I found that the hue slider was a little too small to accurately slide with the touch interface, so I wanted it to take up more of a percentage of the total width. I’m can be lazy about calculating widths in CSS, so I went off looking for a different way to do this.

Aspect Ratios

Why couldn’t I just use percentage widths? Because the left portion of the colorpicker needs to be a square – or else the gradients for saturation and value just look weird and don’t really map up 1:1. I did some searching and found a CSS workaround to keep the aspect ratio of a fluid element by ansciath. The meat of this trick is that according to the spec for margin-top, a percentage refers to the width of the containing block, not the height. This post got me much of the way there, but I had to include a couple of fixes for IE and ways.

The really nice part about using this technique is that it makes spectrum extremely easy to skin in your own CSS. Check out ColorStash for an example of this. Using media queries and max-widths, I can change the width of the colorpicker as the browser resizes to get some really responsive behavior on a UI control (colorpicker) that has typically been very static.


See the demo of the aspect ratio and media query. Try resizing your browser window to under 480px width to see the switch happen. Here is the full source code for the demo.

Below is a snippet showing the basic HTML/CSS needed for this technique:

<div class='container'>
    <div class='outer'>
        <div class='fill'></div>
        <div class='inner-top'>
            <div class='square'>Always a square</div>
            <div class='right'>% width</div>
    <div class='bottom'>
.outer {
  width: 100%;
.inner-top {
   position:absolute; top:0; left:0; bottom:0; right:0;
.square {    
    position: absolute;
.right {
    position: absolute;
    background: purple;
.fill { 
    *height: 80%;
    margin-top: 80%;  /* Same as square width */
@media (max-width: 480px) {
    .square { right: 51%; background: blue; }
    .right { left: 51%; }
    .fill { margin-top: 49%; }