-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
feat(snackbar): Update styles to match guidelines #4070
Conversation
Codecov Report
@@ Coverage Diff @@
## feat/snackbar #4070 +/- ##
=================================================
+ Coverage 98.67% 98.74% +0.06%
=================================================
Files 126 123 -3
Lines 5596 5406 -190
Branches 746 724 -22
=================================================
- Hits 5522 5338 -184
+ Misses 74 68 -6 Continue to review full report at Codecov.
|
🤖 Beep boop! Screenshot test report 🚦52 screenshots changed from Details52 Added: |
} | ||
|
||
@mixin mdc-snackbar-min-width($min-width) { | ||
.mdc-snackbar__surface { |
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 is regarding additional wrapper .mdc-snackbar__surface
used to achieve opaque background.
Did you run into any issues using mix()
sass function?
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 question!
Two One issues:
mix()
prevents clients from using CSS variablesIf theoverlay
color has an alpha channel,mix()
will return anrgba()
value.
This will make the snackbar's background appear semi-transparent instead of opaque, which violates the spec.
Ok, this was a stupid argument. It probably doesn't make sense for theoverlay
color to have an alpha channel.
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 need CSS variable support for users using sass mixins?
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.
If possible, yes, but if we have to choose between supporting CSS variables and having a simple Sass API, we normally go with a simple Sass API.
I'll remove the __overlay
element and simplify the fill-color
mixin so that it only takes 1 color parameter. The mix()
function will be called in _variables.scss
, similar to what mdc-chips does.
packages/mdc-snackbar/_mixins.scss
Outdated
} | ||
} | ||
|
||
@mixin mdc-snackbar-surface-fill-color($color) { |
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.
mdc-snackbar-fill-color
?
Should we expose two separate mixins? Seems like these mixins are helping customize low-level elements of this component.
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 definitely see your point. Having two separate mixins is not very intuitive for clients who just want to set the background-color
to a specific hex value.
However, the internal guidelines say that the rendered background-color
of a snackbar should be a combination of two theme colors: surface and overlay. It may be low-level, but it's how the theming system works. I'm not sure what the alternative is.
Would it be better to have a single mixin that accepts two color params? E.g.:
@mixin mdc-snackbar-fill-color(
$surface-color: surface,
$overlay-color: on-surface,
$overlay-opacity: high
) {
.mdc-snackbar__surface {
@include mdc-theme-prop(background-color, $surface-color);
}
.mdc-snackbar__overlay {
$overlay-opacity-value: if(
type-of($overlay-opacity) == number,
$overlay-opacity,
mdc-theme-text-emphasis($overlay-opacity)
);
$overlay-color-value: rgba(
mdc-theme-prop-value($overlay-color),
$overlay-opacity-value
);
@include mdc-theme-prop(background-color, $overlay-color-value);
}
}
If we decide to stick with two separate mixins, I probably wouldn't want to rename them, because IMO it would be confusing to have:
mdc-snackbar-fill-color
(targets__surface
)mdc-snackbar-overlay-color
(targets__overlay
)
The name mdc-snackbar-fill-color
would be misleading, because it doesn't actually set the rendered fill color of the component—just the background behind the overlay.
WDYT? Is there an alternative I'm not seeing here?
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 be agreeable to one mixin w/ arguments for both colors. Separate mixins seems prone to people accidentally overlooking one or the other and not realizing they influence each other.
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.
Done!
@@ -1077,6 +1077,123 @@ | |||
"desktop_windows_ie@11": "https://storage.googleapis.com/mdc-web-screenshot-tests/travis/2018/10/23/19_08_56_617/spec/mdc-select/mixins/shape-radius.html.windows_ie_11.png" | |||
} | |||
}, | |||
"spec/mdc-snackbar/classes/baseline-with-action.html": { |
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.
Snackbar is being clipped in iPhone 5 viewport.
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.
Wow, good catch! 👍
That's due to the default min-width
value of 344px
from the spec:
https://material.io/design/components/snackbars.html#spec
I'll follow up with Design on this.
(OOC, why did you think to test it on an iPhone 5? Never would have occurred to me 😝)
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 was testing if snackbar snaps to screen edges for smaller browsers 🙂
|
||
.mdc-snackbar--stacked & { | ||
flex-direction: column; | ||
align-items: flex-start; |
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.
Should this flip for RTL?
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.
Nope! That's the beauty of flexbox and flex-start
: It's already RTL-aware! 🎉
BTW, you can add ?dir=rtl
to any screenshot test page URL to see what it looks like in RTL:
LTR:
RTL:
packages/mdc-snackbar/_mixins.scss
Outdated
} | ||
|
||
@mixin mdc-snackbar-shape-radius($radius) { | ||
// The mdc-snackbar__overlay selector is needed to prevent the overlay's |
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.
You say the snackbar__overlay
selector is needed... but it's not there?
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.
Good catch, removed
packages/mdc-snackbar/_mixins.scss
Outdated
} | ||
} | ||
|
||
@mixin mdc-snackbar-surface-fill-color($color) { |
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 be agreeable to one mixin w/ arguments for both colors. Separate mixins seems prone to people accidentally overlooking one or the other and not realizing they influence each other.
// Private | ||
// | ||
|
||
$mdc-snackbar-enter-delay_: 0ms; |
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.
Is there a reason these are distinguished as private, given the request we've gotten to expose everything as overrideable?
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.
Good call—made them "public"
@@ -1,5 +1,5 @@ | |||
// | |||
// Copyright 2017 Google Inc. | |||
// Copyright 2018 Google Inc. |
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 typically don't change the copyright year in pre-existing files. I can buy the argument in other cases that the files are effectively being replaced, but this one especially seems somewhat intact.
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 actually rewrote this file from scratch, so I figured that needed a year bump
packages/mdc-snackbar/package.json
Outdated
@@ -16,7 +16,12 @@ | |||
"dependencies": { | |||
"@material/animation": "^0.41.0", | |||
"@material/base": "^0.41.0", | |||
"@material/button": "^0.41.0", | |||
"@material/icon-button": "^0.41.0", | |||
"@material/dom": "^0.41.0", |
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 take it you're expecting to use this in the JS portion?
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.
Yep, I just forgot to remove it from this PR. Fixed!
🤖 Beep boop! Screenshot test report 🚦48 screenshots changed from Details48 Added: |
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.
Looks good overall! Added few comments mostly nit.
Are you planning to update README file in your next PR?
} | ||
|
||
@mixin mdc-snackbar-min-width($min-width) { | ||
.mdc-snackbar__surface { |
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 need CSS variable support for users using sass mixins?
packages/mdc-snackbar/_mixins.scss
Outdated
} | ||
|
||
@mixin mdc-snackbar-fill-color($overlay-color, $overlay-opacity, $surface-color: surface) { | ||
.mdc-snackbar__surface { |
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.
surface
is a global override and can be customized using sass variable - $mdc-theme-surface
. User may not need to send surface color here again?
I'm assuming the overlay color should blend with the global surface color which might be rendered behind snackbar from other components.
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.
Individual components can technically have their own independent "surface" color, which may or may not be the same as the global surface color.
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 checked with designer today, Snackbar doesn't seem to allow customization for snackbar container (surface).
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.
Internal customers need a different background color, so we still need to at least provide a mixin to change it. But I'll remove the __overlay
element and simplify the fill-color
mixin so that it only takes 1 parameter.
@@ -1077,6 +1077,123 @@ | |||
"desktop_windows_ie@11": "https://storage.googleapis.com/mdc-web-screenshot-tests/travis/2018/10/23/19_08_56_617/spec/mdc-select/mixins/shape-radius.html.windows_ie_11.png" | |||
} | |||
}, | |||
"spec/mdc-snackbar/classes/baseline-with-action.html": { |
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 was testing if snackbar snaps to screen edges for smaller browsers 🙂
justify-content: flex-start; | ||
margin-top: -12px; | ||
margin-bottom: 8px; | ||
display: none; |
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 still need to set this to display: none
when the root has aria-hidden="true"
?
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.
Yes, display: none
is necessary to prevent the elements from being focusable when the user presses the Tab key.
<html lang="en"> | ||
<head> | ||
<meta charset="utf-8"> | ||
<title>Baseline Snackbar with Action - MDC Web Screenshot Test</title> |
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.
Update title?
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.
Done
@import "../packages/mdc-textfield/mdc-text-field"; | ||
@import "../../../../packages/mdc-snackbar/mixins"; | ||
@import "../../../../packages/mdc-theme/color-palette"; | ||
@import "../mixins"; |
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 don't seem to be using this here. Should we remove it?
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.
Removed
@import "@material/rtl/mixins"; | ||
@import "@material/theme/functions"; |
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.
Are all of these theme imports used? I don't see mdc-theme anywhere in this file. I think they're used in _mixins
instead.
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.
Removed
// > To disable tap highlighting, set the alpha value to 0 (invisible). | ||
// > If you set the alpha value to 1.0 (opaque), the element is not visible when tapped. | ||
// See https://github.com/ben-eb/postcss-colormin/issues/1 | ||
-webkit-tap-highlight-color: rgba(0, 0, 0, 0); |
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.
Why is this needed on the entire snackbar element?
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.
For some reason, iOS Safari displays a tap highlight on the entire snackbar element 🤷♀️
display: flex; | ||
|
||
// Non-static positioning is required to make `overflow: hidden` work in Safari. |
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.
Are we really running into this bug? Wouldn't we want relative positioning anyway because the overlay element is absolutely-positioned inside the surface element?
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.
Now that I've removed the __overlay
element and simplified the fill-color
mixin to only take 1 parameter, we don't need this anymore. Removed!
pointer-events: auto; // Allow mouse events on surface element while snackbar is open | ||
} | ||
|
||
.mdc-snackbar--closing & { |
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.
Can you explain why there's a --closing but no --opening? It's probably hard to surmise without having the JS APIs to actually cause animation.
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.
Opening and closing use different animations, so I need a separate class for --closing
.
The opening animation is defined in --open
.
margin: 0; | ||
// Two selectors are needed to increase specificity above `.material-icons`. | ||
// stylelint-disable-next-line selector-class-pattern | ||
.mdc-snackbar__action-icon.material-icons { |
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.
Should this really be using material-icons in the selector? What would happen if someone used an image or svg? Should we do the same-class-twice trick instead?
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.
Same-class-twice trick it is!
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.
LGTM. Please address Ken's comments.
🤖 Beep boop! Screenshot test report 🚦48 screenshots changed from Details48 Added: |
Fixes #4061
This PR also deletes snackbar's JS files and unit tests to avoid spurious test failures.
They will be added back in the next PR (for issue #4062).