- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 22 Sep 2009 21:57:27 +0000 (UTC)
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Doug Schepers <schepers@w3.org>, "www-dom@w3.org" <www-dom@w3.org>, XForms <public-forms@w3c.org>
On Tue, 22 Sep 2009, Anne van Kesteren wrote: > > FWIW, what HTML5 does (which I think is fine) does not really amount to > defining the event. It just says at certain places in the algorithms of > the specification to dispatch an event called x. (With the appropriate > details being defined in each case.) If other specifications use an > event with the same name they would not need to refer to HTML5. > > E.g. HTML5 has a readystatechange event that is dispatched on the > Document object. It does not need to refer to XMLHttpRequest for that or > vice versa. They are separate events that just happen to have the same > name and all the same properties. Yeah. I really don't see any point in DOM Events actually defining any events, to be honest, except if it also includes the strict requirements for when they fire -- but even that, I'd prefer in a separate spec or chapter, e.g. a User Interaction Events spec or chapter that defines in painful detail when mouse events fire. Right now, the text in DOM Events for when events fire is woefully inadequate if we're to get full interop. For example, with 'submit', it didn't even say if the event was async or sync, let alone exactly where it fit into the submission model. Same with all the others. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 22 September 2009 21:52:43 UTC