[whatwg] api for fullscreen()

On Thu, Jan 28, 2010 at 8:55 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
> On Fri, Jan 29, 2010 at 5:06 PM, Geoff Stearns <tensafefrogs at google.com>
> wrote:
>>>
>>> enterFullscreen always returns immediately. If fullscreen mode is
>>> currently supported and permitted, enterFullscreen dispatches a task that a)
>>> imposes the fullscreen style, b) fires the beginfullscreen event on the
>>> element and c) actually initiates fullscreen display of the element. The UA
>>> may asynchronously display confirmation UI and dispatch the task when the
>>> user has confirmed (or never).
>>
>> Don't you think it would make more sense to dispatch the enterFullscreen
>> event only when the element actually goes fullscreen? If the user clicks the
>> fullscreen button, but then doesn't accept whatever options (likely a
>> security dialog or something) then it doesn't make sense to broadcast an
>> enterFullscreen event, as you'd just have to broadcast an exitFullscreen
>> event right away to show that the user isn't actually in fullscreen.
>
> That was my intent in the last sentence of the paragraph you quoted.
>
>>
>>>
>>> The enableKeys parameter to enterFullscreen is a hint to the UA that the
>>> application would like to be able to receive arbitrary keyboard input.
>>> Otherwise the UA is likely to disable alphanumeric keyboard input. If
>>> enableKeys is specified, the UA might require more severe confirmation UI.
>>
>> This seems overly complicated. I think it would suffice to simply show a
>> dialog the first time a user wants to go fullscreen within a domain with an
>> option to "remember this choice for this domain." Then the user won't have
>> to jump through the hoops again when they return, but will still protect
>> them from random websites going fullscreen and trying to phish things. This
>> way blocking or restricting keyboard events isn't needed.
>
> Those kinds of dialogs are dangerous because users tend to just dismiss them
> without reading. Passive (ignorable and asynchronous) confirmation works
> better.
>
> The enableKeys option would let authors who don't need alphanumeric input
> (video playback) go fullscreen with a low confirmation bar (perhaps none at
> all, if the fullscreen request is in a click event handler).
>
>> Also consider what happens if the user focuses something on another
>> display. Do you then drop out of fullscreen, or just blur() the fullscreen
>> window? (I'd vote to leave it and just blur() it, so you can do things like
>> watch fullscreen video on one display and continue working in the other).
>
> That sounds like a good idea, but I don't think it needs to be in the spec.
> It's up to the UA.
>
>> Another thing to add in here I haven't seen discussed yet is what to show
>> as the background to the fullscreen element. Consider the example of a 16:9
>> video going fullscreen on a 4:3 display. How do you tell the browser to fill
>> in the extra space around the video with black (or whatever other color you
>> want). Is this a custom css element?
>
>
> The <video> element already letterboxes. So you'd do something like this:
> <div class="fullscreen" style="background:black; position:relative;
> width:640px; height:480px;">
> ? <video style="position:absolute; width:100%; height:100%;"
> src=...></video>
> ? ... controls ...
> </div>
>
> Making the <div> fullscreen would override the author geometry and produce
> the effect you want.

When you say that the DOM viewport of the element is aligned with the
screen when it goes fullscreen, does that mean that the .width and
.height properties are changed? Or does it mean that the element's
size is changed by a CSS style?

The case I'm thinking about is when a Canvas element is taken
fullscreen; on that element changing the .width and .height properties
changes the size of the backing store, but applying a CSS style to
change its width and height causes the backing store to be scaled to
fit. The desired behavior is for the backing store to be resized.

-Ken

> 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]
>

Received on Monday, 1 February 2010 10:39:05 UTC