DOM Events

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

DOM Events

Jean-Yves Bitterlich-2
Hello Editors,

In the context of JSR280 DOM API (JCP), I have here a couple of requests for clarifications for various WebAPI/DOM specifications/drafts. I kindly ask you for your opinion ... 

Charles McCathieNevile wrote:
Hi Jean-Yves,

can you please send them to the [hidden email] list so the editor of the spec sees them (and the rest of the working group)?
* DOM3/Event/EventTarget
Specification: http://www.w3.org/TR/2006/WD-DOM-Level-3-Events-20060413/
Method: EventTarget.dispatchEvent(Event evt)
It is unclear how to notify an application about incorrect event target, when correct event is being dispatched to incorrect eventTarget by EventTarget.dispatchEvent(Event evt).
Declared exceptions in the "Throws" part aren't suitable for this goal.
EventException.DISPATCH_REQUEST_ERR may be used for synchronization of dispatching some correct event to different nodes in different threads.

* DOM3/Event/initMutationEvent
Specification: http://www.w3.org/TR/2006/WD-DOM-Level-3-Events-20060413/events.html
Method: initMutationEvent(NS)(...)
Few parameters have "This value may be null". Parameter "relatedNode" not although it is possible that this arg is null...
The spec should allow relatedNode to be null  :-) 
(Same applies to initMutationEventNS())
What to you think: any chance to have this clarified into the DOM event spec?

* DOM3/Event/DocumentEvent
Specification: http://www.w3.org/TR/2006/WD-DOM-Level-3-Events-20060413/events.html
Method: canDispatch()
The documentation of canDispatch says: "Tests if the implementation can generate events of a specified type."
while the return value description is:
"true if the implementation can generate and dispatch this event type, false otherwise"
Note there is "and dispatch" part of the assertion. If we remove this part, then there will be no reason for confusion with an application events. Now it sounds like the implementation cannot dispatch application specific events.
Do you think you can remove the "and dispatch" part from the assertion ?

I thereby also give permission to forward these requests to w3c.
best regards,

Jean-Yves
--
Jean-Yves Bitterlich
Senior Staff Engineer
Sun Microsystems GmbH
Sonnenallee 1, 85551 Heimstetten, Germany
Mobile: +49-172-8187243
Phone: +49-89-46008-1097 (x61097)
Fax: +49-89-46008-2978 (x62978)
Email: [hidden email]
Amtsgericht München: HRB 161028
Geschäftsführer: Marcel Schneider, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring
WEEE-Reg.-Nr. DE 20803943
HypoVereinsbank München, Konto 31 625 009, BLZ 700 202 70
      
Reply | Threaded
Open this post in threaded view
|

Re: DOM Events

Olli Pettay

Jean-Yves Bitterlich wrote:
> * DOM3/Event/EventTarget
> Specification: http://www.w3.org/TR/2006/WD-DOM-Level-3-Events-20060413/
> Method: EventTarget.dispatchEvent(Event evt)
> It is unclear how to notify an application about incorrect event target, when correct event is being dispatched to incorrect eventTarget by EventTarget.dispatchEvent(Event evt).
> Declared exceptions in the "Throws" part aren't suitable for this goal.
> EventException.DISPATCH_REQUEST_ERR may be used for synchronization of dispatching some correct event to different nodes in different threads.


How can one dispatch an event to "incorrect event target"? Either the
object is an event target (in which case you can dispatch the event) or
it is not event target.

Do you mean that event targets should be able to restrict the types of
events which can be dispatched to them? If yes, what would be the use case?

-Olli

Reply | Threaded
Open this post in threaded view
|

Re: DOM Events

Bjoern Hoehrmann
In reply to this post by Jean-Yves Bitterlich-2

* Jean-Yves Bitterlich wrote:
>Method: EventTarget.dispatchEvent(Event evt)
>It is unclear how to notify an application about incorrect event target,
>when correct event is being dispatched to incorrect eventTarget by
>EventTarget.dispatchEvent(Event evt).

Thank you for your comments. The DOM Event Model does not have a notion
of correct event types for an event target, and there is consequently no
way to inform applications of semantic errors it might have made. It is
in fact difficult to see how such a notion might be defined. For example
the DOMAttrModified event is currently defined only for Element nodes in
the DOM Event Flow, but future specifications might re-use it to inform
applications of changes of pseudo-attributes on processing instructions
like xml-stylesheet. Applications might then use dispatchEvent to simu-
late this in legacy implementations.

