-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
modeBar styling #3068
modeBar styling #3068
Conversation
src/components/modebar/modebar.js
Outdated
} | ||
|
||
icon.appendChild(path); | ||
if(thisIcon.svg) { | ||
icon.innerHTML = thisIcon.svg; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
test-syntax
fails because or innerHTML
:(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be fine. innerHTML
only causes problems on SVG nodes.
Looks like the concerns written down in
plotly.js/tasks/test_syntax.js
Lines 106 to 109 in 9772ef6
// These are forbidden in IE *only in SVG* but since | |
// that's 99% of what we do here, we'll forbid them entirely | |
// until there's some HTML use case where we need them. | |
// (not sure what we'd do then, but we'd think of something!) |
have become reality.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thisIcon.svg
isn't a SVG document but rather its content. icon
is the SVG document so IE doesn't like this. Let me fix this :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in commit e870e34
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I got rid of innerHTML
altogether and now use DOMParser
in commit 61d1c7b !
He made "negatives" which are monochrome like the sign outside the Montréal office. . I also don't have a strong opinion so let's wait and find out what @alexcjohnson thinks. Just a reminder, this PR currently has a major regression: there's no hover and active styles for the buttons. There are different ways to achieve this. |
If we think people will really change the logo color, then it would be worth using the monochrome version. But I suspect anyone who cares that much what the modebar looks like is going to drop the plotly logo entirely, so we should optimize the look of the existing logo, which is the current multicolor version - so I'd vote to keep the color. Do we want to reverse the order of the vertical modebar? We should at least move the logo to the top corner, but I think it might work better - at least for people already used to the horizontal one - to have the whole thing flipped as if we had just rotated the existing modebar around the logo. |
@alexcjohnson I agree we should move the logo to the top. As for the icons, I'd rather have the + icon be to the left or above the - icon. Which is why I prefer the current order of icons. But this is a matter of preference. BTW, it's quite easy to change the order in the code so we can settle this later once we made up our mind :) Note that I made the icons be squares in order for them to tightly fit into a rectangle both horizontally and vertically. Prior to that change, when vertical, some icons were wider and it wouldn't be aesthetically pleasing. As a result some icons are now smaller than they used to (in particular the icons related to hover). I hope this is fine. |
Good call on the ➕ / ➖ order. I suppose we could flip groups but... then it gets confusing if people want to set their own icons. OK, lets leave it as you have it now. Agreed on making them all square in vertical mode. In horizontal mode I do think it looks a bit better with the original sizes, if it's not too difficult to maintain both behaviors. |
I'd vote for making the snapshot button appear at the bottom of the vertical list and the hover buttons at the top under |
Right, that's what I meant by flipping groups - ie the order of groups gets reversed, but within each group the order is maintained. But @etpinard don't you think this would make adding/removing icons (using |
I don't think so, if we document it properly. It might a good excuse to ✅ #2703 |
src/plots/layout_attributes.js
Outdated
@@ -224,5 +224,30 @@ module.exports = { | |||
'or a logo image, for example. To omit one of these items on the plot,', | |||
'make an item with matching `templateitemname` and `visible: false`.' | |||
].join(' ') | |||
}, | |||
modeBarStyle: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no 🐫 in data/layout attributes!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... but wait do we really want to make these layout attributes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ha I see, @alexcjohnson , @nicolaskruchten and @jackparmer have agreed on making these layout attributes in #3063. Not much I can say I guess.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe you could chime in on how we should name those attributes. I didn't realize there was no 🐫 in data/layout attributes! 😳
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd vote for:
modebar: {
orientation: 'h' | 'v',
bgcolor: '',
color: /* implied icon color */,
activecolor: /* just like we currently use for rangeselector */
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I vote for @etpinard's suggestion. What do you guys think? @alexcjohnson @nicolaskruchten @jackparmer
Commit b7c2355 updates the CSS to place tooltips on the left of vertical modebars! |
src/css/_modebar.scss
Outdated
display: block; | ||
float: none; | ||
margin-left: 0px; | ||
margin-top: 8px; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch 👀 ! No, it's not on purpose. I'd rather have the logo at the top. Fixing this right now!
build/ploticon.js
Outdated
}, | ||
'newplotlylogo': { | ||
'name': 'newplotlylogo', | ||
'svg': '<svg xmlns=\'http://www.w3.org/2000/svg\' viewBox=\'0 0 132 132\'><defs><style>
\n .cls-1 {
\n fill: #119dff;
\n }
\n
\n .cls-2 {
\n fill: #25fefd;
\n }
\n
\n .cls-3 {
\n fill: #fff;
\n }
\n </style></defs><title>plotly-logomark</title><g id=\'symbol\'><rect class=\'cls-1\' width=\'132\' height=\'132\' rx=\'6\' ry=\'6\'/><circle class=\'cls-2\' cx=\'78\' cy=\'54\' r=\'6\'/><circle class=\'cls-2\' cx=\'102\' cy=\'30\' r=\'6\'/><circle class=\'cls-2\' cx=\'78\' cy=\'30\' r=\'6\'/><circle class=\'cls-2\' cx=\'54\' cy=\'30\' r=\'6\'/><circle class=\'cls-2\' cx=\'30\' cy=\'30\' r=\'6\'/><circle class=\'cls-2\' cx=\'30\' cy=\'54\' r=\'6\'/><path class=\'cls-3\' d=\'M30,72a6,6,0,0,0-6,6v24a6,6,0,0,0,12,0V78A6,6,0,0,0,30,72Z\'/><path class=\'cls-3\' d=\'M78,72a6,6,0,0,0-6,6v24a6,6,0,0,0,12,0V78A6,6,0,0,0,78,72Z\'/><path class=\'cls-3\' d=\'M54,48a6,6,0,0,0-6,6v48a6,6,0,0,0,12,0V54A6,6,0,0,0,54,48Z\'/><path class=\'cls-3\' d=\'M102,48a6,6,0,0,0-6,6v48a6,6,0,0,0,12,0V54A6,6,0,0,0,102,48Z\'/></g></svg>' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we trim those \n
and spaces?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed by commit dc7877b
buttons = buttons.reverse(); | ||
} | ||
|
||
Lib.addRelatedStyleRule(modeBarId, '#' + modeBarId, 'background-color: ' + fullLayout.modebar.bgcolor); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have to use CSS here? Could we instead add mouseover
/ mouseout
handlers to the modebar buttons, similar to how we handle updatemenu buttons:
plotly.js/src/components/updatemenus/draw.js
Lines 219 to 221 in 30ed4a4
header.on('mouseover', function() { | |
header.call(styleOnMouseOver); | |
}); |
plotly.js/src/components/updatemenus/draw.js
Lines 464 to 467 in 30ed4a4
function styleOnMouseOver(item) { | |
item.select('rect.' + constants.itemRectClassName) | |
.call(Color.fill, constants.hoverColor); | |
} |
that way we wouldn't have to hijack the <style>
dynamically.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could use mouseover
/ mouseout
for hover but I wasn't sure how to handle the active state. Since we already add/remove class name active
to the icons, I thought it made sense to just style those in CSS. @alexcjohnson wasn't against the idea but we can consider another strategy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we already add/remove class name
active
to the icons
Right, getting "active" to work would require some work. The modebar button click handlers would need to update their style attribute instead of appending/removing the "active"
class name.
Consider my comment non-blocking.
Lib.addRelatedStyleRule(modeBarId, '#' + modeBarId, 'background-color: ' + fullLayout.modebar.bgcolor); | ||
Lib.addRelatedStyleRule(modeBarId, '#' + modeBarId + ' .modebar-btn .icon path', 'fill: ' + fullLayout.modebar.color); | ||
Lib.addRelatedStyleRule(modeBarId, '#' + modeBarId + ' .modebar-btn:hover .icon path', 'fill: ' + fullLayout.modebar.activecolor); | ||
Lib.addRelatedStyleRule(modeBarId, '#' + modeBarId + ' .modebar-btn.active .icon path', 'fill: ' + fullLayout.modebar.activecolor); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These don't appear to update properly on relayout
e.g. Plotly.relayout(gd, 'modebar.bgcolor', 'blue')
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me investigate relayout
!
As for the screen capture: the gray icons are the ones that are currently active (gray being the default activecolor
). It does look like a bug the first time you try it but it's not. Maybe I should implement what @nicolaskruchten suggested over here: #3063 (comment). This shouldn't be a problem in Dash however since they usually explicitly style everything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the gray icons are the ones that are currently active (gray being the default
activecolor
).
Ha I see. My mistake!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Commit 97f25e2 fixes the issue with relayout
.
The new style rules were just appended to the same style
element and would have less priority than previous rules. This is fixed by starting with a fresh style
element each time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool. Let's 🔒 this down in a jasmine test though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In commit f5cc0e9, we test each new layout attributes and make sure they behave properly when using relayout
!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great tests. Thanks 🎉
Ok see here's how the default vertical modebars look like with the latest commit ff3f9f6: What do you guys think? Should I choose better defaults? |
@antoinerg it's looking very close! I think the default color logic needs a bit of tweaking though - the inactive color is often too saturated and sometimes too close to the active color, and they're often too prominent in general. See if you can use That strategy won't be able to exactly match our current grays ( |
I followed your suggestion @alexcjohnson in commit db9edd1: coerce('modebar.bgcolor', Color.addOpacity(layoutOut.paper_bgcolor, 0.5));
var modebarDefaultColor = Color.contrast(Color.rgb(layoutOut.modebar.bgcolor));
coerce('modebar.color', Color.addOpacity(modebarDefaultColor, 0.3));
coerce('modebar.activecolor', Color.addOpacity(modebarDefaultColor, 0.7)); which gives the much improved result seen below: Do you have any other comments/suggestions? |
Indeed, much improved! I'm a little surprised that the red background counts as dark according to |
🎉 🥇 🔍 |
Initial attempt at closing #3063
There are several little changes in different places and some may not be satisfactory. This initial implementation will be a good starting point to further discuss how to resolve #3063.
Note that currently, this PR doesn't have the hover effect on buttons. To do this in CSS, we would need to inject a new
<style>
element onto the page to style the pseudo-class:hover
. Alternatively, we could change the fill color in javascript onmouseover. Let me know what you would prefer.