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.
Related
I know that some browsers provide supported HID events via a definied onXYZ property in document, so that one might test e.g. for touch support by testing
if ("ontouchstart" in document) {
...
}
The question is: which specification defines that a element should contain these onXYZ properties?
This question is not about: can I use this, should I use this, which browser supports this...
I've looked through nearly all DOM, events related specifications in
http://www.w3.org/TR/tr-technology-stds
but didn't found a trace.
Update: Clarification:
I'm looking for a specification wording like this:
A browser should define a attribute named onEVENTNAME if it does trigger EVENTNAME on some event.
Interface MouseEvents:
onmousedown: null; // define to tell there is a mousedown events can can be listened to
onmouseup: null;
...
DomElement implementes MouseEvents:
...
The property on the object whose name starts with "on" followed by the event type name is called the "Event Handler IDL Attribute". Note that an Event Handler is not the same thing as an Event Listener.
Section 7.1.5.2.1 of HTML5.1 lists the Event Handler IDL Attributes and the objects to which they apply.
Note that this doesn't include the Touch interface. There's two points to take from that.
There's no requirement for there to be ontouchstart, ontouchend, etc event handlers, either in HTML5 or in the Touch Events spec, and indeed they are not necessary to use touch events, since listeners can be matched with the event types using addEventListener.
There's nothing that precludes a new or updated spec from adding a requirement for event handlers for such events, nor from browsers implementing such handlers in advance of them being documented in a spec.
As a consequence, if ("ontouchstart" in document) is not a good test. Maybe a better way of testing for touch support would be creating a TouchEvent and checking its type.
Incidentally, contrast the Touch events spec, which doesn't mention event handlers, with the more hardware agnostic Pointer events spec which does provide a list of event handlers for pointer events
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.
I've an element that can be dragged using native HTML5. It has dragstart, drag, and dragend event listeners assigned to it. In addition, I also have keydown and keyup event listeners assigned to document.body element.
When dragging the draggable element, ondrag event will fire as expected. When I press & release any key while not dragging anything, document.body keydown/up events will fire.
However, if I keydown/up while performing ondrag, the document.body keydown/up event will not fire. Is there any workaround/hack to this?
Answering my own questions... From Drag Operations - MDN:
With the dragenter and dragover event, the dropEffect property is
initialized to the effect that the user is requesting. The user can
modify the desired effect by pressing modifier keys. Although the
exact keys used vary by platform, typically the Shift and Control keys
would be used to switch between copying, moving and linking.
On HTML5 native drag, the only key press that can trigger anything is the modifier keys. On Mac, it's the option key and the control key. Action is captured via event.dataTransfer.effectAllowed, not keypress or keydown events.
I just found out that onchange event does not bubble in MSIE. I hopped to http://www.quirksmode.org/ to see if I could find other events which are not supported by IE. However I do not see any chart listing onchange event as an event that does not bubble in MSIE. Where can I find such a char?
Actually, MSDN is quite explicit about their implementation not bubbling (unsurprisingly, doing complete opposite of what DOM Level 2 Events module specifies).
I'm not sure why PPK table claims bubbling as untestable in IE. Could be an oversight on his part.
I want to catch which element is on focus when users use tab key to move their focus. For example, there is a form and users can use tab key to move forward to next form element. I'd like to know which element is the current on focus.
Thanks,
Paul
For many event types one can use event delegation, whereby one captures the event on some containing element as it bubbles up the document hierarchy, and then establishes the element on which the event originated. Unfortunately, the focus, blur, and
change events do not bubble.
However, in DOM implementations that implement the standard DOM Events model, one can instead use the capture phase, which intercepts the event on its way down to the element where it will fire.
This doesn't work in (surprise, surprise) Internet Explorer (IE), which still doesn't have an implementation of the standard event model, even in IE8. However, IE has its own focusin and focusout events, which do bubble.
The end result is that, as usual, one has to write one's code so as to deal with the way proper browsers work, and also with the way IE works.
Luckily this is one of those cases where ppk (aka Peter-Paul Koch) of quirksmode.org has already done the hard work: his article Delegating the focus and blur events should tell you all you need to know, as well as providing a succinct explanation of how event delegation works.
use the onFocus event on the form elements, so
<form>
<input id="fred" type="text" onFocus="alert('focused this');"/>
</form>
check out http://www.w3.org/TR/html4/interact/scripts.html#adef-onfocus
there are javascript events that are related to focus. The onfocus and onblur (opposite of focus) events can be used to update a variable that says which form element is currently in focus.