Skip to content
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

Merged
merged 24 commits into from
Oct 5, 2018
Merged

modeBar styling #3068

merged 24 commits into from
Oct 5, 2018

Conversation

antoinerg
Copy link
Contributor

@antoinerg antoinerg commented Oct 2, 2018

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.

}

icon.appendChild(path);
if(thisIcon.svg) {
icon.innerHTML = thisIcon.svg;
Copy link
Contributor Author

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 :(

Copy link
Contributor

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

// 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.

Copy link
Contributor Author

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 :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in commit e870e34

Copy link
Contributor Author

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 !

@antoinerg
Copy link
Contributor Author

BTW, here's what it looks like with a vertical orientation and black icons:
chrome_2018-10-02_17-02-54

@antoinerg
Copy link
Contributor Author

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.

@alexcjohnson
Copy link
Collaborator

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.

@antoinerg
Copy link
Contributor Author

antoinerg commented Oct 3, 2018

@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.

Horizontal
2018-10-02_23-35-16

Vertical
2018-10-02_23-33-25

@alexcjohnson
Copy link
Collaborator

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.

@etpinard
Copy link
Contributor

etpinard commented Oct 3, 2018

Good call on the / order. I suppose we could flip groups bu

I'd vote for making the snapshot button appear at the bottom of the vertical list and the hover buttons at the top under orientation: 'v'.

@alexcjohnson
Copy link
Collaborator

I'd vote for making the snapshot button appear at the bottom of the vertical list and the hover buttons at the top under orientation: 'v'.

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 modeBarButtons(ToAdd|ToRemove)?) confusing?

@etpinard
Copy link
Contributor

etpinard commented Oct 3, 2018

don't you think this would make adding/removing icons (using modeBarButtons(ToAdd|ToRemove)?) confusing?

I don't think so, if we document it properly. It might a good excuse to ✅ #2703

@antoinerg
Copy link
Contributor Author

Reversing the order of groups looks like this:
2018-10-03_11-36-25

As long as the ➕ is above ➖, I don't have a preference.

@@ -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: {
Copy link
Contributor

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!

Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Contributor Author

@antoinerg antoinerg Oct 3, 2018

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! 😳

Copy link
Contributor

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 */
}

Copy link
Contributor Author

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

@antoinerg
Copy link
Contributor Author

Commit b7c2355 updates the CSS to place tooltips on the left of vertical modebars!

2018-10-04_13-50-44

@etpinard etpinard added this to the v1.42.0 milestone Oct 4, 2018
display: block;
float: none;
margin-left: 0px;
margin-top: 8px;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

peek 2018-10-04 13-41

Looks like the vertical orientation has more top margin than the what the horizontal orientation has to its right.

Is this on purpose? This is just something I noticed, I don't have a strong opinion on what this should look like.

Copy link
Contributor Author

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!

},
'newplotlylogo': {
'name': 'newplotlylogo',
'svg': '<svg xmlns=\'http://www.w3.org/2000/svg\' viewBox=\'0 0 132 132\'><defs><style>&#xD;\n .cls-1 {&#xD;\n fill: #119dff;&#xD;\n }&#xD;\n&#xD;\n .cls-2 {&#xD;\n fill: #25fefd;&#xD;\n }&#xD;\n&#xD;\n .cls-3 {&#xD;\n fill: #fff;&#xD;\n }&#xD;\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>'
Copy link
Contributor

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?

Copy link
Contributor Author

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);
Copy link
Contributor

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:

header.on('mouseover', function() {
header.call(styleOnMouseOver);
});

function styleOnMouseOver(item) {
item.select('rect.' + constants.itemRectClassName)
.call(Color.fill, constants.hoverColor);
}

that way we wouldn't have to hijack the <style> dynamically.

Copy link
Contributor Author

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.

Copy link
Contributor

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);
Copy link
Contributor

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')

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

peek 2018-10-04 13-54

moreover, modebar.color doesn't seem to work on some icons.

Copy link
Contributor Author

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.

Copy link
Contributor

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!

Copy link
Contributor Author

@antoinerg antoinerg Oct 4, 2018

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great tests. Thanks 🎉

@antoinerg
Copy link
Contributor Author

Ok see here's how the default vertical modebars look like with the latest commit ff3f9f6:
chrome_2018-10-05_14-20-15

What do you guys think? Should I choose better defaults?

@alexcjohnson
Copy link
Collaborator

@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 Color.contrast without lightAmount or darkAmount, followed by Color.addOpacity (just using different opacity for active and inactive), to make colors that closely match the existing colors when the background is white.

That strategy won't be able to exactly match our current grays (rgba(0,31,95,0.3) and rgba(0,22,72,0.5)), which are tinted a bit blue, unless perhaps you replace Color.defaultLine when returned by Color.contrast with a different color based off those two...

@antoinerg
Copy link
Contributor Author

antoinerg commented Oct 5, 2018

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:
chrome_2018-10-05_15-05-13

Do you have any other comments/suggestions?

@alexcjohnson
Copy link
Collaborator

Indeed, much improved! I'm a little surprised that the red background counts as dark according to Color.contrast, the inactive buttons are a little hard to see there. But... really, who makes a plot with a bright red background? To my eye all the others look good, so I'd say we're ready to go!
💃

@antoinerg antoinerg merged commit 88d48c5 into master Oct 5, 2018
@antoinerg antoinerg deleted the 3063-modebar-style branch October 5, 2018 20:32
@jackparmer
Copy link
Contributor

🎉 🥇 🔍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature something new
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Modebar aesthetic configurability
4 participants