Les éléments de section (section, article, nav, aside, header, footer) segmentent des portions du document ou de l'application web, qui possèdent une valeur sémantique particulière ; contrairement à des éléments génériques comme span ou div qui ont un rôle totalement neutre, et ne servent qu'à regrouper d'autres éléments HTML pour leur affecter un style CSS commun, voire pour interagir avec eux via le DOM... Il ne s'agit donc pas de nouveaux éléments avec des noms génériques : c'est bien plus que ça !

HTML5 inclut la majorité des éléments HTML4 pour assurer une rétro-compatibilité avec les navigateurs. Au-delà de ce critère, les groupes de travail qui ont élaboré HTML5 ont su analyser les usages courants et s'adapter aux tendances du web avec (entre autres) les nouvelles façons de trier l'information sur une page web. Des statistiques ont été élaborées sur les attributs id les plus fréquemment attribués aux grands découpages de pages HTML.

Par exemple, une majorité des sites contiennent des informations supplémentaires relatives ou non au contenu principal (que l'on nomme sidebar ou barre latérale). Cette information est alors placée dans un élément <div class="aside"> dédié - qui permet d'affecter des propriétés de styles CSS - mais n'a aucune signification particulière pour un navigateur ou un moteur d'indexation. C'est le cas de tous les autres <div>. Le même principe peut être appliqué pour baliser les différents articles d'un site d'information : pourquoi ne pas prévoir un élément <article> plutôt que de segmenter tout le contenu avec des <div class="article"> ? Ceci en facilitera autant l'extraction d'information, la syndication de contenu, et la structuration du code source.

Liste récapitulative des éléments de section HTML5

Le tableau suivant récapitule les nouveaux éléments de section et leur usage le plus commun, tel que décrit par la spécification.

Un cas particulier : Internet Explorer <9

Pour les versions antérieures à Internet Explorer 9, ces nouveaux éléments ne sont pas reconnus par l'analyseur syntaxique. C'est-à-dire qu'ils ne sont non seulement pas stylés en bloc par défaut, mais également qu'on ne peut leur appliquer aucun style de quelque manière que ce soit.

Une technique alternative consiste à déclarer ces éléments au préalable en JavaScript. Un script (nommé html5shim ou html5shiv) est prévu à cet effet et mis à disposition à cette adresse :

<!--[if lt IE 9]>
<script src="//html5shim.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->

Étant muni d'un commentaire conditionel, il ne sera chargé que pour ces versions spécifiques (Internet Explorer 6 à 8 inclus).

Pour tous les autres moteurs de navigateurs récents, il ne sera pas nécessaire d'appliquer une telle astuce : même si ces éléments n'auront pas de signification particulière pour le moteur de rendu, il sera possible de leur appliquer des styles CSS s'ils ne sont pas affichés en bloc par défaut.

Si vous utilisez déjà une bibliothèque telle que Modernizr, il ne sera pas nécessaire d'appliquer un autre script (tel que html5shim) car celle-ci embarque déjà une déclaration équivalente.

Exemples de documents

Exemple minimal

Voici un schéma basique d'un découpage d'une page HTML5. Précisons bien qu'il ne s'agit pas d'une règle fixe à appliquer à tout document mais juste d'un exemple.

L'en-tête <header>

Plutôt que de se cantonner à un simple <div id="header"> le nouvel élément <header> convient parfaitement à l'introduction d'un document. Tout comme l'élément <nav> qui remplace avantageusement <div id="menu">.

Le contenu principal et annexe

L'élément aside revêt le rôle de barre latérale, et l'élément section est appelé pour regrouper le contenu principal.

Le <footer>

Sans suprise l'élément footer est destiné au pied-de-page. Il peut accueillir des mentions spécifiques, un rappel du titre et du logo, des liens de navigation, etc.

Remarque

Finalement, il suffit de considérer qu'il s'agit d'un remplacement pragmatique de certains éléments, ayant eu un identifiant proche (id="header", id="navigation", id="content"...). Mais ce n'est qu'une impression. Se limiter à ce constat serait incomplet. L'usage de ces nouveaux éléments doit se faire à bon escient.

Exemple détaillé

Le schéma suivant est plus précis et se concentre sur chaque <article>. Il démontre que éléments de section ne se limitent pas à un simple découpage et à une application de styles graphiques mais bien à une meilleure classification sémantique de l'information.

Démonstration

On retrouve ici header, aside, footer alors qu'ils sont déjà utilisés dans d'autres parties du document. C'est un critère important : l'utilisation de ces éléments n'est pas limitée à une occurence par page. Ils peuvent très bien s'appliquer à des contenus locaux, par exemple dans <article> qui représente déjà une portion de contenu. Il peut donc possèder (entre autres) : un en-tête header (avec des titres, des informations sur la date de publication et l'auteur), un pied d'article footer, des infos complémentaires dans un ou plusieurs aside etc.

Les balises en détail

<section>

C'est la plus générique : elle est utilisée lorsqu'aucun autre élément de section n'a pu lui être préféré. Il ne faut cependant pas la confondre avec l'élément div qui n'a aucune valeur sémantique. Les deux ne sont pas interchangeables. La section regroupe un ensemble de contenu d'une même thématique, ou bien un ensemble d'éléments offrant une fonctionnalité spécifique dans une application web.

Pour résumer, on utilise l'élément <section> généralement quand :

• Ce n'est pas une balise employée uniquement pour styler un élément voire plusieurs éléments
• D'autres éléments de section ne sont pas appropriées (article, aside ou nav)
• Il contient naturellement un titre d'introduction

<section>
  <h1>Articles</h1>
    
  <article>
       ...
  </article>
</section>

Documentation sur l'élément <section>

<article>

C'est une spécialisation de section. On pourrait d'ailleurs hésiter entre ces deux éléments. L'élément article possède une plus forte valeure sémantique car il est "autosuffisant". Son contenu est donc réutilisable tel quel dans un autre endroit (un flux RSS par exemple), et il est fréquent qu'il soit présent au côté d'autres frères dans un même document.

<article>
  <h1>Titre de l'article</h1>
  <p>Contenu de l'article</p>
</article>

Documentation sur l'élément <article>

<aside>

L'élément aside est destiné au contenu indirectement lié à l'article lui-même : il représente ce qui l'entoure, de façon annexe. Par exemple, on pourra s'en servir pour proposer la définition d'un terme, une biographie de l'auteur de l'article, un glossaire, préciser des sources, une liste d'articles en relation... aside n'est donc pas forcément dédié au seul usage d'une barre de contenu latérale.

<aside>
  <h4>Sources de l'article</h4>
  <ul>
    <li><a href="#">Lien 1</a></li>
    <li><a href="#">Lien 2</a></li>
    <li><a href="#">Lien 3</a></li>
  </ul>
</aside>  

Documentation sur l'élément <aside>

<header>

L'élément <header> représente l'en-tête d'une section (section, article...) ou d'une page entière. Il peut contenir un logo, un ou plusieurs titres, d'autres informations d'introduction, une navigation, un formulaire de recherche général.

<article>
  <header>
    <h1>Titre de l'article</h1>
    <p>Auteur : bidule</p>
  </header>
    
  <p>Contenu de l'article</p>
</article>

Documentation sur l'élément <header>

<footer>

L'élément footer représente le pied de page, ou bien la conclusion d'une section. On y place des informations concernant l'auteur, des mentions légales, une navigation ou une pagination (en combinaison avec <nav>), un logo de rappel, des coordonnées, des dates de publication.

<article>
  ...
  <footer>
    <p>Posté par Simon, le 
      <time datetime="2012-02-02">2 février 2012</time>
    </p>
  </footer>
</article>

Documentation sur l'élément <footer>

<nav>

L'élément <nav> est une section de liens de navigation. On peut l'utiliser pour la navigation principale, mais également pour d'autres parties du document devant lister des liens de navigation interne.

<nav>
  <ul>
    <li><a href="index.html">Page d'accueil</a></li>
    <li><a href="contact.html">Contact</a></li>
  </ul>
</nav>

Documentation sur l'élément <nav>

Conclusion

HTML5 dispose d'éléments bien pensés pour un meilleur balisage sémantique de l'information. Le plus difficile n'est pas d'écrire ces nouvelles balises, mais bien de comprendre leur usage. Les confusions qui peuvent survenir (section dans article ou vice-versa par exemple) risquent de créer de longs débats quant à leur emploi : il faudra être vigilant.

Son usage est très simple, il suffit de copier-coller les quelques lignes générées dans le code source de la page, ou bien dans un fichier externe, puis d'exploiter l'objet Modernizr et ses propriétés (par exemple Modernizr.canvas, Modernizr.fontface, Modernizr.geolocation etc), initialisées aux valeurs booléennes true ou false. La méthode Modernizr.load vise aussi à faciliter le chargement de scripts tiers. Enfin, la bibliothèque embarque une déclaration des éléments HTML5 pour les anciennes versions d'Internet Explorer afin de permettre l'emploi de styles sur ces derniers.

Attention : il ne s'agit pas de moderniser les navigateurs mais uniquement de procéder à une détection, pour éventuellement utiliser d'autres scripts en complément, apportant des fonctionnalités non supportées.

Inaugurés avec HTML5, les éléments <figure> et <figcaption> fonctionnent de concert pour associer une légende à une illustration ou un autre élément média.

<figure>
  <img src="image.jpg" alt="" />
  <figcaption>Légende associée</figcaption>
</figure>

Élément <figure>

<figure> est une unité de contenu, c'est-à-dire que cet élément sert de conteneur dans lequel s'insèrent divers éléments comme des images, des schémas, des vidéos, des tableaux ou encore des blocs de code. L'objectif est de lier ce contenu à une légende, définie par l'élément <figcaption> (facultatif).

Élément <figcaption>

Enfant direct de <figure>, son rôle est de légender son parent, sous forme de texte et/ou de liens. Il peut se placer avant ou après le contenu principal de <figure>.

Quelques applications dans le monde du livre

Ce fonctionnement se retrouve dans de nombreux ouvrages, y compris les premières encyclopédies pour lesquelles on imprimait des planches de figures à part.

Compatibilité navigateur des éléments <figure> et <figcaption>

Navigateurs	Versions
	Internet Explorer 9.0+
	Firefox 3.0+
	Chrome 4.0+
	Safari 3.1+ iOS Safari 3.2+
	Opera 9.0+ Opera Mini 5.0 + et Mobile 10.0
	Android Browser 4.0+

Un navigateur n'implémentant pas ces éléments affichera le contenu au format brut, sans présentation particulière. Par défaut, le style appliqué est display:block sur les deux éléments, ainsi que des marges sur <figure>. Sous IE<9 il faudra appliquer un shim pour pouvoir leur appliquer un style bloc.

Applications sur le web

Utilisation sans légende

Il est tout à fait envisageable d'insérer <figcaption> avant l'image voire de ne pas le mettre du tout car il est facultatif.

<figure>
  <img src="un-gout-de-fraise.jpg" alt="Proposition pour le thème : Un goût de fraise" />
</figure>

Démonstration

Les différents éléments peuvent être stylés en CSS. Dans cet exemple ont été ajoutées à <figure> une bordure et une couleur de fond blanche.

Une image avec sa légende

Dans son usage le plus courant, l'élément <figure> contient une image puis sa légende <figcaption>. 

<figure>
  <img src="un-gout-de-fraise.jpg" alt="" />
  <figcaption>Proposition pour le thème : <br><em>Un goût de fraise</em> du jeu <a href="http://www.photogame.fr/">PhotoGame</a></figcaption>
</figure>

Démonstration

Utilisation avancée

Il est prévu de pouvoir regrouper une liste d'images et ainsi les lier à l'aide d'un unique élément <figcaption>.

Une liste d'images

<figure>
  <img src="porto1.jpg" alt="Graffiti dans le sud de Porto" width="181" height="242">
  <img src="porto2.jpg" alt="Balcons dans une rue de Porto" width="181" height="242">
  <img src="porto3.jpg" alt="Chat somnolant au sud de Porto" width="181" height="242">
  <figcaption>Photo d'un voyage à Porto. Ville emplie de graffitis, balcons loufoques et chats profitant des quelques ruines derrière la ville.</figcaption>
</figure>

Démonstration

Un bloc de code

Les illustrations ne sont pas les seuls éléments HTML à pouvoir profiter de <figure> et <figcaption>. On peut également les appliquer à un bloc de code source.

<figure>
   <pre>
      <code>
        <!-- Le code source à exposer -->
      </code>
   </pre>
   <figcaption>Description du code source présenté</figcaption>
</figure>

Démonstration

Une vidéo

Le même principe est appliqué à la balise <video>. Voir aussi l'article : Introduction à la balise <video>.

<figure>
    <video src="video.ogv" width="640" height="480"></video>
    <figcaption>Description de la vidéo</figcaption>
</figure>

Les diagrammes et autres graphes dynamiques

Du côté de Canvas et SVG, le document peut également en profiter. HTML5 ne compte pas que <figure> et <figcaption> dans ses nouveaux éléments mais également <canvas>, qui vous permettra de créer, en association avec JavaScript, des diagrammes, des graphiques, et tout ce qu'une surface de dessin permet de faire. À ce sujet, consultez l'article de David Rousset : Introduction aux APIs graphiques d’HTML5: SVG & Canvas

Choisir <figure> ou <aside> ?

Ces deux éléments sont des unités de contenu mais n'ont pas le même rôle sémantique. Tandis qu'<aside> n'est pas essentiel pour la compréhension de la page (il ne doit être qu'un apport tangentiel), <figure> est lié à celle-ci : il transmet un contenu pertinent, lié au contenu principal, comme le serait une image classique.

Nous pouvons donc résumer la chose comme suit :

• <aside> : son contenu est périphérique à la page, et son absence ne doit pas gêner la compréhension de celle-ci.
• <figure> : son contenu contribue à donner du sens et de la compréhension à la page, et son placement n'est pas déterminant.

Propriétés des éléments

<figure>

<figcaption>

• CSS : Support de 3D-Transforms
• HTML : Support de l'élément <bdi>
• HTML5 : Meilleure implémentation de IndexedDB
• Nouvel inspecteur de document et de styles CSS
• Anti-aliasing pour WebGL
• Activation du mode plein écran (Fullscren API)
• Mises à jour automatiques en tâche de fond
• Meilleure prise en charge des extensions
• Prise en charge de l'API Touch Events pour la version mobile et meilleure accélération matérielle avec OpenGL ES

Il s'agit également de la première version qui soit estampillée ESR (Extended Support Release), pour rassurer et déployer une version maintenue à long terme surtout dans le monde de l'entreprise. Téléchargement : Windows, Mac OS X, Linux.

Pour les développeurs web, on notera une grande refonte de l'inspecteur HTML/CSS intégré au navigateur, qui se rapproche des outils les plus agréables à utiliser à ce jour.

Une vidéo de démonstration en fait la promotion :

Et pour les prochaines versions, que nous prépare Mozilla ? Parmi ce qui est prévu : migration des paramètres depuis Chrome, amélioration de la lisibilité du texte, support de Flash sur Android, vue 3D dans l'inspecteur de code, éventuellement support du protocole SPDY. À plus long terme, la volonté est de pouvoir créer des web apps mieux intégrées au système d'exploitation, d'améliorer l'interface générale (onglets, téléchargements, accueil) et de rendre les mises à jour encore plus transparentes pour l'utilisateur.

Un document HTML5 minimal

Sans surprise, les bases d'un code HTML5 ressemblent beaucoup à celles rédigées à l'aide des précédentes versions HTML 4 et XHTML 1.x. Rétro-compatibilité oblige. On y retrouve donc un doctype suivi des éléments les plus courants : <html>, <head>, <title>, <meta>, <link>, <script> et <body>.

<!doctype html>
<html lang="fr">
<head>
  <meta charset="utf-8">
  <title>Titre de la page</title>
  <link rel="stylesheet" href="style.css">
  <script src="script.js"></script>
</head>
<body>
  ...
  <!-- Le reste du contenu -->
  ...
</body>
</html>

Le doctype

La première ligne d'en-tête a été considérablement simplifiée. On peut maintenant retenir un doctype par coeur, sans avoir à le copier-coller.

<!doctype html>

Ce doctype allégé a été mûrement testé et réfléchi : il permet toujours - pour les anciens navigateurs - de rester dans le mode d'interprétation conforme aux standards et d'éviter le mode quirks. On peut remarquer qu'il n'y a pas d'allusion à un quelconque numéro de version. Son rôle est toujours de préciser quel est le type de document qui va suivre, afin de permettre au navigateur de savoir quel langage de la vaste famille SGML il devra interpréter.

L'élément racine <html>

C'est lui qui va recueillir les deux principaux éléments de la hiérarchie : <head> et <body>.

L'attribut lang (sur <html>)

On a tendance à l'oublier : l'attribut lang précise la langue utilisée pour le contenu de la page, lorsqu'il est placé sur la racine <html>.

<html lang="fr">

Une langue bien indiquée sera utile ainsi aux synthèses vocales (pour adopter le bon accent).

Les fameux <head> et <body>

À ce niveau, le code HTML peut être divisé en deux parties : l'en-tête située entre les balises <head> et </head>, qui regroupe toutes les méta-informations, c'est-à-dire les données qui ne sont pas représentées directement à l'écran dans le rendu du document, mais qui lui sont tout de même liées : le titre dans <title> (extrêmement recommandé), les autres méta-informations variées (facultatives : mots-clés, description générale de la page) dans zéro ou plusieurs <meta>, et éventuellement <link>, <script> ou <style>.

La deuxième partie comprend le corps à proprement parler, c'est-à-dire <body>. On y retrouvera tout le reste du contenu HTML, structuré par des balises variées - selon ce que l'on aura à y placer - et dont l'apparence sera affectée par les styles CSS chargés dans <link> et/ou <style>.

L'attribut charset (sur <meta>)

Préciser l'encodage des caractères est primordial pour exploiter la bonne page de code et ne pas se retrouver avec les caractères spéciaux ou accentués. Le choix de l'UTF-8 est désormais préconisé par le W3C pour tous les protocoles échangeant du texte sur internet (dont HTML).

<meta charset="utf-8">

On retrouvera donc très souvent ce codage de caractères, par contre il faut toujours veiller à ce que l'éditeur permettant de coder en HTML (que ce soit un IDE tout-en-un ou un simple éditeur de texte) enregistre le fichier avec le bon encodage, et non en Latin-1 (alias ISO-5589-1) ou ANSI si la balise <meta> indique UTF-8.

Veillez à toujours placer cette déclaration d'encodage avant toutes les autres balises contenues dans la section <head>. En effet, celles-ci sont immédiatement concernées, par exemple <title> qui peut déjà faire appel à des caractères en UTF-8 ; ceci également dans un but de sécuriser l'interprétation des caractères spéciaux et prévenir les injections de contenu indésirables.

L'élément <link>

Dans la majorité des cas, une balise <link> placée dans l'en-tête permet de mettre en relation la page avec d'autres documents externes. La plupart du temps cela concerne les feuilles de style CSS externes avec une relation du type stylesheet, mais il est aussi possible de définir d'autres types de relations (par exemple avec author, icon, prefetch, next, prev, etc).

<link rel="stylesheet" href="style.css">

En HTML5, il n'est plus strictement obligatoire de spécifier l'attribut type.

Pour inclure directement des instructions CSS dans le document HTML sans passer par un fichier externe, <style> est à votre service. Cependant, il vaut mieux faire confiance à un fichier indépendant : il n'y aura qu'un seul code à maintenir pour de multiples pages (voire pour tout le site), et la mise en cache par le navigateur n'en sera que plus efficace.

L'élément <script>

Cet élément permet d'ajouter des scripts (JavaScript) qui vont s'éxécuter côté client dans le navigateur dès leur chargement.

<script src="script.js"></script>  

En HTML5, il n'est plus obligatoire de spécifier l'attribut type. Celui-ci est de toute manière interprété par défaut en text/javascript par tous les navigateurs.

Les autres éléments HTML5

Une fois la structure de base préparée, il est temps de commencer à y placer d'autres éléments HTML pour le contenu à proprement parler : paragraphes, listes, liens, images, vidéos, tableaux de données, formulaires, etc. La majorité des éléments HTML sont toujours au rendez-vous dans HTML5, qui se voit complété par quelques nouveautés pour le balisage. Par exemple :

• Éléments de section <section>, <article>, <header>, <footer>, <nav> et <aside>
• Élément <datalist>
• Éléments <details> & <summary>
• Éléments <figure> & <figcaption>
• Éléments média <audio> et <video> complétés par <source>
• Élément <canvas>
• Éléments <meter>, <output> et <progress>
• Élément <time> et <mark>
• Et tous les autres, que l'on peut retrouver dans une liste complète maintenue par le W3C : HTML : The Markup Language

Pour rappel, tous les nouveaux éléments HTML5 ne sont pas nécessairement reconnus de façon native et cohérente par tous les navigateurs (même les plus récents). Pour certains, il sera possible de trouver des alternatives avec des compléments en JavaScript. Pour d'autres, il faudra patienter jusqu'à une implémentation totale, et évaluer le risque selon le besoin : un nouvel élément sera-t-il tout de même consultable, masqué, ou géré de façon erronée ?

Pour juger de l'état de la prise en charge par les navigateurs, fiez-vous à Caniuse.com qui dresse des tableaux de support complets, ou bien encore à HTML5Please, qui indique de façon rationnelle par rapport aux parts de marché ce qu'il est possible d'utiliser en production pour un maximum de visiteurs.

Templates et boilerplates

Des modèles réfléchis et structurés existent pour faciliter le démarrage d'un nouveau projet web autour de HTML5, et de ses futures évolutions. Ils reprennent la structure globale d'un document, en y ajoutant quelques bonnes pratiques, avec parfois des fichiers de configuration pour le serveur et des feuilles de styles de base, voire même des librairies JavaScript.

HTML5 Boilerplate

HTML5 Boilerplate

Initializr

Initializr 2 par Jonathan Verrecchia

HTML KickStart

HTML KickStart par 99lime

Jetez-vous à l'eau !

Comme on peut le constater, démarrer un document HTML5 est facilement abordable, et reste rétro-compatible, pour peu que les nouveaux éléments soient intégrés de façon intelligente. Étant donné que cette nouvelle version du langage embarque la grande majorité des éléments déjà connus par les précédentes moutures, il n'y aura pas de risque de s'y aventurer progressivement.

HTML5 propose de nouveaux éléments qui ont pour objectif de faciliter l'intégration de médias, d'utiliser des composants plus dynamiques sans avoir besoin de faire appel - à plus long terme - à des extensions propriétaires (Flash, Java, Silverlight). Le balisage propose également d'obtenir une meilleur sémantique, avec tous les aspects bénéfiques qui en découlent (accessibilité, référencement, syndication, interprétation par les moteurs de rendu, etc.)

HTML5 siginifie-t-il obligatoirement l'utilisation de CSS 3 ? Dois-je tout réapprendre ? Pour répondre à ces questions, un article est prévu à cet effet : Les 5 mythes et vérités de HTML5

Appel à orateurs...

Si vous désirez participer à cet événement en tant qu'orateur, faites-nous part de votre candidature et de vos idées en remplissant le formulaire d'Appel à Orateurs.

Nous organiserons a priori deux sessions de conférences en parallèle : une présentation de 45min en grande salle ainsi que des mini-conf / ateliers de 20 minutes.

Le choix sur le contenu se fera durant le mois de mars et sera détaillé sur le site de la Kiwi Party, nous vous tiendrons bien évidemment informés dès que possible.

Information importante : il s'agit d'un événement dont tous les frais sont intégralement couverts par des sponsors et par Alsacréations. Nous tenons à dédommager autant que faire se peut les orateurs pour leurs déplacements ou hébergements, mais nous ne pourrons certainement pas couvrir tous les frais engagés. À titre d'exemple, la moyenne des défraiements s'élevait autour de 100 euros par orateur l'an passé.

... et aux sponsors

Les sponsors ont un rôle prépondérant pour cet événement puisque c'est grâce à eux qu'il peut avoir lieu et accueillir autant de participants. L'an passé, grâce à Epitech, Kiubi, Eyrolles, Dunod et Devclic, nous avons pu être accueillis dans de magnifiques locaux au centre de Strasbourg, pu rembourser une partie des frais des orateurs, et disposer de lots pour les gagnants du Quiz.

Nous souhaiterions bien évidemment réitérer ces petites attentions cette année et accueillerons avec plaisir tout partenaire qui nous permettrait d'offrir des lots lors des jeux organisés durant la journée ou de participer aux frais.

Sponsors, contactez-nous !

Élément <details>

Cet élément permet de baliser un contenu quelconque (texte, image, listes, tableaux, formulaires, etc) ayant pour rôle d'apporter une information ou des détails supplémentaires. Ceux-ci ne doivent cependant pas être obligatoires pour poursuivre la bonne marche de l'application web ou la compréhension du document HTML.

Le navigateur pourra masquer ces informations par défaut, et les déployer à la demande de l'utilisateur (voir exemples visuels ci-après). Une icône pourra indiquer l'état de l'élément : déployé (visible) ou compacté : seul le résumé reste visible. Ce résumé, assimilable à un titre ou une légende, est apporté par <summary>.

Attribut open de l'élément <details>

Si cet attribut est présent, les détails sont exposés à l'utilisateur dès le chargement.

Élément <summary>

Cet élément sert d'intitulé à <details>, en cela il doit être pertinent. Sa fonction s'apparente à une légende ou un résumé donnant du sens au contenu de son parent. Seul <details> peut-être le parent de <summary>. Si <summary>n'est pas présent, il incombe au navigateur de déterminer le libellé de <details>.

Exemples pratiques retrouvés sur systèmes d'exploitation

L'intérêt de ces deux éléments fonctionnant de concert est de mimer ce que l'on retrouve déjà couramment avec les interfaces graphiques des systèmes d'exploitation. Un intitulé est présenté à l'utilisateur, résumant parfois un état, et permettant d'accéder - généralement après un clic - à d'autres informations détaillées.

Compatibilté navigateur des éléments <details> et <summary>

Navigateurs	Versions
	Chrome 12.0+
	Android Browser 4.0+

Un navigateur ne supportant pas ces éléments affichera leur contenu sans comportement particulier.

Utilisation classique

L'élément <details> contient l'élément <summary> lui servant d'intutilé ou de légende, à la suite de celui-ci nous retrouvons le contenu à afficher ou masquer. L'attribut open affichant par défaut le contenu. Pour une utilisation classique l'icône par défaut est une flèche : ►

<details open>
   <summary>Caractéristiques techniques</summary>
   <table>
      <tr>
         <th>Nom</th>
         <th>Détails</th>
      </tr>
      <tr>
         <td>Matière</td>
         <td>Inox alimentaire</td>
      </tr>
      <tr>
         <td>Dimensions</td>
         <td>140x120 mm, hauteur 30 mm</td>
      </tr>
   </table>
</details>

L'élément <details> peut aussi contenir des éléments de formulaire.

<form>
   <label for="quantite">Quantité : </label>
   <input type="number" name="nombre" id="quantite">

   <details>
      <summary>Options possibles</summary>
      <fieldset>
      <legend>Choix de la couleur :</legend>
         <p>
         <input type="radio" id="d1" name="couleurs"><label for="d1">Gris</label>
         <input type="radio" id="d2" name="couleurs"><label for="d2">Rouge</label>
         <input type="radio" id="d3" name="couleurs"><label for="d3">Vert</label>
         <input type="radio" id="d4" name="couleurs"><label for="d4">Bleu</label>
         </p>
      <fieldset>
   </details>
   <input type="submit" value="Ajouter au panier">
</form>

Démonstration

Aperçu sous Chrome 16.0

Accessibilité

Dans cet exemple, le groupe de boutons radio est entouré d'un élément <fieldset> (et donc précédé d'un élément <legend> pertinent), comme le demande la Technique WCAG 2.0 H71: Providing a description for groups of form controls using fieldset and legend elements (voir les critères 11.5 à 11.7 du référentiel Accessiweb 2.1 pour les critères de succès WCAG 2.0 et tests RGAA correspondants).

