by Mojah on 11/4/20, 10:24 AM with 26 comments
by jchw on 11/5/20, 5:48 AM
This has an additional benefit that even methods like PUT do not: it works no matter how many layers of your stack might have retry behavior (properly or improperly) and enables safe retry even when you can’t be sure if the request went through or not. The primary downside is that it introduces a single point of failure, though you could theoretically shard it by some property of the request such as the session key/user id/IP address. Still desirable if you have something you really don’t want to repeat, like a transaction. (Probably would be wise to also make those multiple stage, but nonetheless.)
Goes without saying you should definitely still mitigate this on the client side by updating the UI state if JavaScript is available.
by ktpsns on 11/5/20, 8:07 AM
Also since 2015 the mobile adaption increased more and more. On mobile devices, the "double tap" concept never was very important, I think (at least not in the web context).
Therefore my feeling is that this issue is mostly a thing from the past.
Nevertheless I sometimes see forms which implement this "disable after submission" principle. Especially when it's about money, such as when booking a hotel or flight, etc.
by Thorrez on 11/5/20, 7:13 AM
by wingerlang on 11/5/20, 5:18 AM
Literally only to open a file from finder, which I use in column mode so navigating is single clicking.
by anuila on 11/5/20, 4:05 AM
document.addEventListener('dblclick', event => {
if (event.target.closest('a, input, button'))
event.preventDefault()
})
by spiznnx on 11/5/20, 6:13 AM
by TonyTrapp on 11/5/20, 12:06 PM
by akersten on 11/5/20, 4:13 AM
The proposal should instead be for an attribute that prevents double-clicks, because that way browsers that have not implemented it still behave correctly. Additionally, you don't "break userspace" for millions of forms online that no longer work as the developer intended.
However, I'm skeptical that we need to encode this at all into the standard, since setting the `disabled` attribute on the submission button after submission is pretty much test case #0 of any serious online form development.
Amusingly, things have gotten a lot better since 2015 when this was written. That blob of JQuery is now replaced with binding the `disabled` attribute to `isSubmitted` state on your React-based webform. An interesting glimpse into the web-that-used-to-be.
by emmelaich on 11/5/20, 5:07 AM
I've seen new users in particular double click to open.
Then, since the machine is so busy, nothing happens for a bit.
Concerned, the user then double clicks again. At this point they start to despair or curse.
by treve on 11/5/20, 4:56 AM
Sadly, it doesn't seem browser vendors are very interested to support this.
by vim-guru on 11/5/20, 8:05 AM
by squam on 11/5/20, 4:11 AM
I agree this would be a more sensible behavior for form submission, but given that ship has long since sailed: https://xkcd.com/1172/