From e26d24940b2234a1a5e63b19d19d298bf36354e2 Mon Sep 17 00:00:00 2001 From: julieng Date: Sun, 14 Nov 2021 14:30:32 +0100 Subject: move *.html to *.md --- .../introduction_to_html/debugging_html/index.html | 194 --------------------- .../introduction_to_html/debugging_html/index.md | 194 +++++++++++++++++++++ 2 files changed, 194 insertions(+), 194 deletions(-) delete mode 100644 files/fr/learn/html/introduction_to_html/debugging_html/index.html create mode 100644 files/fr/learn/html/introduction_to_html/debugging_html/index.md (limited to 'files/fr/learn/html/introduction_to_html/debugging_html') diff --git a/files/fr/learn/html/introduction_to_html/debugging_html/index.html b/files/fr/learn/html/introduction_to_html/debugging_html/index.html deleted file mode 100644 index ed0cfa6a2b..0000000000 --- a/files/fr/learn/html/introduction_to_html/debugging_html/index.html +++ /dev/null @@ -1,194 +0,0 @@ ---- -title: Déboguer de l'HTML -slug: Learn/HTML/Introduction_to_HTML/Debugging_HTML -tags: - - Codage - - Débutant - - Erreur - - Guide - - HTML - - Validation - - débogage - - validateur -translation_of: Learn/HTML/Introduction_to_HTML/Debugging_HTML -original_slug: Apprendre/HTML/Introduction_à_HTML/Debugging_HTML ---- -
{{LearnSidebar}}
- -
{{PreviousMenuNext("Apprendre/HTML/Introduction_à_HTML/Document_and_website_structure", "Apprendre/HTML/Introduction_à_HTML/Marking_up_a_letter", "Apprendre/HTML/Introduction_à_HTML")}}
- -

Écrire du code HTML, c'est bien, mais si quelque chose se passe mal, que faire pour trouver où est l'erreur dans le code ? Cet article vous indique divers outils pour vous aider à trouver et corriger les erreurs en HTML.

- - - - - - - - - - - - -
Prérequis :Être familiarisé avec les bases du HTML, traitées aux pages Commencer avec le HTML, Fondamentaux du texte HTML et Création d'hyperliens.
Objectif :Apprendre les bases de l'utilisation des outils de débogage pour détecter des problèmes en HTML.
- -

Déboguer n'est pas un problème

- -

Quand on écrit du code , tout va généralement bien, jusqu'au moment redouté où une erreur se produit — vous avez fait quelque chose d'incorrect, donc votre code ne fonctionne pas — soit pas du tout, soit pas tout à fait comme vous l'aviez souhaité. Par exemple, ce qui suit montre une erreur signalée lors d'une tentative de {{glossary("compile","compilation")}} d'un programme simple écrit en Rust.

- -

Console montrant le résultat de la compilation d'un programme Rust avec guillemet manquant dans une chaîne textuelle dans une instruction d'affichage. Le message signalé est « erreur : guillemet double manquant dans la chaîne ».Ici, le message d'erreur est relativement facile à comprendre — « unterminated double quote string » : il manque un guillemet double ouvrant ou fermant pour envelopper la chaîne. Si vous regardez le listage, vous verrez println!(Salut, Ô Monde!"); il manque un guillemet double. Cependant, des messages d'erreur peuvent devenir plus complexes et plus abscons au fur et à mesure que le programme grossit et, même dans des cas simples devenir intimidants à quelqu'un qui ne connaît rien du Rust.

- -

Déboguer ne doit toutefois pas devenir un problème — la clé pour être à l'aise lors de l'écriture et du débogage d'un programme réside dans une bonne connaissance à la fois du langage et des outils.

- -

HTML et le débogage

- - - -

HTML n'est pas aussi compliqué à comprendre que le Rust. HTML n'est pas compilé sous une forme différente avant que le navigateur n'ait fait son analyse et affiche le résultat (il est interprété, pas compilé). Et la syntaxe des {{glossary("element","éléments")}} HTML est sans doute beaucoup plus facile à comprendre qu'un « vrai langage de programmation » tel le Rust, le {{glossary("JavaScript")}} ou le {{glossary("Python")}}. La façon dont les navigateurs analysent le HTML est beaucoup plus permissive que celle des langages de programmation, ce qui est à la fois une bonne et une mauvaise chose.

