LaurentDenis

Le billet de Karl pointe bien le problème de bcp de gens qui se lancent dans la mise en page full-CSS : il y a une étape décevante, où le résultat n'est pas bon. A ce stade, il faut, je crois, faire sa petite révolution culturelle : Le design CSS est par nature "mouvant", car le positionnement (source de la plupart des déceptions et des difficultés) est beaucoup plus élastique que dans un tableau. Les données sont positionnées selon le flux, avec des déplacements (positions relatives et float) ou carrément extraites du flux (positions absolues et fixes). Et les moteurs de rendus ont leurs caprices et leurs traits de caractères personnels. Un moyen de faire cette petite remise en cause est d'abandonner (temporairement) les unités absolues (pixels) et de ne travailler qu'en em, puis en % (les em sont plus faciles à manier). Il faut avoir cette élasticité en tête et renoncer à "figer" la page dans des dimensions et une disposition qui en ferait un document de verre. La page est fluide...

La page échoue également sous konqueror, IE5mac... C'est le bon vieux problème du box-model qui ressort. En résumé, à cause d'une interprétation défectueuse du mode de calcul des largeurs/hauteurs dans IE5, les navigateurs plus récents ont deux modes de calculs rivaux des largeurs/hauteurs. Ils adoptent l'un ou l'autre selon le type de standard de la page (HTML / XHTML / strict / transitional ...). Pour approfondir, voir http://openweb.eu.org/articles/dimensions_boites_css/ Opera (et les autres ci-dessus) utilise ici le mode de calcul "IE", où la largeur disponible dans le conteneur "main" est trop petite pour le contenu. Solution expéditive : Faire passer Opera en mode "strict" de calcul des largeurs, à l'aide d'une règle CSS3: .main { box-sizing: content-box; } ça ne règle le problème que pour Opera 7+ Solution de fond : supprimer le padding pour le conteneur main, le remplacer par une marge équivalente appliquée aux div intérieures ; virer la largeur spécifiée pour les div intérieures. ça donne grossièrement : .main { position : relative; left : 20%; min-height : 100%; width : 728px; font-size : 10px; background : white; padding : 25px 0 20px 0; border : 0 none #333333; border-style : none solid; margin-left : -130px; } .heading { padding : 10px 0 15px 0; margin: 0 15px; border-bottom : 1px solid #d9d9d9; } .search { margin: 0 15px; padding : 15px 0; border-bottom : 1px solid #d9d9d9; } .text { margin: 0 15px; padding : 15px 0; border-bottom : 1px solid #d9d9d9; } .form { margin: 0 15px; padding : 15px 0; border-bottom : 1px solid #d9d9d9; } .categories { margin: 0 15px; background : #f7f7f7; padding : 15px 0; border : 1px solid #d9d9d9; border-top : 0 none inherit; overflow : hidden; } .pages { margin: 0 15px; padding : 15px 0; border-bottom : 1px solid #d9d9d9; overflow : hidden; } etc... A affiner... Mais ça règlera le problème pour tous les navigateurs. En fait, autant éviter les positionnements en largeur au pixel près : c'est l'intérêt des unités relatives (em, %) qui facilitent la mise au point d'un design "fluide" qui variera d'un navigateur à l'autre, sans dégradation gênante cependant. D'autre part, il faudrait supprimer le javascript de détection du navigateur, erroné et inutile, la même feuille pouvant être servie à tous... Et gros défaut : la page n'est plus stylée si javascript est désactivé dans le navigateur

