Re: URL structure sanity check

In some cases (WebSocket, for example, if I am not mistaken), you cannot
use addEventListener for listening to an event, like ws.onopen. Adding it
as "open" might cause some confusion.
It might be an implementation issue, because I think WebSocket is specified
to subclass EventTarget as well, which means addEventListener should apply
to it, but in Chrome, as far as I remember, it does not work. I have not
tried other browsers.
Anyway, in cases like these (assuming no browser implements
addEventListener for that object), events should begin with the "on"
prefix, I believe (but still have the regular Event template, I guess).

What does everyone think?

Also, does anyone have any information regarding other browsers (or current
Chrome?) in this regard?


☆*PhistucK*



On Thu, Nov 15, 2012 at 11:18 PM, Michael Sierra <msierra@adobe.com> wrote:

> Re the recent conf-call clarifying the apis/ URL space, here are a few
> random APIs generated from some test W3C specs:
>
> https://github.com/mike-sierra/webplatform/blob/master/urls.txt
>
> Of all the comments are marked "#",
>
> * I think of "deviceorientation" as belonging under apis/, but it seems to
> simply modify the window object.  Can/should it be represented here?
>
> * The File API defines a new URL scheme, and I wonder where that gets
> doc'ed
>
> * I noticed one instance of a namespace collision, where an abort() method
> collides with an "abort" event.  In this URL list, I kept it as it appears
> in the spec, "onabort," but current practice in the wiki is to strip the
> "on" prefix, which would cause a problem.
>
> --Mike Sierra
>
>