- From: Google <sysbot+gh@w3.org>
- Date: Wed, 17 May 2017 17:44:04 +0000
- To: public-secondscreen@w3.org
I think that is okay, but one concern raised earlier is that there may not be specified behavior for mandatory features not implemented by the playback device. As you say this is also an issue for both local and remote playback, so the fix may be to address this in HTML5, but practically speaking I could see the potential for different interpretations. For example, if muting is not supported, one UA may allow the attribute to be set but not propagate the command to the remote device, while another UA may ignore attempts to set the attribute. In either case content with custom controls may not correctly reflect the remote state depending on whether they recheck the attribute after setting and whether it accurately reflects the remote state. Maybe the note could state that the properties of the media element should reflect as closely as possible the remote playback state, even if not all features are supported by the remote playback device; and events should not be fired unless they reflect actual changes to the remote playback state. Second, one purpose of the Presentation API note was to give specific guidance as to what APIs are not expected to work on the presentation. Can the same be done for remote playback - I think you started a list above, can it be made more explicit? I would be in favor of two separate notes as I think they convey different information. -- GitHub Notification of comment by mfoltzgoogle Please view or discuss this issue at https://github.com/w3c/remote-playback/issues/41#issuecomment-302170859 using your GitHub account
Received on Wednesday, 17 May 2017 17:44:10 UTC