Div de présentations?

Bonjour,

Nouveau ici je vous fais partager une réflexion, une interrogation.

On dit que les CSS servent à séparer la présentation du contenu qui est décrit par XHTML.

Or, avce les DIV, on ne fait pas que structurer des infos ayant un sens(ex un div article qui regroupe des titre et des paragraphes). On utilise aussi des DIV pour grouper des infos dans des colonnes, le header ou le footer.

Peut-on considérer celà comme de la structuration ou bien de la présentation?

Car dans tous les cas, mettre de tels div réduit l'indépendance du contenu et de la présentation. En effet, si je veux changer des éléments de colonne par exemple, je dois changer la structure XHTML.

Bref, que est l'avantage par rapport aux tableaux hormis le fait que ça utilise un peu moins de code et que c'set sémantiquement correct d'après les spécifications? Car on peut imaginer le rajout d'un attribut à la balise table par le W3C qui indiquerait que celle-ci est sans valeur sémantique et on aurait alors un code sémantiquement correct non?

Je vous laisse la parole.

J'ai lu les specs CSS 3. Apparemment ils ont un module pour le layout qui semble réellement effectuer la séparation de celui-ci de la structure.

Serait-ce donc une limitation des versions actuelles de CSS?

Ah... la vieille quête du Graal, la fameuse structure XHTML minimale et sémantique, tout en étant stylable à volonté...

A l'usage, bof, bof bof.

Anticiper les besoins de présentation via des regroupements div (mais aussi d'autres besoins de script, etc) est un travail délicat mais nécessaire. Et qui n'a, surtout, rien de probléamatique ni d'incompatible avec la séparation structure/présentation. si si.

Sinon, pour CSS3, voir simplement l'historique de statut de chaque module : certains sont de simples conjectures qui n'aboutiront jamais, d'autres sont quasi-finalisés.

Et oui, CSS2.1 est un outil très limité, ce qui n'empêche pas 8O% du Web d'avoir déjà beaucoup de mal à l'utiliser en sous-régime...
Modifié par Laurent Denis (15 May 2007 - 21:57)

NOn je disais ça car lorsque on lis les arguments en faveur de l'usage des CSS, on dit partout que c'est pour une séparation contenu-présentation.

Sinon pour en revenir aux tables. En quoi des DIV sont-ils mieux pour un layout en colonnes que des TABLES hormis le fait que les DIV sont sémantiquement corrects(puisque nuls)?

Tout d'accord avec Laurent.

Laissons de côté la recherche effrénée du sémantiquement correct. À ma connaissance, les div sont considérés comme non porteurs d'information par les agents utilisateurs, et sauf peut-être dans le cadre des micro-formats, je ne connais pas d'outil cherchant à analyser les div d'un document web pour en tirer une information sur la structure sémantique du document.

La structuration sémantique, en HTML, se ferait plutôt via les titres de section h1, h2, etc. Cette structuration là est d'ailleurs exploitée par certains agents utilisateurs (les lecteurs d'écran, par exemple).

Pour ce qui est de la problématique de la séparation de la structure et de la mise en forme, qui impacte essentiellement la conception technique et la maintenance, la multiplication des div pour la mise en forme est effectivement un accroc à cette séparation, et peut à la rigueur poser des problèmes pour la maintenance et les ajustements éventuels des styles.

Pour un site en HTML statique, ça peut effectivement être problématique. Certains changements de mise en forme imposeront non pas uniquement une modification des CSS, mais aussi une modification du code HTML de chaque page concernée.

Pour un site dynamique il suffira le plus souvent, en plus de la modification de la feuille de style, de modifier un gabarit (ou template). Pour le coup, c'est assez souple.

Dans les deux cas ci-dessus, on retrouve effectivement une contrainte existant déjà avec les tableaux de mise en page. Les CSS permettent de faciliter les modifications de mise en forme sans modification du code HTML, mais ne permettent pas pour autant des modifications de mise en forme sans limites.

