Arguments pour convertir une personne aux DIV et SPAN au lieu de TABLE

loran750 · 11 Mai 2011

Bonjour,

Je voudrais convertir et convaincre un client d'oublier les tables, et de se baser dans son développement sur du code HTML bien comme il faut.
En d'autres termes : qu'il arrête de faire des tableaux ou de composer sa page avec des <TABLE>.

Auriez-vous des arguments forts pour qu'il oublie définitivement les TABLEs ?

cdt
loran

Marie-Aude · 11 Mai 2011

"Non"

Si il n'est pas convaincu par l'immense facilité de développement et de mise à jour, et que c'est lui qui code, tu n'y peux rien.

Regarde Zecat... toujours full table

loran750 · 11 Mai 2011

oui Marie-Aude, mais tu as vu l'âge de Zecat ? Etonnant qu'il se soit habitué au clavier des ordinateurs... mais il a encore le tic de renvoyer vers la gauche le

Zecat, pas taper :mrgreen: :mrgreen: :mrgreen: :mrgreen:

En fait, je pensais essentiellement à la problématique d'avoir une page qui s'affiche de manière unique sur tous les navigateurs (IE7+, FF3.5+, C8+ au moins). On a toujours eu la question "et sur firefox/internet explorer, ça va ?".
Et donc l'impact sur la charge de travail pour valider et adapter éventuellement les pages en old HTML ("HTML legacy").

Marie-Aude · 11 Mai 2011

Simplement sur cet aspect là, ça ne suffit pas. En div il y a aussi des différences légères d'affichage.

Mais en revanche, c'est surtout :
- clarté / lisibilité du code
- meilleure gestion des affichages taille variable par redimensionnement des divs
- plus facile à maintenir une fois que tu as compris
- possibilité d'utiliser les float pour éviter les zones vides que peuvent générer des tables

Zecat · 11 Mai 2011

Je suis d'accord sur le fond. Rester en full table, c'est le mal mais bon la flemingite aidant ...

Sinon :

Marie-Aude a dit:
- clarté / lisibilité du code

$largeur="150";
$hauteur="230";
$icone="picto_alerte.png";
$titre="Mon zouli titre";
$content=$varavecpleindetrucfaitenamont;
include("Ze_cadre_standard_je_veux_pas-savoir-tu-te-demerdes.php");

C'est pas la panacée mais ca rend la chose lisible et facile a modifier partout sur le site ...

Marie-Aude a dit:
- meilleure gestion des affichages taille variable par redimensionnement des divs

Cf au dessus :
$largeur="150";
$hauteur="230";

Marie-Aude a dit:
- plus facile à maintenir une fois que tu as compris

include("Ze_cadre_standard_je_veux_pas-savoir.php");
un script a regarder ... pas très compliqué ...

Marie-Aude a dit:
- possibilité d'utiliser les float pour éviter les zones vides que peuvent générer des tables

Cf au dessus :
$largeur="150";
$hauteur="230";

Exemple : les 4 cadres rubriques, a savoir, actu et derniers ... sur la home de mon www, fait juste avec 4 appels de include("Ze_cadre_standard_je_veux_pas-savoir.php");

Debug : facstoche
standardisation : impec

:mrgreen:

Edit : j'ai oublié :

$croll="";
ou
"x" ou "y" ou "xy" :wink:

boby55 · 11 Mai 2011

Je raconte mon expérience personnelle :

Un jour je me suis dis mais pourquoi toujours des <TABLE>, je vais essayer de faire propre avec des <DIV>. Là, tout content, je commence à mettre les mains dans le cambouis et tout ce passe bien a 95%, mais pour les 5% restant cela devient infernal.

Quand on affiche des données sous forme simple, par exemple 4 blocs sur chaque ligne tout va bien, mais quand sur une ligne tu as besoin d'un affichage spécial les problèmes se posent.

Au final, professionnellement (Création de sites de Back Office) je suis resté aux <TABLE> car niveau temps de production et facilité de maintenance il n'y a pas photo.

Chaque collègue rencontré depuis a eu le même parcours, chacun à essayé FULL <DIV>, a sué, pleuré, et est revenu aux <TABLE>.

:wink:

Dolph · 11 Mai 2011

Parfois, faut savoir se passer de client comme celui-ci.

Zecat · 11 Mai 2011

boby55 a dit:
Chaque collègue rencontré depuis a eu le même parcours, chacun à essayé FULL <DIV>, a sué, pleuré, et est revenu aux <TABLE>.

:wink:

Finalement j'ai economisé un aller retour suage, pleurage :mrgreen:

Robinson · 11 Mai 2011

L'usage des tables ponctuellement, aucun soucis, ça m'arrive, surtout pour faire un simple tableau ^^

Mais tout développer en table, non merci, je ne ferai jamais ce retour en arrière ^^

loran750 · 11 Mai 2011

Dolph : non non... je ne suis pas au point de pouvoir me passer de client. En plus, ce client est très important pour moi !

Zecat & boby55 : Je partage bien votre point de vue. Les tables c'est facile et comment dire ... naturel et direct.

Marie-Aude : je vais quand même tenter de vanter les mérites du passage au div, on va tester un peu. Mais si c'est au détriment de l'efficacité, on reviendra sur nos pas. Comme me le dit un collègue : "Pourquoi tu n'en profites pas pour apprendre les nouveaux outils qu'on te met à disposition ?" j'ai répondu : "j'ai pas le temps de m'amuser, je travaille *"

* bon c'est pas une excuse mais quand on a vraiment pas le temps et que le temps est compté ...

Marie-Aude · 11 Mai 2011

@Zecat, un jour tu découvriras les em et la mise en page fluide

