HTML5 de ses débuts à maintenant

La liste des propriétés CSS, avec pour chacune, une indication de la version de CSS ou de la version du module de CSS, avec laquelle elle a été introduite. Dans la seconde moitié de la page, une liste des propriétés qui ont été proposées ou été en cours, puis abandonnées, certaines étant encore reconnue préserver la compatibilité (par exemple row-gap s’appelait avant grid-row-gap) : Index of CSS properties (w3.org).

La même chose, pour les descripteurs : Index of CSS descriptors (w3.org).

Pour connaître la signification des abréviations dans la colonne du status, voir la légende à la section “ Color key ”.

Les propriétés sont ce qui est écrit dans les blocs des “ qualified rule ”, ce qui est le plus courant et le plus connus. Par exemple :

“ div.graphique ” est le sélecteur, “ font-size: 120% ” et “ display ” sont deux propriétés (“ inline-block ” et “ 120% ” sont des valeurs de propriété) et l’ensemble forme une règle qualifiée. La première page liste les propriétés, dont “ font-size ” et “ display ” sont deux exemples.

Les descripteurs sont ce qui est écrit dans les blocs des “ at-rules ”, moins fréquentes mais incontournables pour certaines réalisations. Par exemple :


Ne pas confondre sélecteurs et descripteurs, même si les deux mots se ressemblent. “ src ” et “ font-family ” sont deux descripteurs, “ div.graphique ” est un sélecteur. De plus, certains descripteurs peuvent avoir le même nom que certaines propriétés, alors que la signification technique n’est pas la même, cependant que la signification intuitive est très liée. C’est le cas de “ font-family ” par exemple, qui est le nom d’une propriété est aussi le nom d’un descripteur. Au contraire, “ src ” n’est le nom que d’un descripteur, il n’existe pas de propriété de ce nom là. Mais “ src ” est le nom de plusieurs descripteur, un pour le module des couleurs et un pour le module des polices de caractères.

Alors, en plus de ne pas perdre de vue si un nom désigne une propriété ou un descripteur, il faut aussi savoir à quoi exactement le descripteur se rapporte, comme il y a des homonymes entre les descripteurs. De mémoire, je ne crois pas qu’il y ait d’homonymes entre les noms des propriétés, même si un nom de propriété peut être homonyme d’un nom de descripteur. Mais je crois qu’il y a des homonymes entre les valeurs de propriété (ce qui est après “:”) et les propriété (ce qui est avant “:”), mais sans pouvoir donner d’exemple sur l’instant.

N’ai pas trouvé de liste exhaustive des at‑rules, n’en ayant vu que des incomplètes (il faudrait en générer une d’après les spécifications de CSS).

— Édit du 2026-06-07 —

Voir aussi : Re: HTML5 de ses débuts à maintenant, pour des indexes des pseudo‑classes et des pseudo‑éléments.

En rapport : Minimum common web API — ECMA-429 (ecma-international.org), Décembre 2025, première édition.

… et c’est une primeur découverte par hasard par curiosité

Vous connaissez peut‑être les informations de débogage que les compilateurs peuvent laisser dans les fichiers des applications natives. On peut vouloir supprimer ces informations pour alléger ces fichiers est parfois réduire leur taille de moitié, mais la possibilité d’avoir ces informations est utile pour résoudre des bugs ou des consommations de ressources semblant anormales, même si ce n’est pas le seul moyen d’y parvenir.

Il existe quelque chose de similaire pour les fichiers JavaScript, WebAssembly et CSS (le CSS est parfois compilé depuis d’autres langages que CSS lui‑même, cette technique ne se limitant pas au langages effectuant des opérations et produisant des états). C’est sous la forme d’un fichier JSON, à côté des fichiers concernés. Est‑ce que ça peut inclure le HTML qui peut lui aussi être généré, comme c’est même souvent le cas ?

Le standard s’appelle Source map format specification, alias ECMA-426, donc géré par l’ECMA. Le commité technique associé est le TC39.

Il est précisé que le document qui fait référence, c’est celui au format HTML, pas celui au format PDF.

Voir : Source map format specification — ECMA-426 (ecma-international.org), Décembre 2024.

Ce standard peut avoir l’air d’avoir pas plus d’un an, mais c’est en réalité sa version 3 et peut‑être plus en réalité, comme il est dit que le numéro de version a été figé à 3 et qu’il ne changera plus.

Il ne semble pas existé d’abréviation largement reconnue pour Source map format specification, en tous cas pas SMFS, mais il semble facilement désigné par le diminutif Source map.

Ce standard a l’air effectivement en usage.

JavaScript est une marque déposée de Oracle, ECMAScript est une marque déposée enregistrées, de l’ECMA : Re: Les standards de JavaScript (ECMAScript).

Après les variables CSS apparues il y a déjà plusieurs années, voici maintenant les scopes CSS : Isoler finement les styles CSS à l'aide de @scope (alsacreations.com), Raphaël X, 20 Mai 2026.