La grande différence est que les tables ont un sens : presenter des données tabulaires, alors que les div n'ont aucun sens ils servent juste à regrouper par blocs. Donc avec les div tu n'envois pas une fausse information au navigateur, ou au programme qui explore ton site.

Ce sont juste des balises qui servent de repéres, il n'y a aucune limitation a leur utlisation, ce sont de simple repére de mise en page et c'est même mieux de les utliser si c'est pour rajouter des blocs qui ont un sens uniquement graphique, plutot que de se casser la tête inutilement a tout faire rentrer dans sans balise extra. Par exemple pour un menu tu peux trés bien utliser la balise ul pour styler l'ensemble sans rajouter de div, mais si tu fais une colone avec un menu et des banners, à ce moment là tu regroupes les deux dans un div "left".

Au contraire si tu fais un tableau, on vat comprendre que les deux éléments de ta colone ont un lien parceque qu'ils sont dans le même tableau, et pire si ce tableau là est lui même dans un tableau plus grand, et je encore pire si ton menu et lui même un tableau...

La différence est donc énorme...

Chandy a écrit :
NOn je disais ça car lorsque on lis les arguments en faveur de l'usage des CSS, on dit partout que c'est pour une séparation contenu-présentation.

Pour être plus clair : c'est une plus grande séparation entre contenu et présentation, mais pas une séparation absolue.

De plus, tu prends l'exemple d'une structuration avec un tableau de mise en forme. Mais même si tu utilises ce tableau de mise en forme, tu vas probablement utiliser des styles CSS pour gérer les marges et retraits, la mise en forme du texte, les couleurs et images de fond, non ? Pour tous ces aspects, tu auras bien une séparation contenu/présentation effective.

Chandy a écrit :
Sinon pour en revenir aux tables. En quoi des DIV sont-ils mieux pour un layout en colonnes que des TABLES hormis le fait que les DIV sont sémantiquement corrects(puisque nuls)?

Attention aux confusions. Les div ne sont pas « sémantiquement corrects », mais plutôt « sémantiquement négligeables ». La spécification HTML 4.01 décrit l'élément div comme un support pour les styles (CSS) et les informations de langue (attribut HTML lang). Et pas, si je ne m'abuse, comme une « unité de sens ».

Au passage, dans certains cas un tableau sera plus adapté qu'une construction tarabiscotée en divs (et autres éléments HTML moins diabolisés que table).

Chandy a écrit :

Peut-on considérer celà comme de la structuration ou bien de la présentation?

Ni l'un ni l'autre, cela apporte de l'utilisabilité pour des déterminations liées (css, script)

a écrit :

En quoi des DIV sont-ils mieux pour un layout en colonnes que des TABLES hormis le fait que les DIV sont sémantiquement corrects(puisque nuls)?

2 choses :

. <div> n'attribut aucune signification déterminée à son contenu alors que <table> si.

. <div> n'est que neutre , en terme de détermination, mais pas complètement nul. A tout le moins cela signifie qu'un contenu de niveau block (plusieur <p> par exemple) va être regroupé dans un même conteneur. Du point de vue html ceci ne sert pour l'instant à rien (il ne s'agit encore une fois que d'utilisabilité ou de maniabilité) car tout est considéré comme étant suffisamment précisé par l'utilisation adéquate des en têtes de sections <hn>

Il semblerait bien que les évolutions futures des langages mettent en place des conteneurs de niveaux block intermédiaires permettant de limiter l'usage de <div>, je crois qu'il est question d'un <section> ou quelque chose comme ça. Les gourous t'en diront plus je pense.

matmat a écrit :
La grande différence est que les tables ont un sens : presenter des données tabulaires

C'est en tout cas la théorie.

Maintenant, pour la pratique :

matmat a écrit :
La différence est donc énorme...

La différence serait à vérifier dans les faits.

Pour quel utilisateur/avec quel outi/pour quel usage la différence se fait-elle sentir ?