C'est cet élément fieldset qui est entouré d'un élément <details> (et précédé d'un élément <summary>). Une variante de l'exemple où figurerait seulement les 5 boutons radio et leurs étiquettes ainsi que les éléments summary et details aurait été plus courte mais sans fieldset ni legend, la fonction des boutons radio n'est plus explicitée, en particulier dans les lecteurs d'écran actuels.

Concernant l'accessibilité générale des éléments <details> et <summary> ceux-ci ne sont pas accessibles au clavier car il n'est pas possible d'atteindre le marqueur (icône) via la tabulation dans le navigateur l'implémentant début 2012. HTML5 Doctor aborde le sujet, se référer à son article sur ces éléments.

Aller plus loin

Combinaison multiple

Plusieurs blocs <details> peuvent être imbriqués les uns dans les autres, cette pratique reste tout à fait valide.

Modifier le style de l'icône

Il n'y a pas de convention actuellement définie et reconnue par tous les navigateurs pour accéder aux propriétés CSS. Néanmoins avec le moteur WebKit et la pseudo-classe ::-webkit-details-marker vous pouvez modifier l'icône (en forme de flèche par défaut). Le sélecteur details[open], permet de styler l'icône lorsque <details> est déployé.

summary::-webkit-details-marker {
   color:#ADCA48;
   background:#ADCA48;
}

details[open] summary::-webkit-details-marker {
   color:#eaeaea;
   background:#eaeaea;
   outline: 2px solid #ADCA48;
}

Démonstration

Aperçu sous Chrome 16.0

Il est également possible de changer l'icône par défaut à l'aide de la  pseudo-classe :after

summary::-webkit-details-marker {
   display: none
}

summary:after {
   content: "+";
   color: #ADCA48;
   float: left;
   font-size: 1.5em;
   font-weight: bold;
   margin: -5px 5px 0 0;
   padding: 0;
   text-align: center;
   width: 20px;
}

details[open] summary:after {
   content: "-";
}

Démonstration

Aperçu sous Chrome 16.0

Alternative en JavaScript

Voici une alternative basée sur jQuery pour les navigateurs n'implémentant pas encore les éléments <details> et <summary>. Il est important de savoir que ces éléments peuvent être utilisés quelle que soit la prise en charge. Si l'effet est déjà fonctionnel avec des éléments neutres <div> et un complément en JavaScript, il sera profitable de s'orienter vers <details> et <summary> pour les navigateurs qui les supportent nativement, et de continuer à exploiter la version en JavaScript pour les autres.

Tout d'abord faites appel à votre script dans lequel vous intégrerez la fonction permettant d'afficher/masquer les éléments et la dernière version de jQuery en les insérant juste avant la balise de fermeture </body>

  <script src="https://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"></script>
  <script src="details-summary.js"></script>
</body>

Dans votre fichier details-summary.js, il vous faudra vous assurer que la page est chargée, une fois celle-ci prête il est important de vérifier que le navigateur n'implémente pas les éléments <details> ou <summary> afin de ne pas lancer le script si tel est le cas :

$(document).ready(function() {
 if (!('open' in document.createElement('details'))) {

Une fois la condition validée, pour chaque élément <details> on affiche "son" <summary> à l'aide de la méthode show(). Pour procéder à la détection, l'utilisation de Modernizr peut être plus avantageuse.

Et lorsque l'on clique sur l'élément <summary> une fonction permet d'afficher ou masquer les frères de celui-ci, c'est-à-dire le contenu. Puis on ajoute ou enlève la classe open à l'élément <details> ainsi que la classe html5_details.

    $("details").each(function() {
      $(this).find("summary").show().click(function() {
        $(this).siblings().toggle();
        $(this).parent('details').toggleClass('open');
      });

Avant de fermer la fonction, il reste encore à masquer le contenu si l'attribut open n'est pas présent au sein de la balise <details>. On stocke dans une variable l'attribut open. On vérifie s'il est absent, si tel est le cas, on masque les enfants de <details> excepté <summary> que l'on affiche. 

      var opened = $(this).attr("open");
      if(opened==undefined) {
        $(this).children().hide();
        $(this).children("summary").show();
      }
    });

  // Fermeture de la condition et de $(document).ready
  }
});

Le script établit le comportement dynamique, mais cela n'est pas suffisant pour la présentation : il faut encore ajouter l'icône et cela se passe du côté de la feuille de styles CSS. Rien de plus simple, grâçe à la pseudo-classe ::before et à la classe .open :

.html5_details > summary::before {
  content:"►"; margin-right:"5px";
}
.html5_details.open > summary::before {
  content:"▼"
}

Démonstration

Vous obtenez ainsi le même affichage que par défaut.

Il existe d'autres alternatives :

• <details> fallback via jQuery par Mathias Bynens
• Un autre polyfill <details>, aussi basé sur jQuery par Manuel Bieh
• jquery-details par Denis Sokolov

Propriétés des éléments

<details>

<summary>

Ressources en ligne

• Les éléments <details> et <summary> vus par le WhatWG
• Pages des éléments <details> et <summary> par le W3C

Inauguré avec la vague HTML5, <datalist> est un élément de formulaire permettant de lier une liste de choix à un élément input. Il est voué à fournir des fonctionnalités d'auto-complétion ou d'auto-suggestion, dans un formulaire classique ou un champ de recherche, voire à d'autres éléments d'entrée, tels que les nouveaux types <input type="range">.

Par défaut, <datalist> demeure invisible. Lors de la frappe, ou en appuyant sur la touche ↓ (flèche bas) , la liste de choix apparaît et autocompléte le champ de formulaire rattaché.

Compatibilté navigateur de l'élément <datalist>

Navigateurs	Versions
	Firefox 4.0+
	Opera 9.0+ Opera Mobile 10.0+
	Internet Explorer 10+

Un navigateur ne supportant pas l'élément n'affichera aucune suggestion. Le champ <input> lié restera cependant totalement fonctionnel, l'entrée sera libre. L'exemple présenté dans cet article ne fonctionne que sur les navigateurs compatibles. Pour les alternatives, se rapporter au dernier point.

Utilisation classique

Dans la majorité des situations, il sera utile d'associer un champ d'entrée texte <input type="text"> à une liste de suggestions.

<label for="choix_bieres">Indiquez votre bière préférée :</label>
<input list="bieres" type="text" id="choix_bieres">
<datalist id="bieres">
  <option value="Meteor">
  <option value="Pils">
  <option value="Kronenbourg">
  <option value="Grimbergen">
</datalist>

Démonstration

Aperçu sous Internet Explorer 10

Le champ de formulaire (input) et la liste de suggestions (datalist + option) sont reliés grace à la valeur commune des attributs list rattaché à l'input, et id de la datalist.

Utilisation multiple

Il est possible d'utiliser la même liste de suggestions pour plusieurs champs de formulaire. Cela peut être pratique pour les champs dupliqués, il n'y a ainsi qu'une seule liste à maintenir.

<p>
  <label for="choix_bieres">Indiquez votre bière préférée :</label>
  <input list="bieres" type="text" id="choix_bieres">
</p>

<p>
  <label for="choix_bieres_ami">Indiquez le choix de votre ami :</label>
  <input list="bieres" type="text" id="choix_bieres_ami">
  <datalist id="bieres">
    <option value="Meteor">
    <option value="Pils">
    <option value="Kronenbourg">
    <option value="Grimbergen">
  </datalist>
</p>

Démonstration

Alternative vers <select>

Pour les navigateurs ne supportant pas <datalist>, une alternative simple peut être trouvée en complétant le formulaire par un <select>. Le champ primaire reste libre, tandis que la liste de choix est présentée pour ces navigateurs.

<label for="www">Adresse web</label>
<input id="www" type="url" list="urldata" name="adresseweb">
<datalist id="urldata">
  <label for="adresse">ou sélectionner dans la liste</label>
  <select name="adresse" id="adresse">
    <option value="http://www.alsacreations.com/">http://www.alsacreations.com/</option>
    <option value="http://www.bing.com/">http://www.bing.com/</option>
    <option value="http://www.google.fr/">http://www.google.fr/</option>
    <option value="http://www.yahoo.fr/">http://www.yahoo.fr/</option>
  </select>
</datalist>

Démonstration

Il appartient ensuite au script traitant les données côté client (navigateur) ou côté serveur de déterminer de quel champ proviennent les données : a priori il faudra prendre en compte la liste de choix uniquement si le champ est laissé libre.

Dans le même ordre d'esprit, un contenu texte stocké dans <datalist>, en-dehors des options, sera affiché par les navigateurs qui ne reconnaissent pas cet élément.

<datalist>
  Votre navigateur ne supporte pas datalist en HTML5
  <option value="option1">Choix1</option>
  <option value="option2">Choix2</option>
  <option value="option3">Choix3</option>
</datali>

Valeurs possibles pour les options

L'étiquette affichée est définie par l'attribut label. Cependant, il est important de garder à l'esprit que la valeur utilisée au final est celle donnée aux attributs value des éléments <option> et non à leur contenu (situé entre la balise ouvrante et la balise fermante) ou à la présence de l'attribut label.

<datalist id="elements">
  <select>
    <option value="sans label ni contenu"></option>
    <option value="sans label avec contenu texte">le texte</option>
    <option value="avec label" label="le label"></option>
    <option value="avec label et texte" label="le label">le texte</option>
  </select>
</datalist>

Si des valeurs différentes sont spécifiées pour deux ou trois de ces possibilités (value, label ou contenu texte), par exemple <option value="kro" label="Kronenbourg, la bière">Kronenbourg</option> le comportement des navigateurs sera disparate :

• Internet Explorer 10+ se comportera de façon correcte,
• Opera 9+ affichera un maximum d'informations en combinant value et label mais pas le texte contenu,
• Mozilla Firefox 9+ affichera de préférence le label, puis le contenu texte, puis la valeur figurant dans l'attribut value

Démonstration

Pour les navigateurs ne supportant pas <datalist>, l'élément <select> est toujours affiché en dernier recours, mais ses options sont aussi affectées par les précédentes informations, mais avec une meilleure cohérence dans l'interprétation : toutes les options sont affichées de la même façon. Notons aussi que les options ne peuvent être groupées avec <optgroup> comme dans une liste de choix <select>.

Autres éléments concernés

La liste de données peut être potentiellement appliquée à d'autres éléments d'entrée, et n'est pas limitée à un <input type="text">. Si le navigateur le supporte, elle a pour vocation d'épauler d'autres types, par exemple <input type="range">, <input type="email" multiple> ou <input type="url">.

<label for="lumi">Luminosité</label>
<input id="lumi" type="range" list="lumidata" min="0" max="100" value="50" step="1">
<datalist id="lumidata">
  <option label="Minimum" value="0">
  <option label="Maximum" value="100">
</datalist>

<label for="www">Adresse web</label>
<input id="www" type="url" list="urldata">
<datalist id="urldata">
	<option value="http://www.alsacreations.com/">
	<option value="http://www.bing.com/">
	<option value="http://www.google.fr/">
	<option value="http://www.yahoo.fr/">
</datalist>

Aperçu sous Opera 11.6

Caractère dynamique

Le contenu de l'élément <datalist> peut être manipulé dynamiquement dans le document, par JavaScript et l'API DOM notamment. Ceci permet d'ajouter ou de supprimer des options à la demande, par exemple en fonction d'un critère local (une case à cocher, une autre condition) ou en fonction du retour d'un appel AJAX avec XMLHttpRequest, voire avec un framework JavaScript tel que jQuery.

Propriétés de l'élément <datalist>

Alternatives pour les anciens navigateurs

Cet élément étant présent en dur dans le document HTML, des frameworks JavaScript appropriés (jQuery, Dojo...) ou des scripts spécifiques peuvent aller y piocher les informations pour construire une auto-complétion dynamique.

• jQuery HTML5 datalist plugin par miketaylr.
• Relevant Dropdowns par Chris Coyier.
• datalist fallback par adactio.
• Webshims Lib supporte datalist (inclus input[list], input[selectedOption], datalist[options]) par Alexander Farkas.

Nous avons soulevé cette question à la fin de l'année passée, et force est de constater qu'un bon nombre de ressources considérées comme des références dans notre domaine deviennent petit à petit obsolètes, tant le Web, les navigateurs et les standards évoluent constamment.

Les articles et tutoriels proposés sur Alsacreations.com n'échappent pas à cette règle inexorable et c'est pourquoi un grand ménage a été programmé et s'achève en ce moment dans le but de remettre au goût du jour l'ensemble de nos contenus libres.

Sous la houlette de Dew, une petite équipe d'irréductibles modérateurs s'est évertuée pendant plusieurs mois à reprendre un par un plus de 275 documents publiés et leur appliquer les modifications suivantes :

• relecture attentive des informations,
• correction des erreurs (typographiques, syntaxes, codes),
• mise à jour (supports navigateurs, nouvelles spécifications)
• optimisations ergonomiques (sommaires, scission en plusieurs pages),
• ajout ou mise à jour des illustrations des articles

Ce travail de titan, qui sera régulièrement renouvelé par surveillance automatique des dates de mise à jour, nous permet de vous proposer un ensemble de contenus qui devrait toujours coller au plus près de l'actualité, même si vous avez affaire à une "ancienne" ressource. Et c'est bien ce qu'on aimerait trouver lors de toutes nos recherches sur Internet, n'est-ce pas ?

(Photo : Walt Stoneburner)

Avec HTML5, mon site sera plus beau

HTML5 dispose certainement d'un beau logo orange rayonnant inauguré par le W3C pour en faire la promotion, cependant il fonctionne toujours en osmose avec CSS pour régir l'apparence, la présentation, la disposition du contenu.

Cela signifie donc que rien ne change par rapport aux précédentes versions de HTML : il vous faudra toujours jongler avec habileté entre CSS, les images issues de la maquette graphique, éventuellement des effets en JavaScript, du SVG, voire Canvas, pour construire le côté visuel d'un document ou d'une page web.

Avec HTML5, mon site sera plus dynamique et réactif

Là aussi, les mêmes arguments de conception entrent en jeu : sans JavaScript et l'API DOM, l'interactivité reste coite. Or, JavaScript et le DOM sont des technologies qui évoluent depuis un moment déjà, sans avoir attendu HTML5. Les diverses optimisations mises en avant par les versions successives des moteurs d'interprétation font chemin commun.

HTML5 apporte donc des fonctionnalités, mais pas de "rapidité" au sens strict du terme. Le code JavaScript sera interprété exactement de la même façon, navigateur par navigateur.

Avec HTML5, je devrai tout réapprendre depuis zéro

HTML5 a été pensé notamment pour rester majoritairement rétro-compatible avec les précédentes versions de HTML, et faciliter le quotidien des intégrateurs avec une syntaxe quelque peu simplifiée. Si bien que la courbe d'apprentissage est très douce pour ceux qui ont déjà des notions générales concernant HTML.

En revanche, concernant toutes les API, il y a beaucoup à découvrir, pour ne citer que certaines d'entre elles : Web Storage, Web Workers, la géolocalisation, Canvas, Offline Web Applications, Drag & Drop, Server-Sent Events, Web Sockets, Web Messaging, History, et toutes celles qui sont en train de mijoter dans les groupes de travail du WhatWG, du W3C et des éditeurs de navigateurs (Apple, Google, Microsoft, Mozilla, Opera).

La présence d'API (interfaces de programmation) dans HTML5 est rendue nécessaire par les nouveaux besoins qui ont émergé ces dernières années, en termes de mobilité, de multimédia, d'interactions avec l'utilisateur. On ne se limite plus à une spécification de balises mais on s'oriente bien vers un langage puissant pour construire des applications web complètes, en synergie avec JavaScript.

Avec HTML5, je suis dans le Cloud

Refondre un site depuis zéro juste pour dire "je suis passé à HTML5" n'est pas significatif. Quel est le gain attendu ? HTML5 n'est pas un ensemble indissociable de fonctionnalités, il permet une transition douce avec des améliorations ponctuelles ne serait-ce qu'en se limitant aux simples balises et en mettant de côté les API : le balisage sémantique (nouvelles balises de section), les nouveaux éléments bien pratiques (video, audio, formulaires, etc), Microdata.

Et si vous changez le doctype par <!doctype html>, votre site est virtuellement en HTML5, puisque c'est ainsi que le langage est annoncé au navigateur ; mais n'exploitera aucune des nouveautés avant de plonger les doigts dans le code.

Concernant le fameux nuage, HTML5 dispose bien sûr d'API facilitant la mise en place d'applications web exploitant des données distantes (avec Web Sockets, XMLHttpRequest 2, etc), les stockant localement (avec Web Storage), exécutant des fonctionnalités en mode déconnecté (avec Offline Web Applications), et des traitements variés. Il s'agit donc d'un moyen, mais pas une finalité en soi.

Pour HTML5, je dois faire appel à des startups primées à LeWeb©™

Engouement, espoirs, marketing, font que le mot HTML5 est exploité à toutes les sauces, pour promouvoir des produits et services web, qui ne reposent pas nécessairement sur lui. C'est désormais un terme à la mode, pour regrouper tout et n'importe quoi (y compris ce que l'on peut faire avec JavaScript/CSS/AJAX), tout comme l'a été le fameux "web 2.0" et c'est bien dommage. Il n'est donc pas primordial de passer par une multinationale trempant dans le marketing, ou par une jeune pousse ayant procédé à une levée de fonds de quelques millions. Bien au contraire, ce sont les artisans du web qui sont les mieux informés au quotidien et les plus aguerris avec des situations concrètes. La plupart des intégrations réalisées par l'agence web Alsacreations.fr le sont désormais en HTML5, et ce en toute transparence.

Les grandes conférences où se retrouvent les courageux ayant déboursé un billet d'entrée à quelques milliers d'euros pour se taper dans le dos, tout en disant qu'ils vont révolutionner le monde avec des rationalisations de process en HTML5 sont à des parsecs de la réalité. [Ceci est un point de vue strictement personnel qui n'engage pas l'équipe d'Alsacreations]

Les vérités

HTML5 est une technologie d'avenir 

Durant de nombreux mois, les actualités mentionnaient une date de finalisation officielle de la recommandation W3C pour 2022. Or, il s'agit du même principe que pour les spécifications CSS et tous les autres standards qui ont vu le jour progressivement : rien n'empêche de s'en servir avant la publication finale de la recommandation, pour peu que les navigateurs implémentent les fonctionnalités HTML5, et que celles-ci restent stables à moyen ou long terme. Le processus de normalisation des groupes de travail HTML est long : il comprend de nombreux tests et critères de qualité à remplir avant de déclarer officiellement le langage spécifié en tant que standard.

Il s'agit donc bien - désormais - d'une technologie du présent (que des millions de sites exploitent déjà en production) qui a encore de nombreux tours dans sa poche, et de grandes évolutions en perspective. Il est fort probable que l'échelonnement par versions (4, 5...) soit délaissé au bout d'un moment ou modifié, étant donné la nécessaire réactivité face aux changements du web, ainsi qu'aux nouveaux besoins. C'est un choix qu'a déjà fait le WhatWG pour désigner l'ensemble sous le terme de Living Standard.

HTML5 est vaste

Oui, plus qu'avant, sans compter les compléments apportés par JavaScript et CSS, l'empilement des langages et des concepts à maîtriser s'accroît. Il ne faut plus considérer le web comme une soupe de tags. De gros progrès ont été accomplis. La réalisation d'applications web et de documents HTML réclame de plus en plus d'attention, de professionalisme et d'expériences. Les conséquences en termes de référencement, d'accessibilité et d'utilisabilité sont bien plus que jamais mesurées et ressenties à court terme.

Nous avons toujours évolué dans un univers dans lequel nos métiers (graphiste, intégrateur, développeur, administrateur) s'interpénètrent sans frontière nette, et tant mieux : il est toujours bon d'explorer toutes les voies menant à la réalisation d'un projet complet, de savoir quelles sont les implications de chacun. Ceci va aller en s'accentuant, le dynamisme développé côté client (navigateur) faisant de plus en plus appel à des dialogues avec le serveur, et avec un graphisme riche et dynamique.

HTML5 améliore le référencement

Avec une plus forte présence de la sémantique, avec de nouveaux éléments pour baliser le contenu (<output>, <mark>, <time>, <figure>, etc), avec les éléments de section (<article>, <nav>, <aside>, etc) et avec la venue des microformats directement via Microdata, HTML5 met le cap sur un web où tous les contenus seront amenés à être balisés avec soin, à être exploités, indexés, triés. C'est par ailleurs la vocation première de HTML dès ses débuts. Les résultats ne seront pas immédiatement visibles, bien que certains robots mettent déjà à profit les avancées réalisées par ces nouvelles approches. Nous savons tous que les algorithmes des grands moteurs de recherche (Google, Bing, Yahoo) changent jour après jour. À ceci, il n'y a pas de mystère : la seule voie recommandable est celle de suivre celle des bonnes pratiques,  d'éviter tous les artifices, bref, de rester naturel.

HTML5 est plus accessible

Un bon balisage sémantique, propre, utilisé à bon escient, peut améliorer l'accessibilité d'une façon générale. C'est une évidence qui existe depuis les prémices de HTML. De façon plus approfondie et outre les WCAG 2.0 qui peuvent s'appliquer à tout, WAI-ARIA est une démarche active en faveur de l'accessibilité, prise en compte dans la conception de HTML5. Elle est mise en oeuvre en complément de l'attention portée aux autres points et pièges classiques relatifs au web, notamment pour les applications web qui pourraient être construites autour de HTML5. L'abandon des plug-ins propriétaires va en ce sens, avec toutefois des écueils. Par exemple, Canvas reste un trou noir duquel aucune information ne sort. Les éléments média <video> et <audio> voient tout juste le sous-titrage pointer le bout de ses caractères.

Lorsque les agents utilisateurs et les assistants à la navigation (synthèses vocales, etc) exploiteront tous les pans de HTML5 de façon efficace, un grand pas aura été fait en avant. Consultez également l'état des lieux de l'accessibilité en HTML5.

HTML5 a plus d'affinités avec les mobiles et les tablettes

Le taux de renouvellement de ces plate-formes est plus soutenu, ce qui permet un renouvellement plus fréquent du parc des navigateurs mobiles. Ceux-ci supportent de plus en plus de fonctionnalités avancées, dont certaines sont clairement orientées vers la mobilité : les API HTML5 telles que Offline Web Applications, Web Storage, History, la géolocalisation, les nouveaux types pour <input> et les Media Queries (CSS3) sont pensés pour faciliter le développement sur des terminaux devant respecter des contraintes de mobilité (réseau à faible débit, parfois déconnecté, pour une surface d'affichage réduite et des économies d'énergie).

Avertissement : On parle ici de HTML5 en tant que successeur des précédentes spécifications HTML 4.x et XHTML 1.x. Dans l'absolu, l'évolution du langage est motivée par le W3C d'un côté - qui privilégie la numérotation de versions - et par le WhatWG de l'autre - qui préfère parler de "standard vivant" sans lui attribuer de numérotation rigide tant sa maturation doit rester souple et progressive.

Et vous, qu'en pensez-vous ?

Comment ressentez-vous l'agitation actuelle autour de HTML5 et CSS3 ? Avez-vous eu des expériences concluantes ? Abordez-vous avec sérénité les nouveautés ?

Avant que le forum ne soit complètement déserté, je vous souhaite - au nom de tous les contributeurs bénévoles d'Alsacreations.com - de passer d'excellentes Fêtes de fin d'année et de nous revenir en pleine forme pour 2012 !

A l'année prochaine !

(photo par Raphaël Goetter)

Pour rappel, ce partenariat s'effectue sous la forme de livres Eyrolles offerts aux membres "actifs" d'Alsacréations. Le terme "actif" désignant ceux possédant un certain nombre de points Kiwiz (gagnés en publiant articles, tutoriels ou actualités) dans leur besace.

Ce partenariat, devenu dorénavant trimestriel, s'achève aujourd'hui et reprendra au mois de mars sous le même principe. Voici les heureux bénéficiaires de cette Opération n°3 ainsi que leurs gains :

• Igor reçoit "Responsive web design" en échange de 20 kiwiz,
• Geoffrey C. reçoit "Lightroom 3 pour les photographes" et "Photo de portrait" en échange de 70 kiwiz,
• Vaxilart reçoit "HTML5, une référence pour le webdeveloppeur" en échange de 40 kiwiz,
• jojaba reçoit "HTML5, une référence pour le webdeveloppeur" en échange de 40 kiwiz,
• Victor BRITO reçoit "Mémento CSS3" en échange de 20 kiwiz.

Encore un grand bravo à ces bénéficiaires et un grand merci pour leur activité sur Alsacréations. Les ouvrages seront expédiés directement par Eyrolles.

Et à bientôt pour la prochaine édition... gardez vos kiwiz de côté ;)

