HTML5: Introduction

Même si la norme n’est pas encore officiellement publiée, HTML 5 fait déjà partie de notre quotidien: les navigateurs savent gérer une partie des spécifications, de plus en plus de sites sont écrits avec cette version de HTML, et nous utilisons tous les jours, sans le savoir, des applications HTML 5 sur nos smartphones.

J’ai commencé l’étude de HTML5/CSS3, dans le but de changer le thème du blog. Cet article est le premier d’une série, qui conduira à la publication d’un nouveau thème, reprenant les technologies/techniques exposées.

Un peu d’histoire

HTML (Hypertext Markup Language) est l’un des trois piliers du World Wide Web (Internet), avec le protocole HTTP, et la gestion des adresses (spécifications de nommage, et DNS).

Le langage apparaît au tout début des années 1990. Son objectif était de fournir un langage permettant l’écriture de documents, et de relier ses documents entre eux avec des hyperliens. Le langage était, assez rudimentaire, ne contenant pratiquement que des balises liées au texte: titre du document, balises de titre et sous-titre (H1, H2, …), les listes, et la balise p.

A partir de là, il faudra attendre 1997 pour disposer d’une spécification officielle et formelle. De 1990 à 1997, HTML va évoluer au gré des nouveautés apportées par les navigateurs: Mosaic d’abord, qui apporte les balises IMG et les formulaires, puis Netscape, et Internet Explorer.

En 1997 apparaît donc enfin une spécification officielle (HTML 3.2 puis 4.0), qui apporte un net progrès par rapport aux versions précédentes:

  • Le support des feuilles de styles CSS et des scripts,
  • Une plus grande structuration des balises,
  • Conséquence des deux premières lignes: un début de séparation entre le contenu, et la forme.

En 1999 apparaîssent HTML 4.01, puis XHTML 1.0, ce dernier devant assurer une transition entre le langage HTML et XML.
Car l’objectif du consortium W3C était à l’époque d’abandonner le langage HTML tel qu’il était, au profit d’un langage basé sur XML (Extensible Markup Langage). Démarrés en 2000, les travaux n’aboutirent jamais. En 2004, des éditeurs de navigateurs Web (dont Apple, Mozilla Foundation, Opera Software) créent le WHATWG (Web Hypertext Application Technology Working Group) dans le but de reprendre les travaux sur le langage HTML, le XHTML étant jugé trop complexe.

En 2007, le W3C relance le développement de HTML, en reprenant les travaux du groupe WHATWG. Le développement de XHTML 2 sera définitivement abandonné en 2009.

Le premier brouillon (draft) de HTML 5 est publié en Janvier 2008. Les spécifications sont censées être figées depuis Mai 2011, pour démarrer une phase de correction/finalisation, qui devrait aboutir à une version officielle en 2014.

Quelques commentaires

  • Cette histoire explique les différences entre les navigateurs: d’une part, seule la norme HTML 4/XHTML 1.0 existe, et d’autre part, l’officialisation de ces spéfications prend 10 ans à chaque fois,
  • Je n’excuse pas Microsoft pour autant, qui aura mis presque une décennie pour produire un navigateur capable d’interprêter du HTML 4 correctement,
  • Avec des temps de cycle aussi longs, les spécifications risquent d’être obsolètes avant même leur sortie,
  • L’histoire de ce langage est marquée par les querelles continues, entre les pragmatiques d’une part, partisants de solutions simples, basées sur l’existant, avec des évolutions progressives (les éditeurs de navigateurs), et les puristes, d’autre part, partisants de langages évolués, « propres », complets, mais également beaucoup plus complexes (W3C).

Cet article aborde HTML5 uniquement. Les styles CSS3 seront abordés dans un autre article.

Qu’apporte HTML5 exactement?

Maintenant que nous savons ou nous en sommes, nous pouvons aborder le sujet proprement dit.

Langage de balises enrichi

Le langage HTML 5 apporte

  • Une compatibilité ascendante avec les versions précédentes,
  • Une séparation accentuée entre le contenu et la mise en forme,
  • L’ajout de balises permettant une meilleure identification des différents composants du document, et donc d’en améliorer son analyse sémantique.

