Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous

Identifiant
Mot de passe

Mot de passe oublié ?

Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

à ne pas confondre avec le HTML5

Le 11 décembre 2014 à 12:35, par vermine

19 commentaires

43PARTAGES

Voter pour

2

Voter contre

0

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

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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Votre nom : Votre e-mail :

Décrivez l'erreur que vous souhaitez porter à notre connaissance :

19 commentaires

Commenter Signaler un problème

Rédacteur/Modérateur

Le 12/12/2014 à 14:24

Citation

Envoyé par Tarh_

Voir le message

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.

Voter pour

2

Voter contre

1

Rédacteur/Modérateur

Le 11/12/2014 à 16:23

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

Voter pour

0

Voter contre

0

Expert éminent sénior

Le 11/12/2014 à 16:31

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.

Voter pour

0

Voter contre

0

Rédacteur/Modérateur

Le 11/12/2014 à 18:48

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.

Voter pour

0

Voter contre

0

Membre éclairé

Le 12/12/2014 à 10:07

Citation

Envoyé par SylvainPV

Voir le message

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.

Voter pour

1

Voter contre

1

Expert confirmé

Le 12/12/2014 à 17:20

Citation

Envoyé par SylvainPV

Voir le message

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.

Voter pour

0

Voter contre

0

Rédacteur/Modérateur

Le 13/12/2014 à 0:32

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.

Voter pour

0

Voter contre

0

Expert confirmé

Le 13/12/2014 à 10:48

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

Voter pour

0

Voter contre

0

Membre éclairé

Le 13/12/2014 à 11:01

Zefling a raison.

Citation

Envoyé par SylvainPV

Voir le message

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

Voter pour

0

Voter contre

0

Rédacteur/Modérateur

Le 13/12/2014 à 16:16

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.

Voter pour

0

Voter contre

0

Commenter Signaler un problème