Alt-I, des informations alternatives - IE SUX

Tarte aux trois CSS

Hadrien — Tue, 31 Aug 2010 11:57:00 +0200

Les CSS dans leur troisième version apportent tout un lot de propriétés qui font gagner énormément de temps à l'intégration de design. Parmi celles-ci, on retrouve border-radius, permettant d'arrondir les angles des boites, linear-gradient qui ajoute un dégradé en tant que fond d'un élément, ou box-shadow qui lui applique une ombre. Toutes ces propriétés permettent de rationnaliser ces différents effet qu'on bidouillait auparavant à l'aide de div et de span imbriqués avec des morceaux d'images de fond pour simuler une ombre ou un coin arrondi. On gagne donc à la fois en productivité, mais aussi en bande passante et on obtient un rendu graphique forcément plus optimisé.

C'est bien beau tout ça mais… Bien évidemment, Internet Explorer ne gère pas ces propriété. IE8 gère ~~encore difficilement~~ enfin les CSS 2, alors lui demander des choses si compliquées, faut pas pousser. On peut espérer que IE 9, qui doit sortir dans quelques mois, saura les interpréter correctement, sans bug, ni hack… Mais même dans ces conditions, les précédentes versions de IE resteront encore quelques années beaucoup trop implémentés (IE6, 10 ans, est toujours utilisé par 10% des clients web, c'est énorme !) Alors que faire ?? On oublie ces CSS 3 et on continue à galérer comme avant ? Ou alors on utilise des outils supplémentaires comme http://css3pie.com !

CSS3Pie

CSS3 Pie est un framework qui se permet d'ajouter à IE 6, 7 et 8 la gestion des propriétés border-radius, box-shadow, border-image, linear-gradient, et une presque gestion des valeurs en rgba (déclaration de couleur en RGB avec une valeur d'opacitié). Il suffit donc d'appliquer cet outil pour que, magiquement, nos CSS 3 fonctionnent sous IE ! C'est énorme !

Sur le dernier projet de JFG Networks sur lequel je travaille et dont je parlerais longuement incessamment sous peu, j'ai décidé d'aller de l'avant et d'utiliser les technologies web les plus avancées, dont CSS 3. IE ne serait supporté que dans sa version 8, je pouvais donc me le permettre. Les conséquences se limiteraient à un design légèrement plus carré sous IE : là où les autres navigateurs afficheraient des coins arrondis, IE les laisseraient désespérément carrés. Puis j'ai découvert CSS3Pie et j'ai été ravi de pouvoir fournir une expérience utilisateur identique sur tous les browsers.

Comment ça marche ???

CSS3Pie consiste en un fichier PIE.htc qui n'a absolument rien à voir avec un mauvais constructeur de smartphone taïwannais. Il s'agit d'une sorte de javascript qui sera exécuté sur les balises xhtml auquelles il est appliqué. C'est grâce à ça que les propriétés inconnues de IE sont simulée en JS.

Par exemple, pour appliquer une bordure arrondie aux éléments de classe ".rounded", nous utiliserons cette déclaration CSS :

.rounded {
	-moz-border-radius: 5px; /* FF1+ */
	-webkit-border-radius: 5px; /* Saf3+, Chrome */
	-khtml-border-radius: 5px; /* Konqueror */
	border-radius: 5px; /* Standard. IE9 */
	behavior: url(path/to/PIE.htc);
}

Les trois premières lignes (-moz, -webkit, -khtml) n'ont rien à voir avec css3pie et sont les noms des propriétés propriétaires et temporaires utilisées par les navigateurs qui n'appliquent pas la spécification CSS3 tant qu'elle n'a pas été finalisée.
border-radius est la vraie propriété css.
behavior est une propriété de Internet Explorer qui permet d'appliquer un fichier htc à ces élements. PIE.htc va donc lire les propriétés de l'élément en question et simuler les rendus que IE ne connais pas grâce à javascript.

Ça a l'air plutôt pas mal tout ça hein ! Mais pourtant…

Pourtant ???

Malheureusement beaucoup trop de contraintes m'ont empêché d'utiliser cet outil très tentant. Forcé de laisser mon design carré aux utilisateurs d'IE, voici les points qui m'ont embêté, voire bloqué :

