La sémantique en HTML 5

Arrêtons-nous à considérer notre responsabilité. Par accident de l’histoire, nous sommes associés au développement d’un outil important que notre civilisation utilisera pour communiquer pendant des décennies. Par conséquent, lorsque nous nous tournons vers l’amélioration du langage HTML, nous devons comprendre à quel point les conséquences des décisions d’aujourd’hui peuvent être considérables.

HTML 5, l’effort récemment redoublé du W3C pour façonner la prochaine génération de HTML, a pris, au cours de la dernière année, un élan considérable. C’est un projet énorme, couvrant non seulement la structure du HTML, mais aussi les modèles d’analyse, les modèles de gestion des erreurs, les DOM, les algorithmes de récupération de ressources, les contenus multimédias, les dessins 2D, les modèles de sécurité, les modèles de chargement de pages, stockage de données côté, et plus.

Il y a également des révisions de la structure, de la syntaxe et de la sémantique de HTML, dont certaines ont été abordées dans «Un aperçu de HTML 5».

Mais pour cet article, considérons uniquement la sémantique du HTML. C’est quelque chose qui m’intéresse depuis de nombreuses années et qui, à mon avis, est fondamental pour l’avenir du HTML.

La BBC a récemment annoncé qu’elle supprimerait le microformat hCalendar de ses listes de programmes, en raison de problèmes d’accessibilité et de facilité d’utilisation liés au modèle de conception abbr. Cela démontre que nous avons, sans aucun doute, repoussé la capacité sémantique du langage HTML, bien au-delà de ce qui avait été prévu, et de ce qui est raisonnablement possible avec le langage. Nous avons simplement épuisé les éléments HTML et les attributs pour baliser des documents sémantiques plus riches. Si nous continuons à être intelligents avec les constructions existantes de HTML, de tels problèmes se poseront. Mais HTML souffre d’un défaut fondamental en tant que langage de balisage sémantique: sa sémantique est fixe et non extensible.

Ce n’est pas simplement un problème théorique. Des centaines de milliers de développeurs utilisent les attributs class et id de HTML pour créer un balisage sémantique plus riche. (Ils les utilisent aussi comme des «crochets» pour le style CSS, mais c’est une autre affaire). Presque invariablement, ces développeurs utilisent des vocabulaires ad hoc, c’est-à-dire des valeurs qu’ils ont constituées, plutôt que des valeurs issues de schémas existants. Il s’agit au mieux d’un pseudo balisage sémantique.

De nombreuses pages du Web utilisent des microformats pour ajouter une sémantique plus structurée que celle disponible dans l’ensemble des éléments et des attributs appauvris de HTML. Dans ce cas, les valeurs utilisées pour l’attribut class proviennent de vocabulaires convenus, parfois adoptés à partir d’autres normes, telles que vCard, parfois à partir de nouveaux vocabulaires où aucune norme préexistante solide n’existe (comme c’est le cas pour hReview).

Sémantique Extensible

Il y a un problème très réel qui doit être résolu ici. Nous avons besoin de mécanismes en HTML qui permettent clairement et sans ambiguïté aux développeurs d’ajouter à leur balisage une sémantique plus riche et plus significative, et non une pseudo-sémantique. C’est peut-être l’objectif le plus urgent du projet HTML 5.

Mais ce n’est pas aussi simple que de trouver un mécanisme permettant de créer une sémantique plus riche en contenu HTML: les solutions sont soumises à des contraintes importantes. Le plus important est peut-être la compatibilité ascendante. La solution ne peut pas casser les centaines de millions d’appareils de navigation utilisés aujourd’hui, qui continueront d’être utilisés pendant de nombreuses années. Toute solution qui ne serait pas rétrocompatible ne sera pas largement adoptée par les développeurs par crainte d’exclure les lecteurs. Il va rapidement dépérir sur la vigne.

