[whatwg] createEvent() in Web Workers?

[Jonathan Cook]

> 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