Developpez.com - Rubrique JavaScript

Le Club des Développeurs et IT Pro

Mask.js : valider vos champs HTML numériques, dates et textuels à chaque touche frappée

à ne pas confondre avec le HTML5

Le 2014-12-11 12:35:45, par vermine, Expert éminent sénior
Mask.js : valider vos champs numériques, dates et textuels à chaque touche frappée
A ne pas confondre avec le HTML5

Mask.js est une bibliothèque JavaScript qui permet de valider des champs HTML input selon un masque de type date, numérique ou texte. Le but est d'empêcher l'entrée de caractères non valides lorsqu'ils sont tapés.

Exemple de code :

Code javascript : 
1
2
3
4
5
6
Mask.newMask({ 
	$el: $('input.name'), 
	mask: 'HH:mm', 
	errorFunction: function() {}, 
	defaultValue: '12:00' 
});

Comme ce code le laisse sugérer, la bibliothèque est dépendante de jQuery.

En voici quelques caractéristiques :

  • vous pouvez préciser un nombre de caractères à ne pas dépasser ;
  • la gestion des dates comprend également les années bissextiles et les dates incorrectes ;
  • vous pouvez utiliser une fonction personnalisée pour gérer les entrées non valides ;
  • la validation se fait au fur et à mesure que vous encodez.


Cette bibliothèque fait un travail différent que ce qu'offre le HTML5 avec ses nouveaux types de champs. Effectivement, ici nous parlons bien de masque de saisie (légèrement) paramétrable avec la possibilité de gérer les erreurs de manière personnalisée.

Site de Mask.js.
D'après un article sur DailyJS.

Et vous ?

Que pensez-vous de ce genre d'outils à l'heure actuelle ?
En connaissez-vous d'autres et lesquels conseillez-vous ?
  Discussion forum
