- From: Mounir Lamouri <mounir@lamouri.fr>
- Date: Thu, 05 Nov 2015 15:21:00 +0000
- To: public-secondscreen@w3.org
- Cc: Philip Jägenstedt <philipj@opera.com>, jer.noble@apple.com, avayvod@google.com, jonas@sicking.cc
Hi, Anton and I are trying to define how disableRemotePlayback (or hideRemoteControl as currently named in the spec draft) should behave. After talking with a few parties, we believe that everybody agrees that we need such an attribute but it seems that there is a subtle difference in how it should behave. So, these are the use cases we have in mind: - A website doesn't want the user to play the media remotely because the website doesn't want the content to be played remotely (content restrictions or secondary content, etc.) - A website doesn't want the UA to suggest to the user to play the media remotely because it is using the Presentation API. - A website wants to control the user experience and prevents the UA from showing any kind of browser UI for remote playback (url bar icon, notification icon, overlay icon, default controls icons, ...). We believe that these use cases can be fulfilled by hinting the UA to disable its UI for remote playback. However, another approach would be to fully disable the remote playback ability, blocking the API -- it seems that Safari's x-webkit-wirelessvideoplaybackdisabled behaves like that. This approach doesn't fulfil the last use case. These two approaches are very similar apart that if the website tries to use the Remote Playback API. In the former, the calls will be allowed while in the latter, the UA will reject them. We prefer the first approach because we believe it is more flexible and extensible: the website gives a hint to the UA but isn't limited in its behaviour afterwards. If you have a preference over the behaviour, we would love to hear it. As long as we are at it, feel free to suggest better names ;) Cheers, Anton & Mounir
Received on Thursday, 5 November 2015 15:21:31 UTC