- From: Mounir Lamouri <mounir@lamouri.fr>
- Date: Mon, 07 Dec 2015 11:42:25 +0000
- To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, Anton Vayvod <avayvod@google.com>
- Cc: public-secondscreen@w3.org, Philip Jägenstedt <philipj@opera.com>, jer.noble@apple.com, Jonas Sicking <jonas@sicking.cc>
On Thu, 3 Dec 2015, at 11:52, Kostiainen, Anssi wrote: > 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. If `start()` were to work even if the attribute was set, I don't think having a user warning would be useful. If `start()` is called, I would expect that the websites has a UI that allows remote playback of the video so the user and the website are clearly expecting the video to be played remotely at that point. I think one of the benefits of blocking remote playback is that such "bug" in the website would be caught early because the remote playback would fail consistently in all browsers. A website could easily remove the attribute and call `start()` if they need to. -- Mounir
Received on Monday, 7 December 2015 11:42:51 UTC