ISSUE-42 (simpler custom events): Should we simplify custom events? [DOM3 Events]

ISSUE-42 (simpler custom events): Should we simplify custom events? [DOM3 Events]

http://www.w3.org/2008/webapps/track/issues/42

Raised by: Doug Schepers
On product: DOM3 Events

>From Cameron McCormack in http://lists.w3.org/Archives/Public/www-svg/2005Oct/0005.html:

I'd like to make another suggestion about DOM 3 custom events; this time
a great simplification.

Currently any custom event object that is to be dispatched to listeners
must implement the CustomEvent interface, and hence also the Event
interface.  For ECMAScript, this means writing 10 methods for that
object--plus one more to get event dispatching working properly[1] and
another to make it work under sXBL[2].  For Java it's even worse, since
getter methods must be provided for the attributes, bringing the number
of methods to 20.  Though a Java implementation could provide an
abstract custom event class to extend to ease that burden, this isn't
possible for ECMAScript if it's to be non-UA-specific.

The main reason for custom events is to associate extra attributes with
the event object specific to the event.  As such, I think it's likely
overkill to allow user objects to be dispatched by the events
implementation.  Instead, we could have a custom event object created
by the implementation, if this object has an attribute of type DOMObject
that holds all of the custom event object information.

  interface CustomEvent : Event {
    readonly attribute DOMObject details;

    void initCustomEventNS(in DOMString namespaceURIArg,
                           in DOMString typeArg, 
                           in boolean canBubbleArg,
                           in boolean cancelableArg,
                           in DOMObject detailsArg);
  };

These custom event objects could be then created with a call to
DocumentEvent.createEvent("CustomEvent").  For example in ECMAScript:

  var currentTime = ...;
  var evt = document.createEvent("CustomEvent");
  evt.initCustomEventNS("http://example.org/timer",
                        "tick",
                        true, false, { time: currentTime });
  document.documentElement.dispatchEvent(evt);

If specifying whether custom events should be retargetted or stopped at
shadow scope boundaries under sXBL is a desirable feature (and I think
it is), then a separate interface to set this information is probably
the way to go.

  interface EventXBL {
    attribute boolean retargetable;
  };

All event objects created by an sXBL capable events implementation would
implement this interface.  The retargetable attribute would be set to
the appropriate value when methods such as UIEvent.initUIEventNS,
MutationEvent.initMutationEventNS, etc. are called.  For events without
an intrinsic retargetability (such as those initialised with
Event.initEventNS or CustomEvent.initCustomEventNS), it would default to
a particular value (not sure what would be the more appropriate default
here).

If a CustomEvent were retargetted, its details attribute would be copied
to the clone.

I think this is much simpler than what is currently specified, as
demonstrated by this[3] ECMAScript example.

Please let me know your thoughts on this suggestion.

Thanks,

Cameron

[1] http://lists.w3.org/Archives/Public/www-svg/2005Apr/0208.html
[2] http://lists.w3.org/Archives/Public/www-svg/2005Sep/0072.html
[3] http://wiki.apache.org/xmlgraphics-batik/CustomJavaScriptEvents

Received on Wednesday, 23 July 2008 18:46:40 UTC