Pour une fois, ce blog ne parlera pas d’HTML5, de javascript avancé ou de performances mais de bonnes pratiques. On reste toutefois dans la modernité du développement Web, car nous allons voir pourquoi j’estime que la plupart des développeurs Web et pire, des Web agencies sont sous-équipées lorsqu’il s’agit de tester ses navigateurs.

Je vous livre même la conclusion immédiatement : vous vous devez d’avoir des machines virtuelles pour avoir un environnement de test simplement normal et voici pourquoi.

Je ne m'énerve pas, j'explique

Je travaille dans des conditions outrageusement luxueuses. Comprenez par là que je bosse sur un MacBook Pro depuis 4 ans, et que j’ai une machine virtuelle pour chaque version d’Internet Explorer. J’ignorais ma condition de nanti jusqu’au jour où j’ai travaillé avec une web agency puis discuté avec d’autres développeurs. Ce qui comme la plupart des développeurs ne me gênait pas au début (après tout c’est cher à mettre en place) est devenu rapidement un problème : mes prestataires ne pouvaient pas reproduire certains bugs car ils n’avaient pas les outils nécessaires. Après une petite année à ce régime, j’ai cumulé suffisamment de preuves pour me permettre de demander légitimement aux prochains prestas de s’équiper avant de travailler avec nous.

Arrettez les "compatibility mode"

[caption id=”attachment_620” align=”aligncenter” width=”345” caption=”Choix du mode de compatibilité dans IE8 Debug Tool”][/caption]

C’est probablement le pire moyen de tester : le mode de compatibilité d’IE8 ou IE9 supposés exécuter le moteur de rendu d’IE7 ou IE8. MS a voulu bien faire pour faciliter la vie de ses utilisateurs et leur permettre une transition en douceur de IE7 vers IE8, mais les développeurs se sont vite rendu compte que le mode de compatibilité générait des rendus différent de IE7. A tel point que Yahoo! et sa matrice de navigateurs à tester recommandent constamment de tester spécifiquement le mode de compatibilité (voir les updates, dans les notes).

Certaines techniques sont faussées : j’ai par exemple constaté que le support des images en data:uri et base64 marchait dans IE8 en mode IE7 standard alors que IE7 ne le supporte pas. Comment faire pour valider certaines techniques émergentes (ici pour les performances) si vous n’avez pas les bons navigateurs pour tester ?

La différence de comportement la plus grave que j’ai constaté (et je ne suis pas le seul) vient du moteur javascript : sous IE6 et IE7, le fait d’oublier d’enlever la dernière virgule (,) après une chaîne JSON a toujours planté le script :

var oData : {
  value1:"blah",
  value2:"blah", // === boom
};

Sous IE8 comme sur tous les autres navigateurs, cette syntaxe est valide. Or si vous vérifiez avec le mode de compatibilité IE7 sous IE8, vous ne verrez pas cette erreur qui casse votre javascript et qui enlève donc des fonctionnalités majeures de votre site, simplement parce que vous n’êtes pas dans les bonnes conditions pour tester.

Les installation multiples d'Internet Explorer

[caption id=”” align=”aligncenter” width=”476” caption=”Screenshot IE tester”][/caption]

Internet Explorer est à ce point implanté dans son OS qu'il est en théorie impossible d'installer plusieurs versions d'Internet Explorer (ce qui leur avait même valu des problèmes avec la justice). Mais plusieurs softs ont pallié à cette situation et permettent d'exécuter plusieurs versions d'IE comme IETester, IECollection ou Multiple IE. Le problème, c'est que ces différentes instances d'IE continuent de partager certaines DLLs et autres appels système. Ca n'a l'air de rien, mais concrètement pour le développeur Web ça l'empêche de voir certaines choses :

Plugins

Les interaction avec des plugins populaires comme Flash ou Java sont problématiques :

  • J'ai déjà vu Flash planter sans que IE dans un IETester ne s'en aperçoive, le fallback que nous implémentions en Flash (la sélection multiple de fichiers pour un uploader) était essentiel, mais le développement était pénible : on s'est rendu compte au bout d'un moment que Flash ne répondait plus ou mal, et qu'il fallait tuer le processus Flash pour que cela remarche. Avec un IE natif, pas de problèmes : lorsque Flash plante, il se relance correctement, ce qui accélérait le développement
  • l'interaction avec une applet java (toujours pour un uploader, en drop de fichiers cette fois) était tout simplement impossible à tester avec plusieurs IE dans le même IETester. Une machine virtuelle, c'est déjà lourd à lancer, alors imaginez 3 applets en parallèle qui essayent de s'afficher sur la même zone de l'écran. Les fichiers n'étaient pas réceptionnés dans la bonne instance d'IE ...

