TABLE ou FULL CSS

  • Auteur de la discussion Auteur de la discussion boby55
  • Date de début Date de début
WRInaute occasionnel
Bonsoir,

Mon site web est actuellement structuré avec des <table> pour afficher son contenu.
De ce fait le rapport code html/contenu est assez élevé, et je voulais savoir si cela avait un impact important sur le référencement.
Et oui les div c'est sympa mais mettre 3 heures pour aligner sous tous les navigateurs 2 éléments ... ça m'a jamais motivé :mrgreen:
 
WRInaute accro
boby55 a dit:
ça m'a jamais motivé :mrgreen:
c'est pour cela que ça te prend 3 heures.

sinon le temps de chargement étant un facteur pris en compte (comme d'autres), oui, cela a un impact.
 
WRInaute passionné
L'impact du code, s'il existe, est minime.

Si je ne me trompe pas, des tests ont montré que la qualité du code n'avait pas d'impact sur le référencement.

Matt Cutts a également dit que le code important peu.


...mais je préconise quand même le full xHTML + CSS, c'est quand même bien mieux, plus propre etc.
Quand aux problèmes d'alignements etc., ça s'apprend.
 
WRInaute accro
@5_legs, c'est super pratique pour travailler avec un designer, tu lui demandes juste de suivre le grid :wink:
 
WRInaute occasionnel
temps de chargement étant un facteur pris en compte

ok mais entre 20 ko de page avec table et 14 en div par exemple, une fois compressé si je gagne 0.001 ms ça reste moindre à mon goût.

Matt Cutts a également dit que le code important peu

Je me concentrerais donc pas à tout modifier dans ce cas.

Si tu n'a pas envie de te prendre la tête avec les alignements, il y a des frameworks CSS

Je ne connaissais pas nonplus, mais dans le cas présent c'est un existant trop complexe pour faire une simple grid 4*4, j'ai des tables avec colspan, rowspan, mais avec du css avec. Je fais du valide w3c sur les pages principales quand même ^^

Merci pr vos conseils en tout cas
 
WRInaute accro
boby55 a dit:
temps de chargement étant un facteur pris en compte

ok mais entre 20 ko de page avec table et 14 en div par exemple, une fois compressé si je gagne 0.001 ms ça reste moindre à mon goût.

A ton goût ...
essaie sur une page pour voir (note bien que le facteur vitesse de chargement est assez récent il me semble donc ...)
Mais de toute façon je ne pense pas que le rapport soit de 0.001 ms au final surtout si ta gestion du CSS est inexistante, car le gain sera plus important je pense (en général entre une page type dreamweaver et la même soignée je constate 66% de poids en moins)
 
WRInaute passionné
@spout : moi je suis à la recherche d'une grille CSS fluide qui fonctionne bien... en vain.
J'en ai testé, j'en ai créé, et le résultat n'est pas brillant dans toutes les résolutions hélas.


Je fais du valide w3c sur les pages principales quand même ^^
C'est pas bien difficile, et ça dépend notamment du doctype. En HTML 4.0, les < table > étaient très répandues et acceptées.
En xHTML 1.0, les < table > sont bien sûres acceptées, mais ne doivent être utilisées uniquement pour des données tabulaires. Le validateur ne pouvait pas vérifier si les tables sont utilisées pour des données tabulaires ou pour faire des mises en page, il valide... (c'est un ordinateur : bête et méchant). Dans les faits, ce n'est pas vraiment valide, ni un code propre (il ne faut donc pas trop se fier à la validation).
La validation doit surtout servir à déceler des erreurs (oubli de balise fermante par exemple).
 
WRInaute accro
Anto1982 a dit:
De toute façon, les tableaux sont très bien pour les données tabulaires... inutile de réinventer la table.
Et si la table était utilisée pour une raison de mise en page, c'est pas le positionnement de 3/4 blocs qui est difficile.
 
WRInaute discret
C'est aussi une question de dépréciation. Quand on sait coder. On code avec de la logique, et donc dans les respects des dernières normes.
C'est alors qu'on s'aperçoit que le <table> est du code déprécié. Donc si on veut travailler correctement on n'utilise plus le <table>.

Au final, coder en full CSS c'est plus pratique et ca permet de faire + de choses.

Avoir un site valide W3C ca s'appelle savoir coder.
 
WRInaute passionné
C'est aussi une question de dépréciation. Quand on sait coder. On code avec de la logique, et donc dans les respects des dernières normes.
C'est alors qu'on s'aperçoit que le <table> est du code déprécié. Donc si on veut travailler correctement on n'utilise plus le <table>.

pas pour des données tabulaires...
 
WRInaute discret
Anto1982 a dit:
C'est aussi une question de dépréciation. Quand on sait coder. On code avec de la logique, et donc dans les respects des dernières normes.
C'est alors qu'on s'aperçoit que le <table> est du code déprécié. Donc si on veut travailler correctement on n'utilise plus le <table>.

pas pour des données tabulaires...

Données tabulaires ou pas, mettre du <table> c'est du code déprécié. Et tes données tabulaires tu peux très bien les afficher en CSS.
 
WRInaute accro
thibotus01 a dit:
Anto1982 a dit:
C'est aussi une question de dépréciation. Quand on sait coder. On code avec de la logique, et donc dans les respects des dernières normes.
C'est alors qu'on s'aperçoit que le <table> est du code déprécié. Donc si on veut travailler correctement on n'utilise plus le <table>.

pas pour des données tabulaires...

Données tabulaires ou pas, mettre du <table> c'est du code déprécié. Et tes données tabulaires tu peux très bien les afficher en CSS.
ça c'est de l'ayatolisme.
 
WRInaute impliqué
thibotus01 a dit:
Données tabulaires ou pas, mettre du <table> c'est du code déprécié. Et tes données tabulaires tu peux très bien les afficher en CSS.

C'est totalement faux, dans les doctypes la balise table n'a jamais été dépréciée, et n'est pas près de l'être, certaines informations nécessitent l'usage des tableau, c'est le cas des données tabulaires, notamment pour une question d'accessibilité, pour un non-voyant, des données tabulaires présentes sans utiliser les tableaux ne leur seraient pas compréhensible, alors qu'avec un usage correct des tableaux oui : http://www.pompage.net/pompe/autableau/
 
Nouveau WRInaute
Eh hop une couche de plus table vs css.
Franchement quand on a besoin de générer des tableaux, pourquoi ne pas les utiliser.
Je dit pas !!!! Faire un site tout en table comme à l'époque ou la css c'était pas ça. Ok mais là y a les css !
Donc les tables sont a éviter pour faire son squelette surtout que l'on peu faire des trucs beaucoup plus évolué avec des div ou autres balise + CSS et que l'on a un plus grande souplesse pour séparer data et mise en page.

Mais TABLE ET CSS ne sont pas antinomiques bien au contraire les CSS peuvent apporter beaucoup aux balises associées à table. Maintenant il appartient a chacun de décider ou non d'utiliser une table d'autant que comme le précise DadouDuck, pour peu que la table soit bien formé avec les entêtes, les pieds, définitions de colonnes etc, le non voyant sera content de pouvoir lire les données correctement.

Et ou table = déprécié ??? je vois pas ou ???? Que l'on me montre la page dans les standard du W3C qui indique que la balise table est obsolète. Je veux bien le croire mais je suis comme St Thomas je veux voir la page sur leur site. En tout cas je l'ai jamais vu pour l'instant. Mais bon les normes ça évolue.
 
WRInaute discret
zeb a dit:
ça c'est de l'ayatolisme.

Et en français ca donne quoi ?


DadouDuck a dit:
C'est totalement faux, dans les doctypes la balise table n'a jamais été dépréciée, et n'est pas près de l'être, certaines informations nécessitent l'usage des tableau, c'est le cas des données tabulaires, notamment pour une question d'accessibilité, pour un non-voyant, des données tabulaires présentes sans utiliser les tableaux ne leur seraient pas compréhensible, alors qu'avec un usage correct des tableaux oui : http://www.pompage.net/pompe/autableau/

Ton article a 6 ans...... :roll: :roll:


Si tu fais un site avec un ancien doctype, certe rien ne t'empêche d'utiliser le <table>, sauf que tu feras un site qui ne sera pas aux dernières normes (xHTML strict actuellement), et ton <table> se résumera par :

L'affichage des tableaux se fait lentement
Les tableaux nuisent à l'accessiblité
Les tableaux nuisent à l'impression
Les tableaux sont complexes et coûteux à produire
Les tableaux alourdissent les pages


Le coup des aveugles pour l'accessibilité, c'est complètement l'inverse, car leurs système ne peuvent généralement reproduire des graphiques, ce que fait <table>

http://www.openweb.eu.org/articles/problemes_tableaux/

L'article précise que les table ne sont pas fait pour la mise en page, ok, et qu'on peut éventuellement les utiliser pour des données tabulaires, mais si ton doctype est en xhtml strict, tu ne peux pas. Et le faire en CSS conviendra parfaitement.
 
WRInaute accro
Bonjour

Pour moi les deux principaux arguments "contre" les tableaux et "pour" les DIV / CSS, c'est :
1°) maintenabilité / lisibilité du code
2°) accessibilité

