On Fri, Aug 6, 2010 at 10:17 AM, Simon Fraser <span dir="ltr"><<a href="mailto:smfr@me.com">smfr@me.com</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;">
This is feedback on the Mozilla FullScreen API proposal here:<br>
<<a href="https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI" target="_blank">https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI</a>><br>
<br>
> The user agent may transition a Document into or out of the<br>
> fullscreen state at any time, whether or not script has requested<br>
> it. User agents are encouraged to provide standard UI to exit the<br>
> fullscreen state, for example if the user presses the Escape key.<br>
<br>
Does this imply that the UA has a "fullscreen" button, when<br>
the user uses this to make the window fullscreen, then the<br>
CSS pseudoclasses described in this document are applied?<br></blockquote><div><br>Yes, that's the idea. We want to be able to integrate fullscreen UI with scripted fullscreen.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I'm not sure that's always desirable; I think it might result<br>
in unexpected behavior for users who use the fullscreen button<br>
as an equivalent to maximizing the window.</blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I'd suggest that the CSS pseudoclasses are only applied when the<br>
fullscreen JS API has been called by the web content.<br></blockquote><div><br>Well, that's up to the UA; you can have a fullscreen mode that doesn't put the document into the fullscreen state, if you want.<br><br>
Note that the API lets authors distinguish "fullscreen with a specific targeted element" vs "fullscreen with no targeted element", and a basic fullscreen UI would only enter the latter mode. So I don't think you'll get unexpected behavior in practice if they're integrated.<br>
<br>Personally I think they should be integrated. For example, if you have a canvas game that occupies most of the window except for some instruction text, and the game has a fullscreen command that makes the canvas fill the window and resizes the canvas buffer to the window size, I think it would be nice for the UA's fullscreen UI to trigger the same behavior. Or maybe you have a slide viewer and you want the UA's fullscreen UI to trigger fullscreen presentation mode. This API makes that possible.<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;">
> * void cancelFullScreen()<br>
<br>
I think "exit" would be better than "cancel".<br></blockquote><div><br>The only problem with "exit" is that you might call it when you're not actually in fullscreen state, since requests are asynchronous. I think of it more as cancelling the request than actually forcing a change.<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;">
> New methods of Document:<br>
> * void requestFullScreen()<br>
> * void requestFullScreenWithKeys()<br>
<br>
> New methods of Element:<br>
> * void requestFullScreen()<br>
> * void requestFullScreenWithKeys()<br>
<br>
Do we really need to add these to both Document and Element?<br>
It seems like the Document ones could be removed; if an<br>
author wants to take the Documemnt fullscreen, they simply<br>
call the methods on document.documentElement.<br></blockquote><div><br>Yes, we can do that. This means getting rid of the concept of not having a fullscreen element, and instead special-casing the case where the fullscreen element is the root element in a few places. But I think that's probably a win. Thanks.<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;">
I'm not fan of "WithKeys" in the method names. Out of<br>
context, it's not clear what "keys" means. I think<br>
"keyboardInput" or "keyInput" would be more understandable.<br></blockquote><div><br>OK.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Also, why not just use a parameter:<br>
<br>
void requestFullScreen(bool allowKeyboardInput)<br></blockquote><div><br>boolean parameters are bad style IMHO. It's hard to tell at the call site what they mean.<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;">
or have some constants for behavior:<br>
<br>
const unsigned short ALLOW_KEYBOARD_INPUT = 1;<br>
void requestFullScreen(unsigned short behavior)<br>
<br>
This would be extensible, and would allow us to permit other<br>
behaviors later.<br></blockquote><div><br>Sure.<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;">
Why don't requestFullScreen()/requestFullScreenWithKeys() return<br>
a boolean value indicating whether the UA will allow the request<br>
to proceed? The author has no information about whether fullscreen<br>
is going to happen after making this call, and UAs will certainly<br>
want to deny fullscreen in various situations.<br></blockquote><div><br>The UA may not be able to make a decision synchronously. Permitting asynchronous decisions about whether to permit fullscreen was a key goal here. For example that gives UAs the option of presenting passive confirmation UI.<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;">
> New content attribute of the <iframe> element:<br>
> * allowfullscreen<br>
> This is a boolean attribute. When this attribute is not set, UAs<br>
> should ignore fullscreen requests in the iframe or its descendants.<br>
<br>
Descendant nodes, or descendant iframes?<br></blockquote><div><br>Descendant frames. I'll clarify that.<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;">
> * :full-screen-doc<br>
<br>
I don't like the abbreviation of "document" here. Would "page"<br>
be a better term to use than "document" for these?<br></blockquote><div><br>We can just make it ':full-screen-document'.<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;">
> * :full-screen-doc<br>
> While a Document is in the fullscreen state, the 'full-screen-doc'<br>
> pseudoclass applies to the root element of that Document.<br>
><br>
> * :full-screen-doc-with-target<br>
> While a Document is in the fullscreen state and the document's<br>
> current fullscreen element is an element in the document, the<br>
> 'full-screen-doc-with-target' pseudoclass applies to the root<br>
> element of that Document.<br>
<br>
Just to be clear, if a document is fullscreen, and the fullscreen<br>
element is not the document element, then the document element<br>
will get both these pseudoclasses?</blockquote><div><br>Correct.<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;">What happens when the<br>
fullscreen element is the the document element?<br></blockquote><div><br>As written, it would get all three pseudoclasses. But I think we can get rid of full-screen-doc-with-target completely.<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;">
I'd like to see the proposal fleshed out to address the following<br>
scenarios:<br>
<br>
* the document is fullscreen, and navigation happens<br></blockquote>* the document is fullscreen, and the content calls requestFullScreen()<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
again (possibly with a different element, possibly inside an iframe).<br>
* the document is fullscreen, and the fullscreen element is removed<br>
from the DOM<br>
* the document is fullscreen, and the fullscreen element has<br>
display:none set on it.<br>
* consideration of whether the fullscreen API can be called at<br>
any time (risk of "drive-by-fullscreening").<br>
* affect, if any, on calls to focus() on elements which are not children<br>
of the fullscreen element.<br></blockquote><div> </div></div>Done. In most of those cases, nothing special happens. That is intentional; for example, I think trying to special-case handling of display:none or focus would quickly add a lot of complexity.<br>
<br>Thanks for the feedback!<br clear="all"><br>Rob<br>-- <br>"Now the Bereans were of more noble character than the
Thessalonians, for they received the message with great eagerness and
examined the Scriptures every day to see if what Paul said was true." [Acts 17:11]<br>