-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Buttons: CSS Specificity Clean-up #10031
Conversation
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.
Impressive! AMAZING work getting rid of all those !importants. This is much cleaner.
I would love to approve this, but I'd like Riad and @aduth eyes on this because there's a fair bit of history to why we got to where we are today, for example the hover style should not work on an aria-disabled button (like the up mover on the first block), but this seems to work as intended even with this refactor.
But this will be really nice to get in. Thank you!
There's probably even more history than you might expect!
I guess that works because it's an But this is a good point indeed! I'll test again by forcing some |
Related : #9588 (comment) , #9702 In that I don't know that these styles ought to be implemented specific to IconButton vs. Button generally, |
1a6fc65
to
2a4e4db
Compare
Anything we can do to help? Were there specific items we needed to test for visual regressions for? |
From a quick reading, the next step to get this PR merged is in this comment:
If there are no visual regressions to find, it's probably totally okay to move forward even though these changes might theoretically break some thing. As Andrew suggests, the Button and IconButton components are due for a refactor anyway, so let's not let perfect be the enemy of good. |
Sorry for the delay folks! I tried applying My change incorrectly assumed that The solution is simple enough: replace Though, what is the a11y reason behind the possibility of using AFAIK (but I'm not an a11y expert), |
@afercia can you add some color commentary here? I don't know that we use this aspect anywhere but here: See the Up arrow. Because it's the first block in the list, you can't move it upwards. This button is aria-disabled, but not disabled. I can't recall why it's not both, but I seem to recall there was a good reason. |
Yes and no :) That's certainly true when using the Tab key to navigate content. However, screen readers offer the ability to navigate any element in the page using the arrow keys. When doing so, even a That said, I seem the reason why the mover buttons are not really disabled is 6b7b163 See also the comment on the related PR #730 (comment) So it wasn't implemented this way for an a11y requirement. It was done to repair a problem with focus. From an a11y perspective I have no strong objections as long as the button does nothing and is communicated both visually and semantically as "disabled". Note there's also an If you want to try to make it really disabled with a |
Just an additional note:
Ideally, |
@afercia thank you so much for the explanation and the context! I'll replace |
2a4e4db
to
4badd04
Compare
color: $white !important; | ||
background-size: 100px 100% !important; | ||
&.is-busy:disabled, | ||
&.is-busy[aria-disabled="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.
Note: these two are losing the &.is-primary
selector because we are already nested inside &.is-primary {}
(line 63).
re-ran the failing suite here, looks green now |
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 👍 I didn't notice any regression on my testing but it's not easy to check everything.
Awesome job
background: #f7f7f7; | ||
box-shadow: none; | ||
text-shadow: 0 1px 0 #fff; | ||
-webkit-transform: 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.
this is probably useless because we use auto-prefixer
4badd04
to
5afcf51
Compare
Tests are green. Github is stuck somehow :) |
Thanks for reviewing and merging @youknowriad! |
Looks like this change broke the focus style on buttons that are links. Seems only Chrome understands I tend to think the Chrome behavior is wrong, as the Will create an issue. |
Description
Simplify the Button component's CSS to make it easier to integrate it in external projects.
In particular this PR:
!important
.:not(:disabled):not([aria-disabled="true"])
with:enabled
.[disabled]
with:disabled
.How has this been tested?
Tested locally on Chrome 69, Firefox 62, Safari 12, Edge 17, and IE 11.
To test this, please smoke-test the editor to make sure the
Button
behave as expected.Types of changes
Code quality enhancement
Checklist: