Skip to content
This repository has been archived by the owner on Sep 5, 2024. It is now read-only.

md-button: md-raised's "hover" status should not raise higher ("pressed" should) #1832

Closed
albertboada opened this issue Mar 8, 2015 · 6 comments
Assignees
Milestone

Comments

@albertboada
Copy link

Right now (https://material.angularjs.org/#/demo/material.components.button), raised _md-button_s raise higher when hovered.
However, according to the public Material Design guidelines, raising only happens when you press the button (or when it is focused), not when you hover it:

http://material-design.storage.googleapis.com/publish/v_2/material_ext_publish/0B08MbvYZK1iNelZlNW13UVRzUnc/components-buttons-mainbuttons-buttons-motionraised_large_xhdpi.mp4

Sorry if this has been already informed or already scheduled for development, could not find anything about it.

@albertboada albertboada changed the title [mdButton] md-raised's "hover" status should not raise higher ("pressed" should) md-Button: md-raised's "hover" status should not raise higher ("pressed" should) Mar 8, 2015
@albertboada albertboada changed the title md-Button: md-raised's "hover" status should not raise higher ("pressed" should) md-button: md-raised's "hover" status should not raise higher ("pressed" should) Mar 8, 2015
@marcysutton marcysutton self-assigned this Mar 9, 2015
@marcysutton
Copy link
Contributor

I don't see a hover state at all in that video. I think we should get clarification from the UX team on this one, as I have seen internal design docs that show additional raising on focus to differentiate from hover. cc @ThomasBurleson

@albertboada
Copy link
Author

Exactly, hover state has no special style at all anywhere in the spec. Not sure this is intended, so you better internally confirm this!

@ThomasBurleson ThomasBurleson modified the milestone: 0.9.0 Mar 12, 2015
@marcysutton
Copy link
Contributor

Actually it turns out there is no hover state for buttons per the design spec. Shadow raising should only occur on the focus and press actions, with the latter showing more of a shadow.

@albertboada
Copy link
Author

So the video is trustworthy 100%, right? Because that focused state style would solve all the current confusion if implemented (#556, #142), even if it is always activated (not only through keyboard) (#1594).

In the meantime, being able to distinguish hover from focused status will help a lot, too.

@marcysutton
Copy link
Contributor

That issue again....it's a really tough one to solve unfortunately, as the "fix" is pretty hacky. It's a larger issue in browser focus support, IMO. That PR should make it better, but it's not perfect.

There is work to be done on focus/pressed states, so I'll work that in as part of this issue.

@albertboada
Copy link
Author

Yeah, but I meant... even if #1594 never landed, with these new (and very distinguishable) hover/focused/pressed styles there will be no confusion anymore, so it will not be an issue anymore if the button stays "focused" when pressed :)

marcysutton pushed a commit that referenced this issue Mar 20, 2015
marcysutton pushed a commit that referenced this issue Mar 23, 2015
marcysutton pushed a commit that referenced this issue Mar 27, 2015
@ajoslin ajoslin added the in progress Mainly for in progress PRs, but may be used for issues that require multiple PRs label Mar 27, 2015
marcysutton pushed a commit that referenced this issue Mar 27, 2015
Includes component fixes after global CSS updates

Closes #1607, #1687, #1690, #1832, #1907, #1987, #2009
@ajoslin ajoslin removed the in progress Mainly for in progress PRs, but may be used for issues that require multiple PRs label Mar 28, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants