Aller au contenu | Aller au menu | Aller à la recherche

logo

Alt-I, des informations alternatives

Alt-I est un blog traitant d'informatique généraliste et de cultures alternatives.

vendredi, 7 mars 2008

IE8 VS FX2 VS SF3

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 :

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.

jeudi, 14 février 2008

Acid test 3

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% :

Acid test 3 reference

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

Acid test 3 WebKit

Et marrons nous devant IE6 et IE7 :

Acid test 3 IE6Acid test 3 IE7

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

mercredi, 6 février 2008

À la recherche du bug perdu

IE6 Crash planté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.

mardi, 15 janvier 2008

Les styles de IE

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;
}

Copyright 2008 © DaScritch

vendredi, 4 janvier 2008

Requêtes Ajax et Internet Explorer

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.