An idea for creating events is to support [Constructor] on all event
IDLs, which makes the createEvent method unnecessary.
Maybe we could even make the arguments to the constructor be called to
initFooEvent() directly, so instead of doing
var e = document.createEvent('MouseEvents');
e.initMouseEvent('click', ...);
foo.dispatchEvent(e);
you could do
foo.dispatchEvent(new MouseEvent('click', ...))
I've cc-ed www-dom since this is a suggestion for a change to DOM Events.
I think that allowing creation of events via constructor is a good
idea. It is simple in a way that doesn't detract from usefulness. I
don't think it's a good idea to diverge far from how events are done in
the DOM for non-DOM uses. That means that the DOM specs should lead the
way in terms of providing for how events work for browsers, available
objects like Web Workers, server-side javascript and anything else you
can think of.
The DOM Level 3 Events spec is specifying interface DocumentEvent that
document should implement, corresponding to feature "Events". It would
be nice if the DOM Level 3 DocumentEvent and Event interfaces were
super-classes of something also available for other implementations.
WorkerGlobalScope could implement this non-DOM eventing interface and
whatever constructors make sense to be available for Worker events
(ErrorEvent is the one that is already specified, as well as the
messaging ones). Another example of an object that does eventing but
isn't DOM is the XmlHttpRequest object.
Regards,
J5
I'm the type of person who "thinks out loud" and as such even in an
email conversation I can get long-winded and lengthily end up somewhere
that I later realize is much quicker to arrive at by direct means. I
don't know whether the protocol of this list is that I ramble or that I
be as direct as possible and do thinking "off-list". I suspect that it
leans towards the latter and so I'm putting the rambling part below.
=================================
That uncouples events from the document object and makes it easier to
make them part of specs that are not DOM-related, so it sounds like a
good idea to me. I think you'd still want to support a no-arg
constructor and some form of mutators for initialization.
For use cases where separate initialization is not needed, I think the
syntax you're showing is very understandable and the terseness does not
detract from the usefulness.
For reasons related to use of reflection, it would still be nice to be
able to create an event by passing the name via string.
Could it make sense to have an independent event control object (factory
or singleton make sense to me) that could be used to create events via
reflection rather than explicit constructors? It might be interesting
to be able to look-ahead at upcoming events that are not yet being
processed, or have built in event history. Such an object could be a
window into existing eventing queues, as well as a place to implement a
createEvent method agnostically.
Under the hood the eventing object could be proxying to document or
workerglobalscope or window or whatever object or objects are actually
implementing eventing. In that sense I guess it could be made an
interface that document and workerglobalscope implement and not even be
a first-class object.
I am now thinking a bit in circles here, because I'm back to suggesting
document.createEvent() as just fine :) I hope my comments are useful.
I will try to summarize where I've ended up:
Objects implementing DOM Level 3 Event interface can be created via
constructor, equivalent to .creatEvent(foo), .initFooEvent(bar,baz,...)
EventingInterface specifies createEvent method and maybe some other fun
stuff for looking at eventing queues
Document (and possibly WorkerGlobalScope) to implement EventingInterface
(if people want the convenience of the coupling of Document with event
creation because of all the DOM Events)
Consider Eventing object "eventing" which implements EventingInterface
to be used in place of Document in non-DOM environments
Regards,
J5
