Repository navigation
Horizontal legend layouts with long series names become vertical #960
Description
Activity
Looks like this is in fact the intended behavior as per the discussion following #769 (comment) and implemented in #786.
In brief, the current implementation gives one width value for all legend items. That width value is maximum text width of trace
namepresent on the graph as computed here.I understand that the current behavior may not be ideal for all. I wouldn't be opposed to making the trace item layout you're referring to available as a new feature.
Perhaps we should add a boolean attribute
wrappeditemsthat would befalsebe default. When set to turned horizontal legend items would be displayed as you described. This solution isn't perfect, as this newwrappeditemsattribute would only make sense for legends withorientation: 'h'- making the learning curve a little steeper for our users.Alternatively, we should come up with a more granular solution similar to what's proposed in #881 - where we could make the dimension of each legend item configurable.
You could also come up with different semantics at the top level besides 'v' & 'h'. For example:
horizontal
vertical
columnsTo me the current implementation of horizontal is more clearly represented by the word "columns", because of the unintended consequences of spacing being tied to word length. Clear semantics is the most important aspect when creating a package with a less steep learning curve.
So given that this was intentional behavior, we should presumably avoid changing the behavior of
orientation: 'h'if possible to avoid a breaking API change, but I I suppose a different option toorientationcould be added:'hw'or similar for "horizontal wrapped".
I think adding thewrappeditemsattribute is reasonable. It's perhaps not optimal that it's only applicable for legends withorientation: 'h', but there are other cases of this: for instance, the axiscategoryarrayattribute only has an effect ifcategoryorderis set to"array".
If I understand how such a granular solution would work, the idea would be that each series could be set to either participate in the maximum width (the current behavior) or use its own? This would be a superset of thewrappeditemsoption. The attribute could be set to:false(all series use the maximum width: current behavior). Default.true(all series use their own width)- An array of booleans (for each element, if
truethe corresponding series uses its own width, and iffalseuses the maximum width of all series set tofalse)
@mboorstin thanks very much for your input.
I vote personally vote 👎 on adding a
hwvalue to theorientationattribute. Makingorientationtake anything else then v for vertical and h for horizontal would be inconsistent with the other places where we useorientationsuch as in thebartrace type.but there are other cases of this: for instance, the axis categoryarray attribute only has an effect if categoryorder is set to "array".
Good point here. Attributes that only have effect when an other attribute is set to a particular value aren't uncommon in plotly.js. Adding something like
wrappeditemswould definitively be the easiest to get this functionality out. But, I'm thinking maybe we could do better by adding a more general option that could specify other useful legend layouts.@markwatabe made a good point about a possible
'column'attribute or value. The default vertical legend is indeed a column of legend items, but maybe we could have add'block'option or even acolumns: 2attribute-value pair to make the legend span multiple columns. In turned, thewrappeditemsfunctionality could be set by settingcolumns: 4.Yes, I agree on the downvote for adding a
hwvalue to theorientationattribute.
Why wouldcolumns: 4create the wrapping like I suggested here? If anything, it seems like0is the logical value to create a wrapping without columns. Also, I'm not sure how the current horizontal behavior would be expressed with acolumnattribute, because to my understanding it (dynamically) selects the maximum number of columns it can use given the label lengths.it seems like 0 is the logical value to create a wrapping without columns.
Oh right. That's even better than my suggestion. 👍
, I'm not sure how the current horizontal behavior would be expressed with a column attribute,
Good point here. Maybe
columnisn't the right word as a column's dimensions for horizontal legends is computed vary differently than for vertical legend. Maybeblocksis a better term for it.I'm still not sure of what the correct value is for a
blocksattribute to express the current behavior. 0 doesn't make sense because we'll use it for the wrapped behavior, and any number greater than or equal to 1 seems like it should produce exactly that many blocks, but the current behavior can choose the number of blocks it sees fit.
Perhaps we ought to treat this instead as a maximum number of columns, where 0 means "no maximum" (the current behavior), 1 means wrapping into a single column (the behavior we discussed adding in the first place), and greater values will only produce up to that number of columns.Also running into this issue, and willing to create a PR but not sure what ya'll deem the best way to do this.
I'm actually having the same need as #1193 --- if there is only one row in a horizontal legend then using the max width doesn't look too pretty, BUT for me I would want to use the max width if it went to multiple lines.
wonder if this should be a separate option on the legend like "renderInline" (needs a better name) that you could force to be true for all traces. (for the case like @mboorstin's)
but then also change current functionality so that if you can fit all the traces in one row in the legend's area -- and in that case we would also ignore maxwidth. i generally think that's a better outcome for everyone, but I could be thinking about this narrowly with my use cases.
I am also running into a combination of this issue and #771 since every legend item is in its own row, the legend takes up the entire space of the graph.
I got around this by making the legend font size smaller. But I hope that this is a temporary work around.
From @gilles-crealp 's #4394
I do not know if this is the expected behavior but when you set legends horizontally and you group some legends, the grouped legends are displayed vertically.
See traces 0 to 4 in the screen capture.
This issue has been tagged with
NEEDS SPON$ORA community PR for this feature would certainly be welcome, but our experience is deeper features like this are difficult to complete without the Plotly maintainers leading the effort.
Sponsorship range: $5k-$10k
What Sponsorship includes:
- Completion of this feature to the Sponsor's satisfaction, in a manner coherent with the rest of the Plotly.js library and API
- Tests for this feature
- Long-term support (continued support of this feature in the latest version of Plotly.js)
- Documentation at plotly.com/javascript
- Possibility of integrating this feature with Plotly Graphing Libraries (Python, R, F#, Julia, MATLAB, etc)
- Possibility of integrating this feature with Dash
- Feature announcement on community.plotly.com with shout out to Sponsor (or can remain anonymous)
- Gratification of advancing the world's most downloaded, interactive scientific graphing libraries (>50M downloads across supported languages)
Please include the link to this issue when contacting us to discuss.
Reacted by MikkoHaavisto, Angela Devia, Gabriel, Thuong Nguyen and Quentin PinçonThe simplest workaround to avoid this problem is to
slice(0, maxLengthForLegend)the trace's name (maxLengthForLegendbetween 20 and 30 seem to work well and allow the trace name to be recognized).Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson
Repro cases: http://codepen.io/anon/pen/RGozGE
I've encountered an odd behavior on horizontal legends with long series names. If the series names are relatively short, setting
layout.legend.orientationto'h'does indeed produce a reasonably laid out horizontal legend where each line of the legend is filled with as many series as possible (first example in the codepen). If, however, a series has a very long name, each series is placed on its own row in the legend (effectively becoming a vertical legend), even though there's clearly room for series with shorter names to be placed on the same rows (second example in the codepen). I think the more logical behavior should be something like this, where the series are packed into rows as closely as their names allow.I'm happy to make a PR to improve this (it should just involve fiddling with the logic near legend/draw.js:603). Should the current behavior be preserved via a new legend attribute whose default is the current behavior and has an option for the new behavior, or is the current behavior never reasonable and should be replaced?
CC to @markwatabe who originally discussed this issue with me and helped with the proposed solution.