>Method: initMutationEvent(NS)(...)
>Few parameters have "This value may be null". Parameter "relatedNode"
>not although it is possible that this arg is null...

Thanks for spotting this error, the next draft will note that this para-
meter may indeed be null, perhaps indirectly, saying that the parameters
to an init method may be null iff the attribute may be null. There may
be similar errors in the draft, please let us know if you find more.

>Method: canDispatch()
>The documentation of canDispatch says: "Tests if the implementation can
>generate events of a specified type." while the return value description
>is: "true if the implementation can generate and dispatch this event type,
>false otherwise" Note there is "and dispatch" part of the assertion. If
>we remove this part, then there will be no reason for confusion with an
>application events. Now it sounds like the implementation cannot dispatch
>application specific events.

I think simply removing the offending phrase is not the best course of
action, at least not until the draft defines what it means if an imple-
mentation is able to generate an event type. I will try to come up with
better text for this.

Thanks again for your comments. Please let us know if you have further
input on the document.
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Reply | Threaded
Open this post in threaded view
|

Re: DOM Events

Jean-Yves Bitterlich-2
Bjoern,
Thanx very much for the prompt reply.
here tackling the EventTarget.dispatchEvent point:
(see inline)

Bjoern Hoehrmann wrote:
* Jean-Yves Bitterlich wrote:
  
Method: EventTarget.dispatchEvent(Event evt)
It is unclear how to notify an application about incorrect event target,
when correct event is being dispatched to incorrect eventTarget by
EventTarget.dispatchEvent(Event evt).
    

Thank you for your comments. The DOM Event Model does not have a notion
of correct event types for an event target, and there is consequently no
way to inform applications of semantic errors it might have made. It is
in fact difficult to see how such a notion might be defined. For example
the DOMAttrModified event is currently defined only for Element nodes in
the DOM Event Flow, but future specifications might re-use it to inform
applications of changes of pseudo-attributes on processing instructions
like xml-stylesheet. Applications might then use dispatchEvent to simu-
late this in legacy implementations.
  
The feedback from our developer:

List of event types is declared in the section  "1.4.2 Complete list of event types" of "Document Object Model (DOM) Level 3 Events Specification" (http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/events.html#Events-EventTypes-complete). Let's examine the DOMActivate UIEvent. According to this section: "Some events will only be dispatched to a specific set of possible targets, specified using node types.". The possible target for DOMActivate event is an Element only (according to the table in this section). I will be using JAVA syntax.

First step, I created an intstance of UIEvent with type DOMActivate by DocumentEvent.createEvent("UIEvent") and UIEvent.initUIEvent(..) with appropriate parameters.

Second step, I tried to dispatch this instance of UIEvent to Comment by ((EventTarget)someComment).dispatchEvent(.....)

Specification doesn't explain, what a DOM implementation SHOULD DO in this case. I mean, that event target is incorrect (not suitable) in this case (see column "Target node types" in the table of "information on the event types" in the section 1.4.2). Also  I can't find any appropriate notifications in specification for applications. Such notifications may be useful for application development.

I can suggest three possible use cases for such situations:

1) Dispatch event to the "incorrect" (not suitable) event target and add appropriate description to specification.
Cases when "event targets able to restrict the types of events which can be dispatched to them"
2) Add new Exception to the section "Exceptions" of EventTarget.dispatchEvent, throw it and add appropriate description to specification.
3) Do nothing and add appropriate description to specification.

I guess that second case is more preferable for application developer.

Best regards,
Dmitry.





  
Method: MutationEvent.initMutationEvent(NS)(...)
Few parameters have "This value may be null". Parameter "relatedNode"
not although it is possible that this arg is null...
    

Thanks for spotting this error, the next draft will note that this para-
meter may indeed be null, perhaps indirectly, saying that the parameters
to an init method may be null iff the attribute may be null. There may
be similar errors in the draft, please let us know if you find more.

  
Method: DocumentEvent.canDispatch()
The documentation of canDispatch says: "Tests if the implementation can
generate events of a specified type." while the return value description
is: "true if the implementation can generate and dispatch this event type,
false otherwise" Note there is "and dispatch" part of the assertion. If
we remove this part, then there will be no reason for confusion with an
application events. Now it sounds like the implementation cannot dispatch
application specific events.
    

I think simply removing the offending phrase is not the best course of
action, at least not until the draft defines what it means if an imple-
mentation is able to generate an event type. I will try to come up with
better text for this.

