"filledpoint" macro?

[kanitw]

Two motivations:

1) Going from "mark": "point" to "mark": {"type": "point", "filled": true} is quite annoying to type.

2) More importantly currently config.point is optimized for unfilled points. (As shown below, the default size is kinda small for filled points). Having another set of separate config is probably helpful.

[domoritz]

Then we should remove circle?

[kanitw]

They are redundant, but I don't think it warrants a breaking change. I'd prefer to keep them.

[domoritz]

We can deprecate circle.

[g3o2]

As a complimentary note, point and circle appear both misleading terms in the context of vegalite, for point's default setting looks like a circle, while circle looks like a filled point.

[kanitw]

We can deprecate circle.

We can, but I don't think we should.

As a complimentary note, point and circle appear both misleading terms in the context of vegalite, for point's default setting looks like a circle, while circle looks like a filled point.

I'm not sure why is that misleading. Point can has many shapes and the default shape is circle. Circle is literally a shortcut for a filled point. (Tableau does exactly the same thing for "point" and "circle". Ggplot also has a simliar point "geom")

[arvind]

I'm a little wary of increasing the number of mark entries, especially if the primary motivation is to shortcut something that is already a relative minor and localized change to the specification. I worry about the redundancy/duplication this would add to the language (and the related costs that assess in terms of learnability/documentation/maintenance/etc.). For example, would the default filled-point be equivalent to circle? And now that fill is itself an encoding property, would both of those be equivalent to point + fill? And would we still maintain the mark.filled boolean?

This area of the language feels like it is under increasing pressure of feature creep/bloat and so I think we should be extra vigilant and judicious!

[kanitw]

I agree with your concerns, but wanna make a note that the primary motivation is that the default config is not well optimized for filled point.

the related costs that assess in terms of learnability/documentation/maintenance/etc.

There is some additional cost, but they can all point to the same page (like ggplot2 does). So I'd say this cost is relatively small. That said, we will try to keep the number small. For example, I don't think we should introduce "ribbon" like ggplot2 does. Area is sufficient.

For example, would the default filled-point be equivalent to circle?

Yes. We could deprecate circle and square, but given that we have them for so long. I don't want to introduce breaking changes. (If I can go back in time though, I think circle and square shouldn't be included.)

And now that fill is itself an encoding property, would both of those be equivalent to point + fill?

Nope. Because the default stroke will still be applied.
(Adding "fill" shouldn't magically remove "stroke".)

And would we still maintain the mark.filled boolean?

Yes because for normal use case color should be sufficient, but for delicate things like maps, users would need finer grained control over fill and stroke

[kanitw]

Actually if we deprecate square and circle without removing them from the code (but remove from the docs). Then we can reduce the documentation surface (one mark less).

[arvind]

I agree with your concerns, but wanna make a note that the primary motivation is that the default config is not well optimized for filled point.

Fair enough. And apologies if I've been out of the loop and missed this, but have we brainstormed alternatives to the config block instead? That strikes me as a more localized, lower cost change to me.

I appreciate your answers to my individual questions about redundancy, but I almost feel like they bolster my point of increasing the complexity of reasoning about the language. The differences between the various configurations is quite subtle and not immediately obvious. Moreover, it seems to reduce the language viscosity, allowing for things to be expressed that seem contradictory at first glance.

For example, "mark": {"type": "filled-point", "filled": false}. This presumably results in an unfilled circle as the filled property takes precedence, but why would the language allow me to say such a thing? Should we continue to prioritize the flexibility of filled-point over the messiness it also comes with?

[kanitw]

have we brainstormed alternatives to the config block instead

Not sure what you mean here, but feel free to propose an idea.
(This issue isn't set in stone we can still prototype better ideas!)

For example, "mark": {"type": "filled-point", "filled": false}. This presumably results in an unfilled circle as the filled property takes precedence.

A desired implementation is filled should be ignored in this case.

[kanitw]

I think a better solution is to make point+fill work.

Basically, whenever at least of fill or stroke is specified, color channel should be ignored.
This will enforce better specs anyway---If users wanna use color, just use color. If users wanna customize both fill and stroke, directly use fill and stroke (not fill and color or stroke and color).

Note that the default size issue still persist, but that's not worth making the language more complicated.

Thanks @arvind for pushing back :)