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.

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

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

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

[Paleo]

Zefling a raison.

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

[SylvainPV]

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.

[Paleo]

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

Ce sont des choses moins critiques, plus transversales, et surtout en dehors du contexte d'une application Web (et en pratique beaucoup plus rares). Nous sommes dans la même situation qu'une machine avec un système d'exploitation configuré dans une langue et qui fait tourner une application dans une autre langue. Exemple : je développe en anglais sous PhpStorm en anglais, mais mon OS est en français. Ça m'agacerait que PhpStorm se mette à utiliser les notations françaises dans les champs de saisie des préférences. De même qu'un système d'exploitation en français peut faire tourner des applications en anglais, un navigateur en français devrait pouvoir faire tourner des applications en anglais.

Pour les boites de dialogues, à mon avis l'avenir n'est pas dans les alertes mais dans l'élément <dialog> qui n'introduit aucune localisation particulière.

[Zefling]

Tout tant à rendre tout personnalisable, et avec une possibilité de traduction ou personnalisation : les placeholder, l'élement <dialog>, contextmenu (qui permet de faire ses propres actions en menu contextuel), et d'autre que j'oublie. La partie form est juste la plus mauvaise : message d'erreur pas personnalisable, pas de possibilités réelles de personnalisation.

[SylvainPV]

Tu as vu ma capture d'écran avec les différences d'ergonomie d'un appareil à un autre ? Une personnalisation standard pour ce type de composant est tout bonnement impossible, la spécification ne prévoit pas d'UI par défaut justement parce qu'elle ne conviendrait pas à tous les types de périphériques existants, sans même réfléchir à ceux à venir.

Des datepickers JavaScript personnalisables il y en a des tonnes et ils ont tous le même défaut: ils sont utilisables sur une plage restreinte de terminaux, et considérablement dégradés sur le reste. Moi qui suis spécialisé dans le web multi-plateforme, c'est un problème que j'ai rencontré plus d'une fois. J'ai dû débrancher des datepickers JavaScript existants dans plusieurs projets parce que certains utilisateurs mobiles ne pouvaient pas saisir de date. J'en ai parlé dans mon article sur les Web Components : http://sylvainpv.developpez.com/publ...s-debat/#LII-C

Ce que j'essayais de faire comprendre à mes clients, c'est que la personnalisation du datepicker par le navigateur est une aubaine: ils ont été conçus par des spécialistes spécifiquement pour l'appareil ou la classe d'appareil correspondants, et sont intégrés souvent en natif pour une ergonomie et une réactivité optimale. Et en plus, les utilisateurs savent déjà s'en servir puisque c'est celui de leur système ! Mais c'est quelque-chose que les développeurs et les clients ont beaucoup de mal à accepter, ils me répondent souvent quelque-chose comme "c'est bien mais moi je voudrais le bouton en rouge" .

[Zefling]

Mais c'est quelque-chose que les développeurs et les clients ont beaucoup de mal à accepter, ils me répondent souvent quelque-chose comme "c'est bien mais moi je voudrais le bouton en rouge" .

Non, moi on me dit : « je ne veux pas que les week-end et jour férié soient sélectionnables. Mais aussi qu'il faut qu'il y soit des pages horaires possibles sur le “time”, voir des paliers variables suivant la plage. Que le “slider” ait une incrémentation exponentielle, etc. » Des dizaines des cas qui ne rentrent pas dans le « standard ». Je ne vais pas faire du standard si ça ne correspond pas au besoin. Pourquoi crois-tu que les éléments Jquery UI soit si paramétrables comparé au élément standard qui le sont quasiment pas. De plus, IE8/9 sont encore très souvent une cible requise dans mes projets, et ça ne fonctionne pas dessus (pas plus que Firefox et IE11).

Autre problème, c'est que ces éléments quand ils ne sont pas supportés sont juste des type="text" avec des formats spécifiques pas forcement naturel comme datetime : « 2014-12-04T22:03:58Z ».

Bref, le jour où tu les verras autrement utiliser que dans des applications spécifiquement mobile/tactile (et encore) n'est pas encore près d'arriver. En attendant, les widgets font du bon boulot.

[SylvainPV]

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.

Moi aussi j'ai à faire à ce genre de cahier des charges particulier mais je m'en suis toujours sorti en appliquant les règles de validation par-dessus le standard. Pour restreindre les dates par exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
var date = document.querySelector('[type=date]');
date.addEventListener('input', checkDateValidity);
 
function checkDateValidity(e){
    var day = new Date( e.target.value ).getUTCDay();
    if( day == 0 || day == 6 ){
        e.target.setCustomValidity("Veuillez sélectionner un jour de semaine");
    } else {
        e.target.setCustomValidity('');
    }
}

Pour assurer le support sur les navigateurs, je me sers d'un test de support qui charge un polyfill au besoin (le widget jQueryUI sur desktop, et un widget de ma conception sur petits écrans tactiles). L'empreinte réseau est minimale, le test et le chargement du polyfill ne font qu'une dizaine de lignes de code.

Bref, le jour où tu les verras autrement utiliser que dans des applications spécifiquement mobile/tactile (et encore) n'est pas encore près d'arriver

Non, tu n'as pas du tout compris ce que j'ai essayé de t'expliquer au sujet du lien entre sémantique et multiplateforme. S'il s'agissait uniquement des applications spécifiquement mobile/tactile, on utiliserait justement un widget puisqu'on connaît le contexte d'utilisation client ; de la même façon que vous utilisez encore les widgets comme jQuery UI parce que vous négligez l'usage tactile. Mais pour les sites web publics, ceux dont on ignore quels visiteurs vont le consulter et comment, ce contexte d'utilisation est inconnu et c'est justement pour ça qu'on doit reposer sur les standards pour se donner les meilleures chances d'avoir un composant utilisable. J'ai plusieurs sites en production qui utilisent les date inputs et le résultat est nettement plus convaincant que du temps où je me contentais du widget jquery UI, y-compris pour l'usage desktop. Par exemple le navigateur a plus de facilité à autocompléter la date de naissance dans les formulaires d'inscription car il repère que c'est un champ date.

[Zefling]

Désolé, mais je préféré mettre les jours en désactivé que renvoyer une erreur au submit. Au moins, le client ne perd pas de temps à faire un validation pour rien. C'est genre de chose qui serait appréciable d'avoir directement sur le comportement de l’élément. Mais bon, je ne suis pas trop le HTML5, je ne sais pas si c'est prévu.

[SylvainPV]

Cela peut se faire aussi, en écoutant l'évènement invalid par exemple et en déclenchant manuellement la soumission du formulaire. D'après la spécification, il y a la méthode reportValidity() qui sert à ça mais elle semble très peu supportée.

[Zefling]

Ça ne sera pas aussi visuel qu'un <option> désactivé dans un <select>.