XYZ color picker confuses 0..1 and 0..100% range

[svgeesus]

The XYZ-d65 color picker has 0..100 scale but gives black for [0,0,0] and an oog color close to white for [1,1,1]; it is not possible to pick any other colors due to the slider granularity.

[svgeesus]

@LeaVerou

[LeaVerou]

Maybe the max granularity shouldn't be 1 but .1? Take a look here and tell me how you think we should fix this generically. We can't just special case XYZ.

[svgeesus]

let {name, range, refRange} = meta;
	name = name || id;
	range = range || refRange || [0, 100];
	let [min, max] = range;
	let step = (max - min) / 100;
	if (step > 1) {
		step = 1;
}

Since xyzd65 and xyzd50 don't declare a range, they end up with [0, 100] and (100-0)/100 should be 1 but is, I suspect, something like 1.00000000000001 and thus greater than 1. An epsilon in there would catch this and make it more robust. Although why forcing there to be only 100 steps is beneficial could also be examined.

[svgeesus]

Giving the relative XYZs a reference range of [0, 1] would also work.

[svgeesus]

(confirming this UI bug still exists)

[LeaVerou]

Is this issue still present on https://apps.colorjs.io/picker/ ?
If so, please transfer to the apps repo.

[svgeesus]

Confirming that the issue still exists, because [0..1] and [0..100] are being confused

[LeaVerou]

What should the range be for each XYZ space?

[svgeesus]

As I said earlier:

Giving the relative XYZs a reference range of [0, 1] would also work.

[LeaVerou]

@DmitrySharabin could we integrate the <color-picker> component to use here so we don't maintain similar code in two places?

[DmitrySharabin]

@DmitrySharabin could we integrate the <color-picker> component to use here so we don't maintain similar code in two places?

@LeaVerou, I integrated the <color-picker> component (preview and corresponding PR). Please take a look.

[LeaVerou]

Thanks @DmitrySharabin! Is this issue present in <color-picker> too? If not, we should close.

[DmitrySharabin]

Is this issue present in <color-picker> too?

Unfortunately, it does. As @svgeesus mentioned, since xyzd65 and xyzd50 don't declare a range, they end up with [0, 100] (here and here). In <color-picker>, we don't fall back to [0, 100] (when calculating the default color) expecting that all the color spaces declare ranges for their coords (that make <color-picker> throw for the mentioned color spaces).

So, to solve this issue, we should probably declare ranges for those spaces. As Chris said:

Giving the relative XYZs a reference range of [0, 1] would also work.

[LeaVerou]

Yeah, let's do that.