Moving Form Events from DOM3 Events to HTML5 (was: Removing Form Events?)

Hi, Ian-

(BCCing public-html, because I love crossposting)

Ian Hickson wrote (on 9/21/09 6:42 AM):
> On Mon, 21 Sep 2009, Doug Schepers wrote:
>>  I'm pondering removing the event types associated with forms: 'change'
>>  [1], 'submit' [2], and 'reset' [3].  They are so specific to HTML that
>>  they are probably best defined there, rather than in a generic DOM Event
>>  specification.
> What does it mean to define an event? (i.e. what would I have to do in
> HTML5 if we moved this there?)

You would need to specify the event type (e.g. 'submit'), which 
interface(s) it uses, what values it populates the attributes of that 
interface with and where they are derived from, whether it bubbles, what 
the event target is, whether or not it is cancelable, what its default 
action is (if that is to be defined in the spec, and is not 
UA-dependent), and what extra context information it has beyond simply 
the event target.

You also need to specify the conditions under which it is dispatched... 
say, user submits a form, or more precisely, user activates a <input> 
element which is of types 'submit' or 'image' on a form.  You might also 
discuss the conditions under which an event does not fire, or when it 
exhibits idiosyncratic behavior (like 'load'), because of legacy quirks. 
  This is why I thought you might like to define it in HTML5, since you 
can go into much more precise HTML-specific detail than I think is 
appropriate for DOM3 Events.  (XForms, the only other spec which I would 
expect to use these, instead defines its own events [1][2][3]... a heck 
of a lot of events, in fact.)

In practice, most of this information is already in DOM3 Events, and you 
would just need to extract it and reformat and reword it to suit HTML5's 
conventions.  HTML5 already define some events, so I don't think it's 
inappropriate to add a few more.

You would not have to define the event dispatch or event flow models, 
nor would you have to define an interface (unless you felt it was 
needed)... you would continue to rely on DOM3 Events for that.

Obviously, the WebApps WG wouldn't drop them from DOM3 Events if you 
don't have the time to add them to HTML5, or if the HTML5 WG decides 
they don't want to bring them in for whatever reason... but I do think 
it would benefit both specs were they to be moved.  DOM3 Events would be 
more generic, and HTML5 could define them in more contextual detail.


-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Monday, 21 September 2009 18:47:38 UTC