Re: Moving Form Events from DOM3 Events to HTML5

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