- -

Code permissif

- -

Que voulons‑nous dire par permissif ? Et bien, quand vous faites une erreur dans du code, vous rencontrerez deux types principaux d'erreurs :

- - - - - -

HTML ne craint pas les erreurs de syntaxe, car les navigateurs l'analysent de manière permissive : la page s'affiche toujours même s'il y a des erreurs de syntaxe. Les navigateurs intègrent des règles indiquant comment interpréter un balisage incorrectement écrit, de sorte que vous obtiendrez toujours quelque chose à l'exécution, même si ce n'est pas ce que vous attendiez. Mais cela reste, bien sûr, toujours un problème !

- -
-

Note : HTML est analysé de façon permissive parce que, lorsque le Web a été créé pour la première fois, on a décidé qu'il était plus important de permettre aux gens de publier leur contenu que de s'assurer d'une syntaxe absolument correcte. Le web ne serait probablement pas aussi populaire qu'il l'est aujourd'hui, s'il avait été plus strict dans ses débuts.

-
- -

Apprentissage actif : étude avec un code permissif

- -

Voici le moment venu d'étudier le caractère permissif du code HTML.

- -
    -
  1. Primo, télécharchez notre démo debug-example et enregistrez‑le localement. Cette démo est délibérement écrite avec des erreurs pour que nous puissions les examiner (le balisage HTML est dit malformé, par opposition à bien-formé).
    2. -
  2. Ensuite, ouvrez‑le dans un navigateur. Vous verrez quelque chose comme ceci :Un simple document HTML intitulé « Exemples de HTML à déboguer » et quelques informations sur les erreurs HTML courantes, telles que les éléments non fermés ou mal imbriqués et des attributs non fermés.
    3. -
  3. Constatons que ce n'est pas terrible ; examinons le code source pour voir ce que nous pouvons en faire (seul le contenu de l'élément body est affiché) : - 
        <h1>Exemple de HTML à déboguer</h1>
-
-    <p>Quelles sont les causes d'erreur en HTML ?
-
-    <ul>
-      <li>Éléments non fermés : si un élément n'est <strong>pas
-          fermé proprement, ses effets peuvent déborder sur des
-          zones que vous ne souhaitiez pas.
-
-      <li>Éléments incorrectement imbriqués : imbriquer des
-          éléments proprement est également très important pour
-          que le code se comporte correctement.
-          <strong>caractères gras <em>ou gras et italiques ?</strong>
-          qu'est‑ce ?</em>
-
-      <li>Attributs non fermés : autre source courante de problèmes
-          en HTML. Voici un exemple: <a href="https://www.mozilla.org/>
-          lien à la page d'accueil de Mozilla</a>
-    </ul>
    -
    4. -
  4. Revoyons les problèmes : -
      -
    • Les élements {{htmlelement("p")}} (paragraphe) et {{htmlelement("li")}} (élément de liste) n'ont pas de balise de fermeture. En voyant l'image ci‑dessus, cela ne semble pas avoir trop sévèrement affecté le rendu, car on voit bien où un élément se termine et où le suivant commence.
      • -
    • Le premier élément {{htmlelement("strong")}} n'a pas de balise de fermeture. C'est un peu plus problématique, car il n'est pas possible de dire où l'élément est supposé se terminer. En fait, tout le reste du texte est en gras.
      • -
    • Cette partie est mal imbriquée : <strong>caractères gras <em>ou gras et italiques ?</strong> qu'est ce ?</em>. Pas facile de dire comment il faut interpréter cela en raison du problème précédent.
      • -
    • La valeur de l'attribut {{htmlattrxref("href","a")}} n'a pas de guillemet double fermant. C'est ce qui semble avoir posé le plus gros problème — le lien n'a pas été mentionné du tout.
      • -
    -
    5. -
  5. Revoyons maintenant comment le navigateur a vu le balisage, par comparaison au balisage du code source. Pour ce faire, utilisons les outils de développement du navigateur. Si vous n'êtes pas un familier de l'utilisation des outils de développement du navigateur, prenez quelques minutes pour revoir Découverte des outils de développement du navigateur.
    6. -
  6. Dans l'« Inspecteur », vous pouvez voir ce à quoi le balisage du rendu ressemble : L'inspecteur HTML dans Firefox, avec le paragraphe de l'exemple en surbrillance, montrant le texte "Quelles sont les causes d'erreurs en HTML ? Ici, vous pouvez voir que l'élément de paragraphe a été fermé par le navigateur.
    7. -
  7. Avec l'« Inspecteur », explorons le code en détail pour voir comment le navigateur a essayé de corriger nos erreurs HTML (nous avons fait la revue dans Firefox ; d'autres navigateurs modernes devraient donner le même résultat) : -
      -
    • Les éléments p et li ont été pourvus de balises fermantes.
      • -
    • L'endroit où le premier élément <strong> doit être fermé n'est pas clair, donc le navigateur a enveloppé séparément chaque bloc de texte avec ses propres balises strong, jusqu'à la fin du document !
      • -
    • L'imbrication incorrecte a été corrigée ainsi : - 
      <strong>caractères gras