Pour éviter de répéter du code un peu partout, j'ai d'abord tenté de mettre mon behavior: url(path/to/PIE.htc); sur *, puis sur body, mais aussi sur un selecteur existant qui contenait un border-radius :
```
bla {
	behavior: url(path/to/PIE.htc);
}
body {
	behavior: url(path/to/PIE.htc);
}
.maclasse *:first-child {
	behavior: url(path/to/PIE.htc);
}
```
Erreur fatale ! Internet Explorer n'a pas supporté la charge de travail que ça lui a demandé. En effet, après avoir compris comment fonctionnait cette propriété, on en déduit que le script contenu dans le .htc s'exécute indépendamment pour chacune des balises contenant la page, soit quelques centaines, ou peut être milliers selon la complexité de la page… IE a freezé. Conclusion : ne jamais placer de behavior dans un selecteur contenant une astérisque ou une sélection trop groumande.
Le path vers le fichier PIE.htc doit absolument être relatif non pas à la css, comme pour une image de background, mais à la page web courante. Ça pose pas mal de problème quand on développe dans un environnement différent de la production : en effet, en dev, le fichier pourrait être sur /css/PIE.htc, tandis qu'en prod, il sera probablement sur un serveur statique : http://static.mondomaine.com/PIE.htc. C'était la raison pour laquelle je souhaitais rationnaliser la présence de ce behavior dans le sélecteur * pour n'avoir qu'une seule modification à appliquer lors d'une mise en production du code de l'application.
Dans certains cas, lorsque un ''border-radius'' est appliqué à l'aide de __css3pie__, les images de fond (''background-image'') de l'élément disparaissent. Et c'est ce point là qui a été le plus bloquant pour moi. À choisir entre des coins carrés au lieu de rond ou des coins ronds, mais un design tout blanc… j'ai laissé tomber les ronds…
CSS3Pie reconnait très bien ''border-radius'', mais pas du tout ses sous propriétés ''border-bottom-left-radius'', ''border-top-right-radius'', etc. Rien de très grave, certes, mais il faut penser dès le début à n'utiliser que ''border-radius: topleft topright bottomright bottomleft;'' pour ne pas perdre du temps à tout corriger.
Après on peut aussi râler sur le fait d'utiliser une propriété propriétaire qui ne fonctionne que par et pour Microsoft… mais la fin justifie malheureusement les moyens…

Conclusion

Vivement IE9. Sortie de la beta prévue mi septembre pour tous les experts qui sont à l'aise avec le téléchargement et l'installation de logiciels. CSS3Pie peut quand même dépanner pour des sites peu complexes, mais n'est pas encore digne d'être recommandé dans toute les situations.

Des bugs… des bugs…

Hadrien — Sat, 20 Feb 2010 21:21:00 +0100

Après IE8, c'est au tour d'IE7 de nous fatiguer avec ses bugs. C'est un bug particulièrement chiant car difficile à détecter. Il apparait parfois quand on modifie le DOM et son style. IE 7 ne rends pas la page correctement, mais un rafraîchissement de l'affichage par un redimensionnement de la fenêtre ou un changement d'onglet remet tout en ordre. La difficulté dans ce cas de figure, une fois qu'on l'a identifié, est de forcer Interner Explorer à rafraîchir sa page sans déranger l'utilisateur.

J'ai rencontré le problème pendant le développement de la barre Overblog. Au DOMReady, la barre est insérée via javascript. Le DOM est construit, et son design est mis en place par une balise style contenant les CSS adéquates. Parmi celles-ci, je rajoute un margin-top de 30px sur la balise html afin de décaller toute la page vers le bas pour placer la barre overblog au dessus. C'est censé donner ça :

Sauf que sous IE 7, ça donne ça :

… et tout se décale correctement comme sur la première capture si je resize la fenêtre ou si je passe à un autre onglet et que je revient.

La solution que j'ai trouvé en fouillant sur le net est de changer discrètement une propriété CSS qui aurait une incidence sur l'ensemble de la page une fois que celle-ci est complètement chargée. En l'occurence :

YAHOO.util.Event.on(
	window,
	'load',
	function()
	{
		document.body.style.display = 'none';
		document.body.style.display = 'block';
	}
);

