Re: Fwd: [IndexedDB] Event handlers

Le 01/02/2013 02:17, Cameron McCormack a écrit :
>>> 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
I keep reading this sentence and I'm not sure I understand. I would 
expect the "I" in IDL and API to refer to the same thing, that is, a 
description of how a script can interact with an object. An IDL fragment 
should be a D-escription of the overall AP-I. That's what I imagined at 
least. Maybe I was wrong.

> it has no effect on how the object is exposed to JS.
That's only anecdotal in my opinion, because JS doesn't have native 
events. If JS (or another language implementing IDL) had native events 
(JS probably will, IIRC Alex Russel mentioned something about that), 
then would you put it in IDL?

> 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:
>
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#the-p-element 
>
>
> There's "Categories", "Contexts in which this element can be used", 
> "Content model", etc.
These are specific to HTML. And nothing forbids you in JS to append an 
<h1> to a <p>.

Events are almost everywhere in the platform: user interaction, DOM 
mutations, storage events, page visibility, progress events...
Interestingly enough, in some cases, people naturally assume events can 
be put on any object [1]. It's only because of scars of the past (see 2 
comments below) that it's not the case it seems.
Also interesting, Node.js in its documentation [2] gives as much 
importance to methods than to events in interface description. That's 
not ECMAScript, that's not web browsers, but I see a trend.

> 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.
If events were parts of WebIDL, the extension mechanism is already 
there: Partial interfaces

David

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=714358#c58
[2] http://nodejs.org/docs/v0.9.8/api/stream.html

Received on Friday, 1 February 2013 11:04:36 UTC