Création d'applications HTML5

De meilleurs Web Forms grâce aux HTML5 Forms

Brandon Satrom

Télécharger l'exemple de code

Si vous êtes un développeur Web, vous avez sans doute déjà créé un formulaire HTML. En fait, vous en avez peut-être créé plus qu'il ne vous importe de vous souvenir. Vous maîtrisez sans aucun doute des types d'entrées classiques comme texte, mot de passe, fichier, masqué, case à cocher, radio, envoyer et bouton, et vous avez certainement utilisé la plupart (ou tous) à plusieurs reprises.

Si je devais vous demander quel type d'entrée, dans la liste ci-dessus, vous utilisez plus que toute autre, vous me répondriez sans doute « texte », comme le feraient la plupart d'entre nous. Le type d'entrée texte est l'outil polyvalent pour le développement de formulaires HTML classiques. D'un côté, il est en mesure de s'adapter à n'importe quelle tâche que vous lui confiez, mais, d'un autre côté, il est sémantiquement neutre, ainsi le navigateur n'apporte aucune aide pour faire de cet élément quelque chose de pratique. Pour compenser, des développeurs et des concepteurs ont ajouté leur propre sémantique à ces éléments (via des ID et des noms de classe) et se sont appuyés sur des infrastructures de serveurs et JavaScript pour gérer la validation et ajouter de riches interactions.

Un exemple classique consiste à collecter des dates dans des champs de texte. Le plus souvent, vous voulez améliorer un champ de date à l'aide d'un sélecteur de dates. C'est généralement un JavaScript manuel ou une infrastructure de type interface utilisateur jQuery, ce qui ajoute un comportement d'interaction qui permet à l'utilisateur de sélectionner une date dans un widget et de renseigner cette date dans le champ d'origine.

Aussi utile soit-il, (et en tant que développeurs nous sommes devenus de véritables adeptes de ce type de modèles), ce modèle est si souvent répété qu'il est inévitable de finir par se demander « Pourquoi le navigateur ne peut-il pas le faire lui-même ? ».

La bonne nouvelle, c'est que, avec HTML5 Forms, le navigateur le peut... et le fera. En plus du texte et des quelques types existants dont nous disposons depuis des années, HTML5 ajoute 13 nouvelles valeurs pour l'attribut de type d'entrée, ainsi que toute une série d'autres attributs qui accéléreront le développement de vos formulaires. Ce mois-ci, je vais vous communiquer quelques uns des nouveaux attributs et types d'entrées associés à HTML5 Forms, ainsi que leur statut d'implémentation dans divers navigateurs. Je présenterai ensuite un bref aperçu de nouvelles fonctionnalités de validation client pour HTML5 Forms. Enfin, j'examinerai de quelle manière des mises à jour récentes de Visual Studio 2010 et Microsoft .NET Framework 4 permettent à HTML5 Forms et Web Forms ASP.NET de bien s'accorder. Je discuterai pendant tout ce temps de la manière dont vous pouvez inclure HTML5 Forms dans vos applications aujourd'hui tout en fournissant des solutions de secours pour les navigateurs plus anciens. Toutes les démonstrations pour cet article, qui sont disponibles en ligne, ont été créées à l'aide de WebMatrix, un outil de développement Web gratuit et léger de Microsoft. Vous pouvez essayer WebMatrix par vous-même à l'adresse suivante : aka.ms/webm.

Nouveaux types d'entrées dans HTML5

Ce que nous connaissons aujourd'hui comme étant HTML5 Forms ou HTML5 Web Forms a démarré sous le nom de Web Forms 2.0, une spécification pré-HTML5 créée par un groupe appelé WHATWG (Web Hypertext Applications Technology Working Group). La majeure partie du travail initial du WHATWG est devenue le point de départ ce que nous appelons maintenant HTML5 et l'effort Web Forms 2.0 fait à présent partie de la spécification HTML5 officielle, que vous pouvez consulter à l'adresse suivante : bit.ly/njrWvZ. Une partie non négligeable de la spécification est consacrée à de nouveaux types et attributs de contenu pour l'élément d'entrée, que vous trouverez à l'adresse suivante : bit.ly/pEdWFs.

Comme je l'ai mentionné précédemment, la spécification introduit 13 nouveaux types d'entrées à utiliser dans des formulaires : recherche, tél., url, e-mail, dateheure, date, mois, semaine, heure, dateheure-locale, numéro, plage, couleur.