Ça semble bien fonctionner… mais pas tout le temps… La seule solution que j'ai trouvé est de faire encore pire que ça :

setInterval(
	function()
	{
		document.body.style.display = 'none';
		document.body.style.display = 'block';
	},
	500
);

Toutes les demi secondes, l'affichage est raffraichit. Ainsi, on est sur de ne plus avoir de problème avec ce bug sous IE7. Évidemment, ce code n'est à faire éxécuter que par IE7 en testant l'environnement par les méthodes de votre choix. (YAHOO.env.ua.ie == 7) si vous utilisez YAHOO User Interface (YUI).

Et encore merci Microsoft.

Un nouveau bug sur IE8

Hadrien — Fri, 19 Feb 2010 09:52:00 +0100

Je viens de trouver un bug sur Internet Explorer 8. Ce dernier ne sait pas modifier correctement le href d'une balise a -_-" Voici le cas pratique :

<h2>
	Indenté
</h2>
<p>
	<a href="http://alt-i.fr/">
		http://alt-i.fr/
	</a>
</p>
<p>
	<a href="http://www.google.com">
		http://www.google.com
	</a>
</p>
<h2>
	Non indenté
</h2>
<p>
	<a href="http://alt-i.fr/">http://alt-i.fr/</a>
</p>
<p>
	<a href="http://www.google.com">http://www.google.com</a>
</p>
<h2>
	Texte différent
</h2>
<p>
	<a href="http://alt-i.fr/">Alt-I</a>
</p>
<p>
	<a href="http://www.google.com">Google</a>
</p>
<script type="text/javascript" charset="utf-8">
//<![CDATA[
	(function()
	{
		var as = document.getElementsByTagName('a');
		for (var i = 0; as[i]; i++)
		{
			as[i].href = 'http://www.over-blog.com';
		}
	})();
//]]>
</script>

Donc des liens dont le label est identique au href (c'est à dire que sera affiché sur la page web l'url vers laquelle il lie) et des liens avec un label différent. Un script qui prends tous les liens et modifie leur href, donc pour changer l'url vers laquelle ils lient, mais pas leur label.

Le résultat est évidemment correct sur tous les navigateurs. Par exemple Firefox :

Par contre sous IE8, c'est autre chose. Celui-ci se permet de modifier non seulement le href, mais aussi le label. Regardez :

La solution absolument ridicule est donc de mettre de coté le innerHTML avant de modifier le href, puis de le remettre correctement :

(function()
	{
		var as = document.getElementsByTagName('a');
		for (var i = 0; as[i]; i++)
		{
			var label = as[i].innerHTML;
			as[i].href = 'http://www.over-blog.com';
			as[i].innerHTML = label;
		}
	})();

Merci Microsoft.

Si même Microsoft a du mal avec son navigateur…

Hadrien — Mon, 25 Jan 2010 13:42:00 +0100

Voici une page du site de Microsoft.com.

Sous Firefox 3.5 Mac OS X :

Aucun soucis apparent, l'affichage est nickel !

Safari 4, Mac OS X :

Ah, on constate un petit décallage du logo bing dans le champ de recherche. Bon. C'est Safari, on se doute bien que Microsoft ne va pas optimiser son site pour Apple.

Internet Explorer 7, Windows XP :

Ah ben merde… Sur leur propre navigateur, on a un décallage :o Ouais, ok, c'est pas la dernière version…

Internet Explorer 8, Windows XP :

No comment.

Conclusion, même les pauvres dev de chez Microsoft galèrent avec leur bouse d'IE. C'est rassurant.

IE et le DOM

Hadrien — Wed, 02 Dec 2009 11:40:00 +0100

J'ai un formulaire qui contient un attribut action, comme tout formulaire qui se respecte et un nœud enfant de nom 'action' : un input.

Comme le spécifie le DOM, on accède à un attribut via la méthode parent.getAttribute(name) et à un nœud enfant via parent.getElementsByTagName(name)[indice]. Un raccourci existe : parent.name. Il correspond soit à l'enfant de name 'name' ou à son attribut 'name' si pas d'enfant : ce sont les nœuds enfant qui ont la priorité. Ainsi, dans mon cas, form.action me retourneras logiquement l'input de name 'action'. Tandis que form.getAttribute('action') me retournera en toute logique son attribut nommé 'action'.

