La première version d'HTML date du début des années 1990. Dans cette décennie se succèdent les versions 1 à 4 (avec des versions/évolutions mineures pour certaines), la quatrième étant la première pouvant être qualifiée à la fois de moderne et de mature.
Dans sa toute première mouture, apparaît le principe (syntaxe) de base : un contenu texte, augmenté de balises (
tag en anglais) décrivant le contenu, et offrant ainsi des fonctionnalités telles qu'essentiellement les liens "hypertexte" (élément texte cliquable permettant d'accèder à d'autres documents, en quelque sorte "liés"). Le document (texte) HTML brut en lui-même devient moins lisible "humainement" puisque le contenu texte de base se retrouve "entaché" d'informations annexes, mais est censé être lu par un logiciel (le navigateur web, spécialisé dans l'interprétation du HTML) pour être affiché en fonction. De fait, HTML1 ne propose qu'un nombre très réduits de balises, et la mise en forme reste très sommaire, en dehors de cette fonctionnalité hypertexte : la possibilité de formatage basique du texte (gras, italique, souligné...) n'est pas encore présente, pas plus que la possibilité d'inclure des images et encore moins de l'interactivité si ce n'est ces liens hypertexte. En gros, outre les liens (balise "a" ancres, d'
anchor en anglais), sont disponible des balises pour décrire des informations sur l'auteur du document, le titre du document et différents niveaux de titres du contenu, les paragraphes, différents types de liste. On y trouve déjà avec ce peu d'élément le principe d'organisation hiérarchique du contenu en "arbre" : certains éléments peuvent en contenir d'autres, ce qui permet ainsi par exemple de définir une liste comme un élément parent d'éléments de liste, et par voie de conséquence la possibilité d'avoir des sous-listes.
Globalement c'est le même principe qui se retrouve lorsque vous utilisez les possibilités de l'édition avancée de post (la différence avec HTML étant la forme des balises : dans les posts, une balise est définie entre crochets -- parenthèses carrées -- là où les balises HTML sont définies entre crochets points -- symboles inférieur et supérieur à). Le language descriptif (nommé BBCode) est évidemment dérivé d'HTML et a été mis au point pour permettre à des contributeurs de mettre en forme du texte sans utiliser directement HTML pour des raisons à la fois de simplification (avec le temps, vous allez voir que HTML a proposé de plus en plus de balises et de fonctionnalités) et par soucis de ne pas compromettre la sécurité d'un site (le BBCode est interprété en HTML et ainsi l'utilisateur n'a accès qu'à un nombre réduit de fonctionnalités) d'un point de vue essentiellement structure visuelle de l'ensemble de la page où sa contribution sera intégré, mais secondairement et potentiellement d'accès à des failles permettant de compromettre la partie côté serveur (plus rare, plus délicat, mais pas impossible dans l'absolu).
Pour reprendre l'exemple de la liste, pour afficher ceci:
- element 1
- element 2
- element 3
dans un post en BBCode, vous écrirez :
Code : Tout sélectionner
[list][*]element 1[*]element 2[list][*]element 2.a[*]element 2.b[/list][*]element 3[/list]
et pour permettre un peu plus de lisibilité (dans le code brut, pour vous y retrouver : cela ne changera pas le résultat final, tant que les balises sont au même endroit relativement au contenu à formater) vous pourrez introduire des espaces et des sauts de ligne:
Code : Tout sélectionner
[list]
[*]element 1
[*]element 2
[list]
[*]element 2.a
[*]element 2.b
[/list]
[*]element 3
[/list]
Ce qui devrait être "traduit" en HTML par :
Code : Tout sélectionner
<ul>
<li>element 1</li>
<li>element 2
<ul>
<li>element 2.a</li>
<li>element 2.b</li>
</ul>
</li>
<li>element 3</li>
</ul>
"ul" pour "undordered list" (non-ordonnée, dans le sens non-numéroté : avec des puces plutôt que des chiffres, ou des lettres)
"li" pour "list item" (élément de liste)
Chaque paire de "<li>", "</li>" (et plus généralement chaque paire de
tag) définit un élément, grace à une balise ouvrante (sans barre oblique, symbole division, "slash" en anglais) et une balise fermante (avec le
slash), et le contenu texte à afficher entre les deux.
Chaque "li" est contenu dans un élément "ul" dit parent (chaque "li" est enfant d'un "ul"), le deuxième "li" contient en plus une sous-liste (un élément "ul" et ses "li" enfants).
De la même manière que le formatage attendu d'une telle liste est d'avoir les éléments d'autant plus décalés qu'ils font partie d'une sous-liste, il est très commode (et rapidement nécessaire pour ne pas -- trop -- se perdre dans une forêt de
tags) de faire de même en indentant (ajout d'espace en début de ligne) son code de manière logique selon l'ouverture et la fermeture des balises et en hésitant pas à ajouter des sauts de ligne pour clarifier et retrouver plus aisément les différentes parties du contenu.
Les balises peuvent accueillir des paramètres en son sein (avant le crochet fermant la balise d'ouverture de l'élément). Par exemple, un lien en BBCode s'écrit (une des manières, puisque une adresse internet sans BBCode sera automatiquement convertie en lien) :
Ce qui se traduit en HTML par :
En BBCode, il n'y a en principe qu'un seul paramètre, qui suit le nom de la balise après le signe égal (=).
En HTML, il peut y avoir plusieurs paramètres (certains spécifiques à certains
tags, d'autres communs à tous, certains obligatoires, d'autres optionnels) qui sont dit nommés (chaque nom permet de discriminer différents types) et d'une part séparés par un ou des espaces (qui peuvent être un saut de ligne), et d'autre part dont le "contenu" (la valeur) est en principe délimitée par une paire de guillemets droits (simples ou doubles -- ils sont nécessaires dès lors que la valeur doit contenir des espaces, et il est conseillé de ne pas les omettres dans tous les cas ne serait-ce que pour garder de bonnes habitudes : HTML est permissif, mais cela a quelques limites). En ce qui concerne l'exemple du lien (donné à dessein

), le nom du paramètre essentiel est "href", sa valeur doit contenir l'adresse vers laquelle rediriger l'utilisateur (du document à charger) lorsqu'il clique sur le texte contenu dans la balise (entre le
tag ouvrant et le
tag fermant qui par défaut sera affiché souligné et en général en bleu pour caractériser un lien cliquable -- hypertexte -- dans l'exemple, le texte "voir le document").
Pour en revenir à l'évolution d'HTML, au milieu des années 1990 (autour de 1995), arrive la version 2, avec la balise image ("img"), le formatage basique du texte (gras, italique, souligné...) au delà de la simple découpe en paragraphe proposée par HTML1, les premiers éléments de formulaire (liste de choix à sélectionner, champ d'entrée de texte...) pour permettre une certaine interactivité avec le serveur (les informations saisies sont envoyées au serveur, qui peut répondre en renvoyant un document approprié, plutôt que simplement un document dont "l'adresse" a été codée "en dur" dans les paramètres d'un lien), et surtout apparaît la structure générale du document html, composée d'un unique noeud (élément d'un structure en "arbre") racine (la balise "html", qui contient par conséquence tous les noeuds/éléments enfants et/ou sous-enfants composant le document) dans lequel sont attendus deux noeuds enfants de base (relativement -- du fait du caractère permissif du language) obligatoires : les éléments (noeuds/balises) "head" (de l'anglais "tête") et "body" (de l'anglais "corps"). L'élément "head" va accueillir des noeuds enfants décrivant le document (et notament la balise "title" qui contient le titre du document lui-même, et qui sera généralement affiché dans la barre de titre de la fenêtre du navigateur et/ou de l'onglet le cas échéant). L'élément "body" va lui accueillir tous les noeuds qui composent la partie visible du document : c'est le noeud principal du document, le "corps" de celui-ci. Typiquement (la permissivité d'HTML permet de composer rapidement dans l'absolu un contenu en ommettant tout ce qui est "externe" au noeud "body", mais le document ne sera pas valide, même s'il devrait en général être affiché tel qu'attendu -- pas nécessairement cependant dans quelques cas plus ou moins particuliers) le code d'un document HTML valide va se présenter sous cette structure minimale :
Code : Tout sélectionner
<html>
<head>
<title>le titre de ma page web</title>
</head>
<body>
... contenu de la page ...
</body>
</html>
En exemple reprenant les premiers exemples donnés plus haut, ainsi qu'utilisant quelques une des balises déjà évoquées :
► Afficher le texte
Code : Tout sélectionner
<html>
<head>
<title>le titre de ma page web</title>
</head>
<body>
<h1>Le titre principal affiché dans la page</h1>
<h2>Les exemples</h2>
<h3>L'exemple de la liste</h3>
<p>Un premier paragraphe introduisant notre exemple de liste...</p>
<ul>
<li>element 1</li>
<li>element 2
<ul>
<li>element 2.a</li>
<li>element 2.b</li>
</ul>
</li>
<li>element 3</li>
</ul>
<h3>L'exemple du lien</h3>
<p>
Un second paragraphe accueillant notre exemple de lien :
<a href=http://lesiteweb.tld/document">voir le document</a>
</p>
<h2>La conclusion</h2>
<h3>A propos de la balise "p"</h3>
La balise "p" définissant un paragraphe n'est pas nécessaire en
soi pour afficher du texte ;-)<br>
En revanche, introduite dans HTML2, la balise "br" (pour "break
line" en anglais, "casser la ligne" litéralement) est requise pour
imposer un passage à la ligne (en dehors de l'utilisation de balises
spécifiques, ou paramétrées pour ne pas suivre cette règle de
base) car en HTML tous les espaces (espaces, tabulations, etc.
dans le texte brut -- le code HTML -- seront "rassemblés" et les
passages à la ligne ignorés, du moins considérés comme un
simple espace.)<br>
<br>
Néanmoins, la balise "p" introduira un passage à la ligne implicite
à la fin du paragraphe (après la balise fermante) ainsi que par
défaut un peu de marges avant et après (sans devoir requérir à un
tag "br" -- saut de ligne -- supplémentaire comme ici).
<h3>A propos des balises de titre "h1" à "h6"</h3>
Elles définissent une section, ou sous-section. "h1" définit le titre
principal (avant HTML5 elle n'est censée apparaître qu'une fois par
page; à partir d'HTML5 c'est un peu différent, mais nous y reviendrons
plus tard).<br>
Comme la balise "p", elles induisent un passage à la ligne implicite à
leur suite, et par défaut un peu de marges...
</body>
</html>
Ce qui donnerait dans un navigateur quelquechose ressemblant à (où le contenu de la conclusion revient sur les balises utilisées dont je n'ai pas donné d'exemple avant, et qui sera plus lisible qu'avec les balises ^^) :
► Afficher le texte
Le titre principal affiché dans la page
Les exemples
L'exemple de la liste
Un premier paragraphe introduisant notre exemple de liste...
- element 1
- element 2
- element 3
L'exemple du lien
Un second paragraphe accueillant notre exemple de lien : voir le document
La conclusion
A propos de la balise "p"
La balise "p" définissant un paragraphe n'est pas nécessaire en soit pour afficher du texte ;-)
En revanche, introduite dans HTML2, la balise "br" (pour "break line" en anglais, "casser la ligne" litéralement) est requise pour imposer un passage à la ligne (en dehors de l'utilisation de balises spécifiques, ou paramétrées pour ne pas suivre cette règle de base) car en HTML tous les espaces (espaces, tabulations, etc. dans le texte brut -- le code HTML -- seront "rassemblés" et les passages à la ligne ignorés, du moins considérés comme un simple espace.)
Néanmoins, la balise "p" introduira un passage à la ligne implicite à la fin du paragraphe (après la balise fermante) ainsi que par défaut un peu de marges avant et après (sans devoir requérir à un tag "br" -- saut de ligne -- supplémentaire comme ici).
A propos des balises de titre "h1" à "h6"
Elles définissent une section, ou sous-section. "h1" définit le titre principal (avant HTML5 elle n'est censée apparaître qu'une fois par page; à partir d'HTML5 c'est un peu différent, mais nous y reviendrons plus tard).
Comme la balise "p", elles induisent un passage à la ligne implicite à leur suite, et par défaut un peu de marges...
A la fin des années 1990, on passe à HTML3 puis HTML4 : les deux introduisent de nouvelles balises (avec HTML3 le plus notable est l'apparition de la balise "script" apportant le support de Javascript et permettant d'ajouter de l'interactivité côté utilisateur, dont la manipulation des images dans le document afin d'offrir des effets lors du survol de celles-ci par le pointeur de la souris comme le remplacement pour simuler des effets visuels de boutons et/ou valider les données d'un formulaire avant de l'envoyer au serveur, plutôt que de devoir le faire au niveau du serveur), mais la vraie maturation vient donc juste avant d'entrer dans le XXIème siècle (vers 1999 avec HTML4)... Dans le même temps Javascript mature de son côté et peu à peu va pouvoir de plus en plus et de mieux en mieux interagir dynamiquement avec le contenu HTML (bien plus que la simple manipulation d'images ou des données de formulaire -- on parle alors de DHTML, pour Dynamic HTML).
Entre les deux versions, mature d'une part l'idée de mieux séparer contenu et forme (style) avec le projet d'intégrer un language spécifique pour le style et de concentrer dans HTML l'organisation du contenu (cela donnera le language CSS, qui va être peu à peu supporté par les navigateurs et pleinement supporté par HTML4), et d'autre part se forme le W3C, un consortium (W3 pour World Wide Web -- le nom "long" du web -- et C pour Consortium) réunnissant des développeurs web du monde entier pour définir les spécifications de la norme HTML (puis de CSS, qui est intiment lié, bien que préexistant dans d'autre champs d'applications), plutôt que d'être défini par des structures plus réduites (si ce n'est par un ou deux individus).
HTML4 apporte entre autre la possibilité de spécifier la version d'HTML supposée être utilisée pour interpréter le code : le "doctype" est devenu nécessaire au fur et à mesure que des fonctions sont ajoutées et/ou retirées du standard, afin que les navigateurs puissent continuer à correctement interpréter des documents fait avec de plus anciennes versions sans risquer de (trop) casser leur mise en page, mais surtout HTML4 propose différentes variations (sous-versions) dont les "frameset", possibilité de composer des pages en assemblant des cadres contenant différents documents (et éventuellement communiquant entre eux
via Javascript : ainsi, on peut envisager d'avoir une page qui représente un index ou un menu composés de liens, qui ne remplira qu'une partie de la fenêtre d'affichage, et de n'avoir à charger que les sous pages dans une autre partie lorsque l'on clique sur les liens... cela permet par exemple d'alléger un peu la navigation et les données à charger à chaque changement de page, ainsi que de limiter les données qui pourraients se répéter d'une page à une autre (le bandeau de titre peut être une page ne contenant que cela et n'être chargé qu'une fois, ainsi qu'un pied de page, un menu, un index etc.).
Avec HTML4, le format du "doctype" (qui se place sur la première ligne du code HTML, juste avant la balise "html" ouvrante) est imbuvable (long, complexe, impossible à retenir : je vous en fais grâce, mais si vous tenez à vous en convaincre, faites donc une petite recherche internet avec les mots clés "html4 doctypes"), HTML5 va en tenir compte et considérablement le simplifier :
Ouf

! Car HTML5 n'est officiellement sorti qu'en 2016 dans sa première spécification finale... même si les navigateurs l'ont progressivement supporté plus ou moins à partir de 2010 (ce qui fait une bonne douzaine d'années au moins à se farcir les "doctypes" d'HTML4 ^^
Parrallèlement, CSS a évolué de la première spécification CSS1 à CSS3.
Plein de nouvelles possibilités (pour ne pas dire énormément), qui font aussi que tout en se simplifiant sur certains aspects, le développement de pages HTML/CSS c'est considérablement et singulièrement complexifié, mais offre aussi aujourd'hui des possibilités inégalées de développement de ce que l'on nomme maintenant des "applications web", car on est très loin des simples pages statiques avec quelques liens hypertexte et éventuellement quelques images associées des débuts
Je ne vais pas m'étendre plus dans ce post (qui commencent déjà à être bien long

-- la suite étant écrite préalablement) et discuter d'HTML5 : d'un part, on pourra y revenir ponctuellement dans de futurs posts, et d'autres part c'est très largement (et souvent bien mieux que je ne saurais faire) documenté sur internet (même en se limitant aux sujets dans la langue de Molière, bien que celle de Shakespeare soit bien plus prolixe, profonde et complète dans ce domaine ^^)...