La structure de vos pages (<div> et <hn>) ?

Bonjour !

J'ai une question qui me taraude depuis plusieurs temps, qui concerne la structure de base d'une page. Cette question est la suivante : quand vous avez, par exemple, plusieurs <h2>. Est-ce que vous mettez chaque <h2> dans sa propre <div> ? Ou mettez-vous une seule <div> avec tous les <h2> dedans ?

Voici le code de la première proposition (avec un <h1> et des <p> pour avoir une structure complète) :

<div>
  <h1></h1>
  <p></p>
  <div>
     <h2>
     <p></p>
  </div>
  <div>
     <h2>
     <p></p>
  </div>
</div>

Et ici le code de la deuxième proposition :

<div>
  <h1></h1>
  <p></p>
  <div>
     <h2>
     <p></p>
     <h2>
     <p></p>
  </div>
</div>

Alors pourquoi je me pose cette question, c'est surtout parce qu'on voit sur une majorité de sites la deuxième proposition. Avec des <hn> qui n'ont pas leur propre <div>, des <h2><h3><h4> qui se suivent, etc. Hors, en regardant dans les spé HTML et WCAG, on peut lire plusieurs choses :

Dans la spé HTML 4.01, il est indiqué clairement qu'un titre décrit la section qu'il introduit. Donc un <hn> va décrire son <div>. Dans la même page, il est inscrit en titre de section pour les div et span, la formule "grouping elements".
Ainsi, on a un élément qui sert à en grouper d'autres (div), et qui se transforme en section avec l'ajout d'un titre (hn). Donc, si on prend la proposition 2, en prenant le deuxième <h2>. Ce <h2>, quelle section décrit-il ? Vu que la section dans laquelle il est, est déjà décrite par le premier <h2> . Dans la première proposition, chaque sous-sections est décrite par son <h2> à lui, et ne regroupe que les éléments (ici juste un <p>) en rapport avec le <h2>...

Jusqu'ici, on peut soulever un débat... Maintenant, en regardant la spé WCAG 1, et plus particulièrement les solutions techniques, on tombe sur cet exemple :

<H1>Cooking techniques</H1>
   ... some text here ...
   <DIV class="section2">
   <H2>Cooking with oil</H2>
   ... text of the section ...
   </DIV>

   <DIV class="section2">
   <H2>Cooking with butter</H2>
   ... text of the section ...
   </DIV>

Donc ici, chaque <h2> possède sa <div>....

Que pensez-vous de tout ça ? Peut-on dire que, dans tous les cas, si on veut une structure correcte, chaque <hn> doit être placé dans sa <div> ? Que plusieurs <hn> ne peuvent se côtoier ?

Pour ma part, ca dépend de l'importance du <hn> ... Mais si c'est pour une utilisation ressemblant à l'utilisation de <dt> / <dl> , j'utilise volontairement la deuxième proposition !

Je déplace dans le salon Sémantique où on parle de "Pourquoi et comment utiliser les balises (X)HTML à bon escient".

FlorentG a écrit :
Hors, en regardant dans les spé HTML et WCAG, on peut lire plusieurs choses :

Dans la spé HTML 4.01, il est indiqué clairement qu'un titre décrit la section qu'il introduit. Donc un <hn> va décrire son <div>. Dans la même page, il est inscrit en titre de section pour les div et span, la formule "grouping elements".
Ainsi, on a un élément qui sert à en grouper d'autres (div), et qui se transforme en section avec l'ajout d'un titre (hn)

(....)

Peut-on dire que, dans tous les cas, si on veut une structure correcte, chaque <hn> doit être placé dans sa <div> ? Que plusieurs <hn> ne peuvent se côtoier ?

Non, HTML4.01 n'est pas un format "hiérarchique" comme le sera HTML2.0 avec ses <section> et ses <h>. C'est un format "plat" où le regroupement d'éléments avec <div> est :
- optionnel
- justifié par le besoin d'appliquer un style, un script, etc.

En d'autres termes, l'erreur ici est de confondre <div> et <section> : <div> intervient quand il répond à un besoin de regroupement et qu'aucun autre élément spécifique ne convient. Mais il ne hiérarchise pas, et n'a aucune relation avec les titres <hn>.

Un document sans aucun <div> et avec une structure de <hn> est donc tout aussi valable que celui qui serait systématiquement découpé à coup de divs...
Modifié le 12 Jan 2005 - 18:42

