table html et marges

Thibaut Allender a écrit :

On 18/09/2006 21:15, Arnold McDonald (AMcD) wrote :

Je n'ai certes quasiment plus de table pour mes
mises en page, merci, je suis les évolutions moi aussi, mais si je tombe sur
un cas casse-pied, ça ne me gênera nullement d'y retourner.

Faut y passer, faut se faire violence, renoncer à certaines mise en page
et voilà.

Se faire violence et renoncer, mais bien sûr. Ca c'est possible dans
l'univers utopique où le développeur est en relation directe avec son
client et quand ce client accepte les propositions de corrections qui
sont faites sur *sa* mise en forme exceptionnellement magnifique. Ce
n'est malheureusement pas le cas de l'univers dans lequel j'évolue.

Je fais peu ou pas d'intégration HTML en frontoffice et ne rencontre
donc pas ce probleme puisque *je* suis libre du choix de mise en forme à
utiliser. Mais quand je vois ou entends les collègues totalement
désespérés d'expliquer aux responsables commerciaux ou aux chefs de
projets en quoi tel ou tel choix de mise en forme est problématique ou
encore en quoi l'espoir d'un positionnement au pixel près est une
hérésie, je constate que la solution la plus souvent retenue est
l'utilisation d'un tableau pour arriver à la demande exacte du client
plutot que de renoncer et de se faire violence sur une autre mise en forme.

Les réponses des commerciaux que j'entends c'est généralement : "oui
mais tu comprends il a demandé ça comme ça, on lui a vendu X jours alors
debrouilles toi pour pas dépasser la dead line" ou encore "oui mais avec
tel navigateur il y a un pixel en trop la"

Convaincre un client c'est pas facile.
Convaincre ton chef de proj qui doit convaincre le commercial qui doit
convaincre le client, ça l'est encore moins.

Et donc, comme c'est malheureusement toujours le marketing qui emporte
le bras de fer contre la technique, les tables sont loins de disparaître.

--
laurent

Laurent vilday wrote:

Je fais peu ou pas d'intégration HTML en frontoffice et ne rencontre
donc pas ce probleme puisque *je* suis libre du choix de mise en forme à
utiliser. Mais quand je vois ou entends les collègues totalement
désespérés d'expliquer aux responsables commerciaux ou aux chefs de
projets en quoi tel ou tel choix de mise en forme est problématique ou
encore en quoi l'espoir d'un positionnement au pixel près est une
hérésie, je constate que la solution la plus souvent retenue est
l'utilisation d'un tableau pour arriver à la demande exacte du client
plutot que de renoncer et de se faire violence sur une autre mise en forme.

Est-ce que ce message est une manière de dire qu'il est raisonnable de
mal faire son travail en prenant comme prétexte "le manque de temps"
?!!! Je suis assez attéré de ce que je lis, j'espère me tromper.

Pierre Goiffon a écrit :

Laurent vilday wrote:

Je fais peu ou pas d'intégration HTML en frontoffice et ne rencontre
donc pas ce probleme puisque *je* suis libre du choix de mise en forme
à utiliser. Mais quand je vois ou entends les collègues totalement
désespérés d'expliquer aux responsables commerciaux ou aux chefs de
projets en quoi tel ou tel choix de mise en forme est problématique ou
encore en quoi l'espoir d'un positionnement au pixel près est une
hérésie, je constate que la solution la plus souvent retenue est
l'utilisation d'un tableau pour arriver à la demande exacte du client
plutot que de renoncer et de se faire violence sur une autre mise en
forme.

Est-ce que ce message est une manière de dire qu'il est raisonnable de
mal faire son travail en prenant comme prétexte "le manque de temps"
?!!! Je suis assez attéré de ce que je lis, j'espère me tromper.

Décidemment, marre de usenet. Pierre, voyons, ce n'est pas ce que j'ai
dit. Alors je reprends.

Arnold essaye d'expliquer qu'il *peut* arriver qu'un choix de mise en
forme soit difficilement réalisable en CSS sans figures acrobatiques et
surtout sans un réel cout financier puisque les figures prennent du
temps. Et qu'une solution utilisant un tableau est une solution
*financière* qui se pratique
moins de prises de tete == moins de temps == plus d'argent

Ce sur quoi Thibaut lui répond : "Faut y passer, faut se faire violence,
renoncer à certaines mise en page et voilà."