-  <em>ou caractères gras et italiques ?</em>
-</strong>
-<em> qu'est ce ?</em>
      -
      • -
    • Le lien avec les guillemets manquants a été illico détruit. Le dernier élément li ressemble à ceci : - 
      <li>
-  <strong>Attributs non fermés : autre source courante de problèmes
-en HTML. Voici un exemple :</strong>
-</li>
      -
      • -
    -
    8. -
- -

Validation d'un HTML

- -

Comme vous pouvez le voir dans l'exemple ci-dessus, il faut s'assurer que votre HTML est bien formé ! Mais comment ? Dans un petit fichier comme celui qui précède, il est facile de chercher dans les lignes et de trouver les erreurs, mais qu'en est-il d'un document HTML énorme et complexe ?

- -

La meilleure stratégie consiste à faire passer votre page HTML par le Markup Validation Service (Service de validation de balisage) — créé et maintenu par le W3C, l'organisation s'occupant des normes définissant le HTML, les CSS et autres technologies web. Cet outil Web accepte un document HTML en entrée, le parcourt et fait le rapport de ce qui ne va pas dans le HTML soumis.

- -

La page d'accueil du validateur HTML

- -

Pour définir le HTML à valider, vous pouvez donner une adresse web (Validate by URI) , téléverser un fichier HTML (Validate by File Upload) ou entrer directement du code HTML (Validate by Direct Input).

- -

Apprentissage actif : validation d'un document HTML

- -

Essayons cet outil avec notre document exemple.

