On Fri, Jan 29, 2010 at 4:06 PM, Kit Grose <span dir="ltr"><<a href="mailto:kit@iqmultimedia.com.au">kit@iqmultimedia.com.au</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Regarding point 1, surely any fullscreen API should only support block-level elements?<br></blockquote><div><br>I don't see why. Setting position:fixed does what you want in the cases I can think of.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

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).<br>
</blockquote><div><br>Sorry I wasn't clear. By "in-page UI" I meant UI under the control of the author.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

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.<br>
</blockquote><div><br>Indeed. A CSS pseudo-class sounds like a reasonable idea.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

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.<br>
</blockquote><div><br>If you change the layout, zooming isn't really necessary. My guess is that there are several interpolation strategies for transition effects that would all work. For example, you could apply the style change, render the element at the size of the screen, and then zoom that image out from the element's old position to the screen size.<br>
<br></div></div>Rob<br>-- <br>"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]<br>