Quand tu dois modifier un site fait en tableaux, excuses moi mais tu peux aller pleurer (ou alors imbriquer des tables dans des tables...) ; en CSS, un coup de feuille de style et basta !

Il m'arrive d'utiliser des tableaux... mais pour les données tabulaires (à plus de deux colonnes, sinon je préfère les dl/dd/dt)
 
WRInaute accro
thibotus01 a dit:
et qu'on peut éventuellement les utiliser pour des données tabulaires, mais si ton doctype est en xhtml strict, tu ne peux pas. Et le faire en CSS conviendra parfaitement.
D'où est-ce que tu sors ça ?
La balise table n'est pas dépréciée en xhtml strict.
C'est aussi ridicule d'abuser dans un sens que dans l'autre.
 
WRInaute discret
fredfan a dit:
thibotus01 a dit:
et qu'on peut éventuellement les utiliser pour des données tabulaires, mais si ton doctype est en xhtml strict, tu ne peux pas. Et le faire en CSS conviendra parfaitement.
D'où est-ce que tu sors ça ?
La balise table n'est pas dépréciée en xhtml strict.
C'est aussi ridicule d'abuser dans un sens que dans l'autre.

Oui, en fait autant pour moi, c'est certains attributs utilisés dans la balise table qui sont dépréciés en strict...
 