- -
    -
  1. D'abord, chargez le Markup Validation Service dans un des onglets du navigateur, si ce n'est déjà fait.
    2. -
  2. Basculez sur l'onglet Validate by Direct Input.
    3. -
  3. Copiez la totalité du code du document (pas uniquement l'élément body) et collez-le dans la grande zone de texte affichée dans Markup Validation Service.
    4. -
  4. Pressez le bouton Check.
    5. -
- -

Cela vous donnera une liste d'erreurs et autres informations.

- -

La liste des résultats de la validation de HTML par le service de validation du W3C.

- -

Interprétation des messages d'erreur

- -

Les messages d'erreur sont généralement utiles, mais parfois non ; avec un peu de pratique, vous trouverez comment les interpréter pour corriger votre code. Passons en revue les messages d'erreur et voyons leur signification. Chaque message est accompagné d'un numéro de ligne et de colonne pour faciliter la localisation de l'erreur.

- - - -

Si vous ne comprenez pas ce que signifie chaque message d'erreur, ne vous inquiétez pas — une bonne idée consiste à corriger quelques erreurs à la fois. Puis essayez de revalider le HTML pour voir les erreurs restantes. Parfois, la correction d'une erreur en amont permet aussi d'éliminer d'autres messages d'erreur — plusieurs erreurs sont souvent causées par un même problème, avec une sorte d'effet domino.

- -

Vous saurez que toutes vos erreurs sont corrigées quand vous verrez la bannière suivante dans la sortie :

- -

Banner that reads "The document validates according to the specified schema(s) and to additional constraints checked by the validator."

- -

Résumé

- -

Voilà donc une introduction au débogage HTML, qui devrait vous donner des compétences utiles sur lesquelles compter lorsque vous commencerez à déboguer des CSS, du JavaScript ou d'autres types de code plus tard dans votre carrière. Ceci marque également la fin des articles d'apprentissage du module Introduction au HTML — maintenant vous pouvez faire un auto‑test avec nos évaluations : le lien ci‑dessous vous dirige sur la première.

- -

{{PreviousMenuNext("Apprendre/HTML/Introduction_à_HTML/Document_and_website_structure", "Apprendre/HTML/Introduction_à_HTML/Marking_up_a_letter", "Apprendre/HTML/Introduction_à_HTML")}}

- - - -

Dans ce module

- - diff --git a/files/fr/learn/html/introduction_to_html/debugging_html/index.md b/files/fr/learn/html/introduction_to_html/debugging_html/index.md new file mode 100644 index 0000000000..ed0cfa6a2b --- /dev/null +++ b/files/fr/learn/html/introduction_to_html/debugging_html/index.md @@ -0,0 +1,194 @@ +--- +title: Déboguer de l'HTML +slug: Learn/HTML/Introduction_to_HTML/Debugging_HTML +tags: + - Codage + - Débutant + - Erreur + - Guide + - HTML + - Validation + - débogage + - validateur +translation_of: Learn/HTML/Introduction_to_HTML/Debugging_HTML +original_slug: Apprendre/HTML/Introduction_à_HTML/Debugging_HTML +--- +
{{LearnSidebar}}
+ +
{{PreviousMenuNext("Apprendre/HTML/Introduction_à_HTML/Document_and_website_structure", "Apprendre/HTML/Introduction_à_HTML/Marking_up_a_letter", "Apprendre/HTML/Introduction_à_HTML")}}
+ +

Écrire du code HTML, c'est bien, mais si quelque chose se passe mal, que faire pour trouver où est l'erreur dans le code ? Cet article vous indique divers outils pour vous aider à trouver et corriger les erreurs en HTML.

+ + + + + + + + + + + + +
Prérequis :Être familiarisé avec les bases du HTML, traitées aux pages Commencer avec le HTML, Fondamentaux du texte HTML et Création d'hyperliens.
Objectif :Apprendre les bases de l'utilisation des outils de débogage pour détecter des problèmes en HTML.
+ +

Déboguer n'est pas un problème

+ +

Quand on écrit du code , tout va généralement bien, jusqu'au moment redouté où une erreur se produit — vous avez fait quelque chose d'incorrect, donc votre code ne fonctionne pas — soit pas du tout, soit pas tout à fait comme vous l'aviez souhaité. Par exemple, ce qui suit montre une erreur signalée lors d'une tentative de {{glossary("compile","compilation")}} d'un programme simple écrit en Rust.

+ +

Console montrant le résultat de la compilation d'un programme Rust avec guillemet manquant dans une chaîne textuelle dans une instruction d'affichage. Le message signalé est « erreur : guillemet double manquant dans la chaîne ».Ici, le message d'erreur est relativement facile à comprendre — « unterminated double quote string » : il manque un guillemet double ouvrant ou fermant pour envelopper la chaîne. Si vous regardez le listage, vous verrez println!(Salut, Ô Monde!"); il manque un guillemet double. Cependant, des messages d'erreur peuvent devenir plus complexes et plus abscons au fur et à mesure que le programme grossit et, même dans des cas simples devenir intimidants à quelqu'un qui ne connaît rien du Rust.

+ +

Déboguer ne doit toutefois pas devenir un problème — la clé pour être à l'aise lors de l'écriture et du débogage d'un programme réside dans une bonne connaissance à la fois du langage et des outils.

+ +

HTML et le débogage

+ + + +

HTML n'est pas aussi compliqué à comprendre que le Rust. HTML n'est pas compilé sous une forme différente avant que le navigateur n'ait fait son analyse et affiche le résultat (il est interprété, pas compilé). Et la syntaxe des {{glossary("element","éléments")}} HTML est sans doute beaucoup plus facile à comprendre qu'un « vrai langage de programmation » tel le Rust, le {{glossary("JavaScript")}} ou le {{glossary("Python")}}. La façon dont les navigateurs analysent le HTML est beaucoup plus permissive que celle des langages de programmation, ce qui est à la fois une bonne et une mauvaise chose.

+ +

Code permissif

+ +

Que voulons‑nous dire par permissif ? Et bien, quand vous faites une erreur dans du code, vous rencontrerez deux types principaux d'erreurs :

+ + + + + +

HTML ne craint pas les erreurs de syntaxe, car les navigateurs l'analysent de manière permissive : la page s'affiche toujours même s'il y a des erreurs de syntaxe. Les navigateurs intègrent des règles indiquant comment interpréter un balisage incorrectement écrit, de sorte que vous obtiendrez toujours quelque chose à l'exécution, même si ce n'est pas ce que vous attendiez. Mais cela reste, bien sûr, toujours un problème !

+ +
+

Note : HTML est analysé de façon permissive parce que, lorsque le Web a été créé pour la première fois, on a décidé qu'il était plus important de permettre aux gens de publier leur contenu que de s'assurer d'une syntaxe absolument correcte. Le web ne serait probablement pas aussi populaire qu'il l'est aujourd'hui, s'il avait été plus strict dans ses débuts.

+
+ +

Apprentissage actif : étude avec un code permissif

+ +

Voici le moment venu d'étudier le caractère permissif du code HTML.

+ +
    +
  1. Primo, télécharchez notre démo debug-example et enregistrez‑le localement. Cette démo est délibérement écrite avec des erreurs pour que nous puissions les examiner (le balisage HTML est dit malformé, par opposition à bien-formé).
    2. +
  2. Ensuite, ouvrez‑le dans un navigateur. Vous verrez quelque chose comme ceci :Un simple document HTML intitulé « Exemples de HTML à déboguer » et quelques informations sur les erreurs HTML courantes, telles que les éléments non fermés ou mal imbriqués et des attributs non fermés.
    3. +
  3. Constatons que ce n'est pas terrible ; examinons le code source pour voir ce que nous pouvons en faire (seul le contenu de l'élément body est affiché) : + 
        <h1>Exemple de HTML à déboguer</h1>