Thanks again for your comments. Please let us know if you have further
input on the document.
  

--
Jean-Yves Bitterlich
Senior Staff Engineer
Sun Microsystems GmbH
Sonnenallee 1, 85551 Heimstetten, Germany
Mobile: +49-172-8187243
Phone: +49-89-46008-1097 (x61097)
Fax: +49-89-46008-2978 (x62978)
Email: [hidden email]
Amtsgericht München: HRB 161028
Geschäftsführer: Marcel Schneider, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring
WEEE-Reg.-Nr. DE 20803943
HypoVereinsbank München, Konto 31 625 009, BLZ 700 202 70
      
Reply | Threaded
Open this post in threaded view
|

Re: DOM Events

Bjoern Hoehrmann

* Jean-Yves Bitterlich wrote:

>First step, I created an intstance of UIEvent with type DOMActivate by
>DocumentEvent.createEvent("UIEvent") and UIEvent.initUIEvent(..) with
>appropriate parameters.
>
>Second step, I tried to dispatch this instance of UIEvent to Comment by
>((EventTarget)someComment).dispatchEvent(.....)
>
>Specification doesn't explain, what a DOM implementation SHOULD DO in
>this case. I mean, that event target is incorrect (not suitable) in this
>case (see column "Target node types" in the table of "information on the
>event types" in the section 1.4.2). Also  I can't find any appropriate
>notifications in specification for applications. Such notifications may
>be useful for application development.

The purpose of listing the possible event targets in the specification
is to say that an implementation of only DOM Level 3 Events will not
dispatch certain event types to certain event targets unless requested
to by a DOM application. These listings are not meant to otherwise con-
strain implementations, applications, or specifications. What the DOM
implementation (must) do in the case above is dispatch the event object
to the comment node; no checking on the semantic correctness of the re-
quest to dispatch the event object is performed by the implementation.

I can update the specification to just say what I wrote above. Would
that help, or do you have a suggestion how to convey the above more
clearly in the draft?
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Reply | Threaded
Open this post in threaded view
|

Re: DOM Events

Stewart Brodie
In reply to this post by Jean-Yves Bitterlich-2

Jean-Yves Bitterlich <[hidden email]> wrote:

> Bjoern,
> Thanx very much for the prompt reply.
> here tackling the EventTarget.dispatchEvent point:
> (see inline)
>
> Bjoern Hoehrmann wrote:
> > * Jean-Yves Bitterlich wrote:
> >  
> >> Method: EventTarget.dispatchEvent(Event evt)
> >> It is unclear how to notify an application about incorrect event
target,

> >> when correct event is being dispatched to incorrect eventTarget by
> >> EventTarget.dispatchEvent(Event evt).
> >>    
> >
> > Thank you for your comments. The DOM Event Model does not have a notion
> > of correct event types for an event target, and there is consequently no
> > way to inform applications of semantic errors it might have made. It is
> > in fact difficult to see how such a notion might be defined. For example
> > the DOMAttrModified event is currently defined only for Element nodes in
> > the DOM Event Flow, but future specifications might re-use it to inform
> > applications of changes of pseudo-attributes on processing instructions
> > like xml-stylesheet. Applications might then use dispatchEvent to simu-
> > late this in legacy implementations.
> >  
> The feedback from our developer:
>
> List of event types is declared in the section  "1.4.2 Complete list of
> event types" of "Document Object Model (DOM) Level 3 Events
> Specification"
>
(http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/events.html#Events-EventTypes-complete).

> Let's examine the DOMActivate UIEvent. According to this section: "Some
> events will only be dispatched to a specific set of possible targets,
> specified using node types.". The possible target for DOMActivate event
> is an Element only (according to the table in this section). I will be
> using JAVA syntax.
>
> First step, I created an intstance of UIEvent with type DOMActivate by
> DocumentEvent.createEvent("UIEvent") and UIEvent.initUIEvent(..) with
> appropriate parameters.
>
> Second step, I tried to dispatch this instance of UIEvent to Comment by
> ((EventTarget)someComment).dispatchEvent(.....)
>
> Specification doesn't explain, what a DOM implementation SHOULD DO in
> this case.

The DOM implementation MUST carry out the standard DOM event dispatch.
Nothing more, nothing less.  Your example of dispatching events to Comment
is perfectly allowable, as Comment implements EventTarget (via CharacterData
and Node).


Where the DOM Level 3 Events document is lacking, in my opinion, is that it
does not say enough about dispatch of events to objects that implement
EventTarget but do not implement Node.  In my DOM implementation, my
XMLHttpRequest objects implement EventTarget.  Quite how this fits with
capturing, at-target and bubbling phases or default event handlers isn't
100% clear to me - although in this case, I think it is obvious that you
just get an at-target phase. But what about other non-Node objects that are
arranged in a tree hierarchy? Also, *I* think it's obvious, but somebody
else might think that some other behaviour is equally obvious.



> I mean, that event target is incorrect (not suitable) in this
> case (see column "Target node types" in the table of "information on the
> event types" in the section 1.4.2). Also  I can't find any appropriate
> notifications in specification for applications. Such notifications may
> be useful for application development.
>
> I can suggest three possible use cases for such situations:
>
> 1) Dispatch event to the "incorrect" (not suitable) event target and add
> appropriate description to specification.
> Cases when "event targets able to restrict the types of events which can
> be dispatched to them"
> 2) Add new Exception to the section "Exceptions" of
> EventTarget.dispatchEvent, throw it and add appropriate description to
> specification.
> 3) Do nothing and add appropriate description to specification.
>
> I guess that second case is more preferable for application developer.