Et Joyeux Noël !

• Comment récupérer l’émulateur Windows Phone et l’utiliser
• Un point sur les différences entre IE9 Desktop et mobile
• Comment débugger votre code JavaScript avec jsConsole
• Pour finir, comment débugger le trafic réseau entre l’émulateur et le reste du monde grâce à Fiddler

Le but principal de cet article étant de vous faire gagner potentiellement du temps.

L’émulateur Windows Phone

La toute première chose que je vous invite à faire est de télécharger le SDK qui contient l’émulateur ici : Télécharger le SDK Windows Phone . Vous pouvez l’installer sous Windows Vista ou Windows 7.

Il contient également les outils (gratuits) de développement. Si le sujet vous intéresse et que vous souhaitez découvrir cette plateforme, rendez-vous ici : Découvrir la plateforme Windows Phone

Mais revenons au sujet qui nous intéresse. Une fois le SDK installé, vous trouverez l’émulateur dans votre menu démarrer :

Lorsque vous le lancez, vous aurez ce résultat et vous pouvez configurer 2 ou 3 trucs :

Vous pouvez par exemple choisir entre le fait de recevoir par défaut la version mobile du site ou la version bureau.

Détail important à connaitre : pour éviter de taper les URLs avec le clavier virtuel, cliquez dans l’émulateur et appuyer sur la touche “Pause”. Vous devriez ensuite être en mesure de taper avec votre clavier dans l’émulateur.

