HTML5 : la finalisation annoncée « prochainement »

En fait, si, le WHATWG me semble faire beaucoup de récriminations envers le W3C. Édit du 2025-12-09 : en plus le WHATWG a la mauvaise manie de faire des révisions sans les présenter comme telle, ni de présenter les différence entre les nouvelles et les anciennes révisions. Mais avec le temps, ça semble s’être stabilisé quand‑même.

Si vous êtes perdu(e)s dans le fouillis des modules et « niveaux » de CSS, voir cette page : CSS Snapshot (w3.org).

En plus du précédent lien, voir aussi : All CSS specifications (w3.org).

Pendant longtemps, il y a eu deux standards concurrents pour HTML5 : celui du W3C et celui du WHATWG. Le 28 Mai 2019, le W3C a officiellement annoncé qu’il déléguait la maintenance du standard HTML et DOM, au WHATWG, le W3C devenant un collaborateur.

Voir : W3C and the WHATWG signed an agreement to collaborate on a single version of HTML and DOM (w3.org), Mai 2019.

Il n’y a donc maintenant qu’une source unique pour ce « standard ». Je met des guillemets, parce que le WHATWG ne maintient pas un standard, mais un “ living standard ”, un « standard » jamais stable ; c’est ce qui me préoccupe encore malgré que la situation soit quand‑même plus claire maintenant. Édit du 2025-12-09 : mais le W3C maintient encore certains standard, comme l’API MIDI et l’API audio pour le web et bien sûr, l’incontournable CSS sans quoi rien ne serait présentable.

Pour un standard plus stable, le W3C reste une option : HTML 5.3 (w3.org), Octobre 2018. Édit du 2025-11-22 : ce lien est maintenant une redirection vers le site du WHATWG , mais un autre document reste maintenu par le W3C, cependant peut‑être obsolète : HTML5 (w3.org).

Il change au plus une fois par an, ce qui est plus crédible qu’un « standard » comme celui du WHATWG, qui change tous les deux ou trois jours. En consultant celui du W3C, il faut juste vérifier l’existence d’une version plus récente, de temps en temps, en augmentant le numéro de version dans l’URL. Par exemple changer html53 en html54 dans l’URL plus haut, et voir si l’URL renvoi vers une page non‑trouvée ou pas. Ne pas tester simplement html ou html5 pour avoir la dernière version, ça redirige vers le « standard » du WHATWG.

— Édit du 2025-12-05 —

Le WHATWG, qui définie aussi le DOM et diverses autres interfaces de programmation (API), ne les définit pas toutes. Par exemple pour le MIDI accessible en JavaScript (*), c’est encore le W3C qui s’occupe des spécifications : Web MIDI API (w3.org).

(*) En vrai, ce sont des interfaces en IDL (Interface Description Language), qui n’implique pas que la mise en œuvre est pour un interpréteur JavaScript. D’ailleurs JavaScript n’est jamais mentionné, excepté occasionnellement en coulisse comme source d’inspiration ou comme « préoccupation ». Il se trouve seulement que JavaScript est le langage le plus concerné par ces API (mais pas seulement, Rust aussi) et que par défaut, les scripts qui s’intègrent au HTML, sont en JavaScript, au point qu’il est même conseillé de ne plus préciser d’attribut type aux éléments script.

Ne pas confondre HEAD et HEADER. Ne pas confondre EM et STRONG. Les éléments B et I n’ont pas de sémantique.

HEADER fait partie contenu de la page, il ne contient pas des méta‑données comme HEAD.

EM met une emphase, qui modifie le sens perçu à la lecture de la phrase, selon une interprétation humaine implicite. Le texte dans EM, se réfère aux même mots correspondant ailleurs, qu’ils aient été écrit explicitement ou lus implicitement. La relation créé peut être une relation d’accord ou de désaccord, par exemple.

STRONG ne cré pas de relation interprétable comme EM, il met une emphase seulement pour souligner, dit seulement qu’il ne fait pas omettre ce qui est dans STRONG, par exemple en cas de lecture en diagonale.

B n’est ni EM ni STRONG.

MAIN est un élément très important. Il n’est pas un élément définissant une section, contrairement à ce qui est parfois affirmé sur certains sites. Il est très important parce qu’il permet de déterminer ce qui est vraiment le contenu de la page, pour les lecteurs d’écran et pour les robots qui ne posent pas de problèmes. Pour mettre de côté ce qui est accessoire, on peut lui joindre l’élément ASIDE.

Les éléments définissant des sections, peuvent être imbriqués. Par exemple on peut avoir un ARTICLE inclus dans un ARTICLE. Si ça fait sens ou pas, dépend des cas. Ça peut être intéressant quand un article est lui‑même composé d’éléments, dont des éléments sont accessoire, et il faut alors à nouveau distinguer ce qui est accessoire mais qui se situe dans le ARTICLE, en utilisant encore à l’intérieur, une distinction avec ASIDE et ARTICLE.

CSS3 existait déjà en 2001 : Introduction to CSS3 (w3.org), 23Mai 2001. Ça surprend, alors que CSS n’a commencé à être courant que depuis environ 2005 ou même après ; avant ça, le style était indiqué sur chaque élément avec des attributs, ce qui faisait d’ailleurs des pages lourdes et difficile à éditer.

CSS et HTML sont deux choses séparées, mais elles sont liées et encore plus quand on parle de HTML5, en pratique on parle souvent du JavaScript et du CSS qui les accompagnent, alors il y aura peut‑être d’autres écarts comme celui‑ci dans ce sujet.

Les bordures des boites sont spécifiées dans CSS background au lieu de CSS box‑model comme ça devrait être le cas : CSS Box Model Module Level 4 (w3.org), 4 Août 2024.


Ça devrait être le cas, parce que les bordures font partie du dimensionnement des boites et les marges qui sont décrites dans box‑model, sont empêchées de fusionner quand il y a des bordures.

Un autre sujet en rapport : HTML5 et API web : les quirks sans quirks‑mode.

Voir aussi, en rapport : Un typage ingénieux pour JavaScript.