Et là mon intervention, c'est très bien et très joli comme idée, mais
c'est complètement utopique à moins d'être son propre décideur. Toutes
les personnes qui font des sites webs - et je prend mes collègues comme
exemple puisque je constate qu'ils ont de temps en temps le problème -
n'ont *pas*, vraiment pas du tout, le loisir de déplacer un pixel de ce
qu'il leur est demandé de réaliser.

Donc voila, certainement pas pour dire que c'est raisonnable de mal
faire, bien au contraire. Juste pour rappeler que tout le monde n'a pas
la liberté du choix de la mise en forme. Et que quand un problème de
mise en forme survient, les décideurs finissent toujours, à ce que j'en
vois des différentes boites que j'ai pratiqué, par écarter les arguments
techniques et les propositions de substitution en imposant des temps de
dev réalisables exclusivement par tableau.

Si tout le monde ici à la liberté d'imposer ses choix, tant mieux vous
avez de la chance. Mais la réalité du monde du travail, des profits
financiers (sighh) et l'espérance de vie de IE6 (2010) fait que la mise
en forme par tableau continue a avoir plusieurs années devant elle.
Refuser d'admettre que c'est l'aspect financier qui prime sur l'aspect
sémantique des choses, c'est se voiler la face sur la réalité.

Maintenant que c'est dit, et avant que ce soit interprété forcémment de
travers, je souligne que je suis en désaccord avec cet état de fait et
que je n'utilise des tableaux que quand j'ai des données tabulées. Mais
c'est comme ça que ça se passe dans le monde réel.

Le fait est qu'un commercial est réfractaire à l'aspect
sémantique/standards/etc. de la chose, et c'est pas faute d'avoir perdu
des heures (que dis-je, des mois !) à tenter d'expliquer encore et
toujours la même chose. Et je vous parle même pas des graphistes qui
pondent du n'importe quoi avec de plus en plus d'images transparentes et
d'opacités.

Le pauvre développeur à qui on impose des dead lines irréalistes n'a
d'autre choix que de

1) ne pas faire. Risque de vite se faire dégager lui.

2) faire en 100% CSS et de temps en temps dépasser les dead line à cause
d'une connerie de pixel mal placé dans tel ou tel autre navigateur, d'un
bug d'affichage (peekaboo, guillotine, IE italics, etc), d'un colonnage
compliqué avec des background positionnés au pixel pres entre les
colonnes flottantes, etc. A force de dépasser les dead line, il risque
lui aussi de vite se faire dégager. Et c'est pas une question de
compétences, c'est juste le fait qu'il a pas le choix sur ce à quoi ça
doit ressembler. Le pixel près est certes pour nous (techniciens) une
absurdité sans nom, mais le non expert n'en a rien a faire que le code
soit propre, ce qui compte c'est son putain de pixel. Et il ne comprend
pas qu'on vienne utiliser une technique (CSS) qui ne répond pas à *son*
problème quand le neuneu avec un tableau réussi à faire ce qu'il veut.

3) faire en tableau direct tout en abandonnant l'espoir de leur faire
entendre raison. Et aucun de ceux qui le nourrisse (tout le monde n'est
pas son propre patron, il existe des employés !) n'y voit rien, ils sont
contents.

Bref si c'est encore possible, celui qui prend le choix 3 est le gagnant
au niveau de sa hierarchie et c'est tout ce qui importe réellement. Et
je crois que le choix est vite fait entre un web semantique et une
assiette remplie. C'est mal mais c'est comme ça.

--
laurent

On 21/09/2006 18:49, Laurent vilday wrote :

Arnold essaye d'expliquer qu'il *peut* arriver qu'un choix de mise en
forme soit difficilement réalisable en CSS sans figures acrobatiques et
surtout sans un réel cout financier puisque les figures prennent du
temps. Et qu'une solution utilisant un tableau est une solution
*financière* qui se pratique
moins de prises de tete == moins de temps == plus d'argent

tout dépend du niveau en CSS de l'intégrateur, du pixel près ça se fait
aussi en CSS, je n'employerais pas pour autant des tables si je devais
réaliser une telle mise en page.

--
thibaut allender | http://capsule.org | http://photo.capsule.org

Je te remercie pour ton intervention. Oh, pas parce que tu es d'accord avec
moi, mais ça fait plaisir de lire qu'au moins 2 ou 3 intervenants ont
compris ce que je voulais signifier. C-O-M-P-R-I-S ! Que l'on soit d'accord
ou pas, là n'est pas le problème, mais au mois comprendre ce que dit
quelqu'un est la base d'un débat.

