Re: Moving Form Events from DOM3 Events to HTML5

On Tue, 22 Sep 2009, Doug Schepers wrote:
> Ian Hickson wrote (on 9/22/09 5:57 PM):
> > 
> > Right now, the text in DOM Events for when events fire is woefully 
> > inadequate if we're to get full interop.
> 
> You've made that claim before, and in response I've improved the 
> specificity of each event, detailed in many cases (not yet all) what the 
> values for each attribute are for each event type, enumerated the order 
> in which related events fire, and made other improvements.

Let's look at 'load':

# A user agent must dispatch this event when the DOM implementation
# finishes loading the resource (such as the document) and any
# dependent resources (such as images, style sheets, or
# scripts). Dependent resources that fail to load must not prevent
# this event from firing if the resource that loaded them is still
# accessible via the DOM. If this event type is dispatched,
# implementations are required to dispatch this event at least on the
# Document node. This event differs from the DOMContentLoaded event in
# that it is not dispatched until all external resources are loaded.

Here are some questions that I do not believe the above adequately 
answers:

* Which resources does the event fire for? Does it fire on a Document 
fetched using XMLHttpRequest? Does it fire for a favicon declared on a 
<link> element? Does it fire for a plugin loaded purely by type="" with no 
associated resource in <object>?

* What element does the event fire at? Consider a <video> element with two 
<source> elements. When the second <source> element's URL is resolved and 
the video fetched, should the event fire on the <source> or the <video>?

* Should the event fire synchronously or asynchronously?

* Does a dynamically inserted <script> element inserted during the 
DOMContentLoaded event delay the 'load' event, or should the 'load' event 
only be delayed by resources that started loading before the document 
ended parsing?

* If the user switches alternative style sheets while the document is 
loading, does the 'load' event get delayed by the loads of the alternative 
style sheets, only the persistent ones, or only the preferred set?

* On <video> elements, should the 'load' event fire before or after 
networkState is set to NETWORK_LOADED?

* If an <input> element with type=text has a src="" attribute, and the 
type is dynamically switched to "image" and back to "text" before the 
image has loaded, should the 'load' event fire on the <input> element once 
the image has loaded? If this occurs while the document is loading, should 
the document-wide 'load' event wait for the image?

* When the 'load' event is fired at the Document, what nodes are expected 
to receive the event? (It actually has to be the Window object, weirdly.)

* Should 'load' fire before or after the delayed 'popstate'?

* Does 'load' fire before or after the <script> element's script?

* Does 'load' fire before or after img.complete becomes true?

* When an <iframe> contains a document, should the 'load' event be fired 
at the <iframe>, the inner Document/Window, or both? If both, in what 
order?

* What should UIEvent.view be when there are multiple views? (Is 'load' 
really a UIEvent?)


Next let's consider 'error'. The DOM3 Events spec says:

# A user agent must dispatch this event when a resource failed to load, or 
# has been loaded but cannot be interpreted according to its semantics, 
# such as an invalid image, a script execution error, or non-well-formed 
# XML.

Questions:

* What resources exactly? Does this event fire for <img>? <iframe>? 
<object>?

* What exactly is a failure to load or failure to interpret according to 
its semantics? Does an HTML parse error trigger 'error'? A syntax error in 
a scripted eval? A style sheet syntax error? An SVG conformance error? (I 
think all three of those are not errors, in practice.)

* What does the event fire at? For example, for <video><source>, does it 
fire at <video>? <source>? both?

* What should UIEvent.view be when there are multiple views? (Is 'error' 
really a UIEvent?)

* When an <html manifest> fails to load, is the event fired at the <html> 
element?

* Is the event fired asynchronously or synchronously? For example, say 
that you have a script that does:

  <script onerror="alert('A')">
   var x = new Image();
   x.onerror = function () { alert('1') };
   x.src = 'data:,fail';
   throw 'fail';
  </script>

...what order do the events fire in? A then 1, or 1 then A? Or does only 1 
or only A fire? Or neither?

* When you have a script error, does the <body onerror=""> call get 
invoked as an event dispatch or a function call? Is that an 'error' event?


Consider 'resize' or 'scroll':

# A user agent must dispatch this event when a document view or an element 
# has been resized/scrolled. This event type is dispatched after the 
# resize/scroll has occurred.

* Do these events fire synchronously, or are they queued up?

* The text says that they fire at the end of the resize/scroll, but what 
is the end? (In particular, they seem to fire continuously in the UAs I 
tested.)


Consider 'blur':

# A user agent must dispatch this event when an event target loses focus. 
# The focus shall be taken from the element before the dispatch of this 
# event type. This event type is similar to focusout, but is dispatched 
# after focus is shifted, and does not bubble.

* Does the event fire before or after the 'change' event fires when that 
is applicable? (e.g. <input type=text onchange onblur> -- which fires 
first when focus changes?)

* Is it synchronous or asynchronous, if focus was changed programatically?


Consider 'mousedown':

# A user agent must dispatch this event when a pointing device button is 
# pressed over an element.

* How do you know if you are over an element? (In particular, how does 
alpha transparency affect the determination? It is different in IE than 
Firefox, which is right?)

* If you click a text field, and script cancels 'mousedown', does the text 
field get focused? Does 'click' fire? Does 'mouseup' fire?

* If you cancel 'mousedown', can you still get a 'dragstart'?


Personally I think the way to fix these problems is to change to a more 
explicit model whereby algorithms parallel what UAs will do, with the 
events fired from the algorithms, so that there is no ambiguity. For 
example, for mouse events, actually define a single algorithm that handles 
all mouse input, handling everything from managing changing coordinates to 
detecting drag starts to managing the down/click/up/down/click/dblclick/up 
sequencing, etc. Basically, implement the device input driver, in prose.

This is more or less what HTML5 does with everything that fires events.


> > For example, with 'submit', it didn't even say if the event was async 
> > or sync,
> 
> Does this apply to all events?  Please provide a pointer to the relevant 
> definitions and a couple of examples where you have provided adequate 
> detail, and I'll go from there.

An example of an asynchronous event in HTML5 would be the 'load' and 
'popstate' events fired after document load:

   http://www.whatwg.org/specs/web-apps/current-work/#delay-the-load-event

The magic words here are "queue a task", which invokes a whole bunch of 
event loop stuff defined here:

   http://www.whatwg.org/specs/web-apps/current-work/#event-loops

An example of a synchronous event in HTML5 would be the 'popstate' event 
fired during session history traversal:

   http://www.whatwg.org/specs/web-apps/current-work/#activating-state-object-entries

However, note that this is effectively asynchronous if the algorithm 
itself is invoked from a task, as happens e.g. here:

   http://www.whatwg.org/specs/web-apps/current-work/#scroll-to-fragid

(The algorithm there is queued, and in that algorithm's step 3, "Traverse 
the history" is synchronously invoked, and in that algorithm's step 9, 
"Activating state object entries" is synchronously invoked, and in that 
algorithm's step 2, first branch, the event is fired synchronously -- but 
since the whole thing is happening in a queued task, from the original 
script's point of view, it seems asynchronous.)

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 6 October 2009 00:29:26 UTC