Chez Microsoft, comme d'habitude, la logique vient au second plan. Ainsi, sous IE 7 :

>>> document.forms[1].action
 
<input contentEditable="inherit" start="fileopen" type="hidden" height="149286376" maxLength="2147483647" loop="1" size="20" value="documents:setAlbum" name="action"
 
>>>> document.forms[1].getAttribute('action')
 
<input contentEditable="inherit" start="fileopen" type="hidden" height="119117208" maxLength="2147483647" loop="1" size="20" value="documents:setAlbum" name="action">
 
>>> document.forms[1].attributes.action.value
 
"/url_du_formulaire.php"

Monsieur a décidé que le nœud enfant serait finalement un attribut et m'oblige à passer par des chemins farfelus pour aller chercher cette action tant convoitée…

Merci encore Microsoft.

Microsoft se fout de la gueule du monde

Hadrien — Fri, 17 Apr 2009 14:51:00 +0200

On me signale un bug qui vient d'être trouvé sur Overblog sous IE 8. Un bug bizarre : IE 8 ne comprends pas la méthode element.removeAttribute('readonly'). Une méthode javascript pourtant très vieille et qui n'a jamais posé de problème, même pas à IE<6. Hm… Je regarde de plus prêt, et je me rend compte que IE 8 est réglé en mode compatibilité IE 7. Repassons en mode normal. Ah. Plus de bug. Et en plus la page s'affiche mieux.

Lors du développement d'IE8, ses développeurs avaient annoncés qu'ils laissaient le moteur de rendu de IE7 pour des raisons de rétrocompatiblité. Il était annoncé qu'un site serait affiché par défaut avec le moteur de rendu d'IE8 (normal) mais qu'il restait possible pour un webmaster de forcer l'utilisation du moteur d'IE7 en plaçant une balise meta spécifique dans le header de sa page. Soit. Nous n'avons pas placé cette balise, nous préférons être affiché avec un moteur le plus respectueux possible des standards. Alors pourquoi Overblog s'affiche-t-il en mode IE 7 ???

À la sortie d'IE 8, Microsoft a publié une blacklist de sites qu'ils ont qualifié arbitrairement d'incompatible avec IE8 et dont ils ont forcé le rendu avec le moteur 7. Peu de temps après cette sortie, nous avons reçu un mail de Microsoft nous annonçant qu'on était dans cette blacklist. Donc, nous sommes affiché avec le moteur d'IE7 car Microsoft l'a décidé sans nous demander notre avis. Le plus incroyable, c'est que notre site s'affiche pourtant mieux avec le nouveau moteur qu'avec celui qu'on nous impose.

Je fouille donc la doc de Microsoft pour trouver un moyen de forcer le moteur 8. Et je finis par trouver que la meta magique dont je parlais précédemment permet en fait de choisir n'importe quel moteur. On en profite pour rigoler un petit peu :

<meta http-equiv="X-UA-Compatible" content="IE=4">   <!-- IE5 mode -->
<meta http-equiv="X-UA-Compatible" content="IE=7.5" > <!-- IE7 mode -->
<meta http-equiv="X-UA-Compatible" content="IE=100" > <!-- IE8 mode -->
<meta http-equiv="X-UA-Compatible" content="IE=a" >   <!-- IE5 mode -->

D'après la doc, on peut indiquer "IE=100" si on veut le moteur 8 ou "IE=tamerenshort" si on veut le 5. Ridicule.

Donc pour finir, nous sommes donc forcés de rajouter une balise de merde pour indiquer à un navigateur parmi tant d'autre qu'il doit afficher nos pages normalement. Dingue non ?

Internet Explorer Speed Rabbit

Hadrien — Wed, 25 Mar 2009 09:23:00 +0100

Microsoft a lancé la version 8 de son navigateur ~~de merde~~ Internet Explorer la semaine dernière. Il fallait bien évidemment l'accompagner d'une campagne de promotion, car ce n'est sûrement pas par ses qualités qu'il va réussir à reprendre les parts de marché que Firefox et Safari lui ont repris. Et bien j'aimerais bien savoir combien sont payés les commerciaux chez Kro, car pour faire des opération pareille, c'est vraiment jeter l'argent par les windows.

