Support coloring certain fields

[kanitw]

This is especially useful for multi-series line chart (e.g., in
vega/vega-lite#4293).

Here readers can benefit if the temp_max and temp_min have some colors.

For example, something like:

(The circles are manually drawn for demonstration)

[domoritz]

Yeah, that would be nice. Vega-Lite could just generate tooltips with HTML and the tooltip library could render them. A better solution would be to pass a color separately somehow. I don't have a good idea yet, though.

[kanitw]

From chatting with my colleagues at Apple and @kristw, multi-series line is actually quite common and there is a need for a good tooltip for it.

To follow up, there should be a way to pass some metadata for each mark group to the tooltipHandler. Then vega-tooltip can then define its own metadata format.

A few options for how to pass this to the plugin:

1. One possible way is to use arbitrary channel name in Vega (e.g., tooltipParams). In Vega-Lite, each TooltipFieldDef can then have a special param property.

For example, if the tooltip is {time: 'June', a: 1, b: 2}, we could have a tooltipParams output {a: {mark: 'circle', fill: 'red'}, b: {mark: 'circle', fill: 'orange'}}.

The tooltip can then read item.tooltipParam and apply the parameter accordingly.

2. Alternatively, is to agree on the a nested object format for tooltip.
   For example, we could agree that we can wrap tooltip with {value: ..., params: ...}
   So {time: 'June', a: 1, b: 2} could become

{
  time: June,
  a: {text: 1, params: {mark: 'circle', fill: 'red'}},
  b: {text: 2, params: {mark: 'circle', fill: 'orange'}}
}

I think 1) is cleaner as we don't have to modify Vega tooltip handling / default handler. Perhaps the only thing is to make tooltipParams an official channel, so Vega-Lite output can pass Vega validation.

Any thoughts? cc: @jheer @domoritz

Note that I'm not fixated on how the parameter object (e.g., {mark: 'circle', fill: 'red'}) should look like, nor how the channel for 1) should be named (tooltipParams) -- so I'm open to hear suggestions tool.

[domoritz]

I'm okay with either of those two options. Wouldn't it be easier and more flexible, though, if you could pass some html string to label keys instead? I'm worried that we would gradually add more and more things to the params.

[kanitw]

Sounds good, i was thinking about html/svg string when i walked to dinner too.

There are some benefits for having some language consistency but it seems hard to define the scope so it’s probably better to just leverage HTML string.

[kanitw]

@domoritz

If we want to support HTML / SVG string by default though, then we should modify how we sanitize the tooltip key. (Right now HTML isn't allowed at all. Perhaps, we can allow a subset of it, but ban JS instead for security?)

[domoritz]

Yeah, we would need to make some changes. I think it would be nice to support an object to map keys to labels. It's a bit add to have to put large strings into keys.

[kanitw]

Actually, thinking about generality of our language, it might be better to define a syntax here.

[domoritz]

I agree as long as we scoped the extension.

[kanitw]

I think we can structure this parameter object like other guides:

Suppose we use the method 1. above (titleParams channel), I can see the titleParams be:

{
  a: {symbolType: 'circle', symbolColor: 'red', titleColor: 'red'}, 
  b: {symbolType: 'circle', symbolColor: 'orange', titleColor: 'orange'}
}

This would be quite natural in Vega-Lite:

• We can add tooltip property to FieldDef like the following:

encoding: {
  x: {field: 'a', type: ..., tooltip: {symbolType: 'circle', symbolColor: 'red', titleColor: 'red'},
  ...
}

or for manually specified tooltip channel:

encoding: {
  ...
  tooltip: [
    {field: 'a', type: ..., tooltip: {symbolType: 'circle', symbolColor: 'red', titleColor: 'red'}
    ...
  ]
}

[domoritz]

These tooltips in https://observablehq.com/@benoldenburg/mta-daily-ridership-recovery by @benoldenburg are beautiful. I think it would be awesome if we could try to enable tooltips like that in Vega.

[ifokeev]

need this feature a lot

[MathisFederico]

Yup this would be very nice ! Any idea of the progression of it so far ?

[domoritz]

Not from my side. I'm looking for someone who would be willing to take on this issue.

I think it shouldn't be too difficult. We need to add a field to the object that Vega-Lite generates and then we need to read it out when we generate the tooltip HTML.

[MathisFederico]

Not from my side. I'm looking for someone who would be willing to take on this issue.
I think it shouldn't be too difficult. We need to add a field to the object that Vega-Lite generates and then we need to read it out when we generate the tooltip HTML.

Well sadly I don't have the skills for it ... maybe @kanitw who first had the idea ?

[jwadelauer]

Glad to have found this is being discussed.

I think it makes a lot of sense to handle tooltips the same way a symbol legend is handled so that it can accept the same channels: color, opacity, size, and shape. Example below showing the symbols on the left side of the tooltip labels where applicable.

I can't share this specific example but here is one I have been mirroring the majority of the spec with using a public dataset:
https://vega.github.io/editor/#/gist/6998093fdc66bffa0521465af7d0dd41/spec.json

[bluesmoon]

FWIW, I was able to do part of this with pure CSS by targeting the tr:nth-child() td selector of the tooltip table. You can add a ::before pseudo element with the following css:

#vg-tooltip-element tr:nth-child(i) td.key::before { 
            content: "";
            display: inline-block;
            float: left;
            margin-right: 0.5em; 
            width: 0.8em;
            height: 0.8em;
            border-radius: 0.4em;
            background-color: <color for the ith series>
}

Where i starts from 1.

It looks like this:

What I would really like is just the option of adding a data-content attribute to the td.value element so that I can target CSS to cells with specific values in them.