La solution doit également être compatible avec le futur. Pas dans le sens où il doit fonctionner dans les futurs navigateurs – c’est la responsabilité des développeurs de navigateurs – mais il doit être extensible. Nous ne pouvons nous attendre à une solution unique que nous développons en ce moment pour résoudre tous les futurs besoins sémantiques imaginables et inimaginables. Nous pouvons développer une solution qui peut être étendue pour répondre aux besoins futurs à mesure qu’ils se présentent.

Ces deux contraintes en tandem présentent un énorme défi. Mais dans le contexte d’un langage dont les principales itérations arrivent à une décennie de distance et dont l’importance en tant que plate-forme mondiale de communication est primordiale, c’est un défi à résoudre.

Alors, comment HTML 5 aborde-t-il ce problème? HTML 5 introduit un certain nombre de nouveaux éléments. Certains sont ce que j’ai appelé «structurel»: section, nav, side, header et footer. L’élément de dialogue est une sorte d’élément de contenu, semblable à un blockquote. Il existe également un certain nombre d’éléments de données, tels que le compteur, qui «représente une mesure scalaire dans une plage connue ou une valeur fractionnaire; par exemple l’utilisation du disque »et l’élément time, qui représente une date et / ou une heure.

Bien que ces éléments puissent être utiles et semblent avoir suscité un certain intérêt, résolvent-ils réellement le problème que nous avons identifié, en particulier dans le double contexte de la compatibilité ascendante et descendante?

Considérons chaque contrainte.

RÉTROCOMPATIBILITÉ

Comment les navigateurs actuels gèrent-ils ces nouveaux éléments, tels que la section? Eh bien, les versions les plus récentes de Safari, Opera, Mozilla et même IE7 vont toutes rendre une page comme suit.

<h1>Top Level Heading</h1>

<section>
  <h1>Second Level Heading</h1>
    <p>this is text in a section element</p>
    <section>
      <h1>Third Level Heading</h1>
    </section>
</section>
Cela ressemble à un excellent début. Mais lorsque nous essayons de styliser, par exemple, des éléments de section avec CSS qui ressemblent à ceci:

section {color: red}
… la plupart des navigateurs mentionnés ci-dessus réussissent à styliser l’élément, mais pas IE7 (et donc probablement 6).

Nous avons donc un sérieux problème de compatibilité avec 75% des navigateurs actuellement utilisés. Compte tenu de la demi-vie d’Internet Explorer, nous pouvons prédire que la plupart des utilisateurs utiliseront IE6 ou IE7 dans plusieurs années.

Si HTML 5 introduit ces nouveaux éléments, quelle est la probabilité qu’ils soient mis en œuvre par la grande majorité des développeurs, sachant qu’ils sont essentiellement incompatibles avec la majorité des navigateurs utilisés?

Malheureusement, si vous recherchez des solutions alternatives au problème CSS, placez des attributs de classe sur vos éléments de section et essayez ensuite de les styliser à l’aide de la valeur de la classe. Cela ne fonctionnera pas dans IE. Peut-être y a-t-il une solution de rechange, mais à moins qu’il y en ait, cela ressemble à une rupture de marché.

Passons maintenant à la compatibilité, la deuxième contrainte.

COMPATIBILITÉ AVANT

Nous commencerons par poser la question: «pourquoi inventons-nous ces nouveaux éléments?» Une réponse raisonnable serait: «parce que le HTML manque de richesse sémantique, et en ajoutant ces éléments, nous augmentons la richesse sémantique du HTML – cela ne peut pas être mauvais, n’est-ce pas?

En ajoutant ces éléments, nous nous penchons sur la nécessité d’une plus grande capacité sémantique en HTML, mais seulement dans un champ restreint. Peu importe le nombre d’éléments que nous allumons, nous penserons toujours à plus de bonté sémantique à ajouter au HTML. Et donc, après avoir ajouté autant de nouveaux éléments que nous le souhaitons, nous n’aurons toujours pas résolu le problème. Nous n’avons pas besoin d’ajouter des termes spécifiques au vocabulaire HTML, nous devons ajouter un mécanisme permettant d’ajouter de la richesse sémantique à un document si nécessaire. En termes techniques, nous devons rendre HTML extensible. HTML 5 ne propose aucun mécanisme d’extensibilité.