Voici les autres choses à connaitre sur l’émulateur qui pourront vous aider à créer vos expériences mobiles sur Windows Phone. Gestion de l’orientation présente sur la barre d’options à droite de l’émulateur :

Et voici le résultat :

Autre détail à connaitre, pour que l’orientation s’effectue correctement et soit prise en compte, il faut ré-appuyer sur la touche “pause” si vous l’avez fait précédemment pour utiliser votre clavier. Sinon, vous aurez l’impression de devoir systématique pencher la tête à gauche ou à droite. :)

Vous pouvez aussi simuler de votre position pour la géolocalisation. Prenons par exemple ce site web de démo : IE Test Drive Mobile avec Géolocalisation HTML5 qui utilise justement l’API de géolocalisation.

Voici le résultat par défaut dans l’émulateur :

On vous localise sur Redmond. Donc si vous voulez changer cela (sauf si vous habitez vraiment à Redmond ;-)), vous pouvez le faire en faisant apparaitre une fenêtre supplémentaire. Pour cela, cliquez sur “>>” et mettez une punaise (ou push pin en anglais) à l’endroit souhaité. Voici un exemple où j’en mets un sur la Tour Eiffel et l’application HTML5/JavaScript obtient bien la bonne information :

Cela peut donc être très pratique pour débugger une application HTML5 basée sur la géolocalisation sans forcément vous balader physiquement dans toute la France… voir la planète ! :)

