Repository navigation
Syntax for highlight-type aesthetic override #528
Description
Activity
Sister issue filed in Hephaestus at posit-dev/hephaestus#31
The ggplot2 equivalent is either the
after_scale()native affordance or gghighlight for a higher level apiHere are some initial thoughts I'm willing to part with.
There is already a precedent for using scales for non-aesthetic/meta-aesthetic things like faceting variables.
So I'd propose we reuse the scale syntax whereFROMis hardcoded to be 3 discrete categories representing the (1) selected bit, (2) a hovered bit and (3) background bits.
So using:SCALE highlight TO [red, null, grey]Will display the selected observations as red, hovered observations will keep their colour while background goes gray.
If we're considering more highlights than just colour, e.g. opacity we can maybe introduce a bit of syntax to allow
SCALE highlight colour TO ...orSCALE highlight opacity TO ...I feel like this belongs in a layer, rather than in a scale TBH. It is fair that different layers react differently to highlighting even though they are scaled by the same scale
Lastly I want to make this super flexible in terms of what gets highlighted and a data selection doesn't really fit into a scale
My off-the-cuff suggestion is something like
DRAW point MARKING opacity => 0.5 WHEN data.species NOT IN 'adelie'I'm not married to
MARKING.HIGHLIGHTINGis both very long and feels wrong because you'd often use this to dim the other data rather than highlight somethingIn the
TABULATEwork there is aHIGHLIGHTclause that does cell-specific markup. It would be good to disambiguate that and interactive highlighting.
I'd be happy with layer level logic, but we should have some syntax around different interactive behaviours such as selecting/hovering etc. Something likeMARKING opacity => 0.5 WHEN data.species NOT IN [selected, hovered]or some other magic keywords that map to interactive behaviour.I don't think we have to think about interactivity directly in this - we just have to make the system flexible enough (I do have thoughts about it though that doesn't completely align with "magical keywords" but also isn't too far away from it)
I do like your point about ensuring parallelism between VISUALISE and TABULATE
I begin to suspect we need a dedicated syntax (sub-clause to DRAW) that encompasses the idea of overwriting the literal value of an aesthetic based on a condition. I think it needs to live separately because it needs to work both for mapped and set values and after scaling has been applied. While it is nice in itself for static plots (i.e. easy lowering of opacity on a group of background observations) I think it will be integral to a future dynamic grammar in order to describe rich hover and select behavior