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

[Amsterdam] Updating button styles #2874

Merged
merged 28 commits into from
Mar 4, 2020

Conversation

daveyholler
Copy link
Contributor

@daveyholler daveyholler commented Feb 19, 2020

Summary

Updates button styles.

  • Buttons that were hollow in appearance in the default EUI theme are now a subdued version of their parent color.
  • Shadows have been removed
  • Button text is now a heavier 600 weight
  • Border radius (except on small buttons) has been increased to a calculated value of 6px

Screen Shot 2020-02-27 at 13 02 18 PM

Screen Shot 2020-02-27 at 12 55 54 PM

Details

There's some additional files here. Lemme break it down:

  1. mixins/_button.scss: Modifies current theme's mixins/_button.scss file
  2. variables/_buttons.scss: Modifies current theme's variables/_buttons.scss file
  3. overrides/*.scss: Modifies the EuiButton* component stylesheet. This is intended as a temporary stop gap until Amsterdam is the default theme. Certain elements like shadows and borders exist in the component code that are to be removed in Amsterdam.

Consumers

The default un-filled/hollow buttons in EUI's current theme have been replaced by a filled version that use a subdued variant of the button's assigned color. In most use cases there should be no need to update or modify your existing UIs. For additional information on how/when to use certain button styles, please refer to our Button Guidelines

Follow Ups

Button group styles will be updated in a follow up PR to enhance clarity between default and toggled states.


Dev

In order to support theme overrides that require more than just SASS variable changes, and to avoid duplicating lots of code, several additional steps were taken for the button:

  • Broke euiButton() mixin down to smaller mixins for easier reuse of base styles
  • The overrides/ folder sits outside of global_styling/ and is imported after component imports
    • Then you only need to override what is different from the default theme and not the entire markup

Disabled styles

There was a lot of manual configuring to create the disabled styles for the different types of buttons. I ended up creating a new variable (in buttons only) called $euiButtonColorDisabledTextColor that just calculates the contrast to the 2.0 necessary for disabled elements. This is then used in text portions of disabled buttons that don't have a background. I also then use the same calculation for fill buttons to change the text color to achieve a 2.0 contrast which does mean changing the text color from white to a dark gray:

Before

Screen Shot 2020-02-26 at 17 03 09 PM

After

Screen Shot 2020-02-26 at 17 03 26 PM

Dark mode

Screen Shot 2020-02-26 at 18 30 15 PM

But this is a much more sustainable approach when it comes to theming as I was able to remove a lot of overrides for Amsterdam.

Ghost buttons

This PR also has a fix for the current theme's ghost button disabled styles.

Screen Shot 2020-02-26 at 14 04 02 PM


Deprecations #1469

text color EuiButton (and alts)

We should really deprecate the text color for buttons as it looks too similar to disabled buttons. We can keep it for EuiButtonIcon and EuiButtonEmpty, but the basic buttons shouldn't allow it.

disabled color EuiButton (and alts)

It doesn't quite make sense to have a disabled color for buttons. Instead we should rely solely on the :disabled property.


Checklist

  • Check against all themes for compatibility in both light and dark modes
    - [ ] Checked in mobile
  • Checked in IE11 Edge and Firefox
    - [ ] Props have proper autodocs
  • Added documentation examples
    - [ ] Added or updated jest tests
    - [ ] Checked for breaking changes and labeled appropriately
  • Checked for accessibility including keyboard-only and screenreader modes
  • A changelog entry exists and is marked appropriately

@johnbarrierwilson
Copy link
Member

Is that screenshot using the current 16px base font size? Will it shrink a little when we switch to 14px? Just curious. It doesn't look bad right now, but I think that 14px base size will be an improvement.

@myasonik
Copy link
Contributor

Just wanted to check if you ran all these through a contrast check? (We want to hit a 5.4:1 ratio between the text and the backgrounds.)

@snide
Copy link
Contributor

snide commented Feb 19, 2020

@myasonik Think you mean 4.5. We have plenty of tooling around accessibility checks for colors in the docs. You can safely assume @cchaos or I will watch over these PRs as they come in 😄

@daveyholler
Copy link
Contributor Author

@johnbarrierwilson

Is that screenshot using the current 16px base font size? Will it shrink a little when we switch to 14px? Just curious. It doesn't look bad right now, but I think that 14px base size will be an improvement.

This is 16px atm. PR for font size changes will come later.

@cchaos
Copy link
Contributor

cchaos commented Feb 19, 2020

This one is going to be a bit trickier because we would like avoid as much direct copy/pastes and duplicate styles as possible. It just makes maintenance that much harder. I will pull down this branch and see what kind of solutions I can come up with. It'll probably be a mix of making more mixins and/or breaking apart styles based on purpose. So give me a bit to fiddle with this one.

daveyholler and others added 11 commits February 21, 2020 16:15
- Only showing the Amsterdam callout when they’ve switched to the Amsterdam theme
- Added `makeGraphicColor()` SASS color function
- Added defaults to `makeHighContrastColor()` SASS color function
- Broke `euiButton()` mixin down to smaller mixins for easier reuse of base styles
- Moved `overrides/` folder out of `global_styling` and importing __after__ component imports
- Only overriding what __needs__ to/what is __different__
@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_2874/

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_2874/

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_2874/

@snide snide mentioned this pull request Feb 26, 2020
35 tasks
@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_2874/

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_2874/

@cchaos
Copy link
Contributor

cchaos commented Feb 27, 2020

🎉 This one is ready for final review. Please read through the summary first as it should address a few things that might come up.

Copy link
Contributor

@cchaos cchaos left a comment

Choose a reason for hiding this comment

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

I did a final code review, and it all LGTM 👍

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_2874/

Copy link
Contributor

@snide snide left a comment

Choose a reason for hiding this comment

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

Code looks good, buttons look good. Nice work.

I see a break on context menus in the new style where the popover can't calculate a best position. I haven't dug too far into the reason yet, it doesn't look related to this PR. Only happens in the new theme. Does not seem related to this PR because I'm noticing it on the compiled site. Super weird and wondering if it has to do with the dynamic css switch.

Not for this PR, but my guess is we still have some work to do on Focus states for buttons. We do it a little differently (sometimes darken, sometimes lighten, sometimes outline...etc).

The filled, but disabled Ghost buttons seem like they might need a separate check for their text color. Feels like it pops too much for a disabled button.

image

@cchaos
Copy link
Contributor

cchaos commented Feb 28, 2020

I see a break on context menus in the new style where the popover can't calculate a best position. I haven't dug too far into the reason yet, it doesn't look related to this PR. Only happens in the new theme. Does not seem related to this PR because I'm noticing it on the compiled site. Super weird and wondering if it has to do with the dynamic css switch.

OMG, thank you for pointing out that it's only in this theme. I kept seeing this error too, but couldn't find a pattern to it. And every time I checked on published docs it was fine (because I never switched from the default theme).

I'll see if @chandlerprall can take a look outside of this PR


The filled, but disabled Ghost buttons seem like they might need a separate check for their text color. Feels like it pops too much for a disabled button.

I'm now setting the text color to be 2.0 contrast from background color of filled ghost buttons

Screen Shot 2020-02-28 at 10 08 52 AM

@cchaos cchaos requested a review from snide February 28, 2020 15:11
@cchaos
Copy link
Contributor

cchaos commented Feb 28, 2020

@chandlerprall Scratch that request, I've found the root of the problem stemming from an early change the the EuiPanel mixin. I'll be able to push the fix up to this PR.

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_2874/

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_2874/

Copy link
Contributor

@snide snide left a comment

Choose a reason for hiding this comment

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

Awesome. Thanks for the quick fixes. That disabled ghost button looks much better now.

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_2874/

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_2874/

Copy link
Contributor

@chandlerprall chandlerprall left a comment

Choose a reason for hiding this comment

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

Changes LGTM; looked to see if TypeScript could be helpful around that deprecation but didn't find anything

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_2874/

@daveyholler daveyholler merged commit 8c3ca5f into elastic:master Mar 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deprecations Contains deprecations. Add them to the deprecations meta ticket after merge.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants