- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 22 Sep 2009 15:01:38 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: Anne van Kesteren <annevk@opera.com>, Doug Schepers <schepers@w3.org>, "www-dom@w3.org" <www-dom@w3.org>, XForms <public-forms@w3c.org>
On Tue, Sep 22, 2009 at 2:57 PM, Ian Hickson <ian@hixie.ch> wrote: > 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. Though, in all fairness, there's lots of things in specs that you produce that really belong in separate specs. ;-) / Jonas
Received on Tuesday, 22 September 2009 22:02:32 UTC