Mike Bostock

Pretty close, but it would be much nicer if you could express inline syntax for a gradient rather than having to create the linearGradient element in SVG. I think we...

> Is it acceptable? Is there any way we could make it better? I think it’s probably fine, and better that throwing an error. If we wanted to be fancier,...

> The trouble with ticks is that there is a lot of occlusion Sure, but it’s easy to do, and there’s precedent, and it’s sometimes useful. I would _also_ like...

> We should aim for a consistent approach (brush, lasso, pointer) and just show the selection region as an overlay of the corresponding shape. Consistency is generally a good thing,...

Here’s my other idea for a visual representation of the logical selection. The first video is mode *xy*, the second mode *x*. https://user-images.githubusercontent.com/230541/151676770-28a3b5de-60a3-4b66-b072-c241f5725aa1.mov https://user-images.githubusercontent.com/230541/151676771-e8837560-25aa-493d-aea6-72100fcd4cb0.mov It looks kinda neat, but I...

> Rather than mode, could we use pointer, pointerX and pointerY? Maybe a different interpretation of your comment is that pointer means _mode_ = *xy*, pointerX means _mode_ = *x*,...

> I'm confused by your remark since dotY does accept both x and y Oh, whoops. I got confused because it wasn’t always that way; prior to 5b81573b374129f7d1811d0644ba6e2625841472 dotX forced...

Okay, I think I got it in the latest commit. Now brushX and brushY allow you to specify _y_ and _x_, respectively. And pointerX and pointerY similarly only provide defaults...

I’ve implemented persistent selection (click and drag, and shift-click and drag). Let me know what you think, @Fil!

Some open tasks: - [x] Allow *fill* on pointer. (It’s currently overridden by fill="none".) - [x] For one-dimensional pointers, draw blue rules rather than dots? - [x] Change the default...