Re: Moving Form Events from DOM3 Events to HTML5

Hi, Ian-

Ian Hickson wrote (on 9/21/09 6:10 PM):
> On Mon, 21 Sep 2009, Doug Schepers wrote:
>>  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?)
(blah blah blah)
> In that case HTML5 already defines 'submit', 'DOMActivate',

But not 'DOMFocusIn' or 'DOMFocusOut'... the intention to retain 
'DOMActivate' in HTML5 indicates to me that it should also stay in DOM3 
Events, which has been the topic of some discussion.

> 'load',
> 'DOMContentLoaded', 'error', 'change', 'input', 'unload', 'focus' (just
> for elements, not windows), and 'blur' (again just for elements, not
> windows), as well as many other events that DOM3 Events doesn't currently
> mention.

In general, I think these overlapping events should be normatively 
defined in one spec (DOM3 Events) so that there is less risk of them 
diverging and contradicting each other, and that HTML5 should simply 
state how those events might apply in the case of HTML specifically.

But I recognize that there's a lot of legacy there with HTML, so I'm not 
sure what the best resolution would be in this case.  I would like to 
see some mention in the HTML5 spec of DOM3 Events defining those events, 
in any case.

> It doesn't currently define 'reset' or 'abort'. I'd be happy to define
> those in HTML5; their absence is an oversight.

That would be great, thanks.

(Why did anyone ever think that defining a 'reset' button, or worse yet, 
actually using it on a form, was a good idea?)

-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Monday, 21 September 2009 23:01:22 UTC