L'utilisation de ces nouveaux types est simple. Imaginons que je veuille insérer un nouveau champ d'e-mail sur un formulaire de commande. Comme vous pouvez le voir sur la Figure 1, j'ai modifié la page de commande du site Web de modèle Pâtisserie WebMatrix en lui ajoutant des champs, dont e-mail.

Figure 1 Un exemple de formulaire de commande

Pour ce formulaire, le champ e-mail est indiqué comme suit :

<input type="email" id="orderEmail" />

Vous remarquerez que l'attribut type est égal à « email » au lieu de « text ». Ce qu'il y a de mieux concernant les nouveaux types d'entrées HTML, c'est que vous pouvez les utiliser aujourd'hui et qu'ils fonctionnent, dans une certaine mesure, dans n'importe quel navigateur. Lorsqu'un navigateur rencontre un de ces nouveaux types, un de ces deux événements se produit.

Si le navigateur ne prend pas en charge les nouveaux types d'entrées, la déclaration du type ne sera pas reconnue. Dans ce cas, le navigateur dégrade sans perte de données l'élément et le traite comme suit : type=« text ». Vous pouvez tester cela en plaçant cet élément sur un formulaire et en tapant « document.getElementById(‘orderEmail’).type » dans la console Outils F12 d'Internet Explorer 9. Ainsi, vous pouvez utiliser ces nouveaux types aujourd'hui et, si le navigateur ne prend pas en charge un champ donné, il continuera de fonctionner comme un champ de texte normal.

Cependant, si le navigateur reconnaît un type, vous tirerez des avantages immédiats de son utilisation. Pour des types reconnus, le navigateur ajoute un comportement intégré spécifique au type. Dans le cas du type e-mail, Internet Explorer 10 Platform Preview 2 (PP2), et les versions ultérieures, valideront automatiquement toute entrée et soumettront à l'utilisateur un message d'erreur si la valeur fournie n'est pas une adresse e-mail valide, comme illustré sur la Figure 2.

Figure 2 Validation navigateur automatique du type d'entrée d'e-mail

Il est facile de déduire l'objet et le comportement de chaque élément d'après son type, ce qui nous permet d'atteindre aisément un autre niveau de richesse sémantique dans nos formulaires. De plus, certains de ces nouveaux types d'entrée permettent au navigateur de fournir des interactions plus riches aux utilisateurs dès l'installation. Par exemple, si je place l'élément suivant sur un formulaire et que j'ouvre ensuite ce formulaire dans un navigateur qui prend entièrement en charge le type d'entrée date, l'interaction par défaut est bien plus riche qu'une ancienne zone de texte traditionnelle :

<input type="date" id="deliveryDate" />

La Figure 3 illustre ce que le type de date peut fournir dans Opera 11.5. La meilleure partie repose sur le fait que tout ce que j'ai eu à faire pour obtenir cette interaction a consisté à spécifier type=« date » et le navigateur s'est chargé de tout le travail manuel dont je devais auparavant me charger dans JavaScript pour proposer ce niveau de fonctionnalité.

Figure 3 Type d'entrée Date dans Opera 11.5

Il est important de remarquer que la spécification HTML5 ne dicte pas de quelle manière les navigateurs devraient présenter ces nouveaux types d'entrée, ou comment ils devraient présenter des erreurs de validation. Vous devez donc vous attendre à constater des différences mineures à majeures entre les navigateurs. Par exemple, Chrome 13 présente un compteur pour la date et non un sélecteur de dates, comme illustré sur la Figure 4 (ce qui, bien entendu, aura pu changer d'ici à ce que vous lisiez ceci). Vous devez également savoir qu'une discussion est en cours sur le W3C (World Wide Web Consortium) concernant la spécification de style de navigateur et la localisation d'éléments tels que dateheure, date et couleur. Les navigateurs ne sont pas tous d'accord, actuellement, sur la manière d'implémenter ces types et il n'existe à ce jour aucun mécanisme de personnalisation dans les implémentations existantes qui soit similaire à ce que l'interface utilisateur jQuery est en mesure de vous proposer. Si vous choisissez d'implémenter ou de tester ces nouveaux types, assurez-vous toujours de fournir une solide solution de secours. De plus, si la cohérence de la présentation et du comportement est importante pour vos utilisateurs, vous devrez peut-être appliquer des styles personnalisés, remplacer des comportements par défaut sur ces commandes ou utiliser une solution basée sur un script.

Figure 4 Type d'entrée Date dans Chrome 13

J'ai indiqué précédemment que ces champs continueraient de se comporter comme des champs de textes normaux, ce qui est un joli exemple de dégradation sans perte de données que les navigateurs nous fournissent. Mais un champ de date implémenté en tant que zone de texte traditionnelle est bringuebalant et largement considéré comme une expérience utilisateur médiocre. Cependant, un petit coup de pouce de la part de Modernizr et de l'interface utilisateur jQuery vous permettra de fournir une solution qui mélange ce que HTML5 Forms fait de mieux avec une intéressante solution de secours.

Vous vous souviendrez d'avoir lu dans mon dernier article (msdn.microsoft.com/magazine/hh394148) que Modernizr (modernizr.com) est une bibliothèque de JavaScript qui peut vous aider à détecter une assistance pour des fonctionnalités HTML5 dans le navigateur. Pour cet exemple, je veux utiliser Modernizr pour faciliter la détection de l'assistance pour le type d'entrée de HTML5 et, s'il n'est pas pris en charge, j'utiliserai le widget sélecteur de dates de l'interface utilisateur jQuery (jqueryui.com) afin de fournir une expérience utilisateur similaire. Une fois que j'ai téléchargé et ajouté des références pour Modernizr, jQuery et l'interface utilisateur jQuery, je peux ajouter une assistance de secours pour mes éléments de date avec seulement quelques lignes de code :

if (!Modernizr.inputtypes.date) {
  $("input[type=date]").datepicker();
}

le résultat, comme on le voit dans Internet Explorer 10 PP2, est illustré dans la Figure 5.

Figure 5 Prise en charge du champ de date avec l'interface utilisateur jQuery

Nouveaux attributs de contenu d'entrée dans HTML5

En plus des nouveaux types d'entrée, HTML5 fournit quelques nouveaux attributs de contenu pratiques qui peuvent être utilisés sur des champs d'entrée pour fournir une prise en charge de la validation et de meilleures fonctionnalités. Un de ces nouveaux attributs est « placeholder » (espace réservé), qui, selon la spécification, « …représente une indication courte (un mot ou une phrase courte) visant à aider l'utilisateur dans sa saisie de données » (accentuation). Par exemple, je peux prendre deux des champs de notre formulaire de commande et ajouter espace réservé=« du texte » à chaque champ, avec le résultat illustré sur la Figure 6:

<input type="email" id="orderEmail" placeholder="ex. name@domain.com" />
<input type="url" id="orderWebsite" placeholder="ex. http://www.domain.com" />

Figure 6 Utilisation de l'attribut d'espace réservé avec des champs d'entrée

Le texte de l'espace réservé est de couleur plus claire que le texte normal et, si je place une accentuation sur chaque champ, le texte disparaît, ce qui me permet de saisir ma propre valeur.

Comme avec les nouveaux types d'entrées, l'attribut d'espace réservé n'est pas pris en charge dans des navigateurs plus anciens. Il ne se produira cependant rien de fâcheux si un utilisateur visite une page avec eux, envisagez donc de les utiliser aujourd'hui, même si vous ne prévoyez pas d'ajouter une assistance pour des navigateurs plus anciens. Si vous ne voulez pas de « polyfill » pour une prise en charge d'espace réservé, Modernizr peut apporter une solution. Comme je l'ai signalé dans mon article précédent, nos amis de chez Modernizr s'efforcent de tenir à jour une liste de chaque Polyfill et secours que vous pourriez souhaiter pour une fonctionnalité HTML5 donnée. Vous pouvez consulter cette liste à l'adresse suivante : bit.ly/nZW85d.

Pour cet exemple, utilisons l'espace réservé HTML5 jQuery créé par Mike Taylor, que vous pouvez télécharger à l'adresse suivante : bit.ly/pp9V4s. Une fois que vous l'avez, ajoutez ce qui suit à un bloc de script référencé par votre page :

Modernizr.load({
    test: Modernizr.input.placeholder,
    nope: "../js/html5placeholder.jquery.min.js",
    callback: function() {
      $('input[placeholder]').placeholder();
    }
  });

là, Modernizr teste si l'attribut d'espace réservé est pris en charge et si ça n'est pas le cas, il charge html5placeholder.jquery.min.js. jQuery sélectionne alors chaque élément avec un attribut d'espace réservé et ajoute une prise en charge de plug-in à chacun. Si vous essayez cela dans Internet Explorer 9, vous remarquerez que le résultat final est très similaire à la prise en charge de navigateur natif fournie dans Internet Explorer 10 PP2.

