2) Chris brought forward the case of nesting. You have a fullscreen
presentation (lets assume API-based activated for now) and in that
presentation there's some video that the presenter wants to display
fullscreen (lets assume the video player is a custom widget with
API-based
fullscreen activation for now). Once the presenter exits displaying the
video fullscreen, the presentation should still be fullscreen.
Initially this was brought up with the video being hosted in a separate
descendant document, but the video could be in the same document as
well.
roc suggested a model that works when you have separate documents and
it
could be made to work for the single document case too, as long as the
level
of nesting remains is no larger than required for the presentation
scenario
mentioned above.
Is that an acceptable limitation? Alternatively we could postpone the
nested fullscreen scenario for now (i.e. make requestFullscreen fail if
already fullscreen).
+1 for punting on the nested case.
I think you'd ever only want to have one thing fullscreen at a time.
Thus, if you go from a fullscreen to another, the previous one should
naturally leave fullscreen. I think that's how presentation
functionality works on ppt and similar tools, too.
Silvia.
I can see the use case when Document is fullscreen, and then an element is
fullscreened.
So if another element goes fullscreen it replaces the previous, if any,
but the document keeps its state.
Another alternative would be to have a stack, but I think that's overkill.
