3 ms·
> > The buttons are clickable divs, not actual HTML buttons > It'd certainly be nice if everything just automagically worked about accessible UI but we're not
by pickpuck 6y ago
> > The buttons are clickable divs, not actual HTML buttons
> It'd certainly be nice if everything just automagically worked about accessible UI but we're not there yet
OP's suggestion is that the author should have used native HTML <button>, a simple solution that has worked since the beginning.
But you're right that it's not so elegant in reality:
You must remember to add type="button" attribute, otherwise clicking it could trigger page reload accidentally.
Most browsers still force <button> to retain its default display property. Within flowing text, it can never break naturally onto the next line, whereas an <a> link can.
It also can't be a flex or grid container in certain browsers, so you often need an inner element for proper spacing/positioning.
Note that the inner element would need to be a <span> not a <div> because <button> can only contain phrasing elements.
- chrismorgan 6y agoI quibble over a few of your points: (a) type="button" only does anything if the button is form-associated—otherwise it’s the default. And even then, if your button within a form is semantically submit buttons (as the Create button here is), the semantically-best technique is instead to leave the button as a submit button, and instead of using a click handler on the button, to use a submit handler on the form and do event.preventDefault() within it. (b) That buttons don’t wrap externally is a feature, not a bug. Links should wrap. Buttons should not. The point here is that it is a button, so it should use <button>, and this is just one of the reasons why. (c) <button> not supporting `display: flex` was Firefox-specific and fixed almost four years ago in Firefox 52. I believe the last fiddly alignment corner cases were fixed over two years ago also. So you can safely forget about that limitation now. (d) You shouldn’t want to put a div inside a button, any sort of button (whether <button> or any other technique). That’s not what buttons are.
- Stratoscope 6y ago> if your button within a form is semantically submit buttons (as the Create button here is), the semantically-best technique is instead to leave the button as a submit button, and instead of using a click handler on the button, to use a submit handler on the form and do event.preventDefault() within it. This is my biggest pet peeve with so many modern websites and web-based desktop apps. It's not just a matter of being semantically correct in some abstract sense, it completely breaks the user experience for a keyboard user like me. If you have a form with, say, two text fields, I expect to be able to type into the first field, hit Tab to the second one, type into that one, and press Enter to submit. All too often, when I press Enter, nothing happens! This is because of the very problem you described: the developer used a click event handler on the submit button instead of a submit handler on the form as they should have. It's such an easy thing to get right; why do so many get it wrong?