HTML 5, par conséquent, implémente une fonctionnalité qui casse un pourcentage considérable des navigateurs actuels, et ne nous permet pas vraiment d’ajouter une sémantique plus riche au langage.

Plusieurs questions demeurent concernant les nouveaux éléments. D’où viennent ces nouveaux noms d’éléments? Comment at-il été décidé qu’il devrait y avoir un élément de navigation et qu’il devrait être appelé «nav»? Pourquoi le même terme devrait-il s’appliquer à la navigation au niveau de la page, au niveau du site et au niveau du méta-site?

Pourquoi ne pas adopter un vocabulaire existant, tel que Docbook? Son vocabulaire relatif à la structure des documents est beaucoup plus riche et a été développé par des experts en publication pendant de nombreuses années. Ce n’est pas un argument en faveur de Docbook, en particulier: le fait est que la tâche extrêmement importante de fournir un mécanisme pour la richesse sémantique en HTML est abordée de manière ad hoc, en accordant apparemment peu d’attention aux meilleures pratiques 30 ans ou plus. (Le travail original sur GML a commencé au début des années 1970).

Quelques réflexions sur une solution

Donc, après avoir critiqué les efforts actuels, ai-je des suggestions pratiques sur la façon de résoudre ce problème? Eh bien, j’ai le début d’un.

Si ajouter des éléments à HTML est hors de question, du moins dans les paramètres de cette discussion, les attributs sont l’autre domaine logique du HTML sur lequel se concentrer. Après tout, pendant près d’une décennie, nous avons utilisé des attributs de classe et d’identifiant pour étendre la sémantique de HTML. Un grand nombre de développeurs sont familiers avec cela. Le projet microformats a démontré que les attributs existants de HTML ne sont pas suffisants, en tant que mécanisme généralisé, pour étendre la sémantique de HTML. Donc, si nous devons utiliser des attributs pour résoudre ce problème, nous devons créer un ou plusieurs nouveaux attributs. Avant d’en savoir plus sur la façon dont cela pourrait fonctionner, il est juste de soumettre cette suggestion aux mêmes exigences que pour les nouveaux éléments de HTML 5. Plus important encore, est-ce que l’introduction de nouveaux attributs HTML rétrocompatibles? Et si oui, fournit-il un mécanisme réalisable d’extensibilité sémantique en HTML?

Inventons un nouvel attribut. Je l’appelle «structure», mais le nom particulier n’est pas important. Nous pouvons l’utiliser comme ceci:

<div structure=”header”>

Voyons comment nos navigateurs s’en sortent avec cela.

Bien entendu, tous nos navigateurs auront un style CSS pour cet élément.

div {color: red}

Mais qu’en est-il de ça?

div [structure] {font-weight: bold}

En fait, presque tous les navigateurs, y compris IE7, stylisent le div avec un attribut de structure, même si l’attribut de structure n’existe pas! Malheureusement, notre chance est au rendez-vous, contrairement à IE6. Mais nous pouvons utiliser l’attribut en HTML et faire en sorte que tous les navigateurs existants le reconnaissent. Nous pouvons même utiliser CSS pour styler notre HTML en utilisant l’attribut dans tous les navigateurs modernes. Et si nous voulons une solution de contournement pour les navigateurs plus anciens, nous pouvons ajouter une valeur de classe à l’élément de style.

Comparez cela avec la solution HTML 5, qui ajoute de nouveaux éléments qui ne peuvent pas être stylés dans Internet Explorer 6 ou 7 et vous verrez qu’il s’agit là d’une solution plus rétrocompatible.