+
+    <p>Quelles sont les causes d'erreur en HTML ?
+
+    <ul>
+      <li>Éléments non fermés : si un élément n'est <strong>pas
+          fermé proprement, ses effets peuvent déborder sur des
+          zones que vous ne souhaitiez pas.
+
+      <li>Éléments incorrectement imbriqués : imbriquer des
+          éléments proprement est également très important pour
+          que le code se comporte correctement.
+          <strong>caractères gras <em>ou gras et italiques ?</strong>
+          qu'est‑ce ?</em>
+
+      <li>Attributs non fermés : autre source courante de problèmes
+          en HTML. Voici un exemple: <a href="https://www.mozilla.org/>
+          lien à la page d'accueil de Mozilla</a>
+    </ul>
    +
    4. +
  4. Revoyons les problèmes : +
      +
    • Les élements {{htmlelement("p")}} (paragraphe) et {{htmlelement("li")}} (élément de liste) n'ont pas de balise de fermeture. En voyant l'image ci‑dessus, cela ne semble pas avoir trop sévèrement affecté le rendu, car on voit bien où un élément se termine et où le suivant commence.
      • +
    • Le premier élément {{htmlelement("strong")}} n'a pas de balise de fermeture. C'est un peu plus problématique, car il n'est pas possible de dire où l'élément est supposé se terminer. En fait, tout le reste du texte est en gras.
      • +
    • Cette partie est mal imbriquée : <strong>caractères gras <em>ou gras et italiques ?</strong> qu'est ce ?</em>. Pas facile de dire comment il faut interpréter cela en raison du problème précédent.
      • +
    • La valeur de l'attribut {{htmlattrxref("href","a")}} n'a pas de guillemet double fermant. C'est ce qui semble avoir posé le plus gros problème — le lien n'a pas été mentionné du tout.
      • +
    +
    5. +
  5. Revoyons maintenant comment le navigateur a vu le balisage, par comparaison au balisage du code source. Pour ce faire, utilisons les outils de développement du navigateur. Si vous n'êtes pas un familier de l'utilisation des outils de développement du navigateur, prenez quelques minutes pour revoir Découverte des outils de développement du navigateur.
    6. +
  6. Dans l'« Inspecteur », vous pouvez voir ce à quoi le balisage du rendu ressemble : L'inspecteur HTML dans Firefox, avec le paragraphe de l'exemple en surbrillance, montrant le texte "Quelles sont les causes d'erreurs en HTML ? Ici, vous pouvez voir que l'élément de paragraphe a été fermé par le navigateur.
    7. +
  7. Avec l'« Inspecteur », explorons le code en détail pour voir comment le navigateur a essayé de corriger nos erreurs HTML (nous avons fait la revue dans Firefox ; d'autres navigateurs modernes devraient donner le même résultat) : +
      +
    • Les éléments p et li ont été pourvus de balises fermantes.
      • +
    • L'endroit où le premier élément <strong> doit être fermé n'est pas clair, donc le navigateur a enveloppé séparément chaque bloc de texte avec ses propres balises strong, jusqu'à la fin du document !
      • +
    • L'imbrication incorrecte a été corrigée ainsi : + 
      <strong>caractères gras
