Catégorie « Standards du WEB »

De l'intérêt d'utiliser des standards

Lorsqu'il y a peu, Opera a annoncé sa migration sous Webkit, certains se sont réjouis à l'idée de voir réduire le nombre de moteurs de rendus et donc la diversité des navigateurs à supporter lorsqu'on développe un site.

D'autres ont rétorqué qu'une réduction de la diversité, si elle pouvait potentiellement faire gagner du temps à court terme, ne pouvait qu’être néfaste à long terme pour le web en général. En effet, le développement des standards et leur respect dans les différents navigateurs ne se fait que parce que plusieurs moteurs ont une part de marché significative. Pour preuve : à l'époque où Internet Explorer faisait 95% de part de marché, non seulement l'innovation se faisait uniquement en mode propriétaire à la seule initiative de Microsoft mais pire encore, elle a fini par s'assécher totalement après la sortie d'IE6. Seule l'arrivée de Firefox a fini par relancer la machine.

Actuellement, si Webkit est encore loin d'atteindre la part de marché passée d'IE sur les ordinateurs de bureaux, il est largement majoritaire sur les mobiles et tablettes, ce qui conduit de plus en plus de développeurs à ne développer leurs sites et applications web que dans l'optique de webkit, ignorant totalement les autres.

Faire ce choix de la facilité est à mon sens une grave erreur car si webkit est largement majoritaire actuellement, qu'en sera-t-il dans un ou deux ans ? Nul doute que l'écart se sera resserré si Firefox OS prend des parts de marché significative. Je doute assez peu que ce soit le cas, la seule inconnue restant la taille de cette part.

L'importance de respecter les standards est essentielle pour fonctionner sur un large panel de navigateur. Et fonctionner sur un large panel de navigateurs en respectant les standards (plutôt qu'en abusant de hacks en tous genre ou en développant des version parallèles) est non seulement plus maintenable mais aussi plus pérenne.

En effet, quand on se base sur les spécificités d'un navigateur, on est à la merci de son évolution. Car si les standards implémentés dans les différents navigateurs sont destinés à durer (un site qui fonctionnait bien sur les standards d'il y a dix ans fonctionne toujours actuellement), les éléments spécifiques, eux, peuvent disparaitre ou changer du jour au lendemain.

Nous en avons fait la douloureuse expérience avec RBS Change ces derniers mois. En effet, le backoffice est basé sur XUL, une technologie propriétaire de Mozilla, donc limitée au seul moteur Gecko (donc Firefox essentiellement). Depuis qu'elle a renoncé il y a quelques années à en faire un standard, Mozilla tend à réduire progressivement la portée de XUL. Initialement utilisables pour des applications web standard comme alternative plus riche à (X)HTML, XUL n'est actuellement plus utilisé que pour l'interface de Firefox. Pour continuer à l'utiliser dans le backoffice de Change, il nous faut passer par une extension.

