W3C home > Mailing lists > Public > public-webplatform@w3.org > November 2012

Re: URL structure sanity check

From: PhistucK <phistuck@gmail.com>
Date: Fri, 16 Nov 2012 00:33:27 +0200
Message-ID: <CABc02_LtmZQqLx-ki0-=scnsDO2rsQfn5psu4O8ZyNReEr+k_A@mail.gmail.com>
To: Michael Sierra <msierra@adobe.com>
Cc: public-webplatform@w3.org
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?


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
Received on Thursday, 15 November 2012 22:34:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:13:33 UTC