RE: Requesting display of non HTML content (was: Draft of Second Screen Presentation Working Group Charter available)

Hi Anssi, all,

> -----Original Message-----
> From: Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com]
> Sent: Donnerstag, 29. Mai 2014 11:43
> To: Francois Daoust; public-webscreens@w3.org
> Cc: Mark Watson; Mark Scott; Rottsches, Dominik; mark a. foltz; Bob Lund;
> Bassbouss, Louay; Philipp Hoschka; Daniel Davis
> Subject: Requesting display of non HTML content (was: Draft of Second
> Screen Presentation Working Group Charter available)
> 
> Hi Francois, All,
> 
> On 29 May 2014, at 00:34, Francois Daoust <fd@w3.org> wrote:
> 
> > Apologies for top-posting. I have been following this discussion for a
> > while now and I'm a bit confused, so here is an attempt to reformulate
> > the problem at hand with my own words. Hope I got things right :)
> 
> Francois - thanks for summarising the discussion, very helpful!
> 
> > I see two issues here. I agree with MarkW that both of them are already in
> scope for a potential working group given the current charter and that they
> should remain in scope. The short summary of that email is thus "no
> proposed change to the current draft charter".
> >
> >
> > Filtering out non compatible displays
> 
> [I'll leave this one out to focus on the latter issue first.]
> 
> > Requesting display of non HTML content
> > -----
> > The second issue at stake is about specifying what happens when a call
> such as the following is issued:
> >
> >  navigator.presentation.requestShow('video.mp4');
> >
> > The main problem is that, regardless of where this runs, this does not
> create a "browsing context" as such since a video is not an HTML document.
> >
> > While it's easy to see how a browser could create a fake browsing context
> for the video (as is done in practice when you open a link to a video in your
> browser), it's hard to see how the initiating page can communicate with the
> created browsing context to control video playback.
> >
> > Here, my understanding is that Anssi and Dominik wants to put support for
> non HTML content out of scope of the working group, whereas MarkF,
> MarkS and MarW would like to leave it in. Is that a fair summary?
> 
> We've been discussing what can be passed to the requestShow() AFAICT.
> 
> I've argued random schemes should not be supported. After rereading
> MarkS and MarkW's requirements, below I have a proposal how we might be
> able to reach consensus on this issue (I'm hoping) with something that is
> more webby, in my option.
> 
> > If support for non HTML content is in scope, the API needs to specify what
> happens in such a case. Main question is thus: how to control the media
> player from the initiating web application when you don't know anything
> about it? For media content, typical commands include: play, pause, seek,
> but what about subtitles?, switching to another format? etc. The commands
> could perhaps be borrowed from the HTML5 video interface. The Google
> Cast Chrome Media API could be a good starting point:
> >
> >
> https://developers.google.com/cast/docs/reference/chrome/chrome.cast.
> m
> > edia.Media
> >
> > MarkS, MarkF, any input on this?
> 
> [...]
> 
> > As mentioned by MarkW below, the current charter has non HTML content
> in scope for the group: "The web content may comprise HTML documents,
> web media types such as images, audio, video, or application-specific media,
> depending on the capabilities of the secondary display for rendering the
> media". So, here again, no change to the current wording.
> 
> 
> Here's my proposal for "requesting display of non HTML content" building
> atop the existing Web platform APIs (similarly to e.g. how <video> is used as
> input in WebGL or canvas, <audio> as input in Web Audio API etc.).
> 
> This suggests requestShow() accepts not only an URL as an argument (that
> points to content that creates a browsing context, that is text/html), but also
> an HTMLMediaElement.
> 
> Here's an example how I envision this would work:
> 
> <!DOCTYPE html>
> <html>
> <head>
> <title>Presentation API FTW</title>
> </head>
> <body>
> 
> <video src="foo.mp4" poster="foo.jpg">
> Fallback content for the video.
> </video>
> 
> <audio src="bar.ogg">
> Ditto, but for the audio.
> </audio>
> 
> <img src="baz.jpg" alt="Image description" />
> 
> <script>
> var video = document.querySelector('video'); var audio =
> document.querySelector('audio'); var image =
> document.querySelector('img');
> 
> // Start the video playback when the video is ready to be shown // on the
> secondary screen, show the poster.jpg placeholder // before the playback
> starts.
> requestShow(video).then(function (display) { video.play(); });
> 
> // ... the same for audio (there's no poster obviously):
> // [noting for audio "show" sounds weird]
> requestShow(audio).then(function (display) { audio.play(); });
> 
> // ... and finally, also works with images.
> // If you want to implement an image slideshow you // could modify the
> image.src programmatically requestShow(image).then(function (display) { /*
> ... */ }); </script> </body> </html>
> 
I like this proposal, this solves the media control issue by using HTMLMediaElements and opens the door for using existing APIs like MediaStream API, FileSystem API for accessing offline files, etc.  without the need to touch the Presentation API spec.   

> Obviously, canvas could be piped to a secondary screen similarly, but I stop
> here.
Actually you can adapt it to any DOMElement ;). This is what I already proposed sometime at the very beginning of the CG discussion.  

> 
> IOW, we reuse the machinery already defined in the HTML spec for media
> elements.
> 
> All - WDYT?
> 
> Thanks,
> 
> -Anssi

Louay

Received on Friday, 30 May 2014 09:25:11 UTC