Un autre nouvel attribut intéressant est « autofocus », qui, comme son nom l'indique, vous permet de spécifier un champ de formulaire unique afin de recevoir automatiquement un focus lorsqu'une page est chargée. Un seul champ par page devrait contenir cet attribut. Si plusieurs éléments sont marqués d'un autofocus, c'est le premier portant cette déclaration qui reçoit le focus au chargement de la page. Pour mon formulaire de commande, je veux que le champ Nom reçoive un focus. J'ajoute donc l'attribut comme suit :

<input type="text" class="field" id="orderName" autofocus />

L'attribut Autofocus, qui peut être utilisé sur n'importe quel contrôle de formulaire, est une excellente alternative pour les stratégies centrées formulaire et basées sur un script contre lesquelles de nombreux développeurs Web ont lutté par le passé.

Validation de formulaire HTML5

Je ne dispose pas ici de la place suffisante pour aborder tous les nouveaux attributs intéressants relatifs aux formulaires, mais je vais consacrer quelques moments aux suivants : « obligatoire », « modèle », « novalidate » et « formnovalidate », qui font tous de la validation de formulaire côté client un jeu d'enfant.

Pour les navigateurs qui le prennent en charge, l'attribut « obligatoire » indique au navigateur que ce formulaire ne peut être envoyé sans une valeur. Par exemple, j'ajoute « obligatoire » au champ Nom de mon formulaire de commande :

<input type="text" class="field" id="orderName" required />

Lorsque je consulte cette page dans Internet Explorer 10 PP2 et que j'essaie d'envoyer le formulaire, je vois quelque chose de similaire à ce qui est illustré sur la Figure 7. Avec un attribut unique, le navigateur est suffisamment renseigné pour affecter un style à l'élément à l'aide d'une bordure rouge et affiche un message à l'utilisateur indiquant que le champ est obligatoire.

Figure 7 Utilisation de l'attribut Obligatoire sur un champ de formulaire

Précédemment, la Figure 2 a montré de quelle manière le navigateur peut automatiquement valider certains types, par exemple « e-mail » et « url », sans saisie supplémentaire pour l'utilisateur. Avec l'attribut « modèle », vous pouvez fournir votre propre test de validation pour des types d'entrée. Selon la spécification HTML5, « modèle » attend une expression normale, que le navigateur utilise pour valider le champ propriétaire.

Mon formulaire de commande contient un champ téléphone (type=« tél. ») et je peux préciser un modèle de validation comme celui-ci :

<input type="tel" id="orderTelephone" pattern="\(\d\d\d\) \d\d\d\-\d\d\d\d" title="(xxx) xxx-xxxx" />

Cette expression normale (peu complexe) indique au navigateur d'attendre un nombre à sept chiffres avec des parenthèses autour du code de la zone et un tiret dans le numéro local. L'entrée de toute autre donnée entraîne l'apparition du message de la Figure 8. Veuillez noter que ce message contient des instructions indiquant à l'utilisateur comment formater l'entrée : « (xxx) xxx-xxxx ». Cette partie du message est issue de l'attribut de titre du même élément. Il est donc possible de contrôler au moins en partie le message de validation via votre balise. Il y a cependant un élément à noter lors de l'utilisation du titre pour faciliter la validation. Selon la spécification, le navigateur peut choisir d'afficher le titre dans d'autres cas sans erreur. Ne comptez donc pas sur cet attribut pour identifier du texte erroné.

Figure 8 Utilisation de l'attribut Modèle pour spécifier une expression de validation

L'automatisation de la validation par le navigateur est une fonction intéressante, mais deux questions viennent immédiatement à l'esprit. Premièrement, qu'en est-il des scripts de validation client ou de validation serveur générés par mon infrastructure de serveur (ASP.NET MVC, par exemple) ? Et deuxièmement, que se passe-t-il lorsque je veux que l'utilisateur soit en mesure d'enregistrer le formulaire en tant que tâche en cours, sans validation ? La première va, malheureusement, au-delà de la portée de cet article. Mais j'ai rédigé un billet de blog concernant ce sujet précis dans MVC ASP.NET, que vous pouvez consulter à l'adresse suivante : bit.ly/HTML5FormsAndMVC.

La deuxième question, en revanche, est simple. Supposons que vous avez un formulaire sur lequel des utilisateurs vont passer un certain temps avant de l'envoyer, et qu'ils vont peut-être même enregistrer plusieurs fois avant de finalement le publier sur votre serveur. Dans de tels cas de figure, où vous voudrez autoriser un utilisateur à envoyer un formulaire sans validation, deux attributs sont à votre disposition : « formnovalidate », qui est placé sur des champs d'entrée de type « envoyer » et « novalidate », qui est placé sur une balise Form d'ouverture. Là, je placerai deux champs d'envoi sur mon formulaire, comme suit :

