L'utilisation des "calques" DIV associés aux styles CSS devient le nouveau courant d'intégration et de mise en forme des documents pour de nombreuses raisons.
Cette nouvelle "mode" apporte son lot de fanatismes et surtout d'incompréhensions et de mauvaises utilisations.
Pour exemple le plus classique : les gens se disent : "chouette, je vire les tableaux et je remplace par des divs" (ensuite ils se retrouvent avec autant de divs qu'ils avaient de cellules de tableaux et se disent : les calques / CSS c'est nul, ça sert à rien !).
Confusions de termes et amalgames
Il ne faut pas confondre CSS, XHTML, Anti-Tableaux, Sémantique et Accessibilité. La mode des CSS se développe tellement vite qu'elle s'accompagne de nombreux amalgames de ce genre.
CSS ne signifie pas obligatoirement "Anti-Tableaux" (tableless)
La Sémantique et l'Accessibilité existaient dès la création du web : avant même les CSS et XHTML, le web avait pour but de structurer des informations (sémantique) et d'être universel (accessibilité).
Dire : "je me mets aux CSS (ou au XHTML) donc je supprime les tableaux pour la mise en page" est une faute de logique car il n'y a aucune relation directe entre les Feuilles de Style et les tableaux.
Les tableaux ne sont qu'un lot de balises (TABLE, TR, TD, ...) qui appartient au langage HTML et prévu pour structurer des données tabulaires.
Le W3C déconseille effectivement l'utilisation de tables pour les mises en pages, mais ne l'interdit pas pour autant. Pour preuve, un document structuré sous tableaux peut être Valide en XHTML Strict.
Mais CSS ne signifie pas obligatoirement "Anti-Tableaux" : on ne supprime pas les tableaux pour une question de langage (CSS, XHTML), mais pour une question de Sémantique (les tableaux sont fait pour la structuration de données) et, surtout, pour une question d'Accessibilité (une mise en page tabulaire n'offre pas de "vision d'ensemble" aux handicapés, notamment aux aveugles)
CSS ne signifie pas obligatoirement "Sémantique"
Dire que "Se mettre au CSS c'est obligatoirement se mettre a créer des documents sémantiquement corrects" est également faux.
Depuis que le HTML existe, rien ne nous a empêché de faire des documents sémantiquement corrects. Le XHTML n'a rien inventé de ce côté.
A l'inverse vous pouvez très bien concevoir un site Valide XHTML Strict qui n'est pas sémantique pour un sou. Tout simplement parce que les Validateurs ne sont pas des baguettes magiques : ils vérifient si la syntaxe est bonne, si les balises sont propres.
Par contre, il leur est impossible de vérifier si vous avez utilisé les bonnes balises au bon endroit. Ni de savoir si votre paragraphe (p) est bien un paragraphe et non un titre (Hn), etc...
Par exemple, vous pouvez très bien définir un bloc qui fait 70000px de haut. C'est propre et Valide, mais ça ne ressemble à rien.
Bref, la sémantique est un travail à part, qui n'est pas automatique en codant en XHTML / CSS
CSS ne signifie pas obligatoirement "Accessibilité"
Comme la Sémantique, l'Accessibilité n'est pas inhérente au XHTML/CSS. Elle suit des normes spécifiques et une liste de points à vérifier. Elle dispose également de Validateurs spécifiques.
Pour finir : les différences entre XHTML et HTML
Ne pas croire que XHTML est obligatoirement synonyme de CSS.
Pour information, je rappelle que les seules différences fondamentales entre HTML et XHTML sont de l'ordre de la rigueur :
- Toute balise ouvrante doit être fermée
- Balises et propriétés en minuscules
- Valeurs entre quotes (apostrophes) ou double quotes (guillemets)
- Chaque propriété doit avoir une valeur (pas de propriété vide comme
checked, qui doit être écritchecked="checked") - Les balises doivent être correctement imbriquées
C'est tout ! Comme vous le voyez, aucune notion de tableaux, de CSS, de sémantique ni d'accessibilité : ces termes et domaines existent déjà en HTML
Conclusion
Ce petit explicatif est très loin d'être exhaustif, il n'est pas fait pour servir de référence.
Il est simplement un petit rappel pour ne pas faire de confusions hâtives entre différents domaines qui, bien que proches, ne sont pas obligatoirement synonymes.
Commentaires
Hello,
bravo pour cet article qui remet bien des pendule à l'heure...
Oui, bravo :o)
Mais en même temps, je trouve ça triste qu'on doive sans cesse rappeler ce genre de choses qui semblent pourtant évidentes : pourquoi faire compliqué (tableaux, tagsoup et divsoup) quand on peut faire simple (sémantique et une bonne sieste).
Le plus effrayant, c'est de passer pour d'austères et rigides codeurs quand on parle de css, sémantique ou accessibilité ! Vivement que le vent tourne !
Argh, nooooooon! Le web moderne ne consiste pas à utiliser des calques. Le calque reste une exception, un ultime recours quand on ne peut faire autrement. Ce n'est absolument pas la base du concept. :-)
openweb.eu.org/humeurs/ca...
Cette idée vient des éditeurs WYSIWYG qui ont autant de vocabulaire qu'un animateur télé ou un politicien. Comment on insère un <address> ou un <blockquote> avec ces outils, par exemple?
@Fabrice Bonny : "Le web moderne ne consiste pas à utiliser des calques."
>> Oui, c'est vrai que j'ai employé le terme de "calque" en début de billet. Je l'ai mis volontairement entre guillemets puisque de toute façon selon moi, un calque ne signifie plus grand-chose :
www.alsacreations.com/art...
J'aurai sans-doute dû utiliser le terme d'"élément"...
Mais en fait je ne vois pas vraiment le rapport avec le billet : celui-ci ne porte pas du tout là dessus ;)
Le terme calque désigne généralement un <div> (ou un <layer> du temps de Netscape Communicator). Il faut bien parler d'élément ou de conteneur. Quant au rapport avec ton billet, on parle bien de "sématique" (attention, pas du web sémantique) puisque l'on voit des <div class="adresse"> au lieu de <address>. Sinon, on en arrive à une solution où on met autant de <div> que l'on mettait de <td>. :-)
@Fabrice Bonny : "Quant au rapport avec ton billet, on parle bien de "sématique""
>> Oui j'évoque la sémantique pour rappeler que "CSS" n'est pas obligatoirement synonyme de "Sémantique".
Il est vrai que la Sémantique est souvent occultée : on voit souvent des DIV mal utilisées plutôt que des balises appropriées et pourvues de sens.
J'en remets une couche à la suite de Fabrice : Vu ce que font les DreamWeaver de tout poil et même certains auteurs qui codent à la main, il faut systématiquement mettre en garde sur les utilisations abusives des <div> à la place des éléments de texte HTML spécifiques.
Mais surtout, à propos de "Comme la Sémantique, l'Accessibilité n'est pas inhérente au XHTML/CSS." :
il me semble préférable de dire ici : "XHTML/CSS ne suffisent pas à garantir l'accessibilité, mais un de leurs objectifs majeurs est de favoriser le reste de la démarche d'accessibilisation, qui a ses propres critères plus spécifiques."
Le point 11.1 de la WAI dit clairement : "Utilisez les technologies du W3C quand elles sont disponibles et appropriées pour une tâche, et utilisez les dernières versions dès quelles sont supportées."
@Laurent Denis > Tout à fait.
Je veux simplement mettre le doigt pour dire que l'objectif à atteindre (l'Accessibilité) n'est pas OBLIGATOIREMENT atteint, par magie, en faisant du XHTML / CSS et en arborant un joli logo "XHTML Valid !".
Beaucoup de gens croient que tout est automatique : en faisant un site en XHTML/CSS, ils auront nidéniablement un site sans tableaux, sémantique et accessible... ce qui est faux.
Le langage n'est qu'un moyen pour atteindre les différents objectifs...
> Le W3C déconseille effectivement l'utilisation de tables pour les mises en pages, mais ne
> l'interdit pas pour autant. Pour preuve, un document structuré sous tableaux peut être
> Valide en XHTML Strict.
Normal, ce n'est pas le rôle du validateur HTML, qui lui ne s'occupe que de vérifier la syntaxe et l'imbrication des éléments. Il ne s'occupe pas du sens. Le validateur ne vérifie qu'une partie du langage : la syntaxe.
C'est un peu comme si on disait que le code de la route n'interdit pas le demi-tour parce que à la station service les pneus sont gonflés selon les recommandations.
Je crois qu'il faut rapidement qu'on fasse comprendre aux gens que le validateur est un outile, pas un but. On peut avoir une page acceptable et non valide comme une page innacceptable et valide. Et pour ça il faut vite arrêter de jurer par le validateur à chaque fois.
C'est d'ailleurs vrai aussi avec les "validateurs" d'accessibilité, il ne s'agit que d'outils pour aider l'auteur, rien d'autre.
Pour compléter Eric "On peut avoir une page acceptable et non valide comme une page innacceptable et valide. Et pour ça il faut vite arrêter de jurer par le validateur à chaque fois." :
Une page, formellement invalide selon le validateur mais à cause d'erreurs "minimes" me semble beaucoup moins grave qu'une page formellement valide, mais en fait truffée de div employée à la place des éléments significatifs, ou structurée n'importe comment, ou faisant de la pseudo-structure factice dans les navigateurs graphiques à coup de CSS. ça reste encore vrai (dans certaines limites dont on avait parlé ici à la suite d'un autre post) lorsque les tableaux sont utilisés pour la présentation.
Eric a tout à fait raison : pour promouvoir la conformité aux Standards, il faut clairement avertir des limites des outils de validation, et différencier validité et conformité.