Quelque que soit le type de site sur lesquels ils sont implémentés (e-commerce, blog, sites d’actualités, etc.), ces boutons de partage ont un intérêt non négligeable puisqu’ils permettent de rendre son contenu facilement visible au plus grand nombre.

Il peut donc être intéressant de mesurer ces interactions sociales sur votre site internet. Combien d’internautes ont liké votre dernier article ? Combien l’ont unliké ? Combien l’ont liké en provenant d’un moteur de recherche ? Quel pourcentage des conversions proviennent d’internautes socialement engagés ? Vous l’aurez compris : le plus important est de pouvoir segmenter ces données pour connaître toujours davantage vos internautes.

Google nous propose aujourd’hui un tag permettant de récupérer ces données sur son outil Google Analytics : le _trackSocial.

Qu’est-ce que le _trackSocial ?

Le _trackSocial vient se rajouter à l’ensemble des autres tags Analytics tels que le _trackPageView, le _trackEvent, le _trackPageLoadTime, etc.

Il est construit de cette façon si :

_trackSocial (network, socialAction, opt_target, opt_pagePath)

• Le paramètre « network » nécessite une chaîne de caractères indiquant le réseau sur lequel l’action a lieu (ex : Facebook, Twitter).
• Le paramètre « socialAction » nécessite une chaîne de caractère indiquant l’action que réalise le bouton (ex : Like, Unlike, Send, Tweet).
• Le paramètre « opt_target » (optionnel) nécessite l’URL de la page cible.
• Le paramètre « opt_pagePath »(optionnel) nécessite l’URL de la page sur laquelle a eu lieu l’action.

Pour comprendre ces deux derniers paramètres, voici un exemple :

Le blog de Synerg’heTiC vient de publier un article. Voici l’URL de l’article :
http://blog.synerghetic.net/2011/08/26/deux-semaines-de-news-campagnes-buzz-3/
L’article s’affiche donc en mode complet à la page :
http://blog.synerghetic.net/2011/08/26/deux-semaines-de-news-campagnes-buzz-3/)
et en mode court sur celle-ci :
http://blog.synerghetic.net

Les boutons Like et Tweeter sont sur les deux pages.

Prenons deux utilisateurs A et B :

• L’utilisateur A like l’article sur la page de celui-ci : http://blog.synerghetic.net/2011/08/26/deux-semaines-de-news-campagnes-buzz-3/, le tag sera donc :

_gaq.push(['_trackSocial', 'facebook', 'like',
'http://blog.synerghetic.net/2011/08/26/deux-semaines-de-news-campagnes-buzz-3/',
'http://blog.synerghetic.net/2011/08/26/deux-semaines-de-news-campagnes-buzz-3/']);

• L’utilisateur B quant à lui, like l’article sur la page : http://blog.synerghetic.net/, le tag sera donc :

_gaq.push(['_trackSocial', 'facebook', 'like',
 'http://blog.synerghetic.net/2011/08/26/deux-semaines-de-news-campagnes-buzz-3/',
'http://blog.synerghetic.net/']);

Cela permettra d’analyser par la suite, sur quelle page le contenu a été le plus partagé et bien d’autres données, aussi segmentées soient-elles.

L’implémentation du tag

Le tag _trackSocial s’implémente de manière différente selon l’action à réaliser (Like, Unlike, Send, Tweet).

Facebook : Bouton Like

Pour pouvoir récupérer les données d’un Like sur Google Anlaytics, il faut utiliser l’évènement edge.create et une fonction de rappel qui se lance quand l’évènement se déclenche. L’URL de la ressource est alors passée en paramètre afin de pouvoir la récupérer dans Google Analytics.

FB.Event.subscribe('edge.create', function(targetUrl) {
  _gaq.push(['_trackSocial', 'facebook', 'like', targetUrl]);
});

Facebook : Bouton UnLike

De la même manière que précédemment, on utilisera une fonction de rappel mais cette fois-ci avec l’évènement edge.remove :

FB.Event.subscribe('edge.remove', function(targetUrl) {
  _gaq.push(['_trackSocial', 'facebook', 'unlike', targetUrl]);
});

Facebook : Bouton Send

Ici on utilise l’évènement message.send pour implémenter le bouton Send :

FB.Event.subscribe('message.send', function(targetUrl) {
  _gaq.push(['_trackSocial', 'facebook', 'send', targetUrl]);
});

Twitter : Bouton Tweeter