En clair, des balises disparaîssent <center>, <font>, par exemple, et d’autres apparaîssent. J’ai classé ces nouvelles balises en deux catégories:

  • Les balises sémantiques, comme header, section ou article: ces balises sont là pour identifier clairement le contenu situé à l’intérieur. On pourrait imaginer qu’un moteur de recherche ne s’intéresse, un jour, qu’au contenu des balises article,
  • Les balises « applicatives », comme figure,audio, video ou canvas: ces balises comblent une lacune des versions précédentes de HTML, qui ne savaient pas très bien gérer les objets autres que textuels.

En réalité, le W3C classe les balises en 7 catégories, avec un beau schéma à la clé. Je vous laisse consulter la spec pour de plus amples informations (prévoir quelque chose contre les maux de tête).

Structure des entités HTML 5

En fait, tout en étant très proche, en apparence, des versions précédentes, HTML5 dispose d’un modèle de données bien plus complexe, apportant une plus grande liberté: les balises peuvent presque toutes, être conteneur ou contenu de toutes les autres balises, ce qui n’était pas le cas précédemment.

Les balises les plus intéressantes (et les mieux définies) sont:
(cliquer sur la balise pour avoir la définition du W3C)

Balise Rôle
article Je vous donne la définition du W3C, particulièrement claire: « a self-contained composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication ». Heureusement, nous avons les exemples: article de journal, article ou page d’un blog, le commentaire d’un utilisateur, ou un widget (interactif). En occultant le dernier exemple, nous pourrions dire que la balise article sert à marquer le contenu réel (au sens information) d’une page.
header comme son nom le suppose, cette balise indique l’en-tête de l’élément parent. Cet élément peut être la page elle-même, un article, une section, …
footer Cette balise correspond au pied de page. Comme pour la balise précédente, footer peut s’appliquer a une page, un article, …
nav Cette section contient un groupe/ensemble de liens (vers d’autres pages, ou la page courante). Jusque là, la spec considérait que cette balise ne devait être utilisée que pour les éléments principaux de navigation (le menu principal). Le draft que je viens de lire (16 août 2011), semble dire que la balise peut être utiliser de façon plus générique. Pour l’instant, je recommanderais de suivre ce qui se fait un peu partout: une seule balise nav par page.
time Permet d’identifier la date et l’heure d’un élément (un article par exemple).
section Typiquement le type de balise dont le rôle et l’utilisation est difficile à appréhender. La définition dit: « un groupement thématique d’éléments » … Il est bien précisé plus bas, que la balise ne doit pas être utilisée comment élément générique (comme span ou div). Aujourd’hui, en fonction des templates ou des frameworks, cette balise est plus ou moins utilisée. On peut imaginer l’utiliser pour marquer les paragraphes d’un texte, par exemple. Comme pour la balise nav, je pense qu’il faut s’appuyer pour l’instant sur ce qui existe: dans la plupart des frameworks, section est utilisée pour contenir une liste d’articles, ou une liste de commentaires, …
aside Encore plus flou. La définition nous dit que la balise doit servir à stocker des informations n’ayant pas forcement rapport avec le contenu de la page. La spec cite ensuite son utilisation dans le cadre d’une sidebar, ou d’un bloc adjacent au contenu. Tout irait bien, si quelques lignes plus bas, l’exemple montre une balise aside au beau milieu d’un article. Les frameworks, ou les thèmes sont très partagés sur l’utilisation de cette balise. Certains s’en servent pour marquer la sidebar, par exemple, d’autres s’en servent pour contenir les widgets …
figure Balise très intéressante. figure, ainsi que figurecaption servent à contenir tout ce qui n’est ni texte, ni géré par d’autres balises comme audio ou video. Concrètement, la balise contiendra des images ou du code source, par exemple. Cette balise pourrait servir, à identifier, et référencer toutes les figures, graphes, formules, … d’une page.
hgroup Le rôle de cette balise est resté flou assez longtemps. Aujourd’hui il semble y avoir un concensus: la balise hgroup sert de conteneur à une ou plusieurs balises H1,H2, ..., et permet de ne retenir que la balise de niveau hiérarchique supérieur. Si une balise hgroup contient H1 et H2, dans la hiérachisation seule la balise H1 sera retenue. 
input Cette balise n’est pas nouvelle, mais elle dispose maintenant d’un bien plus grand nombre d’attributs. Jusqu’à présent, nous avions droit à type="text", "checkbox", .... Maintenant, nous pouvons spécifier le type de données attendu: datetime, number, range, email, url, search, color. Ceci veut dire, qu’au niveau du formulaire, une partie des vérifications sera faite avant l’envoi des données.

