Etirez, réduisez, déplacez et empilez les blocs... >>> Retour page R&D
21 février 2008
La théorie générale précise que l'encadrement des objets par un jeu de balises spécifiques détermine une (esquisse de) "sémantique de contenus" : <h[n]> décrit un certain niveau de titre, <p> un paragraphe, <img> un contenu visuel, etc...
Si cette sémantique minimaliste est incapable de préciser si un texte est légèrement plus important qu'un autre - l'équivalent d'un encadré par exemple, sens que <strong> ou <em> ne recouvre pas - ou si une photo illustre basiquement le texte ou apporte un regard ironique et distancié, elle est en revanche suffisante pour organiser et structurer les contenus en vue de récupération et de traitement ; on peut, via un certain nombre de dispositifs, discriminer telle ou telle balise pour en gérer ponctuellement le contenu (le faire apparaître ou disparaître, l'imprimer ou l'ignorer, n'en restituer qu'une partie, etc.) selon les UA.
L'utilisation rationnelle de ces balises, base de la validation W3C, garantit donc des restitutions conformes aux normes technologiques en vigueur dans le monde du web. Mais ces normes ont leurs limites : d'une part elles ne sont utilisables que dans le strict cadre restreint du www, de l'autre elles ne sont pas suffisamment détaillées pour recouvrir le champ des sémantiques possibles en dehors d'une "mise en page" à plat et en 2D. Dans l'optique d'un web 3D où il sera nécessaire de prévoir de usages "spatiaux" et "temporels" des objets, la sémantique Html devient à peu près inopérante. Devons-nous pour autant le jeter ? Non, et pour deux raisons : la première est que des consultations www continueront à être demandées et que nous nous devons d'assurer la pérennité et la rétro-compatibilité des contenus, la seconde est que quelle que soit la forme que prendront les contenus web 3D, en tant qu'objets numériques ils resteront signalisés. Que cette signalisation à venir soit une déclinaison des balises actuelles - tendance Xml - ou une création pour répondre à des langages particuliers n'a en soi pas tellement d'importance si une méthode de conversion (mutabilité des contenus) est possible.
Ceci plaide en faveur de pratiques allant vers un plus grand respect de cette sémantique Html portée par ses balises, pas tant pour ce qu'elle est (faible, incomplète, peu performante) que pour ce à quoi elle pourra servir.
Les balises neutres <div> et <span> se différencient par leurs statuts : block ou inline, c'est-à -dire par la façon qu'elles auront à interagir avec leur environnement structurel : <div> - dont la sémantique propre est "division dans un contenu" - crée un objet de sens neutre en tant que diviseur : il ne précise pas le rôle de son contenu interne dans l'architecture globale des sens mais instancie une découpe particulière en un endroit particulier qui vient scinder le contenu général ou en particulariser une partie, par exemple pour l'extraire une partie (encadré) ou la définir comme outil de la page (menu) ; <span>, en tant qu'objet inline, sert lui à décrire, au sein d'un sens porté par une balise, une partie à laquelle attribuer un traitement particulier : par exemple une couleur de texte différente, une autre typo, un fond distinct, etc.
Si dans une optique purement www l'usage de <div> ou de <span> ne requiert de distinguo que formel (y'a t-il ou pas rupture "optique" du flux ?), dans un usage futur, distinguables en tant qu'objets par lesquels un sens peut se mettre à passer, le choix d'utiliser l'une ou l'autre n'est plus neutre : à une rupture optique de flux en 2D peut correspondre une rupture d'objets en 3D, à une découpe textuelle peut correspondre un changement de lieu, de temps ou des deux.
Si d'un point de vue sémantique web une structuration Html de type <div><h1><h2><div><p><span> (j'interviens au final sur une partie de paragraphe appartenant à un sous-ensemble d'une séquence de titres elle-même incluse dans une division initiale) est à peu près équivalente à <div><h1><div><h2><p><span> (j'interviens au sein d'un objet distinct constitué d'un titre et d'un paragraphe et dépendant du titre de premier niveau), en terme de manipulation ultérieure - par exemple en gestion d'objets-volumes - le scénario est différent : l'objet <p>, modifié localement par <span>, sera physiquement relié ou pas à <h2>. Ce statut de <p>, déjà effectif via Css (on peut faire intervenir une cascade particulière en dotant le second <div> d'attributs spécifiques) mais non-effectif d'un pur point de vue Html, n'est plus le même, même en l'absence de Css. Toute intervention sur <h2> dans la première version n'implique pas nécessairement d'intervention sur <div><p> qui peut se trouver "coupé" du flux ; en revanche, dans la seconde version, toute intervention sur <h2> impliquera une conséquence sur la séquence <p><span>. Pour obtenir ce résultat en restitution www, on devra soit affecter des séries d'attributs à <h2> (version 1), soit les affecter au second <div> (version 2). Du coup les deux structurations ne sont plus du tout équivalentes : dans un cas on interagit avec un objet (<p><span>) et dans l'autre avec un autre (<h2><p><span>). C'est la différence qui existe en PAO ou en 3D entre des objets liés et des objets non-liés.
Or affecter à <h2> des attributs concernant les comportements futurs de <p><span> considérés en tant qu'objets à lier revient à surajouter à <h2> des événements ou éléments qui ne relèvent pas de sa sémantique propre (introduire un type de contenu de deuxième niveau). Ce qui, en affichage web, ne relève que d'une habitude de codage ou de besoins de mise en page peut présenter, sous d'autres contextes de restitution, des fonctionnalités très différentes. Il n'est donc pas anodin d'utiliser la sémantique à des fins de présentations : outre que cela peut nuire à la restitution web, cela peut également empêcher un usage rationnel des objets définis par cette sémantique, aussi faible soit-elle. Et puisque Css autorise une gestion fine des apparences et positionnements média par média, il est donc préférable - comme dans l'exemple ci-dessus - d'opter pour un usage non-neutre des balises neutres. Au pire ça ne servira à rien, au mieux ça servira à tout. Quoi qu'il en soit, ça garantira un résultat optimisé dans tous les cas... alors que l'inverse n'est pas vrai.