Demander une date dans un formulaire: les solutions


Tout le monde a déjà été confronté à ce problème: sur une de vos pages, vous avez besoin de demander une date à vos utilisateurs, via un formulaire. Il y a plusieurs façons de faire, certaines plus simples ou plus pratiques que d’autres. Ayant été face à cette situation il y a quelques temps, j’ai fini par trouver la solution qui me convenait le mieux après avoir pesé le pour et le contre de chacune. Après avoir à nouveau discuté de ce problème avec Valentin de TheAppLab, j’ai décidé de vous partager ma vision de la chose.

Le champ de type text

<input type="text" name="date">

C’est sans conteste la solution la plus simple. Le désavantage, et il est de taille, est que vous faites entièrement confiance à l’utilisateur quant au format sous lequel il entrera la date. 23/09/2013, 09/23/13, 23 septembre 2013, … Vous l’aurez compris, ce sera assez pénible à gérer lorsque vous allez vouloir traiter la donnée qu’il a entrée.

Pour éviter un peu les ennuis, on pourrait bien aimablement suggérer le format auquel il doit entrer la date, par exemple au moyen d’un label ou d’un placeholder. Mais vous le savez certainement, il ne faut jamais faire confiance à l’utilisateur, rien ne nous dit qu’il respectera le format qu’on lui indique.

On pourrait alors le forcer à faire correctement, en vérifiant, par exemple à la validation du formulaire au moyen de javascript, que la date est entrée dans le format voulu. C’est assez simple à mettre en place, mais il ne faut pas oublier que le javascript pourrait être désactivé pour contourner cette vérification, ou que la requête pourrait être envoyée sans passer par le formulaire. Pensez donc à toujours faire la vérification du côté serveur également, et ce quelque soit la méthode utilisée en amont.

Le triple select

L’idée est d’éviter d’imposer un format de date à l’utilisateur, en utilisant un élément select pour le jour, un autre pour le mois et un dernier pour l’année.

date_select

<select name="annee">
    <option value="2013">2013</option>
    <option value="2012">2012</option>
</select>
<select name="mois">
    <option value="01">Janvier</option>
    <!--...-->
    <option value="12">Février</option>
</select>
<select name="jour">
    <option value="01">01</option>  
    <!--...-->
    <option value="31">31</option>
</select>

On est ainsi sûr qu’on aura l’information formatée comme on le désire (on n’oublie pas de bien vérifier quand même du côté serveur, au cas où la requête serait forgée et ne passerait pas gentiment par le formulaire). Le seul inconvénient, c’est que ça reste assez pénible pour l’utilisateur qui doit se farcir trois listes déroulantes pour entrer une date.

On n’oubliera bien évidemment pas de vérifier avec un peu de javascript que la date entrée est valide (typiquement pour éviter des choses comme le 31 avril ou le 29 février 2013).

Le champ de type date

L’arrivée du HTML5 va solutionner notre problème. En effet, de nombreux nouveaux types de champs input ont fait leur apparition, comme par exemple les types date, datetime, number, email, … Ne vous réjouissez par contre pas trop vite, ces nouvelles normes ne sont malheureusement pas encore suffisamment supportées que pour pouvoir être réellement utilisées. Et pourtant, je vais l’illustrer avec le cas de type date, c’est tellement pratique.

Date: <input type="date" name="date">

Sur navigateur (seul Chrome semble être compatible pour le moment), le champ de type date vous permet de modifier la date au moyen de flèches, mais également de faire apparaître le calendrier pour y sélectionner la date voulue.

champs_date

Mais ce n’est pas tout, la cerise sur le gâteau: la prise en charge sur mobile (du moins sur Safari pour iOs et Chrome pour Android).

date_ios Screenshot_2013-09-26-22-35-30

Il n’y a plus qu’à espérer que cette fonctionnalité se généralise au plus vite aux autres navigateurs histoire qu’on puisse enfin en profiter.

Le datePicker de jQuery UI

Mais si comme moi, vous êtes assez fan du calendrier pour sélectionner la date, il existe de nombreuses alternatives permettant d’avoir un rendu similaire. L’une d’entre elle, et celle que j’utilise, est jQuery UI.

Je pense que le nom de cette librairie est assez explicite, mais pour ceux qui sont fatigués, ça se base sur jQuery et propose de nombreux éléments d’interface graphique comme des sliders, barres de progressions et surtout… le datePicker !
C’est cet élément qui va nous permettre d’obtenir ce résultat (démo live):

Datepicker jQuery UI

L’utilisation de base est très simple: Après avoir inclus les fichiers js de jQuery et jQuery UI, il vous suffira d’appeler la méthode datePicker() sur votre objet.
Par exemple:

<form>
    <input type="text" class="datepick">
</form>

<script type="text/javascript">
    $(document).ready(function() {
        $('.datepick').datepicker({ dateFormat: "yy-mm-dd"});
    });
</script>

Dans l’exemple, j’ai précisé le format auquel je voulais obtenir la date. Il existe une flopée d’autres paramètres si vous voulez un peu plus de contrôle. Pour ça, je vous renvoie vers la documentation.

C’est donc jusqu’à maintenant, la solution qui me séduit le plus. Et vous, comment faites-vous quand vous devez demander une date à vos utilisateurs ?

facebooktwittergoogle_pluspinterestlinkedintumblrmailfacebooktwittergoogle_pluspinterestlinkedintumblrmail

Un commentaire

  1. Sympa l'initiative du blog !

    Perso je trouve que Bootstrap est pas mal, sinon j'ai découvert KendoUI y'a pas très longtemps, ça a l'air sympa, mais pas encore testé.
    Reply
  2. Bon article :) Perso j'utilise aussi jQuery UI pour ce genre de chose, je ne peux que le recommander de même :)
    Par contre il y a une raison pour laquelle tu ne termine pas tes single tags par /> mais simplement par > ? Je pense que pour être valide W3C tu need la première option :)
    (tiens, idée peut-être pour un prochain article qui m'intéresserait si tu en sais quelque chose là-dessus : est-ce que ça sert d'être valide W3C de nos jours ou non ?)
    Reply
    • Merci DaTa !
      Pour les tags, je suis la norme HTML et non pas XHTML. Dans le XHTML, tu as effectivement des "self closing tags" comme <input />, <img />, <br />, <link />...
      En HTML (et donc en HTML5), ce n'est pas nécessaire (c'est même potentiellement pas valide, à tester). <input>, <img>, <br>, <link>, ... sont valides.

      Au final, je ne pense pas que ça soit important car les navigateurs font assez bien leur boulot que pour gérer les deux (mais tant qu'à faire, c'est plus facile à écrire <...> que <... />).

      Maintenant faut voir si tu veux un code valide W3C ou pas. Et bonne idée, j'en parlerai prochainement dans un article.

Laisser un commentaire.