The second option would be incredibly difficult for DOM implementations - it
would likely introduce browser incompatibilities left, right & centre as
different versions of different browsers had different lists of which events
can be dispatched to which objects.

As far as I am concerned, as an implementor of a DOM framework, it is
imperative that EventTarget.dispatchEvent() always be permitted to dispatch
the specified event, so that listeners registered with addEventListener are
invoked when the event types in the event and the listener match.


> > > Method: DocumentEvent.canDispatch() The documentation of canDispatch
> > > says: "Tests if the implementation can generate events of a specified
> > > type." while the return value description is: "true if the
> > > implementation can generate and dispatch this event type, false
> > > otherwise" Note there is "and dispatch" part of the assertion. If we
> > > remove this part, then there will be no reason for confusion with an
> > > application events. Now it sounds like the implementation cannot
> > > dispatch application specific events.
> >>    
> >
> > I think simply removing the offending phrase is not the best course of
> > action, at least not until the draft defines what it means if an imple-
> > mentation is able to generate an event type. I will try to come up with
> > better text for this.

To be honest, I do not understand fully under what conditions canDispatch()
can return FALSE other than either the namespaceURI or type is invalid
according to the naming rules for those strings.  But if that is all that it
can do, then perhaps it would better to remove it completely and rely on
dispatchEvent raising INVALID_CHARACTER_ERR exceptions as appropriate.


--
Stewart Brodie
Software Engineer
ANT Software Limited

Reply | Threaded
Open this post in threaded view
|

Re: DOM Events

Bjoern Hoehrmann

* Stewart Brodie wrote:
>Where the DOM Level 3 Events document is lacking, in my opinion, is that it
>does not say enough about dispatch of events to objects that implement
>EventTarget but do not implement Node.  In my DOM implementation, my
>XMLHttpRequest objects implement EventTarget.  Quite how this fits with
>capturing, at-target and bubbling phases or default event handlers isn't
>100% clear to me - although in this case, I think it is obvious that you
>just get an at-target phase. But what about other non-Node objects that are
>arranged in a tree hierarchy? Also, *I* think it's obvious, but somebody
>else might think that some other behaviour is equally obvious.

How events flow through a data structure is controlled by the event flow
associated to the event targets making up the structure. DOM Level 3
Events defines one such event flow, the DOM Event Flow. Another event
flow is defined in DOM Level 3 L&S, which is the example given in the
draft. The next draft will define better terminology to help defining
new event flows in a manner compatible with the DOM Event model. I would
expect the XHR specification would say something like, that the propa-
gation path consists of only the xhr object, to define its event flow.

>To be honest, I do not understand fully under what conditions canDispatch()
>can return FALSE other than either the namespaceURI or type is invalid
>according to the naming rules for those strings.  But if that is all that it
>can do, then perhaps it would better to remove it completely and rely on
>dispatchEvent raising INVALID_CHARACTER_ERR exceptions as appropriate.

The purpose of the method is to allow scripts to query whether the DOM
implementation is prepared to automatically generate and dispatch events
of the specified type, for example, whether it will report the download
progress of referenced resources using the 'progress' event as discussed
on this list.
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/