W3C home > Mailing lists > Public > public-secondscreen@w3.org > April 2015

Re: onavailablechange event target

From: Anton Vayvod <avayvod@google.com>
Date: Thu, 2 Apr 2015 16:17:36 +0100
Message-ID: <CAOjek6qLRwSBMcMLnRqdObXWvBJQ28NO2mMdSrDKDcwhn74vjg@mail.gmail.com>
To: Oleg Beletski <o.beletski@samsung.com>
Cc: "public-secondscreen@w3.org" <public-secondscreen@w3.org>
Hi Oleg,

adding any new names to the window object is discouraged as it pollutes the
global namespace and can break the existing web sites (see our recent
discussion here: [1]).
Hanging an event handler off an object linked to navigator should be fine
and is used for example in navigator.connection.onchange: [2].

Hope this helps,
Anton.

[1] https://github.com/w3c/presentation-api/issues/26#issuecomment-82839960
[2] https://w3c.github.io/netinfo/

On Wed, Mar 25, 2015 at 11:36 AM, Oleg Beletski <o.beletski@samsung.com>
wrote:

>  Hi,
>
>
>
> In Presentation API specification the NavigatorPresentation interface is
> an EventTarget and is an attribute of the Navigator.
>
>
>
> We have noticed that other APIs that provide some data about global state
> of the Navigator do not use it as an event target because of some reasons.
> Examples are online/offline events and Gamepad API. There is the
> navigator.onLine property but events (online, offline) are both dispatched
> on the Window object. Gamepad API designed in a similar way. Gamepad
> interface has a attribute "connected" but then events (gamepadconnected,
> gamepaddisconnected) are fired against the window.
>
>
>
> What could be the reason why existing APIs do not use Navigator properties
> an EventTarget and what the correct way to do that?
>
>
>
> Then we also noticed some typos in the working draft in section 7.4 and 8.
> that mention that events is fired against the PresentationSession (should
> be the NavigatorPresentation with current design).
>
>
>
>
>
> Best regards,
>
> --
>
> Oleg Beletski
>
> Principal Engineer
>
> Samsung Electronics R&D, Finland, Espoo
>
> o.beletski@samsung.com
>
Received on Thursday, 2 April 2015 15:18:27 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 2 April 2015 15:18:28 UTC