3 ms·
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-full
by rdoherty 14y ago
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-fullscreen-api-for-fun-and-profit/ 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.
- rdoherty 14y agoTo 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!
- bdougherty 14y agoMy bad! There is a BigScreen.onerror, but I missed it in the docs. It should cover most things, but I didn't fully test it. I also couldn't get any browser to fire the native event in my testing.
- rdoherty 14y agoI think you can get it to fire if you trigger requestFullscreen outside of a user-initiated event? I'll have to check on that.