3 ms·
You can use <div role=button tabindex=0>.
by 7786655 6y ago
You can use <div role=button tabindex=0>.
- extra88 6y agoTabindex=0 means you can tab to it but you still can’t press Enter or the space bar to activate it like a real button. So now you have to bind a keypress listener. Use a real <button>! You can style it.
- LeonB 6y agoSafari on iOS does not consistently apply HTML standards.
- extra88 6y agoNo browser consistently applies HTML standards and nothing but HTML standards. In this case, your complaint is probably about the browser prefixed property and value, -webkit-appearance: button. This is a good article about Overriding Default Button Styles that also touches on why one should use a genuine <button>: https://css-tricks.com/overriding-default-button-styles/ https://css-tricks.com/overriding-default-button-styles/
- LeonB 6y agoThanks for that link. I’ve read so many of these, and it all comes down to a trade off which they decide goes a particular way but I don’t feel convinced by their reasoning. It still seems like, in cases where the appearance has to be pixel perfect you can either: add a few lines of accessibility code to a .button (which is consistently described every where I look), or add many many more lines of css reset code, which is quite opaque. The article you linked says that to reset the style... you end up applying -webkit-appearance:button. Whereas I thought the style reset would include removing that? Other sources online say that’s warranted. There is a choice to be made, and the sort of “semantic-fundamentalism” preaching I see in these articles seems to be used as a way to avoid truly weighing up the options. They treat guidelines as laws and try to justify it from there. For me: it depends.
- extra88 6y agoIt doesn't say to make the -webkit-appearance value 'button', that's the default. Change it to 'none'. Look at the first embedded Codepen, note it also has a -moz-appearance: none, it's not just Safari. I don't understand why someone would want to add multiple attributes plus a JavaScript keypress listener to the wrong element when you can instead add basically reusable "reset" CSS to the right element (<button>). You're making choices for the people using a site. If you use a <button> and don't get the CSS right, it doesn't always look the way you'd like for some people; if you don't use a <button> and an attribute or the JavaScript is wrong, it doesn't work at all for some people. You don't have total control over the appearance of everything in the browser anyway. Some people want or need to make changes (higher contrast, more readable font, etc.) to use the web and not using appropriate elements just makes it harder for them to do that. https://codepen.io/andybelldesign/pen/Vxpjvo https://codepen.io/andybelldesign/pen/Vxpjvo
- LeonB 6y agoIt sounds like you almost saw that there are trade offs involved in the two different approaches. But then just went for pejorative terms a bit more. There are some scenarios where total control of the style is an important part of the thing being built. I’m closing the browser now. I do appreciate the many constructive parts of what you’ve said. The preaching about what’s “wrong” I can skip. Like there’s some grand moral imperative not to connect a click handler to a div. Spare me!
- rado 6y agoThe click handler won't work with keyboard and who knows what else, which means broken accessibility, This is actually a moral issue (you shouldn't decide which people to exclude), as well as legal in some territories. And the button can be styles pixel perfect easily, as explained above.