[whatwg] api for fullscreen()

[Kit Grose]

> 1) Should be convenient for authors to make any element in a page display fullscreen
> 2) Should support in-page activation UI for discoverability
> 3) Should support changing the layout of the element when you enter/exit fullscreen mode. For example, authors probably want some controls to be fixed size while other content fills the screen.
> 4) Should accommodate potential UA security concerns, e.g. by allowing the transition to fullscreen mode to happen asynchronously after the user has confirmed permission

A couple of points:

Regarding point 1, surely any fullscreen API should only support block-level elements?

If I'm reading point 2 correctly, I disagree with it (except in cases like <video> where a default style exists to manipulate the element itself). To me (based on how I can envisage using this functionality, particularly regarding touch-screen kiosks) the use-cases for full-screen capable elements should be left out of the UA and in the hands of the author (e.g. as Javascript buttons or links).

When it comes to point 3, I figure a good way to handle this might be to introduce a CSS pseudo-class for fullscreen elements. Then the UA default style would simply be *:fullscreen { position: fixed; left: 0; top: 0; right: 0; bottom: 0; }. Some method for changing the layout of the element is going to be required to handle cases where the aspect ratio of the screen doesn't match that of the element in the document flow.

Should zoomed-up versions of a container scale elements like images and text or merely the containing box? If the latter, does that limit the ability to provide animation in-UA to naturally zoom the element to full-screen without distracting re-flow of text? And does it limit the likely use-case for authors of providing full-screen slideshows etc. where images would be expected to zoom to fill their new, larger container.

One other brief concern; there's a chance (e.g. on mobile devices) that the "fullscreen" layout is smaller than the element in the normal document flow (where it can be scrolled). That may make it necessary to permit some user manipulation of the fullscreen layout such as zooming and panning (which may otherwise be restricted as per point 4).

—Kit