Pour le reste, testez votre site de manière habituelle et observez les différences entre la version desktop et mobile comme avec le site Food Sense par exemple mettant en œuvre intelligemment CSS3 Media Queries :

Vous pouvez voir ci-dessus le résultat sur IE9 sous Windows 7, IE9 sur Windows Phone en mode portrait puis paysage.

Donc si tout cela vous intéresse et que vous souhaitez accueillir dans de bonnes conditions les nombreux acheteurs récents du superbe Nokia Lumia 800, foncez télécharger ici le SDK :

Télécharger le SDK Windows Phone ici

Et testez votre site dessus !

Différences entre IE9 desktop et mobile

Commençons par les choses en moins classées par ordre d’importance selon moi:

• pas de support des fonts téléchargeables comme EOT, TTF/OTF et WOFF. Bien que le tag font-face soit supporté, le navigateur IE9 mobile n’essaiera pas de télécharger la font. La liste des fonts installées et supportées par Windows Phone se trouve ici : Liste des fonts supportées
• pas de support de flux multiples avec la balise audio HTML5
• pas de support de mode de rétro compatibilité avec le mode de document Internet Explorer 8. IE9 mobile rendra les sites forcément avec le moteur de rendu d’IE9.
• assez logiquement, pas de support de communications “cross-window” via JavaScript
• pas de support de VBScript, d’ActiveX, d’extensibilité via les BHO (Browser Helper  Objects) et les barre d’outils, pas de support d’Active Document non plus
• pas de support de vieilles technologies comme les “binary behaviors”, HTCs, HTML+TIME et VML
• pas de compilation JIT

