Cet article est écrit par Christophe Davy, dirigeant de Brand Online Commerce, qui est « l’invité permanent » de François sur ce blog.
Il fut un temps pas si éloigné où les concepteurs de sites, e-commerce ou pas, avaient le sourire : le marché des navigateurs évoluait vers plus de compatibilité et le travail consistant à valider l’affichage et l’utilisation d’un site internet sur tous les navigateurs (la recette cross-navigateurs) devenait une formalité.
Tout le monde le sait, historiquement, c’est Internet Explorer qui est le vilain petit canard : de version en version, ce navigateur a connu de multiples refontes, pas toujours en accord avec les standards. Sa popularité chez les développeurs de sites web est inversement proportionnelle à celle des hormones de croissance dans le peloton cycliste…
La perte progressive de parts de marché d’Internet Explorer au profit de navigateurs plus respectueux des standards (Firefox, Safari, Opera,…) laissait présager de jours meilleurs et provoqué un regain de confiance chez les développeurs. Mais malheureusement, il semblerait que Chrome vienne (déjà) tout gâcher !
Le navigateur de Google, qui communique sur sa simplicité, sa rapidité et sur sa dimension je-suis-cool-parce-que-j’utilise-un-produit-Google, réinvente les soucis de compatibilité que l’on croyait réservés à Internet Explorer !
Chez Brand Online Commerce, à l’occasion de la mise en ligne du site e-commerce de la marque Helena Rubinstein, qui incorpore une plateforme Magento couplée à pas mal de flash, de vidéos et autres barres flottantes, nous avons découvert dans la douleur que Chrome était plus que difficile à dompter.
Nous qui pensions surtout à vérifier la compatibilité du site sur les différentes versions d’Internet Explorer, nous avons été surpris de devoir batailler sur certains points d’intégration avec Chrome. Et depuis, à chaque fois que nous partageons cette surprise avec d’autres personnes, nous faisons le constat que Chrome pose des problèmes à pas mal de concepteurs de sites.
Bon, ne soyons pas dupes : pour que Chrome soit le navigateur le plus rapide du marché, c’est bien que Google a dû faire quelques impasses sur les normes, non ?
Perso, c’est toujours IE qui me pose le plus de soucis… Mais c’est vrai que Chrome pose quelques soucis aussi.
Par contre, la conclusioon me semble se reposer sur une idée complétement bancale : Dire que si Chrome est si rapide, c’est parcequ’il fait l’impasse sur quelques normes, c’est prétendre que le respect des normes et des standards est un frein à la performance.
Je ne suis pas tu tout sûr que mieux respecter les normes causerait de moins bonnes performances…
@LapinLove404
Je finis par une question, je n’en sais rien et tu as raison de dire que c’est peut-être une réflexion bancale.
Néanmoins, on peut tout de même imaginer, faute de mieux, que les développeurs de Google ont trouvé des astuces de programmation pour accélérer les performances du navigateur Chrome, et que certaines de ces astuces nécessitent de faire l’impasse sur du code lié au respect des normes, non ?
Oui, je suis plutôt d’accord avec lapin.
Maintenant, il faut le savoir, faire une norme qui garanti à 100% que tous les navigateurs auront exactement le même comportement est très, très, très (…) difficile.
En son temps, NTT docomo avait même abandonné, et finalement imposé son navigateur…
Bon, en plus, les navigateurs font la course pour mettre en oeuvre le HTML5, pas encore normalisé…
Très bon sujet donc 😉 avec en plus la complexité des nouveaux terminaux d’accès, voir la déferlante des tablettes attendue.
D’ou mon idée, proposé sur le billet précédent, d’un langage et d’un framework permettant plutôt une génération du html… Mais ça, ça existe pas encore.
Et les hormones de croissance dans le foot, le rugby et tout autre sport???
A mon avis, ce que les développeurs ont préféré c’est passer plus de temps sur l’optimisation des performances que sur le respect parfait de normes et standards (plus ou moins bien définis).
@François : Sans aller aussi loin, le HTML5 Boiletplate propose une solution qui permet une certain flexibilité face aux navigateur, entres autres via les classes dynamiques.
Bon, faut encore cross-tester le bazar, mais ca aide 😀
http://html5boilerplate.com/
Je ne pense pas que chrome soit le problème.
Si vous pouviez mettre des exemples de comportement incorrects cela pourrait vraiment enrichir votre propos.
Le plus gros problème à mon sens est la multiplication des versions induites par ces release plan extrêmement resserrées dans le temps. Si on peut penser que les utilisateurs pensent de plus à mettre à jour leur navigateur et que les maj automatiques aident, il n’en demeure pas moins que le spectre de versions s’étend.
Le seul défaut de chrome sur le sujet c’est d’utiliser le moteur « webkit » crée par Apple et qui respecte bien mieux les standards que les autres. Il est aussi plus rapide pour la simple et bonne raison que c’est le plus récent. Taper sur chrome, d’accord. Mais pas sur ces sujets là. S’il y en a un qui n’a pas fait l’impasse sur les standards, c’est bien chrome/safari.
Étrange que ce diagnostic ne se retrouve pas dans les divers bench de conformité aux standards qu’on trouve sur le Web (Acid3 restant le plus populaire, au moins pour la couche CSS qui constitue une très grosse partie de l’intégration graphique), alors que ces tests couvrent quand même une sacré variété de cas d’utilisation.
En ce qui me concerne j’utilise Chrome au quotidien, c’est donc le premier browser sur lequel je réalise une intégration et je n’ai pas le recul pour valider ou non cet article. Néanmoins, ça me semble un peu louche.
D’accord avec Jaffeux, des exemples seraient les bienvenus
( J’ai pour ma part constaté des difficulter pour implementer de l’opacité sous chrome-linux uniquement. )
LapinLove404 a écrit : « Par contre, la conclusioon me semble se reposer sur une idée complétement bancale : Dire que si Chrome est si rapide, c’est parcequ’il fait l’impasse sur quelques normes, c’est prétendre que le respect des normes et des standards est un frein à la performance. »
Pour moi ça peut paraître logique, je ne suis pas concepteur de navigateur, tout comme toi (je suppose), mais imaginons que pour mettre le navigateur aux normes, il faut plus de lignes de codes (ce qui parait logique, un peu comme pour certaines normes HTML), qui dit plus de lignes de codes, dit plus de traitements, et ce pour chaque pages internet qui sera chargée lors de l’analyse du code source pour interprétation.
Ils ont donc surement fait impasse sur certaines normes qui pour eux n’avait pas plus d’importance que d’autres ou utilisaient plus de ressources que les autres.
@Jaffeux @opi
J’ai écrit mon message après plusieurs semaines de travail à finaliser le site HR en ayant un oeil simultanément sur Firefox 3.4 et 4, IE7, IE8, IE9, Chrome et Safari. Et autant nous n’avons pas été surpris des difficultés à intégrer le site sur les différentes versions d’IE (même plus mal…), autant on a constaté qu’on avait plus de mal avec Chrome qu’avec IE9 ou Firefox 4 sur des points d’intégration complexe (Magento + une autre techno).
2 exemples : le flash plein écran de la homepage, et la barre flottante collée au bas de l’écran.
Attention ! Je répète qu’on est dans un contexte Magento, ce qui vient complexifier la mise en oeuvre de ces technos.
@Empty
J’ai suivi le même raisonnement que toi. Je pense qu’il est difficile de faire plus rapide que le concurrent sans faire quelques impasses. Et avec notre site HR, on est peut-être tombé là où il ne fallait pas tomber.
Très étonnant cet article, on frise la polémique 😉
Le sujet est très sensible pour toute la profession…
Alors j’ai qq interrogations:
Peut-on avoir qq précisions sur les elements de code incriminés?
S’agit-il de CSS? De JS j’imagine…? Mais quel framework? (Z’utilisez surement un framework jquery ou autre?)
Et surtout, par rapport a Safari, y a t il eu des différences d’interprétation du code?
Au plaisir de vous lire!
Intéressant.
D’experience je dirais plutôt que ce qui passe avec Chrome passe sur les autres : Firefox, Opéra et Safari (je ne parles pas des IEXXs). A l’inverse, si on integre avec Firefox on peut avoir des surprises avec Chrome, Opéra et Safari. Je dirais donc, de façon totalement subjective, que c’est plutôt Firefox qui ne respecte pas aussi bien les normes que Chrome, Opéra et Safari.
Le débat reste ouvert.
Il y a des standards clairement détaillés et c’est évident que Chrome fait l’impasse sur beaucoup de choses. Je suis assez d’accord sur le fait que Google a du retirer certains parsages trop gourmand pour obtenir un gain de performance. D’abord on fait acquisition du marché grâce à la performance, ensuite on se met au standart pour garder tout ce petit monde et ne pas porter l’étiquette du new IE.
Je n’ai plus en tête tous les bugs de Chrome mais il est aussi chiant que IE en terme de respect des standards.
Pour ceux qui se posent la question faite un design assez évolué (avec des positions absolute, text-align:center, vertical-align:middle, margin:auto, float, display, opacity, des ombres, des sprites, … des changements CSS dynamique via Jquery, …) qui respecte les normes W3C -> affichez votre design sous-Chrome et vous verrez certains attribut CSS pas correctement pris en compte, certains effets Jquery qui ne fonctionnent tout simplement pas ou bizarrement.
Un simple width:100% dans certains encapsulages n’est pas pris en compte par Chrome o_O
Est-ce trop gourmand de calculer à la volée des dizaines de x,y imbriqués et superposés sur plusieurs Flux + les variations du DOM (scroll, etc) ? Oui quand on a 20 onglets d’ouverts, Firefox et IE savent le faire contrairement à Chrome.
Si Google fait des rognages du genre on a pas finis d’en chier …