Pour ce qui est de Twitter et de son bouton Tweeter, le fonctionnement global est le même. On attache une fonction de rappel à l’évènement tweet. Quand l’évènement se déclenche, la fonction est appelée pour récupérer l’URL de la ressource tweetée (qui a été stockée dans une iFrame) afin de la passer en paramètre du tag :

twttr.events.bind('tweet', function(event) {
  if (event) {
    var targetUrl;
    if (event.target && event.target.nodeName == 'IFRAME') {
      targetUrl = extractParamFromUri(event.target.src, 'url');
    }
    _gaq.push(['_trackSocial', 'twitter', 'tweet', targetUrl]);
  }
});

Ces fonctions sont uniquement en Javascript : elles doivent donc être tout simplement mises entre balises script et à intégrer avant la fermeture de votre balise body.
A noter : il n’y a pas besoin d’implémenter le tag pour le bouton +1. Celui est automatiquement récupéré par Google Analytics.

L’analyse des données avec Google Analytics

Avant tout propos, sachez qu’il vous faudra la version 5 de Google Analytics pour constater les résultats.

Sur cette version donc, vous avez dans la rubrique « Visiteurs », un onglet « Réseaux sociaux » dans lequel il y a deux intitulés : « Intérêt et interaction » et « Pages ».

Intérêt et interaction

Sur cette page, vous apercevez le nombre de « visites sociales ». C’est-à-dire les visites ayant déclenché un évènement social tel qu’un clic sur le bouton Tweeter ou un Like.

Si vous cliquez sur les visites qui sont socialement engagées, vous atterrissez sur une page avec le détail des actions qui ont été réalisées sur votre site.

Vous avez ainsi la possibilité de segmenter l’ensemble de vos données en fonction de vos visites sociales. Cela permet de récolter des données très intéressantes sur ces visites parmi lesquelles leur taux de conversion, leur source principale, etc… A votre guise !

Pages

Sur cette partie, vous avez la liste des URLs qui ont été l’objet d’une action sociale (option « Entité sociale ») et la liste de celles sur lesquelles ont été effectuées les actions (option « Page »). Pour comprendre la différence entre les deux, je vous invite à relire la partie « Qu’est-ce que le _trackSocial ? » un peu plus haut.

De la même manière que précédemment, l’intérêt est double. Vous avez une vue sur vos contenus qui ont été partagés et la possibilité de segmenter les données selon les critères que vous désirez en créant un segment personnalisé.

A noter : les données que vous récupèrerez ne correspondront uniquement qu’aux actions ayant été faites sur votre domaine. Si votre article reçoit un Like, Unlike, Send, Tweet ou un +1 hors de votre domaine, il ne sera pas comptabilisé dans les rapports Google Analytics.
Cependant, il existe une alternative pour le bouton +1 puisque vous avez toujours la possibilité de récupérer la donnée totale sur les Google Webmasters Tools.

Conclusion

Certains se diront peut-être que l’on peut obtenir le même genre de données en utilisant le tag _trackEvent. Ce n’est pas totalement faux. Le _trackSocial permet juste beaucoup plus de flexibilité avec les données.

Par exemple, la distinction entre la page partagée et la page où a eu lieu le partage serait difficilement récupérable avec le _trackEvent (il faudrait concaténer ces deux pages dans le paramètre Label du tag). Et dans l’hypothèse où vous souhaiteriez fonctionner comme ça, vous auriez beaucoup plus de mal à segmenter vos données.

Et vous, que pensez-vous du _trackSocial ? Vous l’utilisez sur votre site ?

Partagez vos astuces !

Les événements « touch »

Les « touch events » sont comparables aux événements « mouse » que l’on connaît déjà depuis longtemps, et qui fonctionnent toujours d’ailleurs sur ces supports tactiles. Ils sont au nombre de trois :

-          touchstart ( = mousedown) : s’initiliase lorsqu’un doigt touche l’écran
-          touchmove ( = mousemove) : s’initialise lorsqu’un doigt bouge sur l’écran
-          touchend ( = mouseup) : s’initialise lorsqu’un doigt ne touche plus l’écran

Ces fonctions doivent s’initialiser avec les fonctions « bind » ou « live » (pour jQuery).

$(‘element’).bind(‘touchstart’, function(event){
   var e = event.originalEvent ;
   event.preventDefault() ;
   var firstFinger = e.touches[0].pageX ;
}) ;