L’approche que propose le titre, est restrictive, mais l’article est bien. Vouloir trop isoler les éléments, ça peut aller contre l’harmonie d’ensemble, mais même quand on veut que les choses s’associent, on peut avoir des mauvaises surprises avec un style qui s’applique quand on ne le voudrait pas.

Ça ressemble à la fois à une amélioration des sélecteurs traditionnelles et à une fonctionnalité du langage Sass (c’était déjà le cas quand CSS a enfin inclus les variables par lui‑même). Édit : à propos de cette comparaison, un bémol dans l’édit qui suit.

— Édit du 2026-06-03 —

Même sans utiliser @scope, les règles imbriquées peuvent maintenant être écrites directement en CSS.


Modern CSS is fun (chameth.com), 17 Mars 2026. Il y présente aussi d’autres nouveautés utiles récentes.

Les règles imbriquées ont l’imbrication en commun avec @scope, mais ne limitent pas leur porté comme @scope peut le faire. Il est possible que ce qui soit recherché, soit souvent des règles imbriquées plutôt que toujours @scope. C’était aussi une caractéristique du langage Sass, qui est maintenant disponible directement en CSS, et c’était tellement évident qu’on pourra dire que ça s’est fait attendre. Avec les règles imbriquées, il y a un “ & ” qui a un rôle similaire au “ :scope ” dans @scope, mais là aussi, c’est différent, similaire mais différent, alors à ne pas confondre.

“ & ” est pour le sélecteur parent, alors ce qu’il désigne dépend de où il se trouve dans les imbrications, tandis que “:scope” désigne toujours un élément (il peut y avoir plusieurs tels éléments dans un document) pris pour contexte dans l’arbre des éléments. Pour les distinguer, @scope est plutôt à propos de l’imbrication des éléments et les règles imbriqués, sont plutôt à propos de l’imbrication des règles. Comme les deux sont liés, il y a inévitablement des similitudes entre les deux, mais comme ils sont liés sans être pareil, il y a aussi des différences.

En fait, ce sont plutôt les règles imbriquées, qui ressemblent à Sass, pas @scope, que Sass ne pouvait pas faire, puisque ça nécessite un support du navigateur. Excepté si @scope est utilisé sans sélecteur limite, parce que dans ce cas, il ressemble plus facilement aux règles imbriquées.

Il semble que “ & ” peut aussi être utilisé dans @scope, mais à vérifier et il faudrait savoir s’il y a des interprétations uniques à ce contexte.

Quelque chose qui semble ambivalent avec HTML5. Certains éléments et attributs des anciennes versions de HTML, sont considérés comme obsolètes. Parmi les choses considérées comme obsolète, il y en a qui sont quand‑même considérées comme acceptables (conformes), et d’autres qui sont entièrement à ne pas utiliser. Pourtant, le même document défini les interfaces que les navigateurs doivent leur donner et les attributs de ces éléments que les navigateurs doivent leur reconnaître et comment les interpréter. Ce n’est pas très clair.

Voir : 16 Obsolete features (whatwg.org).

Par exemple, l’élément FONT, qui existait dans les premières versions de HTML, est considérés comme obsolète et ne devant plus du tout être utilisé, dans la section 16.2. Pourtant l’interface que cette élément doit avoir, est défini, dans la section, 16.3.

Normalement, l’explication est dans cette phrase au début de la section 16.3 :

Il faut sûrement comprendre, interdit pour les auteurs de sites actuels, mais devant être supportés pour les navigateurs, pour les anciens sites dont plus personne ne s’occupe mais qui sont toujours accessibles.

Je crois me souvenir d’un paragraphe dans HTML5, qui disait que les exigences et recommendations, ne sont pas les mêmes pour les auteurs et pour les navigateurs.

C’est dommage que l’élément FONT ne soit plus supporté, parce qu’il aurait put être utile pour mettre des petits textes ou des mots dans certaines couleurs, sans passer par des styles CSS, pour les cas où ce n’est pas du style, mais une donnée ou une indication d’interprétation. Par exemple dans la légende d’un graphique, les couleurs ne sont pas des styles, ce sont des données ou des traits sémantiques. On pourrait se dire que dans ce cas, la même remarque pourrait se faire avec les éléments gras et italique, mais il ne sont pas considérés comme obsolètes, même s’ils ont une description sémantique, pas stylistique, qui n’est que indicative, alors la comparaison ne peut pas être faite. Avec Unicode, des variantes typographiques, selon l’épaisseur du trait et l’obliquité, ont été retenus comme des caractères distincts des caractères de base dont ils sont dérivés, tout en étant considérés comme identiques pour certaines formes normalisés, qui peuvent être canoniques ou pas. Là aussi, ce n’est pas de la couleur, mais c’est le même principe, surtout que c’est décrit comme une variation de police de caractère. Ce n’est pas considéré comme du style, mais comme de la sémantique, même si elle notée comme éventuellement ambiguë.

