paint

[mbostock]

This introduces a paint method for specifying SVG paint servers, namely patterns and gradients.

In contrast to the render function approach and function uris, this approach eliminates manual management of unique identifiers, and lets you specify the desired paint inline, in one place — either as a constant fill or stroke option, or the range of an ordinal color scale (and perhaps even a quantitative scale?).

This also lets us offer convenience constructors for common paint servers such as linearGradient. We have to decide how much of the CSS specification to implement… but you could always go beyond that with a custom paint method. We should also decide whether e.g. color stops are expressed relative to the object bounding box, or if the stops should be positioned in data space. The former is the SVG default, but the latter allows more meaningful encodings in visualization.

TODO

• Types
• Documentation
• Tests
• Allow fill to be specified as a constant paint
• Allow fill to be specified as a paint channel
• Allow stroke to be specified a constant paint
• Allow stroke to be specified as a paint channel
• Allow ordinal color range to be specified as an array of paints
• Assign unique identifiers when rendering paints
• Design a linearGradient API… userSpaceOnUse or objectBoundingBox?

Fixes #185 #903 (with additional work).

[Fil]

Sounds promising! (Also, somehow related to #1132 / #1109, for the attribution of a unique id.)

I'm trying to think about how we would express these gradients in the API.

A few use cases for data encoding:

• https://observablehq.com/@d3/variable-color-line
• https://observablehq.com/@d3/gradient-encoding
• https://observablehq.com/@d3/threshold-encoding

These cases are arguably (more or less) covered by the variable stroke feature. They have a color that depends on the datum (x or y), and an orientation that can be horizontal or vertical. The corresponding stops would have to be sorted and normalized into 0%—100%, or, alternatively, generated with ticks?

• https://observablehq.com/@d3/sankey/2

(Assuming we had sankey paths as a mark, but we can think of it as a link mark.) In this case the orientation would be given by the direction of the mark (source to target). Each individual mark would need two colors, either constant or a channel: one for the source and the other for the target.

There might be more use cases that we'd want to support.

Then there are "aesthetic" use cases, for example to paint each country with a gradient to give some visual dynamism to a map. In that case we need the orientation and n colors.

A secondary question is how do we make the ids predictable? Would they be some sort of a hash of the parameters+a counter?