Extensibilité à travers des attributs

Au lieu de nouveaux éléments, HTML 5 devrait adopter un certain nombre de nouveaux attributs. Chacun de ces attributs concernerait une catégorie ou un type de sémantique. Par exemple, comme je l’ai détaillé dans un autre article, HTML inclut la sémantique structurelle, la sémantique rhétorique, la sémantique des rôles (adoptée à partir de XHTML) et d’autres classes ou catégories de sémantique.

Ces nouveaux attributs pourraient alors être utilisés comme l’attribut class est utilisé: pour s’attacher à une sémantique d’élément décrivant la nature de l’élément ou pour ajouter des métadonnées sur l’élément.

Ceci n’est pas différent de l’attribut role de XHTML, mais plutôt que d’avoir un seul attribut “bucket” pour toute la sémantique de l’élément, nous devrions identifier les différents types de sémantique pour un élément et les séparer.

Par exemple, l’attribut de rôle XHTML fonctionne comme suit:

<ul role=”navigation sitemap”>
  <li href=”downloads”>Downloads</li>
  <li href=”docs”>Documentation</li>
  <li href=”news”>News</li>
</ul>

Les valeurs de l’attribut role sont une liste de mots, séparés par des espaces, du vocabulaire par défaut ou d’un vocabulaire défini.Pourquoi ne pas simplement adopter l’attribut de rôle tel quel? Eh bien, il existe d’autres types de sémantique pour lesquels le terme rôle ne s’applique pas. Par exemple:

<p rhetoric=”irony”>He’s a fantastic person.</p>

Cela montre un type théorique de sémantique – “rhétorique” – qui pourrait être utilisé pour décrire la nature rhétorique. Bien entendu, cet élément n’a pas pour tâche “l’ironie” dans le document, mais le contenu de l’élément est ironique.

Encore une fois, peu importe si nous utilisons “équivalent” ou un autre nom. Il est important de savoir qu’il n’est pas aussi simple que d’utiliser l’attribut class ou l’attribut role en tant que conteneur unitaire pour toutes les informations sémantiques. Pour une solution propre extensible, une compatibilité ascendante et une flexibilité suffisante seraient au moins garanties pour envisager une solution dans la direction décrite ci-dessus.

J’ai étiqueté ce paragraphe “Quelques réflexions sur une solution” parce que la partie importante du travail consiste à développer une solution viable. Les questions ouvertes sont les suivantes.

  • Combien d’attributs sémantiques différents devrait-il exister? Ces catégories devraient-elles être extensibles et si oui, comment?
  • Comment sont définis les termes?
  • Devrions-nous simplement inventer les valeurs dont nous avons besoin, comme le font les développeurs, avec les valeurs de classe, ou faut-il que toutes les valeurs soient définies dans une spécification normalisée? Ou devrait-il y avoir une technique pour inventer (et, espérons-le, partager) une sorte de profil?
  • Si un conflit se produit entre deux termes, par exemple, si deux expressions identiques sont définies par deux termes différents, comment est-il résolu?
  • Avons-nous besoin d’une forme d’espace de noms ou existe-t-il une autre technique?

Au lieu de me précipiter pour répondre à ces questions, je les soulève pour mettre en évidence les tâches à accomplir. Et pour commencer un dialogue. Les ramifications et la portée des décisions à prendre pour HTML 5 sont trop importantes pour être prises sans une connaissance approfondie de la linguistique, de la sémantique, de la sémiotique et des domaines connexes.

Espérons-le, sinon rien, il est clair que le simple fait d’inventer de nouveaux éléments ne prolonge pas la sémantique du HTML.

Ne prenons pas ces décisions à la légère, nous avons déjà suffisamment mis nos petits-enfants au défi du changement climatique. Laissez-nous vous laisser le meilleur HTML possible.

Source : https://alistapart.com/article/semanticsinhtml5