5568 sujets

Sémantique web et HTML

Salut,

Je tiens à préciser que tout ce que je vais dire ci-dessous fonctionne avec Opera, IE, Firefox

Mais avec netscape, le calc avec class="graph" aulieu de le mettre a droit avec float:right; il me le met au dessus du text

Car je veux afficher a gauche le texte puis qui continue en dessous comme ici

http://raynox.homelinux.com/projet/?page=2

Mais ca me saoule Netscape 7 veut pas fonctionner normalement Smiley decu

XHTML

<div class="graph"  style="float:right;">
<form action="?page=4" method="post">
	<a href="?page=3"><img src="contenu/produit/graph-img.php?id=4" alt="Cliquer ici pour avoir le graphique en plus grand" /></a>
	<br />
	<input type="text" name="nombre" value="1" size="3" /><input type="submit" value="Ajouter" />
</form>
........ text divers ici ......
</div>


CSS

.graph
{
float: right;
margin: 20px 20px 10px 10px;
border: 0px;
width: 255px;
text-align: center;
vertical-align: middle;
display:table-cell;
}



Merci
Smiley eek
Bonjour,

L'affichage fonctionne correctement sous NS7.2.

au passage : le display:table-cell et le vertical-align sont inutiles. Le bloc étant flottant, il obligatoirement en display-block.
ah ok merci de l'info, mais pour ce qui concerne Netscape c'est la version 7.0 mais bon je peux rien y faire

merci Smiley biggrin
Raynox a écrit :
ah ok merci de l'info, mais pour ce qui concerne Netscape c'est la version 7.0 mais bon je peux rien y faire

merci Smiley biggrin


À tout hasard, je demande : quelle est l'utilité de Netscape 7 aujourd'hui ? Pour un utilisateur, il y a peut-être des avantages (ne serait-ce que l'habitude !), mais pour tester une mise en page ?

Avec le nombre de navigateurs sur le marché, la compatibilité totale est une illusion. Les choix stratégiques seront donc plutôt de l'ordre de :
- il faut que ça soit standard, pour que ça passe dans Firefox, Safari, Konqueror, Opera...
- il faut que ça soit compatible Internet Explorer 6, pour des bêtes questions d'audience.
Une fois ces deux problèmes réglés, et à moins d'utiliser des choses un peu poussées qui demanderont de fignoler la compatibilité pour un certain nombre de navigateurs (même ceux plutôt conforme avec les standards : il ne suffit pas d'être de bonne volonté pour bien implémenter les spécifications du W3C... qui d'ailleurs sont parfois trop vagues pour qu'on puisse les implémenter de la même manière dans chaque logiciel !), on aura un site qui passe bien pour 98-99% des utilisateurs.

Faut-il vraiment rajouter Netscape 7 à la liste ?
mpop a écrit :

