882 - Chart Title Alignment #3276
Conversation
- Not cleaned up. - Padding attributes missing. - `auto` values missing.
- Current position means the title's baseline sits in the middle of the to margin.
- For initial render and update through relayout/update.
- colorbar is using the titles component to draw its title and therefore needed to adapt to the attribute structure assumed by the titles component.
- Adapt layout attributes. - Extend compatibility code in `cleanLayout`. - Adapt polar drawing code. - Adapt tests being based on old title attr structure.
- Adapt layout attributes. - Extend compatibility code in `cleanLayout`. - Adapt ternary drawing code. - Adapt tests being based on old title attr structure. - Test relayouting title attributes.
- Adapt layout attributes. - Extend compatibility code in `cleanLayout`.
- Further being splom, validate and template tests.
- Special coerce logic for y because it can be 'auto' also.
- Eliminate an unnecessary else block.
- Bug: Using an attribute string representing the deprecated title structure to unset a value wasn't supported.
- Bug: if only a `titlefont` but no `title` was set, `cleanTitle` would not create the new title structure.
src/plots/plots.js
Outdated
| function coerceTitleY() { | ||
| if(layoutIn.title && isNumeric(layoutIn.title.y)) { | ||
| var propOut = Lib.nestedProperty(layoutOut, 'title.y'); | ||
| var opts = Lib.nestedProperty(plots.layoutAttributes, 'title.y').get(); |
There was a problem hiding this comment.
If we keep this, it doesn't need to be nestedProperty - plots.layoutAttributes.title.y would work, right?
There was a problem hiding this comment.
You're right. Lib.valObjectMeta.number.coerceFunction used to check the defined min/max bounds but the removal of min/max in the attribute definition rendered that obsolete (see above) 🤦♂️
There was a problem hiding this comment.
See commit 5fb7b8f
|
- Swichting the valType to 'number' spares the custom coerce function. - In addition fixes the missing min and max bounds for y.
- This transitions all traces depending on `colorbar` as well.
- Also remove unnecessary code in carpet implementation.
Converted |
- Reason: having no default at all for `title.text` would lead to a non-existing `title` container (through a call to `relinkPrivateKeys` deep down the stack) eventually and as consequence would require to safeguard access to `[ab]axis.title.text` by checking `[abaxis.title]` is defined before.
src/traces/carpet/axis_defaults.js
Outdated
| if(!containerOut.title.text) { | ||
| delete containerOut.title.font; | ||
| delete containerOut.title.offset; | ||
| } |
There was a problem hiding this comment.
Is there some reason it doesn't work to invert this pattern? ie only coerce these attributes if we have a title, rather than always coercing them then deleting if there's no title?
There is a lot of this pattern above - coerce everything and then delete - and it's needed when a value provided to one of these other attributes affects the default of the controlling attribute - like if there's an explicit start line color or width we default to show the start line, so we need to coerce startlinecolor and startlinewidth before we can correctly coerce startline but then if start line was explicitly hidden we need to delete color and width. But I don't think that applies here.
There was a problem hiding this comment.
Is there some reason it doesn't work to invert this pattern?
I don't think so, but I can't say for sure TBH. What could be a reason for checking for an empty title and deleting title attributes at the end? In theory, every call to coerce could clear containerOut.title. But since there's no comment on the "why", let's reverse the logic as you suggested and keep 🤞 we haven't broke anything. Does that sound like a plan?
| coerce('titleside'); | ||
| coerce('title.text', layout._dfltTitle.colorbar); | ||
| Lib.coerceFont(coerce, 'title.font', layout.font); | ||
| coerce('title.side'); |
There was a problem hiding this comment.
Oh hmm, I was going to say we should not coerce title.font and title.side here but because of _dfltTitle you'd have to explicitly set title.text = '' to make these irrelevant, and even then in principle in editable: true mode we would need these attributes. So I guess here - and everywhere else the titles are editable within the plot - it's correct as is. And the only places that doesn't apply are carpet (discussed elsewhere) and pie (already handled correctly) 🎉
There was a problem hiding this comment.
I agree. That was my concern as well (plus my guess that we might need font to calculate things like automargin even if we don't have a title set). But I resisted to raise that because I haven't done the research in the code to underpin my claim.
|
Beautiful. As I was giving the code a final look I saw a few extra "oh wait, what about..." only to find you'd already addressed and thoroughly tested them all. Love it. 💃 |
|
I'm going to add a second 💃 here. Amazing work @rmoestl ! |
|
🎉 |
This PR adds the capability to align the main plot title as requested in issue #882.
New title attributes structure
Besides the introduction of the discussed alignment options, this PR also transitions to a new
titleattribute structure.layout.titlehas becomelayout.title.textandlayout.titlefonthas becomelayout.title.font. The same goes for any other title definitions withinlayout, e.g.xaxis,yaxis,polar.radialaxisand so on.The structure of title attributes within
dataremains unchanged as it won't have added any significant value to users compared to the additional effort this would have taken (e.g. transitioningpie).To be discussed
TODOs were added that probably need a closer look by a core maintainer.plotly_relayoutwhich especially showed in two broken and thus updated tests inlegend_test.js. Users are still able to use the old attributes structure as an input toPlotly.relayoutandPlotly.update. But any handlers listening onplotly_relayoutevents, that assume the old title structure, need to be updated.Lib.warncalls incleanLayouthave not been added so far since the original issue is about two years old as of writing and every other clean-up code incleanLayoutdoes not yet emit warnings.