Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Buttons: CSS Specificity Clean-up #10031
Simplify the Button component's CSS to make it easier to integrate it in external projects.
In particular this PR:
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
Types of changes
Code quality enhancement
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
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
@afercia thank you so much for the explanation and the context!