<input type="submit" value="Place Order" />
<input type="submit" formnovalidate value="Save for Later" id="saveForLater" />

L'attribut « formnovalidate » sur le deuxième bouton désactivera la validation et enverra le formulaire, permettant d'enregistrer le travail en cours de l'utilisateur dans ma base de données, ou même sur le côté client à l'aide d'une nouvelle technologie de stockage HTML5 comme localStorage ou IndexedDB.

Formulaires HTML5 et Web Forms ASP.NET

Avant de conclure cet article, je veux partager quelques petits éléments d'information supplémentaires concernant les formulaires HTML5 pour les développeurs de Web Forms ASP.NET. Si vous prévoyez un développement de formulaires HTML5 avec des Web Forms ASP.NET, il y a de bonnes nouvelles : de nombreuses mises à jour relatives à HTML5 sur .NET et Visual Studio sont publiées hors bande. Ainsi, vous n'êtes pas obligés d'attendre la prochaine version de l'infrastructure pour utiliser ces fonctionnalités aujourd'hui.

Pour démarrer avec les formulaires HTML5 et les Web Forms ASP.NET, vous aurez besoin de récupérer une ou deux mises à jour. Commencez par vous assurer de disposer de Visual Studio 2010 SP1 (bit.ly/nQzsld). En plus d'ajouter une prise en charge des nouveaux attributs et types d'entrées HTML5, ce service pack fournit également quelques mises à jour qui vous permettent d'utiliser les nouveaux types d'entrées HTML5 sur le contrôle serveur TextBox. Sans cette mise à jour, vous verrez des erreurs de compilation lors de l'utilisation de nouveaux types.

Vous voudrez également récupérer la mise à jour  Microsoft .NET Framework 4 Reliability Update 1 (bit.ly/qOG7Ni). Cette mise à jour est conçue pour traiter un certain nombre de problèmes relatifs à l'utilisation des nouveaux types d'entrées HTML5 avec les Web Forms ASP.NET. Scott Hunter en aborde quelques uns (UpdatePanel, contrôles de validation et rappels), dans un billet de blog qui date de début août et que vous pouvez consulter à l'adresse suivante : bit.ly/qE7jLz.

L'ajout d'une prise en charge des Web Forms aux navigateurs avec HTML5 est une bonne nouvelle pour les développeurs Web de partout. Non seulement avons-nous un ensemble de types d'entrées sémantiques dont nous pouvons tirer profit dans nos applications, mais nous pouvons également utiliser ces types d'entrées aujourd'hui sans conséquences désastreuses sur les navigateurs plus anciens, tout en bénéficiant de fonctionnalités améliorées (dont la validation de client automatique), sur les plus récents. L'utilisation dès à présent de ces nouveaux champs présente des avantages immédiats dans l'environnement des applications mobiles également. En effet, dans ce domaine, l'usage de types comme « url » et « e-mail » invitera les appareils mobiles à présenter à l'utilisateur des options de clavier logiciel adaptées à ce type d'entrées. Lorsque vous associez ces nouvelles fonctionnalités à Modernizr et une des excellentes options de polyfilling, vous disposez de tous les outils nécessaires pour adopter des formulaires HTML5 dans vos applications dès à présent.

Pour obtenir davantage d'informations sur la prise en charge des formulaires HTML5 dans Internet Explorer 10 PP2, rendez-vous sur ietestdrive.com et n'oubliez pas de consulter le guide du développeur du Centre de développement Internet Explorer (bit.ly/r5xKhN). Afin d'approfondir vos recherches sur les formulaires HTML5 en général, je vous recommande la lecture de « A Form of Madness », du livre de Mark Pilgrim « HTML5: Up and Running », (O'Reilly Media, 2010), ainsi que la section Forms de la spécification W3C HTML5 (bit.ly/nIKxfE).     

Brandon Satrom *est développeur pour Microsoft à l'extérieur d'Austin, Texas. Il possède un blog dont l'adresse est userinexperience.com et vous pouvez le suivre sur Twitter à l'adresse Twitter @BrandonSatrom.*

Je remercie les experts techniques suivants pour leur relecture de cet article : *Jon Box,  John Hrvatin,  Scott Hunter et *Clark Sell