Microsoft a conclu un partenariat avec Speed Rabbit Pizza qui propose pendant une période limité la pizza Internet Explorer 8 :

Remarquez le 'e' moisi au milieu de la pizza. Hmmmm appétissant isn'it ? Remarquez aussi le concept publicitaire poussé à son paroxisme : pizza IE 8 => 8 parts, 8 ingrédients, 8 €. Je me demande s'ils ont pas confié la campagne à un stagiaire en fait…

Je me demande s'ils ont poussé le vice en imposant IE8 pour passer commande en ligne :o

Source : Le journal du geek

Internet Explorer 8

Hadrien — Fri, 20 Mar 2009 14:52:00 +0100

Je me suis fait une 3° VM sous XP pour y installer Internet Explorer 8, sorti hier, pour mes tests. Et je me suis marré. Lors du premier lancement, Microsoft nous ressort la blague de Intel et du Pentium qui accélère Internet :

Bon ceci dit, c'est vrai que niveau vitesse, comparé à IE6, ça trace ! Il va enfin presque aussi vite que Firefox 0.6. Bon, après, j'ai voulu lui faire passer le test Acid3 pour rigoler :

Ce n'est pas le résultat qui m'a fait rigoler, mais la vitesse à laquelle il a péniblement atteint le score de 20/100. Quasiement une minute quand il faut seulement 3 secondes à Safari 4 pour atteindre les 100/100.

Bravo Microsoft, on avance…

Victoire

Hadrien — Thu, 18 Dec 2008 18:04:00 +0100

Internet Explorer vient de passer sous la barre psychologique des 60% de part de marché ! Plus que 59% de IE, toute versions confondues ! Firefox atteint plus de 30%.

Un petit pas pour l'homme, un grand pas pour l'humanité !

Désactiver Javascript sous IE7

Hadrien — Fri, 21 Nov 2008 17:09:00 +0100

Ou "Le parcours du combattant".

Il me fallait désactiver javascript sous IE7 pour tester mon application. Je m'attendais à un truc relativement simple : décocher une case dans un onglet des préférences d'Internet Explorer. Je cherche donc… introuvable. Aucun option relative à Javascript. Je demande donc à Google…

Je découvre qu'il faut donc aller dans les options de sécurité et décocher l'option "Scripts ASP" :| Script ASP Hm, il doit y'avoir erreur. Bon je teste… Putain, c'est bien ça. Donc pour désactiver Javascript sous IE 7, il faut décocher "Scripts ASP" !

Ah, vous ne trouvez pas l'option en question. Normal, elle se trouve là :

Vous ne le voyez pas ? Normal, c'est tout en bas de cet immense dialogue totalement désordonné et non redimensionnable. Le voici recomposé après plusieurs captures d'écrans :

Au passage, j'ai une pensée émue aux gens qui disent régulièrement : "Windows say mieux que Mac OSX parce qu'on peut configurer au taquet de truc !". Alors, oui en effet, on peut en configurer des choses… mais à quel prix…

Hotmail sux

Hadrien — Sat, 15 Nov 2008 19:26:00 +0100

Oui, beaucoup le savent déjà. Mais beaucoup n'en sont pas encore assez conscient.

Nahuel m'envoie ce billet tout à l'heure, qui parle d'un pseudo bridage de Hotmail pour les utilisateurs d'Ubuntu. En effet, sous Ubuntu, il est impossible d'écrire un mail sur Hotmail, l'éditeur restant grisé et désactivé. Ils préconisent de modifier le userAgent de Firefox pour enlever la partie indiquant que le navigateur tourne sous Ubuntu, ce qui règle le problème et rend accessible la zone d'édition.

Alors, on parle forcément de bridage des services Microsoft, de scandale, etc. Moi j'aurais plutôt tendance à penser que les développeurs du service Hotmail sont juste de gros ahuris. J'ai tenté l'expérience pour vérifier ce problème. Je suis sur Mac, je teste avec Firefox.

Tout d'abord, je vérifie la valeur de general.useragent.vendor dans la conf de Firefox. Ça tombe bien, la clé n'existe pas. Je me connecte donc à Hotmail, je tente d'écrire un mail. Aucun problème :

Je modifie ensuite la clé general.useragent.vendor en "window", puis "macosx" :