WRInaute accro
thibotus01 a dit:
Oui, en fait autant pour moi, c'est certains attributs utilisés dans la balise table qui sont dépréciés en strict...

Et de même l'article que tu as cité toi même dit bien que les tables sont à éviter pour faire de la présentation, mais qu'elles sont là pour présenter des données tabulaires.

Les attributs des tables dépréciés en xhtml strict sont uniquement ceux liés à la présentation, ce qui est parfaitement normal, ça va dans le css.
 
WRInaute occasionnel
Moralité : TABLE et DIV ont leur place respective , le tout égrémenté de CSS pour parfumer la recette :mrgreen:

Désolé d'avoir lancé la polémique :roll:
 
WRInaute accro
boby55 a dit:
Moralité : TABLE et DIV ont leur place respective , le tout égrémenté de CSS pour parfumer la recette :mrgreen:

Désolé d'avoir lancé la polémique :roll:
De rien, sujet éculé mais une piqure de rappel ne fait pas de mal.
C'est en polémiquant qu'on devient polémiqueron.
 
WRInaute impliqué
thibotus01 a dit:
zeb a dit:
ça c'est de l'ayatolisme.

Et en français ca donne quoi ?

Le mot ayatollah est souvent employé pour désigner une personne particulièrement intransigeante sur un sujet précis.