Je me répète une ultime fois, loin, très loin de moi l'idée de ne pas faire
dans la norme. Seule la norme assure une perennité. Si cela avait été
possible avant, j'aurai bien volontiers utilisé du CSS et quasiment plus
d'attributs dans le code HTML. Seulement, cela n'a pas été toujours
possible, et c'est là que je me suis emporté vis à vis de personnes qui
viennent te sortir leur grosse théorie CSS-full-compliant-mort-à-IE. Comme
si le webmaster avait toujours (eu) le choix !!! Et le client ? Ils codent
depuis quand ces gens là ? Dire au client "ha non, ça je fais pas paske
c'est pas CSS ou faut un hack sous IE", c'est à mourir de rire. On fait
comme le client veut, point. Eh bien voilà, pendant longtemps, le plus
rapide, sûr et portable était de passer par les tables, et beaucoup l'ont
fait. Je me rappelle bien le début du CSS, je passais un temps considérable
à regarder quelles propriétés étaient correctement rendues par, NN, IE, OP,
etc. À l'époque d'ailleurs, un tas de sites expliquant le CSS possédaient
des tableaux avec les attributs CSS supportés par les navigateurs. C'était
folklo hein. Quiconque en a bavé sur un attribut parce que Netscape ajoutait
deux pixels, ou IE supportait pas tel type de marge comprend de quoi je veux
parler ! À croire que certains n'ont jamais eu de client leur disant "je te
préviens, faut que ça tourne à partir d'IE 5.5".

Alors voilà, on faisait avec les tables, parce que pour être direct, c'était
bien moins chiant et beaucoup plus sûr ! Les tables étaient rendues peu ou
prou de façon identiques suivant les browsers.

Je suis le premier à dire que cela est bien évidemment à proscrire en 2006 !
Quand on voit un code full-css et le vieux code avec 12.000 tables
imbriquées, ya pas photo hien ! Mais je dis également qu'il doit encore
subsister quelques cas tenaces (si le CSS2 était supporté à la perfection
par tout le monde, ça se saurait !) et que si le gars n'a pas le temps, il
résoudra le cas rapidement, avec une table ! Cela est très souvent liée avec
un coût aussi. Le gars qui a son gros site parfaitement géré avec des
tables, va-t-il tout refaire en CSS si ça ne lui apporte rien, sauf une
perte financière ? Comme l'a dit un intervenant, faire du CSS c'est un autre
mode de pensée qu'avec des tables ! Repenser un site-table en site-CSS,
c'est du boulot !!

Il est clair aussi qu'il faut séparer le webmaster indépendant de celui qui
bosse dans une grosse boîte. Ce dernier risque peu de passer 10 heures sur
le site de la W3C pour régler un conflit CSS, dans ces boîtes, tout devant
être fait pour avant hier.

Voilà. Jamais je n'ai dit qu'il fallait mal programmer !!! Ce qui me
connaissent sur d'autres forums (programmation, hacking, etc.) peuvent vous
le confirmer, je ne supporte pas le code crade, les algos foireux, les
solutions de raccroc. Simplement mes remarques portaient également sur un
contexte historique et c'est clair que ça n'a pas simplifié la clarté du
propos et je m'en excuse.

Alleez, sans rancune.

Laurent vilday a écrit :

2) faire en 100% CSS et de temps en temps dépasser les dead line à cause
d'une connerie de pixel mal placé dans tel ou tel autre navigateur, d'un
bug d'affichage (peekaboo, guillotine, IE italics, etc), d'un colonnage
compliqué avec des background positionnés au pixel pres entre les
colonnes flottantes, etc. A force de dépasser les dead line, il risque
lui aussi de vite se faire dégager. Et c'est pas une question de
compétences, c'est juste le fait qu'il a pas le choix sur ce à quoi ça
doit ressembler. Le pixel près est certes pour nous (techniciens) une
absurdité sans nom, mais le non expert n'en a rien a faire que le code
soit propre, ce qui compte c'est son putain de pixel. Et il ne comprend
pas qu'on vienne utiliser une technique (CSS) qui ne répond pas à *son*
problème quand le neuneu avec un tableau réussi à faire ce qu'il veut.

S'il est vrai que faire un site sous dreamweaver tout en table et/ou
uniquement avec du positionnement absolu, c'est très rapide, il vaut
mieux qu'à côté de ça (selon le type de site), tu sois un très bon
graphiste et développeur (je constate de plus en plus que les sites au
design soignés sont plus ou moins valides HTML/CSS alors que les sites
bien laids ou pseudo-business restent en table.)