Peut‑être que la meilleure solution dans ces conditions, serait d’utiliser des classes, une pour chacune des couleurs qu’on veut pouvoir afficher. Le CSS ne serait plus modifié, seulement des attributs class le seraient. Mais ça ne peut pas marcher si la liste de toutes les couleurs possibles, n’est pas connue exhaustivement à priori, alors pour ça, l’élément FONT avec son attribut color, aurait convenu sans poser de problème. Ça ne marche plus aussi, si on supprime le CSS et justement, enlever le CSS, c’est le meilleur test pour vérifier qu’une page est bien conçue sémantiquement. D’ailleurs, une classe CSS est difficilement interprétable automatiquement, même avec un nom parlant.

Une seconde solution alors, plus aventureuse mais justifiée, serait de tricher, en utilisant cet élément malgré son interdiction, sachant qu’il doit de toutes manières, être reconnu et interprété correctement par les navigateurs.

Des indexes des pseudos‑classes et des pseudo‑éléments. Ça peut sauver quand quelque chose semble impossible à styler sur une page. Il ne faut quand‑même pas en abuser, à utiliser seulement quand c’est nécessaire et laisser les styles par défaut quand ils ne posent pas de problème.

C’est sur le site MDN. Je ne sais pas s’il existe ce genre de liste dans les sites de référence.

Introduction aux deux :
Pseudo classes and elements (mozilla.org).

Dans la section référence des sélecteurs :
Pseudo-classes (mozilla.org).
Pseudo-elements (mozilla.org).

Dans la section guide :
Pseudo-elements (mozilla.org)
Il n’y a pas de page dans cette section, pour les pseudo‑classes.

Sur la pseudo classe “:target” en particulier, sans savoir pourquoi elle est distinguée :
Using :target (mozilla.org).

Un exemple de cas où ça peut sauver, c’est pour donner un style au bouton de sélecteur de fichier dans un formulaire. Ça a souvent été commenté comme impossible à faire, mais c’est facile en utilisant le pseudo‑élément ::file-selector-button.

D’autres solutions ont été proposées avant que celle‑ci n’existe, mais elles étaient tellement compliquées qu’il valait mieux les éviter et laisser les styles par défaut. Un exemple, dont le lien est volontairement désactivé : --https://www.quirksmode.org/dom/inputfile.html . Ce lien est connu, souvent proposé comme solution, mais il est obsolète depuis longtemps déjà.

On peut éviter en partie le problème des solutions obsolètes, en évitant les solutions qui sont des bricolages abusifs, ce qui était le cas de celle‑ci. Quand une solution est tellement pénible, c’est qu’il y a un trop important problème quelque part et alors mieux faut faire avec pour ne rien aggraver et attendre qu’un jour une autre solution plus normale soit possible.

Voir aussi : Re: HTML5 de ses débuts à maintenant pour des indexes des descripteurs et des propriétés.

HTML5 n’est normalement plus défini par une DTD SGML, comme l’était les précédentes versions jusqu’à HTML4. Des gens ont quand‑même essayé de faire leur possible pour poser les règles de HTML5 sous forme d’une DTD : SGML HTML200129 DTD Reference (sgml.net), de date inconnue. Ou cette autre version : SGML HTML5 DTD Reference (sgml.net). Pour le second lien, l’URL dit HTML5.1. Je ne sais pas si HTML5.1 date d’avant ou d’après la version du premier lien. Le fait qu’un numéro de version mineur soit donné, indique c’est pour un HTML5 datant de l’époque où il était encore maintenu par le W3C. Il y a aussi une version pour HTML5.2 (même remarque) : SGML HTML5.2 DTD Reference (). … Et peut–être d’autres versions encore.

Au premier lien, il est dit qu’il n’est pas possible de reformuler toutes les règles dans une DTD. Mais une chose me semble étrange. Il est que dit que par exemple, les valeurs par défaut des attributs ne peuvent pas être définis. Pourtant je me souviens qu’avec une DTD, on pouvait définir des valeurs par défaut des attributs. Ou alors des détails qui rendrait cette limitation compréhensible, ne sont pas expliqués.

La DTD au premier lien, correspond à HTML5 tel qu’au 28 Janvier 2021, alors que HTML5 change tellement tout le temps qu’il n’a pa de numéro de version.

Ça ne peut apparemment pas être utilisé pour traiter les documents HTML5 comme s’ils étaient du SGML (HTML5 y ressemble quand‑même encore beaucoup par la forme, la syntaxe), mais ça peut être intéressant pour diverses raisons.

À l’origine, les documents HTML étaient (imparfaitement) des documents SGML. Ce dernier était le langage sémantique standard pour le texte, dans les années 1980 à 1990 environ. Puis HTML, plus populaire bien que très peu générique, a pris sa place, puis XML, plus générique, s’y est joint en parallèle peu après. Ces deux là étaient initialement considérées comme des applications de SGML. Par la suite, comme XML était sensé se substituer à SGML, il n’y faisait plus référence, et comme HTML5 n’a plus été défini comme du SGML, SGML a de plus en plus disparu, excepté dans certaines administrations qui en dépendaient beaucoup. Aussi, HTML a souvent été utilisé plus comme un langage de présentation que sémantique. C’est encore plus évident avec HTML5, qui peut servir à définir des interfaces utilisateur pour des applications, ce qui est sans rapport avec SGML, qui servait à écrire des documents.