Aug 24 2009
Facebook s’est, semble-t-il, fourvoyé avec l’inclusion de Facebook Connect sur des sites tiers. Facebook Connect la solution de SSO (Single Sign On, centralisation d’authentification) fournie par le géant Facebook. Vous connectez votre compte Facebook avec la communauté d’un site, d’un blog et pouvez commenter les billets et interagir avec les autres membres.
On se réfèrera au Facebook developer wiki pour implémenter cette fonctionnalité. Cependant, le code généré et proposé sur le Facebook developer wiki ne passe pas la validation W3C et ce, avec n’importe quel doctype XHTML, le problème semble encore assez problématique avec le draft HTML5. En cause, l’appel à de multiples espaces de nom :
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:fb="http://www.facebook.com/2008/fbml">
Théoriquement, le tag <html> fait appel à 2 espaces de nommage (xmlns et xmlns:fb) et XHTML est sensé l’autoriser (au moins dans sa version 1.1). Mais que nenni, cette implémentation n’est que sur le papier… dommage !
Je n’ai visiblement pas été le seul à constater cet état de fait et après une petite discussion sur Twitter (merci à Jérémie Patonnier pour ses avis pertinents), il s’avère que l’insertion de Facebook Connect
à un site, fait perdre la validation W3C sans que l’on y puisse grand
chose. La seule solution que j’ai pu entrevoir, est de redéfinir la DTD
du doctype comme mentionné dans cet article d’A List Apart : Validating a custom DTD.
Cependant, cette technique ne sera pas intégralement reconnue par le
validateur du W3C car s’appuyant sur un doctype non homologué… le
serpent se mord la queue !
Même après de vaines recherches, le forum de Facebook developer reste désespérément sans réponse pour cette problématique.
C’est tout de même étrange que l’un des sites au plus fort trafic mondial (le 3ème selon Alexia, 2ème en France) oblige à faire une telle gymnastique pour avoir un code propre mais non valide.
Facebook semble plus se soucier de ce qui fonctionne plutôt que de ce qui est valide. J’en arrive à une réflexion : doit-on se soucier de la validité du code de nos applications ? Je dis “oui !”. Cette affaire n’est pas sans rappeler quelques tentatives de flibustiers pour faire passer leurs propres implémentations de fonctionnalités navigateurs pour des standards de fait… suivez mon regard.
Chez groupeReflect, nous nous appuyons sur les standards et les bonnes pratiques afin de délivrer un produit de qualité, avec une forte accessibilité, utilisable sur une grande majorité de navigateurs et surtout, dont le code sera pérenne même si les navigateurs évoluent : c’est notre engagement !
Malheureusement, avec Facebook Connect, nous nous heurtons à un obstacle qui nous oblige à revoir la qualité de nos livrables sans pouvoir maudire sans pouvoir mots dire.
Avez-vous déjà rencontrer ce problème ? Pensez-vous que la gestion des standards ne sera plus l’apanage des fabricants de navigateurs mais également celui des sites à fort trafic qui pourrons tenter de faire avancer les choses plus rapidement ou d’imposer leur vision des standards ?
Je suis très souvent amené à rencontrer des brand managers, directeurs marketing, communication, directeurs généraux et présidents chez les annonceurs. Si tous sont très majoritairement convaincus que le web et le digital en général constituent l’avenir en matière de communication de marque et de pub, certains doutent encore et cèdent parfois à la facilité d’une publicité sur la bonne vieille TV. Argument avancé : “Je sais Manuel que tu as raison, mais j’ai pas le temps, faudrait que je me plonge dans le sujet, je vais plutôt faire une campagne TV et engageons une opé sur le web en relais de tout cela. Aller la prochaine fois on bascule tout sur le web, promis”.