@boby55 le full table est tout aussi idiot que le full div. Il y a des cas où il faut utiliser des tables. Une admin de site fait souvent partie de ces cas (listes de posts, d'options, etc....) les tables ne sont pas "le mal", elles le sont quand on imbrique 9 cases pour faire une bordure à coins arrondis

UsagiYojimbo · 11 Mai 2011

Pas mieux. Rien que pour la lourdeur du code généré et sa lisibilité, ça vaut de se prendre légèrement plus la tête.

boby55 · 11 Mai 2011

Marie-Aude a dit:
@boby55 le full table est tout aussi idiot que le full div. Il y a des cas où il faut utiliser des tables. Une admin de site fait souvent partie de ces cas (listes de posts, d'options, etc....) les tables ne sont pas "le mal", elles le sont quand on imbrique 9 cases pour faire une bordure à coins arrondis

Personnellement je fais MIXTE : <TABLE> et <DIV>, je ne prône nullement le FULLTABLE :mrgreen:

Pour être poète, je dirais que dans la vie rien n'est tout blanc ou tout noir (Voir Mickaël Jackson :roll

spout · 11 Mai 2011

Une présentation qui date déjà: http://www.hotdesign.com/seybold/
Il y a une version traduite en FR aussi.

Zecat · 11 Mai 2011

UsagiYojimbo a dit:
Pas mieux. Rien que pour la lourdeur du code généré et sa lisibilité, ça vaut de se prendre légèrement plus la tête.

Lisibilité pour qui ? pour celui qui affiche le source ? rien a battre ...
Lisibilité pour moi ? parfaitement lisible avce les includes de "boites noires"
Lourdeur ; j'ai pas été revoir mais la derniere fois GWT me disait en moyenne 1,1 s et plus rapide que 84 % des sites je crois (je suis sur un mutu banal) ... donc a relativiser ...

Une chose est sure, je le concède : travailler efficaement avec les tables et td implique un peu de bouteille et une approche tres organisée et flemmarde du codage ... si on part la fleur au fusil ca devient vite un joyeux foutware ... . Mais quant on est rodé, ca roule tout seul et la productivité est maxi ...

Zecat · 11 Mai 2011

Marie-Aude a dit:
@Zecat, un jour tu découvriras les em et la mise en page fluide

Ca sera pas avant 2012 :mrgreen: Pour 2011 j'ai epuisé mon "capital neurones" avec php, mysql, jquery et les css ! Halte aux cadences infernales :mrgreen:

spout · 11 Mai 2011

Ça fait des années que je me bat sur WRI contre les sites full tables...
Maintenant avec les grid, cela n'a jamais été aussi simple: http://960.gs/demo.html

Marie-Aude · 11 Mai 2011

Et puis ça dépend aussi des mises en page.. les tiennes restent assez simples

Zecat · 11 Mai 2011

Marie-Aude a dit:
Et puis ça dépend aussi des mises en page.. les tiennes restent assez simples

Un truc compliqué n'étant jamais qu'une succession de trucs simples :wink: C'est vrai en toutes choses ... Et puis "simple, c'ets relatif ... regarde le forum de qlm en full table : il a rien a envier aux standards du marché ...

Blount · 11 Mai 2011

@Zecat : je suis désolé, mais l'argument « j'ai la flemme », tu peux le ranger. La flemme de quoi ? D'apprendre, « d'innover » (dans le sens, faire autrement qu'avant), dans ce cas, on fout tout les langages de programmation au placard et on revient à l'assembleur

(bon j'exagère légèrement).

Les tableaux sont à utiliser, mais à utiliser correctement. En claire, pour tout ce qui est affichage de données tabulaires (tout ce que tu pourrais mettre dans un tableur), il faut user des tableaux, ce qui est normal.

Une fois que tu as compris les bases, qui se réduit à utiliser du CSS (width, margin et float principalement), tu as tout à y gagner.

Site 2 colonnes :

Code:

<div style="width: 900px; margin: 0 auto;">
    <div style="margin-bottom: 15px;">entête</div>
    <div style="float: left; width: 750px;">contenu principal à gauche</div>
    <div style="float: right; width: 125px;">menu à droite</div>
    <div style="margin-top: 15px; clear: both;">pied de page</div>
</div>

Et ta structure principale est prête. Bien entendu, on placera le CSS à l'extérieur du HTML (là, c'est un exemple), ce qui allège le HTML et la bande passante si le cache est bien configuré.
Maintenant, je ne dis pas qu'il n'y a pas d'inconvénients.

Le truc pratique, c'est que si tu décides par exemple de mettre le menu à gauche, il suffit d'inverser les valeurs de « float », pas besoin de toucher à l'HTML. On peut même imaginer permettre à l'utilisateur de choisir sa position lui-même ^^.

Marie-Aude · 11 Mai 2011

C'est bien ce que j'appelle une mise en page "simple"

@boby55 moi je fais partie des gens qui ne sont JAMAIS retournés aux tables

Zecat · 11 Mai 2011

On peut faire la meme chose avec les tables ... deux includes a inverser ... et la aussi on peut donner cette option a l'utilisateur. La limitation n'est a mon avis pas fonctionnelle.

Je m'étais meme amusé mais pa smis en prod ... à coller un slider a coté d'un tableau et on reglait sa hauteur et donc celle du dessous selon la position du slider ... ca tenanit en 5 lignes de code ... Donc l'argument tu peux pas faire ... pour le moment j'ai pas rencontré de blocages (en fait je fait l effort d'apprendre un truc que si vraiment je suis coincé ... cf mysql Vs .txt, etc ... mais pour le moment je n'ai pas encore été en position de me dire zut je peux pas avec les tables ...

Ca viendra surement un jour ...

Zecat · 11 Mai 2011

Blount a dit:
@Zecat : je suis désolé, mais l'argument « j'ai la flemme », tu peux le ranger. La flemme de quoi ? D'apprendre, « d'innover » (dans le sens, faire autrement qu'avant), dans ce cas, on fout tout les langages de programmation au placard et on revient à l'assembleur (bon j'exagère légèrement).

Hum .. le bon temps des 24 k de mémoire centrale (et des grosses gamelles multiplateau de 5 Mo) ... boosté à 48k pour les riches :mrgreen:

CARREZ · 11 Mai 2011

Sujet intéressant ...

Le "full quoi que ce soit" est effectivement une bétise de puriste. Un client qui dis ça déjà n'a pas tout compris ...
Utiliser une table quand on a besoin d'afficher une table c'est logique, pratique et pas du tout contre productif. Notamment dans un backoffice ...

A mon avis l'argument pour passer aux div c'est la maniabilité des blocs grâce au CSS. Un table reste une table avec des limites à chaque table, à chaque ligne, à chaque cellule. Les div permettent tout de même beaucoup plus de possibilités graphiques.

Côté qualité du code source je parlerais de légéreté plutôt que de lisibilité. Le commun des mortels se fout effectivement de lire un code html, tant qu'il se charge ! A quantité de code égale on peut afficher plus de choses avec des div qu'avec des table il me semble ...

Dernier point, les div permettent aussi, encore grâce au CSS, d'afficher un site différemennt en fontion du média. Pour faire une mise en page spécifique pour l'impression avec des tables ça peut être beaucoup plus compliqué qu'avec des div. Idem pour les mobiles, les cellules d'une table restent les unes à cpôté des autres, des div peuvent être disposées verticalement sur mobile et horizontalement sur les autres média.

Après si il veux pas, il veux pas, tant pis pour lui ;-p

YoyoS · 11 Mai 2011

Parait que des benchmarks ont été fait et des chartes graphiques de sites en <div> s'affichent plus rapidement que celles de sites en <table>. Consomment moins d'CPU

JanoLapin · 11 Mai 2011

spout a dit:
Une présentation qui date déjà: http://www.hotdesign.com/seybold/
Il y a une version traduite en FR aussi.

la voici:
http://www.hotdesign.com/seybold/french/index.html

Marie-Aude · 11 Mai 2011

CARREZ a dit:
Dernier point, les div permettent aussi, encore grâce au CSS, d'afficher un site différemennt en fontion du média. Pour faire une mise en page spécifique pour l'impression avec des tables ça peut être beaucoup plus compliqué qu'avec des div. Idem pour les mobiles, les cellules d'une table restent les unes à cpôté des autres, des div peuvent être disposées verticalement sur mobile et horizontalement sur les autres média.

Excellent argument

loran750 · 11 Mai 2011

nan di diou spout & JanoLapin !
Voilà exactement ce qu'il fallait ! Une présentation claire et synthétique. Merci !

Zecat · 11 Mai 2011

YoyoS a dit:
Parait que des benchmarks ont été fait et des chartes graphiques de sites en <div> s'affichent plus rapidement que celles de sites en <table>. Consomment moins d'CPU

Je n'en disconviens pas mais c'ets pas decisif pour changer d'approche ... que mes pages s'affichent en 0,8 au lieu de 1,1 ... c'ets joli sur le papier mais au quotidien, ca change rien d'aller plus vite que deja vite :wink:

Parce que dans tout ce debat on perd de vue l'utilisateur du site ... qui lui se contrefout de ce qu'il y a sous le capot : il ne s'interesse que a ce qu'il a sous les yeux ... donc c'est vraiment un debat qui a cet égard est secondaire pour moi.

HawkEye · 12 Mai 2011

boby55 a dit:
Chaque collègue rencontré depuis a eu le même parcours, chacun à essayé FULL <DIV>, a sué, pleuré, et est revenu aux <TABLE>.

Pourtant, franchement, backoffice ou pas, entre afficher en tables et en div c'est franchement en div que c'est le plus simple.
La difficulté, c'est de franchir un cap "psychologique" et "graphique", mais une fois que c'est fait, franchement, tu ne peux plus t'en détacher

JanoLapin · 12 Mai 2011

Pour faire avancer le débat entre les pour , les contres, et les ni pour ni contre bien au contraire, ce serait bien si quelqu'un avait un site de vraie vulgarisation sur la mise en page <div>, parce qu' ahma c'est là que àa pêche...

Zecat · 12 Mai 2011

HawkEye a dit:
boby55 a dit:

Chaque collègue rencontré depuis a eu le même parcours, chacun à essayé FULL <DIV>, a sué, pleuré, et est revenu aux <TABLE>.

Cliquez pour agrandir...

Pourtant, franchement, backoffice ou pas, entre afficher en tables et en div c'est franchement en div que c'est le plus simple.
La difficulté, c'est de franchir un cap "psychologique" et "graphique", mais une fois que c'est fait, franchement, tu ne peux plus t'en détacher

oui oui c est dans ma to do list de ... 2012 :mrgreen:

HawkEye · 12 Mai 2011

JanoLapin a dit:
Pour faire avancer le débat entre les pour , les contres, et les ni pour ni contre bien au contraire, ce serait bien si quelqu'un avait un site de vraie vulgarisation sur la mise en page <div>, parce qu' ahma c'est là que àa pêche...

> http://www.alsacreations.com/ What Else ?

JanoLapin · 12 Mai 2011

HawkEye a dit:
JanoLapin a dit:

Pour faire avancer le débat entre les pour , les contres, et les ni pour ni contre bien au contraire, ce serait bien si quelqu'un avait un site de vraie vulgarisation sur la mise en page <div>, parce qu' ahma c'est là que àa pêche...

Cliquez pour agrandir...

> http://www.alsacreations.com/ What Else ?

justement, c'est un peu ça le problème: il n 'y a pas de site passerelle pour apprendre à passer des tables aux div. Du coup on ne peut conseiller que des sites, fort bien fait au demeurant, (what else, tu as raison) qui repartent entièrement de zéro, ou du moins donnent cette impression. C'est assez décourageant...

Un peu comme un type habitué à conduire une voiture, qui souhaiterait passer à la camionnnette (non pas à la F1 :mrgreen: ) et à qui on dirait qu'il doit repasser son permis.

Pour les pros site de programmation web, il y a surement un créneau à prendre...

Blount · 12 Mai 2011

Je ne comprend pas le problème. Quand on passe des tableaux aux blocs « div », il n'y a rien à réapprendre. Bien sur, si tu ne connais pas le CSS, là oui, tu repars de zéro. Mais il en serait plus que temps

Dans pas longtemps, nous allons tous devoir réapprendre une nouvelle façon de faire en utilisant les nouvelles balises HTML5 (header, article, etc.). Mais là, c'est un changement un peu plus compliqué.

Seule la réponse à la question « comment faire pour avoir cet affichage ? » change. Au lieu d'avoir une vision de tableau, tu as une vision de bloc. Qui est en fin de compte pareil (les «td» passe en «div» auxquels tu appliques du CSS).

moira · 12 Mai 2011

Le passage au HTML5 est nettement plus facile que le passage Table -> Div.

D'un coté on a de la sémantique pure et de l'autre, on a (pour moi ;p) du bidouillage en terme de paramétrage des div où tu dois limite mesurer pour mettre au pixel près. Sans compter que c'est mal / pas supporté par les anciennes version des navigateurs et que malheureusement, quand tu fais du B2B, t'as plus souvent ces dinosaures que les plus récents !!

Personnellement, le CSS est très utile pour la mis en forme des éléments, mais pour la mise en page je galère. Et pourtant, j'ai de la bouteille !

spout · 12 Mai 2011

moira a dit:
Personnellement, le CSS est très utile pour la mis en forme des éléments, mais pour la mise en page je galère. Et pourtant, j'ai de la bouteille !

Il y a des grids CSS, c'est génial pour la synergie infographiste / intégrateur HTML/CSS.

fredfan · 12 Mai 2011

C'est bien les grids mais c'est quand même paradoxal de supprimer les tables pour les recréer en CSS
Malgré tous ses atouts, en particulier dans la simplification du code HTML, le CSS est quand même passé à côté d'instructions de positionnement efficaces et simples.

Blount · 12 Mai 2011

Le seul inconvénient pour moi est l'utilisation de « float » qui introduit des bugs d'affichage si c'est mal conçu.

Exemple :

Symptôme :
1 - bloc passe en dessous d'un autre

2 - le conteneur des blocs flottant perd sa hauteur.

Solution bug 1 :
La largeur totale des éléments fils ne doit pas dépasser la largeur du conteneur. Cela comprend : les marges, les paddings, les bordures et bien évidemment la largeur des blocs eux mêmes.
Si vous souhaitez une largeur de 150 pixel pour le menu par exemple, il faut déduire les autres valeurs. Si vous avez une bordure gauche de 1px, un padding droit et gauche de 10px, vous mettrez en « width » : 119px.

Solution bug 2 :
Il faut mettre un fils qui force le parent à reprendre son état normal, l'astuce est donc d'utiliser la propriété « clear » du CSS. J'ai pour cela l'habitude d'utiliser un span de cette ménière :

Code:

<span class="clear">&nbsp;</span>

Avec le CSS suivant :

Code:

span.clear {
    font-size: 1px;
    display: block;
    clear: both;
    visibility: hidden;
}

Une fois ces habitudes prises, c'est un jeu d'enfant

@fredfan : il ne faut pas confondre utilisation des balises <table> et la position en grid. Ce n'est pas du tout la même chose.

JanoLapin · 12 Mai 2011

@blount: tu vois que l'on peut expliquer clairement et de façon adaptée en quoi consiste le passage des <table> aux <div>. Mais aucun site ne fait cela vraiment: tous repartent de zéro, et tu te trouves devant une montagne...

Par ailleurs, j'ai commencé à regarder le html5, ça m'a l'air quand même nettement plus simple (je ne parle pas de css3)

Blount · 12 Mai 2011

J'essayerai de faire un article sur mon blog en reprenant mon poste précédent, ce sera plus adapté qu'ici

(en plus, ce n'est pas trop le sujet).

Pour le HTML5, ce qui me pose problème, c'est l'utilisation correcte des balises, je n'ai pas encore approfondi la chose.

Robinson · 12 Mai 2011

JanoLapin a dit:
@blount: tu vois que l'on peut expliquer clairement et de façon adaptée en quoi consiste le passage des <table> aux <div>. Mais aucun site ne fait cela vraiment: tous repartent de zéro, et tu te trouves devant une montagne...

Par ailleurs, j'ai commencé à regarder le html5, ça m'a l'air quand même nettement plus simple (je ne parle pas de css3)

Peut-être car il n'y a strictement aucun rapport entre div et table ? :roll:

Comment effectuer une transition entre deux éléments complètement différents ?

Il n'y a pas d'équivalents, c'est bien ça le gros bonus ! On cesse d'utiliser une architecture archaïque pour passer au modulaire qui ouvre de nouvelles portes.

JanoLapin · 12 Mai 2011

personellement, je me reconnais parfaitement dans les propos de moira.

en B2B, le full div c'est loin d'être toujours la panacée..

Blount · 12 Mai 2011

Juste pour mon ignorance, B2B veut dire ?

Zecat · 12 Mai 2011

Bord... de Bord.. :?: ok :arrow: :mrgreen:

boby55 · 12 Mai 2011

JanoLapin a dit:
personellement, je me reconnais parfaitement dans les propos de moira.

en B2B, le full div c'est loin d'être toujours la panacée..

+1 :roll:

(avec des clients sous IE6 surtout .. et oui ça existe encore :wink: )

spout · 12 Mai 2011

Blount a dit:
Juste pour mon ignorance, B2B veut dire ?

http://tinyurl.com/67t9lty :mrgreen:

Marie-Aude · 12 Mai 2011

J'ai un peu de mal à comprendre certaines choses...

Je crois qu'il ne faut pas confondre "le div" et "la créativité débordante du graphiste" ... et rajouter par dessus l'exigence de l'exactitude au pixel près par rapport à la création du graphiste dans tous les navigateurs.

A partir de ce moment là, il est parfaitement possible de faire des versions dégradées de façon acceptable sous IE6, avec les feuilles de styles conditionnelles, voir un chouia de tables conditionnelles dans le code (le site d'exemple de menus déroulants en css purement compatibles IE6 est une très bonne leçon pour ça)

Il est parfois un peu difficile de faire comprendre au client que "ses" clients (surtout en B2B) ne vont pas faire joujou à mettre le site dans plusieurs navigateurs. Il faut aussi lui faire comprendre qu'il ne maitrise pas la largeur d'affichage, la définition, chez son client final, pour arriver à des arrangements raisonnables

Sinon, il fait un site full flash, et basta

(ah non, il n'aura plus les mobiles...)

fredfan · 12 Mai 2011

Ca vaut le coup de passer tester http://www.csszengarden.com/tr/francais/ pour la liberté de présentation qu'apporte le CSS

nervusdm · 12 Mai 2011

Les tables et les div font tout deux parties des nos outils de progs. Il faut réussir à les utiliser les deux ;p sans être trop pro "l'un" ou "l'autre" !

Topsitemaker · 12 Mai 2011

Bonjour,

Je jongle entre les <table> et les <div>, les 2 sont essentiels à la bonne conception d'un site. c'est comme la guéguerre Windows, MAc et Linux tous les systèmes sont bons.

L'inconvénient du <div> c'est d'en connaitre le vocabulaire et la définitions exactes CSS (float, clear:both ... parmi les plus exotiques) pour design-er ce que l'on veut faire.

Le principal inconvénient du <table>, à mes yeux, c'est qu'un site conçu avec une table qui englobe toutes les parties du site, va s'afficher une fois que toutes les cellules de la table soient chargés. Donc on aura une impression que le site est lent car on remarquera ce temps d'arrêt du chargement provoqué par la table.

moira · 12 Mai 2011

B2B : Business To Business - Un professionnel qui s'adresse à un professionnel
Tu as aussi du B2C : Business To Customer et C2C (bon là, ca devrait aller ;p)

@marie-aude : je comprends tes arguments. Simplement, j'aime avoir en temps que société le même design partout (l'un de mes mots fétiches est homogénéité), et en temps que développeur, je n'ai pas envie 1) de me poser des questions sur les rustines à poser pour que le rendu soit identique partout 2) de devoir jouer du pixel à tâton pour positionner mes éléments.

Mais j'avoue qu'une fois le CSS maîtrisé parfaitement, ce doit être aussi rapide à intégrer dans les 2 cas (et certainement plus malléable en CSS).

cedric_g · 12 Mai 2011

Bonjour

Pour ma part j'ai "basculé" vers les DIV fin 2006, reléguant les tableaux... pour les données tabulaires (comme il se doit :twisted: )

À l'avantage des DIV :
- légèreté du code (je me souviens sur ma galerie photo, lors du passage TAB > DIV j'ai gagné en moyenne... 40% de poids au niveau des pages HTML !)
- maintenabilité
- souplesse (genre je veux basculer une sidebar de l'autre côté pour voir ce que ça fait... Un coup de CSS et hop !)
- accessibilité (et par ce biais... claire participation à l'optimisation technique pour le SEO car on peut grâce aux CSS faire "passer" le contenu au-dessus du reste dans le code

)
- souplesse pour le multi-supports (clients lourds, mobiles, iPad... mais aussi facilité de mise en oeuvre des feuilles de styles pour l'impression !)
- facilité d'ajustement et de mise au point en conception (merci Firebug :mrgreen: )
- dans une certaine mesure, séparation entre la sémantique/le fond (code xhtml) et la présentation/la forme (css) : on y sera pleinement avec HTML5

Après c'est pas non plus sorcier d'appréhender l'essentiel : padding, margin, float, clear (je résume !)

Parce que les DIV, finalement, leur difficulté de mise en oeuvre, c'est au niveau du CSS, pas du code de la page qu'on la retrouve et ce n'est pas plus mal

loran750 · 12 Mai 2011

@Marie-Aude, j'ai convaincu il y a longtemps mon infographiste d'utiliser Flash à outrance... ce n'est pas pour y revenir

tiens, par curiosité, je me demande comment les infographistes font pour découper une maquette photoshop en gabarit html/css.

Robinson · 12 Mai 2011

loran750 a dit:
@Marie-Aude, j'ai convaincu il y a longtemps mon infographiste d'utiliser Flash à outrance... ce n'est pas pour y revenir

tiens, par curiosité, je me demande comment les infographistes font pour découper une maquette photoshop en gabarit html/css.

C'est le boulot le plus détestable qui soit :lol:
Il devient d'ailleurs très difficile de trouver des personnes pour réaliser cela ^^

Mais il y a de bons outils qui aident grandement (mais excusez je n'ai plus le nom en tête).

fredfan · 12 Mai 2011

Robinson a dit:
Mais il y a de bons outils qui aident grandement (mais excusez je n'ai plus le nom en tête).

Si ça te revient ça m'intéresse

Leonick · 12 Mai 2011

Blount a dit:
J'ai pour cela l'habitude d'utiliser un span de cette manière :

Code:

<span class="clear"> </span>

plutôt que d'utiliser

Code:

<span class="clear">&nbsp;</span>

autant utiliser

Code:

<hr class="clear" />

c'est plus concis.
Sinon, pour en revenir à l'utilité des div vs table : dans une galerie photos, tu peux ajuster le nombre de photos par ligne par rapport à la largeur utile du navigateur, avec des float. Ca évite, par exemple, d'avoir des ascenseurs horizontaux

spout · 12 Mai 2011

Leonick a dit:
Sinon, pour en revenir à l'utilité des div vs table : dans une galerie photos, tu peux ajuster le nombre de photos par ligne par rapport à la largeur utile du navigateur, avec des float. Ca évite, par exemple, d'avoir des ascenseurs horizontaux

Ho oui c'est bien vrai ! float left + width en % et on peut ajuster le nombre de colonnes en CSS, tandis qu'avec des tables tu dois modifier ton code HTML/PHP modulo machin

Marie-Aude · 12 Mai 2011

Il y a quand même l'outil tranche pour cela,

Personnellement, je fais le boulot moi même, en ayant les fichiers PSD "avec toutes les couches, tout, tout, tout" (y compris les fonts, les motifs, etc) car le découpage dépend trop de la façon de créer le style.

Récemment je suis intervenue sur un site en hauteur fixe, avec "tout" en image de fond (-http://nierada-marketing.de), pour intégrer le blog (pas encore en ligne). J'ai transformé pas mal d'images (cadres, bandes, etc.) en simples bordures sous css, avec une feuille de style alternative pour IE "avant css3", c'est plus léger, plus facile à maintenir, et beaucoup plus fluide, notamment en hauteur.
Si j'avais dû garder les images de fonds, c'était déjà nettement plus de code, et je ne l'imagine pas en tables.

@moira il y a plusieurs choses différentes. L'homogénéité du design est une chose. Elle se joue autant sur le web que sur le print. Or malheureusement, quels que soient tes efforts, tu ne pourras jamais maitriser le calibrage de l'écran du visiteur. Entre une homogénéité et une identité totale entre deux navigateurs (qui prend la peine d'afficher côte à côte sur le même écran la même page d'un site sous deux navigateurs différents pour pointer les différences ?) il y a une énorme différence, aussi en termes d'efforts.
Fais tu en sorte que les boutons submit, les ascendeurs dans les zones de texte, soient identiques entre IE, FF, Opéra et Safari ? (par exemple... parmi d'autres).
Par ailleurs, c'est pour les tables comme pour les div, quand tu connais ton outil, tu ne tâtonnes pas au pixel près. Quand je tâtonne, c'est parce que j'ai la flemme de prendre ma calculette pour préparer mon modèle de boîte

. C'est réellement une question de temps d'apprentissage.
J'ai fait mon tout premier site en tables, sans vraiment maîtriser.
Prise d'un élan suicidaire, j'ai décidé d'en faire la v2 en div.
J'ai ai passé trois semaines de nuits blanches. Mais j'ai oublié ce que c'est qu'un gif d'espacement

j'aime avoir en temps que société le même design partout (l'un de mes mots fétiches est homogénéité), et en temps que développeur, je n'ai pas envie 1) de me poser des questions sur les rustines à poser pour que le rendu soit identique partout 2) de devoir jouer du pixel à tâton pour positionner mes éléments.

Blount · 12 Mai 2011

loran750 a dit:
@Marie-Aude, j'ai convaincu il y a longtemps mon infographiste d'utiliser Flash à outrance... ce n'est pas pour y revenir

tiens, par curiosité, je me demande comment les infographistes font pour découper une maquette photoshop en gabarit html/css.

C'est de l'intégration. Et comme le dit Marie-Aude, avec les sources graphiques, ça va tout seul. Je ne suis pas infographiste (pas du tout même), et pourtant j'ai déjà intégré des maquettes au pixel près (j'exagère un peu ^^). Quand je regarde une maquette, je ne vois pas la beauté du graphisme, je vois simplement les principaux blocs, avec leur contenu et position (genre Néo, qui voit le code du programme en cours

).
C'est peut-être le fait de ne pas être designer (ni l'auteur) qui me permet de faire de l'intégration facilement.

_Soul · 12 Mai 2011

fredfan a dit:
Robinson a dit:

Mais il y a de bons outils qui aident grandement (mais excusez je n'ai plus le nom en tête).

Cliquez pour agrandir...

Si ça te revient ça m'intéresse

+1
Jamais vu un truc aussi chiant, je délègue en général x)

spout · 12 Mai 2011

Robinson a dit:
Mais il y a de bons outils qui aident grandement (mais excusez je n'ai plus le nom en tête).

Du style: http://www.divine-project.com/ ?
(Mais d'après ce que j'ai pu lire, ça découpe en une belle soupe de tags)

Sinon:
http://developer.yahoo.com/yui/grids/builder/
http://builder.yaml.de/

Et d'autres: http://www.webdesignbooth.com/15-extremely-useful-css-grid-layout-gene ... designers/

Zecat · 12 Mai 2011

C'est un topic pour convertir ... ou pour dissuader :mrgreen: :?:

Blount · 12 Mai 2011

Quand on lance un sujet comme celui-ci, il faut s'attendre à ce genre de dérive

Mais bon, je pense que ça va encore, on reste tout de même dans le sujet div/tableau

(même s'il y en a un qui à tenté à débat windows/linux ^^)

loran750 · 12 Mai 2011

je suis pas d'accord.
Pour ma part, j'ai eu les réponses que je voulais.
1/ les tables sont à conserver dans le cas d'une utilisation de ... tableaux classiques, tandis qu'il vaut mieux passer au div dans le cas de l'agencement d'une page web.
2/ j'ai pu noter plusieurs liens vers des documents explicatifs que je pourrai utiliser comme présentation au client, à l'infographiste, etc.

Donc, même si ça dérive, j'ai mes réponses. Faut-il garder le topic ouvert ? Oui à condition que ça ne tourne pas au "pour ou contre" et aux débats qui finissent en clash...

Marie-Aude · 12 Mai 2011

Non je trouve ça plutôt intéressant

on cause aussi outils d'intégration...

Une des choses que je n'aime pas trop avec les outils qui "coupent en tranches tout seuls", c'est qu'après, pour faire un bon sprite, il faut tout recoller.

Comme dit Blount, il y a un boulot à faire qui est technique, et qui est de penser en transformation css, en code léger, le plus léger possible (le bonheur de supprimer des div de positionnement ^^) et sur l'ensemble de la configuration d'un site. Je n'ai pas envie de me casser à faire des trucs totalement différents sur la page d'accueil, la page "single", la page "panier", "produit", etc. Mon zonage doit être le plus efficace possible, et d'un point de vue "code" et d'un point de vue "graphique".

Alors de temps en temps je rembarre le graphiste avec "on avait dit simple à intégrer" quand il me fait un texte qui se tortille autour d'une photo, "on avait dit web, pas print", quand il se pointe avec un background de 60k super zouli (dont 95% seront cachés par le contenu...), et de temps en temps je lui demande de me découper quelques trucs lui même de façon précise, mais justement, quand on ne construit pas un site "en table avec un morceau d'image dans chaque cellule" ^^ ça le fait encore relativement facilement.

lunicrea · 12 Mai 2011

Salut !

Pour ma part, j'ai encore des table dans mon code mais je considère effectivement que ce sont plus des "vestiges" du passé qu'autre chose.
Cela me permettait à l'époque de ne pas en ch*er entre compatibilité moz / ie ... voir Safari aussi !

TODO : Penser à reprendre l'architecture de mon CMS afin d'enlever tous les table.

spout · 12 Mai 2011

lunicrea a dit:
TODO : Penser à reprendre l'architecture de mon CMS afin d'enlever tous les table.

Oui parce que ton www est un bel exemple :mrgreen:

lunicrea · 12 Mai 2011

spout a dit:
lunicrea a dit:

TODO : Penser à reprendre l'architecture de mon CMS afin d'enlever tous les table.

Cliquez pour agrandir...

Oui parce que ton www est un bel exemple :mrgreen:

Ah je m'occupe que du référencement pour ce site là

C'est du SPIP existant avant que je prenne le site en main.

Topsitemaker · 12 Mai 2011

coté intégration, j'ai ma p'tite technique pour faire du millimétrage au pixel près,

Avec Firebug de FF, je sélectionne le DIV, et je double-clique une valeur du div comme le left ou top. puis j'utilise les flèches pour augmenter et réduire la valeur, ça bouge en direct sur le navigateur.

Blount · 12 Mai 2011

Voila, j'ai écris mon petit article qui pourra aider les nouveaux venus dans la mise en forme sans tableau.

J'ai repris en parti le contenu de mon poste sur les problèmes de placement, avec quelques explications supplémentaires.

Leonick · 12 Mai 2011

par contre, il faut faire attention à ne pas être pris d'une divite aiguë et n'utiliser les div qu'à bon escient : pour des menus architecturés en arborescence, un ul li suffit, pas besoin de l'inclure dans 1 ou plusieurs div
un div avec des paramètres de mise en forme inclus (du genre <div style="margin : 5px; font-size:10pt">) ça n'est pas bon non plus
bien utiliser aussi l'héritage dans les css

Amauri · 12 Mai 2011

Il n'y a pas de bonnes ou de mauvaises balises, il faut juste les utiliser avec cohérence.

Les <table> pour des tableaux, des <div> pour placer le contenu, des <p> pour des paragraphes, ... Le nommage des balises est en général suffisamment clair.

Topsitemaker · 13 Mai 2011

Amauri a dit:
Les <table> pour des tableaux, des <div> pour placer le contenu, des <p> pour des paragraphes, ... Le nommage des balises est en général suffisamment clair.

oui,
Pas plus tard qu'hier j'ai atteint les limites du <div> lors de la conception d'un menu avec sous-menus.
Il était basé sur du " ul / li / div / a ", le problème c'est que sous IE le hover sur le <a> ne maintenait pas en place le <div> du sous-menu.

J'ai du me résoudre à utiliser une structure " ul / li / ul / li / a " pour que le menu fonctionne correctement sur tous les navigateurs, en substituant le <div> par du "ul li"

Autant le <div> est naturellement prédisposé à être utilisé pour la structure générale d'un site,
Autant le "ul li" est plus efficace pour les menus.

chaque balise sa spécialité.

Marie-Aude · 13 Mai 2011

Topsitemaker a dit:
J'ai du me résoudre à utiliser une structure " ul / li / ul / li / a " pour que le menu fonctionne correctement sur tous les navigateurs, en substituant le <div> par du "ul li"

Te "résoudre" ?

c'est la structure classique, je n'aurais jamais essayé de faire autre chose.

Quand on parle de mise en page en "div" cela ne veut pas dire qu'on utilise du div pour tout, sinon cela revient à faire la même chose que les tables

c'est juste un résumé pour parler de l'ensemble des balises sémantiques, span, p, cite, blockquote, ol, dl, etc.

Blount · 13 Mai 2011

Pour les menus, j'ai bien toujours avoir un conteneur principal. Ensuite, j'y met bien entendu une liste pour afficher le menu.

Leonick · 13 Mai 2011

Topsitemaker a dit:
Autant le "ul li" est plus efficace pour les menus.

comme je l'avais dit au dessus, il est juste prévu pour ça, les listes structurées

Blount a dit:
Pour les menus, j'ai bien toujours avoir un conteneur principal. Ensuite, j'y met bien entendu une liste pour afficher le menu.

le ul est un containeur suffisant

JanoLapin · 13 Mai 2011

@Leonick: suffisant pour quoi, STP ?

fredfan · 13 Mai 2011

Il ne faut quand même pas rêver faire une présentation avec juste un ul et un div dans le body
Avec tous les problèmes de marges, de padding et de fonds on est obligé d'encapsuler un minimum.
Un div pour l'ensemble de la page, un pour le ul du menu et un ou deux pour le contenu, sans compter les paragraphes, ça semble un minimum pour tout stabiliser et positionner.

JanoLapin · 13 Mai 2011

Donc finalement, c'ets pas du tout aussi simple que les tables quand il s'agît de positionner dans l'espace ?

fredfan · 13 Mai 2011

Ce n'est pas simple mais les tables ça l'est encore moins

Zecat · 13 Mai 2011

fredfan a dit:
Ce n'est pas simple mais les tables ça l'est encore moins

ah bon :roll: j'ai rien senti :mrgreen:

padadam22 · 13 Mai 2011

J'étais anti div, anti span, anti css.... j'en suis vite revenu quand il a fallu que je code mes premières pages et que je n'arrivais à rien avec des tables pourtant si chères à mon coeur :mrgreen:

Zecat · 13 Mai 2011

Variante : je suis pas anti css :mrgreen:

JanoLapin · 13 Mai 2011

Zecat a dit:
Variante : je suis pas anti css :mrgreen:

quel soixante-huita'wd celui-là alo'w... :mrgreen:

Pulsar-san · 17 Mai 2011

fredfan a dit:
Un div pour l'ensemble de la page, ..., ça semble un minimum pour tout stabiliser et positionner.

Même pas.
Le body est déjà un conteneur par lui-même et il peut être stylé en CSS.

fredfan · 17 Mai 2011

Pulsar-san a dit:
fredfan a dit:

Un div pour l'ensemble de la page, ..., ça semble un minimum pour tout stabiliser et positionner.

Cliquez pour agrandir...

Même pas.
Le body est déjà un conteneur par lui-même et il peut être stylé en CSS.

Si tu ne mets pas de div global tu vas rencontrer un jour ou l'autre un bug sur un navigateur que tu n'as pas pensé à vérifier, ou une difficulté de positionnement. Au prix du div au kilo je préfère en mettre un et économiser deux heures de prise de tête. Quand je n'en mets pas c'est à condition qu'il n'y ait pas d'éléments à risque genre ul ou p qui traînent au niveau 1

Nemoadd · 18 Mai 2011

fredfan a dit:
Si tu ne mets pas de div global tu vas rencontrer un jour ou l'autre un bug sur un navigateur que tu n'as pas pensé à vérifier, ou une difficulté de positionnement. Au prix du div au kilo je préfère en mettre un et économiser deux heures de prise de tête. Quand je n'en mets pas c'est à condition qu'il n'y ait pas d'éléments à risque genre ul ou p qui traînent au niveau 1

Je n'ai encore jamais rencontré de bug parce que je ne mets pas de div global.

Tous les bugs que j'ai pu rencontrer à mes débuts, c'était à cause d'une mauvaise gestion des marges. Lorsqu'on a compris le truc, tout marche nickel dès le début. Et compatible 100% au pixel près sur tous les navigateurs (sauf IE6, je l'ai blacklisté, celui-là).

Arguments pour convertir une personne aux DIV et SPAN au lieu de TABLE

WRInaute passionné

WRInaute accro

WRInaute passionné

WRInaute accro

WRInaute accro

WRInaute occasionnel

WRInaute impliqué

WRInaute accro

WRInaute passionné

WRInaute passionné

WRInaute accro

WRInaute accro

WRInaute occasionnel

WRInaute accro

WRInaute accro

WRInaute accro

WRInaute accro

WRInaute accro

WRInaute accro

WRInaute impliqué

WRInaute accro

WRInaute accro

WRInaute accro

WRInaute discret

WRInaute accro

WRInaute accro

WRInaute accro

WRInaute passionné

WRInaute accro

WRInaute accro

WRInaute accro

WRInaute accro

WRInaute accro

WRInaute accro

WRInaute impliqué

WRInaute discret

WRInaute accro

WRInaute accro

WRInaute impliqué

WRInaute accro

WRInaute impliqué

WRInaute passionné

WRInaute accro

WRInaute impliqué

WRInaute accro

WRInaute occasionnel

WRInaute accro

WRInaute accro

WRInaute accro

WRInaute impliqué

WRInaute impliqué

WRInaute discret

WRInaute accro

WRInaute passionné

WRInaute passionné

WRInaute accro

WRInaute accro

WRInaute accro

WRInaute accro

WRInaute impliqué

WRInaute impliqué

WRInaute accro

WRInaute accro

WRInaute impliqué

WRInaute passionné

WRInaute accro

WRInaute occasionnel

WRInaute accro

WRInaute occasionnel

WRInaute impliqué

WRInaute impliqué

WRInaute accro

WRInaute occasionnel

WRInaute impliqué