Parsing rgba() and hsla() values about d3-color

[mbostock]

And, d3-interpolate now supports opacity interpolation as of release 0.5.2! For example:

var i = d3.interpolate("transparent", "red");
i(0.5); // "rgba(255, 0, 0, 0.5)"

[mbostock]

I couldn’t think of an elegant way to represent optional alpha without adding it to all color spaces, and then it didn’t seem very useful. (Also, you couldn’t name it a as in RGBA, because then you’d have two a channels for Lab color.)

It would be possible to strip out the alpha channel when parsing CSS rgba(…) and hsla(…) specifications, but I don’t see this as immediately useful so I haven’t been motivated to implement it. Perhaps you could elaborate on how would you use it?

[davelandry]

I have a function that calculates the perceived color displayed on screen when depicting a slightly transparent color on top of another color (ex. 50% black on top of white looks grey).

Kind of an edge case I know, but I'm rolling it out into a large color utility and love the way your new d3-color module validates colors (returns null instead of just black for non-colors). Even if you just parsed out the appropriate RGB and HSL values and didn't touch the alpha channel, I could parse that out on my own.

[davelandry]

My buddy @alexandersimoes had a quirky idea: naming the variable after the actual greek alpha symbol: α

[mbostock]

Another option would be an object that represents a color and an opacity. So like, call it a “paint”:

function paint(string) {
  return {
    color: …,
    opacity: …
  };
}

So the returned paint.color would be a color instance (such as rgb or hsl) and paint.opacity would be a number between 0 and 1 inclusive. If you pass it an rgb(…) string rather than an rgba(…) string then opacity would be 1.

[mbostock]

naming the variable after the actual greek alpha symbol

We used greek names for many private variables in D3. It arguably improved the readability of the (mathematical) code, but it came at the expense of confusing people unfamiliar with character encodings. At the time, it felt like a reasonable trade-off since character encodings are such a critical concept. But I’ve softened my stance on that, and I’m not planning on using non-ASCII characters for the new D3 modules.

Even then, I wouldn’t recommend using them for a public API, if only because they can be tedious to type. You can enable the Greek input source (γνῶθι σεαυτόν), but that shouldn’t be a requirement. And copy-paste to type is a pain.

Edit: I cheated and copy-pasted that.

[davelandry]

👍

[davelandry]

oh man, that's super sexy