31–40 of 82 posts
I don’t believe a two-state button is standard HTML.
I've played with some buttons that struck me as fairly standard and found that they have exactly the semantics implemented here (to fire, you need to press down inside the button area, hold down (leaving the area or not), and release inside the area).
I don’t believe a two-state button is standard HTML.
Not sure what you mean. I've played with some buttons that struck me as fairly standard and found that they have exactly the semantics implemented here (to fire, you need to press down inside the button area, hold down (leaving the area or not), and release inside the area).
This diagram is showing more checkbox behavior rather than button.
Here’s my first attempt. (Probably wrong, since I did it by hand.)
(enter,leave,|press,(enter,leave,)*release,|press,enter,release,leave,|enter,press,leave,(enter,leave,)*release,)*(enter|press,enter,(leave,enter,)*release),press,(leave,enter,)*,release
Its all fun and games until somebody managed to click on your button without hovering first.
I see two ways to do that: 1. keyboard navigation (Enter and space are ignored) 2. hover, then F5 to reload the page (this resets the state, and you get your cursor on the button without a state transition) presses are completely ignored either way
Its all fun and games until somebody managed to click on your button without hovering first.
I see two ways to do that: 1. keyboard navigation (Enter and space are ignored) 2. hover, then F5 to reload the page (this resets the state, and you get your cursor on the button without a state transition) presses are completely ignored either way
Earlier quoted context omitted.
Right click locks you in the "press" state, just so you know.
No repro here (Chrome 99 on Windows): right-clicking the button works the same as left-clicking it (yes, there's my browser's context-menu, but it doesn't seem to interfere with the webpage's logic at my end).
Still a crazy cool demo though. Having worked on ui for my hobby games, I always knew it was more complex than just onClick, but this makes me understand it perfectly. I'm probably going to implement a model based on this in my current project.
This is something I created many, many years back for Stanford’s CS103 course as a lecture demo. Apologies for the lack of mobile support - I’ve always presented this from my laptop. :-)
I know this is nitpicky, and yes, I see that "fire!" is an accepting state, but maybe you could have a special transition from "fire!" to "hover" labelled "reset".
This is something I created many, many years back for Stanford’s CS103 course as a lecture demo. Apologies for the lack of mobile support - I’ve always presented this from my laptop. :-)
nice! how about something like that for drag/drop? anyone? :)
It's funny that buttons are the "Hello World" of frontend components, because they're actually feverishly nuanced.
I wrote a proof of concept for one of these, using XState, a few months back.
My use case was a cross platform react native button -- which means there's technically a difference between "pressed" and "hover" -- and there's also a loading state, which required special handling for the a11y state.
https://codesandbox.io/s/fervent-shirley-dgesq?file=/src/Pre...
NOTE: this will open a popup (might have to enable popups) with the visualizer, and it defaults to the a11y machine, but there's a drop down to switch to the main button machine.