Support width/height channel for ranged mark?

[kanitw]

Currently we only support x and x2 channels.

[g3o2]

As is, adding height and width makes vega-lite more flexible without breaking its interface. Naturally, vega-lite should at least throw a warning when both styles are used simultaneously.

Another consideration is whether vega-lite should further abstract this. However, usage of any style highly depends on the data at hand and at the flexibility of data transforms.

[kanitw]

Sure, but we have calculate object which means we don't really need to add width and height channel, but it might be convenient for users to add (at the expense of quite more complicated internal code).

[g3o2]

Calculate works fine indeed if the data provided are in a "tidy" shape, the argument of convenience being applicable to other data shapes.

[kanitw]

Adding xc / yc may also be useful for violin plot too.

[kanitw]

I wonder if we should avoid adding xc/yc, but instead use align and baseline as a way to mapping x/y channels to xc/yc instead:

1) Image marks already have align/baseline, which seems to be equivalent to the following:

• x+width+align=center => xc + width
• x+width+align=left => x + width
• x+width+align=right => x2 + width

Introducing xc/yc would be redundant and unnecessarily introduce complexity the language surface. It's just more consistent to apply align/baseline to other ranged marks like rect/rule/area.

2. Adding xc/yc can be confusing in many places:
   • x and xc are also the same thing for non-ranged marks (e.g., point, line)
   • x in Vega-Lite is already xc by default for ranged marks in some cases like x-scale of vertical bar (when explicit width is specified). (Our discussion here also shows that x should be xc by default when width is specified in many case.)

• xc is a bit like complecting alignment with position. It's just basically x that's center aligned. With align / baseline as the modifier, I think this better fit people's mental model (or at least mine). I think the separation between x and xc could be quite confusing for high-level reasoning in systems like CompassQL/Draco too.

3. Adding xc/yc means users can choose either x/y or xc/yc. Thus, our internal rules (e.g., for looking up scales and axes) have to check both x/y and xc/yc everywhere and will make the codebase very complicated. (That said, this is a minor point and we can only choose do this for our internal implementation and make xc/yc a macro of x/y with align/baseline.)

That said, adding xc that is separate from x, x2 could be useful for a potential extension for the error bar macro (https://github.com/vega/vega-lite/issues/4422#issuecomment-496313449). However, in such cases, there are 3 distinct things (x_start, x_end, x_center), so we could say that xc only works with error bars and avoid complexity in many other places.

cc: @jheer @domoritz

[kanitw]

We also need to decide whether they should have their own scales or simply use x/y-scales.

All currently examples in Vega simply use width / height with x/y band scales. But we don't need explicit width/height channels in Vega-Lite for that as we automatically produce width/height for x/y band scales.

• x is discrete, width is continuous -- consider a horizontal violin plot, we would need a separate width scale that should be linear.

• x is discrete, width is discrete -- not sure when we should need this? Maybe for mapping an ordinal field to width? If so, also separate scale?

• x is continuous, width is continuous -- consider a horizontal gantt chart, the width of bars should simply use the continuous x-scale. However, using width/height directly with continuous x/y scales that are non-linear or do not include zero wouldn't make sense (as we won't get the right width).

• x is continuous, width is discrete -- not sure when we should need this? Maybe for mapping an ordinal field to width? If so, also separate scale?

Based on this analysis, the case that both x and width are continuous sounds like we should share the x scale but otherwise separate width scales make sense. Should we omit the shared case and always assume separate scale to avoid complexity? (Users can easily use x2 = x+width for the shared scale case anyway.)

In #4703, we also decided that offset channel would always have a separate scale. (shared scale can be x = origin_x + x_offset anyway)

[kanitw]

This is probably more direct way to think about when someone wanna add lollipop tooltip.

cc: @haldenl