Disons que je veux créer un conteneur tout bête pour mettre en forme un ensemble d'éléments, par exemple pour leur rajouter un cadre. Je peux écrire :

<div id="mes-elements"> ... bla bla bla mes éléments à grouper ... </div>

ou bien encore :

<table id="mes-elements"><tr><td> ... bla bla bla mes éléments à grouper ... </td></tr></table>

Quels sont les problèmes que l'on rencontrera dans le deuxième cas ?

Chandy a écrit :
En quoi des DIV sont-ils mieux pour un layout en colonnes que des TABLES hormis le fait que les DIV sont sémantiquement corrects(puisque nuls)?

Une gestion transparente de la linéarisation, c'est tout.

Du moins... jusqu'à ce que suffisamment de navigateurs implémentent le display:table, et que l'on voit alors de vieux problèmes oubliés resurgir

Bonsoir,

Laurent Denis a écrit :
Du moins... jusqu'à ce que suffisamment de navigateurs implémentent le display:table, et que l'on voit alors de vieux problèmes oubliés resurgir

Peux-tu développer, s'il te plaît ? Ca semble intéressant, mais j'avoue que je ne vois pas du tout où tu veux en venir.

<edit>Ah si. Mais bon, on peut déjà créer ce genre de problèmes en sortant les éléments du flux, non ?
Modifié par Julien Royer (16 May 2007 - 00:23)

Christian Le Bouler a écrit :

. <div> n'attribut aucune signification déterminée à son contenu alors que <table> si.
.

Oui mais ça c'set qu'une question de spécifications. Changeons la spécification éventuellement via l'ajout d'un attribut ou une balise au comportement identique à TABLE mais intitulée LAYOUT et le problème est contourné.

Chandy a écrit :
ou une balise au comportement identique à TABLE

Qu'est ce que tu appelle comportement ? S'il s'agit de rendu css media screen alors cela ne concerne en rien les balises mais seulement les css pour ce type de media.

La balise <table> induit que le contenu concerné doit être appréhendé (et pas seulement visualisé ou gniagniagni gniagniagnia) de manière vectorisée et c'est la seule balise qui induise cela.
Modifié par Christian Le Bouler (15 May 2007 - 23:18)

a écrit :
Oui mais ça c'set qu'une question de spécifications. Changeons la spécification éventuellement via l'ajout d'un attribut ou une balise au comportement identique à TABLE mais intitulée LAYOUT et le problème est contourné.

ça c'est sur pourquoi faire simple quand on peut faire trés compliqué...

Quel est le probléme à contourner?

Chandy a écrit :
Je vois pas trop l'avantage de structurer un header-3 colonnes-footer avec des div car il me semble qu'hormis quelques balises en plus, c'set pas mieux qu'avec des tableaux. Je suis pas un expert, je vous donne mon point de vue extérieur.

Disons qu'avec des div tu auras un peu plus de libertés de mise en forme, mais effectivement pas énormément plus. À toi de faire tes choix.

Chandy a écrit :
Pourquoi des tableaux? Pour pallier aux limitations d'implémentation des CSS ds les navigateurs, notamment IE ou encore les anciennes versions dont l'usage est plus répendu d'après mes stats que les navigateurs textes ou autres navigateurs alternatifs.

L'utilisation de tableaux permet effectivement de pallier certaines limites. Ces limites d'implémentations ne sont toutefois pas si énormes que ça, et ne doivent pas être exagérées outre mesure.

Chandy a écrit :
Alors svt on me réponds que c'set pas bon du point de vue de la sémantique

L'argument me semble effectivement faible, à partir du moment où on évite les écueils que représentent les multiples tableaux imbriqués et surtout les tableaux non linéarisables.

Chandy a écrit :
Il me semble qu'on pourrait contourner ce problème en changeant un peu les specs quitte à rajouter un attribut à TABLE.

Qu'est-ce qui prendra le plus de temps :
- un support relativement complet de CSS 2.1 dans les dernières versions des navigateurs ?
- un support des «tableaux de mise en forme» introduits dans une hypothétique norme HTML 4.1 ou HTML 5 ?