La structure d’un document pourrait donc ressembler à cela:

Structure d'une page écrite en HTML 5

Je reviendrai en détail sur la structure des pages en HTML5, dans un prochain article.

A noter que le document commence par

<!doctype html>

Fini donc, les lignes interminables de définitions DTD!

Du web à l’application

HTML 5 n’est pas qu’un simple langage de description de document. Il permet de développer de véritables applications, avec des éléments comme

  • La balise canvas, permettant de créer des éléments graphiques « à la volée », en Javascript. Typiquement certains jeux sont déjà développés comme cela,
  • L’attribut draggable permet de rendre un élement déplaçable,
  • Dans le même genre d’idée, Contenteditable indique que l’utilisateur pourra modifier le contenu et le balisage de la zone marquée,
  • Une API appelée WebStorage (souvent appelé local storage), permet de faire stocker localement, par le navigateur des paires de variables/valeurs,
  • Une API de géolocalisation permettra également d’interroger le navigateur sur la localisation de l’utilisateur.

Tous ces éléments dynamiques et ces APIs sont utilisables grâce/avec Javascript.
Ces APIs et ses éléments ouvrent des possibilités énormes, mais je pense que nous n’avons pas fini d’entendre parler de problèmes de sécurité.

De nombreuses applications développées en HTML5/CCS3/Javascript existent déjà, par exemple:

Compatibilité

Les éditeurs (un en particulier) avaient du mal à se conformer à des spécifications qui dataient de l’année 2000, alors imaginez ce qu’il va se passer avec un spec qui n’en n’est qu’au stade de brouillon !

Plus sérieusement: HTML 5 est issu du groupe WHATWG, consortium regroupant des éditeurs de navigateurs Internet. L’adaptation de HTML5 a donc logiquement déjà commencé, d’autant que les spécifications sont figées.

Les derniers navigateurs FireFox 5, Internet Explorer 9, Safari, Opera sont déjà capables de comprendre les nouvelles balises, et implémentent certaines des API.

Reste à gérer les anciens navigateurs, qui constituent une part non négligeable de nos lecteurs.
Pour obtenir une compatibilité de base (avec les nouvelles balises), il faut ajouter deux éléments dans l’entête de vos pages:

Un petit script permettant de créer les balises manquantes:

document.createElement('header');
document.createElement('footer');
document.createElement('section');
document.createElement('aside');
document.createElement('nav');
document.createElement('article');
document.createElement('figure');
document.createElement('time');

Ce script existe déjà, et peut être téléchargé ICI.

Une feuille de style pour indiquer au navigateur la façon de gérer ses balises:

header, footer, section, article, aside, nav ... { display: block; }

Pour une meilleure compatibilité, de généreux développeurs nous ont concocté des scripts comme Modernizr.js et des feuilles de styles comme normalize.css.

Attention à cette dernière, il ne s’agit pas d’un « reset » a proprement parlé comme l’on peut en rencontrer avec les frameworks CSS.

Commentaires personnels

En parcourant les spécifications, je me rend compte, que le chemin est encore long avant d’avoir quelque chose de stable. Le rôle de certaines balises n’est pas encore défini, et certaines API sont encore au stade d’idées …