Soit tu fais dans le 'comme avant', soit tu fais dans le 'comme
prochainement' ; tu as le choix, puisque on est encore dans le 'comme tu
veux'. Mais l'accessibilité à le vent en poupe et le référencement
devient une arme redoutable. Et faire ça en table, ça va te demander de
sacrés dépassement de deadline :)

Me concernant, je bouffe beaucoup de sites de mes concurrents (sur la
même cible que moi) en référencement. Au début tu rames, après tu as des
arguments qui pèsent lourd. Et tes arguments, contrairement à ce qu'aime
affirmer l'autre gros lourd, ce n'est pas 'mort à IE, MS c'est pourri'
(ça, c'est le contre-argument des neuneus qui pensent que l'on déteste
IE par principe : non, on aime pas ça parce que celui qui fonctionne le
moins bien - or rapidité d'exécution, puisque IE bat souvent FF sur ce
terrain - !).

3) faire en tableau direct tout en abandonnant l'espoir de leur faire
entendre raison. Et aucun de ceux qui le nourrisse (tout le monde n'est
pas son propre patron, il existe des employés !) n'y voit rien, ils sont
contents.

C'est que tu n'as pas su employer les bons arguments. C'est un métier de
savoir convaincre les gens.

Laurent vilday wrote:

Décidemment, marre de usenet. Pierre, voyons, ce n'est pas ce que j'ai
dit. Alors je reprends.

Je te remercie de détailler...

A te lire je dégage particulièrement ces passages :

Arnold essaye d'expliquer qu'il *peut* arriver qu'un choix de mise en
forme soit difficilement réalisable en CSS sans figures acrobatiques et
surtout sans un réel cout financier puisque les figures prennent du
temps. Et qu'une solution utilisant un tableau est une solution
*financière* qui se pratique
moins de prises de tete == moins de temps == plus d'argent

(...)

Toutes
les personnes qui font des sites webs - et je prend mes collègues comme
exemple puisque je constate qu'ils ont de temps en temps le problème -
n'ont *pas*, vraiment pas du tout, le loisir de déplacer un pixel de ce
qu'il leur est demandé de réaliser.

(...)

Mais la réalité du monde du travail, des profits
financiers (sighh) et l'espérance de vie de IE6 (2010) fait que la mise
en forme par tableau continue a avoir plusieurs années devant elle.

(...)

Le fait est qu'un commercial est réfractaire à l'aspect
sémantique/standards/etc. de la chose, et c'est pas faute d'avoir perdu
des heures (que dis-je, des mois !) à tenter d'expliquer encore et
toujours la même chose. Et je vous parle même pas des graphistes qui
pondent du n'importe quoi avec de plus en plus d'images transparentes et
d'opacités.

Et je comprend ceci :

1) il y a des mises en page que l'on fait par tableaux et qui sont
impossibles ou trop compliquées en CSS

2) le concepteur doit faire ce qu'on lui dit, et les réalités techniques
ne sont jamais prises en compte


Ce que j'ai à en dire :


1) Impossible de faire telle ou telle chose en CSS ?

Lorsque l'on se forme, on a en effet ce sentiment. Il faut tout
ré-apprendre... et surtout connaitre quelques hacks pour que ça
fonctionne dans IE ! Mais c'est l'opposé de la réalité ! Et c'est je
crois ce qui explique les réactions très négatives des différents
contributeurs.

Car sincèrement, avec tous les sites aujourd'hui étant passés
massivement à CSS... comment peut-on douter de l'efficacité de ces
"nouvelles" méthodes de conception ?!! Toutes les choses que l'on peut
faire en plus ! Or la légéreté que ça apporte et l'efficacité pour la
maintenance, la diversité des mises en page disponibles un peu partout
démontre qu'à peu près tout est réalisable - en tout cas, plus qu'avec
de simples tableaux.
Aussi, qui peut affirmer qu'une mise en page par tableaux se fait en 2
coups de cuillère à pot ? Avec ces "anciennes" techniques c'est très
compliqué d'arriver à un résultat "qui marche" (ce qui ne veut pas dire
grand chose mais passons) déjà dans 2 navigateurs... Le tout est qu'il y
a un grand nombre de professionnels qui ont eu quelques années pour se
casser les dents là-dessus, et que donc ils connaissent déjà...

