- From: Anssi Kostiainen via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Jun 2017 11:37:15 +0000
- To: public-secondscreen@w3.org
Hearing no further comments, I'd ask the editors @avayvod @mounirlamouri to implement the synthesis of the latest proposals. Feel free to use your editorial freedom to mould the text to fit in the spec, but roughly: * Add the following informative notes (I replaced normative RFC 2119 terms with their informative equivalents, some editorial): >Given the varying capabilities of the remote playback devices, some `HTMLMediaElement` APIs will not work by design or will be obsolete. In these cases they are expected to fallback to the same behavior as if the local playback device would not support these APIs. Examples of such features include encryption, captions, multiple tracks, and so on. >The properties of the `HTMLMediaElement` are expected to 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." * Classify the `HTMLMediaElement` properties into two buckets: properties that MAY and MUST behave as specified also on the remote playback device per the list documented earlier in this issue. I suggest use a concise form over an actual list: >The following `HTMLMediaElement` properties MUST behave as defined in [HTML] on the remote playback device: X, Y, Z". Listing MUSTs and MAYs is a start, and optimally we'd add normative language to define expected behaviour in the case of "not supported" for each MAY feature, as to allow web developers feature detect such cases in an interoperable manner across implementations. I opened #88 to discuss the case where the remote playback device capabilities might not always be a subset of those of the local playback device. -- GitHub Notification of comment by anssiko Please view or discuss this issue at https://github.com/w3c/remote-playback/issues/41#issuecomment-307764652 using your GitHub account
Received on Monday, 12 June 2017 11:37:30 UTC