The intention for unified hoverlabel formatting is that if layout.hoverlabel isn't specified, it will use the settings from layout.legend for e.g. bgcolor and font etc, otherwise it will use the layout.hoverlabel settings.
Right now it seems like neither work to override the hoverlabel formatting in x unified mode
At the moment, it inherits layout.font. I'll implement what you're asking.
@nicolaskruchten @alexcjohnson is it ever possible for layout.hoverlabel to be undefined? Doesn't it always get coerced?
Oh I meant if e.g. layout.hoverlabel.bgcolor isn't specified in the input, we should fall back to layout.legend.bgcolor's coerced value in unified hovermode... makes sense?
so: layout: {} will get us a white hoverlabel, layout: {legend: {bgcolor: 'red}} will get us a red hoverlabel and layout: {legend: {bgcolor: 'red}, hoverlabel: {bgcolor: 'blue'} will get us a blue one. Ditto all the other settings in layout.hoverlabel like font etc that are in common with layout.legend.
Just be careful re: all the template confusion, ideally we can just use the legend settings as the defaults for the hoverlabel settings at the coerce level, rather than interrogating the input layout directly.
Now what do you suppose will happen if you provide:
layout: {
template: { layout: { hoverlabel: { bgcolor: 'blue' } } },
legend: { bgcolor: 'red' }
}
I'm not sure what this should do, but we have similar inheritance scattered all around - and we I do recall we discussed this during the templates push - so it should be handled at the coerce level rather than special logic for this case.
right sorry I meant to post this exact example... the answer is blue ;)
related to https://github.com/plotly/plotly.js/issues/4482 ?
Most helpful comment
Just be careful re: all the
templateconfusion, ideally we can just use thelegendsettings as the defaults for thehoverlabelsettings at the coerce level, rather than interrogating the input layout directly.Now what do you suppose will happen if you provide:
I'm not sure what this should do, but we have similar inheritance scattered all around - and we I do recall we discussed this during the templates push - so it should be handled at the
coercelevel rather than special logic for this case.