Should we revise the rule for including zero in positional scale domains?

[domoritz]

Vega-Lite always includes zero in the positional scale domains. Maybe we should only do it for marks that have an area (bar, area) but not lines/points/etc.

See https://github.com/vega/vega-lite/blob/master/src/compile/scale/properties.ts#L397

[jwoLondon]

No sure I see the logic in the mark determining the scaling. If anything, zero origin should be a property of measurement type (nominal, ordinal, interval -> not zero; ratio -> zero). e.g. an area chart showing temperature would probably not have a zero origin, but a line chart of counts probably would.

But given this is more often an issue of context I think it better to leave it for all marks by default for backwards compatiblity.

[domoritz]

One could argue that when we have e.g. line marks, we don't need to include 0 in the y scale domain since the line encodes with position, not length. I agree that context matters more and users should always be able to change the default but I am wondering what a good default is.

The reason why I bring this up is that Datawrapper changes whether to include 0 based on the mark type: https://twitter.com/wisevis/status/1346522488575033344/.

Example: bottom two is what we do right now, first is what we could be doing by default.

Open the Chart in the Vega Editor

[jwoLondon]

If the logic is that in area charts we are integrating the shaded area, I'd suggest we mentally integrate the area under a line too.

I think with a non-zero default for quantitatively scaled line charts, there is a greater risk of people creating poor charts by accepting a non-zero default than accepting a default zero origin. An advantage of the zero default is that if the scaling ends up being very poor (e.g. a variation between 99-100 with a zero origin), it is immediately visually obvious, whereas, like your top example, a potentially misleading non-zero origin is more subtly problematic and so less likely to be changed.

[domoritz]

I like your point about it being obvious that zero should not be included and including zero being safer to not be misleading.

Being safer by default is better than being a less effective (including zero reduces the distance used to encode data).

[kanitw]

In #8324, we're discussing about making this configurable.