Fonts et couleurs

Pour le rendu des fonts il vous faudra typiquement vérifier votre site sous un Safari sur Mac et sur un IE6 sous XP : le Safari Mac rend les polices exactement comme votre graphiste l’a prévu sur sa belle maquette Photoshop. C’est la vision qu’il a du site, et c’est surement celle que les décideurs ont du site … Le couple terrible IE6-XP qui est encore là pour longtemps est lui à l’extrémité opposée du spectre des rendus, et correspond au pire de ce que verront vos visiteurs. Les versions supérieures de IE et des navigateurs ne font qu’améliorer le rendu sans jamais totalement atteindre la perfection du couple Safari / OSX.

[caption id=”attachment_634” align=”aligncenter” width=”542” caption=”Au moins 4 rendus par police”][/caption]

J’ajoute que selon la taille de police, l’activation ou pas de l’option lissage, le type de police et les caractères utilisés, certains mots peuvent devenir illisibles ou du moins pénibles à lire sur les Windows. Lorsque vous décidez de l’utilisation d’une police, il vous faudra d’abord vérifier son rendu final sur au moins XP, Vista ou Seven, et enfin MacOS. Soit vous maintenez 3 machines physiques avec 1 OS sur chacun, soit vous utilisez les machines virtuelles (ou plus pénible : des machines en dual boot).

Le rendu des couleurs : j’avoue ne pas très bien savoir comment faire ici. Mac et les différents Windows rendent les couleurs différemment, discutez en 2 minutes avec un graphiste, ça lui laissera le loisir de vous montrer qu’il en sait plus que vous. Hors avec les machines virtuelles, on affiche un Windows sur un Mac, je n’ai aucune idée de ce que cela donne réellement. Pour en rajouter un peu, je n’obtiens pas les mêmes couleurs selon que je suis sur l’écran du macbook ou sur le 2nd écran … Devant mon incapacité à vous expliquer comment tout cela marche, je ne peux que citer une des bonnes pratiques généralement accolée à l’accessibilité : inutile de jouer avec des nuances de couleurs, préférez de forts contrastes.

Etre à jour

Microsoft patche régulièrement ses OS ainsi que ses IE. Rarement mais sûrement certaines choses peuvent s’arrêter de fonctionner suite à ces patchs. Exemple concret : dans les IEs on pouvait récupérer le chemin local d’un fichier sélectionné par un input type=file. Ceci permettait d’afficher une miniature d’une image avant upload, fonctionnalité d’ailleurs à nouveau permise par HTML5. En 2009 un patch est passé qui a fait disparaître cette possibilité, après 10 ans de bons et loyaux services (voir les screenshots que j’avais fait).

Les packs d’IE ne permettent pas de rester à jour, ou alors vous dépendez de leur bon vouloir. Avoir une machine virtuelle permet d’utiliser le mécanisme d’auto-update de MS.

Autres fonctionnalités cassées

