Re: Fwd: [IndexedDB] Event handlers

Le 24/01/2013 09:26, Anne van Kesteren a écrit :
> On Thu, Jan 24, 2013 at 8:55 AM, Cameron McCormack <cam@mcc.id.au> wrote:
>> It seems a bit like a layering violation for Web IDL to describe events.
>> The "EventHandler" name is already pretty suggestive about the purpose of
>> the attribute, IMO. :)
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 ;-)

> 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?
 From a developer perspective, events aren't very discoverable as things 
are. I don't know if most developers are aware that the image element 
has an error event or things like that. At events like 
TestTheWebForward, having events in IDL would encourage people to test 
for events.
 From a documentation writer perspective, if events aren't part of 
WebIDL, it really isn't easy to find and document them.
I'll take page visibility [1] as example. From a developer perpective, 
the most important addition of this spec is the visibilitychange event, 
but it's not part of the IDL. Arguably, if the state was passed in the 
event data, it wouldn't be necessary to store the state (both hidden and 
visibilityState) as document properties; at least, that's the case for 
the use case in the introduction. But I understand the potential 
frustration and fear that can come with defining an empty partial 
interface :-)

As a developer and documentation writer, I eye-scan specs to understand 
them and IDL is obviously something I look for a long time to try to 
understand the overall consistency and the feature.

I care much less about layering violation (which abuses can be 
discovered with a fully automated tool anyway) of having events in IDL 
than the benefits that can come out of it (discoverability, better 
"testability" to some extent, unnecessary addition of attributes...)

David

[1] 
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PageVisibility/Overview.html

Received on Thursday, 31 January 2013 12:02:15 UTC