color <funciri>

[mbostock]

Fixes #362. Also fixes an unfiled bug where “none” or “currentColor” with surrounding whitespace would not properly be recognized as a constant color.

[Fil]

This is so cool!

A side issue with the function marks in the examples snapshot tests is that the technique isn't perfect when using faceting: in that case the <defs> end up being repeated in each facet.

We could do something like

 (function() { let i = 0; return () => i++ ? null : svg`…` })()

but it's quite a lot to expect of the user. Related: #501

[mbostock]

A side issue with the function marks in the examples snapshot tests is that the technique isn't perfect when using faceting

True, but that doesn’t seem like it should be a blocker for this PR.

I’m not sure what approach we want to take here. Some possibilities…

1. I don’t think that marks should be stateful (which would make them harder to compose and reuse in novel contexts).
2. We could have a “defs” property that is parallel to marks where you can put hooks for rendering into a defs element, but that seems very special purpose for this feature, and I expect we want something higher-level for creating patterns and gradients (eventually).
3. We could pass an additional argument to mark.render that indicates faceting. Technically this is already true because the axes argument is undefined when faceting, but we still don’t know which facet is being rendered. I do feel like mark.render already takes too many arguments though.
4. A render hook for scales? That’s really what we want here—the patterns are to support the color scale. If we wanted to support textures as a built-in scale type, we’d need to provide a way for scales to “render” their supporting elements.

It’s probably worth moving this discussion to another (possibly existing) issue. I don’t see that there’s anything blocking us from supporting funciri for color.