J'ai lu l'article en diagonale et je trouve qu'il parle un peu plus que "juste le HTML".
L'auteur aborde notamment quelques avantages que présente le typage number d'une balise input HTML pour certaines catégories d'utilisateurs (les gens qui utilisent des lecteurs d'écran par exemple, donc les gens qui typiquement ont déjà des difficultés pour remplir un formulaire) ou pour certains usages (clavier numérique sur des terminaux de type smartphone, gain de temps pour la saisie au niveau de l'utilisateur). C'est pas rien quand même, car ces usages et situations sont à prendre en considération si le typage number peut faciliter ces interactions homme(s)-machine.
Il me semble que l'auteur se plaint surtout des différences d'implémentation du typage number dans les différents navigateurs, qui rend difficile le traitement de l'input. Il semble préférer utiliser d'autres typages d'input que number. Par exemple, il cite l'article du gouvernement UK qui conseille l'usage d'un typage de l'input en texte, accompagné par une expression rationnelle de type [0-9]*. Pourquoi pas, mais il faut voir ce que le dev' y gagne et surtout ce que l'utilisateur y perds au passage.
L'auteur semble également préférer les méthodes basées sur javascript pour (pré-)valider et interagir avec l'usager du formulaire, pourquoi pas. Il dresse un tableau des données qui peuvent arriver dans un input typé number : des nombres négatifs, positifs, en notation scientifique (exponentielle),... À mes yeux, son tableau me semble bien incomplet, il oublie les langues dans lesquelles on mets une virgule pour séparer les décimales, celles où l'on mets un point, les langues dans lesquelles on sépare d'un espace les milliers des centaines et toutes ces conventions d'écriture parfaitement valables mais qui rendent un traitement par javascript particulièrement hasardeux si le dev' n'y prête pas garde. Sans parler des abruti(e)s dans mon genre qui vont remplir le champs du formulaire en hexadécimal, pour voir si ça passe. Et si le javascript du dev' est mal foutu, c'est l'utilisateur du formulaire qui finira par faire un rage quit. (commentaire acerbe : le dev' s'en fout parce que lui, ça lui fait gagner sa vie de pondre des javascripts tout pourris).
Et puis, j'y vois toujours un danger à ces javascripts qui tentent de contraindre mes saisies dans un formulaire. J'ai parfois l'impression que les dev' oublient que le code javascript qu'ils exécutent, ils l’exécutent dans mon navigateur, sur mon ordinateur et que jusqu'à preuve du contraire, c'est pas du tout un environnement de traitement sécurisé pour eux... Ils sont en environnement hostile et si me prends l'envie de leur envoyer de la merde à la place du bel input qu'ils s'attendent à recevoir, j'espère qu'ils ont bien prévu le coup de leur côté. La base, quoi.
Au final, ce qui ressort de cet article pour moi, c'est que le typage number est bien trop imprécis et mal spécifié pour être directement utilisable sans soucis par les dev'. En même temps, imaginez un monde sans float, sans long et toutes ces subtilités, les dev' système feraient un peu la tronche, non ?
Mais, quand une "norme" est mal spécifiée, on ne la jette pas à la poubelle, ça serait jeter le bébé avec l'eau du bain en prétendant qu'on va faire autrement dans notre petit coin. Non, on l'améliore, on la rends fonctionnelle parce qu'au final, c'est l'usager qui est gagnant et c'est grâce à ce point précis que l'informatique a réussi à conquérir le monde.
"C'est ainsi que nous gagnons" (citation du livre Les oiseaux du temps d'Amal El-Mohtar & Max Gladstone).
[^] # Re: Juste le html
Posté par Glaeken (site web personnel) . En réponse au lien Why the number input is the worst input. Évalué à 10.
J'ai lu l'article en diagonale et je trouve qu'il parle un peu plus que "juste le HTML".
L'auteur aborde notamment quelques avantages que présente le typage number d'une balise input HTML pour certaines catégories d'utilisateurs (les gens qui utilisent des lecteurs d'écran par exemple, donc les gens qui typiquement ont déjà des difficultés pour remplir un formulaire) ou pour certains usages (clavier numérique sur des terminaux de type smartphone, gain de temps pour la saisie au niveau de l'utilisateur). C'est pas rien quand même, car ces usages et situations sont à prendre en considération si le typage number peut faciliter ces interactions homme(s)-machine.
Il me semble que l'auteur se plaint surtout des différences d'implémentation du typage number dans les différents navigateurs, qui rend difficile le traitement de l'input. Il semble préférer utiliser d'autres typages d'input que number. Par exemple, il cite l'article du gouvernement UK qui conseille l'usage d'un typage de l'input en texte, accompagné par une expression rationnelle de type [0-9]*. Pourquoi pas, mais il faut voir ce que le dev' y gagne et surtout ce que l'utilisateur y perds au passage.
L'auteur semble également préférer les méthodes basées sur javascript pour (pré-)valider et interagir avec l'usager du formulaire, pourquoi pas. Il dresse un tableau des données qui peuvent arriver dans un input typé number : des nombres négatifs, positifs, en notation scientifique (exponentielle),... À mes yeux, son tableau me semble bien incomplet, il oublie les langues dans lesquelles on mets une virgule pour séparer les décimales, celles où l'on mets un point, les langues dans lesquelles on sépare d'un espace les milliers des centaines et toutes ces conventions d'écriture parfaitement valables mais qui rendent un traitement par javascript particulièrement hasardeux si le dev' n'y prête pas garde. Sans parler des abruti(e)s dans mon genre qui vont remplir le champs du formulaire en hexadécimal, pour voir si ça passe. Et si le javascript du dev' est mal foutu, c'est l'utilisateur du formulaire qui finira par faire un rage quit. (commentaire acerbe : le dev' s'en fout parce que lui, ça lui fait gagner sa vie de pondre des javascripts tout pourris).
Et puis, j'y vois toujours un danger à ces javascripts qui tentent de contraindre mes saisies dans un formulaire. J'ai parfois l'impression que les dev' oublient que le code javascript qu'ils exécutent, ils l’exécutent dans mon navigateur, sur mon ordinateur et que jusqu'à preuve du contraire, c'est pas du tout un environnement de traitement sécurisé pour eux... Ils sont en environnement hostile et si me prends l'envie de leur envoyer de la merde à la place du bel input qu'ils s'attendent à recevoir, j'espère qu'ils ont bien prévu le coup de leur côté. La base, quoi.
Au final, ce qui ressort de cet article pour moi, c'est que le typage number est bien trop imprécis et mal spécifié pour être directement utilisable sans soucis par les dev'. En même temps, imaginez un monde sans float, sans long et toutes ces subtilités, les dev' système feraient un peu la tronche, non ?
Mais, quand une "norme" est mal spécifiée, on ne la jette pas à la poubelle, ça serait jeter le bébé avec l'eau du bain en prétendant qu'on va faire autrement dans notre petit coin. Non, on l'améliore, on la rends fonctionnelle parce qu'au final, c'est l'usager qui est gagnant et c'est grâce à ce point précis que l'informatique a réussi à conquérir le monde.
"C'est ainsi que nous gagnons" (citation du livre Les oiseaux du temps d'Amal El-Mohtar & Max Gladstone).