My video sparked debate on Twitter, and John Carmack left some (really good) comments. Also pointed out that Chrome changes tabs on press, not on "click". "To perform an action with act-on-release you need to both hit the button, then keep the pointer on target until you perform the release action. If you have a jittery point location, as you do with hand tracking, controllers held away from the body, or old age, this can result in many fail-to-activate cases. You also want generously sized and spaced buttons, but that is an orthogonal effect."

Since I was the person that implemented the original OpenGL based keyboard on Quest (originally GearVR), I thought I’d provide some additional context. John is correct wrt static UI, but I was also one of the people pushing back on his requests to apply this more broadly (such as to nearly everything). Although, I was not the person requesting a study, as the keyboard case was obvious to me ONLY because a text keyboard can easily roll-back characters if you end up holding the key (try holding “n” on the stock iphone keyboard and also note they do act on release). The main issue is still how often buttons are in scrollable UI. At one point I sent him several screenshots with all scrollable containers tinted red (most of the screen) to illustrate how common it was. In this video, the impression was given that scrollable containers aren’t a concern, but that was only because the mobile browser ignored your request to act immediately on press/down, and delayed invoking your handler until it could determine you weren’t scrolling. Thus you also weren’t getting the full latency improvements John was advocating for. In the end, there is some validity to John’s argument but it’s not as simple as just switching things over to press/down events. * UI frameworks would need to be updated to do a delayed down event while detecting intent-to-scroll * not-currently-scrollable containers are more common that never-scrollable so they could certainly benefit opportunistically at the cost of minor inconsistency * any press-and-hold interfaces (think context menus) would need to be replaced or support roll-back logic. * any drag & drop UI would need similar intent-to-drag delays Also note - on mobile, intent-to-scroll (or drag) is significantly easier/better than in VR because a touch digitizer samples input at 300-1000hz vs 72-120hz in VR for controllers and significantly less for hand tracking. The precision of your finger is also higher on mobile vs. VR controllers and esp. hand tracking (requiring bigger deadzones and/or delays). So there you have it - it’s not like the eng at Meta were dumb and didn’t want to have latency improvements, it’s just that we actually have to implement/support all this along with all the edge cases and it’s competing with a million other requests. If it was as trivial as just replacing click with onmousedown, we would have done that years ago.

The whole "undoing" a click is HUGE for me, and I'd hate to see it go...

HTMX supports "fetch on press, show on release", which massively cuts back the time it takes to navigate between webpages. It also supports "fetch on hover", which saves even more time, because it usually takes ~100ms before you press after a hover. It does risk fetching too much, like when you quickly swipe your cursor across a menu, but I believe they thought of that too and solved it for most cases.

I think it's better to trigger on mouse up most of the time due to the user being able to cancel accidental clicks.

Assistive technologies have far better support for the click event than the mousedown event. The click event also includes handlers for keyboard interactions with the space bar or the return key. Please don't forget about accessibility!

And then there's WCAG, Success Criterion 2.5.2 Pointer Cancellation

He is wrong. So many times I've held down on a button, then realized I've changed my mind. So I can release it without clicking.

One thing to mention: on things that should be on release, you can still have a little effect on press. Buttons are like that, to have 4 states: normal, hover, active (aka on pressed, no released) and disabled .... if I remember correctly. Having something like a color change on press would still maintain the feeling of very fast interaction.

This not only goes against accessibility, but also user expectation Imagine 99.9% of websites follow one standard, but you decide to go against it, just so your contact button has a potential saving of ~10ms I especially hope no one uses on press for important actions, such as confirmations

I thought Carmack denied that he was the one who wrote the fast inverse square root function. AFAIK it's actually unknown who wrote it. Edit: did mobile always handle onMouseDown correctly? I swear I have unintentionally clicked buttons while scrolling a lot in the past.

It can be annoying though - tiktok uses the ontouchstart trigger for one of its buttons but if you touch it when scrolling, it gets pressed and the scroll is cancelled.

No. Don't just do this everywhere. Understand your game/app. Then apply it where it's needed.

Mixed feelings. I can see the value in some games / high speed situations... But for most work apps etc, it speeds me up to be able to click at the speed of thought, and be able to "undo" the click by dragging off the button before letting go... That way, each click is less deliberate / more optimistic, and the few extra millisecond before I let go of the button are enough time to hit the brakes on the action if it's wrong. I feel like with "act on press", I'd need to be way more deliberate with every interaction, and it's stressing me out just thinking about it. Although to be honest I'm sure this is something one would adjust to quite quickly, and is probably less significant than any of us here is making it out to be.

