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

WRInaute passionné
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
 
WRInaute accro
"Non" :D

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 :D
 
WRInaute passionné
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
usb_typewriter_1.jpg


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").
 
WRInaute accro
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
 
WRInaute accro
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:
 
WRInaute occasionnel
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:
 
WRInaute accro
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:
 
WRInaute passionné
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 ^^
 
WRInaute passionné
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é ...
 
WRInaute accro
@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
 
WRInaute accro
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.
 
WRInaute occasionnel
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:)
 
WRInaute accro
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 ...
 
WRInaute accro
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:
 
WRInaute accro
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é ...
 
WRInaute impliqué
@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 ^^.
 
WRInaute accro
C'est bien ce que j'appelle une mise en page "simple" :D

@boby55 moi je fais partie des gens qui ne sont JAMAIS retournés aux tables :)
 
WRInaute accro
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 ...
 
WRInaute accro
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:
 
WRInaute discret
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
 
WRInaute accro
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 :p
 
WRInaute accro
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 :)
 
WRInaute passionné
nan di diou spout & JanoLapin !
Voilà exactement ce qu'il fallait ! Une présentation claire et synthétique. Merci !
 
WRInaute accro
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 :p
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.
 
WRInaute accro
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 ;)
 
WRInaute accro
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...
 
WRInaute accro
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>.

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:
 
WRInaute accro
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...

> 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...
 
WRInaute impliqué
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).
 
WRInaute discret
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 ! :)
 
WRInaute accro
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.
 
WRInaute accro
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.
 
WRInaute impliqué
Le seul inconvénient pour moi est l'utilisation de « float » qui introduit des bugs d'affichage si c'est mal conçu.

Exemple :
example.jpg

Symptôme :
1 - bloc passe en dessous d'un autre
example-bug1.jpg


2 - le conteneur des blocs flottant perd sa hauteur.
example-bug2.jpg


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.
 
WRInaute accro
@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)
 
WRInaute impliqué
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.
 
WRInaute passionné
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.
 
WRInaute accro
personellement, je me reconnais parfaitement dans les propos de moira.

en B2B, le full div c'est loin d'être toujours la panacée..
 
WRInaute occasionnel
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: )
 
WRInaute accro
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 :D (ah non, il n'aura plus les mobiles...)
 
WRInaute impliqué
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" !
 
WRInaute impliqué
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.
 
WRInaute discret
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).
 
WRInaute accro
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 :)
 
WRInaute passionné
@Marie-Aude, j'ai convaincu il y a longtemps mon infographiste d'utiliser Flash à outrance... ce n'est pas pour y revenir :p

tiens, par curiosité, je me demande comment les infographistes font pour découper une maquette photoshop en gabarit html/css.
 
WRInaute passionné
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 :p

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).
 
WRInaute accro
Blount a dit:
J'ai pour cela l'habitude d'utiliser un span de cette manière :
Code:
<span class="clear">&nbsp;</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
 
WRInaute accro
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 :D
 
WRInaute accro
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 :D. 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 :D

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.
 
WRInaute impliqué
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 :p

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 :D).
C'est peut-être le fait de ne pas être designer (ni l'auteur) qui me permet de faire de l'intégration facilement.
 
WRInaute impliqué
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 ^^)
 
WRInaute passionné
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...
 
WRInaute accro
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.
 
WRInaute occasionnel
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. :p
 
WRInaute impliqué
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.
 
WRInaute impliqué
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.
 
WRInaute accro
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
 
WRInaute occasionnel
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.
 
WRInaute impliqué
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é.
 
WRInaute accro
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" ? :D 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 :D c'est juste un résumé pour parler de l'ensemble des balises sémantiques, span, p, cite, blockquote, ol, dl, etc.
 
WRInaute impliqué
Pour les menus, j'ai bien toujours avoir un conteneur principal. Ensuite, j'y met bien entendu une liste pour afficher le menu.
 
WRInaute accro
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
 
WRInaute accro
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.
 
WRInaute accro
Donc finalement, c'ets pas du tout aussi simple que les tables quand il s'agît de positionner dans l'espace ?
 
WRInaute accro
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:
 
WRInaute discret
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.
 
WRInaute accro
Pulsar-san a dit:
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.
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
 
Nouveau WRInaute
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à).
 
Discussions similaires
Haut