On Mon, Aug 9, 2010 at 5:58 PM, John Harding jhard...@google.com wrote:
If there are multiple elements on the page (e.g. multiple inline video
players) that could go fullscreen, you still need some way to determine
which of them the user intended to make fullscreen.
It's up to the script in
Fullscreen support for specific elements is more than just a convenience -
it's fairly common to have multiple elements on a page that could be made to
go fullscreen, such as a page with multiple video players. For YouTube,
we've chosen to put our embeddable player within an iframe, but I imagine
Fullscreen support for specific elements is more than just a convenience -
it's fairly common to have multiple elements on a page that could be made to
go fullscreen
If the browser fullscreen API only supported making the entire page
fullscreen, you could make an element fullscreen by making the
If there are multiple elements on the page (e.g. multiple inline video
players) that could go fullscreen, you still need some way to determine
which of them the user intended to make fullscreen. My understanding is
that was the point of designating a fullscreen element - it still requires
that
On Fri, 06 Aug 2010 00:17:54 +0200, Simon Fraser s...@me.com wrote:
or have some constants for behavior:
const unsigned short ALLOW_KEYBOARD_INPUT = 1;
void requestFullScreen(unsigned short behavior)
This would be extensible, and would allow us to permit other
behaviors later.
Can't
Kudos to Mozilla (and Robert?). This is awesome. It does appear that you plan
to allow fullscreen without the use of a user-trigggered event such as a
button-click like Flash does. Not only would I like to launch my app in
fullscreen to play a game, I may want to allow my advertisers to launch
On Aug 5, 2010, at 9:24 PM, Robert O'Callahan wrote:
It's probably worth having such an event, but there will be times when
neither fullscreendenied or fullscreenchanged are fired. I hope authors don't
write apps that break in such cases.
We definitely need some sort of event to indicate
On Sat, Aug 7, 2010 at 1:39 AM, Mike Wilcox m...@mikewilcox.net wrote:
Kudos to Mozilla (and Robert?). This is awesome. It does appear that you
plan to allow fullscreen without the use of a user-trigggered event such as
a button-click like Flash does.
The proposed spec allows that, but I
On Sat, Aug 7, 2010 at 1:57 AM, Mike Wilcox m...@mikewilcox.net wrote:
Regarding fullscreen elements: I appreciate the initiative, but I wonder if
it's necessary to allow fullscreen at the element level?
It's not necessary, but it's a very useful convenience. It also allows the
UA to perform
This is feedback on the Mozilla FullScreen API proposal here:
https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI
The user agent may transition a Document into or out of the
fullscreen state at any time, whether or not script has requested
it. User agents are encouraged to provide
On Fri, Aug 6, 2010 at 10:17 AM, Simon Fraser s...@me.com wrote:
This is feedback on the Mozilla FullScreen API proposal here:
https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI
The user agent may transition a Document into or out of the
fullscreen state at any time, whether or
On Aug 5, 2010, at 5:56 PM, Robert O'Callahan wrote:
On Fri, Aug 6, 2010 at 10:17 AM, Simon Fraser s...@me.com wrote:
This is feedback on the Mozilla FullScreen API proposal here:
https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI
The user agent may transition a Document into or
On Fri, Aug 6, 2010 at 1:37 PM, Simon Fraser s...@me.com wrote:
On Aug 5, 2010, at 5:56 PM, Robert O'Callahan wrote:
On Fri, Aug 6, 2010 at 10:17 AM, Simon Fraser s...@me.com wrote:
* void cancelFullScreen()
I think exit would be better than cancel.
The only problem with exit is that
13 matches
Mail list logo
