News for hackers. Stuff that matters.
Re:WebAssembly Studio by pickpuck on Thursday December 31, 2020 @11:58AM (#25594415)
> > 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.

Re:WebAssembly Studio by chrismorgan on Thursday December 31, 2020 @02:27PM (#25596159)
I 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.

Re:WebAssembly Studio by Stratoscope on Thursday December 31, 2020 @04:03PM (#25597106)
> 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?

Re:WebAssembly Studio by Kailhus on Friday January 01, 2021 @09:26AM (#25603451)
I find this very interesting and is something I get right as a habit.

Is there any resources pointing to such best practices and/or accessibility?

Re:WebAssembly Studio by Kailhus on Tuesday January 12, 2021 @06:22PM (#25755448)
I will answer myself with the latest resource I found: https://webaim.org/intro/