Navigation on mouse down sucks when you just want to grab a link and drop it into a new tab or a separate window as the url. The same goes for buttons that navigate you with js without being anchors so you also can't middle click / ctrl click them into a new tab that way.

The amount of times ive clicked a button by accident and ive saved myself by holding down left click and dragging ny mouse off of the button is crazy. I actually love that part of it

While I do understand his arguments. I really don't want accidental click when I use my touchpad, cause yeah, if I was unlucky enough to stop using the touchpad with a cursor on an element and have touch to click, damn. retaking control of the cursor without clicking is going to be hard. Being able to move the cursor OUT of the element before release to avoid clicking have saved me more than a few times. Also, it's not than phone browser knows to ignore, but that the phone do not send the event to the browser in the first place. at least, it used to be the case on older iphone if I remember correctly

I'd hate this on "send"/"confirm" buttons, where I might decide to NOT do that at the last second, and I can just drag my mouse away to cancel it. App devs, Carmack is a legend, but please don't listen to him here.

Somehow I get the feeling this breaks accessibility unintentionally. It's interesting that it fired on a touch event, maybe mobile logic lets it work if it's the only event specified. Keyboard navigation is another concern. That said, it does feel nicer to fire on a down event.

I think that for sensitive or potentially destructive operations, buttons should act on release. Many times I have pressed a button to later think again and move the mouse over to cancel :p

The cost of a mistake can sometimes be too high. The ability to undo an action is a crucial aspect of good user experience, allowing users to correct their errors.

The phone VR issue (applied to early VR headsets too) was not about fps (though 90+ fps is best for a feeling of presence within the virtual world), but about latency. The world catching up slowly when you turned your head was due to latency between you moving and the system detecting the movement, updating coordinates for the renderer, and sending the image to the screen so that photons could hit your retina. That is a chain of events where latency adds up at each step. It would not matter if you had a 200 fps renderer if the other steps had significant latency.

I love John, and I love that you prefaced this video with some background on why people should listen to him when he talks. I love, even more, that you still thought critically as you listened and went and tried things out for yourself instead of accepting his experience and opinion as fact. Keep up the good work.

A me problem: I like to have to option to cancel my click action, if I have the reflex to do so. A "web" problem: Buttons on the web have this really cool feature that when you focus on it with your keyboard and press spacebar (Enter too, I think), it calls the onclick function. The onmousedown event, on the other hand, it's not called. So you would either be sacrificing accessibility by doing nothing, or give you more work to do to ensure the native behavior still works (listening to keyboard events, checking if it's "spacebar" and if it is, call the onclick function, etc etc etc).

When the page layout changes from a result of a keydown, I imagine could cause problems. And if we want to mix different types of buttons, we really should have a visual language to tell the user what to expect. In VR UIs I can fully see how keydown events are better, I dont how many times I've missed a button because my hand shaked a bit before I was able to let go of the trigger. Hmm... Why are we using the pistol grip for VR cursor actions anyway? Is that really the most stable way? Could a reverse-flashlight-like grip be more stable than a pistol grip to avoid click-shaking?

I agree with him in a game. I do not agree with him on the web. People tend to forget that Carmack is a game developer, do not apply his wisdom outside of games, that does not really work. You can absolutely do things on press even on the web, increment and decrement quantity in a shopping cart for example. If it is easy to revert the change, go ahead. If not, use the release event.

I'm more in the on-release camp. So many times I do that "click - oops! - drag off the control - release" thing. For FPS games, sure, act upon press. For most UIs, nope.

Thx for reading "less" as "fewer" correctly 🤓👌

An important piece to the post I believe is building things to be “undoable” as much as possible. This helps negate accidental clicks, and if something is truly destructive a confirmation modal should probably be required

I think you could get the "best of both worlds" if you have an `onMouseUp` registered to `` that executes an undo on the last operation done in the UI if it is hit, while you have an `onMouseUp` directly on the element that simply cancels event bubbling. Then if you press and hold, then move away before releasing, it reverts whatever that change was but if you press and release then it already started doing that operation on the `onMouseDown` event as Carmack is calling for. This would require that your UI maintains an undo mechanism under the hood, but people are people and make mistakes, so that's *probably* a good idea to have anyway?

This might be okay for states that are temporary, however, I see a lot of alternate considerations like WCAG. I certainly want the ability to opt out of buying something after mouse press by moving away from the button as many others would. So we get the best of both worlds, how about we load the state during on mouse down but don’t commit the change until the click is registered on the element; this would be especially useful for making fetching data from the server more seamless.