(même ceux plutôt conforme avec les standards : il ne suffit pas d'être de bonne volonté pour bien implémenter les spécifications du W3C... qui d'ailleurs sont parfois trop vagues pour qu'on puisse les implémenter de la même manière dans chaque logiciel !)


Et les régressions CSS de firefox 1.5... N'oublions pas les régressions CSS de Firefox 1.5, sur des points totalement dénués d'ambiguité dans CSS2.1 (propriété clear dans un fieldset, par exemple) Smiley rolleyes

(C'est bon d'être politiquemennt incorrect quand ce navigateur de plus en plus mal développé vous a fait perdre 1h30 sur un projet où chaque minute compte Smiley lol )
Modifié par Laurent Denis (27 Dec 2005 - 13:32)
Laurent Denis a écrit :


Et les régressions CSS de firefox 1.5... N'oublions pas les régressions CSS de Firefox 1.5, sur des points totalement dénués d'ambiguité dans CSS2.1 (propriété clear dans un fieldset, par exemple) Smiley rolleyes

(C'est bon d'être politiquemennt incorrect quand ce navigateur de plus en plus mal développé vous a fait perdre 1h30 sur un projet où chaque minute compte Smiley lol )


Ou le fait que les éléments flottés ou positionnés en absolu sortent du flux du body... ce qui fait qu'une image de fond de body positionnée en bas se retrouve plus haut que le contenu total de la page Smiley biggol
Pas cool...

C'est vrai que la politique du "hop je reviens en arrière" fait parfois de beaux dégâts.
Bonjour,

mpop a écrit :


Ou le fait que les éléments flottés ou positionnés en absolu sortent du flux du body... ce qui fait qu'une image de fond de body positionnée en bas se retrouve plus haut que le contenu total de la page


Pourrais-tu préciser ou donner un exemple de flottant et un exemple positionné ?

En effet, dans le cas d'éléments en position absolue, ce comportement est a priori normal : le calcul de la hauteur de l'élément body exclut ses enfants en position absolue, comme le ferait n'importe quel autre conteneur.

Dans le cas de flottants, FF considère que la valeur d'overflow de body est toujours ramenée à auto, ce qui ré-introduit les enfants flottants dans le calcul de sa hauteur. Opera 8.5, en revanche, nécessite qu'on précise la valeur overflow: auto pour les éléments html et body (Mais la preview Opera 9.0 semble avoir régressé sur ce point)...

(Internet Explorer Win, lui, intègre toujours les éléments positionnés ou flottants dans le calcul de la hauteur de body, en raison du haslayout par défaut de cet élément. Là, il s'agit donc d'un bug)
Modifié par Laurent Denis (28 Dec 2005 - 09:51)
Laurent Denis a écrit :
Pourrais-tu préciser ou donner un exemple de flottant et un exemple positionné ?


Alors voilà, je t'ai pris au mot, et comme j'avais rien sous la main j'ai fait un petit exemple :
http://ulines.free.fr/temp/testbodybg/

Explications
- On peut voir le html et le css en affichant la source (c'est du tout en un).
J'ai mis du javascript un peu encombrant Smiley ohwell pour afficher / cacher des blocs qui ont tous les même caractéristiques, sauf pour le positionnement.
- l'élément html a un background gris, et l'élément body a un background blanc et une image de fond attachée en bas et répétée en horizontal (le petit dégradé). Si je n'indiquais rien pour html, il prenait les caractéristiques du background du body, et parfois j'avais deux images de fond, l'une en bas, l'autre au milieu de la page ! Smiley biggol Bizarre quand même Smiley sweatdrop

Observations :
- pas de surprise avec le positionnement normal (encore heureux !)
- le positionnement relatif fonctionne comme le positionnement normal, sauf que le décallage donné au bloc fait sortir d'autant le bloc du flux du body.
- le positionnement absolu fait sortir le bloc du flux du body.
- un bloc flotté sort également du flux du body ! Mais contrairement à ce qui se passe avec le positionnement absolu, on peut corriger cet "effet secondaire" en plaçant à la suite de l'élément flotté un élément avec la règle "clear: both;"

Remarques :
- je n'arrive pas à réduire la fenêtre de Firefox en dessous de environ 1100 pixels (je suis en 1280) sans que la page "bloque" à un moment sur une largeur fixe Smiley eek , comme si j'avais une largeur minimum à ma page (il me semble pourtant rien avoir mis dans le code pour ça !...)

Et voilà...
Modifié par mpop (29 Dec 2005 - 04:08)
Le comportement est tout à fait normal pour le flux, la position relative et la position absolue :
- prise en compte de la hauteur de l'élément en flux
- prise en compte de la hauteur de l'élément en position relative, mais "comme s'il était placé en flux, avant d'être décalé".
- pas de prise en compte de l'élément en position absolue.

Pour le flottant... la page est très élégante, mais c'est un test faussé par ce souci d'élégance Smiley cligne

Les tests d'implémentations sont toujours limités au strict minimum, afin que rien ne vienne jouer les parasites. Ici, le javascript est de trop pour un test CSS : ta page ne met pas en évidence un bug CSS sur le flottant sorti du flux, mais un bug de reflow lié au onmouse.over, qui provoque à la fois le mauvais rendu de l'image d'arrière-plan et le comportement si html n'a pas de couleur de fond. Effectivement, il suffit d'une étape supplémentaire dans le reflow pour compenser ce bug : l'ajout via le onmouse.over d'un élément doté de la propriété clear ou d'un overflow-auto sur body.

Le comportement de FF sur l'image+flottant est en revanche tout à fait normal une fois le test débarassé du javascript : on ne voit plus d'arrière-plan repeint deux fois si html n'a pas de couleur de fond, et l'image se place correctement en fonction de la hauteur du flottant.
Laurent Denis a écrit :
Pour le flottant... la page est très élégante, mais c'est un test faussé par ce souci d'élégance Smiley cligne

Alors on va limiter un peu :

Sans javascript, avec plusieurs pages et élément html à fond grisé :
http://ulines.free.fr/temp/testbodybg1/

Le même, sans propriétés CSS pour l'élément html
http://ulines.free.fr/temp/testbodybg2/

Ça permettra de comparer.

Par contre s'il existe des ressources en ligne sur l'interraction entre CSS et les éléments html et body, je suis preneur !
Bonsoir,

Ah, on progresse en effet Smiley smile .

Désolé, je n'avais pas vu l'importance d'un autre détail de ta page qui conditionne aussi le test : le background de html.

Pour les ressources, voir http://www.w3.org/TR/CSS21/colors.html#q2 et les billets d'Anne Van Kesteren sur le canevas ( http://annevankesteren.nl/2004/02/canvas et http://annevankesteren.nl/2004/05/viewport-canvas-root ), ainsi que les test de Yan Hixon (pas les urls sous la main, désolé). Il y a également une série de test de PPKoch sur body, html et le background, quelque-part dans http://www.quirksmode.org/ ). Mais l'article faisant clairement le point sur canevas, body, html et conteneur initial reste à écrire, dans la mesure du possible.

Quoi qu'il en soit, CSS2.1 prévoit clairement une recommandation (pas une obligation) :

CCS2.1 a écrit :
For HTML documents, however, we recommend that authors specify the background for the BODY element rather than the HTML element. For HTML documents whose root HTML element has computed values of 'transparent' for 'background-color' and 'none' for 'background-image', user agents must instead use the computed value of those properties from that HTML element's first BODY element child when painting backgrounds for the canvas, and must not paint a background for that BODY element. This does not apply to XHTML documents.


Lélément body ne joue obligatoirement son rôle magique en HTML (et en XHTML traité comme du HTML - c'est le cas ici) que dans la mesure où aucun arrière-plan (couleur ou image) n'est spécifié pour l'élément racine html :
- sans le html {background: gray;}, l'arrière plan de body est utilisé pour peindre le canevas; L'image d'arrière-plan positionnée à bottom pour body va "descendre" en fonction du flottant. Tout va bien.
- avec le html {background: gray;} (dont CSS2 déconseille l'usage), c'est l'arrière-plan de html qui peint le canevas. Et c'est l'éventuelle image d'arrière-plan positionnée à bottom pour html qui descendra pour "englober" le flottant (tout ira bien). Mais pas l'image d'arrière-plan similaire pour body (c'est l'exemple de ta page test, et tout va mal)...

Autrement-dit, ta page avec son background sur body rentre dans la zone d'incertitude de CSS2.1 appliquée aux document HTML (et XHTML traités comme tel).

Mais là encore, le comportement de FF me semble conforme à CSS2.1, puisqu'il n'a pas à faire jouer "magiquement" le body. Opera a d'ailleurs le même comportement, si je me souviens bien....
Modifié par Laurent Denis (29 Dec 2005 - 17:20)
Laurent Denis a écrit :
Mais là encore, le comportement de FF me semble conforme à CSS2.1, puisqu'il n'a pas à faire jouer "magiquement" le body. Opera a d'ailleurs le même comportement, si je me souviens bien....


Merci d'abord pour toutes ses précisions.

J'avais remarqué une différence entre Firefox 1.0.x et Firefox 1.5 (me souviens plus des versions de gecko incriminées), dans le cas d'un élément positionné en absolu. Pour être plus clair, ça se passe ici :
http://ulines.free.fr/sophietest/

Le background de <body> est positionné en bas à gauche avec la règle suivante :
background: white url(../img_layout/page_bottom.jpg) left bottom no-repeat;


Avec Firefox 1.5, l'élément positionné sort du flux du body. Avec le 1.0.x, l'image de fond allait bien jusqu'en bas... comme je n'y voyais pas de raison, j'avais pensé à une régression (d'après ce que j'ai lu récemment au sujet d'IE ou d'Opera, c'est pas si rare que ça !), mais il se pourrait que ça soit au contraire une application plus stricte des spécifications.