Une petite introduction à HTML5
J’ai eu l’opportunité de donner un cours d’introduction à HTML5 à la Web School Factory et à Hétic (mon ancienne école). Je vais passer les détails du déroulement des cours puisque ça n’intéresse personne (si ?).
Par contre, j’ai pensé qu’il serait intéressant de retranscrire mon speech et qu’on en discute (celui qui a dit « autour d’une bière » paye sa tournée !). Pour la forme j’avoue avoir bêtement copié sur Stéphane (qui avait copié sur David, qui avait copié sur… ? Euh, bref…).
Si vous voulez sauter les parties barbantes qui ne vous intéressent pas voici un petit sommaire :
Pourquoi HTML5 ?
Je n’ai pas voulu commencer par un historique de HTML parce que ça ne sert pas à grand-chose. Mais il faut quand même resituer HTML5. Depuis 1999 et la publication de HTML 4.01 (suivie de XHTML peu de temps après, mais qui n’apportait rien de nouveau) le langage n’a pas évolué.
Pourtant, les usages ont complètement changé. On n’utilise pas le web comme on l’utilisait il y a 10 ans. On a accès à plus de contenu, on en génère, on regarde des vidéos, etc. On utilise même des applications Web, des programmes que l’on utilise sur le web (comme Gmail ou Google Docs).
Il fallait faire évoluer le langage pour standardiser ce qu’on a bidouillé avec HTML 4.01 ; parce que c’est ce que fait le W3C, ils standardisent. Beaucoup de gens râlent, en disant qu’ils ne vont pas assez vite, qu’ils n’innovent pas. Ce n’est pas vraiment leur travail, ils normalisent, c’est-à-dire qu’ils regardent ce qui existe et le décrivent de la meilleure manière possible pour que tout le monde soit d’accord fasse pareil. Ce n’est pas anodin comme travail.
Et, bien sûr, il fallait continuer à sémantiser, mais à moindre mesure (c’est déjà assez compliqué). Je n’ai pas détaillé ce point, ne voulant pas empiéter sur mon temps.
Pour quoi HTML5 ?
Bon, ce n’est pas vraiment français comme titre, mais je voulais faire un jeu de mot avec le titre de la première diapositive. (Je m’éclate dans ma vie, n’est-ce pas ?)
À quoi sert HTML5 ? À quoi va-t-il servir ?
Tout d’abord, comme HTML 4.01, il sert à structurer un document. Ça ne change pas, on aura plus de possibilités avec HTML5, c’est tout.
On va pouvoir créer des applications web. On le peut déjà, mais on va avoir à disposition des éléments nous permettant de le faire plus simplement.
Enfin, et pas des moindres, HTML5 est là pour préparer l’avenir. Des leçons ont été tirées de HTML 4.01 et XHTML (celui qui vient de dire XHTML2 sort…). HTML5 va préparer les prochaines « versions » du langage, en posant une base saine.
Une nouvelle orientation
Comme je l’ai dit, HTML5 c’est avant tout standardiser l’existant (Pave The Cowpaths — celui qui me propose une bonne traduction aura un câlin — était un des premiers fil de discussion sur la mailing list).
Les changements fondamentaux commencent dans la spécification elle-même. La spécification de HTML 4.01 n’était pas vraiment explicite, du coup certains implémenteurs se sont posés des questions et ont fait comme ils pensaient. Un peu plus tard, d’autres implémenteurs se sont posés les mêmes questions, mais ne sont pas arrivés aux mêmes conclusions. Le résultat ? Un gros bordel. Pour éviter ça, la spécification est volontairement dirigiste, allant jusqu’à fournir des algorithmes très complets que les implémenteurs n’ont qu’à… implémenter.
Un autre point important : le contenu a été repensé. Depuis HTML 3.2, si je ne dis pas de bêtises, il existait trois types de contenu : Text, Flow et Bodytext. J’avoue ne rien y comprendre. HTML5 a revu tout ça et propose des types de contenu plus intelligents. Je ne vais pas rentrer dans les détails, sinon je vais perdre tout le monde, moi en premier.
Mais en quoi est-ce important ? Et bien ce découpage permet d’avoir une certaine richesse sémantique. Je pense que des exemples seront plus parlant alors voyons ce qu’il y a de nouveau !
Doctype
C’est la première chose qu’on trouve dans un document web (qui n’en utilise pas, que je le fouette ?). Je vous mets au défi de me citer de tête le doctype de XHTML 1.0 Strict ou même de HTML 4.01. Pas facile hein ? Le doctype a donc été simplifié :
<!DOCTYPE html>Et maintenant, vous y arriveriez ? Vous pouvez constater qu’on n’utilise pas « html5 » dans le doctype. C’est pour deux — bonnes — raisons : un certain navigateur passe en mode quirks avec « html5 », et ça permet surtout fournir une meilleure compatibilité ascendante. Ça veut dire, qu’il s’agit aussi du doctype pour HTML6.
Si vous voulez faire du XHTML5 — la version XML de HTML5 — vous n’avez pas besoin de doctype mais seulement d’un prologue XML, puisqu’après tout… c’est du XML.
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml">
Encodage
En second, vous déclarez l’encodage du document (j’espère que vous le faites !). Le mécanisme de détection a légèrement changé, mais rien de méchant.
Actuellement, vous déclarez l’encodage en utilisant une ligne similaire :
<meta http-equiv="content-type" content="text/html; charset=UTF-8">Pas vraiment explicite. Et puis, c’est quoi le type MIME ?
<meta charset="UTF-8">C’est beaucoup plus simple, non ? Une petite remarque : vous obtiendrez un warning avec le validateur du W3C, parce qu’il ne prend pas — pour l’instant — en compte ce méta.
La détection de l’encodage est, cette fois, clairement définie (comprenez qu’elle ne l’était pas avant).
- Header HTTP
- BOM du fichier
<meta>
Bien entendu, vous aurez moins de problèmes si ces trois critères ramènent le même encodage. Et tout ça ne vous dispense pas de déclarer le <meta> qui est toujours utile si l’utilisateur veut enregistrer la page.
Nouvelles balises
Je n’ai pas détaillé toutes les nouvelles balises, mais uniquement celles qui présentent un grand intérêt et qui sont — à peu près — facilement compréhensible.
<section>
Une section est un groupage thématique du contenu. C’est, en quelque sorte, une <div> qui a du sens. Dans un document, on peut trouver des groupes de contenus qui n’ont pas forcément de liens entre eux, c’est ici que <section> intervient. Un petit exemple sera plus parlant :
<section id="articles">…</section>
<section id="twitter">…</section>
Attention, il ne faut pas remplacer toutes vos <div> par des <section> ! Vous devez utiliser <div> si vous en avez besoin pour styler mais que le bloc n’a aucune valeur sémantique.
<div id="sidebar">…</div>Une sidebar est purement présentationnelle, donc n’utilisez pas <section>.
Ce n’est pas un hasard si j’ai commencé par cette balise. Un peu plus tôt je vous ai parlé de nouveaux types de contenu. La section est un type très important. En fait, il décrit un bloc que l’on peut prendre indépendamment du document. Ce qui veut dire que les headings (<h1>, <h2>, etc.) sont indépendant des sections.
<header>/<footer>
Ce sont deux balises à la fois simples et difficiles à comprendre.
<header> permet d’introduire une section et de fournir une aide à la navigation.
<body><header id="header">…</header>
<section id="news"><header>…</header>
Vous pouvez donc avoir plusieurs balises <header> dans votre document.
<footer> donne des informations sur la section, c’est en quelque sorte une boite à méta.
<footer id="footer">…</footer></body>
<footer>…</footer></section>
Une fois de plus, suivant le contexte, vous pouvez avoir plusieurs balises <footer>.
<nav>
<nav> est une section permettant de naviguer.
J’ai été assez étonné qu’on me demande ce qu’est une navigation. Typiquement, dans cette section on va trouver des liens qui permettent d’accéder soit à d’autres pages du site, soit à différents contenus de la page.
<nav>
<h1>Navigation</h1>
<ul>
<li><a href="/">Accueil</a></li>
<li><a href="/actualites/">Actualités</a></li>
…
</ul>
</nav>
<nav id="prelude">
<p>Aller au :</p>
<ul>
<li><a href="#contenu">contenu</a></li>
<li><a href="#recherche">moteur de recherche</a></li>
…
</ul>
</nav>
<article>
<article> est une section représentant un contenu indépendant du reste du document. En me relisant, je me rends compte que c’est presque la même chose qu’une section. À ceci près qu’<article> représente du contenu. Il n’y a pas grand-chose d’autre à en dire.
<section id="articles">
<h1>Articles</h1>
<article><h1>Article 1…
<article><h1>Article 2…
<section id="twitter">
<h1>Twitter</h1>
<article>Lorem ipsum…
<article>Dolor sit amet…
<aside>
Son nom peut prêter à confusion alors je préfère dissiper tous les doutes : ce n’est pas une sidebar !
La spécification décrit cette balise d’une très belle manière : C’est une section de contenu tangentiellement relié au contenu l’entourant (The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content.). J’ai beau relire ma phrase, je ne comprends toujours pas.
Heureusement, il y a une phrase qui résume très bien l’intérêt d’<aside>. C’est l’équivalent d’un encart en typographie. Vous avez surement déjà lu un magazine. Parfois, une phrase de l’article est reprise dans un encart, permettant au lecteur de s’intéresser au-dit article. Vous pouvez également vous en servir pour fournir des informations supplémentaires sur le contenu. Par exemple si vous écrivez un article sur une ville, vous pouvez fournir un encart donnant des chiffres clés.
<hgroup>
Peut-être avez-vous déjà eu besoin d’écrire un titre et un sous-titre ? Si vous faites ça :
<h1>Titre</h1>
<h2>Sous-titre</h2>Le contenu que vous écrivez ensuite fera référence à votre sous-titre alors que ce n’est pas ce que vous voulez. <hgroup> est votre ami :
<hgroup>
<h1>Titre</h1>
<h2>Sous-titre</h2>
</hgroup>Cette fois, l’ensemble titre et sous-titre est considéré comme un seul heading. Bon, je pense que cette balise ne sera pas beaucoup utilisée. (Ça vous arrive souvent d’avoir à écrire un sous-titre ?)
<time>
<time> permet d’écrire des dates et des heures. (Elle était dure celle là, hein ?)
Allez, je vous mets trois exemples :
<p>Rendez-vous le <time datetime="2010-10-05">5 octobre</time>.</p>
<p>On se fait un ciné <time>demain</time> ?</p>
<p>Dernière connexion le <time datetime="2010-02-05T10:42:00">5 février à 10:42</time></p>Pas vraiment méchant à utiliser. La date que l’on indique dans l’attribut datetime est au format ISO 8601 et vous n’êtes même pas obligé de la préciser. Dans ce cas, le contenu reflète la date exprimée, mais vous perdez une partie de l’intérêt de cette balise qui est de permettre à l’utilisateur de la rajouter dans son calendrier simplement (le « simplement » est toujours à définir par les développeurs d’users agents).
<canvas>
<canvas> permet de dessiner du bitmap en Javascript. Je dis bien du bitmap, car on ne fait pas de vectoriel avec <canvas>, c’est le rôle de SVG.
C’est en quelque sorte la super-star du HTML5. Grâce à son API 2D et bientôt 3D (peut-être, un jour ?) vous pouvez dessiner ou traiter des images.
Aux vues des deux exemples que j’ai fourni (Raycasting et visualisation with processing.js) un élève m’a dit « Mais, c’est la mort de Flash ? ». Alors, oui et non :-).
Oui, plus besoin d’utiliser un plugin pour faire les 3/4 de ce qui est fait en Flash (des publicités, des animations, etc.).
Non, Flash dispose d’une plus grande API et, pour l’instant, HTML5 est plus limité.
Ce qui fait cruellement défaut à <canvas> c’est son manque d’éditeur. C’est bien beau de jouer avec l’API, mais si on a quelque chose de plus conséquent il faut être très acharné pour le faire avec un simple éditeur de texte. Je ne dis pas que c’est impossible, je dis que ça va freiner son adoption plutôt que d’utiliser Flash qui est déjà bien ancré.
<audio>/<video>
Autres balises super-stars. <audio> et <video> permettent d’insérer du contenu multimédia facilement. Mine de rien c’est une grande avancée. Ça évite d’avoir à utiliser un plugin (Flash, Java, Quicktime, etc.) et du coup, on y gagne en accessibilité et pour <video> en performance (enfin j’espère, de ce que j’ai pu constater ce n’est — pour l’instant — pas le cas).
Je ne mets pas d’exemple, à la fin du cours je présentais du code pour utiliser <video>. Comme il fallait bien sortir ce billet un jour où l’autre (plutôt l’autre avec moi d’ailleurs…) j’ampute cette partie.
Et d’autres…
Il y en a encore d’autres, que j’ai choisi de ne pas détailler : <command>, <datalist>, <details>, <dialog>, <embed>, <figcaption>, <figure>, <keygen>, <mark>, <meter>, <output>, <progress>, <rp>, <rt>, <source>, <summary>
Vous noterez qu’il y a une balise que j’ai barré. <dialog> n’existe plus depuis longtemps dans la spécification, pourtant on la retrouve sur beaucoup d’articles parlant de HTML5. Faites attention à ce que vous lisez et il est toujours bon d’aller faire un tour du côté de la spécification.
Nouveaux attributs
Encore une fois, je n’ai sélectionné que les attributs les plus intéressants.
data-* permet de créer des attributs personnalisés. C’est utile si vous avez besoin de stocker quelque chose temporairement en rapport à votre contenu.
draggable indique que l’élément est déplaçable. Fini la tonne de Javascript pour faire votre Netvibes-like.
role et aria-* vont vous permettre d’améliorer l’accessibilité de vos applications web. Il est à noter qu’en l’état, HTML5 n’est pas très accessible… Mais ils y travaillent !
Balises dépréciées
HTML4 n’est pas exempt de défauts, après tout le W3C est composé d’humains (enfin, pour certains on se demande…). Il y avait des balises à supprimer, pour plusieurs raisons :
- Il y a des balises à but présentationnels et ça c’est mal :
<basefont>, <big>, <center>, <font>, <s>, <strike>, <tt>, <u>; - Des balises posant des problèmes d’utilisabilité et d’accessibilité :
<frame>, <frameset>, <noframes>; - Des balises prêtant à confusion ou inutilisées :
<acronym>, <applet>, <isindex>, <dir>; - Et enfin, il y a
<noscript>, mais qui ne disparaît qu’en XHTML5. De toute façon c’est mal de l’utiliser.
Attributs dépréciés
Il y a quelques attributs qui n’ont plus lieu d’être, principalement parce qu’ils avaient un but présentationnel. Je ne vais pas les détailler et vous encourage à lire directement la liste.
Balises redéfinies
Partie bien difficile. Certaines balises ont changées de sens (pas radicalement) et je dois avouer que j’ai eu bien du mal à l’expliquer.
<i> refait son apparition. Cette fois elle ne permet plus de mettre un texte en italique. Enfin si justement, il faut l’utiliser pour des termes que l’on mettrait en italique, comme des termes techniques, des expressions idiomatiques, des pensées, etc.
<b> refait son apparition. Cette fois elle ne permet plus de mettre un texte en gras. Enfin si justement, il faut l’utiliser pour des termes que l’on mettrait en gras, comme des mots clés, des noms de produit, etc.
<strong> refait son apparition permet d’ajouter de l’importance. (Ce n’est pas déjà le cas ?)
<small> permet d’indiquer un disclaimer ou un copyright.
Je serai curieux de savoir comment ces éléments seront retranscrit par un lecteur d’écran.
Attributs redéfinis
Il y a également quelques attributs qui sont redéfinis, mais la liste est tellement courte que je ne vais pas en parler. (Ah, ben je viens de le faire pourtant)
Web Forms 2.0
Mais que serait le web sans interaction ? Naturellement, il y a des nouveautés du côté des formulaires. Certaines s’appliquent uniquement aux applications web (mais… parfois la distinction entre document et application est difficile, n’est-ce pas ?). Finis la bidouille pour transformer un champ texte en autre chose, maintenant ça sera natif !
Web Forms 2.0 est le vieux nom donné par le WHATWG pour les améliorations des formulaires. Cette dénomination n’est qu’historique, je tenais seulement à faire un petit clin d’œil.
Voici les nouveaux types d’<input> :
datetime, datetime-local, date, time, month, week: je suis obligé de vous l’expliquer :) ?number, range: uniquement des nombres ou des intervalles.email, tel: pour rentrer des emails ou des numéros de téléphones. Imaginez que votre navigateur vous propose également de choisir une adresse ou un numéro de votre carnet d’adresses.url: Uniquement des URL.search: Indique que le champ permet de lancer une recherche.color: Permet de choisir une couleur. Probablement dans une roue chromatique (c’est le navigateur qui s’en charge, par contre je ne sais pas si l’auteur aura la main dessus).
On trouve également quelques nouveaux attributs spécifiques aux formulaires :
autofocusindique au navigateur qu’il doit placer le focus dans le champ dès le chargement de la page. C’est par exemple ce que l’on trouve sur la page de Google.placeholder: On utilise déjà un placeholder dans la plupart de nos sites. Il s’agit d’un texte placé dans un champ, lorsque ce champ prend le focus le texte est supprimé. Si on ne rentre rien, le texte par défaut réapparaît.requiredindique au navigateur que le champ est requis, c’est à utiliser avec l’API associée (que l’on va voir juste après, patiente !).autocomplete,min,max,pattern,step: Ici, on va pouvoir contrôler ou restreindre nativement les saisies.
Web Forms 2.0 décrit également une API de validation des champs. C’est ce qu’on utilise déjà avec un framework Javascript, mais cette fois en natif. Rien de bien méchant, quelques propriétés, méthodes et types d’erreurs spécifiques qui vont nous permettre de faire des formulaires sexy ! (c’est possible ?)
APIs
Comme vous pouvez le constater, l’accent est clairement mis sur l’interaction avec l’utilisateur. Pour vous aider, auteurs du web, HTML5 embarque des APIs très pratiques :
- Canvas : Dessiner et traiter du bitmap ;
- Multimedia : Interagir avec un contenu multimédia (lire, mettre en pause, augmenter le volume, etc.) ;
- Web Forms 2.0 : Valider les éléments de formulaire ;
- Drag&Drop : Donner la possibilité au document de recevoir des éléments de l’extérieur du navigateur, permet aussi de bouger les éléments d’un document ;
- Editing : Permettre d’éditer directement le document ;
- Offline : Permettre au document, ou à l’application web de fonctionner hors ligne. On va par exemple y retrouver une base de données intégrée ;
- Geolocalisation : Permet de géo-localiser l’utilisateur. Par exemple, si vous allez sur le site d’une chaîne de magasin vous n’aurez plus à indiquer votre adresse pour trouver le magasin le plus proche (ça fait peur, hein ?).
Quand l’utiliser ?
S’il y a bien une question qui brule les lèvres de tout le monde c’est celle là. D’ailleurs j’y ai eu le droit plusieurs fois avant d’arriver sur cette diapositive.
Tout de suite est la réponse un peu utopiste mais aussi la plus logique. D’un côté beaucoup de gens sont impatients que HTML5 soit finalisé, de l’autre ils ne veulent pas commencer à l’utiliser avant qu’il soit prêt. J’ai une mauvaise nouvelle pour vous, HTML5 ne sera jamais « fini » ou « prêt ».
Il y a trois acteurs dans la création d’une norme, d’une spécification ou d’un langage :
- Le W3C qui standardise ce qui existe, qui décrit comment devrait se comporter le langage ;
- Les implémenteurs qui modifient leurs navigateurs pour fournir l’interface adéquate ;
- Les auteurs, vous, qui construisez le web.
Sans vous le web n’est rien. Si vous voulez utiliser HTML5 allez-y, qu’est-ce que vous attendez ? Sans vous HTML5 n’existerait pas ou n’existera pas !
Attention tout de même à ne pas utiliser HTML5 sur des projets trop critiques et faites surtout très attention à l’accessibilité qui n’est — pour l’instant — pas optimale (et je reste gentil en disant ça). Pensez également à fournir des alternatives.
… et IE ?
En dehors des APIs et des balises nécessitant une interface spécifique (comme <audio>, <video>, <input>, etc.) les navigateurs en ont un peu rien à faire des balises que vous utilisez. D’ailleurs vous pouvez utiliser vos propres balises. Vous ne validerez pas votre document, mais il fonctionnera toujours dans les navigateurs.
C’est ce qui a fait le succès de HTML : la permissivité.
Là où ça devient plus ennuyeux c’est quand vous devez mettre en forme vos balises. IE a une particularité : il n’arrive pas à styler des balises qu’il ne connait pas. Heureusement il existe un petit hack qui permet de résoudre ce « bug » :
<!--[if lt IE 9]>
<script>
document.createElement("header");
document.createElement("section");
…
</script>
<![endif]-->
Ce code Javascript est à insérer dans le <head> et vous remarquerez le commentaire conditionnel qui l’applique pour toutes versions inférieurs à IE 9 (parce que ce bug est également présent dans IE 8, oui oui).
Ressources
J’étais bien conscient qu’une partie des élèves ne m’écouteraient pas. Mais comme je suis gentil, je leur ai fourni quelques bonnes ressources pour commencer.
- HTML5: The Markup Language, ce document résume HTML5, très pratique pour avoir une vision globale. Par contre, il ne va pas trop dans le détail.
- HTML5 Author Edition, ce document est une version simplifiée de la spécification. Destiné aux auteurs de documents web.
- HTML5 differences from HTML4, comme son nom l’indique, il s’agit des différences que l’on trouve dans HTML5 par rapport à HTML4.
- HTML5 Specification, pour les courageux qui veulent s’aventurer dans la spécification. Faites attention, votre navigateur peut crasher.
- Dive into HTML5 est la référence pour commencer et comprendre HTML5. Il s’agit d’un livre en cours d’écriture.
- HTML5 Doctor est un blog consacré à HTML5. On y trouve des articles expliquant les balises.
- HTML5 Gallery est une… galerie de sites en HTML5. Si vous en réalisez un, soumettez le ! Vous pouvez vous en servir pour vous inspirer, mais faites attention, certains n’ont rien compris au HTML5 ;-).
- Quelques démos qui commencent à se faire vieilles.
- html5shiv vous permet de « corriger » le bug qui vous empêche de style les nouvelles balises sous Internet Explorer.
Conclusion
Mais qu’est-ce que vous faites encore là, à lire ? Allez-y ! Utilisez HTML5 !
Commentaires
Merci pour cet article qui est en effet une très bonne intro à HTML5, simple, claire, avec l'essentiel. On a envie d'approfondir le sujet.
aside n'est pas toujours une sidebar mais elle peut l'être. Regarde l'exemple du blog dans les specs. Directement sous body.
www.w3.org/TR/html5/seman...
la bonne nouvelle pour canvas c'est que Flash CS5 a ajouté l'export dans ce format.
Très instructif et motivant! 
Il va falloir que je teste ça! ^^
> Ce qui fait cruellement défaut à <canvas> c’est son manque d’éditeur.
Je ne vois pas ce qu'un éditeur fait dans l'histoire. canvas, c'est une api, ce n'est pas un document.
Si tu veux y dessiner une simple image : utilises plutôt un svg/png/jpg et cie. D'ailleurs on peut importer une image dans un canvas, ce qui évite d'écrire des centaines de lignes de code pour simplement afficher une image de fond sur l'animation canvas.
D'ailleurs, je n'ai jamais vu un quelconque éditeur spécialisé dans la génération de code pour des surfaces de rendu, que ce soit pour le toolkit graphique ciblé (windows, qt, gtk...).
Au sujet de b, i, em et strong : « Je serai curieux de savoir comment ces éléments seront retranscrit par un lecteur d’écran ».
Comme ils le seront c'est impossible à dire. Par contre, aujourd'hui, malgré que ces éléments existent déjà en HTML4 et même en HTML3.2, les lecteurs d'écran n'en font rien de concret. On peut tricher un peu avec jaws et IE en commandant des changements de voix en fonction des propriétés de police, mais pas en fonction des balises ou des attributs.
Bon alors il n'y a plus qu'a ! Bel article d'introduction a HTML5 qui suppose un bel atelier pour ParisWeb ? (pour concurrencer les prez de Glazman) 
Typiquement le genre de truc qui aurait eu sa place directement sur Openweb...
@Sébastien C., @Raphaëlle, @Olivier Dolbeau : Merci !
@neolao : Je ne suis pas trop fan de l’exemple de la spec :). On dirait que n’importe quoi peut être dans un <aside>, à partir du moment ou c’est dans une page… Ce que j’ai expliqué à l’oral c’est que c’est une question de contexte. <aside> doit faire une sorte de parenthèse sur le contenu principal. Par contre, si je dis que ce n’est pas une sidebar, c’est surtout parce que j’ai vu trop de pages en HTML5 qui utilisaient mal <aside>.
@Frank Taillandier : En effet, le temps que j’écrive ce billet Adobe a annoncé l’export sous Flash :).
@Laurentj : Merci pour le commentaire sur les fautes (que j’ai supprimé, j’avais trop honte). Ce qui m’embête avec <canvas> c’est que sans éditeur les développeurs en herbes (comprendre ceux qui ne connaissent pas Javascript) ne vont même pas essayer de l’utiliser. C’est sur un point de vue d’adoption que ça m’inquiète, pas d’utilisation.
@QuentinC : Justement, on m’a demandé à quoi ça servait de faire la distinction entre un <em>, <i>, <strong>, <b>. J’ai répondu que c’est toute la question de la sémantique. Il faut sémantiser, mais si ce n’est utilisé par aucun user-agent ça ne sert à rien. Et s’il n’y a pas de sémantique, les user-agents n’évolueront pas…
@Christophe C : Oula, c’est peut-être trop m’en demander là :).
@Stéphane Deschamps : Ça peut toujours être adapté
Pour les canvas, il me semble qu'on peut prendre des choses comme
UmlCanvas pour faire du "vectoriel". Mais j'ai par regardé en détail.
fosdem.org/2010/schedule/...
Pave The Cowpaths - preparer le chemin pour les veaux / vaches
Merci pour l'article !
Pave The Cowpaths = Paver les sentiers à vache
ça préserve complètement l'idée cachée derrière l'expression.
(attention! Dans le commentaire précédent, le pluriel a été mal compris)
pas mal tous ca et motivant par contre on ne parle pas du tout du css3 qui a lui seul est une grande revolution dans la facon de concevoir une page web. mais au fait fait t'il parti du html5 ??
Pour Pave The Cowpath, plus sérieusement, à l'oral on peut s'en sortir avec une négation tout en gardant l'image du sentier : Ne pas y aller par quatre chemins.
Ça suppose qu'on fait pas trop attention aux détails.
Ou bien " suivre les sentiers battus "
Un grand merci. J'avais lu différentes choses sur le doctype à utiliser pour du xhtml5 et j'avais lu une sombre histoire de "non, pas de doctype, les header http disent que c'est du xml, point". Cela m'avait donné envie de détruire cette hérésie !
Je suis soulagé, je vais pouvoir aimer le xhtml5 maintenant que c'est plus clair dans ma petite tête.
Dommage au fait, que les images soient si petites, le graphe avec de 'une nouvelle orientation" entre autre ^^ Dommage …
@br, @MacFlav, @Pippin : Vous tenez au câlin, hein ?
@mom : J'ai donné un autre cours sur CSS3, peut-être que je ferai un billet similaire !
@Cellulos : J'ai rajouté le schéma original !
Bonjour, bonne petite introduction mais pourquoi des antislash pour les liens dans les exemples sur la balise <nav> , ne serait pas plutôt des slash et une mauvaise habitute de Windosien ?
Moi j'aurais dit tout simplement "baliser le chemin".
Article bien intéressant, autant pour le HTML5 que pour tous les néologismes français (sémantiser, présentationnelle, etc.) !
En fait, il faut bien dire qu'une sidebar, c'est visuellement sur le côté. Ca n'a rien à voir avec la sémantique.
Tu as même marqué que c'était "purement présentationnelle".
Ca veut dire qu'une sidebar, c'est forcément <div> ?
Le problème, c'est que si t'es catégorique sur <aside> et que les gens utilisent ton explication à la lettre, ils vont utiliser <div> alors qu'il y a une balise qui aurait été plus appropriée.
C'est les specs après tout. Il y a le contexte d'un <article>, mais aussi le contexte de <body>.
En plus, si on regarde les anciennes versions des specs, ça n'y était pas. Ca sera peut-être modifié encore, mais pour l'instant, c'est ça.
En plus, ça m'étonnait qu'ils rajoutent des balises dans HTML5 et oublier les sidebar. Il faut trouver une balise qui ne fait pas explicitement de la présentation mais qu'on peut utiliser pour une sidebar quand c'est sémantiquement correct.
Le passage indiquant que canvas manque d'un éditeur porte à confusion. C'est comme dire que javascript manque d'un éditeur, ça n'a pas de sens.
Au début je pensais que tu voulais dire que ça manquait d'un framework mais je ne pense pas puisque tu cites processing.js dans un des liens suivant.
Je viens justement de terminer un site en HTML 5 et en CSS 3 et j'aimerais vraiment connaître votre avis sur la manière dont je l'ai construit. Si vous avez un peu de temps bien sur
www.diablo3.be/
Merci.
Pour ceux qui cherchent : Paving the cowpath, en français, ça s'appelle suivre le chemins des ânes.
J'ai commencé à rigoler avec HTML5 et CSS3 avec mon dernier blog d'écologie je sais pas si tu as vu ?
Un grand fan des css3, mais qui ne savais que peu de choses sur HTML5 avant d'avoir lu cet article, je te remercie !
C'est un peu plus clair désormais pour moi, et j'envie le jour où tout sera ouvert et accésible sur le web (pas (trop) de plugins supplémentaires pour des choses trivialles comme la vidéo.
Je traduirais "pave the cowpaths" par "goudronner les sentiers battus". En développant, cela laisse entendre que "les chemins qui sont très empruntés mais non présents sur les cartes et/ou peu carrossables méritent qu'on les rende plus visibles encore et agréables à emprunter". Par "chemins" on entend "bonnes idées ou bonnes pratiques encore un peu confidentielles" qui, de standards émergeants, devraient devenir des standards officiels.
Un point qui n'a pas été évoqué dans cette présentation et qui semble également très prometteur, c'est cette caractéristique du HTML de rendre certains blocs éditables. Exit (ou alors à la diète sévère) les éditeurs WYSIWYG en JavaScript ! Pour en savoir plus, cherchez sur le net des infos sur l'attribut HTML5 "contentEditable".
Pardon si ma question peut paraitre naïve, mais en quoi HTML5 n'est-il pas optimisé pour l'accessibilité ?
y a plusieurs nouveaux éléments pour mieux structurer la page, les h1, h2, ...
pour le reste le boulot sur l'accessibilité d'une page c'est subjectif, et l'auteur de le faire : une page structurée est cohérente, des éléments de navigation bien fait ... et des couleurs qui piquent pas les yeux
par rapport au xhtml actuel ?
ou qu'est-ce qui est plus optimisé pour l'accessibilité par (actuellement) exemple ?
super article, en tout cas
j'attends celui pour les CSS3
Merci pour ce passionnant article !
En tant que bleu du html (j'ai découvert ça il y a à peine deux semaines, sur sdz), je n'ai pas pu m'empêcher de regarder un votre code source et il y a un détail qui m'a surpris. Votre doctype annonce XHTML 1.0 strict mais dans le code même on retrouve plusieurs balises appartenant au html5, notamment la balise section (et non, pas seulement quand elle est citée). D'ailleurs, quand on valide le site, il apparaît 93 erreurs, mais si on le revalide en changeant le doctype par <!doctype html>, il n'y a plus que 3 erreurs, très facilement corrigeables.
Alors ? Votre site est-il Html5 lui aussi ?
Ce fut long à lire mais j'ai de grands éclaircissements sur l'utilisation du HTML5 et les innovations qu'il apporte.
En regardant la galerie des sites et certaines balises présentées, j'ai l'impression qu'avec le HTML5, les sites ressembleront de plus en plus à des blogs. Je sais pas trop qu'en penser...
@hubert : Je ne sais pas ce qu’il m’a pris
@neolao : J’ai du mal à imaginer une balise pour sémantiser une sidebar. Ce que j’essayais de faire comprendre, c’est de ne pas voir <aside> obligatoirement comme une sidebar (c’est-à-dire quelque chose qui va sur un côté), mais quelque chose permettant de faire une parenthèse sur un contenu. Après c’est une question de contexte et peut-être que parfois <aside> sera parfait pour une sidebar…
@fuse : Dès qu’on parle de Canvas, on y voit le remplaçant de Flash. Sauf que ce n’est pas le même investissement/simplicité. Tu peux ouvrir Flash, faire des formes dans l’éditeur et avec la timeline faire des animations en quelques clicks, sans forcément trop connaître. Avec Canvas il faut déjà s’y connaître un peu en programmation.
@Falco : Pas mal :). Par contre, tu as des sections sans titre alors que c’est préférable d’en avoir. Sinon, lance un petit YSlow sur ton site !
@Karen : Oui j’ai vu, c’est très sympa ! Par contre, je me demande encore combien de blog tu as…
@AP : J’en parlais à l’oral, c’est l’API “Editing”
@Sylvain : En fait, l’accessibilité n’est pas (trop) abordée pendant cette phase de « développement » du langage. Une fois que le groupe a bien avancé, certaines parties sont confiées à un groupe spécialisé dans l’accessibilité. Un bon exemple c’est la suppression de l’attribut longdesc sur les images…
@mymy : Il fallait bien que quelqu’un le remarque :). En fait, je prépare une nouvelle version de mon blog, en HTML5. Quand je rédige un billet je le fais pour cette future version…
@topor : HTML5 s’oriente peut-être plus vers le contenu ? Les blogs étant l’exemple le plus parlant de l’explosion des contenus sur le web.
@le hollandais volant, @MrThieu : Merci
@Neovov : Merci pour YSlow, je ne connaissais pas.
Hello,
Je m'interroge sur les nuances entre <section> et <article>. La plupart des exemples que j'ai vu prennent le cas d'un <article> découpé en plusieurs <section>...
Mais ne peut-on pas, en partant du fait que <section> est comme "un groupage thématique du contenu", considérer qu'il puisse lui-même regrouper plusieurs <article> abordant le même thème (qui pourraient eux-mêmes être découpés en <section> par "sous-thèmes" par ailleurs) ?
Ainsi, on pourrait par exemple imaginer une <section> "biographie" regroupant plusieurs <article> sur différents auteurs, <article> découpés en <section> par période (enfance, étude, etc.).
Des pistes sur le sujet ?
Ciao,
Hello,
Alors, je réponds moi-même, puisque je demandais si quelqu'un avait des pistes sur la différence entre <article> et <section>, avec un lien qui vient de paraître :
html5doctor.com/the-artic...
Ciao,
Merci pour cette présentation mon pti doov
Très bonne article !
A quand celui sur les CSS3 ?
Article plutôt interessant!
Mais c'est quoi toutes ces erreurs 404 sur ton site mon pti voodoo? Tu nous as habitué à mieux
Ca nous promet encore de belles heures de réflexion face aux bugs et incompatibilités de navigateurs, il va falloir tester tout ça sur toute la série (comme toujours en fait)
Merci pour cette présentation mon pti doov
Très bonne article !
A quand celui sur les CSS3 ?
Bonjour, j'aimerais avoir un document dans lequel il y aurait le cours de Html ainsi que le css. Format Pdf serait bien
Il est mort ce site?
Hum et il n'y a aucune balise en html5 pour préciser que ce contenu n'as rien avoir avec le contenu du site ? Par exemple une alerte pour IE.
Puis ce que <aside> doit avoir un rapport indirect.. Que faire quand il n'y a pas de rapport du tout..
Un <div> ? Je croyais que je devais les garder juste pour les style graphique.
Autre question je suis perdu au niveau de <Hn>
J'en fais quoi par rapport aux article et section. Ils sont indépendant ? Cad qu'en fait les <hn> se rapporterait toujours uniquement à la première section qui est <body>
Ou bien a chaque section je repart à 0 ou a chaque article.. rbef totu ca ne me parait pas très clair ..
Bonsoir Nicolas,
Merci pour cette excellente introduction à l'HTML5 et en particulier à ses nouvelles balises. J'ai découvert ton site après avoir moi-même également publié une introduction à l'HTML5.
Je pense que les 2 sont complémentaires, puisque je n'explore pas les aspects sématiques des balises comme tu le fais mais je compense un peu par l'API Javascript
Dans tous les cas un peu de partage ne peut pas faire de mal, tu peux y faire un tour ici si ça te dit :
www.html5-css3.fr/html5/i...
Bonne continuation dans tes projets !
Il s'agit d'un grand site Web, tant de gens ont besoin de cette information, merci de le fournir. J'aime votre palette de couleurs aussi!
Et même votre adresse mail
Super intéressant tout ça ! Merci beaucoup ! J'aime surtout le draggable !.
Utilisé AT u0026 T Téléphones cellulaires sans fil à l'épargne fantastique!rn rn Si vous cherchez la fin du modèle utilisé AT u0026 T téléphones cellulaires à vendre, vous avez frappé à la bonne place. Tous nos produits neufs, reconditionnés et Occasion AT u0026 T téléphones cellulaires sont garantis et parfaite comme un remplacement pour une perte , téléphone cassé, volé, ou mise à niveau. Choisissez parmi une grande variété d' utilisation d'AT u0026 T téléphones cellulaires pour la vente qui correspondent à votre style et votre budget .rn rn Boutique de nos téléphones sans fil d'AT u0026 T maintenant! <a href=usedcellphonesforsales.in... cellphones for sale</a>
Bonsoir,
Merci pour le cours HTML5 , Super. je vais commencer à developper mais il me faut encore faire des efforts.Je developpe en ce moment avec expression web 4.
Un livre me serait bien utile?sur le HTML5.
Merci encore.
Cijoint l'URL d'un site que je developpe en ce moment,l'hitoire d'une riviere de 140 km de long , qui a fait vivre les hommes pendant plus de 500 ans.
Très cordialement
Serge
Décryptage intéressant, j'ai eu quelques problème avec internet explorer, je essayer ton codage.
Super intéressant, merci !
Merci, article très enrichissant pour les developpeurs
Je ne connais pas le html 5 mais vais peut être m'y mettre rapidement. Merci pour l'article
j'adore merci beaucoup, je vais developper mon site en ce sens.
Laissez le vôtre !
Les commentaires pour ce billet sont fermés.
En voilà une petite introduction utile. Il y a de vraies perles dans ces nouvelles balises. Je vais m'empresser de tester ça. Merci pour les références.