Discussion :

[vermine]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[SylvainPV]

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...

[vermine]

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.

[SylvainPV]

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_bug.cgi?id=825294 ; plus il y a de monde au portillon, plus on a de chances de voir la fonctionnalité intégrée rapidement.

[Paleo]

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.

[SylvainPV]

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.

[Zefling]

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.

[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.

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.

[Zefling]

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.

Pour m'y être confronté, leur rigidité a finit par me convaincre de pas les utiliser.
- possible de choisir la langue ou le format d'affichage
- pas possible de les redéfinir
- pas possible de faire des exceptions
Leur interface n'est pas aussi malléable/customisable que j'aurais souhaité.