- From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
- Date: Thu, 3 Dec 2015 11:52:02 +0000
- To: Mounir Lamouri <mounir@lamouri.fr>, Anton Vayvod <avayvod@google.com>
- CC: "public-secondscreen@w3.org" <public-secondscreen@w3.org>, Philip Jägenstedt <philipj@opera.com>, "jer.noble@apple.com" <jer.noble@apple.com>, Jonas Sicking <jonas@sicking.cc>
Hi, [hat off] > On 25 Nov 2015, at 23:20, Mounir Lamouri <mounir@lamouri.fr> wrote: > > Anton and I have some update about this. We met with Jer Noble (Apple) > two weeks ago and he gave us more details about about the behaviour on > iOS. A significant difference between Safari iOS behaviour and Chrome > Android behaviour is that when selecting a new route, it becomes the > default route. In other words, when a video is played remotely on one > website, when playing something on another website, it would also play > remotely, until the user changes the default route (AFAIUI). Thanks for the update, and sharing the results from the discussion. > Therefore, hideRemoteControls isn't the right attribute because we would > like to not use the default route but the local route when playing a > media element with the attribute. We decided to go with the name of > disableRemotePlayback. The spec has been updated accordingly. > > Regarding the behaviour of the Remote Playback API when the attribute is > set, Jer wants media.remote.start() calls to fail. I'm not sure if we > should do that but I have no valid use case against it so we decided to > go that way unless someone comes with a strong use case. This change > isn't yet part of the specification because this part of the > specification isn't yet fleshed out. Sounds reasonable. Does disableRemotePlayback as now specced mirror the behaviour of x-webkit-wirelessvideoplaybackdisabled? Looking at this the other way: if the start() would not fail when the disableRemotePlayback attribute is set, what would a reasonable behaviour look like? Just thinking on top of my head: would the UA e.g. inform the user that the remote playback of the content is disabled, but nevertheless allow the user to proceed with remote playback? A bit similarly to how a user gets a "confirm form resubmission" interstitial warning if trying to repost cached content. I think explicitly rejecting the promise as suggested by Jer would be better for interoperability and would make for a more consistent UX too. And as a bonus, make the API more polyfillable. > Assuming no one objects to this change, Chrome might ship this attribute > (disableRemotePlayback) in the next release (Chrome 49). We believe that > the attribute is simple enough and offers values to websites which will > be able to disable the default remote playback behaviour if they want > to. The rest of the API will require more work obviously. Shipping this in small yet functional pieces seems like a good idea. Thanks, -Anssi
Received on Thursday, 3 December 2015 11:53:41 UTC