Carnet Wiki

HTML5

Version 21 — Juin 2010 davux

Qu’est-ce que HTML5 ?

HTML5 est une évolution de la norme HTML 4.01, norme datant maintenant d’une dizaine d’années. Cette évolution vise donc à prendre en compte la réalité actuelle des sites web, en posant à plat certains besoins courants, voire en officialisant certaines réponses déjà apportées par les webmasters et les navigateurs à ces besoins.

Cette norme en est au statut Working Draft, ce qui signifie que c’est la dernière ligne droite dans les différentes étapes de validation de la spécification : les seuls changements porteront désormais sur des points de détail. Il est donc déjà possible d’écrire ses squelettes avec les nouvelles balises et attributs HTML5, tout en produisant des pages valides. Il suffit de déclarer le bon DOCTYPE : <!DOCTYPE html> (fastoche, on peut même l’écrire de mémoire).

Un résumé des changements au niveau du balisage peut être vu sur cette page.

Objet de cette page

Cette page tente de jeter un coup d’œil aux évolutions apportées par HTML5, et surtout ce qu’elles signifient pour un CMS comme SPIP.

Si vous avez déjà développé des adaptations à SPIP prenant en compte des éléments cités, n’hésitez pas à les mentionner !

Cette page n’est pas vraiment une présentation exhaustive de HTML5. C’est peut-être une bonne idée de mentionner ici uniquement les changements qui peuvent avoir un intérêt pour SPIP.

Transition

Bien entendu, tout n’est pas intégrable dès maintenant « à la brute ». Le jeu serait donc d’arriver à fournir des nouveaux outils HTML5 dans SPIP, sans toutefois les imposer. On peut peut-être réfléchir sur diverses techniques ici.

  • Fournir des surcharges des fichiers existants en précisant juste le balisage avec des balises HTML5. C’est ce que font par exemple les plugins zpip_html5 et html5.
  • Fournir un socle commun qui permette de coder en HTML5 sans se poser de questions, à la façon du plugin css3. Le plugin html5 fait ça (javascript pour IE et reset CSS).

HTML5 : nouveaux média

L’aspect le plus connu de HTML5 est l’introduction des balises <video> et <audio>.

Un exemple basique ici sur cette page.

On peut donc d’ores et déjà penser à des modèles pour les intégrer dans les squelettes.

  • Il existe maintenant un modèle HTML5 video sous forme de plugin, basé sur Video for Everybody.
  • kent1 travaille aussi sur un plugin html5 intégrant les modèles <audio> et <video> : un exemple (version flash car seul flv disponible) et un autre (version html5 pour les navigateur récents car mp4 et ogv à disposition avec fallback en flash avec flv pour lE et consorts).

Quelles autres possibilités en rapport avec les nouvelles balises de média ?

Lire ces deux articles de référence : Éléments HTML 5 de structure et HTML5 et l’avenir du web

Nouvelles balises de sectionnement logique

-  <section> décrit une section ou une sous-section logique d’une page, disposant typiquement d’un titre. Une bonne question pour savoir si c’est ce qu’on veut, c’est de se demander si ça doit apparaître dans le sommaire de la page. Si oui, alors c’est probablement une section, sinon probablement pas.
-  <article> décrit une entité qui peut se considérer de manière autonome, typiquement un article, un commentaire, etc. Article ou section ? Si ça peut se syndiquer à part, alors plutôt article.
-  <aside> décrit un contenu connexe, un aparté, un corollaire à l’article principal. Dans un article de journal, ça correspondrait à un encadré qui détaille ou élargit un sujet mentionné dans l’article.

Nouvelles balises de flux


-  <nav> décrit une zone permettant de naviguer vers d’autres parties du site. Souvent, ça va être un menu contenant principalement des liens. Il peut bien sûr y en avoir plusieurs dans une même page.
-  <header> décrit la zone de la page ou de l’<article> qui contient la titraille et les éléments qui permettent d’identifier l’article ou la section (pas nécessairement en tête) : une bannière, un champ de recherche, une table des matières... Un peu dur à assimiler au début, mais important : cette zone ne définit pas de sectionnement logique de la page (contrairement à <section> par exemple). La présence ou l’absence de ces balises de début/fin n’ont pas d’incidence sur la table des matières.
-  <footer> est similaire à <header>, mais définit des informations de contexte, traditionnellement placées après le contenu mais pas nécessairement. Cf. : http://css4design.com/html5-pourquo.... Par exemple nom de l’auteur, copyright, un lien vers les commentaires, une date, un auteur, ou des informations complémentaires.
-  <hgroup> définit un groupe de headers (en-têtes).
-  <figure> (et <figcaption>) : bout de code, schéma, photo... qui enrichissent le texte en l’illustrant. Ça pourrait avoir du sens dans les modèles d’images pour les auteurs, ainsi que dans les balises <code></code>.

On remarque au passage que nombre de ces balises trouvent leur équivalent dans le formalisme défini par ZPIP. Bonne nouvelle, les deux sont totalement compatibles car ZPIP définit simplement des noms de classes. Tout ça combinéTout ça combiné , voilà de quoi rendre le code de ses squelettes vraiment très « joli ». :)

