GRATUIT

Vos offres d'emploi informatique

Développeurs, chefs de projets, ingénieurs, informaticiens
Postez gratuitement vos offres d'emploi ici visibles par 4 000 000 de visiteurs uniques par mois

emploi.developpez.com

Mask.js : valider vos champs HTML numériques, dates et textuels à chaque touche frappée
à ne pas confondre avec le HTML5

Le , par vermine, Responsable JavaScript & AJAX
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur https://www.developpez.com
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...
Avatar de vermine vermine - Responsable JavaScript & AJAX https://www.developpez.com
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.
Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur https://www.developpez.com
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_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.
Avatar de Paleo Paleo - Membre confirmé https://www.developpez.com
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.
Avatar de Zefling Zefling - Membre émérite https://www.developpez.com
le 12/12/2014 à 10:53
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, 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é.
Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur https://www.developpez.com
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.
Avatar de Zefling Zefling - Membre émérite https://www.developpez.com
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.
Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur https://www.developpez.com
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.
Avatar de Zefling Zefling - Membre émérite https://www.developpez.com
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é.
Avatar de Paleo Paleo - Membre confirmé https://www.developpez.com
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é.
Offres d'emploi IT
Ingénieur produit (FADEC militaire) H/F
Safran - Ile de France - 100 rue de Paris 91300 MASSY
Ingénieur moa logiciel H/F
Safran - Ile de France - Villaroche
Responsable de projets - actionneurs H/F
SAFRAN - Ile de France - MASSY / MANTES

Voir plus d'offres Voir la carte des offres IT
Responsable bénévole de la rubrique JavaScript : Xavier Lecomte -