19 commentaires
  • SylvainPV
    Rédacteur/Modérateur
    Envoyé par Tarh_
    Justement, la norme est insuffisante :

    • Impossible de localiser dans la langue du site, la localisation dépend de la configuration du navigateur, ce qui n'a aucun sens ;
    • Impossible d'afficher correctement un nombre à la manière française avec des espaces pour séparer les milliers ;
    • Les petites flèches pour incrémenter ou décrémenter un nombre sont hors sujet lorsqu'il s'agit de saisir des grands nombres…

    Pourquoi ça n'a aucun sens de localiser dans la langue de l'utilisateur ? C'est pourtant lui qui est devant l'écran et doit saisir la date... qui sera récupéré avec un format standard côté JS ou serveur de toute manière. Quant aux flèches pour incrémenter, c'est juste un petit plus par rapport à la saisie directe du nombre, tout comme un input text en somme.

    Les date input sont l'inverse de la rigidité, puisqu'ils s'adaptent automatiquement au terminal et à l'utilisateur. Aucun module JS ne peut rivaliser avec ça :


    Ce n'est pas au développeur de décider de la langue ou de personnaliser l'interface de ces boîtes de saisie, ça c'était valable il y a 5 ou 10 ans mais aujourd'hui le développeur n'est pas en mesure d'appréhender tous les contextes d'utilisation de son site.
    le 12/12/2014 à 14:24
  • SylvainPV
    Rédacteur/Modérateur
    Quel dommage qu'ils ne mettent pas à profit le type date et time des input en HTML5... Timezone, format local, datepicker/timepicker optimisé pour chaque terminal, on a tout à y gagner.

    Cette bibliothèque fait un travail différent que ce qu'offre le HTML5 avec ses nouveaux types de champs. Effectivement, ici nous parlons bien de masque de saisie (légèrement) paramétrable avec la possibilité de gérer les erreurs de manière personnalisée.



    HTML5 et la Constraint Validation API fournissent pourtant tout ce qu'il faut pour ça : attribut pattern, propriété willValidate, évènement invalid...
    le 11/12/2014 à 16:23
  • vermine
    Expert éminent sénior
    Oui c'est dommage de ne pas repartir des projets existants et d'apporter des améliorations notoires. Quoiqu'il en soit, ça reste utile sur les navigateurs qui ne supportent pas encore le HTML5. Mais bon, c'est sans doute dérisoire.
    le 11/12/2014 à 16:31
  • SylvainPV
    Rédacteur/Modérateur
    Justement, j'aurais trouvé bien plus compréhensible la démarche d'en faire un polyfill et de reposer sur la spec actuelle HTML5, afin de bâtir sur l'avenir le présent. Même s'il est vrai qu'IE et Firefox traînent la patte sur l'intégration des types date et time, à mon grand désarroi. D'ailleurs si vous voulez donner un petit coup de pouce, ajoutez-vous en CC des rapports de bugs tels que celui-ci : https://bugzilla.mozilla.org/show_bu....cgi?id=825294 ; plus il y a de monde au portillon, plus on a de chances de voir la fonctionnalité intégrée rapidement.
    le 11/12/2014 à 18:48
  • Paleo
    Membre éclairé
    Envoyé par SylvainPV
    Quel dommage qu'ils ne mettent pas à profit le type date et time des input en HTML5... Timezone, format local
    Justement, la norme est insuffisante :

    • Impossible de localiser dans la langue du site, la localisation dépend de la configuration du navigateur, ce qui n'a aucun sens ;
    • Impossible d'afficher correctement un nombre à la manière française avec des espaces pour séparer les milliers ;
    • Les petites flèches pour incrémenter ou décrémenter un nombre sont hors sujet lorsqu'il s'agit de saisir des grands nombres…


    Bref, la norme est mal pensée, la solution est de formater en JavaScript un <input> de type "text". Cela dit, je n'ai pas l'impression que Maskjs fasse l'affaire pour les valeurs numériques françaises. Et puis on peut s'étonner de l'utilisation de jQuery pour un besoin aussi simple.
    le 12/12/2014 à 10:07
  • Zefling
    Expert confirmé
    Envoyé par SylvainPV
    Ce n'est pas au développeur de décider de la langue ou de personnaliser l'interface de ces boîtes de saisie, ça c'était valable il y a 5 ou 10 ans mais aujourd'hui le développeur n'est pas en mesure d'appréhender tous les contextes d'utilisation de son site.
    Je suis sur un navigateur en français et que je demande à avoir mon site en japonais, je ne m'attends pas avoir un formatage en français. Je dis ça parce que copier des dates japonaises dans une interface de site en japonais avec un seul champ date en français, c'est juste trop chiant : 2012/12/12 -> 12/12/2012. De plus, ça ne permet d'avoir de parties facultatives : si j'écris 12/2012 (je ne connais pas le jour) ou 2012 (je ne connais que l'année) ou 12/12 (je ne connais pas l'année), ça me dira que c'est faux, alors que je veux l'autoriser. J'ai fini par coder mon datepicker, c'était plus simple de gérer comme ça.

    Ce n'est peut-être pas au dév de le faire, mais quand il a pas la possibilité de faire ce qu'il faut, il faut comme il peut.
    le 12/12/2014 à 17:20
  • SylvainPV
    Rédacteur/Modérateur
    Si ton navigateur est en français, c'est que tu connais le français et que tu peux parfaitement saisir une date avec la localisation française. Pour le site web, ça ne changera rien puisqu'en amont toutes les dates sont au format anglais YYYY-MM-DD.

    Pour l'histoire des parties facultatives, si tu veux juste renseigner le mois, il y a type="month":


    Enfin s'il y a d'autres comportements particuliers à définir, on peut pourquoi pas surcharger en JavaScript. Mais la surcharge devrait se faire sur le bon élément de base sémantiquement parlant, c'est-à-dire un type date et pas un type text. De la même façon qu'en HTML5 on n'utilise pas de <div> partout sous prétexte que c'est plus facile à styliser.
    le 13/12/2014 à 0:32
  • Zefling
    Expert confirmé
    Je n’étais pas au courant que je pouvais faire ça type="date, month, number" pour gérer sur un même champ les trois possibilités (12/12/2012, 12/2012 & 2012). Il n'y a rien dans la norme pour rendre facultatif le jour, le mois ou l'année.

    C'est pareil pour type="number". On peut définir un max et min, un step (genre 0.01), mais j'aimerais que celui des flèches change et soit un pas de 1 et non de 0.01. Le problème est qu'il est impossible de décolérer le pas de la précision autorisée.

    Il y a aussi le champ type="url" qui n’autorise que des liens complets « http:// », impossible de lui autoriser une adresse relative.

    Quand je suis dans ces cas-là, les éléments HTML5 sont plus une contrainte qu'un avantage. Je ne les utilise que si ça rendre dans ce que je fais. Et je suis désolé, mais pour le champ, je les rentre plus souvent à la main au clavier qu'en ne passant pas le widget de date (surtout quand la date c'est 50 ans en arrière). Aussi, quand je dois copier une liste de date en japonais, je n’ai pas spécialement envie de les réécrire en français parce que mon document de base est en japonais. Quand je suis en japonais, je veux que tout soit en japonais.

    Les champs HTML5 sont parfaits pour de petits formulaires prévus pour les mobiles ou le tactile. Pour les gros formulaires pas du tout adaptés au mobile ou au tactile, je ne leur vois pas spécialement d'utilité.
    le 13/12/2014 à 10:48
  • Paleo
    Membre éclairé
    Zefling a raison.

    Envoyé par SylvainPV
    Si ton navigateur est en français, c'est que tu connais le français et que tu peux parfaitement saisir une date avec la localisation française. Pour le site web, ça ne changera rien puisqu'en amont toutes les dates sont au format anglais YYYY-MM-DD.
    Avec ce genre de raisonnement, les petits drapeaux pour le choix des langues dans un site Web ne devraient pas être affichés, et la version du langage du navigateur devrait être forcée. Mais non. Un site Web ou une application en anglais doit pouvoir proposer un contexte entièrement en anglais, et ceci indépendamment de la configuration du navigateur. Ou du moins, du moment que le navigateur embarque plusieurs localisations, le code HTML devrait pouvoir choisir laquelle privilégier. Actuellement on a des <input> qui affichent un format différent du reste du site ou de l'application.

    YYYY-MM-DD ce n'est pas de l'anglais mais un format d'échange standardisé.
    le 13/12/2014 à 11:01
  • SylvainPV
    Rédacteur/Modérateur
    Je ne pense pas qu'on arrivera à se mettre d'accord. Vous voyez dans la décentralisation de la langue et de l'interface une contrainte alors que j'y vois un avantage certain. Il y a déjà plein d'autres éléments traduits dans la langue configurée par le navigateur comme les boîtes d'alertes, les demandes d'autorisation, les messages de statut... tout cela n'a jamais été un problème. Avoir tous les éléments du site dans une seule langue qui n'est pas celle que vous avez choisi par défaut pour votre navigateur ressemble davantage à un caprice qu'à un réel besoin...

    Si les développeurs se chargent intégralement de la traduction de leur site, dans combien de langues il sera traduit ? Trois ? Cinq au maximum ? En confiant ce rôle au navigateur, vous savez que ces éléments seront traduits dans plus d'une centaine de langues différentes sans même avoir à y penser. J'ignore quel est le format de date en biélorusse, en ouzbek ou en zoulou, mais avec HTML5 je n'ai pas besoin de le savoir. Avec votre solution à base de surcharge d'input text, vos visiteurs étrangers seront forcés d'employer un format de date qui n'est pas le leur. Des outils de traduction automatisés comme Translator peuvent s'occuper du contenu, mais ils ne sauront pas modifier les formats de saisie si vous ne les aidez pas pour ça.

    Cette délégation de la localisation au navigateur, et pas seulement au niveau des champs input, est selon moi essentielle pour donner au Web son vrai caractère universel. En tout cas, plus universel qu'il l'est aujourd'hui avec une poignée de petits drapeaux dans un coin de page.
    le 13/12/2014 à 16:16
  Poster une réponse