Donc : non, cent fois non, il n'y a pas des choses que l'on fait en
tableaux et que l'on ne ferait pas en CSS : c'est tout l'inverse !
Au fond ce qui est évoquée ici c'est : en tableaux je sais faire, en CSS
c'est compliqué je ne sais pas faire. Dire autre chose à mon sens, c'est
soit de l'ignorance bornée soit une hypocrisie forcenée.

Dans un message précédent je souriais de voir que chaque débutant en CSS
envoit le même type de messages ici... c'est d'autant plus vrai que
j'étais dans cette position exactement il y a quelques années. A ma
décharge à l'époque on n'avait pas de "vraie" référence et encore moins
de retour d'expérience conséquent... Et on avait Netscape 4 !
Aujourd'hui, ça me parait vraiment difficile de camper à ce point sur
ses positions !

Pour conclure : on peut arriver à quasiment tous les résultats en CSS,
il faut par contre prendre le temps de se former, de tout reprendre à zéro.


2) Le commercial ne veut rien savoir et vend des maquettes "au pixel"
que lui conçoit le graphiste

La je vais avoir beaucoup de mal à ne pas m'énerver, ce genre de choses
m'énervent particulièrement. Dans n'importe quel business si on vend
sans se soucier des contraintes de production, on va droit dans le mur !

Les techniques de conception associées à CSS (séparation fond / forme,
structuration du contenu) imposent des bouleversements profonds dans
toute la chaine de conception, et la formation de nombreux personnels -
pas seulement l'intégrateur HTML ! Oui, c'est lourd, oui ça prend du
temps. A votre avis, pourquoi donc tant d'entreprises ont entamé ce
changement ? Par pur envie de faire plaisir à quelques représentants du
W3C ? Pour gagner en productivité, être plus efficace ?
Gardez bien à l'esprit ceci : cette discussion, ce ne sont que des mots
jetés sur Usenet, mais partout, des concepteurs ont adoptés ces
nouvelles techniques. Depuis des années ils les perfectionnent.
L'industrie du Web a changé.

Savoir prendre le temps est j'en suis persuadé l'une des principales
qualités d'un bon professionnel. Tout faire "le nez dans le guidon",
appliquer des méthodes sans réfléchir et faire au plus vite parce que
l'on n'a pas le temps"... c'est très dommageable pour l'entreprise, ça
m'énerve particulièrement et du coup ça curcharge les serveurs Usenet.

Et
je crois que le choix est vite fait entre un web semantique et une
assiette remplie. C'est mal mais c'est comme ça.

Je peux citer un grand nombre d'entreprises qui ne sont pas née hier
matin, qui ont vécu l'histoire du Web, qui remplissent très bien leurs
contrats, qui ont une excellente santé, et qui ont adopté CSS et les
techniques de conception qui vont avec (et donc tous les avantages qui
en découlent) il y a de 2 à 5 ans. Ca marche, point.
Je peut citer aussi de très nombreux cahier des charges qui jettent des
prestataires qui produiraient un HTML non structuré, impossible à
maintenir, impossible à référencer (plus rarement : ne respectant pas
les règles d'accessibilité).

Alors oui évidemment il y a de l'inertie, moi-même je suis le premier à
baigner dedans. Difficile de former autant de personnels et de faire
changer les habitudes. Difficile de modifier l'ensemble d'un produit.
Difficile.
Mais refuser de le faire "parce que l'on n'a pas le temps", parce que
l'on a trop de contrats, parce qu'il faut répondre au plus vite... Non,
ce sont de mauvaises raisons.

Oui ça prend du temps, c'est compliqué... Mais oui c'est nécessaire pour
toute entreprise travaillant avec les technologies du Web !

Arnold McDonald (AMcD) wrote:

Je te remercie pour ton intervention. Oh, pas parce que tu es d'accord avec
moi, mais ça fait plaisir de lire qu'au moins 2 ou 3 intervenants ont
compris ce que je voulais signifier. C-O-M-P-R-I-S ! Que l'on soit d'accord
ou pas, là n'est pas le problème, mais au mois comprendre ce que dit
quelqu'un est la base d'un débat.

C'est assez insultant. Vous pouvez reconnaitre que j'ai essayé de
discuter au long de ce fil, vous ne pouvez pas me reprocher les excès
que vous avez régulièrement évoqués. Une discussion, c'est un échange
entre personnes. Si l'on n'a pas "compris" vos messages... Voilà une
conception étrange de l'échange - même s'il est animé...

Je me répète une ultime fois, loin, très loin de moi l'idée de ne pas faire
dans la norme. Seule la norme assure une perennité. Si cela avait été
possible avant, j'aurai bien volontiers utilisé du CSS et quasiment plus
d'attributs dans le code HTML. Seulement, cela n'a pas été toujours
possible, et c'est là que je me suis emporté vis à vis de personnes qui
viennent te sortir leur grosse théorie CSS-full-compliant-mort-à-IE.

Il n'y a pas que la "pérennité" ! Il y a de nombreux avantageux à-côtés
: légéreté du code, maintenance grandement facilitée !
En effet, il n'y a bien que depuis que les "navigateurs 4" (IE,
Netscape) se sont vraiment raréfiés et que IE6 s'est imposé que l'on a
pu commencer à utiliser CSS. Pour les premiers, c'était environ vers
2002-2003, pour le 2eme un peu plus tard...
Et alors ? Qu'est-ce que cela change aux différents échanges que nous
avons eus ?