Hum... Je crois que tu as simplement mélangé un "none" et un "underline" quelque-part, ou fait une faute de typo. Avec : a:link { color: #cc3300; text-decoration: none;} a:hover { color: #fff; text-decoration: underline overline;} a:active { color: #ff0000; text-decoration: line-through;} a:visited { color: #cc3300; text-decoration: none; } Les liens déjà visités ne sont pas soulignés et apparaissent en rouge (FireFox, IE6, Opera, sous Windows)

Ce n'est vrai qu'à première vue, et temporairement. Les utilisateurs sans expérience visuelle de la page existent déjà, et vont se multiplier : - moteurs de recherche - feedreaders "forçant" un RSS quand le site n'en a pas. - traducteurs automatiques - robots de spam - lecteurs d'écran, et pas seulement du type Jaws. Voir le projet Opera-IBM de navigateur pilotable à la voix, dont la suite logique sera le navigateur avec lecture de la page à la demande. ... La page XHTML est plutôt à voir comme une source indépendante du media.

Ceci n'est pas une question "technique", mais plutôt une invitation à réfléchir sur le couple HTML-CSS. Récemment arrivé ici, ayant lu pas mal des sujets précédents, j'ai l'impression qu'une partie des difficultés rencontrées avec CSS tient moins à leur apprentissage qu'à une erreur d'approche générale. CSS est conçu pour styler un document HTML (ou XHTML ou XML) bien formé. Ce qui n'exige pas seulement qu'il soit formellement valide (approuvé par le validateur du W3C). Une page peut être formellement valide, mais avoir une structure illogique. L'étape strictement "HTML" est parfois négligée. Elle doit, AMHA, se faire avec en tête la création d'une source pas spécialement destinée à un média ou à un autre, autrement dit, en oubliant les navigateurs graphiques et CSS. Le meilleur outil pour vérifier que la page en question a une structure solide indépendamment du rendu, c'est un navigateur texte (Faute de mieux peut-être). Si la page est bien rendue dans Lynx, c'est un gage de qualité. Le matériau HTML est bon, on peut alors passer à la couche CSS. Cela correspond-il à votre expérience de découverte des CSS ?

Hum... La vrai solution me semble plutôt du côté des requêtes à la BD... Ne serait-ce que parce que la page risque de perdre son sens dans un média qui ignore la bidouille CSS et qui s'en tient au flux HTML. Les quelques bidouilles possibles ne sont pas enthousiasmantes : - fixer une hauteur constante à ton bloc 2. Le support de height étant assez mauvais dans pas mal de navigateurs, il faut passer par un display: table-cell. Pas très joli quand le contenu de bloc2 est petit... - jouer sur z-index et :hover pour qu'au passage de la souris sur le bloc 1, il réapparaisse "sur" le bloc 2. Surprenant et pas très intuitif pour l'utilisateur. Mais les deux blocs n'étant pas "en flux" (c'est à dire dans l'ordre du code HTML), CSS-HTML ne fournit aucun moyen de calculer la position du bloc 1 relativement à la taille verticale du bloc 2.

C'est impossible via CSS. Les images d'arrière-plan sont plutôt supposées être d'une taille propre à "passer" dans toutes les résolutions courantes. Et avec CSS2, on utilise plutôt les motifs répétés quand il s'agit de couvrir toute la surface d'affichage... 1600*1200 n'est pas vraiment un format ... passe-partout ;-)

Pourrais-tu être un plus précis sur la structure de ta page ? Pourquoi ton bloc 2 n'est-il pas naturellement avant ton bloc 1 dans ton code HTML ? Même si CSS permet de mettre une page cul par dessus tête, dès lors qu'il y a une logique d'organisation, elle doit se retrouver aussi bien dans le code que dans le rendu visuel.

L'un des avantages d'une mise en page sans tableau, c'est l'élasticité... Pourquoi ne pas abandonner ces rigides 750px et passer à une largeur relative en % (centrage par des marges) ?

Hum... Il existe une solution, franchement bourrin : - Prévoir une div class="exemple" englobant la zone en question - Placer dans une feuille de style permanente (appelée par un link sans title) les règles nécessaires pour imposer à tous les éléments de cette div la présentation "par défaut" à peu près commune à tous les navigateurs. Les règles CSS nécessaires sont listées dans une des annexes de la spécification CSS2. - Ajouter !important à chacune - Compléter au cas par cas pour éliminer les styles qui passeraient à travers. - Veiller à ce que cette feuille soit appelée en dernier, pour régler les conflits de priorité CSS. - La mettre à jour régulièrement quand on modifie un des styles de la page... Bien compliqué pour pas grand-chose, ça. C'est pour ça que l'on place généralement les exemples dans une page à part, ce qui a un autre avantage : le lecteur s'y retrouve plus facilement quand il veut regarder le code source, cette page à part étant minimale...

Sibelius, tu fais bien de prévenir sur les div inutiles là où il suffit de styler les éléments HTML. Pour compléter, il faut rappeler une erreur similaire, celle du pseudo-balisage généré via CSS. On a parfois envie de remplacer un tag HTML par une div. Exemple type, les pseudo-listes générées avec display:list-item. Voir http://www.blog-and-blues.com/2004/mars/04...HTML_et_CSS.asp (Désolé de renvoyer chez moi, mais je fais court)

Non, et les quelques ruses possibles (un title sur le paragraphe par exemple) n'auraient aucun sens, pour des raisons d'accessibilité et de sémantique : - ou bien cette image a un sens important dans le contenu de la page, et elle ne doit justement pas être en contenu généré CSS. Elle doit être placée dans un simple élément img ; - ou bien elle est strictement décorative... et n'a pas besoin d'être restituée dans les médias non graphiques. Voir http://openweb.eu.org/articles/accessibilite_images/ La solution est de: -modifier l'image pour n'en conserver que l'aspect décoratif. -et replacer le texte du titre... dans le titre hx approprié ;-)