Il y a d’autres bugs connus sur Multiple IE ou IETester :

  • les champs texte sur "Multiple IE" ne fonctionnent plus
  • les popups et leur interaction avec la page d'appel est cassée
  • les filtres CSS ne marche pas
  • la fonctionnalité d'impression ne marche pas </ul>

    Dégradation gracieuse et Fallbacks

    Les anciens et les futurs navigateurs

    Outre Internet Explorer, certains versions de Firefox valent encore la peine d'être testés avec plusieurs versions. Ca a été le cas pendant longtemps pour FF3, c'est encore peut être le cas sur vos sites pour FF3.5 et à l'heure d'écrire ce post, c'est certainement vrai pour FF3.6, alors que l'on est passé à la 4.0. Les bugfixs passés dans ces releases impactent rarement le travail des webdevs (mais ça arrive) mais il y a surtout eu des ajouts de fonctionnalité majeures (rangées sous l'ombrelle HTML5) ou l'ajout de supports CSS3 : il faut que vous testiez au moins une fois pendant le développement comment se comporte votre fallback ou votre graceful degradation sur ces anciennes versions. Il n'est peut être pas utile de conserver des versions de Chrome et Opéra, l'un car il force l'auto-update, l'autre parce qu'il est rare, mais c'est à vous de juger. Par contre il est vital d'avoir les versions de développement de IE (la 10 preview) et Firefox (Minefield) pour tester régulièrement votre site avec : faites corriger les bugs par Microsoft ou par Mozilla avant que vos utilisateurs ne tombent dessus et vous fasse changer votre code ! Il n'est peut être pas nécessaire d'avoir une machine virtuelle dédiée à une version passées et futures des navigateurs hors IE, car il me semble que différentes versions de FF savent cohabiter ensembles et que les beta/preview d'IE savent également s'installer sans conséquences. Mais il vaut peut être mieux jouer la prudence là dessus : ce sont des versions beta et avec les nouvelles fonctionnalités type accélération matérielle, les navigateurs s'intègrent de plus en plus au système, il me semble donc évident que toute nouvelle installation met en péril l'intégrité des autres versions du même navigateur. Et une fois que le mal est fait, difficile de revenir en arrière, tandis que sur une machine virtuelle vous pouvez isoler le problème, et vous pouvez même revenir en arrière grâce aux fonctionalités de snapshot à exécuter avant toute installation hasardeuse.

    Plugins et addons

    Votre site dépend parfois de Flash ou Java ? Il affiche des publicités ? Il vous faut au moins une machine où Flash et Java ne sont pas installés, afin de tester de manière réaliste votre contenu alternatif ou le fallback de votre fonctionnalité. On ne développe pas ce qu'on ne voit pas. Concernant Flash, et c'est valable avec Java : il existe des différences entre Flash 9 (encore répandu) et Flash 10.x. Les flasheurs développent et testent toujours avec la dernière version : ayez donc une machine avec une ancienne installation de Flash pour vérifier rapidement que le Flash qu'on vous livre marche pour tout le monde. Votre Firefox est peut être comme le mien : c'est devenu un navigateur de développement sur lequel est installé une dizaine de plugins dont le gourmand firebug. Après quelques heures de développement mon Firefox est à la limite du praticable sur certaines pages chargées. Un tour régulier sur un Firefox sans aucun plugin dans une machine virtuelle me permet de vérifier (et non pas de supposer) si c'est un plugin ou mon code qui fait ramer le navigateur.

    Quelles contraintes ?

    Vous êtes probablement d'accord avec le principe d'être dans de bonnes conditions pour tester, mais vous avez peur que cela demande du budget et de la ressource machine ? C'est le cas, mais rien d'insurmontable. Concernant votre machine de développement d'abord :
    • Mac OS : il faudra le tester de toute façon, ne serait ce que pour tester ce que voient les graphistes et les journalistes... Pendant longtemps il n'y a pas eu de machine virtuelle capable de le faire tourner mais il semblerait que cela soit aujourd'hui possible, donc si vous voulez rester sous Windows ou Linux, c'est peut être jouable, à vos risques et périls. Pour ma part et depuis 4 ans, j'ai convaincu mes employeurs de payer 50% plus cher mon matériel pour être dans des conditions de test réalistes. Pour les managers qui doivent justifier ce budget : outre la qualité, un développeur sous mac est un développeur qui restera plus longtemps chez vous :)
    • 4GO de RAM : pendant le développement, il faut tourner avec au moins un IE6 (ou 7) sous XP en permanence ouvert en plus l'environnement de développement normal (Firefox, éditeurs, divers logiciels ...). Avec 2Go, c'est parfois pénible, du coup certains développeurs ferment à jamais la machine. 4Go, c'est mieux, et ça permet de supporter ces jours pénibles, généralement en début et en fin de projet, où vous allez lancer successivement toutes vos machines virtuelles pour valider des choix techniques ou le développement lui même.
    • un disque rapide : 2 OS qui cohabitent, ça fait énormément d'appels au disque dur, surtout que vous allouerez peu de RAM à Windows (512Mo max en général), et ce dernier utilisera la mémoire virtuelle (le disque donc). Si vous n'avez que 2Go de RAM et un disque de portable à 5400 tr/mn, la situation sera intenable. Essayez d'upgrader à 7200 (la différence est flagrante), voir de le remplacer par un SSD, technologie qui commence à être abordable. </ul> Concernant le software :
      • XP et Seven : il vous faut au moins ces 2 OS pour installer de IE6 à IE9. Concernant les licenses, chez Yahoo! nous utilisions des licences dites corporate (valables pour des milliers de postes), donc pas de problème. En PME, la pratique généralement admise est d'acheter la licence, d'installer ... puis de cloner l'image de la machine autant de fois qu'il y a d'environnement et de développeur. Honnêtement je ne sais pas si c'est prévu par la licence. Si vous émulez à partir de Seven avec Virtual PC, Microsoft vous offre des images d'installation (limitées dans le temps) parfaites pour les webdevs.
      • Une machine virtuelle Mac :
        • payant : j'utilise Parallels Desktop qui me satisfait pleinement mais qui a la réputation d'être gourmand en ressources. J'ai entendu du bien de VMWare. Dans tous les cas comptez moins de 100 euros.
        • gratuit : VirtualBox est le leader de l'open source, mais n'était pas sorti lorsque j'ai commencé à utiliser Parallels il y a 4 ans, je ne peux donc pas en parler. Si vous êtes sur Windows Seven, vous pouvez utiliser Virtual PC.
      Les machines virtuelles vous fournissent généralement des images pré-installées. Mais elles ne sont jamais en français, et bien sur ne dispensent pas de fournir une clé Windows valide. Veillez aussi à ce que les images d'XP fournies contiennent bien IE6 :  on ne peut pas désinstaller IE7 pour installer IE6.

      La matrice de tests

      Je vous conseille de suivre la matrice de Yahoo!, mise à jour 2 à 3 fois par an. Voici en tout cas le contenu de mes machines après plusieurs années de pratique : [caption id="attachment_639" align="aligncenter" width="564" caption="Liste des configurations dans Parallels"][/caption] Vista et FF2-3 ne sont peut être plus utiles à posséder, mais sinon toutes ces combinaisons tiendraient en 5 machines. Cela donne accès à :
      • pas de flash/java, flash 9 et un Flash à jour partout ailleurs
      • IE 6, 7 et 8 sur XP, IE9 sur Seven
      • FF3.6 et FF4 (qui n'apparaît pas)
      • IE10 preview à jour, un FF Minefield pour vérifier des bugfix à l'occasion
      • Ces machines comportent presque toutes un Chrome et un Opéra à jour, en plus du Chrome / Opéra / Safari de mon Mac. Oui il y a parfois des différences pas uniquement visuelles entre une version Mac et Windows d'un même navigateur.
      Cela fait beaucoup de combinaisons et il en manque encore : par exemple si je dois un jour tester le site sur IE6 sans Flash, je n'ai pas de machine toute prête. Qu'à cela ne tienne, il me suffit de cloner ou de faire un snapshot de ma machine IE6 puis de desinstaller Flash pour vérifier mon bug.

      Les alternatives

      Service en ligne

      Des services comme browsershots.org ou browserlab permettent d'obtenir rapidement un screenshot d'une page vue par beaucoup de couples OS/navigateurs différents. Le désavantage évident, et dans mon cas bloqueur, est que votre page doit être sur une URL publique et que vous ne pouvez pas interagir avec la page. Peu d'équipe développent directement en ligne, préférant des URLs internes, et il est difficile de se passer de tester des interaction (:hover, formulaires, application Web ...)

      Machines physiques

      Les machines physiques sont encore plus réalistes que les machines virtuelles, en théorie vous y gagnerez donc en qualité de test. Le point négatif que j'ai expérimenté ne vient pas de l'outil mais de la nature humaine : accessibles physiquement ou depuis un VNC, c'est une solution peu pratique que les développeurs finissent par ne plus utiliser, préférant coder à l'aveugle plutôt que de se déplacer physiquement ou subir des lags réseau... Oui les développeurs sont comme ça, d'où l'intérêt d'investir dans du matériel :) J'ajoute que les machines virtuelles permettent de faire des snapshots, ce qui permet de gagner en souplesse en installant sans remords des programmes pour tester certaines conditions extrêmes (IE toolbars, mises à jour de Flash, Silverlight et Java, reproduire un bogue avec un antivirus agressif ...). Maintenir un parc de machines physiques qui permet d'avoir autant de souplesse prendrait beaucoup de temps

      Linux, windows comme OS principal

      Par conviction ou par économie, vous pouvez préférer développer sur autre chose que Mac OS. Sur ces 2 familles d'OS vous pouvez tout à fait créer des machines virtuelles, mais il vous reste cependant le problème de l'émulation du Mac (je maintiens qu'il faut le tester quoi qu'il en coûte) : à priori la seule solution viable est d'avoir une machine physique Mac constamment à jour que l'équipe pourra utiliser. Mais d'expérience cette machine finira par être sous utilisée, et donc les tests de compatibilité seront moins assurés.

      Conclusion

      • Si vous vous considérez comme un professionnel du Web, vous vous devez d'investir dans un environnement de test fiable
      • Il y a de vraies différences de comportement et de rendu entre un IE natif et des packs d'IE, et entre OS
      • Il y a un gros nombre de combinaisons possibles (4 OS, 5 navigateurs, plusieurs sous-versions, Flash ...) et les différences iront en s'accentuant (nouveaux navigateurs, adaptation à chaque OS ...)
      • La seule solution fiable et souple est d'avoir plusieurs machines virtuelles
      • Il vous faut une machine Mac OS physique pour tester cet OS (une machine partagée ou une par développeur)