"Passes Through" steps feature

[jordwalke]

Hello,

Thank you so much for developing this excellent library. I was imagining a feature that would be very useful. It is a variant of the current steps API.

let color = new Color("black");
color.steps("red", {
	space: "lch",
	outputSpace: "srgb",
	maxDeltaE: 7, // max deltaE between consecutive steps
	steps: 2 // min number of steps
});

The way I understand the current API is as follow:

• Take at least steps steps.
• Each step should be no more than maxDeltaE
• Start at "black" and end at "red" - perfectly.

What I seek is a feature that accomplishes the following:

let color = new Color("rgb(100, 50, 50)");
color.steps("rgb(200, 50, 50)"), {
	space: "lch",
	outputSpace: "srgb",
	minDeltaE: 7, // max deltaE between consecutive steps
	exactNumberOfSteps: 16 // min number of steps
});

Imagine the start and end representing two points along the curve created by both interpolation and extrapolation. They are not the start and end of the resulting steps. The start/end colors (along with other parameters) define a curve in the color space that extends infinitely in both directions, and the start/end merely are points along that curve.

• I then want to take exactNumberOfSteps samples from this curve.
• It's just a "window" of discrete samples from the curve. The contrast between each step should be at least minDeltaE.
• As much as possible, the original start/end parameters should be in the window that is returned. The start/end don't need to actually be in the samples - but ideally they should be somewhere in the continuous curve that is bounded by the sampled discrete samples.
• It is not always possible for the start/end to be in that window. For example you could say start=rgb(0, 0, 0)") end=rgb(255, 255, 255)"), and ask for exactNumberOfSteps=3 with minDeltaE=1. That wouldn't produce enough range for the start/end points to be within the window. But the window could be centered in the start/end points.
• Similarly, you might specify start=rgb(100, 100, 100)") end=rgb(110, 110, 110)") and ask for 16 samples with minDeltaE=7. In that case, the window must extrapolate beyond the start/end points and the start/end points should be as centered as possible within the returned window without clipping. In summary: The window and start/end points should have the same midpoint as much as possible but no more than is possible.

The use case for this is that when creating color themes, people will want to define a starting/ending color - but a design system must create shades in between (or even outside of this range) in order to maintain minimum contrast between shades.

I don't believe this is possible with the current API, unless I'm mistaken.

[facelessuser]

So basically, you want to subdivide only up to the point where the smallest delta E is larger than your target delta E. But then extrapolate that division out to get the remainder of the required steps. Hmm, but maybe that wouldn't always work in some spaces, extrapolating out could revel more cases below the target requiring a re-evaluation of the subdivisions.

Maybe what you want is just a way to take two colors and minimize the interpolation until you have a match to a certain delta E, then you can just manage generating steps in whatever direction and quantity you want.

Whatever the solution, I can't say whether it makes since to have it baked into the library or not, so I'll let others decide if something along the lines of what you are asking should be in Color.js.

One thing is for certain, to do this, you would need iteration timeouts and/or other checks to kick out of the loop when it is unlikely that the target color difference is achievable. Accidentally using two identical colors for instance could cause an infinite loop. Additionally, some color spaces may break down after a certain limit and may interpolate to unexpected results. Unrealistic inputs of delta E (too large for instance), may make impossible targets.

[jordwalke]

So basically, you want to subdivide only up to the point where the smallest delta E is larger than your target delta E.

Really, for a design system - we start with a target deltaE in mind. We don't really think of it as minimum or maximum. It's the desired deltaE. If we had to choose between it being a minimum and a maximum we'd pick minimum because we need "at least this much" contrast. I think of it as "required" deltaE (but with some slop room).
In the happy path, you can imagine this deltaE being fixed.

Then we want to create a continuous spectrum of colors between the start and end colors, and also extending beyond the bookends infinitely. At this point, the start/end colors are somewhere on the spectrum.

Then we want to select the "best" set of exactNumberOfSteps colors from this continuous spectrum. Which samples should we select? The start/end points help you decide which exactNumberOfSteps to sample.

In the happy path, the midpoint of the start/end will be in the mid point of the samples you select. If your samples overshoot the end color, it should overshoot the start color by the same amount in the opposite direction. If your samples undershoot the end color, it should undershoot the start color by the same amount in the opposite direction.

In the not-so-happy path, to achieve exactNumberOfStpes of deltaE contrast, you cannot have the midpoint of the start/end colors be the midpoint of the samples returned. However the following invariants can be maintained:

• The start/end colors are still on the spectrum that is sampled.
• You can come up with exactNumberOfSteps of deltaE contrast as long as you don't clip at black/white (and that's okay if we clip - you gave weird inputs and should expect weird outputs).

[facelessuser]

Okay, so the accuracy of the delta E isn't being prioritized, only that it meets the minimum requirement. There's some more complexity hidden in there to capture what you are looking for, but I think I at least understand what you are aiming for.

I'll let others chime in on whether something like this is generally desired within Color.js.

[jordwalke]

Cool. I think this is pretty valuable for helping people create color schemes for design systems. Because in a design system you start with the following constraints:

• The design system has several "token" colors. (Think: primary blue, surface background dark, danger red etc).
• I know I need n shades per color "token".
• For each "token" color, I need each of those n shades to have E amount of contrast between adjacent shades. (ideally exactly E, but it must be at least E)

Then the person who customizes the design system for their app only has to answer "what is the hue/sat of the token and how dark should it be".
The token may slightly change hue as it goes from dark to light or light to dark.

The most convenient way for a consumer of a design system to specify these things is to give two colors that will be "on the spectrum" of shades. The consumer cannot give you the exact endpoints of the n shades because they don't know if they've covered enough dynamic range to satisfy contrast requirements between shades. But they can easily pick a deep dark red for one endpoint, and a lighter - blue tinted red for the end point.

Then an automated design system would be able to create a sample of n colors based on them.

Maybe there's a way to do it with the current color.js api but I couldn't think of one.

[facelessuser]

I can't speak to how well it will work in practice. Delta E doesn't necessarily translate to consistent contrast. To be honest, I would consider you prototyping it first to see how useful it actually turns out to be. You may find that the results may not align with your expectations. It would also be far more convincing to ship a new "steps" approach with data backing claims that it makes it easier to generate good schemes. I'm personally agnostic to the feature request currently, and skeptical how useful it would be with the steps generating colors extrapolated past black and such.