Perso, je ne vois pas l'utilité d'ajouter des <div> à tout va lorsque ce n'est pas nécessaire.
Un titre décrit la section qu'il introduit, dans ce cas-ci un <p>.

<div id="section">
 <h2>Trucs moches</h2>
 <h3>La sexualité des baleines</h3>
 <p>Lorem ipsum</p>
 <h3>L'art chevaleresque du ping-pong</h3>
 <p>dolor sit amet</p>
 <h3>Les ours à gants</h3>
 <p>Un chasseur sachant chasser sans son chien peut chasser son chien</p>
 <h3>Mise en page tableau</h3>
 <p>grosso merdo</p>
</div>

Modifié le 12 Jan 2005 - 18:43

Laurent Denis a écrit :


Non, HTML4.01 n'est pas un format "hiérarchique" comme le sera HTML2.0 avec ses <section> et ses <h>. C'est un format "plat" où le regroupement d'éléments avec <div> est :
- optionnel
- justifié par le besoin d'appliquer un style, un script, etc.

Pourtant, il est bien écrit :

W3C a écrit :
Les éléments DIV et SPAN, en conjonction avec les attributs id et class, offrent un mécanisme générique qui rajoute de la structure aux documents.

Donc, en plus d'être optionnel ou d'être là pour le style, les <div> servent bien à rajouter de la structure

Laurent Denis a écrit :

En d'autres termes, l'erreur ici est de confondre <div> et <section> : <div> intervient quand il répond à un besoin de regroupement et qu'aucun autre élément spécifique ne convient. Mais il ne hiérarchise pas, et n'a aucune relation avec les titres <hn>.

C'est le <hn> qui donne une hiérarchie à la <div>, non ?

HTML4.01 n'oblige en rien à respecter la hiérarchie des <h1>...<h6>, aussi décevant que ce soit de le constater . Et il ne lie en rien les <h1>... <h6> aux structures crées avec <div> (pas plus qu'à d'autres structures).

D'autre part, "ajoute de la structure" (et je suis bien d'accord que les <div> sont des éléments structurels à part entière, et pas seulement un support de présentation)... ne dit pas que celle-ci induit une hiérarchie : cette structure consiste en un regroupement, c'est tout.

C'est pourquoi HTML est "plat" :
- la présence d'un titre dans une <div> ne permet pas d'en déduire la place de celle-ci dans une hiérarchie.
- et réciproquement, le niveau d'imbrication des <div> ne permet pas de déterminer le niveau de titres (par opposition, le mécanisme des <section> en XHTML2.0 détermine le niveau hiérarchique du titre. Il en est de même, sauf erreur de ma part, en Docboock par exemple).
Modifié le 12 Jan 2005 - 20:27

C'est en effet un choix possible. Mais un choix seulement, que rien n'appuie ni n'infirme dans HTML4.01. C'est le point qu'il fallait éclaircir ici

Sinon, pour ce qui est de convertir XHTML1.0 -> XHTML2.0 (via XSLT), une structure très précise et très stricte de <hn> suffit, sans que les <div> soient nécessaires.

