Eviter les <div> à tout prix ?

Bonjour,

Je sais qu'il est préférable d'éviter la multiplication des <div></div> et ça va de soi.
Mais faut-il tendre vers une suppression totale des <div></div> ?
Par exemple, pour un pied de page qui n'est qu'une liste, vaut-il mieux faire :

<div>
<ul>
<li>tralala</li>
<li>tralala</li>
<li>tralala</li>
</ul
</div>

ou

<ul>
<li>tralala</li>
<li>tralala</li>
<li>tralala</li>
</ul

Pourquoi ?
Modifié par pan (01 Mar 2010 - 13:50)

Bonjour,

pan a écrit :
Mais faut-il tendre vers une suppression totale des <div></div> ?

Si c'était le cas, l'élément div n'existerais pas... Vouloir lutter contre la divite aiguë est louable, mais vouloir anéantir tous les div c'est de l'extremisme. Et l'extremisme c'est malsain !

Pour ton exemple, il n'y a pas de réponse, à part : cela dépends. Cela dépends des éléments de décoration qui doivent être attribués à ce footer ; cela dépends de si, dans le futur, on compte rajouter des éléments dans le footer...

Si le stylage du footer consiste simplement en une couleur de fond et une largeur, la solution sans div est effectivement la plus light et donc, d'un point de vue performance et optimisation, la meilleure. Mais si doivent être attribués plusieurs fond (droite et gauche sur une taille variable par exemple), le recours au div sera tout à fait justifié.

Laurie-Anne a très bien résumé la situation.

Pour ma part, j'analyse la maquette et je retranscris le contenu dans les balises appropriées. Cela donne le code de base auquel j'ajoute si nécessaires des éléments me servant à la mise en forme.

A toi de voir si des containers supplémentaires ou génériques sont nécessaires à ta maquette comme l'ont dit Corinne et Laurie-Anne... dans l'absolu, c'est bien d'éviter la divite et la classite (autant être le plus léger possible), mais tomber dans la "divophobie", c'est pas une solution : c'est parfois bien utile d'avoir quelques éléments de structure supplémentaires : évolution, changements, etc.
Et tout simplement, des div sont tout simplement nécessaires à une bonne intégration dans certains cas !

Salut,

Personnellement je n'utilise de div que pour les grandes zones de ma page (éventuellement pour des besoins particulier pour le design mais généralement on arrive à se débrouiller sans). Quand je parle de zone, c'est lorsqu'elle contient différents éléments. Si c'est mettre un div pour entourer une seule liste non ordonnée, aucun intérêt. Par contre si cette div contient un titre, un paragraphe, et une liste alors là ca peut devenir intéressant.

Quoi qu'il en soit la structure de la page en zones marquées par des div identifiées permet de styliser en cascade en utilisant quasiment jamais aucune classe, et ça pour un code propre c'est super !

Bonjour,

Pour ma part, j'utilise systématiquement des div pour définir toutes les zones importantes de l'interface : le conteneur principal, l'entête, le menu, le corps, le pied de page et tout autre élément pertinent.

Par exemple, même si je peux coder mon menu de cette façon :

<ul id="menu">
	<li>Élément 1</li>
	<li>Élément 2</li>
</ul>

Je préfère le faire comme ceci :

<div id="menu">
<ul>
	<li>Élément 1</li>
	<li>Élément 2</li>
</ul>
</div>

Les avantages que je vois :
- D'un site à l'autre, mon code possède presque toujours la même structure pour les différentes zones, peu importe les besoins au niveau des styles CSS.
- Le code me semble plus facile à consulter, car toutes les zones importantes sont divisées de la même manière, c'est-à-dire avec un div doté d'un id explicite.
- Pour le passage à HTML5, la transformation risque d'être beaucoup plus aisée au niveau des sélecteurs CSS et du repérage des zones à remplacer.
- Si je dois apporter des changements au design, comme l'ajout d'un fond supplémentaire au pied de page ou au menu, ou encore si je dois jouer avec les marges ou le padding, j'ai toujours un div auquel je peux m'accrocher.
Modifié par Tony Monast (01 Mar 2010 - 17:57)

Vous savez que c'est une question dénuée d'importance ?

Bon, quand un outil ne peut pas dire "maman" dans chaque contenu du site sans coder inutilement 4 DIV et 5 SPAN imbriqués au cas où il y aurait à l'avenir des coins arrondis extensibles et compatibles IE-chose, ou encore un tableau de mise en forme (plus de 250 dans une page d'accueil un jour, chacun mono-cellulaire), je veux bien...

Mais pas là.

<edit>surtout que le menu de pied de page, comme il est presque toujours "inline", un grand vieux paragraphe le fait très bien </>

Plus sérieusement: vous cherchez des critères de qualité là où ils ne sont ni vérifiables ni universels.
Modifié par Laurent Denis (01 Mar 2010 - 18:40)

Laurent Denis a écrit :
Vous savez que c'est une question dénuée d'importance ?

Oui, je le sais. Ça n'empêche pas que c'est intéressant d'obtenir le point de vue des autres et en apprendre sur leur façon de faire, et les raisons qui les pousse à le faire de cette façon.

Laurent Denis a écrit :

Plus sérieusement: vous cherchez des critères de qualité là où ils ne sont ni vérifiables ni universels.

De mon côté, je n'essayais pas de dire que ma méthode était universellement préférable à une autre, mais plutôt pour :
- démontrer qu'il y a aussi des avantages à définir toutes les zones avec des divs, sans que ce soit considéré comme de la divite aigu.
- qu'il n'y a pas qu'une seule et unique façon de faire en étant pas tout à fait du même avis que les intervenants précédents.
Modifié par Tony Monast (01 Mar 2010 - 23:01)

pan a écrit :
faut-il tendre vers une suppression totale des <div></div> ?

Non.

Parce que ça n'aurait aucun intérêt.

Ça dépend des contraintes du client, de son CMS/framework, de l'évolution prévue de son site, ...
Mais on peut très bien partir sur :

<ul id="footer">
<li>...</li>
</ul>

et avoir comme sélecteur de règle #footer et non pas ul#footer pour un jour pouvoir évoluer vers :

<div id="footer">
<ul>
<li>...</li>
</ul>
</div>

mais si l'intégrateur qui fait cette évolution est une autre personne, il va créer :

<div id="conteneur_footer">
<ul id="footer">
<li>...</li>
</ul>
</div>

parce que euh loi de Murphy ou celui qui reprend est un boulet ou le premier qui a créé le code brille par l'absence de ses commentaires dans le code ou le client a aucune guideline ...