<input type="number" />

Et là, le navigateur ne vous laisse saisir que des nombres, sans avoir à coder de JS. Mieux, les machines avec claviers virtuels (téléphones, tablettes, etc) affichent généralement un clavier spécial qui permet de saisir facilement des nombres.

Seulement dernièrement, il y a une nouvelle tendance, certains navigateurs affichent aussi des boutons pour incrémenter et décrémenter le champ.

Ça vous bousille tout votre design car c’est inconsistant selon selon les navs, et en plus ces spin buttons sont inutilisables sur mobiles car bien trop petits.

C’est quoi déjà les pas de la salsa ? Un pas en avant, un pas sur place, un pas en arrière, un pas sur place ?

Bref, j’ai d’abord essayé d’appliquer une solution CSSisante :

input[type=number]::-webkit-inner-spin-button,
input[type=number]::-webkit-outer-spin-button {
    -webkit-appearance: none;
    margin: 0;
}
 
input[type=number]{
    -moz-appearance:textfield;
}

Mais bien entendu ça ne marche pas partout, partout. Ça serait trop facile.

En bon dev Web, j’ai du coup utilisé un contournement tout pourri, c’est la marque de fabrique du métier :

<input type="tel" />

Le browser considère ainsi qu’il s’agit d’un numéro de téléphone. Il check donc si c’est un numéro (ou quelques signes comme “.”, “-“, etc, mais c’est acceptable) et fait apparaitre un clavier virtuel presque similaire au clavier pour type=number.

“On s’en contentera”, la devise de notre profession.

server {
        listen       80;
        server_name allthatcounts.net;

        error_log  /var/log/nginx/error_allthatcounts.log;
        access_log  /var/log/nginx/access_allthatcounts.log;

        location / {
            root /home/allthatcounts/www/;
            gzip  on;
            gzip_http_version 1.0;
            gzip_vary on;
            gzip_comp_level 6;
            gzip_proxied any;
            gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
            gzip_buffers 16 8k;
            gzip_disable ~@~\MSIE [1-6].(?!.*SV1)~@~];
            expires modified +90d;
        }
}

En gros c’est juste du log et servir les fichiers statiques compressés avec gzip. Il n’y a rien de plus à faire parce qu’il n’y a pas de backend. Simple. Efficace.

La couille c’est que c’est un copier / coller d’un autre projet que j’ai fais sans trop réfléchir, et quand j’ai mis en prod de nouvelles modifications sur le serveurs, mon Firefox me les affichait pas. Pourtant j’avais bien modifié le manifeste, donc il aurait du tout recharcher…

Sauf que, con de ma race, j’ai copié la ligne :

expires modified +90d;

Qui dit techniquement, met en cache tous les fichiers statiques pour 90 jours. Donc aussi le manifeste. Du coup, toutes les personnes qui ont visité le site ne verront aucune mise à jour pour un bon mois et demi.

Bravo Sam.

Je me tâte à faire une rubrique “jeu” d’ailleurs, pour introduire un jeu de plateau de temps en temps.

Évidement, à force de parties, on commence à en avoir plein le cul d’attendre le tour de l’autre, donc on joue au chrono. On a tenté le sablier, la montre, le portable, l’app, et rien n’est vraiment satisfaisant.

Que fait un programmeur dans ce cas ? Il réinvente la roue, bien sûr !

Voici donc All That Counts, une Web app qui contient :

• Des timers.
• Des chronos.
• Des compteurs de points.

C’est du HTML5 + Javascript, il n’y a pas de backend. Est inclus un mode offline, donc il suffit de visiter l’app une fois pour pouvoir toujours l’utiliser sauf vidange du cache. Magie de Bootstrap, ça marche sur mobile, tablette et destop. Comprendre : design responsive générique.

Sur les navs supportant l’élément audio, ça gong à la fin des timers.

La page “Count Down” est pratique pour faire sa gym, cuire ses œufs et organiser une partie avec des tours limités dans le temps pour 3 joueurs ou plus. Les widgets incluent le temps de dépassement si on a besoin de mettre des pénalités aux escargots et aux stallers.

La partie “Chrono”, c’est gadget pour moi, mais ça pourra peut être servir à certains. J’y ai collé la possibilité de cumuler des temps de tours, pour les sportifs. Je ne sais pas si c’est utile, les coureurs me diront. A la limite pour les concours d’apnée…

