- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 5 Oct 2009 23:56:09 +0000 (UTC)
- To: Doug Schepers <schepers@w3.org>
- Cc: "www-dom@w3.org" <www-dom@w3.org>
On Mon, 21 Sep 2009, Doug Schepers wrote: > > > > In that case HTML5 already defines 'submit', 'DOMActivate', > > But not 'DOMFocusIn' or 'DOMFocusOut'... Do UAs support those events? What is there purpose? I don't mind adding support for them if there's a need. > > '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. I don't think it's possible for a spec other than HTML5 to define events that form part of HTML5 processing models in enough detail to be interoperably implementable and testable. Consider, for example, DOMContentLoaded. It fires at a very precise point after the parser finishing and certain script categories executing. How would DOM3 Events define that? Similarly, 'unload' fires at step 6 of a 10-step algorithm that itself is invoked as step 5 of a 17-step algorithm for document.open() and as step 1 of a 6-step subalgorithm of session history traversal, which is invoked for a variety of reasons. Not only that, but the event had side-effects on garbage collection, on the back-forward cache, and on session history in a way that is very unusual for events (based not on the event being canceled but merely on whether any listeners were run at all). The text in DOM3 Events is woefully inadequate to define 'unload' in enough detail to make the definition useful. In fact, it's flat out wrong -- the event can fire even in cases where the document doesn't get removed from the environment. The same kind level of detail would be needed for all events. > 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. I don't think DOM3 Events can define these events in enough detail to be worth it defining them at all. > > 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. This is now done. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 5 October 2009 23:46:54 UTC