- From: Mark Birbeck <mark.birbeck@webbackplane.com>
- Date: Tue, 22 Sep 2009 15:53:25 +0100
- To: Doug Schepers <schepers@w3.org>
- Cc: "www-dom@w3.org" <www-dom@w3.org>, XForms <public-forms@w3c.org>
Hi Doug, I would vote for keeping these in a general-purpose DOM spec. As you point out, XForms uses its own events, but really it should use the events you mention, and may do in a future version. Also, you can imagine other scenarios, such as voice markup, making use of these event names, independent of HTML. Regards, Mark On Mon, Sep 21, 2009 at 7:47 PM, Doug Schepers <schepers@w3.org> wrote: > Hi, Ian- > > (BCCing public-html, because I love crossposting) > > 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?) > > You would need to specify the event type (e.g. 'submit'), which interface(s) > it uses, what values it populates the attributes of that interface with and > where they are derived from, whether it bubbles, what the event target is, > whether or not it is cancelable, what its default action is (if that is to > be defined in the spec, and is not UA-dependent), and what extra context > information it has beyond simply the event target. > > You also need to specify the conditions under which it is dispatched... say, > user submits a form, or more precisely, user activates a <input> element > which is of types 'submit' or 'image' on a form. You might also discuss the > conditions under which an event does not fire, or when it exhibits > idiosyncratic behavior (like 'load'), because of legacy quirks. This is why > I thought you might like to define it in HTML5, since you can go into much > more precise HTML-specific detail than I think is appropriate for DOM3 > Events. (XForms, the only other spec which I would expect to use these, > instead defines its own events [1][2][3]... a heck of a lot of events, in > fact.) > > In practice, most of this information is already in DOM3 Events, and you > would just need to extract it and reformat and reword it to suit HTML5's > conventions. HTML5 already define some events, so I don't think it's > inappropriate to add a few more. > > You would not have to define the event dispatch or event flow models, nor > would you have to define an interface (unless you felt it was needed)... you > would continue to rely on DOM3 Events for that. > > Obviously, the WebApps WG wouldn't drop them from DOM3 Events if you don't > have the time to add them to HTML5, or if the HTML5 WG decides they don't > want to bring them in for whatever reason... but I do think it would benefit > both specs were they to be moved. DOM3 Events would be more generic, and > HTML5 could define them in more contextual detail. > > > [1] http://www.w3.org/TR/2009/PR-xforms11-20090818/#submit-evt-submit > [2] http://www.w3.org/TR/2009/PR-xforms11-20090818/#evt-reset > [3] http://www.w3.org/TR/2009/PR-xforms11-20090818/#evt-valueChanged > > Regards- > -Doug Schepers > W3C Team Contact, SVG and WebApps WGs > >
Received on Tuesday, 22 September 2009 14:54:15 UTC