Comme vous le dites, vous vous êtes emporté (heureux de vous voir le
reconnaitre), et moi je n'ai pas vu dans la discussion de message
affirmant sérieusement qu'il fallait faire en CSS sans se soucier des
navigateurs n'implémentant pas à la lettre CSS2 (ce serait bien
compliqué, aucun ne le fait vraiment).

Il est clair aussi qu'il faut séparer le webmaster indépendant de celui qui
bosse dans une grosse boîte. Ce dernier risque peu de passer 10 heures sur
le site de la W3C pour régler un conflit CSS, dans ces boîtes, tout devant
être fait pour avant hier.

De ce que j'en ai vécu depuis 6 ans, je serai tenté de dire que c'est
une erreur. Les premiers à subir les pressions du marché sont les
prestataires, les web agency ou les freelance pour faire vite. C'est eux
qui voient rejettés leurs projets parce que leur HTML n'est pas valide,
ou raison similaire. C'est bien souvent le cas dans les services...

Pierre Goiffon wrote:

Arnold McDonald (AMcD) wrote:

Je te remercie pour ton intervention. Oh, pas parce que tu es
d'accord avec moi, mais ça fait plaisir de lire qu'au moins 2 ou 3
intervenants ont compris ce que je voulais signifier. C-O-M-P-R-I-S
! Que l'on soit d'accord ou pas, là n'est pas le problème, mais au
mois comprendre ce que dit quelqu'un est la base d'un débat.

C'est assez insultant.

Dis, t'y vas pas un peu fort là ? Insultant... Tu ne veux pas porter plainte
non plus ? Tu sais, nos petits engueulos à côté de la faim dans le monde
hein... Désolé pour toi, mais je le maintiens, peu ont compris ce que
j'avais voulu signfier. Je n'ai insulté personne et, s'il te plaît, garde la
notion des choses, de la relativité.

En effet, il n'y a bien que depuis que les "navigateurs 4" (IE,
Netscape) se sont vraiment raréfiés et que IE6 s'est imposé que l'on a
pu commencer à utiliser CSS. Pour les premiers, c'était environ vers
2002-2003, pour le 2eme un peu plus tard...
Et alors ? Qu'est-ce que cela change aux différents échanges que nous
avons eus ?

Cela change qu'on peut faire le malin en CSS, je veux dire, avec une
implémentation relativement fiable et un suivi potable de la norme, depuis
quoi, 2 ans au gros maximum ? Il fallait donc faire quoi avant 2003 ou 2004
(puisque tu dis plus tard pour IE, je suppute que tu veux dire 2004). Ne pas
faire de site ? Ne pas se soucier de IE ?

Olivier Masson wrote:

Et tes arguments, contrairement à ce
qu'aime affirmer l'autre gros lourd,

Tu peux éviter les insultes et remarques désobligeantes ? Pourquoi gros
lourd ? Relis-moi bien, visiblement certains on comrpis ce que je voulais
dire.

C'est que tu n'as pas su employer les bons arguments. C'est un métier
de savoir convaincre les gens.

N'importe quoi. Il n'y a à convaincre personne, il y a un travail qui doit
être fait, des désideratas de clients, un temps imparti et de l'argent. Si
le CSS permet de gagner du temps, de préparer une maintenance les doigts
dans le nez et offre une programmation plus souple, tout le monde va
l'utiliser, va foncer dessus. Il faut arrêter de prendre les gens pour des
idiots ! Maintenant, si au bout d'une après-midi le gars n'as pas réussi la
mise en page complexe du client avec des DIV, ben il fait une table.
X-repetita, c'est bien moins fréquent aujourd'hui, bien sûr, mais il éatit
difficile de faire autrement il y a encore peu.