La création d’une variable égale à « event.originalEvent » va permettre de récupérer de nombreuses informations telles que la position des doigts sur l’écran, le nombre de doigts posés … L’appel de « event.preventDefault() » agit comme un « return false », mais peut se placer n’importe où dans la fonction (à la fin pour le « return false »). Il va permettre d’annuler les actions qui sont effectuées normalement. Ainsi, lorsque vous allez bouger votre doigt sur l’écran, celui-ci doit normalement scroller la page. Avec cette fonction tout est annulé et vous pouvez faire ce que bon vous semble de la page.

Les événements « gesture »

Les « gesture events » vont permettre d’agir sur le zoom et la rotation d’un élément principalement. Ils vont s’initialiser de la même manière que pour les événements « touch », et vont agir grâce aux propriétés webkit du CSS3. Ils sont aussi au nombre de trois :

-          gesturestart : s’initialise lorsqu’au minimum deux doigts sont posés sur l’écran
-          gesturechance : s’initialise lorsqu’au minimum deux doigts sont posés et bougent sur l’écran
-          gestureend : s’initialise lorsque deux doigts ne touchent plus l’écran

Ainsi pour zoomer par exemple :

$(‘element’).bind(‘gesturechange’, function(event){
   var e = event.originalEvent ;
   event.preventDefault() ;
   $(this).css(‘-webkit-transform’, ‘scale(‘+e.scale+’)’) ;
}) ;

La grande utilité du moteur graphique de webkit

L’avantage de développer sur des supports embarquant les dernières technologies, en l’occurrence webkit ici, permet d’en profiter pour ses animations graphiques. Ainsi l’appel de la propriété « –webkit-transform »  associée à ses valeurs « scale(x) », « rotate(x deg) » ou encore « translate3d(x, y, z) » permet d’améliorer le rendu de vos animations en les rendant beaucoup plus fluides. Ainsi la modification des valeurs de « translate3d » est beaucoup plus performante que la modification du « top » ou « left » d’un élément en « position : relative » par exemple.

Préférez aussi l’utilisation des animations CSS3 à la place de la fonction « animate » de jQuery, dont voici un exemple :

-webkit-transition : -webkit-transform 0.5s ease-in

Annexes :

Toutes les propriétés de webkit
Doc Apple pour Javascript sur iPhone

Face à la popularité grandissante du « mobile » dans le paysage de l’Internet, la junior entreprise Synerg’heTIC a lancé l’an passé, un groupe de travail chargé d’assurer une veille continue sur les différents thèmes du « web mobile », afin de répondre du mieux que possible aux besoins croissants des entreprises.

Un récent sondage au sein d’une des promotions d’HETIC a montré que de nombreux élèves souhaitaient participer à des projets liés à l’Internet mobile.
L’un d’entre eux, Laurent Bracquart fait aujourd’hui le point sur la partie « interfaces » du sujet.

Intéressé par ce nouveau terrain de jeu qui s’offre à nous, j’ai rédigé il y a quelques semaines une synthèse quant au développement de sites et d’interfaces dits « mobiles ». Cette synthèse met en relief certains points cruciaux dont on parle peu – ou pas – chez les professionnels du Web français, encore sous l’emprise de l’effet de mode.

Le Web mobile (et, par extension, l’Internet mobile) est naissant, et part pour le moment dans « tous les sens ». Cette fiche est une synthèse des problématiques et des bonnes pratiques constatées à ce jour quant au développement d’interfaces adaptées à ce nouveau média. La lecture de ce document permettra au lecteur d’appréhender l’extrême complexité et le nombre de données à prendre en compte pour se lancer dans l’aventure en connaissance de cause.

En bref, l’Internet mobile, c’est…

4 contraintes majeures

• La largeur de l’écran, limitée par exemple à 480px ou 320px sur l’iPhone d’Apple.
• La taille de l’outil de pointage : Il est envisageable que l’outil « doigt » se démocratise progressivement.
• La linéarisation de la page, dans le cas d’un affichage en mode Web dit « non classique ».
• L’absence de « vrai » haut-débit, contrairement à ce qu’annoncent les sirènes du marketing.

Plusieurs types de Web mobile, plus ou moins populaires

• Le WAP
• L’i-mode et son langage de balisage spécifique, le i-HTML.
• Le Web en mode linéaire :  Les contenus s’affichent selon l’ordre d’écriture dans le code HTML.
• Le Web accessible via des terminaux récents du type iPhone ou HTC Hero.

Différents navigateurs