thibotus01 a dit:
Ton article a 6 ans...... :roll: :roll:

Et alors ???? En 6 ans, c'est toujours d'actualités, rien n'a changé depuis la rédaction de cet article...

thibotus01 a dit:
Si tu fais un site avec un ancien doctype, certe rien ne t'empêche d'utiliser le <table>, sauf que tu feras un site qui ne sera pas aux dernières normes (xHTML strict actuellement),

En utilisant les tables le site sera toujours valide aux dernières normes, comme on n'arrête pas de te le dire, table n'est pas déprécié d'ailleurs : http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_tablemodule
The Tables Module provides table-related elements that are better able to be accessed by non-visual user agents. Specifically
Le module Tableaux fournit des éléments de table connexes qui sont mieux à même d'être consultée par les agents utilisateurs non-visuels

C'est assez clair pour toi????

thibotus01 a dit:
Le coup des aveugles pour l'accessibilité, c'est complètement l'inverse, car leurs système ne peuvent généralement reproduire des graphiques, ce que fait <table>

N'importe quoi, les données tabulaires ne représentent pas toujours le contenu de graphiques, et quand bien même, la lecture d'un graphique est plus simple pour un non-voyant quand il est assisté par un tableau justement.

thibotus01 a dit:
http://www.openweb.eu.org/articles/problemes_tableaux/

L'article précise que les table ne sont pas fait pour la mise en page, ok, et qu'on peut éventuellement les utiliser pour des données tabulaires, mais si ton doctype est en xhtml strict, tu ne peux pas. Et le faire en CSS conviendra parfaitement.

J'ai déjà répondu a ce point, les tableaux pour autre chose que des données tabulaires ne sont pas valide, par contre, ils remplissent convenablement la fonction de présentation de données tabulaires qui ne DOIT PAS être présenté d'une autre manière, car sinon, tu casserais un point important des normes : UTILISER LES BALISES ADAPTÉES SÉMANTIQUEMENT AU CONTEXTE, et quoi de mieux sémantiquement de d'utiliser des tableaux pour des données tabulaires?? : http://openweb.eu.org/articles/respecter_semantique/
Nous avons ainsi des balises pour indiquer un titre (h1, h2…) ; des balises pour indiquer des listes (ul, ol,…) ; des balises pour indiquer un paragraphe (p), une citation (blockquote), un tableau de données (table), un bloc regroupant plusieurs contenus (div), etc.
 
WRInaute accro
DadouDuck a dit:
En utilisant les tables le site sera toujours valide aux dernières normes, comme on n'arrête pas de te le dire, table n'est pas déprécié d'ailleurs : http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_tablemodule

je pense même que les tables ne sont pas près de disparaître car si la volonté clairement exprimée de les faire disparaître pour un usage de mise en page / positionnement est une réalité, il serait totalement stupide de priver un langage descriptif du seul élément pensé pour représenter un tableau de données.

Concrètement, il faut bien se dire que si CSS permet de produire un visuel semblable a un tableau, le code html utilisé lui ne sera pas en rapport avec des données tabulées. Hors la tendance va dans le sens de la séparation du code et de la présentation mais pas dans le sens d'un appauvrissement de la sémantique qui elle a besoin de ces tables, listes, bloc, paragraphes etc ... pour s'exprimer pleinement.

A titre de comparaison si le seul fait de pouvoir faire un tableau en CSS justifiait la disparition des tables, on pourrait entre autre par exemple trancher dans le vif et regrouper Span, Div et P(aragraphe) sur le simple fait que leur caractéristique sont souvent utilisées dans le même contexte et que CSS permet de les présenter (a quelques détails près) de la même façon.
 