Ainsi, heureusement, la quasi totalité des différences entre la version de bureau d’IE9 et son équivalent mobile représente, je pense, d’excellentes choses.

Dans les choses en plus, nous avons :

• support du GPS pour la géolocalisation HTML5. Windows Phone utilise ainsi la couche de localisation du périphérique et utilise donc le GPS s’il est disponible. La version de bureau d’IE9 s’appuyant sur d’autres méthodes n’utilisant pas le GPS car quasiment aucun PC n’en est équipé.
• support du Viewport. Width, height et user-scalable. Par contre, bien que certaines de ces fonctionnalités soient supportées dans certains navigateurs, les propriétés minimum-scale, maximum-scale et initial-scale sont pour l’instant non supportées
• support de la propriété CSS : -ms-text-size-adjust

Vous retrouverez tout cela un peu plus en détail et en anglais ici : Web Development for Windows Phone

Pour le reste, reportez vous simplement au guide du développeur Internet Explorer 9 qui contient toutes les fonctionnalités supportées par IE9 desktop et donc mobile. J’attire par exemple votre attention sur 2 points importants lorsque vous allez tester du HTML5 ou CSS3 dans IE9 Mobile :

1. Tout comme IE9 Desktop, il faut absolument avoir créé un document HTML5 standard avec donc la balise en tout début de document. Si vous ne la positionnez pas, IE9 Desktop come Mobile basculeront dans un ancien mode de rendu non “compatible” HTML5
2. IE9 Mobile gère une liste de compatibilité des sites comme décrit ici : IE9’s faster, more capable Compatibility View List… now on Windows Phone! . Donc si vous vous apercevez que votre code ne se comporte par comme prévu dans IE9 Mobile, c’est peut-être que votre site est hébergé sur un nom de domaine marqué comme non compatible dans la liste mise à jour toutes les 2 semaines. Et tout comme IE9 Desktop, vous pouvez forcer le mode standard via le meta tag X-UA-COMPATIBLE.

