Faut-il tester ses sites dans tous les navigateurs ?
Le 20 janvier 2009
Il y a bien longtemps (ah bon ?) les webdesigners construisaient leurs sites internet avec de jolies tableaux (ohhhh, c’est zoliiiiii !). Permettant ainsi que caler tous les éléments de manière assez fidèle, quelque soit le navigateur.
Puis un jour vint les CSS (Cascading Style Sheet : Feuilles de styles), qui ouvrir de nouvelles perspectives aux designers. Du coup la nouveauté s’installa petit à petit comme nouveau standard et très vite la mise en page par tableaux devint le mouton noir du webdesign…
Le fond du problème |
Malheureusement une bonne nouvelle n’arrivant jamais toute seule, cette nouvelle façon de travailler mis en avant les différences entre navigateurs (du moins encore plus que par le passé). Et bien que les CSS permettent une bien meilleure gestion de la forme et du contenu en les séparant (rendant du même coup le code beaucoup plus « propre » et lisible), cela cause tout de même parfois d’épineux problèmes pour avoir un rendu identique sur tous les navigateurs.
Provoquant du même coup une vague de mécontentement auprès de tous les graphistes du web, se mettant ainsi à haïr profondément Internet Explorer.
Loin de moi l’idée de fustiger un peu plus le navigateur livré avec Windows (encore qu’à la version 7 contre 3 pour Firefox, on pourrait trouver à dire…), mais il faut bien avouer que ça manière d’afficher les pages internet est pour le moins « personnelle ».
Ainsi si vous vous contentez de développer vos sites internet sans contrôler de temps à autre si le rendu est identique dans les principaux navigateurs, vous risquez d’avoir un coup de fil de vos clients une fois leurs sites en ligne car vous aurez développé leurs sites pour Firefox alors que eux tentent de les parcourir avec Internet Explorer.
Et c’est bien là tout le problème ! Car personne n’utilise le même navigateur.
Et bien que Firefox grignote des parts de marché à son homologue de la firme de Redmond, nul ne peut ignorer les quelques 70 % ( IE7 + IE6, selon les dernières informations) d’utilisateurs qui continuent à utiliser IE par habitude (ou choix, après tout chacun ses préférences).
Nous voilà donc, pauvres webdesigners (et oui les développeurs sont relativement épargnés par ces petits soucis puisque les langages de programmation sont pour la plupart interprétés « côté serveur » (PHP, ASP,…), donc pas de problème de ce côté là, encore que je ne sais pas ce qu’il en est pour le JavaScript qui lui est utilisé « côté navigateur »…) devant un cruel dilemme : Doit-on tester nos sites sur TOUS les navigateurs ou bien prendre le parti de rajouter un petit message du genre :
Ce site est optimisé pour une navigation sous Firefox.
Qui cache simplement le fait que nous n’avons pas pris la peine de vérifier (et adapter) le design pour un affichage identique (ou du moins le plus proche possible) sous Internet Explorer (et d’autres).
Pour ma part je pense qu’il n’est évidement pas possible de tester un site avec tous les navigateurs. Tout d’abord parce que cela prendrait beaucoup trop de temps, et ensuite parce que certains navigateurs, n’en déplaisent à certains, ne sont utilisés que par un nombre « négligeable » d’internautes.
En ce qui me concerne, je teste mes sites sous Firefox, Internet Explorer, Safari, et Opéra. Et j’essaie (dans la mesure du possible, de tester tout ça à la fois sous PC et sous Mac, excepté pour Safari uniquement sous Mac). Certains trouverons peut-être que ça fait beaucoup (ou qu’il manque Linux ?) mais voici pourquoi ce choix :
Internet Explorer et Safari sont à mon sens incontournables, parce qu’ils sont les navigateurs de base installés sur les 2 systèmes les plus communément utilisés que sont Windows et OS X (voir ici et là) (donc les 2 navigateurs qui seront potentiellement les plus utilisés par les internautes).
Ensuite viens tout naturellement Firefox car dans les faits, il est le second navigateur le plus utilisé par les internautes, juste après Internet Explorer.
Et enfin Opéra car il est l’un des navigateurs les plus respectueux des standards du web établis par le W3C.
Ces choix sont également basés sur les statistiques de mes sites qui affichent des résultats comme suit :
Firefox : 70 à 72 %
Internet Explorer : 10 à 12 %
Safari : 6 à 8 %
Opéra : 2 à 3 %
…
Vous noterez que je ne parle pas de Chrome (le navigateur de Google) bien qu’il semble s’immiscer entre Opéra et Safari selon le système de statistique utilisé, car je préfère attendre de voir s’il s’agit là d’une mode ou si ce nouveau venu s’installe réellement dans les moeurs.
Je précise également que je teste à la fois sou PC et Mac car j’ai pu noter quelques petites différences d’affichage pour un même navigateur, selon le système d’exploitation (c’est assez rare mais ça arrive).
Mais est-ce que ces tests suffisent ?
J’ai bien peur que non malheureusement car il reste 2 points que nous n’avons pas encore abordé :
- la validité du code
- la résolution de l’écran
La validité du code |
Et oui car avoir un site affiché de manière identique (ou quasi-identique) sur l’ensemble des navigateurs c’est bien, mais avoir un code propre et correcte, c’est mieux !
Et s’il est relativement aisé d’obtenir un rendu sensiblement identique sur chaque navigateur, il est également très facile de faire une petite erreur qui rende votre code non-conforme aux standards.
N’hésitez donc pas à faire des tests, mais attention aux résultats : testez vos pages HTML, vos CSS, … avec les outils du W3C
Si vous avez Firefox, vous pouvez également installer l’add-on Firebug.
Quand je vois la quantité d’erreurs que m’affiche le validateur sur explainMe, je me dit qu’il reste encore quelques améliorations à apporter à Wordpress, ou plutôt à certains plugins car les erreurs sont plutôt de leur fait. Car pour le moment, c’est pas vraiment ça … Donc méfiez-vous aussi lors de l’utilisation d’une application livrée toute faite, personne n’est parfait.
N’oublions pas la résolution |
Aujourd’hui il est admis que la résolution standard est 1024 x 768.
Non franchement il reste encore des irréductibles qui tournent en 800 x 600 ?!.
Pour autant cela ne veux pas dire qu’il ne faille pas prendre en compte les résolutions supérieures.
En effet, avec la démocratisation des écrans plats cherchant tous à battre le record de la plus grande résolution possible (et pour les heureux possesseurs d’iMac de 22 pouce et plus 
) la résolution de 1024 x 768 est bien loin derrière…
Si votre site est développé avec une largeur fixe, vous ne risquez pas grand chose, mais si vous avez décidé que votre site s’adapterait en fonction de la largeur de l’écran de l’utilisateur, alors prenez garde à ne pas l’oublier lors du développement !
Ça m’est arrivé il y a peu avec le forum d’explainMe pour lequel les 2 barres de navigation utilisent une image de fond qui ne boucle pas. Malheureusement j’avais tout simplement oublié de spécifier une couleur de fond sensiblement identique (honte à moi 
). Du coup à partir de 1900 pixels de large, les liens (blancs) se retrouvaient sur fond blanc (donc invisible !). Pas très pratique pour cliquer dessus… 
À l’inverse, la majeur partie des designers (voir tous) ont bien évidement une résolution supérieure à 1024 x 768 (voir pour certains 2 écrans ou même plus), et cela peut également provoquer des erreurs de jugement puisqu’il nous est presque impossible d’avoir la moindre idée du rendu d’un site pour une résolution si petite comparée à la notre.
Et ben y’a qu’à modifier votre résolution les cocos !
Mais oui c’est ça ! Et la marmotte…
Pas la peine les amis, si vous êtes sous PC, Sizer risque de devenir pour vous un outil indispensable. Il n’a qu’une fonction, celle de redimensionner n’importe qu’elle fenêtre à n’importe qu’elle résolution (pas uniquement celle du navigateur, n’importe laquelle), mais il sait s’en acquitter avec brio !
Si vous êtes sous Mac, Sizer ne marchera évidement pas, mais vous pouvez toujours installer le plugin Webdevelopper pour Firefox. Il ne redimensionnera que la fenêtre du navigateur, mais c’est déjà ça.
En conclusion je dirais que finalement, même si les navigateurs tendent à s’améliorer avec le temps (on annonce de grands changements pour Internet Explorer 8, on verra bien 
), il faut toujours garder à l’esprit que l’on ne développe pas un site internet uniquement pour soi ni pour sa seule configuration. Donc inutile d’appliquer la doctrine « Qui peut le plus peut le moins » car dans ce cas précis se serait plutôt l’inverse…
[4,25 / 5 - 16 vote(s)]
Loading ...
Effectivement, faire en sorte qu’un site internet complet soit respectueux des standards du W3C, et que en même temps il s’affiche correctement pour tous les navigateurs du marché et fatalement pour toutes les résolutions est purement fictionnel. Le mieux est plutôt d’optimiser un maximum le site pour les premiers navigateurs utilisés.
Et oui, cette histoire de navigateurs est bien compliqué, mais je pense que ça s’arrangera. Personnellement, débutant dans les sites web, je contourne le problème en faisant 2 feuilles de style lorsque les différences sont vraiment trop importantes : une pour notre cher Explorer et une pour firefox. Mais tu ne parles pas de Linux ? Car lorsque j’ai mis mon site en ligne, je n’ai pas eu l’idée d’aller vérifier sous Linux aussitôt, lorsqu’un jour par hasard… surprise ! ça ne ressemblait à rien on peut le dire….
Oui je ne parle pas de Linux car aux vus des parts de marché les différentes distributions de Linux restent tout de même une toute petite minorité d’à peine 1% (mais souhaitons que cela évolue également
car Linux a beaucoup évolué depuis des années et des distributions comme Ubuntu, Open Suze, Mandriva ou autre méritent qu’on s’y attarde).
Cela dit je précise que je viens d’installer Ubuntu en dual boot sur mon portable pour justement pouvoir vérifier à quoi ressemble les sites que je développe sous Linux !
Pour le moment concernant explainMe je suis plutôt rassuré car j’ai la même chose que sur PC et Mac (excepté pour les polices puisque de base Ubuntu n’a pas les polices windows, évidement).
Sinon personnellement je trouve lassant de devoir faire 2 feuilles de style ou bien utiliser des hacks pour pallier aux erreurs des navigateurs, je préfère remanier ma feuille de style pour « adapter » mon souhait initial à la majorité des navigateur, car un jour ou l’autre les hacks ne seront plus valables et comme je suis un peu fainéant sur les bords, au moins je n’aurai pas à revenir dessus
!
Encore et toujours un article complet et bien pensé… Même si je n’applique pas tes cours (plus de développement web depuis plusieurs mois) je les suis toujours avec grand intérêt.
En l’occurrence, cet article me rappel mes déboires avec les différents navigateurs dans ma période faste, durant laquelle la compatibilité de nos page web avec ces 4 navigateurs principaux fût fastidieuse et ennuyeuse.
En effet, il est évident que développer un site internet nécessite à la base un lourd investissement de sois même, mais avec l’arrivée (déjà loin derrière nous) des concurrents à Internet Explorer et Safari le travail à fournir en est devenu conséquent.
Malgré tout il faut noter une très grosse amélioration (en constante évolution) du respect des normes des navigateurs principaux. Ceci nous facilite ainsi la tâche et nous permet de nous consacré d’avantage au design et/ou à l’interactivité du site web en développement.
Pour conclure, je pense qu’il faut continuer à adapter au mieux nos feuilles de styles au différents navigateurs, car tôt ou tard, chaque navigateur respectera scrupuleusement les normes W3C. En attendant, il existe comme vous les savez différentes façons de contourner ces différences entre nos navigateurs préférés: Hack, feuilles de style différentes, … Alors profitons en tant qu’il en est encore possible.
Merci à toi. Et bon courage pour la nouvelle aventure que tu t’apprête à vivre
(bien plus délicate que le développement web je pense…) !
L’aventure a déjà commencé depuis le 17 janvier
Ah ! Félicitation ! (désolé j’ai due raté un wagon).
Super article, juste un point ou je suis pas d’accord mais alors DU TOUT avec toi :
»Quand je vois la quantité d’erreurs que m’affiche le validateur sur explainMe, je me dit qu’il reste encore quelques améliorations à apporter à Wordpress »
Si tu as des erreurs sur ton blog, elles viennent de ton thème et non de wordpress, des erreurs donc très facilement résolvable !
Au premier abord je ne peux qu’être d’accord avec toi. Et d’ailleurs il est vrai qu’après avoir refait un peu le tour des balises et des css, certaines erreurs se sont rapidement résolues.
À vrai dire il ne s’agit pas tellement de Wordpress (je vais modifier ma phrase sur ce point d’ailleurs) mais plutôt des plugins qui pour certains génèrent des codes pas toujours très respectueux du standard. Face à ça 2 solutions :
- soit je mets les mains dans le cambouis et je modifie à la main le code du plugin en question
- soit je laisse tel quel et tant pis pour la validation.
Personnellement je préfère ne pas modifier un plugin à la main car à la moindre mise à jour je serai obligé de refaire la correction (si jamais elle persiste). Du coup c’est une histoire sans fin, et dans le cas présent, le temps que je ne passe pas en développement sur le site est autant de temps que je passe en rédaction de contenu, donc mon choix est vite fait.
Donc malheureusement non toutes les erreurs ne viennent pas de mon thème (et j’aurais préféré), mais plutôt des plugins que j’utilise (très peu d’ailleurs).
Cela-dit la majorité des soucis semble liée aux URL (celles qui vont vers le forum d’une part, apparemment un souci avec les variables passés en GET, et les URL rewritées dans le footer d’autre part).
J’en profite pour passer un message : si quelqu’un à une idée du pourquoi du comment…
Concernant ton code, j’ai analysé les erreurs, et je t’en ferais par sur msn, cela sera plus simple pour l’explication.
Les news de la validation :
nam0 m’a donc contacté par msn aujourd’hui car il souhaitait regarder mon souci de validation W3C.
Et comme je le soupçonnais suite à mon analyse du code, une erreur était due au plugin Wp2BB qui me permet de faire un lien entre le blog et le forum. Il ajoutait une balise « </a> » sans balise « <a> », ainsi qu’un & qui n’était pas affiché avec le code HTML & dans les URL.
Bref au final nam0 à carrément farfouillé le code du plugin pour m’indiquer où effectuer les corrections (je me la suis joué grosse feignasse sur le coup je l’avoue :/).
Une fois la modification du plugin effectuée (y’a que les imbéciles qui ne changent pas d’avis il paraît…) : XHTML valide !
De plus le CSS de mon thème semble également correct (mise à par quelques avertissements), certains CSS de plugin comportant encore des erreurs.
De toute façon il ne s’agit là que de la validation de la page d’index !
Et oui j’ai testé la page du chapitre 4 sur flash juste histoire de voir : presque 300 erreurs !
Je ne souhaite pas jeter la pierre sur les plugins ni dire : « moi j’ai un code propre et pas eux ». Ce serait ridicule de ma part et totalement inutile.
Le fait est que j’utilise un grand nombre de plugins (pour afficher le code, pour des effets de mise en page, pour afficher les vidéos, les votes,…) et ils me rendent tous d’énormes services pour « habiller » mes explications et les rendre plus compréhensibles également donc je préfère les utiliser tel quel au risque d’avoir des erreurs de sémantique plutôt que de m’en passer ou passer du temps à régler ces petis désagréments.
Le principal c’est que le blog soit lisible sur un maximum de navigateur.
Etant donné que tu n’es pas l’auteur de Wordpress, ni de ses plugins tu ne peux rien te reprocher
Après la validation ca reste une question d’ordre personnelle…
Petit commentaire simple pour souhaité une très bonne continuation à ce blog très sympa, aux sujet intéressants et bien expliqué
Il m’a appris beaucoup en très peu d’article
Encore bonne continuation à tous.
Merci à toi !
Je vais faire de mon possible pour continuer sur ma lancée
« Pour ma part je pense qu’il n’est évidement pas possible de tester un site avec tous les navigateurs. Tout d’abord parce que cela prendrait beaucoup trop de temps… »
Il existe http://browsershots.org qui permet justement de tester chaque site avec chaque navigateur et chaque système d’exploitation.
Temps de vérification: attente de 30min maximum pour recevoir les screenshots!
Pourquoi pas, c’est une solution intéressante.
Maintenant je ne pense pas que l’on puisse réellement juger de la compatibilité d’un site uniquement sur un screenshot.
Je suis peut-être « puriste », mais j’aime bien voir comment se comporte le site lorsque je redimensionne la fenêtre du navigateur ou comment sont gérer les rollovers et autres petits détails qui font aussi le design.
ÉDIT : même chose pour les plugins qui permettent d’émuler le moteur de IE dans FF par exemple car les interfaces (hors fenêtre d’affichage du site) sont différentes d’un navigateur à l’autre et tout doit rentrer pour une résolution donnée.
Je sais la je chipote.
Le plugin n’émule pas IE, il ne fait que lancer une instance d’IE dans un onglet. L’affichage sera donc identique, à l’exception de la largeur des barre de navigations, qui ne sont pas de la même taille à quelques pixels prêt.
Autant pour moi. Mais cela ne change pas grand chose je trouve : autant utiliser IE directement.
Fait intéressant, selon une étude mené par microsoft, Linux serait en train de dépasser Mac (ici). Je crois que celui-ci aurait droit à sa place ^^. Sinon, ce que j’aime testé aussi c’est la taille d’écriture. Un simple Ctrl+roulette de souris et la page se transforme. Très utile pour un site qui se dit ‘accessible’.
En effet c’est très intéressent. Et plutôt logique d’ailleurs. Car bien qu’Apple propose un système très abouti il n’en reste pas moins que la firme conserve une politique tarifaire assez élitiste qui, fatalement doit lui faire perdre une partie de la clientèle « grand public ». De plus Linux a fait d’énormes progrès en terme « d’image » ces dernières années avec des distributions plus orientées « grand public » justement comme Mandriva, Ubuntu et d’autres… Donc il est logique à mon sens que Linux grigonte de l’espace plus largement que Mac qui reste « à part » (ce qui est regrétable d’ailleurs je trouve, même si les puristes préfèrent cela).
Pour ce qui est de l’astuce de zoom [Ctrl + molette de la souris], elle est en fait une fonctionnalité proposée par la principaux navigateurs (Opera 10 , IE7 et Firefox 3) et n’a donc pas grand chose à voir avec le codage du site puisque totalement indépendante.
En revanche il est sûr qu’il est toujours possible de « faire plus » pour améliorer l’accéssibilité d’un site et d’ailleurs certains sites proposent des fonctions permettant d’augmenter la taille du texte via le javascript : un exemple de script
Article plus qu’intéressant (et juste… « trouvé à dire » plutôt « trouver »).
Mais, étant un utilisateur assez récent de l’internet (j’avais pas en 1980…), c’est sûr que les CSS n’ont jamais existés ?
Ah, au fait, même en 2009, y’a des designers qui continuent de coder avec des tab’… Après, c’est sûr que ça fait plus codé avec les pieds…
Merci.
»… ’est sûr que les CSS n’ont jamais existés ? »
À priori j’ai trouvé 1994 sur internet comme date de création des CSS (maintenant je ne garantie pas la fiabilité de l’info).
).
De plus il s’agissait plus d’une image que de faits réels (moi non plus je ne codais pas en 1980, j’avais déjà les mains prisent par le biberon
Et Oui il y a encore des designer qui utilise les tabs (dans certains cas ça m’arrive encore d’ailleurs).
P.S. : merci pour la faute, je corrige immédiatement.