L’onglet “Counter” c’est pour compter les points quand on a pas de papier ou de jeton, c’est du dépannage. Ça peut servir aussi pour les gens dont le métier implique de compter des têtes de pipe comme les videurs, les hôtesses de l’air, etc.

Ce qu’on utilise le plus est le mode “Versus”, qui sert aux duels. C’est une sorte de pendule d’échecs, avec plusieurs comportements réglables. Par défaut, le passage d’un décompte à l’autre se fait automatiquement et manuellement, chaque changement de joueur impliquant une remise à zéro.

Comme il n’y a pas de backend, vous pouvez avoir le code source en faisant Ctrl + S, donc je vais pas vraiment me faire chier à le mettre sur github. Déjà, j’ai du codé en pur JS. Moi. Heureusement qu’il y a AngularJS, sinon je changeais de métier. Le déploiement, pareil, c’est Ctrl + C, Ctrl + V, donc je vais pas écrire de doc. L’utilisation, bon, c’est des clics sur des boutons labellisés…

Le code source est dispo sur github.

La seule astuce, c’est qu’en mode versus, CTRL permet de faire un switch, et SPACE permet de faire pause et resume. Je pense que vous vous en sortirez. C’est un compteur, pas une navette spatiale.

Si l’envie incroyable de rajouter des features vous prend, mettez un comment, et je me bougerais le cul pour githuber tout ça.

Mais pour les sites Web ou les apps simples, il est super intéressant d’exploiter les capacités HTLM5 au max pour une obtenir une expérience plus “app” et moins “site web”.

Parmi ces possibilités : le mode hors ligne. D’un côté, il y a le stockage des données dans le navigateur, mais on vous en a déjà parlé.

De l’autre, il y a le cache des ressources. Cela consiste à déclarer quels fichiers (html, css, js, images, fonts, n’importe quoi…) garder en mémoire afin de les charger directement depuis le disque dur au lieu de le faire en ligne.

Pour cela, il faut déclarer un manifeste dans son HTML :

<html manifest="cache.manifest">

Ensuite, on créer le fichier cache.manifest dans son projet, qui est un fichier de texte simple.

Il faut le faire servir avec le mime-type

text/cache-manifest

sinon ça ne marche pas. Si vous le nommez

*.manifest

et que vous le servez avec un serveur de dev, ça marchera tout seul. Pour la prod, il faut le spécifier à votre serveur. Par exemple avec nginx, il faut éditer le fichier /etc/nginx/mime.types et y ajouter :

text/cache-manifest                   manifest;

Pour apache, c’est un truc du genre dans le .htaccess:

AddType text/cache-manifest .manifest

Ensuite, le manifeste ressemble à ça :

CACHE MANIFEST
# 2014-04-20 13:25:00

# Toutes les ressources à sauvegarder en local. Le navigateur
# va toujours chercher ces ressources sur le disque.
# Si on est déconnecté, la page index.html, ses styles et javascript
# s'afficheront donc quand même.
CACHE:
index.html
/favicon.ico
stylesheet.css
images/logo.png
scripts/main.js
fonts/font.woff

# Ressources à toujours charger depuis le réseau. On met ici
# une étoile pour dire "tout le reste". Si on ne fait pas ça,
# on va se retrouver sans css et js :)
NETWORK:
*

# Ressources alternatives si les précédentes sont inacessibles.
# Par exemple, pour afficher un point rouge si on est hors ligne
# et un point vert si on est en ligne :
# images/offline.png sera servi si images/online.png est inaccessible
FALLBACK:
images/online.png images/offline.png

Notez le commentaire # 2014-04-20 13:25:00 tout en haut. C’est
une convention qu’on utilise pour donner la dernière date de modification des
fichiers cachés. En effet, les fichiers de la section CACHE ne seront
pas rechargés tant que le manifeste n’a pas été modifié.

Cela veut dire que si vous modifiez index.html, l’utilisateur
ne verra pas la modification. Mais si vous changez la date du fichier manifeste,
le fichier est modifié, et le navigateur rechargera donc toutes les ressources
qu’il a mis en cache. Ainsi, vous permettez aux utilisateurs de voir les
ressources cachées qui ont été modifiées.

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 ?