On Sat, Jan 30, 2010 at 5:49 AM, Simon Fraser <s...@me.com> wrote:
> On Jan 28, 2010, at 6:42 PM, Robert O'Callahan wrote:
>
> 1) Should be convenient for authors to make any element in a page display
> fullscreen
> 2) Should support in-page activation UI for discoverability
>
>
> I agree with Boris that we should leave this up to the page author.
>
Leaving it up to the page author was what I meant by in-page UI, I just
didn't phrase it well.
> While an element is fullscreen, the UA imposes CSS style "position:fixed;
> left:0; top:0; right:0; bottom:0" on the element and aligns the viewport of
> its DOM window with the screen. Only the element and its children are
> rendered, as a single CSS stacking context.
>
>
> So this makes it a very element-focused API (as does the enterFullscreen()
> method on Element that you propose above).
>
> Another approach would be to leave it entirely up to the page author to
> style their page differently when in fullscreen, and not have the API force
> them to focus on one element. Then the API would probably be on the Window
> object, and the UA would simply transition the view to a fullscreen
> presentation. There could be a pseudo-class to the body, or a way to use
> media queries to allow the author can apply different styles for fullscreen.
>
> In this scenario the author is not forced to nest all their fullscreen
> content under one element, and can continue to show the rest of the page
> content (maybe dimmed out by a semi-transparent overlay div) in the
> background.
>
The latter is easy to do with my proposed API too: just give the fullscreen
element a non-opaque background.
The disadvantage of this approach is that it makes it much harder for the UA
> to do any kind of automatic transitions between the two presentations
> (though it's not clear to me that nice automatic transitions will be
> possible with the element-based API either).
>
I suggested an approach for transitions above: apply style changes, render
the element at the size of the screen, and then zoom that image out from the
element's old position to the screen size. Because <video> self-letterboxes,
you can make this always look good for <video> even if the screen has a
different aspect ratio to the original size of the video element.
There is an additional issue I just thought of: with either approach, you'll
normally want to hide the viewport scrollbar. You could just say that the UA
hides the viewport scrollbar while the viewport is in fullscreen mode. Or
you could use a pseudoclass to set overflow:hidden on the root element,
which would let the author override it, or make the user do that manually.
So how about a Window API with an optional element component:
void enterFullscreen(optional DOMElement element, optional boolean
enableKeys);
void exitFullscreen();
boolean attribute supportsFullscreen;
boolean attribute displayingFullscreen;
"beginfullscreen" and "endfullscreen" events
Where "beginfullscreen" and "endfullscreen" are targeted at the element if
one was provided, or else at the window, and bubble. While a window is
fullscreen, the root element and the designated fullscreen element, if any,
are given a pseudoclass "fullscreen". Then you can have some default rules
in the UA style sheet:
*:root:fullscreen { overflow:hidden; }
*:not(:root):fullscreen { position:fixed; left:0; top:0; bottom:0; right:0;
}
Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
