W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2013

Re: Fwd: [IndexedDB] Event handlers

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 01 Feb 2013 12:17:16 +1100
Message-ID: <510B179C.3090106@mcc.id.au>
To: David Bruant <bruant.d@gmail.com>
CC: Anne van Kesteren <annevk@annevk.nl>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Ms2ger <ms2ger@gmail.com>
On 31/01/13 11:01 PM, David Bruant wrote:
> Interesting. In a different world, I would consider the very existence
> of EventTarget/EventHandler to be a layering violation, but given the
> world as it is (no ECMAScript-level events, EventTarget having its own
> prototype object that has to be explicitely inherited from), maybe
> you're right. Your comment only applies to events having a corresponding
> on* property though.
> If event notations are added, a tool can check if the interface inherits
> from EventTarget.
> Maybe doing such a work and tool would reveal that some specs define
> events without their interface inheriting from EventTarget ;-)

If the event-specific annotations can be made as extended attributes, 
and defined in the DOM or DOM Events specs themselves — like how WebGL 
defines a [WebGLHandlesContextLoss] extended attribute — then I'd be 
fine with that.

>> The main problem at the moment with on/event/ is that you cannot
>> actually tell from that whether such events will be dispatched on that
>> object and no others. (E.g. DOMContentLoaded is dispatched on objects,
>> but has no corresponding on/event/ attribute, events for media
>> elements have on/event/ attributes on HTMLElement rather than just
>> <video> and <audio>, etc.) Although I suppose that is only true for
>> HTMLElement/Document/Window and not true for other classes, such as
>> XMLHttpRequest.
>> I don't think we've settled on a strategy here yet.
>> Maybe IDL is not the right place, but giving a listing of events
>> dispatched next to the IDL might be nice for developers trying to
>> figure out what the object can do.
> May I ask why IDL wouldn't be the right place?
> And what would be a list next-to-IDL-but-notIDL?

Although you could consider the set of events that the browser will 
dispatch to a given DOM object to be part of the overall API interface, 
it's not really part of the interface in the IDL sense -- it has no 
effect on how the object is exposed to JS.  Really, it sounds like you 
just need something that lists these events somewhere easily visible in 
specs.  In the HTML spec, there are various other non-IDL things that 
are mentioned in the green element summary boxes:


There's "Categories", "Contexts in which this element can be used", 
"Content model", etc.  I think that is a natural place to have "Events 
that might naturally be dispatched to this element", although of course 
you would need to allow other specifications to add to the list.
Received on Friday, 1 February 2013 01:17:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:08 UTC