This should be a user-specified OS setting. Users should be able to choose which event they prefer to count as "click", and applications (including browsers) should hook-in to this OS setting.

Many game UIs also act on button press and not release. Also, holding a button down will fire multiple press events in quick succession. Xbox guide uses tabs and if I want to go from tab 1 (games and pins) to tab 6 (settings and power) I press shoulder button once instead of five. It feels fast and indeed snappy, and I love it since I tinker with settings a lot. And here's the kicker: keyboard navigation in the browser works exactly this way too. I think UI designers would level up if they learn the intricacies of other input methods and not only mouse and touch

I use "release miss" many times to cancel click, probably some "unrecoverable" operations should use "up" event but all simple operations should use "down"

Wish you explored this in a mobile context, because as a mobile user I would HATE if I mis-tapped a button while I was trying to scroll the screen and activate something I didn't want to.

moving forward with this is a good idea, it will teach people to watch what they click before they click it

On press for navigation and other non-sending actions, on click for submitting should be a fine compromise.

It depends on what is more important, speed (or time accuracy) or avoiding accidental clicks. You can see this with Google's stopwatch. The start/stop button acts on press, the reset button acts on release. And it makes sense. That's also probably the reason why act on press is more common in games.

I think it would be great to do mouse down for interactive within the page, where the risk of it not being able to be cancelled is a lot smaller that doing it with navigations

I don't know about other areas, but on the web, "Act on Release" is a must, users must be able to cancel a click or a touch on a button or a link.

I went through this conundrum recently when building some TV apps (with a Netflix-like 'Row/List' UI) where the interaction is using a remote control. I went with the 'press' in the end. It just felt better.

OnPress by default. On release for heavy, possibly destructive, hard to cancel/undo operations.

I just went and onMouseDown'd something and it felt like precognition.

I have ADHD. I have to select the text I use multiple times by double click or triple clicking it. When there's a button, I keep pressing the button, then drag away to not trigger it. I keep doing that with all the buttons. Or a press it, then check if the form is filled correctly, then mouse up when I verified. I guess form buttons are different than a menu button or something like that?

Huh, this disproved a couple of doubts I had, sounds like the better way. But I will add that apps/websites should provide a way to undo any accidental click, unfortunately many aren't designed for that.

Except you need to decide if user pressed the button or started the scrolling/gesture. So if you act on the press, how would you decide?

For the car example at 8:00. Modern cars don't use a turn key anymore, it's a push button to start the car, and that push button is not "on press", it's "on hold" along with other "if" conditions like holding down the brake pedal, or checking some sensors if mechanical damage consequences are detected. The handbrake on modern cars is no longer a lever pulling a steel cable, it's an electronic button that you hold for a few seconds while the computer go through its "if" conditions, like the brake will act differently depending if parked or driving at high speed. If you mess too much with the electronic parking brake in a too short period of time, it will fall into standby mode. The turn signal lever is a toggle switch letting electric current through, so you'd think that's kind of "on press", well not always since some drivers are complaining of few seconds delay before the light bulb start blinking on a faulty wiring curcuit that needs maintenance.

Please don't. There's a reason why he can't get traction for his idea. UI developers know more about how UI works than a game developer. Users do not perceive acting on mouse up to be slow. And the only users who unintentionally move the mouse between mousedown and mouseup are the ones with a shake and thus are more likely to misclick. They need the option to opt out of a click. Then there's mobile, where touching the screen can be a scroll attempt or even an errant press. People have learned that you move the mouse to cancel a click, and slide your finger to cancel a touch. Don't mess with people's intuition just to create a more "responsive" experience they won't notice. There's a reason why UI developers will intentionally add delay. Outside of games or other fast action situations, people want a more deliberate pace. They don't even perceive it as lag.

one recent trend in gaming is to use hold actions and i can only guess it originated from consoles where you dont have a 10x keyboard to choose your inputs from. so most recent games i played have a double, sometimes tripple assignment for buttons if you count double tapping as well. i would say generally double assignments are to be avoided and maybe a more context sensitive action would be preferable and also better suited for act on press. it all depends on the context of course, but i agree for most cases act on press would be better. but more as a guideline than a rule

06:52 there are virtual keyboards like onboard that are on release (by default) because you can hold to open character selector

Sometimes I accidentally press something and I hate not being able to drag away while holding to prevent it from happening

