Parcours d’apprentissage web – Part II : HTML, structure et contenus
Cet article s’inscrit dans la série Parcours d’apprentissage web. Nous entrons ici dans la première partie, consacrée aux technologies côté client, avec le HTML, langage qui va nous permettre de donner une structure et un sens à ce que nous allons produire. Après avoir préparé notre environnement de travail et posé une méthode, nous passons maintenant à l’étape suivante : écrire notre première page et comprendre concrètement comment elle se construit.
Le HTML est un langage à balises qui ne se contente pas d’afficher du contenu : il l’identifie et lui donne un rôle. Mais ce que nous manipulons dépasse rapidement quelques exemples isolés. Au fil des pages, nous allons composer avec des contenus de natures variées, préparés en amont, organisés différemment et utilisés dans des contextes multiples. Le HTML intervient alors comme un cadre commun : il reconnaît ces éléments, les met en relation et leur attribue une place lisible dans l’ensemble. Cette capacité à structurer sans enfermer permet au navigateur de comprendre la page, et aux autres systèmes de l’interpréter. C’est à partir de cette diversité, sans la réduire à une liste figée, que nous allons observer comment un document HTML s’organise réellement.
Sommaire, structurer pour comprendre
Ce sommaire propose une lecture progressive du HTML, depuis les fondations jusqu’aux usages concrets. Chaque chapitre éclaire une dimension précise, structure du document, nature du contenu, organisation interne, relations entre les éléments, pour construire une vision cohérente de ce que nous produisons réellement.
- Introduction, apprendre le HTML sans se perdre : poser une approche de travail, comprendre ce que nous cherchons à construire et éviter une lecture fragmentée du langage.
- La structure minimale d’un document HTML : identifier les fondations d’une page et distinguer clairement le cadre du contenu.
- La partie invisible,
<head>, métadonnées et contexte : comprendre ce qui décrit la page au-delà du visible et comment le navigateur interprète ces informations. - Le contenu, matière première du HTML : replacer le HTML dans son rôle, accueillir, organiser et structurer des ressources préparées en amont.
- La partie visible
<body>, structure et organisation de la page : organiser les grandes zones d’une page et donner un rôle à chaque section. - Créer une navigation simple, l’hyperlien ****
<a>: relier les pages entre elles et comprendre les différentes formes de chemins. - Factoriser cette structure : éviter les répétitions et préparer une organisation maintenable du projet.
- Donner forme au contenu : découpe, hiérarchie et organisation : structurer le contenu lui-même et construire une logique de lecture.
- Au cœur du texte : éléments inline et nuances sémantiques : affiner le sens au niveau du texte et comprendre les variations sémantiques.
- Le flux du document et l’organisation des nœuds dans le DOM : visualiser la structure comme un arbre et comprendre les relations entre les éléments.
- Identifier les noeuds,
<id>,<class>et attributs globaux : cibler, nommer et manipuler les éléments dans le document. - Accessibilité et attributs ARIA : donner du sens au contenu pour tous les usages et améliorer l’interprétation par les outils.
- Introduire une première interaction avec l’utilisateur, le formulaire : capter des données et amorcer les échanges avec l’utilisateur.
- Tableaux : restituer des données, pas structurer une page : utiliser les tableaux pour ce qu’ils sont réellement, un outil de représentation de données.
- Listes : énumérer et structurer l’information : organiser des ensembles d’éléments de manière lisible et cohérente.
- Les médias dans une page HTML : intégrer images, sons et vidéos en tenant compte de leur contexte et de leur usage.
- Métadonnées, décrire le document au-delà du visible : enrichir la compréhension du document pour les systèmes et les outils.
- Valider son HTML et comprendre les erreurs : vérifier la conformité et identifier les problèmes de structure.
- Utiliser les outils du navigateur : observer, tester et comprendre le comportement réel de la page.
- Conclusion, le HTML, point d’ancrage des interactions : relier les notions et préparer les étapes suivantes du parcours.
Introduction, apprendre le HTML sans se perdre
Cet article n’a pas pour objectif d’enseigner le HTML au sens classique du terme. De nombreux sites le font déjà très bien, en présentant les balises une à une, avec leurs attributs et leurs usages. Ces ressources sont indispensables, et nous allons nous y appuyer, notamment sur la documentation MDN et la spécification officielle maintenue par le WHATWG. Mais notre objectif ici est différent. Il consiste à apprendre comment apprendre le HTML, quoi regarder en priorité, quoi ne pas négliger, et comment organiser cette découverte.
Apprendre le HTML ne consiste pas à mémoriser une liste de balises. Il s’agit de comprendre une logique de construction. Une page repose sur une structure, une hiérarchie, une architecture. Certains éléments contiennent, d’autres sont contenus. Certains décrivent, d’autres précisent. Cette organisation constitue la base sur laquelle tout le reste viendra se poser, et d’autres dimensions viennent déjà s’y rattacher. Cette approche de structure ne relève pas uniquement de l’organisation technique. Elle influence déjà la manière dont une interface sera comprise, parcourue et utilisée. Cette articulation entre structure, interface et expérience est abordée plus largement dans l’article « UI et UX : L’évolution des interfaces dans un monde connecté ».
Les métadonnées décrivent la page sans être visibles, et les attributs aria en garantissent l’accessibilité. Nous reviendrons plus loin sur ces aspects dans le chapitre « Donner du sens, accessibilité et attributs ARIA », où leur rôle sera abordé plus concrètement.
Il est également important de voir que le HTML n’est pas isolé. Depuis l’introduction de HTML5, en 2008, le navigateur n’est plus seulement un outil de consultation, mais un véritable environnement applicatif. Ne pas hésiter à lire Dive into HTML5 de Mark Pilgrim qui décortique l’historique de cette période. Le langage s’est enrichi, avec de nouvelles balises sémantiques, mais aussi avec des passerelles vers des fonctionnalités jusque là réservées aux applications installées. Ces possibilités prennent vie grâce aux API intégrées au navigateur. Elles ne sont pas extérieures au HTML, elles en sont le prolongement direct et ouvrent la voie aux interactions que nous explorerons plus loin, notamment avec JavaScript.
L’enjeu n’est donc pas d’apprendre vite, mais d’apprendre juste. Comprendre ce que nous construisons. Poser une base solide. Cette approche change profondément la manière d’aborder le HTML. Nous ne cherchons plus à reproduire, mais à structurer.
La structure minimale d’un document HTML
Avant d’explorer les différentes parties du document, il est utile de comprendre qu’une page HTML complète repose sur une structure minimale. Cette structure ne décrit pas encore le contenu, mais le cadre dans lequel il va exister.
Un document HTML commence par une déclaration qui indique au navigateur le type de document, <!doctype html>. Elle est suivie d’un élément racine, <html>, qui contient l’ensemble de la page. À l’intérieur, deux zones principales coexistent. La première, <head>, fournit le contexte du document. La seconde, <body>, accueille le contenu visible.
<!doctype html>
<html lang="fr">
<head>
<!-- Le head contient les informations sur la page -->
<meta charset="utf-8">
<title>Première page</title>
</head>
<body>
<!-- Le body contient ce qui sera affiché -->
<h1>Bonjour</h1>
<p>Ce texte fait partie du contenu visible.</p>
</body>
</html>Nous distinguons ainsi clairement le contexte du document et son contenu. Le navigateur lit cette structure et sait immédiatement où trouver les informations et ce qu’il doit afficher. Cette organisation ne doit pas être vue comme une contrainte technique, mais comme une séparation des rôles. Le document existe, il possède un contexte, et il contient des informations. Comprendre cette distinction permet de mieux situer chaque élément et d’éviter de confondre ce qui décrit la page et ce qui la compose.
Dans la pratique, il arrive souvent de manipuler des fragments HTML isolés. Pourtant, ces fragments prennent toujours place, tôt ou tard, dans cette structure complète. La connaître permet de comprendre où nous intervenons réellement.
La partie invisible, <head>, métadonnées et contexte
Lorsque nous découvrons le HTML, l’attention se porte naturellement sur ce qui est visible. Les titres, les paragraphes, les images, les liens. Pourtant, une partie essentielle de la page ne s’affiche pas directement. Elle se situe dans la section <head>. Cette partie ne contient pas le contenu au sens classique. Elle contient des informations sur le contenu. Elle donne un contexte. Elle permet au navigateur, mais aussi à d’autres systèmes, de comprendre ce qu’ils sont en train de lire.
À ce stade, il ne s’agit pas d’apprendre en détail chaque balise, mais de comprendre leur rôle structurant. La présence de <title> montre que la page possède une identité. Les éléments <meta /> apportent des précisions techniques, comme l’encodage ou le comportement sur mobile. Les éléments <link /> établissent des relations avec d’autres ressources, comme une feuille de style ou une icône. Au fil de la construction, la page cesse d’être un simple affichage pour devenir un document décrit et interprété.
<head>
<!-- Encodage des caractères, indispensable pour afficher correctement les textes -->
<meta charset="utf-8">
<!-- Titre du document, utilisé par le navigateur et les moteurs de recherche -->
<title>Parcours d’apprentissage web</title>
<!-- Adaptation de l’affichage aux appareils mobiles -->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<!-- Icône associée à la page -->
<link rel="icon" href="favicon.svg" type="image/svg+xml">
</head>Ces éléments ne modifient pas directement le contenu visible, mais ils conditionnent la manière dont il est compris, affiché et utilisé. La spécification officielle, Document metadata, décrit précisément ce rôle des métadonnées. Prendre conscience de cette couche change profondément la perception du HTML. La page n’est plus seulement destinée à un lecteur humain. Elle existe aussi pour des navigateurs, des moteurs de recherche, des technologies d’assistance et des systèmes automatisés.
Nous reviendrons plus loin sur cette dimension, notamment dans le chapitre consacré à « Donner du sens, accessibilité et attributs ARIA », où les métadonnées et leur portée seront abordées plus en profondeur. À ce stade, il s’agit surtout de comprendre que le HTML ne se limite pas à ce qui est visible. Il définit aussi le contexte dans lequel le contenu existe.
Le contenu, matière première du HTML
Jusqu’ici, nous avons principalement évoqué le rôle structurant du HTML. Il organise, relie et identifie. Pourtant, il est essentiel de rappeler une réalité souvent implicite. Le HTML ne crée pas le contenu. Il l’accueille.
Le texte, les images, les tableaux, les sons ou les vidéos existent avant leur intégration. Ils sont rédigés, capturés, enregistrés ou préparés ailleurs. Le HTML intervient ensuite pour leur donner une place, une relation et un sens dans la page. Cette inversion de perspective modifie profondément notre approche. Nous ne produisons pas simplement une page. Nous organisons des ressources.
- Le contenu textuel provient fréquemment de fichiers
.txt,.rtf,.docxou.md, mais aussi de formats ouverts comme.odt. Leur préparation influence directement la qualité du résultat. L’encodage des caractères, la structuration des paragraphes ou l’organisation des données déterminent la lisibilité finale. Copier sans comprendre revient souvent à importer des défauts invisibles. - Les données tabulées sont souvent issues de fichiers de type
.xls,.xlsx,.ods,.numbersou.csv, ainsi que via des outils comme LibreOffice Calc, OpenOffice Calc, FreeOffice PlanMaker ou Google Sheets. Leur organisation en lignes et colonnes donne une apparence structurée, mais leur représentation informatique varie selon les formats et les outils. Lors de l’export ou de la copie, des artefacts peuvent apparaître (encodage, séparateurs, cellules fusionnées, formats implicites) et nuire à leur intégration dans une page HTML. Un travail de nettoyage est donc souvent nécessaire pour garantir une restitution fiable et exploitable. - Les images suivent la même logique. Les formats
.jpg,.png,.webp,.avifou.svgrépondent à des usages différents. On rencontre aussi des formats de travail comme.psdou.ai, ainsi que des formats bruts.raw(par exemple.nef,.cr2,.arw). Ces formats ne sont pas directement exploitables dans un navigateur : ils doivent être exportés vers des formats web adaptés. Préparer une image consiste donc à la rendre lisible, légère et compatible avec le contexte de diffusion.
Cette préparation inclut aussi des aspects souvent négligés : la correction orthographique des textes, la cohérence des données, et le respect des droits d’auteur. Éviter le copier-coller non maîtrisé, privilégier des contenus originaux ou des ressources libres de droit, (qu’il s’agisse de médias (images, sons, vidéos) ou de textes de substitution comme le lorem ipsum) fait partie intégrante du travail.
Il ne faut pas oublier l’optimisation, mais aussi l’adaptation aux différents contextes de consultation, un site n’est pas toujours consulté depuis un ordinateur, HDMI, ayant une connexion en fibre optique. Une image trop lourde, un son mal compressé ou une vidéo surdimensionnée ralentissent le chargement. Le HTML n’en corrige pas les défauts. Il s’appuie sur des ressources déjà adaptées. Préparer un média consiste donc à trouver un équilibre entre qualité, poids et usage, et parfois à proposer plusieurs versions d’une même image afin que le navigateur choisisse la plus appropriée selon l’écran, la résolution ou la connexion. Ce mécanisme, que nous approfondissons dans l’article Images responsives : comment le navigateur choisit une image, montre que le HTML ne se limite pas à afficher une image. Il participe à la décision.
Avant de structurer une page, prenons un instant pour préparer ce que nous allons intégrer. Un contenu bien rédigé, nettoyé, encodé correctement, vérifié sur le fond comme sur la forme, et allégé lorsque c’est nécessaire, facilite tout le travail qui suit. Plus la préparation est soignée, plus l’intégration devient simple, lisible et durable. Assurons-nous du contenu lui‑même, avant d’aborder sa mise en place dans la page. Cette étape dépasse la simple technique : elle s’inscrit dans une réflexion plus large sur la cohérence, la qualité et l’utilité de ce que nous produisons. Pour prolonger cette approche, voir l’article « Points clés sur sa stratégie de contenu ».
La partie visible <body>, structure et organisation de la page
Nous pouvons maintenant poser la base d’une première page, sans nous attarder sur le contenu. Avec HTML5, des balises dédiées ont été introduites pour découper clairement les grandes zones d’une page et leur donner un sens explicite. Pour une vue d’ensemble, voir « La structure HTML du document ». On y place simplement les grands blocs : <header> pour accueillir le logo, le nom du site et les premiers repères visuels, <nav> pour contenir les liens qui permettront de circuler d’une section à l’autre, <main> pour recevoir le contenu principal que nous allons réellement écrire, éventuellement <aside> pour proposer des compléments, des encarts ou des informations secondaires, et <footer> pour regrouper les éléments de fin de page, mentions, contacts ou rappels. L’objectif n’est pas l’apparence, mais la structure : le HTML organise et attribue un rôle à chaque partie.
<body>
<!-- En‑tête du site : logo et titre -->
<header>
<h1>Identification du site</h1>
</header>
<!-- Menu principal de navigation -->
<nav>
<!-- Nous placerons le menu de navigation, une fois l'ensemble des pages composé -->
</nav>
<!-- Contenu principal de la page -->
<main>
<p>Contenu principal</p>
</main>
<!-- Zone complémentaire -->
<aside>
<p>Informations complémentaires</p>
</aside>
<!-- Pied de page -->
<footer>
<p>Pied de page</p>
</footer>
</body>Le résultat peut sembler brut. C’est normal. Sans feuille de style, le navigateur applique uniquement ses styles par défaut, parfois appelés naked CSS. Les éléments apparaissent les uns sous les autres, sans mise en forme particulière. Ce dépouillement permet de voir la structure seule. Nous avons ainsi sous les yeux une ossature de page par défaut, un modèle de page (template). À partir de cette base, nous pourrons créer quelques pages nécessaires à notre arborescence, par exemple accueil.html, a-propos.html, contact.html, en conservant cette structure commune, tandis que le contenu de <main> variera d’une page à l’autre.
Créer une navigation simple, l’hyperlien <a>
Relier les pages entre elles transforme notre structure en véritable site. Cette étape repose sur un mécanisme simple, l’hyperlien, mais elle révèle la logique interne du projet. Chaque lien repose sur un chemin. Ce chemin indique au navigateur où trouver la ressource. Pour mieux comprendre ces notions de chemin et d’identification, voir l’article URI, URL, URN : Comprendre les bases des identifiants sur le web et, pour prolonger naturellement cette lecture, voir aussi l’article « Les liens et hyperliens ».
Le chemin peut s’écrire de trois manières : relatif au document, relatif à la racine du site, ou absolu. Pour le rendre concret, posons une petite arborescence :
/
├─ index.html
└─ pages/
├─ a-propos.html
└─ contact.htmlPour que cette logique prenne réellement sens, gardons une même destination (contact.html) et changeons simplement de point de départ (alternativement index.html et a-propos.html). C’est ce déplacement qui va révéler la différence entre les écritures possibles.
- Relatif au document (dépend de l’endroit où l’on se trouve) :
- depuis
index.html→<a href="pages/contact.html">Contact</a> - depuis
pages/a-propos.html→<a href="contact.html">Contact</a>
- depuis
- Relatif à la racine du site (commence par
/, indépendant du document courant) :- depuis
index.html→<a href="/pages/contact.html">Contact</a> - depuis
pages/a-propos.html→<a href="/pages/contact.html">Contact</a>
- depuis
- Absolu (URL complète, utile pour des ressources externes) :
- depuis
index.html→<a href="https://www.exemple.com/pages/contact.html">Contact</a> - depuis
pages/a-propos.html→<a href="https://www.exemple.com/pages/contact.html">Contact</a>
- depuis
Cette distinction peut sembler abstraite, mais elle devient très concrète dès que le projet grandit, elle évite les erreurs de liens quand la structure évolue et clarifie la manière dont les pages sont reliées entre elles. En mettant en place la navigation, nous voyons apparaître un réseau : les pages cessent d’être isolées et deviennent des points reliés entre eux.
<!-- Menu principal de navigation -->
<nav>
<ul>
<li><a href="/index.html">Accueil</a></li>
<li><a href="/pages/a-propos.html">À propos</a></li>
<li><a href="/pages/contact.html">Contact</a></li>
</ul>
</nav>Nous créons généralement une première page nommée index.html. Ce fichier constitue le point d’entrée du site. Lorsque le navigateur accède à un dossier, il recherche automatiquement ce nom. Certains serveurs acceptent également des variantes comme default.html, ainsi que leurs équivalents serveur comme index.php ou default.php. Cette convention permet d’afficher une page sans avoir à préciser son nom : lorsque nous saisissons simplement https://www.exemple.com/, le serveur renvoie automatiquement index.html (ou index.php), sans que ce fichier n’apparaisse dans l’URL.
À ce stade, peu importe le contenu exact. L’essentiel est de poser une structure claire, qui accueillera ensuite les styles, les interactions et les données. Le guide Structurer ses documents propose une exploration détaillée de cette organisation et du rôle de chaque balise.
Factoriser cette structure
Une fois cette structure répétée sur plusieurs pages, une évidence s’impose. Certaines parties restent identiques, généralement l’en‑tête, la navigation et le pied de page se répètent. Au début, nous copions ces fragments d’un fichier à l’autre. Cette méthode fonctionne, mais elle révèle rapidement ses limites. La moindre modification impose de corriger chaque page. Le risque d’erreur augmente, la cohérence diminue et la maintenance devient plus lourde. Cette situation introduit naturellement une nouvelle approche, la factorisation.
Factoriser consiste à extraire les parties communes pour les centraliser. La structure n’est plus dupliquée, elle est partagée. Le site devient plus cohérent, plus lisible et plus simple à faire évoluer. Une modification appliquée à un seul endroit se répercute immédiatement sur l’ensemble. Deux approches illustrent cette logique.
- Les includes PHP : L’utilisation de PHP introduit une transformation importante. Le fichier est d’abord interprété par un serveur, qui produit le HTML final. Le navigateur ne reçoit plus un fichier source, mais un résultat. Nous abordons cet aspect plus en détail dans l’article dédié au PHP, situé dans la Part VI de ce parcours, où nous verrons comment le serveur assemble et génère les pages dynamiquement.
- Les templates Dreamweaver : Dreamweaver propose un système de modèles qui permet de définir une structure commune, puis de créer des pages qui en héritent. Certaines zones restent verrouillées, d’autres restent modifiables. Cette approche facilite la cohérence et limite les erreurs lors des mises à jour. La documentation officielle propose Apprenez à utiliser des modèles Dreamweaver pour créer une mise en page « fixe » et créer des documents basés sur le modèle en conservant la même mise en page.
Ces méthodes reposent sur un même principe, séparer la structure et le contenu. Le fichier n’est plus nécessairement transmis tel quel au navigateur. Il peut être assemblé, complété ou généré.
Donner forme au contenu : découpe, hiérarchie et organisation
Jusqu’ici, nous avons structuré la page dans son ensemble. Nous avons posé une ossature, défini des zones, organisé les grandes parties du document. Mais une fois cette structure en place, une autre étape commence. Elle ne concerne plus la page elle-même, mais le contenu qu’elle accueille. Car le contenu n’est pas un bloc uniforme. Il se compose de titres, de paragraphes, de listes, de liens, de fragments de texte. Lui aussi possède une organisation, une hiérarchie, une logique interne. C’est cette structure plus fine que nous allons maintenant explorer, à l’intérieur de <main> ou <aside>, là où le contenu prend réellement forme.
Face au HTML, la première impression peut être déroutante. Pourtant, en prenant le temps d’observer, une logique claire et progressive apparaît. Il existe des dizaines de balises, chacune avec ses attributs, ses variantes et ses usages. À en voir la liste sur HTML : HyperText Markup Language, (section Référence des éléments & attributs dans le menu de gauche) chercher à tout apprendre d’un seul bloc conduit souvent à se perdre. Il est plus efficace de comprendre comment ces éléments s’organisent.
Ces éléments prennent place dans la partie visible du document, à l’intérieur de <body>. Mais ce qui nous intéresse ici ne se situe plus au niveau de cette organisation générale. Le regard se déplace vers <main> et <aside>, là où le contenu est effectivement écrit, assemblé, et mis en relation. C’est à cet endroit que la structure change de nature. Elle ne consiste plus à répartir des zones dans la page, mais à organiser des éléments entre eux : titres, paragraphes, liens, fragments de texte. La structure devient plus fine, plus proche du contenu lui-même, et c’est cette organisation que nous allons maintenant préciser, en la hiérarchisant et en reliant ses différentes parties.
Une première distinction apparaît rapidement, toujours celle des conteneurs et des contenus. Les premiers servent à organiser et à structurer le contenu, en définissant des zones, des regroupements ou des sections, comme <section>, <article>, <div>, <blockquote>… Les seconds portent l’information elle‑même : ils donnent du sens à ce qui est affiché, comme <h1>, <h2>, <h3>…, <p>, <a>, <form>, <svg>, <code>, <pre>… ou <img />. Autrement dit, certains éléments structurent, tandis que d’autres expriment. Pour comprendre plus finement ces organisations, la notion de Catégories de contenu apporte un éclairage complémentaire.
Dans cette logique, l’approche d’Andy Clarke apporte un éclairage intéressant, notamment dans son ouvrage Transcender les CSS. Bien qu’il s’agisse d’un livre consacré aux styles CSS, il est encadré par des figures majeures des standards du web, avec un avant‑propos de Molly E. Holzschlag, pionnière de la normalisation du web, engagée très tôt dans la diffusion des standards et dans une approche pédagogique visant à les rendre accessibles aux développeurs Thinking Outside the Grid (2005), et une préface de Dave Shea, créateur du projet CSS Zen Garden. Dès les premières pages, une idée forte s’impose : les CSS ne prennent sens que sur une base HTML solide.
Andy Clarke insiste précisément sur ce point. Pour lui, la qualité du rendu, de l’adaptation et de l’expérience dépend d’abord de la manière dont le document est structuré. Il propose de voir le HTML non pas comme une succession de balises, mais comme une manière de donner un rôle à chaque élément du monde que nous décrivons. Comme il l’exprime : « Baliser le monde entier… le monde est une liste ; chaque élément doit y jouer son rôle ». Cette idée devient très concrète dès que l’on construit une page : nous ne plaçons plus simplement du contenu, nous organisons des éléments qui ont chacun une fonction, une place et une relation aux autres, sur lesquels viendront ensuite s’appuyer les CSS.
En attendant les données définitives, il est courant d’utiliser du texte temporaire ou des médias de substitution. Ces éléments permettent de tester la structure et d’en vérifier la cohérence, sans dépendre du contenu final. Bien que l’article ne soit pas finalisé, vous trouverez sur Utiliser des médias libres de droit ou des gardes places, un ensemble de liens vous permettant de trouver des images, des typos, du texte… et bien plus encore.
Cette organisation ne concerne pas uniquement l’affichage ou la lisibilité. Elle influence également la manière dont les contenus sont interprétés par les moteurs de recherche. Une page bien structurée, composée de contenus clairs, hiérarchisés et correctement reliés, devient plus facilement compréhensible, non seulement pour l’utilisateur, mais aussi pour les systèmes qui la parcourent. Le HTML joue ici un rôle discret mais essentiel : il ne référence pas une page, mais il contribue directement à la rendre lisible et exploitable dans un contexte plus large. Pour approfondir cette logique, voir « Référencement d’une page existante ».
Cette distinction introduit une hiérarchie essentielle. La page devient un ensemble organisé, et non une simple succession de balises.
Au cœur du texte : éléments inline et nuances sémantiques
Une fois la structure générale en place et le contenu réparti dans les diverses balises, un second niveau d’affinage apparaît. Il concerne non plus les blocs, mais le texte et les éléments eux‑mêmes.
Certains éléments permettent de préciser, nuancer et enrichir le sens à l’intérieur d’un paragraphe. Les balises <strong> ou <em> marquent une emphase. <small> introduit une information secondaire. <sup> et <sub> permettent d’exprimer une note, une référence ou une formule. La balise <span> occupe une place particulière, car elle est neutre. Elle agit comme un repère discret, sans modifier le sens lui-même. Elle ne porte pas de sens propre, mais sert à cibler ou isoler une portion de texte, notamment pour lui appliquer un style ou un comportement. Ces éléments ne structurent pas la page, mais le sens du contenu lui‑même.
<!-- Exemple 1 : titre avec imbrications inline (emphase, note, lien) -->
<h1>
<small>
<span class="meta">
<strong>
<em>
Comprendre le HTML <sup><a href="#note-1">1</a></sup>
</em>
</strong>
</span>
</small>
</h1>
<!-- Exemple 2 : paragraphe avec code, emphase et repères -->
<p>
Nous avançons par étapes avec la fonction <code>render()</code>, en gardant
<em>une structure claire</em>. <span class="repere">Ce passage sert de repère</span>
pendant la relecture. Ensuite, nous ajoutons du contenu réel,
<strong><span class="position">au bon endroit</span></strong>, sans casser l’ensemble.
</p>
<!-- Exemple 3 : titre + préformaté imbriqué (illustration) -->
<h1>
<em>Exemple <code>HTML</code></em>
<small>
<span class="note">(structure <strong>inline</strong> imbriquée)</span>
</small>
</h1>Ce niveau plus fin complète la hiérarchie introduite précédemment. La page ne se compose plus seulement de zones et de sections, mais d’un texte dont chaque partie peut être qualifiée. Pour approfondir spécifiquement la manière de découper et qualifier le texte, voir l’article « Le texte HTML et sa découpe ». La documentation MDN propose une vue détaillée de ces éléments et de leur rôle :dans Référence des éléments HTML. Progressivement, le HTML révèle sa cohérence profonde. Des grandes zones de structure jusqu’aux nuances du texte, chaque balise contribue à décrire le contenu avec précision.
Le flux du document et l’organisation des nœuds dans le DOM
Au‑delà des balises elles‑mêmes, le HTML repose sur une logique de flux. Les éléments ne sont pas simplement posés les uns à côté des autres, ils sont imbriqués. Certains contiennent, d’autres sont contenus. Cette relation crée une continuité. Cette organisation introduit une notion implicite, celle de parent et d’enfant. Un élément existe à l’intérieur d’un autre. Il hérite de son contexte. Il participe à un ensemble plus large. La page devient une structure vivante, où chaque partie prend sens par sa position.
L’ordre dans lequel les éléments apparaissent joue également un rôle. Le navigateur lit le document de haut en bas. Cette lecture progressive construit l’interprétation. Elle influence l’affichage, mais aussi les interactions futures. Comprendre cette continuité permet d’éviter une erreur fréquente, considérer les éléments comme indépendants. En réalité, ils sont profondément liés. Une balise mal placée, mal fermée ou mal imbriquée peut fragiliser l’ensemble.
Cette notion d’imbrication dépasse le HTML lui‑même. Le CSS s’appuiera sur ces relations pour appliquer ses styles. Le JavaScript utilisera cette organisation pour accéder aux éléments et les manipuler. Ce que nous découvrons ici constitue une base essentielle pour la suite.
Peu à peu, la page cesse d’être une juxtaposition. Elle devient une structure cohérente, organisée selon un flux naturel. Cette structure porte un nom, le DOM, Document Object Model. Le navigateur transforme le HTML en une arborescence d’objets, où chaque élément devient un nœud relié aux autres. Cette représentation rend la page navigable, modifiable et manipulable. Le CSS et le JavaScript n’agissent pas directement sur le texte HTML, mais sur ce DOM.
Pour approfondir cette notion, la référence suivante permet d’en explorer les fondements en lisant Référence du DOM sur MDN et pour voir concrètement comment il est possible d’agir sur cette structure, ce qu’on appelle le DOM-Scripting, rapprochez vous de Manipuler des documents, toujours sur MDN.
Identifier les noeuds, <id>, <class> et attributs globaux
Une fois la structure en place, une nouvelle étape commence. Les différents éléments doivent pouvoir être identifiés. Jusqu’ici, ils existent, mais ils ne possèdent pas encore de références propres. Pour qu’ils puissent être ciblés, reliés ou manipulés, ils doivent recevoir des marqueurs distinctifs.
Dans le chapitre précédent, nous avons utilisé plusieurs balises <span> pour isoler des portions de texte. Pourtant, ces éléments restent difficiles à atteindre précisément. Ils existent, mais rien ne permet encore de les désigner individuellement. C’est ici qu’interviennent les attributs. Ils permettent d’affiner le sens des balises, et surtout de leur donner une identité exploitable.
Les deux attributs les plus structurants dans cette démarche sont id et class. Le premier permet d’identifier un élément de manière unique. Il désigne une occurrence précise dans la page. Le second permet de regrouper plusieurs éléments partageant une même nature, une même fonction ou un même rôle. Il ne désigne plus un point isolé, mais une famille.
<!-- Exemple complet : structure + identifiants (id) + regroupements (class) -->
<main id="contenu-principal">
<article class="fiche fiche-projet">
<header class="zone zone-entete">
<!-- id unique pour ciblage direct -->
<h1 id="titre-projet">RIDA <small>Riders Data Assistant</small></h1>
<p class="accroche texte-court">Un outil pensé pour organiser la préparation d’une compétition.</p>
</header>
<section class="zone zone-contenu">
<h2 class="titre-section">Organisation</h2>
<p class="texte">
Chaque <strong class="mot-cle">catégorie</strong> contient des tâches,
<a href="#" class="lien lien-secondaire">des détails</a>
et parfois <span class="etat etat-brouillon">un état d’avancement</span>.
</p>
</section>
</article>
</main>
<footer class="zone zone-pied">
<p id="status" class="etat etat-brouillon">Statut : brouillon</p>
<!-- Plusieurs <p> avec une classe commune + des classes spécifiques -->
<address class="bloc-contact">
<p class="coord coord-nom">Puce & Média</p>
<p class="coord coord-adresse">12 rue des Ateliers</p>
<p class="coord coord-ville">13100 Aix-en-Provence</p>
<p class="coord coord-tel">Tél : 04 00 00 00 00</p>
<p class="coord coord-mail">
<a href="mailto:contact@puce-et-media.com" class="lien lien-contact">contact@puce-et-media.com</a>
</p>
</address>
</footer>
<!--
Points clés :
- id : identifie un élément unique (ex : #titre-projet, #status)
- class : permet de regrouper (ex : .coord pour toutes les lignes de contact)
- classes multiples : combinent un rôle commun + une spécificité (ex : "etat etat-brouillon")
- on ne dépend plus uniquement de la position dans le DOM, mais du rôle attribué
-->Autrement dit, là où la navigation dans l’arborescence reste possible, l’utilisation de id et class offre un accès plus direct, plus lisible et surtout plus robuste. Nous ne dépendons plus uniquement de la position d’un élément, mais de son rôle dans la structure.
La manière de nommer ces identifiants n’est pas anodine. Elle influence directement la lisibilité et l’évolution du projet. Avec le temps, différentes approches ont émergé pour structurer cette nomenclature, comme OOCSS, BEM, Atomic Design, SMACSS ou ITCSS. Ces méthodes ne concernent pas uniquement le CSS. Elles prennent racine dans le HTML lui‑même, au moment où les éléments reçoivent leurs noms. Elles proposent une manière d’organiser la structure pour la rendre plus claire, plus modulaire et plus durable. Nous approfondirons ces notions dans l’article suivant consacrée au CSS (Parcours d’apprentissage web – Part III : CSS, mise en forme et adaptation).
Peu à peu, la structure cesse d’être seulement organisée. Elle devient référencée. Chaque partie peut être désignée, retrouvée, utilisée.
D’autres attributs viennent naturellement compléter cette capacité d’identification. L’attribut title permet d’ajouter une information contextuelle. L’attribut lang précise la langue d’un élément. L’attribut href établit une relation vers une ressource. L’attribut src désigne l’origine d’un média. Et les attributs data-* occupent une place particulière. Ils permettent d’attacher des données personnalisées, propres au projet, sans modifier la structure ni la sémantique du document. Ils constituent un pont précieux entre le HTML et les scripts.
<h1 id="titre-page" lang="fr" title="Présentation du site">À propos</h1>
<p class="introduction" data-section="presentation">
Nous avançons par étapes, en gardant une structure claire.
<span class="repere" title="Point de repère temporaire">Ce passage sert de repère</span>
pendant la relecture.
Ensuite, nous ajoutons du contenu réel,
<span class="position" data-role="emphase" lang="fr">au bon endroit</span>,
sans casser l’ensemble.
</p>
<img src="image-temporaire.jpg" alt="Image de substitution" title="Illustration provisoire">
<a href="contact.html" title="Accéder à la page de contact">Nous contacter</a>
/* --- Ponts vers CSS et JavaScript (illustration) --- */
/* CSS : cibler par attribut personnalisé (data-role) */
/* Met en évidence les éléments marqués comme emphase */
[data-role="emphase"] {
font-weight: 700;
text-decoration: underline;
}
/* CSS : cibler par attribut title (info contextuelle) */
/* Exemple : ajouter un style aux éléments possédant un title */
[title] {
border-bottom: 1px dotted currentColor;
cursor: help;
}
<script>
// JavaScript : accès direct par identifiant unique (id)
const titre = document.getElementById('titre-page');
titre.textContent = 'À propos (mis à jour par script)';
// JavaScript : sélection par attribut data-*
const emphases = document.querySelectorAll('[data-role="emphase"]');
emphases.forEach(el => el.setAttribute('title', 'Élément mis en valeur'));
</script>Chaque attribut ajoute ici une couche d’information supplémentaire. Certains précisent la langue, d’autres la destination d’un lien, d’autres encore un rôle interne au projet. Le HTML devient ainsi non seulement structuré, mais aussi documenté et enrichi. Pour prolonger cette logique de nommage et de sens, voir « Du nom au sens : conventions, cohérence et langage du code ».
Cette capacité à porter de l’information dépasse le seul affichage et rejoint la question des métadonnées. Pour une vue plus large, voir « Métadonnées : parler aux humains et aux intelligences artificielles ». À ce stade, il ne s’agit pas d’apprendre une syntaxe complète, mais de comprendre une logique. Chaque élément peut recevoir une identité. Cette identité lui permet d’exister non seulement dans la structure, mais aussi dans les interactions à venir.
Le HTML devient alors un point de rencontre. Il relie le contenu, la présentation et le comportement. Cette capacité d’identification constitue la première étape vers l’interconnexion des différentes couches du web.
Accessibilité et attributs ARIA
À ce stade, la structure fonctionne et la sémantique HTML a déjà permis de donner du sens au document. Le contenu est organisé, hiérarchisé, interprétable. Pourtant, cette première couche, aussi essentielle soit‑elle, ne couvre pas toutes les situations de lecture. Le web n’est pas consulté uniquement dans des conditions visuelles standard. Certaines personnes utilisent des lecteurs d’écran, d’autres naviguent sans interface graphique, d’autres encore sont en situation de handicap visuel, moteur ou cognitif. La page existe alors sous d’autres formes. Ignorer cette diversité reviendrait à construire un site partiellement lisible.
Il devient donc nécessaire de prolonger la sémantique native, non pour la remplacer, mais pour la compléter. Certains attributs permettent de préciser l’intention, le rôle ou la relation entre les éléments. Ils rendent explicite ce qui, autrement, resterait implicite. Pour comprendre les enjeux et les limites de cette seule approche structurelle, nous pouvons nous appuyer sur Structure et sémantique, est ce suffisant pour être accessible ?, Qu’entend-on par accessibilité ? et Introduction to Web Accessibility. Ces ressources montrent que la sémantique HTML constitue une base essentielle, mais qu’elle doit parfois être enrichie pour garantir une accessibilité réelle.
<!-- Même exemple enrichi avec des attributs ARIA pour améliorer l’accessibilité -->
<h1 id="titre-page" lang="fr" title="Présentation du site" aria-describedby="desc-page">À propos</h1>
<p class="introduction" data-section="presentation" id="desc-page">
Nous avançons par étapes, en gardant une structure claire.
<span class="repere" title="Point de repère temporaire" aria-label="Repère de lecture">Ce passage sert de repère</span>
pendant la relecture.
Ensuite, nous ajoutons du contenu réel,
<span class="position" data-role="emphase" lang="fr" role="note" aria-label="Emphase importante">au bon endroit</span>,
sans casser l’ensemble.
</p>
<img src="image-temporaire.jpg"
alt="Image de substitution"
title="Illustration provisoire"
role="img"
aria-label="Illustration temporaire de présentation">
<a href="contact.html"
title="Accéder à la page de contact"
role="link"
aria-label="Accéder à la page de contact">Nous contacter</a>Ces attributs aria-* n’ajoutent pas de contenu visible, mais ils fournissent des informations essentielles aux technologies d’assistance. Ils permettent par exemple à un lecteur d’écran de préciser le rôle d’un élément, son intention ou sa relation avec d’autres parties du document. Cette réflexion est approfondie dans ces deux articles Accessibilité web : comprendre avant de coder et Accessibilité web : penser un site dès la page blanche.
Introduire une première interaction avec l’utilisateur, le formulaire
Jusqu’ici, le site présente des informations et permet de circuler d’une page à l’autre. Le formulaire introduit une dimension nouvelle. La page ne se limite pas à être consultée. Elle devient un point de contact. L’utilisateur peut écrire, sélectionner, envoyer. Même si les données ne sont pas encore traitées, leur simple présence transforme la nature du site. La page n’est plus seulement un support de lecture. Elle devient un espace d’expression. Nous découvrons alors de nouveaux éléments, <form>, <label>, <input>, <textarea>. Chacun possède un rôle précis. Certains définissent la zone d’échange, d’autres permettent la saisie, d’autres encore décrivent les informations attendues. Le HTML ne traite pas encore les données, mais il prépare leur transmission.
Cette étape révèle une idée essentielle. Une page peut désormais transmettre des informations vers une autre page, vers un script ou vers un serveur. Elle devient capable de participer à un dialogue. Nous aborderons la réception, le contrôle et la sécurisation de ces données dans la Part VIII consacrée à Relier PHP et MySQL, organiser le dialogue entre traitement et données. Pour l’instant, il s’agit de comprendre que le HTML permet d’ouvrir un canal d’échange, et qu’il prépare le terrain des interactions futures avec La gestion des formulaires.
Le site ne se contente plus d’exister. Il commence à dialoguer.
Le formulaire nous a permis d’ouvrir un premier canal d’échange. À l’inverse, de nombreuses pages ont pour objectif principal de présenter des informations déjà structurées. Dans ce cas, le HTML ne sert plus à capter des données, mais à les restituer de manière claire et organisée.
Tableaux : restituer des données, pas structurer une page
Lorsque les données existent déjà, sous forme de lignes et de colonnes, ou de données déjà structurées, le HTML propose une structure adaptée pour les représenter. Ils servent à représenter des données tabulées, souvent issues de fichiers comme .xls, .xlsx ou .csv. Le HTML ne crée pas ces données, il en reproduit l’organisation. En pratique, cela demande de l’attention : un tableau large se dégrade vite sur smartphone en portrait, et des volumes importants deviennent difficiles à lire. On privilégie alors des solutions adaptées à l’usage (défilement horizontal contrôlé, découpage, ou tableaux filtrables et interactifs lorsque c’est pertinent).
Ils ne doivent pas être utilisés pour construire une mise en page. Cette pratique, fréquente autrefois, rend les pages difficiles à maintenir et à faire évoluer. Pour approfondir les bonnes pratiques et la combinaison des balises, voir l’article « Les tableaux, et les données tabulées ». À partir d’un certain niveau de complexité, leur génération est d’ailleurs souvent pilotée côté serveur.
Côté outillage, certains éditeurs facilitent l’import : Dreamweaver permet par exemple de coller un tableau depuis Excel, puis de nettoyer le code via Outils > Nettoyer HTML (voir la documentation Adobe sur l’import/export de données tabulaires).
Toutes les informations ne se prêtent pas à une organisation en tableau. Lorsque la structure devient plus simple, plus souple, d’autres formes apparaissent.
Listes : énumérer et structurer l’information
Lorsque les données ne prennent pas la forme de lignes et de colonnes, d’autres structures s’imposent. Toutes les informations ne relèvent pas d’un tableau. Certaines s’expriment sous forme d’énumérations, de suites d’éléments ou de relations plus souples. C’est dans ces situations que les listes trouvent leur place. Les listes permettent d’adapter la forme à la nature de l’information. Dans la pratique, nous ne choisissons pas une balise par habitude, mais en fonction de ce que nous voulons exprimer, en utilisant <ul>, <ol> ou <dl> selon le sens recherché.
<!--
Une liste non ordonnée (<ul>) sert par exemple à regrouper des éléments sans notion de priorité
Ici, l’ordre importe peu. Chaque étape existe au même niveau.
-->
<ul>
<li>Installer un éditeur</li>
<li>Créer un premier fichier HTML</li>
<li>Tester dans le navigateur</li>
</ul>
<!--
À l’inverse, une liste ordonnée (<ol>) introduit une progression :
À l’inverse, une liste ordonnée (<ol>) introduit une progression :
-->
<ol>
<li>Écrire la structure HTML</li>
<li>Ajouter le contenu</li>
<li>Vérifier l’affichage</li>
</ol>
<!--
Enfin, les listes de définition (<dl>) permettent de poser des termes et de les expliciter :
Nous ne sommes plus dans une simple énumération, mais dans une relation entre un terme et sa description.
-->
<dl>
<dt>HTML</dt>
<dd>Langage de structuration des contenus</dd>
<dt>CSS</dt>
<dd>Langage de mise en forme</dd>
</dl>Ces différentes formes ne sont pas interchangeables. Elles traduisent une intention : énumérer, ordonner ou définir. En les choisissant correctement, nous aidons le lecteur, et les outils, à comprendre la nature même de l’information. Elles offrent une lecture claire, adaptée aux contenus organisés ou hiérarchisés.
Les médias dans une page HTML
Toutes les structures que nous avons vues jusqu’ici mettent en forme du texte et des relations entre éléments. Pourtant, une page ne se limite pas à des mots. Elle accueille aussi des contenus visuels et sonores, qui répondent à d’autres logiques. Après avoir appris à structurer et à énumérer l’information, il devient naturel de se demander comment intégrer ces formes de contenu sans perdre le sens construit jusque‑là. C’est dans ce passage que la question des médias prend place.
La question devient alors : comment intégrer les différents types de médias dans la page. Tous ne se manipulent pas de la même manière, et leur usage dépend avant tout de leur rôle, et puis quelles balises employer. L’article « Les médias et les multimédias » présente un rapide aperçu des divers types de médias et la manière de les intégrer.
Images : contenu ou habillage
Une image peut être utilisée de deux façons, selon le rôle que nous lui donnons dans la page. Lorsqu’elle porte une information, comme une photo, une illustration, ou un schéma, nous l’intégrons directement dans le HTML avec la balise <img />. Elle devient alors un élément du contenu, au même titre qu’un paragraphe, avec un alt pour décrire ce qu’elle représente et, si nécessaire, un title pour apporter un complément. Dans ce cas, l’image participe à la compréhension du document.
<!-- Image intégrée au contenu : elle a un sens dans la page -->
<figure>
<img src="schema-reseau.webp" alt="Schéma simplifié du réseau" title="Architecture réseau" />
<figcaption>Organisation des éléments dans le réseau</figcaption>
</figure>Cette approche prend encore plus de sens dès que l’on adapte les images aux différents écrans et contextes de lecture. Le navigateur peut alors choisir la version la plus adaptée. Nous détaillons ce mécanisme dans l’article « Images responsives : comment le navigateur choisit une image ». À l’inverse, certaines images ne portent pas directement d’information. Elles accompagnent la mise en forme : logo répété, texture, arrière-plan, illustration décorative. Dans ce cas, elles relèvent du CSS et sont généralement utilisées via background-image. Elles ne décrivent pas le contenu, elles participent à sa présentation.
/* Image utilisée pour l’habillage : rôle visuel, non sémantique */
.header {
background-image: url("/assets/images/header-bg.webp");
background-size: cover;
}Ce point sera approfondi dans la partie suivante de la série consacrée au CSS, mais vous pouvez déjà consulter la documentation officielle, background-image – CSS – MDN, pour comprendre le fonctionnement de cette propriété.
Ce choix entre
<img />etbackground-imageest fondamental : il distingue ce qui porte l’information de ce qui accompagne la présentation. Il n’est pas anodin, car il permet de distinguer ce qui relève du sens et ce qui relève de la mise en forme.
Le cas particulier du SVG
Le format .svg occupe une place à part. Contrairement aux formats d’image classiques, il ne s’agit pas seulement d’un fichier visuel, mais d’un document descriptif (vectoriel) basé sur du texte. Cela change la manière de l’utiliser. Lorsqu’il est appelé via <img />, il se comporte comme une image classique. Mais il peut aussi être intégré directement dans le HTML. Dans ce cas, il devient un élément du document, modifiable, stylisable et potentiellement interactif.
<!-- SVG intégré directement dans le HTML -->
<svg width="120" height="120" viewBox="0 0 120 120" aria-hidden="true">
<circle cx="60" cy="60" r="50" fill="steelblue" />
</svg>Ici, le visuel ne dépend plus d’un fichier externe : il fait partie de la structure. On peut lui appliquer des styles CSS, ajuster ses propriétés, voire le manipuler plus tard avec JavaScript.
/* Exemple : styliser un SVG inline */
svg circle {
fill: rebeccapurple;
}Cette approche ouvre des possibilités concrètes :
- accessibilité (titres, descriptions, rôles ARIA)
- adaptation sans perte de qualité (vectoriel)
- animation et interaction (CSS et JavaScript)
Le SVG peut même aller plus loin en intégrant une véritable couche d’interactivité. Il ne sert plus seulement à afficher un visuel, mais peut devenir une interface à part entière. Un bon exemple en est le plan du studio de Puce & Média, où la légende permet d’afficher ou de masquer différentes couches du schéma. Le SVG illustre parfaitement la frontière entre média et structure : il n’est plus seulement affiché, il participe au document. C’est un bon exemple de la manière dont le HTML peut aller au-delà de la simple intégration pour devenir un véritable support de description et d’interaction.
Vidéo et audio : des contraintes techniques spécifiques
Les médias audio et vidéo introduisent une réalité différente. Contrairement à une image, ils ne se contentent pas d’être affichés : ils doivent être diffusés, chargés progressivement et parfois adaptés en fonction du contexte. Cela implique des formats spécifiques, mais aussi, dans certains cas, une configuration serveur capable de gérer ces flux. Dans la pratique, nous passons rarement directement par un hébergement “brut”. Il est souvent plus simple, et plus fiable, de s’appuyer sur des plateformes comme YouTube ou Dailymotion. Elles prennent en charge l’encodage, l’adaptation aux connexions et la diffusion. Le HTML devient alors un point d’entrée : nous intégrons un lecteur via une iframe, sans avoir à gérer toute l’infrastructure.
<!-- Intégration d’une vidéo YouTube via iframe -->
<iframe src="https://www.youtube.com/embed/VIDEO_ID" title="Vidéo" allowfullscreen></iframe>Ces plateformes proposent également des paramètres avancés pour contrôler le lecteur (lecture automatique, contrôles, etc.), comme le détaille leurs documentations officielles : YouTube Embedded Players and Player Parameters et Choisir votre méthode d’intégration du Player. Cependant, cela ne signifie pas que le HTML5 est limité. Les balises <video> et <audio> permettent une intégration directe, sans plateforme intermédiaire :
<!-- Lecture vidéo native HTML5 -->
<video controls width="640">
<source src="video.mp4" type="video/mp4">
Votre navigateur ne supporte pas la lecture vidéo.
</video>Cette approche donne plus de contrôle, mais demande aussi plus de rigueur dans la préparation des fichiers et leur diffusion. Elle constitue une alternative intéressante, notamment dans des contextes maîtrisés.
<!-- Exemple plus complet : plusieurs formats et options -->
<video controls poster="image.png" preload="metadata">
<source src="video.mp4" type="video/mp4; codecs=avc1.42E01E, mp4a.40.2" />
<source src="video.webm" type="video/webm; codecs=vp8, vorbis" />
<source src="video.ogv" type="video/ogg; codecs=theora, vorbis" />
</video>Dans cet exemple, nous ne fournissons pas une seule vidéo, mais plusieurs formats. Le navigateur parcourt la liste et choisit automatiquement celui qu’il sait lire. L’attribut poster permet d’afficher une image d’attente, et preload="metadata" limite le chargement initial pour préserver les performances. Le navigateur ne lit pas tout en bloc. Il teste chaque source, s’arrête à la première compatible, et adapte le chargement selon le contexte (connexion, appareil, capacités). Cette logique, souvent invisible, conditionne pourtant directement l’expérience de lecture.
La documentation MDN propose une exploration complète de ces API, APIs vidéos et audio. Pour une approche plus globale côté HTML5, voir également L’audio / vidéo en HTML5. Pour aller plus loin, nous pouvons déjà entrevoir ce que permettra JavaScript, que nous aborderons dans la partie suivante de cette série (Parcours d’apprentissage web – Part IV : JavaScript, interactions et navigateur). Sans entrer dans les détails ici, ces pistes montrent comment le média devient interactif et pilotable :
- Comprendre le fonctionnement global côté navigateur : L’API vidéo
- Commencer par comprendre comment contrôler une lecture vidéo : Contrôler une vidéo par JavaScript
- Ajouter des éléments utiles à la lecture, comme des sous-titres : Sous-titres vidéo
- Introduire des repères dans le temps pour naviguer dans le contenu : Utiliser des points de repère en vidéo
- Aller plus loin en pilotant un lecteur externe depuis sa propre interface : Reprendre le contrôle : piloter YouTube depuis votre propre interface
Ces approches relèvent d’une couche supplémentaire, où le HTML sert de base et JavaScript vient enrichir le comportement. Elles permettent de passer d’un média affiché à un média réellement interactif.
Le choix dépend donc du contexte : déléguer la diffusion à une plateforme, ou garder la maîtrise avec HTML5. Dans tous les cas, le HTML reste le point de liaison entre le média et son affichage dans la page.
Documents et ressources externes
Certains fichiers ne sont pas intégrés directement dans la page. Les documents PDF, par exemple, sont aujourd’hui souvent affichés nativement par le navigateur, mais ils restent des ressources externes. En pratique, le rendu peut varier d’un navigateur à l’autre : certains proposent un lecteur complet (zoom, navigation, annotations), d’autres se limitent à un affichage plus simple, et certains environnements déclenchent directement le téléchargement. Cette variabilité doit être anticipée, car elle influence l’expérience de lecture.
<!-- Ouverture d’un PDF dans le navigateur -->
<a href="/docs/guide.pdf" target="_blank" rel="noopener">Consulter le guide (PDF)</a>
<!-- Selon le contexte, il peut être pertinent de proposer explicitement le téléchargement plutôt que l’affichage :-->
<!-- Forcer le téléchargement côté navigateur -->
<a href="/docs/guide.pdf" download>Télécharger le guide (PDF)</a>Au-delà du HTML, la gestion de ces documents peut aussi être pilotée côté serveur. Avec PHP, il est possible de contrôler finement la distribution des fichiers (droits d’accès, journalisation, nom de fichier, en-têtes HTTP) et d’imposer un téléchargement :
<?php
// Envoi d’un PDF en téléchargement contrôlé
header('Content-Type: application/pdf');
header('Content-Disposition: attachment; filename="guide.pdf"');
readfile(__DIR__ . '/docs/guide.pdf');
exit;D’autres formats ne peuvent pas être affichés directement dans la page. Ils deviennent alors des ressources à télécharger ou à ouvrir avec un outil adapté. Là encore, le rôle du HTML est de décrire l’accès au fichier, tandis que le navigateur, et éventuellement le serveur, gère la suite.
Au final, intégrer un média ne consiste pas seulement à l’afficher. Il s’agit de choisir la bonne méthode en fonction de son rôle, de son usage et de son contexte. Le HTML agit ici comme un point de rencontre entre le contenu, la technique et l’expérience de lecture.
Métadonnées, décrire le document au-delà du visible
Aller plus loin implique d’utiliser aussi les métadonnées, qui prolongent ce que nous avons commencé à construire. Jusqu’ici, nous avons donné une structure, puis une sémantique, puis une accessibilité. Les métadonnées introduisent une nouvelle couche. Elles ne s’adressent plus directement au lecteur humain, mais aux systèmes qui lisent la page en parallèle de lui. Métadonnées : parler aux humains et aux intelligences artificielles.
Cette dimension ne concerne pas uniquement l’organisation visuelle. Elle concerne la capacité du document à être identifié, interprété et relayé. Une page peut être analysée par un moteur de recherche, résumée par un agent automatisé, intégrée dans un partage sur un réseau, ou exploitée par une application distante. Dans ces situations, le HTML visible ne suffit plus. Il devient nécessaire de fournir des informations complémentaires, structurées et explicites.
Ces informations prennent différentes formes. Certaines sont intégrées dans la section <head> sous forme de balises <meta> comme nous avons dans le chapitre La partie invisible, <head>, métadonnées et contexte. D’autres utilisent des formats structurés comme les microdatas, les microformats, les vocabulaires de Schema.org, ou des blocs de données encodés en JSON, souvent appelés JSON‑LD. Ces mécanismes permettent par exemple de décrire un article, une personne, un événement ou une organisation. Ils donnent à la page une existence au‑delà de son affichage immédiat. Ces sujets dépassent le cadre de ce chapitre et feront l’objet d’un article dédié. Ce qu’il faut retenir ici, c’est que le HTML ne constitue pas seulement un document à lire, mais aussi une source d’information à interpréter.
<!-- Exemple précédent enrichi avec des microdonnées Schema.org directement dans le HTML -->
<div itemscope itemtype="https://schema.org/Organization">
<h1 id="titre-page"
lang="fr"
title="Présentation du site"
aria-describedby="desc-page"
itemprop="name">
À propos
</h1>
<p class="introduction"
data-section="presentation"
id="desc-page"
itemprop="description">
Nous avançons par étapes, en gardant une structure claire.
<span class="repere"
title="Point de repère temporaire"
aria-label="Repère de lecture">
Ce passage sert de repère
</span>
pendant la relecture.
Ensuite, nous ajoutons du contenu réel,
<span class="position"
data-role="emphase"
lang="fr"
role="note"
aria-label="Emphase importante">
au bon endroit
</span>,
sans casser l’ensemble.
</p>
<img src="image-temporaire.jpg"
alt="Image de substitution"
title="Illustration provisoire"
role="img"
aria-label="Illustration temporaire de présentation"
itemprop="logo">
<a href="contact.html"
title="Accéder à la page de contact"
role="link"
aria-label="Accéder à la page de contact"
itemprop="url">
Nous contacter
</a>
</div>En utilisant ces métadonnées, nous rendons le site plus clair, plus accessible et plus interopérable. La page n’est plus uniquement affichée. Elle est comprise, classée et reliée à d’autres contenus. Pour le vérifier tout passe par Créer un Environnement de Test pour Évaluer l’Accessibilité Web.
Valider son HTML et comprendre les erreurs
Dans la première partie de ce parcours, nous avons insisté sur l’importance d’écrire un epeu de code, d’enregistrer et de tester le résultat dans le navigateur. Et parfois, une page peut sembler fonctionner correctement à l’écran, tout en reposant sur une structure fragile. Le navigateur affiche, corrige et interprète. Il comble les oublis, referme implicitement certaines balises, et permet au document de rester lisible. Cette tolérance est précieuse, mais elle peut aussi masquer des incohérences.
Une balise mal fermée, un élément mal imbriqué ou un attribut incomplet ne bloquent pas toujours l’affichage. Pourtant, ces imprécisions altèrent la structure réelle du document. Elles compliquent l’application des styles, perturbent les scripts et fragilisent l’accessibilité. Le document fonctionne en apparence, mais il perd en fiabilité. Par exemple le code suivant contient certaines erreurs « non bloquantes ».
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>Page de test</title>
</head>
<body>
<!-- Balise <p> non refermée correctement -->
<p>Premier paragraphe
<!-- Balise <strong> mal imbriquée -->
<p>Second paragraphe <strong>avec emphase</p></strong>
<!-- Attribut sans guillemets -->
<img src=https://placehold.co/200x100 alt="Image de test">
<!-- Élément placé au mauvais endroit -->
<ul>
<p>Ce paragraphe ne devrait pas être ici</p>
<li>Élément 1</li>
<li>Élément 2</li>
</ul>
</body>
</html>Valider son HTML consiste à confronter le document à une lecture stricte, indépendante de l’interprétation du navigateur. Des outils comme le validateur du W3C analysent le code et signalent les anomalies. Ces messages ne sont pas des sanctions. Ils sont des repères. Ils nous apprennent à lire autrement, à remonter à l’origine d’une erreur et à comprendre comment la page est réellement construite.
Certains éditeurs facilitent ce travail dès l’écriture du code. Dreamweaver, par exemple, intègre un linter qui analyse le document en temps réel. Les erreurs ou incohérences sont signalées directement dans l’interface, souvent par un soulignement ou un indicateur visuel. Cette assistance immédiate permet de corriger les problèmes au fur et à mesure, sans attendre la phase de validation finale. Le développeur ne découvre plus l’erreur après coup. Il la voit apparaître pendant qu’il écrit, ce qui renforce progressivement sa compréhension de la structure et des règles du langage.
Peu à peu, notre regard évolue. Nous ne nous contentons plus de ce qui s’affiche. Nous prêtons attention à ce qui existe. Cette étape possède une valeur formatrice essentielle, car elle renforce notre compréhension de la structure et consolide les bases du projet.
Un HTML valide n’est pas une exigence abstraite. C’est une fondation solide. Il facilite l’application des styles, la manipulation par JavaScript, l’accessibilité et l’évolution future du site. Il garantit que la page repose sur une structure claire, stable et durable.
Utiliser les outils du navigateur
Le navigateur ne sert plus uniquement à afficher une page. Il devient également un véritable instrument d’observation. Il nous permet de voir ce qui se passe derrière l’interface, et de comprendre comment le document est interprété.
Les outils de développement donnent accès à la structure réelle du HTML. Nous pouvons les ouvrir de deux manières. La plus directe consiste à appuyer sur la touche F12. Une autre approche consiste à effectuer un clic droit sur un élément de la page, puis à choisir Inspecter dans le menu déroulant. Le navigateur affiche alors une nouvelle interface, généralement ancrée en bas ou sur le côté de la fenêtre.
Nous accédons ainsi à une représentation fidèle du document tel qu’il existe réellement. Nous pouvons parcourir les éléments, observer leur organisation et vérifier leur relation. Ce que nous voyons n’est plus seulement le code que nous avons écrit, mais celui que le navigateur a interprété et parfois corrigé. Cette lecture rend visibles certaines incohérences, des balises refermées implicitement, des éléments déplacés ou restructurés.
La console complète cette exploration. Elle affiche les messages liés au chargement de la page. Elle signale des erreurs, des avertissements, des ressources manquantes ou des problèmes de syntaxe. Même dans un simple document HTML, elle peut révéler une image introuvable, un lien incorrect ou un attribut mal formé. Elle devient ainsi un outil de vérification précieux. Elle ne sert pas seulement à corriger, mais à comprendre. Progressivement, elle nous aide à établir un lien direct entre le code que nous écrivons et le document que le navigateur construit.
L’onglet réseau complète cette lecture. Il montre que la page n’est pas un bloc unique, mais un assemblage de ressources, fichiers HTML, feuilles de style, images, scripts. Cette vision transforme notre compréhension. La page cesse d’être un objet unique. Elle devient un ensemble de relations.
Observer ces mécanismes change notre posture. Nous ne supposons plus. Nous vérifions. Nous comprenons comment la page existe réellement.
Conclusion, le HTML, point d’ancrage des interactions
À ce stade du parcours, une idée essentielle se précise. Le HTML ne constitue pas seulement une étape initiale. Il devient le socle commun.
- Le CSS ne crée pas la structure. Il la lit, puis la met en forme. Il s’appuie sur les éléments existants.
- Le JavaScript ne crée pas la page. Il s’attache à elle. Il la parcourt, la modifie et la complète.
- Les métadonnées prolongent cette logique. Elles n’ajoutent rien de visible, mais elles décrivent le document, précisent son contexte, son auteur, sa nature ou son rôle. Elles permettent aux moteurs de recherche, aux navigateurs et aux services externes de mieux interpréter la page.
- Les API du navigateur suivent la même continuité. Elles utilisent les éléments HTML comme points d’entrée pour introduire de nouvelles capacités, manipuler les contenus ou interagir avec l’environnement.
Le HTML devient ainsi le point d’ancrage. Celui qui relie le contenu, la présentation et les interactions. Comprendre cela change profondément notre manière d’apprendre. Le HTML n’est pas une simple introduction. Il constitue une fondation durable. Les chapitres suivants, consacrés au CSS puis au JavaScript, viendront prolonger ce travail et s’appuyer directement sur cette structure.