Nouvelles balises de texte

Pas vraiment d’ajout, mais certaines définitions ont été précisées ou légèrement modifiées pour prendre en compte l’usage actuel tout en le formalisant.
-  <hr> : Changement thématique. Comme un paragraphe, mais en plus fort. Avant, c’était une ligne horizontale, donc visuelle, donc pas cool dans le HTML ; maintenant cette balise « reprend tout son sens ». Welcome back !
-  <b> : texte mis en balance du reste du texte, typiquement en gras mais pas nécessairement, mais sans importance au niveau sémantique. Par exemple, un mot-clé ou un nom de produit.
-  <i> : texte sur un ton alterné avec le reste du texte, typiquement en italique mais pas nécessairement. Par exemple, un terme technique ou étranger, un nom de bateau...
-  <em> : insistance, emphase (depuis HTML4 !)
-  <strong> : importance forte (depuis HTML4 !)
-  <mark>. Ça peut être intéressant pour les résultats de recherche par exemple.
-  <time> permet de définir une date de façon formelle. Ça peut être intéressant dans le plugin Agenda 2.. Voir aussi l’attribut pubdate qui correspond à la date de publication dans SPIP.

Application possible : la barre typographique.

Attributs libres : data-*

Nouveauté de HTML5 très intéressante pour SPIP, notamment pour les plugins : la possibilité de créer ses propres attributs HTML. On peut utiliser n’importe quel nom, mais pour éviter les conflits avec des attributs existants, il faut le préfixer par « data- ». Typiquement, là où actuellement des noms de classe sont utilisés puis parsés, on peut utiliser des attributs data.

Exemples :
-  dans Mediabox, class="boxWidth-50pc" devient data-boxWidth="50%".
-  dans Crayons, class="article-titre-42" peut devenir (par exemple) data-objet="article" data-champ="titre" data-id="42".

Attention : Il est important de garder en tête que ces attributs ne doivent servir que pour un usage interne au site. Les navigateurs notamment (ce qui inclut les extensions) ne doivent pas se baser dessus dans leur fonctionnement, au risque de voir apparaître une « norme HTML parallèle », similaire au chaos qu’on a connu au temps des guerres de navigateurs.

Autres nouveaux attributs

(section à compléter)

-  ping : <a href="..." ping="...">. On demande au navigateur (il est pas obligé) d’informer une certaine URL s’il suit le lien. Application possible : un nouveau plugin qui prend en compte les pingbacks dans les stats ?

Dans les formulaires

HTML5 précise la sémantique des zones d’entrées (input) en définissant de nouveaux types. Bien que la plupart des navigateurs actuels ne fassent pas encore de traitement différencié pour ces types, ils ne les interdisent pas non plus. Mieux encore, certaines personnes ont déjà écrit des petites fonctions javascript qui simulent les fonctionnalités en question sur les navigateurs qui ne les ont pas encore implémentées.

-  search : recherche
-  tel : téléphone
-  url : une URL, qu’elle soit de type HTTP, XMPP, FTP, IRC, etc.
-  email : une adresse mail
-  date, time, month, week, local-date, local-time. Date, heure, mois, semaine, date locale, heure locale.
-  number : nombre entier
-  range : plage ?
-  color : couleur

Par ailleurs, certains attributs permettent de préciser le comportement des champs de formulaire :
-  autocomplete=« off » (valeur par défaut à on). Permet d’activer ou désactiver dans une zone de saisie l’auto-complètement basé par les valeurs enregistrées précédemment par le navigateur.
-  list=« toto ». Indique l’identifiant d’une liste de complètement automatique (voir <datalist> plus bas).
-  required. Intéressant pour CVT.
-  multiple
-  pattern. Intéressant pour CVT, similaire à la fonction Vérifier.
-  min et max
-  step
-  placeholder : texte par défaut. Sympa pour les zones de recherche, pour CVT aussi.

On imagine avec grand plaisir comment le plugin « Saisies » pourra tirer parti de ces nouveaux types et attributs. Le plugin Crayons également.

Nouveaux éléments :
-  <datalist id="toto">. Permet d’indiquer une liste de termes (<option>plop</option>) à utiliser par le navigateur pour le complètement automatique.
-  <keygen>
-  <output> : la sortie d’un calcul dynamique (javascript typiquement, ou via les raccourcis AJAX de SPIP)
-  <progress> : définit la progression d’une opération
-  <meter> : montre une mesure ou une note. Application possible : plugin Notation.

Nouveaux types de <link>

Ces nouveaux types pour les éléments <link> sont éventuellement intéressants dans SPIP.

-  bookmark
-  help
-  search : utilisé dans le plugin OpenSearch (à vérifier)
-  tag : typiquement, pour renvoyer vers la page motXX
-  pingback : Permet d’indiquer une URL de pingback (également connu comme trackback) pour une page, utilisable par les gens qui veulent mettre un lien vers la page depuis leur propre site. But proche de l’attribut ping de la balise <a>.

Nouvelles API Javascript

À faire, j’ai vu que des choses ont été formalisées et enrichies, mais moi j’y connais rien. :p

Documentation externe