|
Removing Form Events?
|
|
Re: Removing Form Events?
Finally!
Would not it make sense to also move drag-and-drop module events into DOM-Events then? To me this module (when polished) looks meeting many platform/technology independent use cases.
Sergey/
--- On Mon, 21/9/09, Doug Schepers < schepers@...> wrote:
|
|
Re: Removing Form Events?
Hi, Sergey-
Sergey Ilinsky wrote (on 9/21/09 5:33 AM):
>
> Finally!
No, not finally yet. This is still pending a decision of the WebApps WG.
> Would not it make sense to also move drag-and-drop module events into
> DOM-Events then? To me this module (when polished) looks meeting many
> platform/technology independent use cases.
I agree that drag-and-drop events would be better separated from HTML5
(indeed, I worked on a draft of it 2-3 years back [1]), but I don't want
to bring it into DOM3 Events, as I think it would only slow down the
specification's progress.
FWIW, I'm not yet convinced the current model for copy/paste/drag/drop
is the best we could do, and I think it needs a lot of work in any
circumstance.
[1] Clipboard Operations for the Web 1.0: Copy, Paste, Drag and Drop
Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
|
|
Re: Removing Form Events?
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?)
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
|
|
Moving Form Events from DOM3 Events to HTML5 (was: Removing Form Events?)
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-valueChangedRegards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
|
|
Re: Moving Form Events from DOM3 Events to HTML5 (was: Removing Form Events?)
On Mon, 21 Sep 2009, Doug Schepers wrote:
> 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.
In that case HTML5 already defines 'submit', 'DOMActivate', '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.
It doesn't currently define 'reset' or 'abort'. I'd be happy to define
those in HTML5; their absence is an oversight.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
|
|
Re: Moving Form Events from DOM3 Events to HTML5
Hi, Ian-
Ian Hickson wrote (on 9/21/09 6:10 PM):
> On Mon, 21 Sep 2009, Doug Schepers wrote:
>> 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?)
>>
(blah blah blah)
>
> In that case HTML5 already defines 'submit', 'DOMActivate',
But not 'DOMFocusIn' or 'DOMFocusOut'... the intention to retain
'DOMActivate' in HTML5 indicates to me that it should also stay in DOM3
Events, which has been the topic of some discussion.
> '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.
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.
> 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.
(Why did anyone ever think that defining a 'reset' button, or worse yet,
actually using it on a form, was a good idea?)
Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
|
|
Re: Moving Form Events from DOM3 Events to HTML5
Hi, Folks-
Given no objections, at least one voice of support, and Ian's
willingness to define these in HTML5, I've tentatively marked the
'change', 'submit', and 'reset' event types as At Risk, and if I don't
hear any objections in the next couple of weeks, I'm likely to remove them.
Speak now or forever hold your peace (until Last Call do us part, that is).
Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Doug Schepers wrote (on 9/21/09 7:01 PM):
> Hi, Ian-
>
> Ian Hickson wrote (on 9/21/09 6:10 PM):
>> On Mon, 21 Sep 2009, Doug Schepers wrote:
>>> 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?)
>>>
> (blah blah blah)
>>
>> In that case HTML5 already defines 'submit', 'DOMActivate',
>
> But not 'DOMFocusIn' or 'DOMFocusOut'... the intention to retain
> 'DOMActivate' in HTML5 indicates to me that it should also stay in DOM3
> Events, which has been the topic of some discussion.
>
>
>> '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.
>
> 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.
>
>
>> 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.
>
> (Why did anyone ever think that defining a 'reset' button, or worse yet,
> actually using it on a form, was a good idea?)
>
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
>
>
|
|
Re: Moving Form Events from DOM3 Events to HTML5 (was: Removing Form Events?)
On Mon, 21 Sep 2009 20:47:27 +0200, Doug Schepers < schepers@...> wrote:
> 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?)
>
> [...]
FWIW, change and submit seem to be defined in sufficient detail already. I
cannot find where reset is dispatched however.
--
Anne van Kesteren
http://annevankesteren.nl/
|
|
Re: Moving Form Events from DOM3 Events to HTML5
|
|
RE: Moving Form Events from DOM3 Events to HTML5
> From: www-dom-request@... [mailto: www-dom-request@...] On Behalf Of Doug Schepers
> Given no objections, at least one voice of support, and Ian's willingness to
> define these in HTML5, I've tentatively marked the 'change', 'submit', and
> 'reset' event types as At Risk, and if I don't hear any objections in the next
> couple of weeks, I'm likely to remove them.
Please leave a note as to *where* these events have gone after they are removed--just so it doesn't look like we forgot about them...
|
|
Re: Moving Form Events from DOM3 Events to HTML5 (was: Removing Form Events?)
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@...> 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
>
>
|
|
Re: Moving Form Events from DOM3 Events to HTML5
Hi, Mark-
Thanks for your feedback. I'm glad to see the XForms folks
participating more actively.
Mark Birbeck wrote (on 9/22/09 10:53 AM):
>
> I would vote for keeping these in a general-purpose DOM spec.
But they aren't general-purpose... for example, they are meaningless in
SVG.
HTML has very specific meanings and behaviors for them, so it has to
redefine them anyway.
It's better to have them defined in one place than in two, and the
logical place to define them is where they are always applicable.
> 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.
In that case, it could refer to HTML5 for the definitions, or create a
small dedicated spec for form-related events which extends DOM3 Events.
It should also contain an FormEvent interface the inherits from
UIEvent, and the set of forms-centric event types.
> Also, you can imagine other scenarios, such as voice markup, making
> use of these event names, independent of HTML.
Conceivable, but VoiceXML [1], for one, doesn't even use DOM3 Events,
much less those events. If it needs those events in the future, it
would probably be better to have a dialog about which events all
forms-related technologies should share... I don't think those three
would be the right choice, or the only event types.
[1] http://www.w3.org/TR/voicexml21/Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
|
|
Re: Moving Form Events from DOM3 Events to HTML5
Hi Doug,
On Tue, Sep 22, 2009 at 4:34 PM, Doug Schepers < schepers@...> wrote:
> Hi, Mark-
>
> Thanks for your feedback. I'm glad to see the XForms folks participating
> more actively.
Mmm...not sure what that has to do with anything...I'm glad to see the
sun is shining here in London. ;)
> Mark Birbeck wrote (on 9/22/09 10:53 AM):
>>
>> I would vote for keeping these in a general-purpose DOM spec.
>
> But they aren't general-purpose... for example, they are meaningless in SVG.
I don't think that's a very good definition of general-purpose. :)
They could be general-purpose in any forms-related technology.
> HTML has very specific meanings and behaviors for them, so it has to
> redefine them anyway.
That might tell us more about their original definition, then.
> It's better to have them defined in one place than in two, and the logical
> place to define them is where they are always applicable.
Not really. If they are defined in an HTML spec, then it implies that
they are not usable elsewhere. Putting them in a more 'general' spec
would encourage more reuse.
>> 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.
>
> In that case, it could refer to HTML5 for the definitions, or create a small
> dedicated spec for form-related events which extends DOM3 Events. It should
> also contain an FormEvent interface the inherits from UIEvent, and the set
> of forms-centric event types.
But wouldn't there then be the possibility of contradiction with the
HTML5 events?
As you just said, better to define things in one place, rather than two.
>> Also, you can imagine other scenarios, such as voice markup, making
>> use of these event names, independent of HTML.
>
> Conceivable, but VoiceXML [1], for one, doesn't even use DOM3 Events, much
> less those events. If it needs those events in the future, it would
> probably be better to have a dialog about which events all forms-related
> technologies should share... I don't think those three would be the right
> choice, or the only event types.
Certainly, but once they go inside HTML5 it's difficult to get them out again.
Regards,
Mark
--
Mark Birbeck, webBackplane
mark.birbeck@...
http://webBackplane.com/mark-birbeckwebBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)
|
|
Re: Moving Form Events from DOM3 Events to HTML5
On Tue, 22 Sep 2009 17:34:25 +0200, Doug Schepers < schepers@...> wrote:
> Mark Birbeck wrote (on 9/22/09 10:53 AM):
>> 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.
>
> In that case, it could refer to HTML5 for the definitions, or create a
> small dedicated spec for form-related events which extends DOM3 Events.
> It should also contain an FormEvent interface the inherits from
> UIEvent, and the set of forms-centric event types.
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.
--
Anne van Kesteren
http://annevankesteren.nl/
|
|
Re: Moving Form Events from DOM3 Events to HTML5
Hi Doug -- the more relevant reference for VoiceXML is the version 3.0 working draft [1] which does use DOM3 events. Charlie
[1] http://www.w3.org/TR/2009/WD-voicexml30-20090825/#Eventing
Charles Wiecha
Multichannel Web Interaction
IBM T.J. Watson Research Center
P.O. Box 704
Yorktown Heights, N.Y. 10598
Phone: (914) 784-6180, T/L 863-6180, Cell: (914) 320-2614
wiecha@...
 Doug Schepers ---09/22/2009 11:34:43 AM---Hi, Mark- Thanks for your feedback. I'm glad to see the XForms folks
