W3C home > Mailing lists > Public > public-forms@w3.org > September 2009

Re: Moving Form Events from DOM3 Events to HTML5 (was: Removing Form Events?)

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Tue, 22 Sep 2009 15:53:25 +0100
Message-ID: <640dd5060909220753m416bc2a4hfb4948c926ea9f40@mail.gmail.com>
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:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:52 UTC