RE: "DOM4 Events" Proposal (was: Spec proposals for Event constructors)

> -----Original Message-----
> From: Anne van Kesteren [mailto:annevk@opera.com]
> Sent: Tuesday, October 18, 2011 8:44 PM
> To: www-dom@w3.org; schepers@w3.org; Kentaro Hara; Jacob Rossi
> Cc: Dominic Cooney; Adrian Bateman
> Subject: Re: "DOM4 Events" Proposal (was: Spec proposals for Event
> constructors)
> 
> On Fri, 14 Oct 2011 05:22:43 +0900, Jacob Rossi <Jacob.Rossi@microsoft.com>
> wrote:
> > Thanks for helping get the ball rolling on this! I think event
> > constructors are a great idea. DOM4 has pioneered this for the Event
> > interface [1]. However, we should do this across all event interfaces.
> > So we need a spec for the remaining ones. I think this, potentially
> > along with other ideas we've had in the past [2, 3], will make up a
> > great new spec to extend DOM L3 Events.
> >
> > I've taken your suggestions and drafted them up as a part of a ""DOM4
> > Events" proposal:
> >
> > http://html5labs.com/dom4events/

> >
> > I'd like to solicit feedback on what I've written so far, other
> > possible features to include in scope for this proposal, and what
> > folks think about bringing this in as a new specification in Web Apps.
> > I'll start some threads with a couple questions I had while writing this
> proposal.
> 
> I do not think we should call this "DOM4 Events". That's very confusing with the
> Events chapter DOM4 has. We should name this "UI Events" or some such,
> similar to "Progress Events".

I actually called it "DOM4 Events" thinking it might fit nicely next to DOM4 and DOM3 Events. My proposal also references both D3E and DOM4 for the basic event model and constructors. But I suppose that could be confusing. I'm open to suggestions for other names. "UI Events" isn't appropriate as this covers more interfaces than just UIEvent.

> 
> The whole section on Feature Detection is out of place as DOM4 explicitly says
> that specifications must not have them.
> 
Do you have a new proposal for feature detection?  DOM Features is supported in multiple implementations. If it's unreliable, well then that's a bug in the implementation.  But I'm open to better ideas for feature detection because I acknowledge hasFeature() is far from perfect. However, removing it without replacing it seems wrong. This is probably a topic for DOM4, though, and not this spec. If DOM4 were to specify a new feature detection mechanism that's better, then I'd support having "DOM4 Events" use that solely. Web developers need feature detection, and right now DOM Features is the only mechanism we have for events.

Another feature I've been considering to add to DOM4 Events is the ability to inspect the list of registered event listeners on a node.  We could make that inspection mechanism differentiate between listeners registered for events supported by the implementation versus for custom events that the implementation itself won't fire.  That would let you test for support by registering a listener and then inspecting the success of the registration.

Or perhaps we could make addEventListener have a return value that indicates native support for the event type?

Received on Thursday, 20 October 2011 17:06:50 UTC