> l'un des enjeux des CSS est
> justement de permettre une
> gestion
> facilitée des différences de
> capacité des navigateurs,
> par le biais de cette
> dégradation correcte

La note est juste et corrige moi si je trompe.

On (ou je) a pris l'habitude de prendre IE 5.x et 6.x comme de mauvais éléves (ils l'ont cherché quand même alors qu'on aurait pu les voir à la lumière de la diversité.

Jouer avec toute les diversités est en fait difficile. Les standards palient aussi cette difficulté, mais ils ne mettent pas à l'abri des nouveaux moules de pensée.

"Diversité" est peut-être un peu fort, IE étant indéniablement un des mauvais élèves CSS actuels. Mais:
- les lecteurs d'écran, par exemple, sont de bien plus mauvais élèves CSS-HTML-WAI, et pourtant, on se préoccupe avant tout de s'en accomoder.
- la question de fond pour IE est AMHA, actuellement : "qu'est-ce qui serait vraiment un obstacle infranchissable à l'utilisation avancée de CSS dans ce qu'il ne sait pas faire ?"

Bravo pour ces explications et cette technique que je n'avais encore jamais vue.

Comme je te l'ai écrit sur le Hub, j'avoue que ce principe est très convainquant.

Reste l'éternel problème de la "dégradation correcte" pour les nombreuses personnes qui **veulent** (et je peux les comprendre) que les colonnes s'adaptent aussi sur IE, ce qui n'est malheureusement pas le cas.

Un client professionnel par exemple ne validera pas un site qui ne s'affiche pas **correctement** sur IE.

Toujours dans la même idée :

perso.wanadoo.fr/sylvain....

J'ai testé sous ie6/winXP et firefox 1.0PR/winXP.
A noter qu'il manque le border du bas du tableau et là j'avoue ne pas avoir d'idée

désolé c'était stupide cela aboutit au même résultat que Laurent avait obtenuen légèrement moins bien de sûrcroit

On revient à l'éternel problème, évoqué récemment sur Cybercodeur (offline pour l'instant) , qui est celui des hacks , comme celui utilisé avec le html>body #gauche ...

Est-ce qu'on peut considéré un code "valide" lorsqu'il y'a des redondances comme ca ?

@Kevin > ne sautons pas à la conclusion au seul mot de "hack", surtout en brandissant un peu vite l'invalidité

- #gauche {float: left} est un code valide,
- html>body #gauche {float: none} est un code valide,
- les deux réunis restent valides : rien ne dit rien dans aucune spécification CSS sur la redondance du point de vue validité.

Bien-sûr, c'est un hack, même valide et des plus mineurs. Et donc potentiellement problématique. Imaginons un navigateur implémentant display:table à la manière de Mozilla, mais pas le sélecteur d'enfant : le layout se casse immédiatement la figure à cause du float.
On pourrait aussi bien (je n'ai pas testé) utiliser !important, voire le sélecteur universel... Tout hack est un risque potentiel, mais celui-ci a le double avantage de ne détourner aucune syntaxe et d'avoir des solutions de repli en cas de besoin.

Pour corriger les erreurs et les compenser ... IE7 ne serait-il pas la bonne solution ? plutot que de multiplier les hacks on aurait une couche de compatibilité.

@Eric > je n'arrive pas à être convaincu par IE7. Cette idée d'un "patch" au choix global ou ciblé est assez séduisante. Mais :
- IE7 suppose javascript... Le hack CSS ne suppose rien.
- C'est une couche supplémentaire à mettre en place, à télécharger et à traiter côté navigateur, là où les hacks CSS "minimalistes" sont beaucoup lus directs et plus simples à mettre en oeuvre. L'investissement me paraît excessif.

Tout à fait d'accord pour la W3C validité, mais je parlais de la validité que l'on accorde au code. Il est très simple de faire quelque chose de complêtement farfelu, avec des redondances, etc, et qui est validé par le W3C ... Et pourtant, si on regarde le code, on dira que c'est vraiment codé comme un cochon ...


Pour IE7, il y'a plusieurs problèmes, entre autre effectivement le Javascript, qui suppose un navigateur le supportant, mais il y'a aussi le problème de la lenteur pour effectuer les modifications ...

@Kevin > Distinguons quatre problèmes en matière de CSS :

- la validité formelle, pour laquelle le validateur W3C (par exemple) apporte une réponse immédiate,

- la validité réelle, c'est à dire ce que les limites actuelles du validateur mécanique ne lui permettent pas de vérifier,

- l'abus, c'est à dire "je fais en CSS ce qui devrait être dans le (X)HTML", généralement à coup de contenu généré et de mise en forme du balisage générique (simulation de titre avec des divs...)

- l'élégance, c'est à dire "la page est-elle valide à tous points de vue mais on pourrait franchement faire ça plus proprement".

Sinon, pour javascript, par les temps qui courent, ce ne sont pas seulement les navigateurs sans supports javascript qui sont intéressants, mais plutôt ceux où le support javascript a été désactivé pour raison (rationelle ?) de sécurité.

IE7, c'est bien un surcouche qui utilise abusivement le nom IE7 ?

@Gloom > voir dean.edwards.name/IE7/

J'ai utilisé cette technique légèrement retouchée avec un autre site sans pb, mais j'ai tenté de l'appliquer à mikeul.grandmanitou.net/d... avec un effet secondaire dont je n'arrive pas à me débarrasser sous Firefox (pas de pb avec IE).

Sur le site, le post le plus récent (en haut donc) ne colle pas au début du div de gauche (#content dans mon cas, l'équivalent de #gauche dans l'exemple).

Impossible de trouver la cause de ce décalage. J'ai modifié les marges, les paddings, j'ai même supprimé les sauts de ligne dans le code source, mais rien à faire.

Si une âme charitable peut m'aider... :o)

Il semblerait que j'ai ma réponse. La suppression d'un tableau dans la colonne de droite (le caldendrier de Dotclear) a tout ramené à sa place.

Un tableau dans un div en display:table-cell, c'est un comportement connu ?

@Mikeul> "Un tableau dans un div en display:table-cell, c'est un comportement connu ?"
Non Mais je soupçonne simplement un problème de gestion des largeurs (le calendrier DotClear ayant une largeur fixe). Auquel cas le problème serait identique avec une image de taille correspondante... A tester, donc.

Et avec 3 colones (une autre menu à droite) ?

Car j'ai du mal la..

Effectivement, pour 3 colonnes (ou plus) ayant chacune une couleur différente, on ne peut peut pas les "faire descendre" jusqu'en bas.
Dans l'exemple ci-dessus, la couleur du bas de la 2eme colonne est la meme que celle du conteneur, forcément ça aide

Si quelqu'un a la réponse...

Pour trois colonnes avec cette technique, voir test.blog-and-blues.org/c...

Toujours le même problème !
Comment faire pour avoir trois colonnes de trois couleurs différentes ?

Si on applique une troisième couleur à la colonne de droite, ça ne descend pas jusqu'en bas...

Peut-être une solution ici :
www.zdnet.fr/builder/web_...
(fonctionne sous IE6 et Firefox 1.0.x)