This page hooks up mouseenter and mouse leave events to the document body, and to dynamically generated DIV tags each containing an IFRAME

This page also hooks up CSS :hover pseudo-class for styling the border on said DIVs which contain the IFRAME

This page also hooks up 2 onload event handlers to the main window, as well as an onload event handler for each IFRAME

In all cases, when available via the type of browser, the event handlers are registered with the "useCapture" of addEventListener set to true. Note that this obviously does not work with Internet Explorer 8 and below since there is no such thing as "capturing" from the top down (attachEvent is used instead). All event handler functions (again when possible), will attempt to "cancel" each event and stop propagation to other handlers.

Note the following behavior in browsers which support DOM Level 3 event handling:
  1. The first onload event for the main window is called. This event handler calls stopImmediatePropagation. Said event handler was registered with "useCapture" set to true.

    The 2nd onload event handler for the main window is NOT called. This is because the 1st event handler (as noted above) called stopImmediatePropagation.

    1st question: What is a valid use-case for for allowing the 1st event handler to stop the 2nd event handler from being called? One is just a sibling of the other. There is no default action for the load event, the event is not "cancellable", and it does not bubble (in fact it's not captureable either see below). The 1st event handler cannot know anything about the 2nd event handler unless the 2 sets of code are tied together in some way. But if they came from different teams / modules on the page, they don't necessarily know about each other. Other events such as focus, blur, mouseenter, mouseleave also seem to fall into this category. Being able to capture them might be desirable, but I cannot think of any reason why stopping propagation to other handlers would be a good thing.

  2. Remember, we attached 2 window onload events with the "useCapture" mode set to true. As noted above, we also attached onload events to each IFRAME (also with useCapture to true, but that's irrelavent).

    Since onload event handler for the main window is set to be capturing you would expect other load events to propagate down, allowing you to capture the load event for each IFRAME via that 1st handler.

    This of course does not work. The load event does not traverse down the document tree. (We also know it does not bubble up of course because the spec says so. . . ) Note that I do believe this is the correct behavior for the given event. 2nd question: Why is the load event special? Do other UI events behave this way? Do any mouse events or keyboard events or focus events behave this way?

  3. If you move your mouse into the document area (anywhere below horizontal line), you will see mouseenter and mouseleave events fired and handled by the handler attached to the BODY element (note that this does not work in web-kit based browsers as they have no support for mouseenter / mouseleave events).

    You'll also note that as you move the mouse, this event will be fired multiple times, as you cross from child elements in the page to other child elements in the page.

    The mouseenter description says:

    A user agent must dispatch this event when a pointing device is moved onto the boundaries
    of an element or one of its descendent elements. This event type is similar to mouseover,
    but differs in that it does not bubble, and must not be dispatched when the pointer device
    moves from an element onto the boundaries of one of its descendent elements.
    										
    Clearly multiple mouseenter events are being fired as the mouse pointer moves from each descendant element, which according to the spec should not be happening. It should have only fired a single time when the mouse moved over any given element in the page. From a capturing perspective this event is behaving exactly like mouseover even though that was certainly not the intention.

    Note that running this page in IE 8 and below, this of course does not happen. Those browsers only have bubbling, and the mouseenter event doesn't bubble. Moving the pointer anywhere into the document triggers 1 and only 1 mouseenter event. Moving between elements does nothing (unless a mouseenter event handler is again specified on some other element see below).

    Again we note that the "useCapture" flag was set, and that the BODY level event handler is cancelling all default and propagation. If you move your mouse over the IFRAME elements (above the horizontal line where "Sub-IFrame 0" or "Sub-IFrame 1"), you'll notice as we log the events in the bottom left, that the BODY event handler received a mouseenter event (again this seems wrong), and then cancelled propagation and the mouseenter event handlers for the DIV surrounding said IFRAME DO NOT FIRE.

    At the same time the :hover CSS pseudo-class IS triggered (note the red border).

    This seems like an unintended consequence of stopImmediatePropagation combined with useCapture. You shouldn't be able to capture, and thereby cancel / not have events fired on the DIV element surrounding the IFRAME b/c the event should have only fired to the IFRAME and not to the document BODY. As noted with IE 8 and below, you cannot stop event handlers from being called for this event b/c THERE IS NO PROPAGATION, since the event does not bubble.

    The original intent of mouseenter was to have a mouse handler event that only fired when the mouse was moved somewhere into that element, and only be fired one time. If you have say a large block element with 100s or 1000s of child nodes, adding a mouseover event handler (whether capturing or bubbling) would result in said handler being fired dozens or more times per second depending on the structure creating unintended performance issues. So instead, using a mouseenter handler, you simply get one event fired to you without being worried about getting called too much. In today's DOM Level 3 model, this feature is essentially removed.

    3rd question: Is this intended? In turn why is it ok that CSS psuedo-classes then will still work but the event binding itself will not? Aren't you just creating a scenario where someone will end up just polling for computed style to know if the mouse pointer is over their element?