It's funny because this issue comes up in all the Fromsoft games with how they handle both rolling and running with one button. Once you're familiar with that negative edge/on-release behavior, it's not too problematic. But to new players, it simply makes for countless moments where they say "i pressed roll!" but they didn't roll and they died. This causes a similar issue in Escape From Tarkov, where the reload key has multiple uses.. one function is the normal reload action, the other is a quick reload that drops your magazine when you double-tap the reload key. This seems fine on the surface, except that it mandates waiting for a set amount of time on each press of that key to see if another keypress comes in. So even if you have it set to on-press, which you can thankfully in Tarkov, it still waits 300ms by default to see if you press it again to make it a double-press. So, one of the common tips is to either swap the bindings, and mash R any time you want to do a normal reload, because it'll start as soon as that double-press is confirmed.. or rebind the Quick Reload action to some other key, and keep the double-press binding empty (which thankfully does allow the game to do the single-press action instantly -- it only invokes the double-press timer for a given key if that key has a double-press action.. kudos to them for this, or the game would literally be unplayable because *every* action would have a 300ms delay).

Azure uses it and it always surprises me when it triggers sooner than I expected

I agree with Carmack with this one and the solution about canceling a misclick (which also was something I was worried about) is quite simple in most cases. - If it is a destructive and irreversible action (or long computation/animation): confirmation dialog (which should already be used in such cases) - Otherwise, allow undo-ing. Could be an actual undo-state that works with ctrl+z, or another button or whatever makes sense. Like a "close" button, a "back", a "decrement" or an "undo". Besides, how frequently do we even misclick? It might be so rare that it makes no sense to not improve everywhere else just for this.

Getting this sort of info at me, which I'd likely otherwise miss, is why I watch Theo's videos.

What about sliders? When I use sliders I always expect the release to be when the value is captured.

Don't forget that onpress is also used for selecting and dragging and dropping! A user might want to do that instead of clicking!

The Google store uses on mouse down and I had it miss fire twice when I scroll. So on heavier pages it does interfere with scrolling.

How does this influence the accessibility of the application?

I love being able to click and move way to stop the event from triggering on things like a crafting button in a game, this type of feature saved me many times with important things, everything else should be on mousedown lol

I think for desktop it makes sense but for phones what counts as a press if it isn't firm? If I am scrolling on the phone and touch pixels while doing so should that count as a press? I feel like press and releasing while still on the same element helps ensure you had an intentional click as opposed to something like Instagram where you can very often accidentally like a bunch of comments. I'm not much of a UI guy so I probably got something wrong. Would be nice if someone has another opinion. edit - Just watched the video and guess you bought up the same issues. Thought I'd comment before just to unbias my thoughts first.

Do all mobile browsers handle onmousedown like that? Firefox, Safari, and Chrome?

I've been doing that for buttons where the actions is not too commiting

For me the thing is that the ability to move mouse away and release when I misclicked is way more important than the delay in the interaction.

wow how did you get it working like that on your phone with just a local network, whenever I tried that it never worked

But a button that has to do something on onMouseDown will do that even if we do a right click on that button. So how would you fix that?

Been fixing games like this with steam input forever. Makes Dark Souls rolls actually usable

Legendary quotes: „Why the f*ck” - John Carmack

How can i incorporate this in shadcn style buttons?

I also like to be able to cancel the action by moving away and release it, I guess for critical parts where you need that functionality, keeping track of the last action and undoing it could solve the problem, it makes the code way more complex though, but it's worth it if you already have the framework to undo it.

Using SDL you can capture button down / up events.. makes things super flexible

I'm going to have to try this out and see if I like it. I suspect I will. Just don't know if it will create a bunch of other issues. But it is a good idea to experiment with for sure. For draggable elements I probably just use onClick, but for non draggable elements I think that is fine. The fact that users can "cancel" a click by dragging afterwards is probably not a use case I would sacrifice better responsiveness for.

I would hazard a guess that the reason we do it this way (on release) is because that's already how it works on Windows (maybe OSs in general, but I wouldn't know). I don't think most people would notice the difference between the two, and I'm curious to see how it'd change the experience in each setting. P.s.: Going on mouse down some stuff sounds like my new favorite euphemism.

“Act On Press” - John Carmack's Bad Take On UI

Can't fully agree on this one. Way too many times I find myself changing my mind as I'm clicking on something and glad I'm able to slide off before releasing. I definitely prefer that chance to correct a mistake over some perceived "snappiness" to programs.

4:19 that’s my only concern, but I guess you can always use other design standards like confirmation modals or something similar perhaps?

my brokerage mobile app actually has press activation on the managing order screen so when you scrolling down to the confirm button you can actually accidentally change shit like type of execution, time delays and even position size. it got me by surprise several times before i realized that's not just because i'm bad and put it wrong numbers and options.

