> 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