Par exemple, j’ai eu une interaction récente sur Twitter avec @benjamincrozat sur du border-radius qui ne marchait pas sous IE9 Mobile. En regardant depuis IE9 Desktop son URL de test, je me suis aperçu de la chose suivante dans la console de debug (via F12) :

On observe alors que dropbox.com est présent dans la liste de compatibilité, ce qui fait basculer IE9 en mode de compatibilité IE7. Conclusion : n’hésitez pas à tester votre site sous IE9 “normal” avant de tester sous IE9 mobile pour faire une 1ère passe de tests.

Débugger le code JavaScript avec jsConsole

Dans la mise au point d’un site web pour mobile, la partie la plus pénible est souvent de débugger le code JavaScript sur tournant sur le périphérique. Heureusement, l’excellent Remy Sharp a eu la bonne idée de travailler sur un projet permettant de piloter à distance le code JS exécuté sur le périphérique. Le fruit de son travail est le projet jsConsole : http://jsconsole.com .

Mais plutôt que de vous expliquer en détail son usage, je préfère fortement vous inviter à lire l’excellent tutoriel présent sur le site d’Alsacréations : Déboguer son site mobile avec JsConsole . Je ne vois pas trop comment je pourrais mieux faire. ;-)

Par contre, j’ai bien vérifié que cette solution fonctionnait parfaitement avec IE9 sur Windows Phone. Voici un exemple utilisant jsConsole et PhoneGap pour Windows Phone 7 :

