Amalgame a écrit :
Le fait de mettre en forme mon code vient modifier moa page.
Hmm... oui et non.
Voici un petit exemple :
<p><span>alsacreation</span><span>s</span></p>
<p><span>alsacreation</span> <span>s</span></p>
<p>
<span>alsacreation</span>
<span>s</span>
</p>
On obtiendra le rendu suivant :
alsacreations
alsacreation s
alsacreation s
On remarque que le cas où les deux span sont séparés d'une espace donne le même rendu que lorsque le deuxième span passe à la ligne.
Il faut se rappeler qu'en HTML, une suite d'espaces sera, par défaut, tronquée à UNE espace maximum. On peut donc, dans le code, espacer les mots autant que l'on veut, on n'aurait toujours qu'une seule espace entre deux mots. À noter que ce type de rendu peut être modifié via un élément
pre ou la propriété CSS
white-space (
http://wiki.media-box.net/documentation/css/white-space ).
Je viens de parler d'espace (qui correspond à un caractère précis), mais il s'agit en fait de tous les « espaces blancs », qui comprennent : l'espace, la tabulation, le retour à la ligne (les retours à la ligne ?).
Bref, les deux notations suivantes sont équivalentes :
1)
<span>alsacreation</span> <span>s</span>
2)
<span>alsacreation</span>
<span>s</span>
Ici, c'est le retour à la ligne (retour chariot) qui est interprété comme une espace.
Précisons avant tout affolement
Ce n'est pas parce qu'un code est indenté que des espaces inopportuns vont apparaître un peu partout sur une page !
Les espaces, tabulations et retours chariot entre deux éléments de type bloc (div, p, hN, ul, li, etc.) seront ignorés. De même, les espaces blancs en début et en fin d'un élément de type bloc (au début ou à la fin d'un paragraphe
p, par exemple) ne seront pas rendus. Les seuls espaces blancs qui seront rendus sont ceux qui séparent des éléments de type en-ligne ou des chaînes de caractères.
Un exemple courant : si vous voulez obtenir une succession d'images de petite ou moyenne taille sur une même ligne, vous pouvez écrire :
<p><img src="anywhere/hophop/images/sentence/first.png" alt="Ceci" /><img src="anywhere/hophop/images/sentence/second.png" alt="est un" /><img src="anywhere/hophop/images/sentence/third.png" alt="exemple" /></p>
Mais comme le code pour les informations des images (texte alternatif, emplacement de l'image) est un peu long, on aura tendance à les mettre sur plusieurs lignes de code :
<p>
<img src="anywhere/hophop/images/sentence/first.png" alt="Ceci" />
<img src="anywhere/hophop/images/sentence/second.png" alt="est un" />
<img src="anywhere/hophop/images/sentence/third.png" alt="exemple" />
</p>
Les deux notations ne sont pas équivalentes. Il faut imaginer que chaque image est un caractère : « a », « b » et « c ». Si on écrit « a b c », ça n'est pas la même chose que si l'on écrit « abc » !
On aura donc, dans le cas du code sur plusieurs lignes, des espaces entre les images. Si on voulait que les images soient complètement collées, c'est raté.
Un cas-limite : espaces excédentaires entre des items de liste avec IE Win
Laurent denis détaille le cas de la
prise en compte des espaces non significatifs dans les listes dont les items sont dotés de layout.
Il s'agit d'un bug très particulier d'Internet Explorer Windows, mais que l'on rencontre souvent tôt ou tard, et qui se manifeste par des items de liste (souvent ceux d'un menu de navigation vertical) qui s'écartent très fortement en hauteur, de façon inexpliquée.
Le bug (détaillé, avec une solution, dans la page du lien ci-dessus) fait que les espaces non significatifs (retours à la ligne, tabulations, espaces) deviennent des lignes vides entre les items de liste, ce qu'ils ne sont pas censés faire, bien entendu !
On résoud ce bug soit en combattant le mal par le mal (cf. la notion de HasLayout, et la solution proposée), soit en supprimant ces espaces non significatifs (ce qui peut faire un code difficile à lire et à gérer), mais uniquement pour les éléments problématiques, pas pour toute la page, bien entendu !
Modifié par mpop (15 Sep 2006 - 00:05)