De plus, ce n'est pas à la spécification de s'adapter à tes choix de conception, mais plutôt à toi de faire ces choix... et de les assumer.

Chandy a écrit :
mais en attendant, lorsque on veut utiliser une grille pour mettre en page, utiliser un élément qui permet de créer des colonnes et cellules me semble bien plus approprié que des DIV

Pour moi, c'est un non-débat. Déjà, tout design n'est pas fait en fonction d'une « grille » ou sous la forme d'un « découpage ». Voir par exemple l'article suivant :
http://blog.alsacreations.com/2007/04/07/344-demarche-integration-html-css

Ensuite, si ton design est basé sur un ensemble d'éléments qui doivent être disposés en une grille (et donc avoir les propriétés de cellules de tableaux), tu as trois possibilités :
- utiliser des div et le positionnement CSS à base de flottants, de positionnement absolu, etc., pour « simuler » les propriétés d'une grille (voir par exemple la technique des colonnes factices) ;
- utiliser display: table, display: table-cell, etc. ;
- utiliser un tableau de mise en forme.
Chaque possibilité a ses avantages et inconvénients (display: table en a un pour ainsi dire rédhibitoire : pas de support dans IE). À toi de les identifier, puis de faire tes choix et de les assumer.

Oki merci Florent V pour tes éclaircissements.

Bonjour

a écrit :

Chandy a écrit :
Je vois pas trop l'avantage de structurer un header-3 colonnes-footer avec des div car il me semble qu'hormis quelques balises en plus, c'set pas mieux qu'avec des tableaux. Je suis pas un expert, je vous donne mon point de vue extérieur.

a écrit :

Florent V. a écrit :
Disons qu'avec des div tu auras un peu plus de libertés de mise en forme, mais effectivement pas énormément plus. À toi de faire tes choix.

<div> ne dit pas exactement la même chose que <table>, et donc comparer l'un et l'autre en terme d'efficacité (technique, économique, etc.) n'est pas nécessairement la bonne démarche.
Dans un usage de mise en page globale (layout), <table> induit un travail de présentation. Ça implique que le contenu est initialement pensé comme "quelque chose à montrer" via un outil capable de le faire.
<div> ne fait rien d'autre que créer des divisions du contenu en unités cohérentes. Qu'ensuite on profite de ces <div> qui "séquencent" (voir cette discussion) le contenu du document pour les mettre en forme via CSS ou interagir via JS ne relève pas de la même approche.
Dans un cas on présuppose l'existence d'outils/agents utilisateurs capables de reconstituer ce qu'on imagine au départ (en gros la mise en page finale), dans l'autre on s'en affranchit.
Les tables ne sont pas à diaboliser au nom de l'accessibilité mais à considérer comme une forme possible de remplacement des <div> si ces dernières sont effectivement considérées et utilisées comme vecteurs de mise en forme/mise en page. Si l'on considère en revanche les <div> comme des balises-outils de séquençages, la question de comparer les unes et les autres n'a pas beaucoup de sens.
Modifié par Arsene (17 May 2007 - 14:48)

Oui Arsène mais justement j'évoquais DIV par rapport aux TABLES dans le cas ou les DIV n'encadrent non pas des unités ayant un sens mais bel et bien des éléments qui sont regroupés ensembles que dans un objectif de mise en page(ex pour des colonnes en CSS)

Si on ncapsule dans un DIV une liste de lien(menu), des liens partenaires et des images(pubs), c'set svt dans un objectif de mise en page.
Modifié par Chandy (17 May 2007 - 19:00)

Au fait, quelqu'un a-t-il un exemple de navigateur pour mobile/pda où un layout tableau est illisible?

Je viens de tester sur Opéra Mobile et le contenu est aussi bien rendu avce une mise en page via tableaux ou DIV, du moment que le contenu est linéarisé bien sur.
Modifié par Chandy (23 May 2007 - 20:30)