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

"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

 

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

 

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

Sinon :

$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 ...

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

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

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:

 

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:

 

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

 

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

 

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 ^^

 

@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

 

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.

 

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

 

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

 

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 ...

 

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:

 

Ç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

 

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é ...

 

@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 ^^.

 

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

 

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 ...

 

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:

 

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

 

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

 

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

 

Excellent argument

 

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.

 

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

 

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...

 

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

 

> 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...

 

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).

 

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 !

 

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

 

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.

 

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.

 

@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)

 

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.

 

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.

 

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

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

 

Juste pour mon ignorance, B2B veut dire ?

 

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

 

+1 :roll:

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

 

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

 

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...)

 

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

 

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" !

 

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.

 

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).

 

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

 

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).

 

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

 

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

 

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

 

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.

 

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.

 

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

 

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/

 

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

 

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 ^^)

 

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.

 

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.

 

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.

 

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.

 

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.

 

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

 

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.

 

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é.

 

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.

 

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

 

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

le ul est un containeur suffisant

 

@Leonick: suffisant pour quoi, STP ?

 

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.

 

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

 

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

 

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

 

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:

 

Variante : je suis pas anti css :mrgreen:

 

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

 

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

 

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à).