- From: Francois Daoust <fd@w3.org>
- Date: Tue, 19 Aug 2014 18:51:26 +0200
- To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
- CC: "public-webscreens@w3.org" <public-webscreens@w3.org>
Replying to myself as I had missed one of the suggested API updates... On 2014-08-19 18:42, Francois Daoust wrote: > On 2014-08-13 17:00, Kostiainen, Anssi wrote: >> Hi Francois, All, >> >> On 22 Jul 2014, at 13:25, Francois Daoust <fd@w3.org> wrote: [...] > The spec should clarify when the "present" event gets fired in the > presentation page. No sooner than the tick that follows the "load" > Window event? No sooner than the tick that follows the > "DOMContentLoaded" event? Can implementations queue up the event up > until it can be delivered? Or did I miss something? The "present" event > is essential in the presentation page since it is the one that gives it > the handler to the presentation session. And I see this race condition would actually be addressed by the second point in Mark's email about Google/Mozilla suggested API updates: [[ As a secondary aspect an API that exposes the PresentationSession as a property of NavigatorPresentation would be easier for Web developers, as they don’t have to race against the browser firing the onpresent event too soon, before their event handler is registered. ]] http://lists.w3.org/Archives/Public/public-webscreens/2014Aug/0003.html That would indeed be much better from a developer perspective. Francois.
Received on Tuesday, 19 August 2014 16:51:59 UTC