Handling display in Links and Buttons
See original GitHub issueHi @shawnbot and @emplums, re our discussion in slack on display and links and buttons, I thought I’d put it in an issue…
Use cases we need to account for:
- making a button, or a button that looks like a link, fill the full width of a container
- switching the width of a button/link from mobile to desktop
Proposed api changes:
- give button
width
system props - make sure
<Button is="a" />
works properly - make sure
<Button>
hasdisplay: inline-block;
by default so that the width props work (it does in primer css)
This would mean we can do something like:
<Button width={[1, 1, 1/2, 'auto']} />
Let me know what you think and whether I missed any scenarios we need to account for!
Issue Analytics
- State:
- Created 5 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
A Complete Guide to Links and Buttons - CSS-Tricks
Our complete guide to links, buttons, and button-like inputs in HTML, CSS, and JavaScript.
Read more >Links and buttons on websites – Accessible Technology
Links and buttons serve different functions on websites and should be used appropriately. ... The following element is handled as a link by...
Read more >Buttons & Links | Accessibility Guidelines
Screen readers handle links slightly differently than they do buttons. All links and buttons are tab-able, but pressing the Space key or Enter...
Read more >When to Use Buttons and Links | Wireframing Academy
First, you want to think of the primary task you want the user to accomplish on each screen. That should be a button....
Read more >Buttons & Links: The Basics - UX Office - Indiana University
These are buttons that encourage an action from the user. They typically have a solid fill and have the highest emphasis on the...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
True, I believe the rule of thumb for clickable elements in forms is
<buttons>
though, so it’s fine if it navigates to a new pageSort of a separate discussion but I am a bit concerned about a11y + the flexibility of our
Button
andLink
components. I’d love to see our React component library nudge users towards using accessible markup & using Buttons / Links in the correct context. From an accessibility standpoint,<button>
should be used to interact with content on a page, and<a>
should be used to navigate to a new page or new website. To take it a step further,<button>
s should be styled like buttons and<a>
should be styled like links.Encouraging users to use
<Button is='a'>
to get style benefits feels like we’d be steering people in the wrong direction a11y-wise. I’m also wary of even allowingButton
’s tag to be changed at all - in a perfect world theButton
would always render a<button>
and theLink
would always render a valid<a>
with a validhref
attribute on it - but I know we need a bit of flexibility in our system! Just food for thought!