color.equals() should not rely on object equality

[LeaVerou]

I just spent a while debugging some pretty hairy issue where using equals() on two equal colors produced false. Turns out our equals() implementation uses object equality, which fails in a number of cases.

Some ideas for how to address this:

1. Change how equals() works: convert both colors to the same color space if they are different. We can have a separate strictEquals() for what it does now.
2. If checking color spaces fails, compare space ids. Or just compare space ids to begin with (will fail with anonymous spaces, though it's unclear whether we support this well right now)
3. If the current check fails, serialize the colors and compare that (making sure to override any default formats) (issue: slower)
4. Implement a ColorSpace.equals() and defer to that.

[kleinfreund]

I wanted to mention a use case because I just came across this issue:

I didn't know about color.equals() and a piece of code that I'm currently working on uses colorA.distance(colorB) === 0 && colorA.alpha === colorB.alpha instead. Now aside from this potentially not being appropriate (I don't know, all my existing tests pass so introducing it seems to work on a surface level glance), dropping in colorA.equals(colorB) doesn't work on first try (my tests start to fail in a few places).

Some colors I want to consider as equal in my use case then turn up as different even though they have the same coords and alpha when compared in the same space. This could potentially be related/caused by this issue.

[LeaVerou]

I wanted to mention a use case because I just came across this issue:

I didn't know about color.equals() and a piece of code that I'm currently working on uses colorA.distance(colorB) === 0 && colorA.alpha === colorB.alpha instead. Now aside from this potentially not being appropriate (I don't know, all my existing tests pass so introducing it seems to work on a surface level glance), dropping in colorA.equals(colorB) doesn't work on first try (my tests start to fail in a few places).

Some colors I want to consider as equal in my use case then turn up as different even though they have the same coords and alpha when compared in the same space. This could potentially be related/caused by this issue.

If space conversion is involved, I'd use Math.abs(distance) <= Number.EPSILON rather than comparing with 0 to account for precision errors.

[kleinfreund]

If space conversion is involved, I'd use Math.abs(distance) <= Number.EPSILON rather than comparing with 0 to account for precision errors.

That's likely a good call, yes. Thanks!

My use case is a color picker and the application for the color comparison is to avoid firing a change event when the color hasn't changed. So if a precision error would get through the 0 comparison, it wouldn't be too bad and maybe some would expect the change event to fire in these cases. Still, I lean toward using a comparison that accounts for precision errors, too.

(Feel free to mark this as off-topic if you want to keep this issue more focused)