I probably should have mentioned this in the issue before work got started, but I'd like to take a step back to "redesign" this idea of levels. The main problem is that we have a min/max value to provide for each, which means that the levels never really encompass that number (not visually anyhow). This can be confusing if the consumer did not also provide extra context.
So the question is, is this just an implementation detail and we need to change the docs so that the custom ticks live within the levels or do we find a way to ensure they overlap the values provided (even if the values literally overlap, i.e. max: 25, min: 25?
And then just a general note about "design"... Should we consider replacing the track with the levels instead of trying to show beneath it? At least in the single range version?
Originally posted by @cchaos in #5181 (comment)
I probably should have mentioned this in the issue before work got started, but I'd like to take a step back to "redesign" this idea of levels. The main problem is that we have a min/max value to provide for each, which means that the levels never really encompass that number (not visually anyhow). This can be confusing if the consumer did not also provide extra context.
So the question is, is this just an implementation detail and we need to change the docs so that the custom ticks live within the levels or do we find a way to ensure they overlap the values provided (even if the values literally overlap, i.e.
max: 25, min: 25?And then just a general note about "design"... Should we consider replacing the track with the levels instead of trying to show beneath it? At least in the single range version?
Originally posted by @cchaos in #5181 (comment)