automatic color identity scale #673
Conversation
|
There is always going to be a situation in which these default colors are surprising. In this case, if the categories are ["orange", "apple", "banana"] only the orange will show; but if they are ["apple", "banana", "orange"], everything will show (and the "orange" category will be blue or something). This situation is what I had in mind when I suggested that there could be a different type of default ordinal color scale which would be (roughly) a pass-thru for valid css colors, and turbo10 for the others. Also identity doesn't allow to have a legend, so we can't use the legend to inspect what the invalid fields are. |
Totally, but the idea is that you can address those by setting the scale’s type explicitly. And this test is cheap and consistent with our other tests (e.g., to disambiguate ordinal from quantitative or temporal data).
I think that’s also expected and desirable. And if you want a legend, you just set the scale type to ordinal or whatever. |
|
One other thing is that we could explicitly disallow named CSS colors (and thereby require rgb(…) or #rrggbb etc.). I suspect named colors will be responsible for nearly all the ambiguous cases. Of course then folks still might get confused why () => "red" doesn’t give you red. |
* only identity if all values are colors * comments
| // valueOf to work correctly with InternMap. | ||
| export function isColor(value) { | ||
| if (!(typeof value === "string")) return false; | ||
| value = value.toLowerCase(); |
There was a problem hiding this comment.
that's new. css colors are case-insensitive, so should we mention it as a bugfix?
There was a problem hiding this comment.
Yes, this does fix a bug. I’d be surprised if anyone encountered it, but we could mention it.
Alternative to #660. For the color scale, if at least one value is defined and all defined values (from the domain if specified, and otherwise from channels) are valid color strings, default to an identity scale rather than some other type.