I wrote a long blog post about a few months ago about the perils of using fullscreen in modern browsers: http://sorcery.smugmug.com/2012/06/06/using-html5s-fullscree..., which is cited as a reference (awesome!). This explains why some of the code looks similar, I'm glad it was helpful.
This library could use error detection and handling as there are situations where fullscreen could be aborted or fail to start.
It's much better to attempt going fullscreen and have callbacks for errors and successfully entering fullscreen mode. Users can have preferences set to not allow it, press ESC during the transition or a number of other scenarios can occur.
There's also some CSS fixes between browsers that could be included. Safari and Chrome don't stretch the element to 100% monitor width and don't apply a background color by default so you can see 'through' the fullscreen window.
That being said it's good someone is working towards something that's relatively cross-browser. The fullscreen API right now is extremely varied but a really awesome tool for advanced web apps.
To clarify I mean a onerror callback would be nice to have if something goes wrong when attempting to go fullscreen. If I have some time I'll write a patch!
I actually really like that way of doing it, but I don't think it would work well for what I was trying to do with BigScreen, mainly for the video fallback behavior. When browsers do drop the prefixes, part of the functionality wouldn't exist anymore.
It does way more normalizing than just the name of the function. It works around a number of bugs when the element is in an iframe, and it has a fallback if you're using it for video (which was the main reason I wrote it).
Does anyone know of a way to fix the problem when getting out of a fullscreen page in Chrome for Mac? Normally, when trying to exit fullscreen page when the browser is already maximized, it gets thrown out of its workspace - a minor annoyance, but it's irksome enough that I try to avoid using HTML5 fullscreen in web pages.
As far as I can tell that's a mistake. At least that page is perfectly clean, but now I don't necessarily want to go hunting around to see why it was classified like that ;)
[+] [-] rdoherty|13 years ago|reply
This library could use error detection and handling as there are situations where fullscreen could be aborted or fail to start.
It's much better to attempt going fullscreen and have callbacks for errors and successfully entering fullscreen mode. Users can have preferences set to not allow it, press ESC during the transition or a number of other scenarios can occur.
There's also some CSS fixes between browsers that could be included. Safari and Chrome don't stretch the element to 100% monitor width and don't apply a background color by default so you can see 'through' the fullscreen window.
That being said it's good someone is working towards something that's relatively cross-browser. The fullscreen API right now is extremely varied but a really awesome tool for advanced web apps.
[+] [-] rdoherty|13 years ago|reply
[+] [-] cpearce|13 years ago|reply
It's good because it shims the W3C specified fullscreen API; you only have to learn the specified API, you don't have to learn some other API.
[+] [-] bdougherty|13 years ago|reply
[+] [-] bdougherty|13 years ago|reply
[+] [-] mofle|13 years ago|reply
https://github.com/bdougherty/BigScreen/blob/master/bigscree... https://github.com/sindresorhus/screenfull.js/blob/master/sr...
[+] [-] paulrouget|13 years ago|reply
[+] [-] garindra|13 years ago|reply
[+] [-] MatthewPhillips|13 years ago|reply
[+] [-] bdougherty|13 years ago|reply
[+] [-] duckfruit|13 years ago|reply
[+] [-] eblume|13 years ago|reply
[+] [-] andrewmunsell|13 years ago|reply
[+] [-] bdougherty|13 years ago|reply
[+] [-] wheelerwj|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] unknown|13 years ago|reply
[deleted]