Or la version 17 de Firefox a introduit un changement qui entrainait un plantage de Firefox dès l'ouverture du backoffice. Ce bug, critique pour les utilisateurs de Change était loin de l'être pour Mozilla puisque si un patch a été proposé en quelques jours par un contributeur externe, la validation du patch et son intégration dans Firefox a pris plusieurs mois. Et ce n'est que dans la future version 20, soit trois version plus tard qu'il sera enfin corrigé (alors qu'il avait été remonté le jour de la sortie de la 17).

Le choix de reposer sur XUL, s'il semblait bon en 2005 lorsqu'il a été fait (et l'était probablement étant donné ce qu'il permettait à une époque où les frameworks JavaScript étaient balbutiants et où les API standard étaient bien plus limitées) s'avère aujourd'hui avoir des conséquences coûteuses : redévelopper l'intégralité de l'interface ça a un coût assez élevé. Avec une technologie standard on n'aurait pas eu ce problème. Certains pans auraient dû être repensés de toutes façons mais cela aurait pu être bien plus progressif.

Je viens d'évoquer une techno 100% propriétaire comparable à Flash ou Silverlight par exemple dans le sens où, propulsée par un seul éditeur elle peut du jour au lendemain cesser d’être maintenu ou bannie de certaines plateformes. On est donc assez loin de ce qu'on risque de voir arriver avec le ciblage en "Webkit only", du moins dans un premier temps.

Mais les problèmes de ce choix de XUL a d'autres conséquences moins évidentes. En effet, choisir XUL c'est faire du développement dédié à Firefox uniquement. C'est donc se permettre d'utiliser des spécificité de Firefox à tous les niveaux, voire d'en exploiter sans s'en rendre compte ce qui s'avère être des bugs.

Nous en avons fait l'expérience une fois le bug évoqué plus haut puisque même si le navigateur ne plantait plus, le backoffice n'en était pas pour autant redevenu fonctionnel ! En effet à partir de Firefox 17, E4X (déprécié et désactivé dans la version 10) ne cause plus des erreurs seulement lorsqu'il est utilisé mais déjà des erreurs de parsing lorsqu'il est simplement présent dans un fichier. Or si on avait fait en sorte de ne plus passer dedans pour un usage normal, certaines fonctionnalités dépréciées de Change en contenaient encore... nous avions donc le choix entre tuée définitivement ces fonctionnalités ou assurer la compatibilité avec les version actuelles de Firefox. C'est le second choix qui a été fait mais d'une part ça implique qu'il faut mettre à jour Change pour pouvoir tourner sur les dernières versions de Firefox et d'autre part ça a impliquer de tuer des fonctionnalités (certes dépréciées depuis longtemps) dans une version corrective, ce qui n'est pas forcément très réjouissant.

De même, Firefox 20 modifie le comportement de la méthode setAttribute() sur un élément du DOM. Jusqu'à présent en affectant la valeur null, cela affectait au final un chaine vide et maintenant cela affecte la chaine "null". En soi c'est très bien puisque c'est conforme à ce que font tous les autres navigateurs mais ça a des conséquences sur le fonctionnement de l'interface. Si nous avions travaillé en contexte multi-navigateur, nous aurions remarqué cela très tôt. Là encore une fois, ça impose une mise à jour de Change pour rester compatible avec les derniers Firefox.

Et c'est bien cela qui pend aux nez de tous ces développeurs qui font du "Webkit only" : lorsqu'un bug sera corrigé, si leur applications reposent dessus (parfois sans qu'ils s'en doutent), il leur faudra faire des correctifs en urgence pour réparer voir coincera des entreprises sous des vieilles versions comme cela a pu et est encore le cas avec IE6. Et cela arrivera de plus en plus souvent si Webkit continue à progresser en part de marché.

Donc on ne le dira jamais assez : utilisez des standards (et de préférence matures, sans reposer sur des propriétés préfixées) et validez vos développement même mobiles sur plusieurs moteurs différents ! Ne reproduisez pas le désastre d'IE6.

Et en ce qui me concerne, sur ma tablette Android, par principe je ne lance jamais aucun navigateur sous Webkit (sauf tests justement). Jusqu'à présent j'utilisais Firefox et Opera. Maintenant je n'utiliserai plus que Firefox. C'est dommage mais c'est comme ça. Et si un site ne fonctionne que sous Webkit, tant pis pour lui.


Plugin Open search pour Wordpress - version 1.0.1

Je viens de mettre en ligne une nouvelle version de mon petit plugin Open search. Cette nouvelle version n'apporte rien fonctionnellement mais inclus le fichier readme.txt nécessaire à l'ajout sur le repository officiel, un fichier de traduction en anglais et une page de documentation en anglais ( enfin, en anglais de développeur qui se débrouille plus ou moins, hein... je suis preneur de toute suggestion de correction qui en ferait du "vrai" anglais ;:).

Prochaine étape, faire de même avec Post-lister une fois qu'il sera à peu près arrivé à maturité... D'ailleurs la version 0.2 ne devrait pas tarder, maintenant que je suis en vacances, j'ai un peu de temps :smile: Au passage s'il y a un volontaire pour la traduction de la doc, il est le bienvenu (pas forcément tout de suite, vu qu'elle va pas mal bouger avec la prochaine version) :p


Plugin Open search pour Wordpress

Après avoir un peu cherché et trouvé plusieurs plugins gérant Open search mais aucun ne faisait précisément ce que je voulais.

J'ai donc codé ma propre version qui me semble plus complète. Donc qu'est-ce qu'elle fait ?

  • elle intègre Open search à Wordpress (forcément, c'est un peu le but...).
  • elle recherche automatiquement l'icône de favoris, d'abord dans le répertoire du thème courant et ensuite à la racine et à défaut prend l'icône fournie avec le plugin. L'icône recherchée est supposée s'appeler favicon.jpg, favicon.png, favicon.ico ou favicon.gif. Ce qui gère à peu près tous les cas possibles. Y compris mon cas : plusieurs sites tournant avec la même instance de Wordpress.
  • le fichier XML Open search est généré à partir du template présent dans templates/open-search-xml.php. Au cas où vous voudriez le changer (c'est peu probable mais bon, à tout hasard...), ce fichier peut être surchargé en ajoutant dans votre thème un fichier open-search-xml.php. Donc pas besoin de modifier directement le plugin, ce qui facilite les mises à jour.
  • le plugin est localisé (à l'heure actuelle il n'y a qu'une chaine localisée mais bon). Cf le dossier languages du plugin.

Voilà voilà, l'essentiel est dit, manque plus que le lien pour le téléchargement : Plugin Open search 1.0.


Open search

Open Search est une série de formats destinés à partager des recherches. En particulier, et c'est le point dont je vais parler ici, c'est via ce format que sont définis les moteurs de recherche gérés par la barre de recherche de Firefox 2 (et également celle d'IE 7 apparemment).

On peut donc assez facilement ajouter un moteur de recherche à la liste via un simple fichier XML, du moment qu'on a l'URL et les paramètres à passer à la page de recherche.

Format du fichier xml

<?xml version="1.0" encoding="{ENCODAGE}" ?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/" xmlns:moz="http://www.mozilla.org/2006/browser/search/">
	<ShortName>{NOM}</ShortName>
	<Description>{DESCRIPTION}</Description>
	<InputEncoding>{ENCODAGE}</InputEncoding>
	<Image width="16" height="16">{ICÔNE}</Image>
	<Url type="text/html" method="{MÉTHODE}" template="{URL_RÉSULTAT}"></Url>
</OpenSearchDescription>
  • {NOM} : nom du moteur de recherche. C'est ce nom qui sera affiché dans la liste de sélection du navigateur, veillez donc à ce qu'ils reste aussi concis que possible.
  • {DESCRIPTION} : description du moteur.
  • {ENCODAGE} : encodage du moteur et de votre fichier XML.
  • {ICÔNE} : icône de 16x16 pixels associée à votre moteur. Cette icône doit être encodée en base 64, par exemple via ce formulaire.
  • {MÉTHODE} : méthode de passage de paramètre : POST ou GET.
  • {URL_RÉSULTAT} : URL où soumettre la recherche.

D'autres paramètres optionnels existent, je n'ai détaillé là que les parties nécessaires.

Et ensuite ?

Une fois le fichier réalisé, il peut être ajouté dans votre répertoire de Firefox, dans le dossier searchplugins (nécessite de redémarrer Firefox).

Il est également possible s'il s'agit du moteur de recherche de votre site, de faire en sorte que Firefox le détecte automatiquement (de la même manière que pour un flux RSS) en ajoutant la balise link appropriée dans la section head de la page :

<link rel="search" type="application/opensearchdescription+xml" title="{NOM}" href="{URL_DU_FICHIER_XML}">

{NOM} correspond au nom indiqué dans le fichier XML et où, vous l'aurez compris, {URL_DU_FICHIER_XML} est à remplacer par l'URL où vous aurez placé le dit fichier...

Ressources complémentaires