Re: Extend fullscreen API to support second screen

Hi Duan, Francois,

thank you Francois for following up in the exhaustive email thread, explaining the direction and choices, why we’re aiming for an independent, non-mirroring display, as a - in a way - more generic solution, which also allows mirroring through an app-level implementation. I second your explanations there. 

> In a paper from Intel on second screen for web
> (http://www.w3.org/2013/10/tv-workshop/papers/webtv4_submission_19.pdf),
> fullscreen API is metioned:
> 
>> The Fullscreen API is available but does not have a notion of
> controlling which screen the
>> fullscreen content should be shown on.
> 
> However the current spec doesn't have words on fullscreen API. Was
> "extending fullscreen API to the second screen" approch considered but
> dropped? Where can I find the discussions?

For some context, as I wrote this paper and submitted it for the IPTV workshop:

In this section of the paper called “Situation on the Web” I am explaining the starting point for designing and evolving presentation API: window.open, proprietary extensions to the video element and Fullscreen API are mentioned as part of the landscape on the web. Fullscreen API does not allow using secondary displays - hence made an extension or a new API necessary.

Our initial proposal then was a new API - since hooking it into Fullscreen API while keeping backwards compatibility with web content which uses it, did not seem to match requirements and use cases. Francois already listed additional considerations in more detail.

Regards,

Dominik







> 
> Current spec looks promising to me, but I think it has some limitaions
> if one want to mirror a portion of a page (or a portion of it) to the
> second screen. Patial mirroring is quite useful for presentation, e.g.
> on the first screen (laptop or pad) show the slides and the memos, and
> on the second screen (projector) only show the fullscreened slides, and
> keep the two in sync. With current spec, one may load the slides in both
> local and presentation browsing contexts, and capture-send-reply user
> inputs in one or two directions. However, this is error-prone and not
> always feasible. E.g. what if the slides is playing an animation driving
> by a random number generator? Unless the animation code itself is
> presentation-API-aware, the two screens can't keep sync with each other.
> 
> I think "extending fullscreen API to the second screen" can make this
> task trival. The API is like this:
> 
> partial interface Element {
>  void requestFullscreen(optional short screenId);
> };
> 
> The first screen has screenId 0, and other screens has Ids greater. In
> most cases, elem.requestFullscreen(1) would cast the element to the
> second screen, and fullscreened. Once an element is fullscreened on the
> second screen, its live image on the second screen is captured and
> displayed on its original area on the first screen (need scaling to
> fit); other portions of the page are displayed and functioned as normal.
> UA can also redirect user inputs on the original area on the first
> screen to the second screen. Thus, patial mirroring is accomplished, and
> the client code is very simple.
> 
> Can a page get fullscreened on multiple screens simutaneously? The
> problem is, there is only one document.fullscreenElement. So I think the
> anwser is no, unless a parent element is fullscreened on the first
> screen, and then one of its children is fullscreened on the second screen.
> 
> Another issue is, how is the "original area" of the element styled on
> the first screen after it is fullscreened on the second screen? Maybe a
> "::mirror" pseudo-element can be used to represent the "original area".
> 
> Regards,
> Duan Yao
> 
> 
> 
> 
>

Received on Wednesday, 27 August 2014 14:04:10 UTC