Toujours aucun problème.

Je la modifie maintenant avec "linux", "ubuntu", "kikoolol" et autres tests :

Ça y est, plus rien ne fonctionne :

L'éditeur est désactivé. Conclusion, ces gros cons de développeurs de chez Hotmail testent si (navigator.vendor == '' or navigator.vendor == 'windows' or navigator.vendor == 'macosx') pour activer leur éditeur. C'est complètement crétin de se baser sur le userAgent pour activer ou désactiver des parties d'un site, tout le monde sait ça. Si un navigateur ne prends pas en charge une fonction de l'application web, c'est pas à l'application de la désactiver, ça sera le navigateur qui ne la prendra pas en charge. Point barre.

Conclusion, Microsoft sux, ce sont de gros noobs.

Des nouvelles d'IE8

Hadrien — Sat, 20 Sep 2008 08:43:00 +0200

L'équipe de développement d'IE8 nous annonce une petite fonctionnalité fort amusante dans IE 8. Mais il faut d'abord expliquer quelques points.

Quand un serveur web envoi un document (html, ou autre), il passe des informations dans l'entête du fichier, informations qui ne sont pas affichées à l'utilisateur et qui sont destinées au logiciel client. Parmi ces information, est envoyé le "content-type", le type de contenu du fichier. Il s'agit d'indiquer au logiciel client de quel type est le document envoyé qui est souvent un fichier texte.
Par exemple, un fichier html est un fichier texte. Il faut donc spécifier au navigateur que ce texte est du html grâce au content-type 'text/html'. Si je veux que mon fichier html soit affiché en tant que texte, donc, non rendu, je le spécifie comme type "text/plain".

Bon, alors ça c'est pour la théorie. C'est à dire que c'est ainsi que fonctionnent tout les navigateurs et qu'ils doivent procéder. Maintenant, occupons nous d'Internet Explorer. IE 6 et IE 7 ont l'excellente idée de se foutre royalement du content-type et d'essayer de le deviner par lui même. Si on lui envoie un fichier texte défini comme texte brut (text/plain) mais contenant du code html, IE6/7, eux, vont quand même rendre la page html. Les développeurs de IE 8 tentent de résoudre ce problème pour rentrer dans la norme. Dorénavant, IE 8 rendra ce fichier servi en tant que text/plain en texte …à condition d'avoir indiqué un autre paramètre en header : X-Content-Type-Options: nosniff !!

On est donc obligé de rajouter un header propriétaire et non standard à tous nos fichiers web pour indiquer uniquement à IE8 qu'il doit se comporter comme tout les navigateurs. C'est absolument génial, personne à part Microsoft n'aurait osé faire ça.

En pratique, on comprends qu'ils soient "obligés" de procéder de la sorte pour ne pas rendre tout les intranet incompatibles avec IE8. Ils sont piégés dans leurs propres bugs. En corrigeant ce dysfonctionnement, les entreprises seraient forcées de mettre à jour leurs intranets, qui ont été codé il y a plus de dix ans, pour le navigateur de l'époque : IE6, bourré des bugs qu'on connaît tous aujourd'hui, dont celui dont on parle dans ce billet. Si leurs pages html servies en text/plain s'affichent correctement aujourd'hui sur IE6/7, elles ne s'afficheraient plus du tout sur IE8. Et bien sur, ça serait la faute à Microsoft, donc on laisse le bug. Ben pour une fois, non !

Source : IEBlog

Acid 3, état des lieux

Hadrien — Tue, 16 Sep 2008 15:09:00 +0200

Cet article donne un état des lieux de l'avancement des navigateurs dans le passage du test Acid 3.

On constate que les deux pionners que sont Safari et Opéra n'ont toujours pas été rattrapés. On peut voir aussi que Google n'a pas utilisé le dernier Webkit pour son Chrome vu qu'il n'est qu'à 79%. Firefox poursuit lentement son chemin et atteint les 84% et le challenger le plus proche est étrangement Seamonkey.

Allons y pour la poilade. IE 8 n'en est toujours qu'à 21%. Mais le plus drôle, c'est que IE5.5 fait mieux que IE 7 ! (14% contre 12%)

IE8 VS FX2 VS SF3

