> 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 

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).


Reply via email to