Re: HTML5 Feedback: Event bubbling and various event handler DOM attributes

On Wed, 19 May 2010 20:28:52 +0200, Travis Leithead <travil@microsoft.com>  
wrote:

> Event bubbling and specification of event handler DOM attributes
>
> In several places events are defined to fire as "simple events"...
>
> 4.8.9.7 The ready states
> "If the previous ready state was HAVE_CURRENT_DATA  or less, and the new  
> ready state is HAVE_FUTURE_DATA
> "    The user agent must queue a task to fire a **simple event** named  
> canplay." (emphasis mine)
>
> 7.4.2 Focus management
> "3. Fire a **simple event** named focus at the element." (emphasis mine)
> "3. Fire a **simple event** named blur at the element." (emphasis mine)
>
> 3.1.3 Resource metadata management
> "Each document has a current document readiness. When a Document  object  
> is created, it must have its current document readiness set to the  
> string "loading" if the document is associated with an HTML parser or an  
> XML parser, or to the string "complete" otherwise. Various algorithms  
> during page loading affect this value. When the value is set, the user  
> agent must fire a **simple event** named readystatechange  at the  
> Document  object." (emphasis mine)
>
> The definition of a "simple event:"
>
> 6.1.6.3 Event firing
> "Firing a simple event named e means that an event with the name e,  
> which **does not bubble** (except where otherwise stated) and is not  
> cancelable (except where otherwise stated), and which uses the Event   
> interface, must be dispatched at the given target." (emphasis mine)
>
> Media events should bubble?
>
> All media events are "simple events" (e.g., 'canplay' as quoted above)  
> with no additional clarification indicating that they should bubble.  
> Event handler attributes are defined for them on the Window interface,  
> the HTMLDocument interface, and the HTMLElement interface. Because the  
> HTMLVideoElement is derived from HTMLElement, it kinda makes sense to  
> define the event handler attributes there. However, defining these  
> events on HTMLDocument and Window does not seem to make much sense  
> because these events do not bubble. Furthermore, event handlers assigned  
> to the event handler attributes on the HTMLDocument instance or Window  
> instance will never be triggered by the UA because UAs assume (for  
> compat) that event handlers assigned in this manner are registering for  
> the bubbling phase only. Indeed, HTML5 itself defines this behavior:
>
> 6.1.6.1 Event handlers
> "All event handlers on an object, whether an element or some other  
> object, and whether set to null or to a Function  object, must be  
> registered as event listeners on the object when it is created, as if  
> the addEventListener()  method on the object's EventTarget  interface  
> had been invoked, with the event type (type  argument) equal to the type  
> corresponding to the event handler (the event handler event type), the  
> listener set to be a target and bubbling phase listener (useCapture   
> argument set to false), and the event listener itself (listener   
> argument) set to do nothing while the event handler's value is not a  
> Function  object, and set to invoke the call()  callback of the  
> Function  object associated with the event handler otherwise."
>
> Given the extensive care by which these event handler attributes have  
> been specified throughout the Window, HTMLDocument, and HTMLElement  
> interfaces in the spec, we think it makes sense for these "media" events  
> to bubble.

I think we should look at use cases for bubbling events for media elements  
to decide whether they should bubble instead of looking at the care by  
which event handler attributes have been specified.

One media event that springs to my mind is the 'error' event. It's fired  
either at the <video> or at the failing <source>s. 'error' is also fired  
on failing <img>. It does not bubble for <img>. window.onerror is invoked  
for script errors. If we made 'error' bubble for media elements, then  
window.onerror would be invoked for each failing <source> element. Thus, I  
think the 'error' event should not bubble.

Another event is 'progress'. Media elements originally used Progress  
Events, but this was changed to simple events since Progress Events was  
not a good fit for the media elements. However, we might introduce  
different elements in the future for which we want to fire 'progress'  
events (whether Progress Events or simple events), which might well be  
able to contain media elements. If we make 'progress' bubble for media  
elements, such a scenario would have to filter out the events from the  
descendant media elements, which could be surprising especially since the  
Progress Events 'progress' doesn't bubble. Thus, I think the 'progress'  
event should not bubble.


> Please let us know if there is some other rationale that we may have  
> missed.
>
> focus/blur and readystatechange DOM attributes?
>
> Similarly to the above argument, the readystatechange event fires at the  
> document and does not bubble, yet a DOM attribute is defined on the  
> Window interface for "onreadystatechange." Also, blur/focus events _may_  
> fire on Window, and do fire on Elements, but because they also don't  
> bubble, their event handler DOM attributes on the HTMLDocument interface  
> seems somewhat odd.
>
> What is the design principle for this?

I think the design principle here is to expose all event handlers on all  
of Window, HTMLDocument and HTMLElement, for consistency and ease of impl.  
The exception is event handlers for <marquee>.


> Aside from the argument of consistency, I see that having these DOM  
> attributes available could be useful for document.dispatchEvent when an  
> event with the name "blur", "focus", or "readystatechange" is created  
> programmatically.

I agree.

Cheers,
-- 
Simon Pieters
Opera Software

Received on Wednesday, 19 May 2010 22:51:28 UTC