Il y a quelques mois j’ai publié un outil pour calculer une addi­tion en terme de tickets resto (le post de l’époque est ici). Je sais, rien ne m’ar­rête. Voici une mise à jour, avec notam­ment des visuels plus travaillés, ainsi qu’un clavier sur mesure et toujours présent à l’écran.

Vous pouvez le charger ci-dessous en cliquant sur le screen­shot ou l’ou­vrir depuis votre ordi­phone préféré.

Pourquoi un thème sombre ?

Parce que c’est repo­sant pour les yeux, surtout quand l’arrière-plan est très présent, comme ici, et que mon télé­phone et son OS (Moto G et Android vanillé) sont déjà sombres.

Pourquoi un clavier sur mesure ?

Se limiter à ce que fournit l’OS oblige à utiliser :

• sur iOS, un clavier pensé pour la saisie de numéros de télé­phone, donc pas top
• Sur Windows Phone et Android, un clavier plus adapté, sans carac­tères inutiles et avec un sépa­ra­teur décimal. Malgré cela je n’aime pas trop leur dispo­si­tion (voir plus bas).

De plus, le clavier natif appa­rait à l’appui sur un champ. C’est bien dans une page complexe, mais ici il est plus perti­nent d’avoir une mise en page sans scroll, avec les champs fixes et le clavier toujours présent.

Enfin, pour utiliser le clavier numé­rique natif, il faut que l’élé­ment <input> soit de type number. Ca pose certaines contraintes, car l’API a été pensée pour un contrôle de vali­dité dyna­mique mais après coup : c’est seule­ment quand l’uti­li­sa­teur sort du champ que le champ signale l’er­reur, par exemple s’il a saisi des lettres au lieu de chiffre. Ca rend diffi­cile le contrôle a priori que je voulais, puis­qu’on n’a aucun accès program­ma­tique au texte inva­lide d’un champ (value devient vide). De plus, une valeur du genre « 10, » est consi­dérée comme inva­lide, alors qu’il faudrait qu’elle corres­ponde à un état « en cours de saisie », comme c’est le cas dans les bonnes biblio­thèques de gestion des masques de saisie.

Ajoutons qu’en fran­çais le sépa­ra­teur décimal correct est la virgule mais certains navi­ga­teurs (Firefox Mobile) ne le loca­lisent pas correc­te­ment.

C’est pas une mauvaise pratique de réinventer des comportements natifs ?

Totalement. C’était juste­ment instructif pour moi de voir le nombre de choses qu’il faut réim­plé­menter comme on peut. Le chemi­ne­ment a ressemblé à ça :

1. Je ne voulais pas du clavier, alors qu’il appa­rait par défaut, un compor­te­ment théo­ri­que­ment non modi­fiable.
2. Du coup, on triche en faisant perdre le focus à un champ dès qu’il le gagne.
3. Du coup, il faut en garder en mémoire quel champ on a sélec­tionné. Un focus custom, quoi. Il faut égale­ment recréer un curseur et le placer au bon endroit.
4. Ah merde, il faut calculer à la main la posi­tion du curseur.
5. Et bien sûr ça oblige de bidouiller pour obtenir la largeur d’un carac­tère (l’unité ch aurait été parfaite mais Chrome ne la supporte pas). Donc l’outil ne marche qu’avec des polices à chasse fixe (mono­space).

Je vous passe les subtiles diffé­rences de compor­te­ment entre navi­ga­teurs, notam­ment dans la gestion des évène­ments focus et click. Bref, le tout marche mais n’est pas ultra robuste ni fran­che­ment réactif et le code est sans doute encore moins propre et modu­laire que la dernière fois.

Pourquoi cette disposition de clavier ?

Vu qu’on est dans la saisie de monnaie je me suis rapproché de la conven­tion des calcu­lettes, avec le 9 en haut à droite. En plus, la progres­sion des chiffres du bas vers le haut suit le mouve­ment de la main ou du doigt propre au mobile.