• Navigateurs textes.
• Navigateurs vocaux, utilisant le haut-parleur intégré.
• Navigateurs sans styles.
• Navigateurs adaptés aux mobiles du type Opera Mini.
• Navigateurs dits « classiques » (iPhone).

Des approches à réinventer

• Techniques.
• Ergonomiques.
• Éditoriales.
• Graphiques.

L’approche actuelle : une régression ?

Dernièrement, on a pu voir fleurir sur le Web de nombreuses versions de sites estampillées « version iPhone ». Une mode.

Cette approche, bien que de plus en plus répandue, est une aberration à long terme et témoigne d’un manque de compréhension des problématiques d’accessibilité majeures de la part des acteurs du Web français. Elle laisse de côté les autres smartphones et met à mal les efforts de standardisation du W3C. Techniquement, elle nous fait revenir à l’époque de la balkanisation du Web, celle où chaque site digne de ce nom proposait à la fois une version Netscape et une version Internet Explorer.

Pour autant, elle bouscule les conventions. Par ce simple fait, elle est donc appréciable et permettra à terme de définir de nouvelles conventions plus évoluées et adaptées.

Afin de doser le propos et de prendre du recul, deux liens intéressants :

• « En conclusion, avec le web mobile, et aussi le web des objets, nous sommes certainement assez loin de l’application unique et standardisée, mais ce ne sont pas les mêmes métiers qui interviennent : l’éditeur conçoit et fournit le contenu, l’agence web le met en forme pour le PC de bureau, et les développeurs d’applications reprennent les flux pour les widgetiser en fonction du support. », Eric Dupin (http://www.presse-citron.net/les-app-stores-vont-ils-tuer-lespoir-dun-standard-unique)
• « A moins que j’ai oublié quelque chose, le choix de développer un version spécifique non pas à une famille d’usages, mais à un agent-utilisateur spécifique comme l’iPhone est un méchant retour en arrière.« , Elie Sloïm (http://list.accessiweb.org/pipermail/accessibilite-numerique_list.accessiweb.org/2007-November/001566.html)

Le document de référence

Les  »Mobile Web Best Practices » de la MWI (Mobile Web Initiative), groupe de travail du W3C chargé de développer des standards pour l’Internet mobile.

Ce document a été publié dans sa version finale en Juillet 2008. Contrairement à beaucoup d’autres recommandations issues des groupes de travail du W3C, celui-ci est clair, concis et pragmatique. Sa lecture est cruciale avant de se lancer dans ce type de projet.

Les bonnes pratiques majeures

• Le Web mobile, c’est surtout une problématique d’accessibilité. C’est principalement en raison de la méconnaissance des professionnels du Web quant à cette problématique que le Web mobile cherche sa voie. Le W3C conseille à ce propos la lecture des  »Web Content Accessibility Guidelines 2.0 » de la WAI (Web Accessibility Initiative). Pour autant, ce document est relativement imbuvable, voire totalement inadapté pour certains. Une bonne chose est alors d’écouter les utilisateurs et de privilégier le bon sens.
• Supprimer le préfixe « www » et raccourcir les noms de domaines permet de faciliter l’accès au service via un périphérique mobile.
• L’importance des attributs  »width » et  »height » sur les balises <img /> qui évitent au serveur de parcourir à nouveau la page.
• Minimiser le nombre de balises HTML.
• Intégrer selon les normes XHTML Basic 1.1 et CSS 2.1.
• Encoder en UTF-8.
• Ne pas utiliser de JavaScript.
• Développer un unique site, quelle que soit la plate-forme cible.

Les problématiques majeures

• Le problème des styles CSS livrés au type de média « handheld« , qui ne sont en réalité que très peu interprétés par les périphériques mobiles. La cause ? Un choix marketing : la peur que les acteurs du Web fournissent une version dégradée peu attractive aux consommateurs mobiles (et donc le flop marketing engendré).
• La question du contenu : doit-on donner les mêmes informations lors d’une navigation via un périphérique mobile ?
• Les usagers de l’Internet mobile l’utilisent souvent pour rechercher une information précise (horaires, adresse, etc.), contrairement aux utilisateurs non-nomades, qui naviguent principalement au gré des liens.
• Le problème actuel du coût de la navigation (bande passante, abonnements, etc.).
• Que privilégier entre un scroll ou une pagination ?
• La problématique du nombre de périphériques et logiciels à tester : envisageable pour le Web non nomade, totalement farfelue pour le Web mobile et ses milliers de périphériques différents.
• La problématique de l’endurance de la batterie.
• Comment gérer efficacement les messages d’erreurs et de confirmation ?

Les ouvertures

• Les raccourcis clavier prendront avec le mobile tout leur sens s’ils arrivent à s’imposer.
• L’utilisation de la voix pour naviguer (car oui, il ne faut pas oublier que les périphériques mobiles sont avant tout des téléphones).
• L’exploitation des données de géolocalisation.

Pour aller plus loin…

• S’il y a bien une annexe à lire : Une excellente synthèse des problématiques liées au Web mobile aujourd’hui, par l’AWT (Agence Wallonne des Télécommunications).
• Une mine : une liste quasi exhaustive des périphériques mobiles permettant l’accès au Web, accompagnée de caractéristiques détaillées (type d’OS, largeur écran, etc.)…
• …fruit de la plus importante communauté indépendant orientée développement mobile au monde : http://mobiforge.com.
• Voir aussi les autres services liés aux deux liens ci-dessus.
• Présentation des bonnes pratiques du Web mobile par la MWI à Polytech’Nice-Sophia.
• A lire et voir : Une réflexion intéressante avec une vidéo percutante de 2 minutes en bas de page.

Note

• « Web mobile » est une appellation souvent erronée car on l’utilise souvent pour parler des services annexes au Web : messagerie, téléphonie, etc. L’ensemble de ces services (Web compris) forment l’Internet mobile.

Synthèse rédigée par Laurent Bracquart

Profitons de ce tour de force pour faire un tour du marché des navigateurs. À ce jour il existe quatre grands moteurs de rendu HTML (fonction vitale qui permet de générer les pages web) : Webkit (Moteur utilisé par Safari), Gecko (Moteur utilisé par Firefox), Trident (Moteur utilisé par Internet Explorer) ou Presto (Moteur utilisé par Opera). Chacun de ces moteurs évolue d’année en année en essayant de réaliser un score parfait aux différentes versions de l’Acid Test (version 1, version 2 et version 3). Ces tests ont été créés pour que les navigateurs évoluent en respectant les standards du web, les développeurs se surpassent donc d’année en année pour être les premiers à passer le test avec succès. Les premiers à avoir passer le Test Acid 3 sont les développeurs de Webkit suivis le lendemain par ceux d’Opera (fin mars 2008).

À cause de cette évolution fulgurante de nos navigateurs, à quoi doit on s’attendre pour les prochaines années à venir ? Le W3C (Organisme qui établit les nouveaux standards pour le web) a commencé les tables rondes pour une nouvelle version de CSS (CSS 3)  et une mise à jour de HTML (HTML 5). Les premières idées qui pourraient être validées dans cette nouvelle version de CSS seraient entre autres la propriété border-radius (pour arrondir les angles de vos blocs), la propriété resize (permettant à vos visiteurs de redimensionner un bloc de la page sans librairie JavaScript supplémentaire), la propriété text-shadow (ajoute une ombre à votre texte) et bien d’autres encore. Si vous souhaitez obtenir plus d’informations vous pouvez consulter le document de référence pour les réflexions sur CSS 3. HTML 5 (ou XHTML 5)  quant à lui risque d’apporter des fonctionnalités très intéressantes aux développeurs, on compte parmis les idées énumérées (et déjà quasiment validées) les balises vidéo (permettant d’insérer directement une vidéo), audio (permettant d’ajouter un fichier audio), canvas (permettant de dessiner des formes et d’intéragir avec [visualiser avec Firefox 3]) et section (permettant d’augmenter la sémantique du contenu). Ces premières refléxions autours du HTML 5 sont très bien illustrées chez A List Apart [Anglais].

Qui parle d’évolution pour les années à venir ne peut mettre de côté l’avenir du web mobile, iPhone et autre pseudo gPhone vous donneront la possibilité de consulter vos mails et de surfer n’importe où et n’importe quand grâce à leur connexion permanente sur la toile via la 3G, Edge ou autre. Ces utilisations feront croître la part de marché des navigateurs mobiles et c’est dans ce sens que travaillent les équipes des acteurs du marché, Mozilla avec Fennec, Apple avec Safari, Microsoft avec Mobile Explorer, Opera avec Opera Mobile.

Mais l’innovation passe par l’évolution et sur ce point les différences entre les forces en présence sont nombreuses. Microsoft s’est longtemps assis sur son trône de leader du marché sans s’occuper de la concurrence. En 2001, une fois arrivé au sommet le géant américain a stoppé ses laboratoires de R&D pour Internet Explorer, c’est la fin de l’évolution pour quelques années. Pendant ce temps la fondation Mozilla constituée d’anciens de Netscape lance le projet Firefox pour relancer l’évolution du web. Sept années plus tard Mozilla continue de ronger les parts de marché de Microsoft qui s’est remis au travail avec la publication d’Internet Explorer 7 en 2006 et la sortie de la beta 1 d’Internet Explorer 8 en mars 2008. En parallèle de tout cela Opera et Safari continuent leur développement légèrement en retrait du marché mais en allant toujours dans le sens de l’innovation démontrant ainsi que l’évolution a repris son cours et que d’ici quelques années nous aurons tous un navigateur performant et ce, qu’importe sa marque et sa plateforme.

SimpleDB est en fait une base de données à distance permettant l’accès à ses données en temps réel. Attention toutefois, la solution n’est pas basée sur le modèle relationnel ce qui signifie qu’il ne sera pas possible d’effectuer des actions compliquées sur les éléments indexés. Le service est actuellement disponible en version béta limitée.

Quel est l’intérêt de cette offre ?

SimpleDB se présente ni plus ni moins comme une alternative aux bases de données actuelles.

Ce service n’est pas vraiment fait pour des bases de données très complexes mais plutôt pour celles riches en informations. Point important, cette « externalisation » permet aux développeurs de s’affranchir de toutes les problématiques liées à la maintenance, la gestion, la charge ou l’optimisation des données.

Selon les architectures, cela peut également être intéressant d’un point de vue économique. En effet, à l’instar des web services proposés par Amazon, n’est payé que ce qui est utilisé (14 centimes par heure de d’utilisation de machine, de 10 à 18 centimes par Go pour les 10 premiers To transférés).

Un positionnement stratégique

Amazon est comme tout le monde le sait le n°1 de la vente en ligne et dispose logiquement d’une infrastructure solide, efficace et surtout reconnue. Le moteur de recherche Alexa repose par notamment sur SimpleDB.

Cette légitimité permet donc de proposer des services principalement destinés aux PME recherchant une offre avantageuse et de grande qualité. Etoffant petit à petit ses services, Amazon se positionne maintenant clairement comme l’un des futurs grands acteurs des environnements et applications hébergées.

En effet, si l’on ne peut que saluer l’initiative (certes tardive) de rendre le navigateur de Microsoft enfin conforme aux standards web, le hic se situe dans son utilisation.

IE 8 intégrera les 3 moteurs de rendu : celui d’IE 6, d’IE 7 et le nouveau entièrement réécrit pour IE8. Jusque là tout va bien d’autant qu’il y a quelques semaines, l’annonce qu’IE8 passerait le test Acid 2 avait fait espérer bon nombre de personnes quant à l’évolution positive du navigateur.

L’ennui vient du fait que par défaut, ce nouveau moteur de rendu ne sera utilisé. Pour faire interpréter son site par le moteur d’IE8, il sera nécessaire de le spécifier via une balise meta dans le code HTML.

« Ne pas casser la rétro compatibilité ». Oui mais…

L’utilisation de cette meta serait justifiée par la volonté de ne pas « casser » l’optimisation des sites actuels, retro compatibilité oblige.

En effet, IE6 représente 35% des parts de marché des navigateurs et sa non conformité aux standards établis par le W3C oblige de nombreux sites à être optimisés spécifiquement.

L’argument parait tout de même étrange voir absurde car un navigateur comme Firefox arrive à faire ce travail d’interprétation correctement sur une très large majorité des sites, même ceux non optimisés pour lui. Pourquoi IE8 n’en serait-il alors pas capable ?

Par ailleurs, Microsoft demanderait aux autres navigateurs d’adopter cette méthode de « hack » afin de spécifier les moteurs pour lesquels le site serait optimisé (Firefox 2 et 3, IE8 …)

Cela va bien évidemment à l’encontre de la question première qui est de faire des sites respectant les standards, et non des sites s’adaptant aux différents navigateurs…

Ces différentes annonces de la part de la firme de Redmond témoignent néanmoins et malgré tout de la prise de conscience de l’importance des standards du web.

Dommage que cela paraisse si laborieux à être implémenté.

Pour aller plus loin :

• Compatibilité et IE8, le point par Tristant Nitot
• Le standards mode d’IE8 par Country