3:00 I believe it's a problem called magic mouse for macs (as you use mac and that mouse). Sensor is quite in front of the mouse so when you want to click on things, it was to drag that thing as mouse moves a bit on click. Super annoying

In my own web development, I separated out the functions for touch and click. I separated out mobile and desktop versions. If I, a nothing early js developer could figure it out, massive conglomerates can too. Make responsive ui when you can.

I don't get the argument that onPress feels more responsive. I'm sitting here pressing random onRelease buttons right now and they feel perfectly responsive to me. I much prefer being able to correct my mistake by moving my pointer/finger away before releasing than the extra 10ms or whatever that I don't even notice. Maybe in a high-paced game I would notice. For example, I can see the argument that a gun should shoot on the _press_ of a mouse click, rather than on release. But for most regular 2D UI buttons I think onRelease is the way to go.

What is the react native equivalent to onmousedown?

This comes down to expected behavior of the type of UI element. Act on release might be best for things that commit the changes but for everything else it is fair game.

If you want to support dragging (e.g. clicking and holding on a link in your browser lets you drag it to the desktop to make a shortcut) then you can't have the action occur on mouse down. But for simple buttons, e.g. in a game UI, I definitely prefer to do the action on mouse down. It depends on the context. Both are useful.

How did it happen that we did not adopt act on press for mouse buttons when that is what we have always expected for keyboards ?

Ive tested the on mouse down while scrolling issue on my Android with react native once and it was definetly a problem, maybe the Browser or platform is obscuring the result here

I got a fancy ergo keyboard recently and I've been playing around with hold-tap behaviors, and I agree with him there too. Can't stand the uncertainty when I press a key, I don't understand how people live with homerow mods etc. I tried having some lesser-used peripheral keys as mod-tap, and even that got annoying. I want instant and expected behavior when I press, and changes only happen via layers/modifiers.

The problem with onmousedown is it listens on any mousclick (left, right, scroll wheel click etc.)

You could start a transaction on mousedown, finalize on mouseup, and rollback on mouseleave

If you have a more than minimal move event before the release, you could abort / undo the action.

don't take away my ability to overthink a click before i actually commit to it 😭

If youtube had done this I would have subscribed to theo by now.

Oh no, please don’t! On release is a learned behavior, people know they can still drag their mouse away from the button before releasing to prevent the action to be called. Please don’t take this away from us! For most interactions people wouldn’t even notice, because when working in an app you don’t look at the counter. Most people here are probably working on apps where there are much bigger performance improvements can be made without breaking user expectations. Most people aren’t working on a keyboard on a VR headset, they are working on some random banking app that talks to some legacy backend and every page takes 15 seconds to load. But now they saved two full frames and all they had to do was to break 40 years of learned behavior!

tempting but would pass it for the web, I have a feeling that the annoyance of not being able to cancel when I want to would outweigh the micro win between the mouse down and up, it doesn't happen that often so I am not sure how exactly would you do a research that would take that in account

The like button acts on release. I recommend everyone to try it :D

yeah I came across this issue not too long ago where I had a modal with a form in it and a background overlay that would listen to a click event to close it - what used to happen was if you selected some text in an input and end up on the overlay while doing it the modal would close on release, because the user released when on the overlay I hadn’t thought much about it after that but this makes total sense, especially the real world examples I’m gonna be advocating for this at work now for most of the use cases So I changed it to mouse down and problem solved

Just depends on what is being clicked for me. If I have a form with checkboxes and a submit button. The checkboxes/other inputs should be on press, and the submit should be on release. Tons of different cases, But I think the mindset of using on press as the default choice is correct.

I feel like using on release events mostly originated in game development when development kits like microsofts XNA framework were introduced and game dev became possible for the average person to make a game. there was often no delay by default where if you press for a second you'd end up with 1000 tiggered events. it was easier to simply use on release in most cases related to the game ui than to have to write some custom delay/debounce functionality with custom input. it's simply laziness, they want to make the game, they don't want to write the code.

I usually press all the buttons and undo at the same time.

The very thing you showed: Pressing a button and mentioning I didn't want that so I move away from the button and release then to cancel the action is something I think John did not consider. I was implementing for a pure C++ OpenGL GUI some widget logic and that part: Remembering what was pressed and released on to trigger correct "click" events was the greatest pain I ever had implementing some rudiementary logic and I still feel I missed corner cases where some kind of interaction should happen but I do not handle correctly.

I have been fighting on this hill for a long time, nice to know I will die on the same battlefield as Carmack.