Vous pouvez donc compter dessus pour vous aider à tester et corriger votre site sur la version mobile d’IE9.

Attention ! Pour des raisons évidentes de sécurité, attention à bien mettre tout cela en place qu’à des fins de debug et à bien retirer son usage avant la mise en production ! Mais ai-je vraiment besoin de le vous rappeler ?

Débugger le trafic réseau avec Fiddler

Pour finir un peu plus bas dans les couches, nous allons maintenant voir comment capturer le trafic réseau entre l’émulateur Windows Phone et le reste du monde. Voici les étapes à suivre :

1. Installer la dernière version de Fiddler
2. Démarrer Fiddler
3. Aller dans les options via les menus “Tools” –> “Fiddler Options”
4. Ouvrez l’onglet “Connections” et cochez la case “Allow remote computers to connect”.
5. Cliquez sur “OK” pour fermer la fenêtre des options de Fiddler
6. Dans la boite de commandes sous la liste des “Web sessions”, tapez la commande suivante :  prefs set fiddler.network.proxy.registrationhostname HostName où HostName correspond au nom de votre machine
7. Fermer et redémarrer Fiddler
8. Démarrer (ou redémarrer) l’émulateur Windows Phone
9. Ouvrer Internet Explorer et naviguez vers le site à débugger
10. Observez le trafic réseau affiché par Fiddler

Et voici un résultat de capture en naviguant vers le site d’Alsacréations :

Avec notre émulateur gratuit et toutes ces astuces, j’espère que vous serez maintenant correctement armé pour tester et débugger vos sites sur IE9 mobile !

David