- From: Doug Schepers <schepers@w3.org>
- Date: Mon, 21 Sep 2009 23:17:41 -0400
- To: "www-dom@w3.org" <www-dom@w3.org>
Hi, Folks- Given no objections, at least one voice of support, and Ian's willingness to define these in HTML5, I've tentatively marked the 'change', 'submit', and 'reset' event types as At Risk, and if I don't hear any objections in the next couple of weeks, I'm likely to remove them. Speak now or forever hold your peace (until Last Call do us part, that is). Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Doug Schepers wrote (on 9/21/09 7:01 PM): > 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?) > > > Regards- > -Doug Schepers > W3C Team Contact, SVG and WebApps WGs > >
Received on Tuesday, 22 September 2009 03:17:57 UTC