Vacances et compatibilité

Non bien sûr, à mon retour de vacances, ce n'est pas de compatibilité d'humeur avec les amis que j'y ai rencontrés dont je compte vous entretenir …

Mais de ce fameux problème de la compatibilité des navigateurs …

Qui existe depuis toujours, et se apparaît à longueur d'années.

Cependant, une récente expérience vécue par une connaissance, ainsi que le momentum des voyages à l'étranger, sont deux bonnes raisons de m'intéresser à cette question.

Le problème rencontré était le suivant : étant en vacances à l'étranger, dans un hôtel, cette personne s'est connectée via un PC de l'hôtel, sur le site web d'un aéroport belge (dont je ne citerai pas le nom par discrétion !), afin d'y vérifier l'horaire de son vol de retour. Réflexe normal pour tout qui a l'habitude de surfer sur le web ! Hélas, aucune donnée ne s'affichait dans le tableau des horaires. D'où un sacré manque d'efficacité du site.

Vérification faite, les données en question sont publiées en Javascript, et ce dernier était désactivé sur le poste client dans l'hôtel.

Ce cas illustre parfaitement un problème couramment rencontré lors des phases de développement de sites web, ou lors des tests de compatibilité de ceux-ci sur les navigateurs. Avec des réponses classiques des développeurs : « pourquoi s'inquiéter de l'affichage en javascript, alors que 95% des navigateurs acceptent cette technologie ? » (source : http://www.w3schools.com/browsers/browsers_stats.asp ; janvier 2008).

De fait ! mais n'est-ce pas ignorer que les personnes surfant sans javascript n'en ont souvent pas conscience, et ne peuvent changer la configuration elles-mêmes (choix de l'administrateur système dans un réseau d'entreprise, ou session de surf au départ d'un ordinateur tiers hôtel, aéroport, cybercafé, …- bloquant javascript) ? Notons aussi que la plupart des périphériques mobiles, en utilisation croissante, ne supportent pas Javascript.

Certes, il existe de nombreuses bonnes raisons de ne pas activer javascript sur un ordinateur, ou de l'activer. A chacun sa philosophie, mais les faits sont là !

Faut-il pour cela proscrire à jamais l'utilisation de javascript ? Non bien évidemment !

Il faut simplement le réserver à des applications ou données non critiques, et le proscrire lorsque les données sont l'élément central et critique (tels les horaires sur le site web d'un aéroport !).

Comment contourner le problème ? Dans le cas qui nous occupe, les données sont récupérées et traitées par javascript, via une requête à un serveur. La solution élégante la plus simple et la plus universelle au demeurant- aurait consisté à calculer les données côté serveur et les intégrer dans un fichier HTML envoyé à l'utilisateur. Javascript peut alors éventuellement ajouter une présentation dynamique de ces données (panneaux refermables, glissières, drag and drop, …) à l'aide de feuilles de style (CSS) pour l'aspect visuel. Si Javascript est désactivé, les données restent accessibles, et seule leur manipulation dynamique est impossible.

En conclusion, il est évident que l'usage du Javascript peut être intéressant et recommandable ; mais ce choix est insensé pour afficher des données clés, surtout sur le site web d'un aéroport consulté au départ d'ordinateurs « exotiques » ou « cadenassés ».

N'oubliez donc pas d'ajouter ce test, le cas échéant, lors de la phase de réception d'un site web, ou mieux encore, d'inscrire cette contrainte dans le cahier des charges …