WRInaute accro
Je connais les deux et continue à utiliser des tableaux (me fout des nouvelles directives données par des institutions plus ou moins connues ... et inconnues par les moteurs de recherche). Tiens ca fait longtemps qu'il n'y a plus eut de post pour le w3c sur wri :mrgreen:
Il y a un gros avantage des tableaux: on a pas à tester su la présentation est la même avec Ie6, 7 et 8, firefox, safari, .... elle est la même. Pour ma part, les CSS ne servent plus que pour les caractères (j'en ai un peu marre en plus de tomber sur des sites avec mon ie6 complètement décalés (quasiment vides sans scroller) pour les voire en firefox complètement décalé et s'apercevoir que sur ie8 de l'autre ordinateur ca semble bon (et j'ai pas encore installé Safari ou chrome en plus). A part des images qui se déplacent avec le scrolling (voire des menus), voudrait bien voire ce que je sais pas faire avec des tableaux par rapport aux CSS (j'avoue souvent imbriquer des tableaux dans des tableaux).

Le poids du code :D quand on analyse parfois le CSS de certains sites ....

thibotus01 a dit:
L'affichage des tableaux se fait lentement
Les tableaux nuisent à l'accessiblité
Les tableaux nuisent à l'impression
Les tableaux sont complexes et coûteux à produire
Les tableaux alourdissent les pages
Sais pas si tu es pour ou contre les tableaux. Mias:
1. la vitesse de téléchargement d'une page est plus souvent un problème de résolution d'image ou de serveur
2. L'accessibilité reste une légende urbaine des webmasters, aideront pas un aveugle à traverser la rue mais s'inquiète pour leur site. Comme je dit dans des formations techniques sous Windows (à des techniciens): si ca continue, un type complètement aveugle, complètement sourd va finir par utiliser un ordinateur (et j'ai des aveugles comme client de magasin sauf qu'ils utilisent des équipent tout à fait spécifiques et très chères) mais ... cl logiciels permettent d'agrandir les textes (un peu les images mais en déformant). Pourtant chez une personne agée quasiment complètement aveugle, une simple lettre fait plus de 30 cm de haut sur son écran spécial (j'admire cette personne qui lit un texte aussi vite que moi). Au passage, le alt dans les images utilisée comme slogans par certains :roll: . On sait tous qu'on met des alt dans les images pour le référencement. Ca marche pour des aveugles .... NON.
3. Avec les outils actuels, l'impression se fait directement en pdf
4. Il y a un truc génial que j'ai découvert avec Windows 2.0 (qui s'en rappelle) c'est le copier / coller. Les raccourcis ont changés en windows 3.0 (mais les anciens raccourcis fonctionnent encore: c'est <ctrl> >insert> pour copier et <shift> <insert> pour coller (maintenant c'est c et v). D'accord pour ca faut aller dans le code html.
5. c'est le 1 finalement ....

Et c'est reparti pour les faux arguments pour une large partie des webmasters. On se croirait il y a 15 ans entre les PC et les mac de l'époque.
 
WRInaute impliqué
Bon, et bien on a maintenant le deuxième extrême, le juste milieu personne connait??

Je n'utilise pas du tout les tableaux pour la mise en forme, uniquement, les CSS, quand on les maitrises bien, on a pas de problèmes majeurs comme ceux que tu as pus décrire pour le rendu des différents navigateurs, j'ai bien rencontré un petit décalage d'un pixel par-ci, par là, mais rien qui ne choquera l'utilisateur, mais on peut avoir les même merdes avec les tableaux, d'un navigateur à l'autre, les marges par défauts ne sont pas forcement les mêmes.

Les CSS, quand ils sont correctement utilisés, vont générer un code HTML beaucoup plus light, et donc ce sera plus facile pour faire des modifications ultérieures. Avec les tableaux imbriqués, le code HTML devient tellement illisible, que parfois, c'est franchement coton pour faire une modif mineure.

Concernant l'accessibilité, non ce n'est pas une légende urbaine, c'est TRÈS utile, pour les non-voyant, cela facilite leur quotidien, et les rends beaucoup plus indépendant, ils peuvent par exemple faire des démarches administratives, ce qui leur évite soit de faire appel à quelqu'un pour les aider, soit à se déplacer eux même, ce qui est souvent pour eux, un vrai parcours du combattant. Mais, un site réalisé en CSS, n'est pas accessible pour autant, il y a des règles à respecter pour que le site le soit. Concernant l'aide fournie à un non-voyant pour traverser une route, cela n'a rien à voir avec un webmaster, le faire, c'est tout simplement du civisme, mais, je te l'accorde beaucoup en manquent cruellement, mais ces derniers si ils étaient webmaster, n'ont rien a faire de l'accessibilité d'un site internet (a part pour pouvoir facturer plus cher une presta) et donc n'en prendrons pas la défense.

Concernant l'attribut ALT des images, il fonctionne parfaitement pour les aveugles équipé de logiciels de revue d'écran, forcement, le texte ne sera pas écrit en plus gros, mais il sera lu et retranscrit soit par un lecteur braille, soit par une synthèse vocale. Je n'ai jamais utilisé cet attribut pour le référencement, mais toujours pour donner un vrai texte alternatif à l'image.

Ensuite, quand on parle que les tableaux sont complexes et coûteux à produire, c'est complexe parce que le code HTML est beaucoup plus lourd, donc beaucoup moins lisible (ça je l'ai déjà évoqué), coûteux, parce qu'en général, c'est plus long à intégrer qu'une mise en forme CSS, et surtout, beaucoup plus long à modifier, la maintenance de site "tableaux" est plus ardue a faire, donc plus longue.
 
