Anyone any opinions here? Sirisian, what exactly are you suggesting the standard should say?

This strikes me as something platform-dependent.

(In reply to comment #1)
> Anyone any opinions here? Sirisian, what exactly are you suggesting the
> standard should say?

Below the section:
"7 Security and Privacy Considerations"
Put:
------
8 Multiple Monitor Non-Normative Recommendations
When using multiple monitors a user agent will often lose focus. When in fullscreen this means exiting fullscreen. User agents are encouraged to implement a global preference that would allow the user agent to persist in fullscreen. The user agent would prompt the user with a confirmation dialog about staying in fullscreen when losing focus, with options to permit, dismiss, or block all repeated attempts.
------
That's it. I basically took all the wording from the pointer lock specification. Also I removed the per-subdomain since for fullscreen it's unnecessary. Most people will understand if their user agent loses focus and their prompted to stay in fullscreen what is happening.

(In reply to comment #2)
> This strikes me as something platform-dependent.

Very much so. Most operating systems though don't allow more than one window to be in focus at a time. It's a non-normative recommendation so that implementers do something for this case instead of dropping out of fullscreen with no way of staying in fullscreen. This is a problem in most browsers currently that implement fullscreen. It's much easier to say "why don't you implement this in the spec" for people using multiple monitors than it is to try to argue each case.

I don't think this needs to be covered in the spec. It shouldn't affect Web compatibility. It's a quality-of-implementation issue.

I think there are several use cases where multi-monitor support for web apps is desirable. The following use cases require one or more fullscreen views on separate monitors, either due to presentational reasons or UI focus / maximizing available screen real estate. 


1) A presentation system: Slides on one screen (e. g. DVI-attached projector), controls/notes/time etc. on another (presenter-facing) monitor (e. g. internal notebook monitor). See e. g. Keynote's multi-monitor mode. Any chrome is distracting in this case. 

2) Streaming video from a web app (e. g. on a phone/tablet) to a TV (secondary screen) while displaying a remote on the primary internal screen. Compare with e. g. YouTube app with AirPlay. 

3) Many professional or industrial applications can benefit from a multi-monitor setup to extend the number of things you can display at once, have multiple concurrent views with different characteristics (e. g. a data view on one monitor and controls on a touch screen), or have multi-user setups (e. g. a controller, a supervisor and a visitor view, see also #1). Chromeless windows are not required, however having a fullscreen view will clearly benefit the app's UX. 

4) A multi-monitor broadcasting system (with network-attached screens), e. g. company- or department-wide announcement screens. It may sound strange, but I'm sure there are applications where this is very useful. This may also work for TV studio setups though the web is certainly not the right platform to use here (at least yet). 


I cannot think of non-fullscreen use cases, those can actually be accomplished with popups (but probably not mixed fullscreen and popups, at least with current implementations). Thus extending the current requestFullscreen API would be a straightforward approach to solve that problem (IMO). 

So this is just a rough sketch (certainly not a syntax proposal) but it could work like that (somehow related to use case #4): 

```
navigator.getAvailableVideoStreams(function(streams){
  let destinations = [];
  for dest of streams {
    if (dest.isRemote) 
      destinations.push(dest);
  }
  videoElement.requestFullscreen({destination: destinations});
});
```

The available video output streams (each stream is an independently accessible video out stream, as defined by h/w and OS) may indicate if they are local (e. g. attached via DVI) or remote (e. g. via network). The streams should indicate their native resolution (`dest.resolution = [width,height,depth?]`). 

The streams may also provide interfaces for ambient light, brightness, integrated speakers etc., but their use cases are rather academic and certainly out of scope for a v1 (plus, no hardware may support any of this; I'm just exploring possibilites). 


Either way, I think this is a useful and much needed addition to current functionality. This may also be an important feature for B2G-like phones/tablets for tethered or wireless video/interface output (where the current requestFullscreen itself does not make immediate sense). Additionally, having a totally different API for this feature does not seem to be a practical approach here (IMO).

Florian, I filed https://github.com/w3c/presentation-api/issues/150 to check, but I have the feeling there's little overlap between presentation and using fullscreen, although presentation was once of the use cases for fullscreen...

Closing this in favor of that. Perhaps once there are primitives for other monitors we can solve this better, but I don't plan on pioneering that. If you have the resources and want to solve this, do let me know and I'll help you out.