Maintenant encore une question que je me pose. Au niveau de l'évolutivité d'un code XHTML, n'a-t-on pas interêt à rajouter des informations de structure ?
Surtout qu'on sait que séparer structure et présentation permet de changer la présentation sans toucher au reste. Maintenant s'il n'y a pas assez d'informations de structure, difficile de toucher à la présentation...
L'exemple même de ce que j'avance est bien-sûr CSS Zen Garden, qui, grâce à une structure extrêmement riche (trop riche d'ailleurs ), permet une infinité de designs.
Modifié le 12 Jan 2005 - 21:41

Le zen garden est à prendre à part selon moi. La richesse du code est pour la modularité à outrance pour tous le monde. En production concrète on peut obtenir les mêmes types de mise en page avec un code bien plus adapté.

Oui, CSS Zen Garden, c'est avant tout du balisage à outrance. Mais je me demande si parfois il ne faut pas rajouter un tout petit peu plus, voire mettre par exemple systématiquement un id ou des class à certains éléments, pour être plus modulables.
Par exemple, entre un code comme celui-là :

<h1>Mon Site</h1>
<h2>Menu</h2>
<ul>
  <li><a href="index.html">Accueil</a><li>
  <li><a href="truc.html">Trucs</a><li>
</ul>
<h2>Bienvenue</h2>
<p>Bienvenue sur mon super-site !</p>

Et celui-là :

<div id="main">
  <h1>Mon Site</h1>
  <div id="navigation">
    <h2>Menu</h2>
    <ul>
      <li><a href="index.html">Accueil</a><li>
      <li><a href="truc.html">Trucs</a><li>
    </ul>
  </div>
  <div id="contenu">
    <h2>Bienvenue</h2>
    <p>Bienvenue sur mon super-site !</p>
  </div>
</div>

C'est bien sûr le deuxième qui permettera le plus de choses par après. C'est un cas extrême (entre un code ultra-minimal et un code ultra-descriptif), mais je suis pour le fait de systématiquement donner un id à certains éléments qui le méritent, à bien séparer les sections par des <div>, etc. Je ne dis pas qu'il faille tomber dans ce qu'a fait CSS Zen Garden, mais parfois un petit peu plus permettera de faire pleins de choses
Modifié le 12 Jan 2005 - 21:55

FlorentG a écrit :
Maintenant encore une question que je me pose. Au niveau de l'évolutivité d'un code XHTML, n'a-t-on pas interêt à rajouter des informations de structure ?
Surtout qu'on sait que séparer structure et présentation permet de changer la présentation sans toucher au reste. Maintenant s'il n'y a pas assez d'informations de structure, difficile de toucher à la présentation..

Il ne s'agit plus vraiment de séparation structure/présentation ici, mais plutôt de savoir où on choisi de se placer entre:
- une structure très abstraite, "épurée", qui perd effectivement en possibilité de présentation (à moins de rajouter une couche supplémentaire... XSL) mais qui gagne en réutilisabilité.
- et une structure à l'inverse très concrète, qui est plus immédiatement "présentable", parce que beaucoup plus proche du media. CssZen Garden en est un excellent exemple.

Dans la pratique, qui ne s'est pas dit en concevant un template On ne sait jamais, une <div> pour regrouper ceci pourra toujours me servir plus tard... ?

Laurent Denis a écrit :

Dans la pratique, qui ne s'est pas dit en concevant un template On ne sait jamais, une <div> pour regrouper ceci pourra toujours me servir plus tard... ?

Voilà, c'est exactement ce que je me demande . Je suis dans la vie développeur de logiciels, et c'est quelque chose à laquelle je dois faire attention, à savoir que mes bouts de code puissent être réutilisables et extensibles. Même chose pour un code XHTML. Penser à l'avenir, faire bien la balance entre un sur et un sous-balisage...

En effet, pouvoir modifier le design ultérieurement juste en changeant le fichier CSS, c'est intéressant. Je ne sais pas pour vous, mais je change rarement le design d'un site existant. Je n'ai donc pas vraiment le goût d'ajouter des balises inutiles dans le moment, juste au cas où. Comme j'utilise les templates avec Dreamweaver, le jour que j'aurai à ajouter une balise pour que le nouveau design puisse prendre forme avec la nouvelle CSS, je n'aurai qu'à modifier la template. Le tour sera joué en peu de temps, et pendant les 6 mois que mon premier design aura été en ligne, je n'aurai pas consommé des octets supplémentaires inutilement et j'aurai conservé un code simple, sans balises superflux.

Suffit d'avoir les bons outils.

Ben après si t'as 1500 pages dont il faut modifier le design, et que tu n'as pas DreamWeaver...

Dans un tel cas, si tu as bien structuré ton site, c'est-à-dire qu'il est structuré de la même façon dans toutes les 1500 pages, tu peux toujours parvenir à ajouter des balises grâce à des fonctions de Trouver/Remplacer. Évidemment, ce n'est pas aussi simple qu'un système de template, mais ca reste dans le domaine du possible.

Ca reste au choix du développeur et des outils à sa disposition. Je ne crois pas que ce soit plus avantageux d'ajouter des balises superflux et des ID partout lorsque ce n'est pas nécessaire. Si t'es à l'aise avec cette idée, fais-le. Ce n'est pas non plus une mauvaise idée. Il m'arrive d'ajouter un div conteneur pour le site complet, même si celui-ci est fluide 100%. Je le fais au cas où je déciderais de lui donner une largeur fixe plus tard. Ton idée est probablement bonne et déjà utilisée par plusieurs, mais encore faut-il savoir où on doit s'arrêter dans nos prévisions de changement de design.