hibou57 a écrit :Pascal
J'ai esssayé comme ça, avec une définition pour « .header p », effectivement ça marche. Merci.
« .header p » est une notation css2 si je ne me trompe pas... y at-il aussi un moyen d'obtenir la même chose avec css1 ?
C'est un sélecteur css1. tous les navigateurs actuels supportent d'ailleurs CSS1 + au moins une grosse part de CSS2, en fait tous les navigateurs actuels ont un excelent support de CSS2 sauf IE qui a pas mal de bugs, mais ces bugs étant documentés et contournables assez facilement rien n'empêche aujourdéhui d'utiliser CSS2.
Mais je comprends pas une chose : la classe header s'applique à un bloc div, et le p est contenu dans le div, donc comment pouvait-il ajouter une marge externe au div ? (je ne sais pas si j'exprime bien ma question, alors je reformulerai si je ne suis pas compréhensible)
C'est ce qu'on appelle en css les "collapsing margins", deux blocs consécutifs sans bordures ni contenu ont leurs marges qui fusionnent, la margin-top du paragraphe est fusionné avec le margin-top du div puisque ce div n'a ni bordure ni contenu avant le paragraphe (c'est un des points complexes de CSS2, je te le concède). Le comportement d'IE est donc buggué puisqu'il n'a pas fusionné les marges comme le demande la norme.
Comme tu as l'air de bien connaître, je me permet quelques autres questions, si je n'abuse pas.
Pas de problème, ne t'offusque pas si je suis sec, c'est ma personnalité, pense seulement que j'ai déjà répondu à ce type de question une bonne centaine de fois cette année en fait, à force ça lasse
Tu dis que la DTD est incomplète ? J'ai repris la déclaration qu'utilise mon N|vu. Pourquoi est-elle incomplète ? C'est par que c'est une DTD de transition ? Je l'utilise pour la compatibilité avec les anciens navigateur (fondamental dans mon état d'esprit) : ce n'est pas une bonne chose, ou ce n'est pas la meilleure manière ?
C'est ok de faire du transitionnel (même si à mon avis ça cause plus de travail que de bénéfice), mais la bonne DTD est :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"
http://www.w3.org/TR/html4/loose.dtd">
A la base NVU est fait pour faire du code valide en strict (HTML4 ou XHTML). Je pense que Daniel a mis cette dtd incomplète dans un soucis de compatribilité avec la reprise de pages créées dans d'autres outils. Personnellement je trouve ça idiot parce que ça provoque l'utilisation dans les navigateurs du mode "Quirks" (bizarreries en anglais). C'est à dire un mode où les navigateurs affichent dans un mélange de respect des normes et de bidouilles d'avant la normalisation. Quand on a un site à reprendre qui date d'il y a longtemps, ça se justifie, quand on commence à zéro quelque chose il n'y a aucune raison d'utiliser un mode quirks et quasiment aucune d'être en transitionnel.
Je note pour la casse des lettre, même si je n'envisage pas de transition vers xhtml, car je vise la compatibilté avec les anciens navigateur : je tiens à ce qu'on mon site soit accessible à tous/toutes, au sens populaire du terme, c'est-à-dire même par les catégories sociales défavorisées, qui sont équipé avec d'ancien pc et d'ancien logiciel, et qui ne passe par leur temps à bricoler sous linux...
Les anciens navigateurs ne prennent pas en compte les minuscules/majuscules, aucun dégâts donc pour eux. maintenant il faut définir ce qui est ancien pour toi, tu remontes jusqu'où ? personnellement je zappe NS4 et IE4, ils ont accès à mes pages mais sans aucune feuille de style donc ils ne sont pas rejetés, mais bon, si j'ai eu 10 visites sur 300.000 cette années avec des trucs aussi vieux c'est bien le maximum...
Si tu vises IE5+/Gecko/Opera/Safari, il n'y a aucun avantage à se limiter à css1. Il existe par ailleurs des navigateurs modernes gratuits très performants pour de vieilles machines, on pourra citer Kmeleon pour windows 95 qui a le même moteur que Firefox, il n'y a donc pas d'excuse de fracture sociale possible, ou alors il faut aussi décider d'être compatible avec Netscape 3, voire Mosaic...
Ok pour la zéro, je suis d'accord, c'est logique. Mais mettre une unité ne mange pas de pain. Well, passons.
Dans ce cas là je mettrais plutôt des points ou des pixels vu que le % n'est pas une unité de mesure par défaut des navigateurs.
Par contre je n'ai pas bien compris la remarque sur les positions relative, parce qu'il faut quand même bien précisé une coordonnée relative, c'est-à-dire un offset, un déplacement.
Top et left s'appliquent à du positionnement absolu, quand tu utilises du positionnement relatif c'est que tu veux que ton block soit pris en compte dans le calcul de hauteur du flux, il est donc plus logique dans ce cas d'utiliser des margin-top et margin-left. Le calcul du positionnement de top et left avec un block en relatif est particulier :
Computed value: for 'position:relative', see section Relative Positioning. For 'position:static', 'auto'. Otherwise: if specified as a length, the corresponding absolute length; if specified as a percentage, the specified value; otherwise, 'auto'.
This property specifies how far an absolutely positioned box's top margin edge is offset below the top edge of the box's containing block. For relatively positioned boxes, the offset is with respect to the top edges of the box itself (i.e., the box is given a position in the normal flow, then offset from that position according to these properties). Note: For absolutely positioned elements whose containing block is based on a block-level element, this property is an offset from the padding edge of that element. "
Pour le 100%, c'est bien ce que je signifiais... le contenant est implicite... d'autant que dans mon exemple, le contenant est bien le document lui même... Donc il s'agit bien de la totalité de la largeur disponnible au sens absolue. Dans ce cas précis du moins.
Quel est l'intérêt par rapport à un margin:auto qui est la valeur par défaut d'un élément de type block et qui fait excatement ça sans causer de problèmes de barres de défilement intempestives?
Pour résumer : le plus important est de faire du code ultra-simplifié, c'est plus efficace, plus lisible et ça permet de repérer les sources de vrais problèmes bien plus rapidement. Par qilleurs, travailler en mode strict force IE6 à se comporter presque bien, beaucoup de ses bugs disparaissent dans ce mode, donc ça n'a que des avantages, le seul prix étant une plus grande rigueur à avoir dans sa syntaxe.
. Ca ne m'a pas surpris, parce que les dimmension doivent être fourni pour la class header, et non pas pour les éléments html et body.