What is the difference between the onpointerdown and onclick event handlers?
Are there any practical differences? Are the events not propagated the same up the DOM tree? Are there some devices that only respond to one of these events?
I initially assumed that it is only pointerdown that is triggered in touch devices or with a pen, but onclick seems to be triggered as well.
Are there any practical differences?
Yes there are.
pointerDown it's actually equivalent to onMouseDown but the main difference is that mouseDown only sends to an Element but pointerDown can be sent to Document, Window, and Element.
What is the difference between the onpointerdown and onclick event handlers?
pointerDown can captures the right/left/middle clicks.
onClick only captures the left click.
Live Example:
The example will make it clearer.
https://codepen.io/nawafscript/pen/WNEyRyO
To add to Nawaf answer:
The point in time when the evenhandlers are fired is also different (at least when using mouse).
onPointerDown fires when the mouse button is pressed down
onClick waits for press AND release of the mouse button.
Is there any solution to listen keydown event of two blue arrow on left top corner of keyboard in ios system in HTML input tag?
BTW:I tried to bind keydown event of input with a listener function. In response, other keys like qwer can be monitored while only those arrows can not.
thanks in advance.
Pretty straightforward, I've been searching high and low for a comprehensive list of all jQuery events that do not bubble but I have been unable to find one.
For example I am looking for events like image.load, XMLHttpRequest.error, etc.
The docs for jQuery's on() method says this (under "Additional Notes");
The focus and blur events are specified by the W3C to not bubble, but jQuery defines cross-browser focusin and focusout events that do bubble. When focus and blur are used to attach delegated event handlers, jQuery maps the names and delivers them as focusin and focusout respectively. For consistency and clarity, use the bubbling event type names.
In all browsers, the load, scroll, and error events (e.g., on an <img> element) do not bubble. In Internet Explorer 8 and lower, the paste and reset events do not bubble. Such events are not supported for use with delegation, but they can be used when the event handler is directly attached to the element generating the event.
I've bolded the most relevant sentences for emphasis.
Earlier in the docs (under "direct and delegated events", it also says this:
In Internet Explorer 8 and lower, a few events such as change and submit do not natively bubble but jQuery patches these to bubble and create consistent cross-browser behavior.
You'll also find that mouseleave and mouseenter do not bubble (use the mouseover and mouseout events for that). This is discussed in their respective docs.
I wouldn't begin to call the above list comprehensive, but it's a start. I'm not sure how XMLHttpRequest comes into it in your question; it isn't part of the DOM, therefore doesn't have any ancestors, therefore cannot really bubble in the same way as normal DOM events.
According to DOM Level 3 Events spec,
Events that bubble:
beforeinput, click, compositionstart, compositionupdate, compositionend, dblclick, focusin, focusout, input, keydown, keyup, mousedown, mousemove, mouseout, mouseover, mouseup, select, wheel.
Events that don't bubble:
abort, blur, error, focus, load, mouseenter, mouseleave, resize, scroll(*), unload
Note DOM Level 3 Events doesn't define all events, some of them are defined by HTML5 spec.
That spec is less clear, because doesn't always say if events bubble and defines some events in non-normative sections. In one of these it says that drag-and-drop events bubble:
dragstart, drag, dragenter, dragexit, dragleave, dragover, drop, dragend.
(*) When dispatched on the Document element, scroll event type MUST bubble to the defaultView object.
I am writing a web app that includes a search box that updates results as the user types.
The mechanism works because it is implemented identically on the desktop version.
The problem that I am having with it is that none of the event listeners (keydown, keyup, paste) are fired when the user enters text using a swipe input method.
Listening for a change event also doesn't work since the input must lose focus for the event to be fired.
With keyboards like Swype and Android's new keyboard supporting swiping this will be an easily noticed deficiency. What event should I listen for to detect this input?
The input event fires on each change to an input field (see fiddle) -- so you should use that instead of the other events. More info here: https://developer.mozilla.org/en-US/docs/Web/Reference/Events/input
I am trying to differentiate a click from a swipe in Javascript using touch events. I would like to know, is there a property in the touch event object that can be inspected to determine the difference on a 'touchend' event, or do you have to listen for both a touchstart or touchend AND a touchmove event? I am trying to minimise the number of event listeners I have to add to the DOM and am wondering if it is possible to do this by observing a single event? Specifically I am looking at webkit on iOS.
Don't bind to the click event at all. It responds much slower than the collection of touch events.
To check for a swipe, you need to listen for the touchstart and touchend events. Don't worry about touchmove unless you're planning on doing something when that event fires.
On the touchstart event, you will need to record the x/y position of the event. On the touchend event, do the same again. What you'll also need is some kind of threshold value, so that when you calculate the difference between x1-x2 and y1-y2 you can determine if it was a swipe or not.
Apple gives a meta-algorithm that involves touchmove here http://developer.apple.com/library/ios/#DOCUMENTATION/AppleApplications/Reference/SafariWebContent/HandlingEvents/HandlingEvents.html. Search on that page for "identify a swipe" and you'll find it.
I personally have never needed to use touchmove and successfully have used the technique I described above. However, either is a valid approach so you should investigate what works best for you.