[whatwg] Fullscreen revision I

On Tue, Oct 25, 2011 at 12:04 AM, Anne van Kesteren <annevk at opera.com>wrote:

> On Tue, 25 Oct 2011 00:32:43 +0900, Glenn Maynard <glenn at zewt.org> wrote:
>
>> Doing this synchronously means nobody can ever implement ask-first.  Don't
>> permanently lock everyone into a permission scheme with known problems.
>>
>
> Since the events are not dispatched synchronously I think we should always
> be able to change.


The fullscreen element is changed synchronously.  For ask-first, you want it
to change only after permission is granted.


>  It also seems odd that fullscreenElement is set synchronously, but
>> fullscreenchange events are fired asynchronously.  It would make more
>> sense to do them together, from the same task (set all fullscreenElements
>> first, then fire all fullscreenchange events).
>>
>
> 1) You want them to be set so when the UA does its transition it knows what
> to transition to.
>

> 2) You cannot set them all from the same task because that would not work
> for non same-origin documents.


4. Return, and perform the following step asynchronously.
5. Optionally, ask the user for permission to enter fullscreen.  If
permission is denied, terminate these steps.  If permission is granted, or
if permission is assumed, queue a task to run the following steps:
  1. For each document in docs, run these substeps:
    1. Let following document be the
document<http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-document>after
document in docs, or null if there is no such document.
    2. If following document is null, set document's fullscreen
element<http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#fullscreen-element>to
the context
object<http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#context-object>,
queue a task<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#queue-a-task>to
fire
an event<http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-event-fire>named
fullscreenchange with its bubbles attribute set to true on the context
object<http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#context-object>.

    3. Otherwise, set document's fullscreen
element<http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#fullscreen-element>to
following
document's browsing context
container<http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#browsing-context-container>and
queue
a task<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#queue-a-task>to
fire
an event<http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-event-fire>named
fullscreenchange with its bubbles attribute set to true on document.
  2. Return, and run the remaining steps asynchronously.
  3. Optionally, perform some animation.
  4. Optionally, display a message indicating how the user can exit
displaying the context
object<http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#context-object>fullscreen.

 This is much more complicated for developers.  If fullscreenEnabled can
>> change, you have to monitor it to change UI (eg. show/hide fullscreen
>> buttons).
>>
>> How is this simpler than just making requestFullscreen switch the
>> fullscreen element?
>>
>
> If you allow changing the fullscreen element you need to track what
> documents changed, dispatch events as appropriate, and you keep the problem
> that exiting exits everything which is quite odd.


Exiting everything is odd, but only the rare people who are nesting
fullscreening would need to care about it.  Allowing fullscreenEnabled to
change on the fly complicates code for everyone.

I'm not sure how the exits-everything problem relates to the "changing the
fullscreen element" case, though.  You should be able to switch fullscreen
elements without having to flicker out and back into fullscreen to do so,
and without having to move things around in your document.  For example, a
page with four videos could have "next" and "previous" buttons in
fullscreen, which shift to the other videos while remaining in full screen.

-- 
Glenn Maynard

Received on Monday, 24 October 2011 23:18:34 UTC