- From: Rottsches, Dominik <dominik.rottsches@intel.com>
- Date: Tue, 10 Jun 2014 12:30:20 +0000
- To: "public-webscreens@w3.org" <public-webscreens@w3.org>
- CC: "B.Lund@cablelabs.com" <B.Lund@cablelabs.com>, "watsonm@netflix.com" <watsonm@netflix.com>, "fd@w3.org" <fd@w3.org>, "markdavidscott@google.com" <markdavidscott@google.com>, "mfoltz@google.com" <mfoltz@google.com>, "ddavis@w3.org" <ddavis@w3.org>, "ph@w3.org" <ph@w3.org>, "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, "louay.bassbouss@fokus.fraunhofer.de" <louay.bassbouss@fokus.fraunhofer.de>
Hi Anssi, Mark, Louay,
On Mon, 2014-06-02 at 10:36 -0700, mark a. foltz wrote:
> I also agree that this is a good starting point, as it re-uses the
> HTMLMediaElement APIs for both local and remote playback (and this was
> one of the alternatives I proposed earlier for this functionality).
> My only caution is that the devil is in the details as there is a
> large set of functionality that is encapsulated in HTMLMediaElement
> and not all of it may be compatible with rendering on a remote UA, so
> we will need to address content specific negotiation of capabilities
> at some point.
>
I like Anssi's idea and flexibility of using alternative types of
content. But I also agree with Mark that spec'ing the behavior of an
HTMLMediaElement that goes out to a secondary screen might indeed have
the devil in the detail.
I think instead of spec'ing this behavior, it has a better place in a
small helper library in JavaScript. Many sites probably already use
video wrappers like video.js or flvplayer. We could have a companion
project for a helper library like media-presentation.js that provides a
JS function like
requestShowMedia("http://example.org/myvideo.mp4")
or that provides a wrapper for
<html>
<video id="myvideo" src="myvideo.mp4">
</html>
document.querySelector("#myvideo").requestShow();
This is already doable with the current API proposal that we are
discussing on the wiki.
I agree with Louay that the idea is desirable, and with Anssi that this
would improve API ergonomics. But I think it has better place in a
library which can evolve faster and more flexibly than a specification.
I think we reach our goals quicker if we only provide primitives and let
library developers build on top.
If we see certain prominent usage patterns emerge from this example or
similar libraries, we can move them to the native side step by step.
Regards,
Dominik
Received on Tuesday, 10 June 2014 12:31:14 UTC