+  <em>ou caractères gras et italiques ?</em>
+</strong>
+<em> qu'est ce ?</em>
      +
      • +
    • Le lien avec les guillemets manquants a été illico détruit. Le dernier élément li ressemble à ceci : + 
      <li>
+  <strong>Attributs non fermés : autre source courante de problèmes
+en HTML. Voici un exemple :</strong>
+</li>
      +
      • +
    +
    8. +
+ +

Validation d'un HTML

+ +

Comme vous pouvez le voir dans l'exemple ci-dessus, il faut s'assurer que votre HTML est bien formé ! Mais comment ? Dans un petit fichier comme celui qui précède, il est facile de chercher dans les lignes et de trouver les erreurs, mais qu'en est-il d'un document HTML énorme et complexe ?

+ +

La meilleure stratégie consiste à faire passer votre page HTML par le Markup Validation Service (Service de validation de balisage) — créé et maintenu par le W3C, l'organisation s'occupant des normes définissant le HTML, les CSS et autres technologies web. Cet outil Web accepte un document HTML en entrée, le parcourt et fait le rapport de ce qui ne va pas dans le HTML soumis.

+ +

La page d'accueil du validateur HTML

+ +

Pour définir le HTML à valider, vous pouvez donner une adresse web (Validate by URI) , téléverser un fichier HTML (Validate by File Upload) ou entrer directement du code HTML (Validate by Direct Input).

+ +

Apprentissage actif : validation d'un document HTML

+ +

Essayons cet outil avec notre document exemple.

+ +
    +
  1. D'abord, chargez le Markup Validation Service dans un des onglets du navigateur, si ce n'est déjà fait.
    2. +
  2. Basculez sur l'onglet Validate by Direct Input.
    3. +
  3. Copiez la totalité du code du document (pas uniquement l'élément body) et collez-le dans la grande zone de texte affichée dans Markup Validation Service.
    4. +
  4. Pressez le bouton Check.
    5. +
+ +

Cela vous donnera une liste d'erreurs et autres informations.

+ +

La liste des résultats de la validation de HTML par le service de validation du W3C.

+ +

Interprétation des messages d'erreur

+ +

Les messages d'erreur sont généralement utiles, mais parfois non ; avec un peu de pratique, vous trouverez comment les interpréter pour corriger votre code. Passons en revue les messages d'erreur et voyons leur signification. Chaque message est accompagné d'un numéro de ligne et de colonne pour faciliter la localisation de l'erreur.

+ + + +

Si vous ne comprenez pas ce que signifie chaque message d'erreur, ne vous inquiétez pas — une bonne idée consiste à corriger quelques erreurs à la fois. Puis essayez de revalider le HTML pour voir les erreurs restantes. Parfois, la correction d'une erreur en amont permet aussi d'éliminer d'autres messages d'erreur — plusieurs erreurs sont souvent causées par un même problème, avec une sorte d'effet domino.

+ +

Vous saurez que toutes vos erreurs sont corrigées quand vous verrez la bannière suivante dans la sortie :

+ +

Banner that reads "The document validates according to the specified schema(s) and to additional constraints checked by the validator."

+ +

Résumé

+ +

Voilà donc une introduction au débogage HTML, qui devrait vous donner des compétences utiles sur lesquelles compter lorsque vous commencerez à déboguer des CSS, du JavaScript ou d'autres types de code plus tard dans votre carrière. Ceci marque également la fin des articles d'apprentissage du module Introduction au HTML — maintenant vous pouvez faire un auto‑test avec nos évaluations : le lien ci‑dessous vous dirige sur la première.

+ +

{{PreviousMenuNext("Apprendre/HTML/Introduction_à_HTML/Document_and_website_structure", "Apprendre/HTML/Introduction_à_HTML/Marking_up_a_letter", "Apprendre/HTML/Introduction_à_HTML")}}

+ + + +

Dans ce module

+ + -- cgit v1.2.3-54-g00ecf