Hadrien — Fri, 07 Mar 2008 16:04:00 +0100

Derrière ce titre au nom barbare se cache un test comparant Internet Explorer 8 ßeta 1, Firefox 2 et Safari 3. Le test est simple. Chacun des 3 navigateurs sont dans la même machine virtuelle, elle même tournant sur un MacPro BiXeon dual core 2,66Ghz et 3Go de RAM. Les 3 navigateurs ont chargé la page http://www.hadrien.eu. Elle est donc en cache. Seule les performances sur l'éxecution du javascript (très lourd dans le cas de ma page) comptent. Rigolons :

Internet Explorer 8 : la bouse
envoyé par hadrienl

Lien direct vers la vidéo en mp4

Comme on peut le constater, IE8 rame comme une merde, Firefox est pas mal du tout, et Safari 3 déchire tout.

Acid test 3

Hadrien — Thu, 14 Feb 2008 10:51:00 +0100

On va encore se marrer. L'Acid test version 3 a été testé sur tout les navigateurs du marché. Voici ce qui devrait s'afficher sur un navigateur respectant les standards à 100% :

Malheureusement, on est loin du compte. Seule la dernière nightbuild de WebKit atteind un score respectable de 82% :

Et marrons nous devant IE6 et IE7 :

Voilà, avec 70% de navigateurs qui n'arrive même pas à 15% d'un test de standards, le web est mal barré…

À la recherche du bug perdu

Hadrien — Wed, 06 Feb 2008 17:14:00 +0100

Je viens de terminer un safari du bug IE6 assez incroyable. Le bug en question se produisait lorsqu'on arrivait sur le control panel d'over-blog (la page d'accueil de l'admin), sous Internet Explorer, avec certains blogs en particulier. La conséquence était un freeze du ~~bouzin~~ navigateur. Le principal suspect était l'applet flash qui affiche les statistiques.

Après avoir enfin trouvé un blog en dev confronté au problème, nous avons pu faire des tests poussés. Tout d'abord, désactivation de l'applet flash. Toujours le plantage. Hm… ce n'est donc pas Flash qui est cause.
J'enchaîne en désactivant tout le control panel. Plus de soucis. Il s'agit bien d'une zone du tableau de bord : le module "Promo Premium et PDA". En désactivant petit à petit chaque partie du HTML de ce template, on en arrive à trouver la cause du problème. Un <br /> :|

<ul>
	{if empty($thematics)}
	<li>
		<br />{$lg->getText('message.thematicNotSelected')}
	</li>
	{/if}
</ul>

C'est ce <br /> (ne me demandez pas ce qu'il fait là) qui faisait planter IE ! Je trouve ça très fort.

Les styles de IE

Hadrien — Tue, 15 Jan 2008 16:15:00 +0100

Pour patienter devant cette attente insurmontable, une petite blague dans la catégorie IE SUX. Voici les styles que IE applique à toute page web avant de la charger :

* html {
	word-wrap: break-word;
	explorer-stability: random ;
	mso-random-crap: true;
	mso-more-unnecessary-wankery: 15;
	mso-non-standard-selector: naturally;
}

Requêtes Ajax et Internet Explorer

Hadrien — Fri, 04 Jan 2008 12:05:00 +0100

J'inaugure une nouvelle catégorie "IE SUX" dans laquelle j'exprimerais mes coup de gueules envers les malfonctions de cette bouse infâme qu'est Internet Explorer. Aujourd'hui, IE et les requêtes Ajax.

Un bug sur Over-blog : impossible de mettre un caractère accentué à un nom de catégorie sous IE. Celui-ci envoie systématiquement le string en ISO au lieu d'UTF-8.

Après moulte fouilles et tentatives de debug, j'ai finalement trouvé la cause du problème. Il s'agit en fait d'un bug de l'objet ActiveX XMLHTTP de IE (6 et 7). Lorsque l'on envoie des données via une requête Ajax en Get, IE se fait un malin plaisir à envoyer la donnée en tant que UTF-8, mais en réalité en ISO. D'où la réception d'un caractère foireux. Par contre, si les données sont envoyées en Post, aucun problème, c'est de l'UTF-8 qu'il envoit.

Conclusion, envoyez toute vos requêtes Ajax en Post. Merci Microsoft.