Le renforcement de la sémantique est une bonne chose, mais elle induit des contraintes. Le rôle des balises va se renforcer:

    • si votre contenu n’est pas dans une balise article, il risque de ne pas être mise en valeur comme il se doit,
    • Les pages, et leur contenu sont mieux hiérarchisés: les balises h1, h2 servent réellement à autre chose que de support pour des styles. Elles jouent un rôle dans cette hiérarchisation, comme laisse entrevoir la balise hgroup, ce qui veut dire qu’il faudra être très rigoureux sur ce sujet. De nombreux articles parlent déjà de ce problème, et l’on voit apparaître des outils, comme HTML 5 Outliner, pour afficher la table des matières de votre page.

J’aime

      • La séparation de plus en plus forte entre le contenu, et la mise en forme, ainsi que la sémantisation du contenu,
      • La simplification de certains éléments (doctype et meta)
      • Beaucoup des lacunes de HTML 4 sont comblées, notamment grâce aux balises audio, video, ainsi que les balises liées aux formulaires,
      • L’adaptation est rapide, parce que les changements apportés sont gérables: le langage n’apporte que quelques balises supplémentaires, et les autres modules sont optionnels,
      • Ces balises vont en effet éviter l’usage d’éléments externes (les nouveaux attributs de la balise input par exemple).
      • L’apport des balises structurelles, va nous permettre une meilleure identification du contenu « utile » des pages.
      • La norme est en gestation depuis assez longtemps maintenant: les développeurs ont donc pris le temps pour l’étudier. HTML 5 sera donc publiée avec un ensemble de « Best practises », qui pour certaines existent déjà (HTML 5 BoilerPlate par exemple). Il sera donc relativement facile de développer des choses correctes du premier coup.

Je n’aime pas

      • Encore une fois, le W3C nous produit une spécification remplie d’ambiguïtés. Le rôle des balises est contextuel: le rôle d’une balise change, en fonction de sa position par rapport à d’autres balises. Si les choses sont claires concernant des balises comme header ou footer, je pense qu’il faudra un certain temps, avant que nous comprenions tous, quand utiliser des balises comme aside ou section.
      • Le « local storage », et d’une manière générale, tous les composants actifs localement, m’inquiètent un peu: je comprends le besoin, mais j’y vois également de forts risques liés à la sécurité, et la confidentialité des données.
      • L’officialisation de Javascript comme langage du poste client (je n’aime pas ce langage, avis purement gratuit).

Conclusion

Pour moi, le changement est positif. Même s’il évolue beaucoup, le langage de balisage est finalement assez proche de la version précédente, ce qui simplifie la transition.

La séparation entre le contenu, et le contenant s’accentue, et apparaît une véritable sémantisation du contenu.

HTML5 ne doit pas être uniquement considéré comme un langage, mais doit être vu plutôt une boîte à outil. Le point positif est que les modules sont complètement indépendants. Nous pouvons donc démarrer simplement avec le langage, puis en fonction de l’avancement de l’apprentissage, ajouter les modules nécessaires à nos développements, et terminer cet apprentissage par l’écriture de véritables applications.

Faut-il y aller maintenant? Je dirais que oui, pour principalement deux raisons:

  • d’abord, avec un minimum de changements, HTML5 peut être correctement « interprêté » par tous les navigateurs, y compris les plus anciens,
  • ensuite, parce que les composants de base de HTML5 existent déjà (HTML, Javascript, …). En respectant un minimum de règles, les développements effectués aujourd’hui, seront toujours fonctionnels, et correctes lorsque la norme sera officiellement publiée, et adoptée par les éditeurs (et les navigateurs).

Références

3 thoughts on “HTML5: Introduction”

  1. Merci pour cet article fort intéressant !

    Je suis d’ailleurs en train de m’intéresser de près à l’HTML 5 car je vais bientôt passer un de mes sites dans une version rafraîchie et surtout extensible en hauteur (oui, je sais …).

    Je pense donc surtout utiliser les balises header, nav, footer, article, time, section et aside.
    Je vais jetter un coup d’oeil aussi du côté de ce qui est faisable au sujet des balises audio, video et des nouveaux champs input.

    Cela reste encore un bon petit morceau à creuser et à digérer !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.