WRInaute occasionnel
Hier soir je me dis
et si je me débarrassais de mes tables et que je refaisais la structure (header et menu) de mon site en FULL CSS

Alors c'est parti je commence mes modifs : je remplace un TABLE par un div... encore un autre ... je continu ... et là BLOCAGE :

impossible de faire que mon menu de gauche possédant une couleur de fond couleur aille jusqu'au bas de ma page (height 100%) quand mon contenu de page est plus long. Après une errance de près d'une heure sur Google et de tests je renonce et laisse ma TABLE pour mon menu.

CAS classique :

Code:
<div id="boite">
<div id="menu_gauche"></div>
<div id="content"></div>
</div>
Parfois c'est vraiment pas méchant de faire du FULL CCS, mais parfois pour un truc vraiment très con ça devient la galère :mrgreen:
 
WRInaute passionné
impossible de faire que mon menu de gauche possédant une couleur de fond couleur aille jusqu'au bas de ma page (height 100%) quand mon contenu de page est plus long.
Je vois deux solutions à ton problème :
  • faire des "faux columns" ( = une image de fond - cherche sur Google ;-) )
  • utiliser JavaScript pour faire en sorte que tes colonnes aient toujours une hauteur égales les unes aux autres (cherche : "setting equal height of columns" ou qq chose dans le genre)
 
WRInaute occasionnel
SpeedAirMan a dit:
impossible de faire que mon menu de gauche possédant une couleur de fond couleur aille jusqu'au bas de ma page (height 100%) quand mon contenu de page est plus long.
Je vois deux solutions à ton problème :
  • faire des "faux columns" ( = une image de fond - cherche sur Google ;-) )
  • utiliser JavaScript pour faire en sorte que tes colonnes aient toujours une hauteur égales les unes aux autres (cherche : "setting equal height of columns" ou qq chose dans le genre)

Je préfère faire simple (pour faciliter la maintenance et avoir un site lègé).
Le JS ça me semble être une enclume pour écraser une fourmis :roll: (surtout visuellement ça se voit à l'écran parfois sur les navigateurs un peu moues).

Pour des "faux columns", je ne suis pas certain d'avoir compris ( une image de fond sur le body ?) mais cela nécessite une image de plus donc une requête de plus ... je préfère rester en css avec un background-color uniquement pour faire celà.

Merci tout de même pour les suggestions.
 
Discussions similaires
Haut