We currently have separate onDragStart, onDragEnd and onChange events. Combined with the native onClick these cause a somewhat unintuitive call order.
How I understand the use cases of the onDrag* events is to start validation or some other expensive operation only after the user has ended the drag.
I think a simpler solution would be to actually implement onInput and onChange listeners. This means that no onChange is fired during drag anymore. We would however fire onInput throughout this process.
An example of a user interface involving both interactive manipulation and a commit action would be a Range controls that use a slider, when manipulated using a pointing device. While the user is dragging the control's knob, input events would fire whenever the position changed, whereas the change event would only fire when the user let go of the knob, committing to a specific value.
-- https://html.spec.whatwg.org/multipage/input.html#common-input-element-events
We could get rid of some bad ergonomics with onDrag* handlers as well as enabling cross-browser behavior for onInput and onChange.
Other resources:
Search keywords:
We currently have separate
onDragStart,onDragEndandonChangeevents. Combined with the nativeonClickthese cause a somewhat unintuitive call order.How I understand the use cases of the
onDrag*events is to start validation or some other expensive operation only after the user has ended the drag.I think a simpler solution would be to actually implement
onInputandonChangelisteners. This means that noonChangeis fired during drag anymore. We would however fireonInputthroughout this process.We could get rid of some bad ergonomics with
onDrag*handlers as well as enabling cross-browser behavior for onInput and onChange.Other resources:
Search keywords: