W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] Fullscreen feedback

From: Adam Barth <w3c@adambarth.com>
Date: Sun, 22 Aug 2010 22:25:21 -0700
Message-ID: <AANLkTinn+fQM4GtcBxBz0HKH9d_MWDrV--ZbLN2-iQSc@mail.gmail.com>
On Sun, Aug 22, 2010 at 10:11 PM, Robert O'Callahan
<robert at ocallahan.org> wrote:
> On Mon, Aug 23, 2010 at 5:03 PM, Adam Barth <w3c at adambarth.com> wrote:
>> On Sun, Aug 22, 2010 at 9:56 PM, Robert O'Callahan <robert at ocallahan.org>
>> wrote:
>> > On Mon, Aug 23, 2010 at 4:42 PM, Adam Barth <w3c at adambarth.com> wrote:
>> >> Oh, I think the iframe-at-a-time is an easier model to work with since
>> >> the scripting context will get adopted into the full-screen view
>> >> together with the elements.
>> >
>> > It requires the author to put each part of their page that they want to
>> > go
>> > fullscreen into its own subframe. That is cumbersome. With my proposal,
>> > most
>> > existing pages and player UIs would work if you just call
>> > "element.requestFullScreen()" in some event handler.
>>
>> But it doesn't go full screen, right? ?Didn't you say above that the
>> location bar is still there?
>
> That depends on the UA. Assuming we implement this API using our existing
> fullscreen functionality, in Firefox the element would be fullscreen, but if
> the user moves the mouse to the very top of the screen some browser chrome
> will pop down temporarily, including the URL bar.

So...  The trade-off is:

1) Only browsing contexts can go full-screen (since they have URLs
that we could display).
2) Any element can go full-screen, but we'll need to add a nasty
non-semantic attribute.

Another idea is that we could let any element go full-screen, but then
we'd show the URL of its browsing context.  There's some subtleties
here about overlays from parent frames, but those seem solvable.

Adam
Received on Sunday, 22 August 2010 22:25:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:00 UTC