Crasher un site en 3 leçons

Aujourd’hui nous allons découvrir comment on peut arriver à faire crasher un site tout en respectant les standards.

1. Acheter une de ces machines pas très sexy, qui nécessitent une demi-journée d’installation et des heures de mises à jours… Bref, faites l’acquisition d’un PC équipé de Windows XP et installer Internet Explorer 6… Comment? Il est installé par défaut?! Quelle idée… 😉
2. Construiser votre site en prenant soin de produire un code bien valide et en respectant les recommandations en terme d’utilisation des balises XHTML. Durant cette étape, il y a beaucoup de chances que vous ayez à construire un menu et que celui-ci contienne des liens. Pour peu que vous cherchiez à faire un menu un peu travaillé, vous utilisirez certainement un code similaire à celui-ci:

<ul>
<li><a >Lien Menu 1</a></li> <li><a >Lien Menu 1</a></li>
</ul>

et un CSS similaire à celui-ci:

ul { position: relative; width: 200px; height: 35px; ... }
li { width: 25px; height: 35px; ... }
a { width: 25px; height: 35px; display: block;
background-image: url('mon_fond_de_bouton.jpg'); ... }

On pourrait discuter sur la syntaxe et l'emploi du backgroun-image dans le a, mais soyons consistant: pourquoi mettre le background du bouton dans le li alors que son contenu est lié à la balise A (ex.: si l'image contient le texte du lien)?

Avec ce code, vous obtenez un zoli menu et si vous ajouter un A:hover dans le css, vous le rendez même un rien dynamique.

3. Installer le magnifique, pratique, léger, facile à employer, cool,... Moo.fx ou Moo.tools, c'est kiffe-kiffe... Utilisez donc ce magnifique librairie Javascript pour animer votre menu et commencez à naviguer sur le site... BOOOM! Le site freeze, ne répond plus, affiche parfois une erreur 404 et il ne vous reste plus qu'à redémarrez IE en vidant au préalable sa cache.

Mais alors, que s'est-il donc passé? Revenons sur les 3 étapes:

1. Il semblerait que certaines versions de IE (6.xxx) présentent un bug au niveau de l'affichage de la balise A (dixit Quirksmode.org). En deux mots: si vous utilisez le display:block et le background-image dans la balise A, combiné (mais ça peut foirer sans ça) avec un conteneur parent (ici, ul/li) en position:relative et vous remarquerez alors que IE fait clignoter un peu le lien lorsque vous passez dessus avec la souris!

Quand on sait, que le display:block et le background-image sont quasiment (ok, il y a le line-height, aussi, mais c'est moins logique) indissociables pour afficher un lien avec la taille de son arrière-plan, on se demande comment IE peut produire un tel bug.

Jusqu'ici rien de grave, IE fonctionne bien même avec ce bug mais...

3. L'utilisation de Moo.fx semble provoquer, combinée avec le bug ci-dessus, une utilisation anormale de mémoire par IE qui causerait alors le "crash" expliqué ci-dessus. Moo.fx avait déjà rencontré ce genre de problème mais le bug avait été corrigé directement et les étapes ci-dessus emploient la version corrigée. Le plus marrant, c'est que même si le bug du A (cf. point 1.) a lieu sur un lien non présent dans le menu animé, il suffit que le menu soit en cours de déroulement quand vous passez sur le lien et Booom!

La solution?

Elle est très simple: Intégrer votre background-image dans une autre balise mais laissez le display:block dans la balise A. Dans notre exemple:

li { width: 25px; height: 35px;  background-image: url('mon_fond_de_bouton.jpg'); ... }
a { width: 25px; height: 35px; display: block; ... }

Et quand il n'y a pas de LI pour y insérer le background-image? Dans ce cas, on utilise une image à la place du lien :

<a ><img /></a>

Bien sûr, tout ceci n'est vraiment utile que si on emploie Moo.fx ou un outil similaire. personnelement, même si cela ne concerne qu'un faible pourcentage des navigateurs, je préfère prendre le pli de ne plus utiliser le background-image et le display:block dans la balise A. D'ailleurs, en faisant un petit tour sur des gros sites CSS, on se rend compte qu'ils sont souvent développés en évitant de provoquer le bug A.