Hi, Mark-
Thanks for your feedback. I'm glad to see the XForms folks
participating more actively.
Mark Birbeck wrote (on 9/22/09 10:53 AM):
>
> I would vote for keeping these in a general-purpose DOM spec.
But they aren't general-purpose... for example, they are meaningless in
SVG.
HTML has very specific meanings and behaviors for them, so it has to
redefine them anyway.
It's better to have them defined in one place than in two, and the
logical place to define them is where they are always applicable.
> 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.
In that case, it could refer to HTML5 for the definitions, or create a
small dedicated spec for form-related events which extends DOM3 Events.
It should also contain an FormEvent interface the inherits from
UIEvent, and the set of forms-centric event types.
> Also, you can imagine other scenarios, such as voice markup, making
> use of these event names, independent of HTML.
Conceivable, but VoiceXML [1], for one, doesn't even use DOM3 Events,
much less those events. If it needs those events in the future, it
would probably be better to have a dialog about which events all
forms-related technologies should share... I don't think those three
would be the right choice, or the only event types.
[1] http://www.w3.org/TR/voicexml21/
Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
|
|
Re: Moving Form Events from DOM3 Events to HTML5
Hi, Charles-
Charles F Wiecha wrote (on 9/22/09 12:33 PM):
> Hi Doug -- the more relevant reference for VoiceXML is the version 3.0
> working draft [1] which does use DOM3 events. Charlie
>
> [1] http://www.w3.org/TR/2009/WD-voicexml30-20090825/#EventingI stand corrected, thanks... that wasn't obvious from the VoiceXML homepage.
I'm actually very encouraged that VoiceXML uses DOM3 Events... my
previous impression from visiting VoiceXML and MMI events was that it
didn't do so.
I see that VoiceXML uses the DOM event flow model (minus capture
phase?), and the Event, EventTarget, EventListener interface from DOM3
Events, but I don't see any explicit use of any of the other interfaces
or event types. I do see it has a <submit> element, but no mention of a
'submit' event. Is that correct?
We are hoping to take DOM3 Events to Last Call in November, and we would
much rather have major issues resolved before then, including comments
from the XForms and VoiceXML folks. So, I would very much appreciate
review and feedback of the Editor's Draft [1].
[1] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.htmlRegards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
|
|
Re: Moving Form Events from DOM3 Events to HTML5
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. `._.-(,_..'--(,_..'`-.;.'
|
|
Re: Moving Form Events from DOM3 Events to HTML5
On Tue, Sep 22, 2009 at 2:57 PM, Ian Hickson < ian@...> 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
|
|
Re: Moving Form Events from DOM3 Events to HTML5
Hi, Ian-
Ian Hickson wrote (on 9/22/09 5:57 PM):
>
> Right now, the text in DOM Events for when events fire is woefully
> inadequate if we're to get full interop.
You've made that claim before, and in response I've improved the
specificity of each event, detailed in many cases (not yet all) what the
values for each attribute are for each event type, enumerated the order
in which related events fire, and made other improvements.
None of the browser vendors or other implementers involved in
contributing to the spec have voiced similar concerns. Obviously, if
they have need for greater detail, I'm happy to provide that.
>For example, with 'submit', it
> didn't even say if the event was async or sync,
Does this apply to all events? Please provide a pointer to the relevant
definitions and a couple of examples where you have provided adequate
detail, and I'll go from there.
> let alone exactly where it fit into the submission model.
Because that's host-language specific... and that's one of the reasons I
suggested the HTML WG take on tho form events, to be defined in HTML5.
I recognize that those event specifically have particular details that
need better definition within HTML.
> Same with all the others.
If you give detailed, actionable review of a few of the elements, I will
be happy to satisfy those comments, and extrapolate for the other
events. I'm afraid you are not going into sufficient detail for me to
make specific changes. It may be that when you look closely at the
spec, you find that more detail is provided than you thought, but if
not, I'm happy to oblige. We all want interoperability, and we have
strong commitment from the browser vendors to implement DOM3 Events, so
I want to get it right.
Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
|
