An identity (?) scale type that effectively disables the scale, so that you can define channels in visual values (e.g., literal colors or pixels)?

[Fil]

Note: D3 doesn't have an "identity" scale in that sense (d3.scaleIdentity coerces values to numbers).

[mbostock]

The current proposal in #57 (and the title of this issue) introduces an identity scale, affecting the scale definition, but I wonder if this should be part of the channel specification when instantiating a Mark. If tied to the scale definition, then you can only turn the scale off for the entire plot, whereas if it’s part of the channel specification, you can turn the scale off selectively for a specific channel.

Imagine the case where you have a Plot.barX and you want to specify the fill color as visual (unscaled) values, but dynamically. If you set color: {type: "identity"}, any other mark in the same plot now also requires unscaled colors. Whereas if you change the Plot.barX specification somehow, you can affect the bar’s fill color definition without affecting other marks (and even other color channels on the same mark, say stroke).

In the past, marks had a “style” option namespace that was intended for visual values. So, for red bars:

Plot.barX(data, {style: {fill: "red"}})

In contrast, to refer to the field “red” in the data:

Plot.barX(data, {fill: "red"})

I didn’t like this approach very much because the namespace “style” didn’t meaningfully capture the difference between the two (and was easily confounded with CSS). Also as a practical matter, it was tedious for mark implementations to support both: they had to declare two channels, one scaled and one unscaled. So, in 2b797cc I got rid of the style namespace and instead detected when a color was specified as a name. Now this gives you red bars:

Plot.barX(data, {fill: "red"})

And to refer to the “red” field in data, you must specify an accessor or an array of values:

Plot.barX(data, {fill: d => d.red})
Plot.barX(data, {fill: data.map(d => d.red)})

Similarly, for Plot.dot’s r channel, a number value indicates an unscaled constant, while anything else is a scaled channel.

This new approach is very convenient and concise for the common cases, but it does make some strong assumptions: it assumes that you only need to differentiate between constants and scaled channels, never between scaled channels and unscaled channels, which is in effect what is being asked for here.

So, here’s an alternative for consideration:

Plot.barX(data, {fill: {value: "red"}}) // literally red
Plot.barX(data, {fill: "red"}) // the same

Plot.barX(data, {fill: {field: "category"}}) // the field named “category” in data, scaled
Plot.barX(data, {fill: {value: d => d.category}}) // the same
Plot.barX(data, {fill: "category"}) // the same
Plot.barX(data, {fill: d => d.category}) // the same

Plot.barX(data, {fill: {field: "color", scale: null}}) // the field named “color” in data, unscaled
Plot.barX(data, {fill: {value: d => d.color, scale: null}}) // the same

This approach would affect the fill channel’s declared scale, rather than having it hard-coded to color:

plot/src/marks/bar.js

Line 30 in 6658dcb

{name: "fill", value: vfill, scale: "color", optional: true},

This would also allow dual-scale (dual-axis) charts, if you could say that one line’s y mapped to y1, whereas another line’s y mapped to y2. Of course, dual-axis charts are kind of a bad idea, so supporting that isn’t especially high on my priority list and it would require extra machinery to render dual axes besides.

Anyway, I’m just thinking out loud here. I’m not sure we want to expose this level of control — I think it might be a useful constraint that marks have fixed channel definitions (with fixed scales). And it might similarly be a useful constraint to only turn the color scale “off” at the plot rather than channel level.

[Fil]

Would this also allow to opt-in with scale: "color2" ? (not only opt-out with scale: null?)

Then we could have a plot in which some marks are bound to null-scale, others to "color" (which would be the default for "fill" and "stroke"), others yet to "color2", and the scales could be shared.

Another application is for cases where fill and stroke need different scales—e.g. grays for fill and rainbow for stroke.

[mbostock]

Yes, that’s another example of dual-scale (or multi-scale). Though Plot would still need to understand that “color2” is a color scale in the scale registry, presumably. And I’m a little concerned that this adds more complexity than we need. For example, allowing multiple color scales will presumably make it harder to implement color legends. #23

[mbostock]

Not planning on addressing this now for the sake of simplicity, but might revisit if we feel we need more expressiveness.

[Fil]

I wonder if there would be a general way of “opting out” of a scale from the mark. That is, rather than to say "the color scale should be identity" (from the global scale definition), say "this particular mark will use the raw ‘fill’ value". I think it's closer to the use cases we have in mind.

In terms of syntax/API, this might be anything. Here are a few possibilities:

• Plot.dot(data, {x:…, y:…, fill: "raw:rgb" })
• Plot.dot(data, {x:…, y:…, fill: { value: d => d.rgb, scale: null }) // this opens a choice of an alternative scale
• Plot.dot(data, {x:…, y:…, directFill: "rgb" })
• Plot.dot(data, {x:…, y:…, _fill: "rgb" })
• Plot.dot(data, {x:…, y:…, fill: "rgb", color: null })
• Plot.dot(data, {x:…, y:…, fill: "rgb", colorScale: null })
• Plot.dot(data, {x:…, y:…, fill: "rgb", scales: {x: "x", y: "y", color: null} })

(Note: this issue is now much easier to deal with, since marks receive the scaled channels.)

[mbostock]

I briefly did some more sketching here yesterday:

https://github.com/observablehq/plot/compare/mbostock/identity-scale

I’m no longer 100% convinced that this needs to be done at the channel level. That’s certainly more expressive, but I think it could be simpler to just turn “off” a scale by redefining it as an identity scale.

I think the open question for me is whether you still want guides if you have identity scales. Like, would you still want axes? In most cases that I’ve seen the answer is no, but I could still imagine wanting an axis even with an identity scale. I’m not sure it would be possible to do a color or radius legend, though… so maybe it’s fine if that’s not possible.