W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] Feedback on the Mozilla FullScreen API proposal

From: Mike Wilcox <mike@mikewilcox.net>
Date: Fri, 6 Aug 2010 08:57:05 -0500
Message-ID: <D79EB550-8C2C-4FBA-BBE7-8C8F611CC2BA@mikewilcox.net>

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 if fullscreen was successful or not ? not so that our apps don't break, but so we can notify the user of failed functionality. Even a status property is insufficient as it will force us to use a setInterval which seems hacky. And preferably, it would be good to know the reason for the denial:

onFullscreenDenied = function(status){
	if(status=="blocked by browser"){
		alert("You need to change your browser's settings to use fullscreen mode.");
	}else if(status=="blocked by page"){
		disableMyFullScreenButton();		
		alert("Sorry, fullscreen is not available.");
	}
}


Regarding fullscreen elements: I appreciate the initiative, but I wonder if it's necessary to allow fullscreen at the element level? I think Simon is already pointing out potential gotchas. What exactly is the difference between a fullscreen-element and a fullscreen-page that has an element in absolutely position, top z-index, at 100% width and height? As a developer, after entering fullscreen I could possibly do a fancy transition of the element to take up 100%. I have to assume this is what the UA would be doing in the background anyway in order to keep the proper x/y coordinates.


Mike Wilcox
Received on Friday, 6 August 2010 06:57:05 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:59 UTC