Fini donc le temps où votre site restait prisonnier de son canvas en 800×600, maintenant votre dernière application de calcul de budget de croquettes pour hérisson peut enfin s’exprimer dans toute la hauteur et la largeur d’un écran Retanal grâce à requestFullscreen(), qui va vous permettre … d’appuyer sur F11 à la place de l’utilisateur.

Mais il aura à faire un clic de confirmation quand même. Car il aura un gros prompt bien alarmant avant. Le progrès je vous dis !

Le code, en 2 / 2

Parce que bien entendu c’est incompatible avec les tondeuses à gazons et que selon les marques de votre pétrolettes, le prefix ne sera pas le même, on va commencer par vérifier le support du bouzin.

function supportFullScreen(){
    var doc = document.documentElement;
    return ('requestFullscreen' in doc) || ('mozRequestFullScreen' in doc && document.mozFullScreenEnabled) || ('webkitRequestFullScreen' in doc);
}

Puis on va demander à l’utilisateur si on a le droit, s’il-te-plait-pitié-déconne-pas-putain, de mettre votre site en plein écran. Car figurez vous qu’il y a un sérieux risque de phishing, comme en voici la démonstration rigolote.

function requestFullScreen(elem){
    if (elem.requestFullscreen) {
        elem.requestFullscreen();
    } else if (elem.mozRequestFullScreen) {
        elem.mozRequestFullScreen();
    } else if (elem.webkitRequestFullScreen) {
        elem.webkitRequestFullScreen();
    }
}

Ca s’utilise ainsi:

requestFullScreen(document.body)

A ce moment là l’écran de le navigateur passe en plein écran avec un gros panel d’avertissement genre “le certificat du site est invalide”, mais en gris. Et si l’utilisateur lit le message avant de se ruer sur le bouton “annuler” par réflexe, il s’apercevra qu’on lui explique ce qui se passe pour pas qu’il finisse de mourir de sa crise cardiaque.

Vous pouvez utiliser n’importe quel autre élément que body, et donc mettre en plein écran de tout petit widgets. Attention cependant, il va prendre la taille de tout l’écran, déclenchant tout un tas d’events de changement de taille, de display, changeant les overflows et gagnant un style par défaut qui sera différent selon le navigateur. Le W3C a un deal avec les browser vendors pour s’assurer que les devs Web ne soient jamais prêt d’être au chômage.

Passons.

Le problème quand on demande, c’est qu’on peut se voir répondre “non”. Donc en prime, il vaut mieux se concocter un fallback si jamais mémé s’affole devant la menace de voir ses onglets avalés par le viewport. Ici, je vous pond ça en jQuery, parceque la gestion des events à la main, c’est juste relou.

function onFullScreenEvent(callback){
    $(document).live("fullscreenchange mozfullscreenchange webkitfullscreenchange", function(){
        callback(document.fullscreen || document.mozFullScreen || document.webkitIsFullScreen);
    });
}

Bon, normalement on utilise ‘on()’ maintenant chez les gens branchés, mais j’arrive à le faire marche une fois sur deux. Donc ça s’utilise comme ça:

onFullScreenEvent(function(isFullscreen){
    faire un truc selon que l'on est en fullscreen ou pas, comme pousser mémé dans les orties
});

Clusions ensemble entre cons

Et voilà, vous avez une application fullscreenable. Il ne vous reste plus rien à faire. A part rajouter un bouton pour le permettre à l’utilisateur de mettre en fullscreen. Puis un autre pour sortir du fullscreen. Puis de gérer la transition des états de votre app. Les différences de rendu selon la taille des éléments et du style par défaut appliqué par le navigateur. Et bien entendu le plus dur: faire comprendre tout ce bordel à votre utilisateur final.

Plus rien à faire je vous dis: on vous a mâché le travail.

Si vous avez pas le temps, vous pouvez aussi mettre alert('appuyez sur F11 pour passer en plein écran'). Mais bon, j’écrirais des articles sur quoi moi après ?