99,9% des sites web sont obsolètes

Par Jeffrey Zeldman

Extrait deDesigning With Web Standards par Jeffrey Zeldman. Traduit et reproduit avec la permission de l'éditeur, New Riders.

En ce moment une maladie affecte sans discrimination presque tous les sites sur le web, de la plus humble des pages perso jusqu'aux sites d'entreprises à plusieurs millions de dollars. Fourbe et insidieuse, cette maladie passe largement inaperçue parce qu'elle est basée sur les normes mêmes de l'industrie. Leurs propriétaires et leurs administrateurs ne le savent peut-être pas encore, mais 99,9% des sites web sont obsolètes.

Ces sites s'affichent et fonctionnent sans doute correctement dans les navigateurs dominants dont les noms finissent par 4 ou 5. Mais en dehors de ces environnements tolérants, les syndromes de la maladie et du pourrissement ont déjà commencé à apparaître.

Dans les dernières versions de Microsoft Explorer, Netscape Navigator, et Mozilla (le navigateur Open Source basé sur Gecko, dont le code est utilisé pour Netscape Navigator, CompuServe, et d'autres systèmes de navigation), des mises en pages soigneusement construites ont commencé à s'écrouler et des comportements à l'élaboration coûteuse ont cessé de fonctionner. Avec l'évolution de ces navigateurs dominants, la performance générale des sites continue à se détériorer.

Sur des navigateurs alternatifs, sur des lecteurs vocaux utilisés par des handicapés, et sur des appareils non traditionnels à la popularité croissante (des Palm Pilots™ aux téléphones portables à accès web), beaucoup de ces sites n'ont jamais fonctionné et ne fontionnent toujours pas, et d'autres le font partiellement dans le meilleur des cas. En raison de leurs besoins ou de leurs budgets, les propriétaires et les développeurs de sites ont ignoré ces navigateurs et appareils alternatifs, ou les ont pris en compte en détectant leur présence et en leur fournissant du balisage et du code personnalisé - une pratique que l'industrie appelle le « versioning ».

Les versions alternatives offrent aux utilisateurs de navigateurs aussi sophistiqués qu'Opera une expérience amoindrie par rapport à Explorer et Netscape . Les versions pour appareils sans fil (NdT : comme le WAP) sont encore pires. Beaucoup d'entre elles reposent sur des balisages peu répandus et déjà obsolètes.

Ces pratiques gaspillent du temps et de l'argent. Aucune de ces deux ressources n'a jamais été abondante. Les deux sont très limitées depuis que l'économie occidentale est en récession. Pire encore, ces pratiques coûteuses ont failli à résoudre le problème. Certains sites sont toujours en mauvais état. Des utilisateurs en sont toujours exclus.

Un raisonnement rétrograde

Grattez sous la surface de n'importe quel site majeur, d'Amazon à Microsoft.com, de Sony à ZDNet. Examinez leurs balisages tortueux et non-standards, leurs JavaScript et ActiveX propriétaires, et leur mauvaise utilisation des Feuilles de Style en Cascade -quand ils utilisent des CSS tout court. C'est un miracle que de tels sites fonctionnent dans n'importe quel navigateur.

Ils fonctionnent dans les navigateurs dominants d'hier, parce que les cinq premières générations de Netscape Navigator et de Microsoft Explorer ne se contentaient pas de tolérer le balisage non-standard ou le code spécifique à tel ou tel navigateur : ils encourageaient carrément la création bâclée et le codage propriétaire dans une guerre maladroite pour la conquête de l'espace de navigation.

Souvent, les sites non conformes aux standards fonctionnent dans les navigateurs d'hier parce que leurs propriétaires ont investi dans des outils de publication coûteux, qui s'adaptent aux différences entre navigateurs en générant de multiples versions non-standards réglées en fonction de particularités de navigateurs et de plates-formes spécifiques. Cette pratique abuse de la patience des utilisateurs équipés de modems en gaspillant de la bande passante avec des bifurcations de code, des tableaux profondément imbriqués, des pixels séparateurs et autres astuces d'image, et des balises et attributs dépassés ou invalides.

En même temps, ces versions multiples gaspillent la bande passante du propriétaire du site à un coût que même les chefs comptables les plus pingres seraient en mal de calculer. Plus le site est grand, plus son trafic est important, plus grande est la quantité d'argent gaspillée en connexions serveur, en redondances, en astuces d'image, en code et en balisage inutilement complexes.

L'interface de Yahoo!
Ce à quoi ressemble Yahoo - aussi dépouillé qu'un manteau Amish

Le balisage de Yahoo!
Ce qui donne son apparence à Yahoo - un code convoluté.

La page d'accueil de Yahoo est affichée des millions de fois par jour. Chaque octet gaspillé en astuces de design en HTML dépassé est multiplié par un nombre astronomique de pages vues, résultant en Gigaoctets de trafic qui pèsent sur les serveurs de Yahoo et rajoutent à ses frais généraux des coûts de l'ordre du PIB d'un petit pays d'Afrique.

Si Yahoo voulait simplement remplacer ses balises <font> désapprouvées et mangeuses de bande passante par des CSS, le coût de revient de chaque page affichée en serait énormément réduit, et les profits de l'entreprise augmenteraient en conséquence. Alors pourquoi Yahoo n'a t-il pas sauté le pas?

Nous pouvons seulement en conclure que l'entreprise souhaite que son site ait le même aspect dans les navigateurs de 1995 ne reconnaissant pas les CSS que dans les navigateurs modernes. L'ironie, c'est que tout le mode à part la direction de Yahoo se fiche de l'apparence de Yahoo. Le succès formidable du site est dû au service qu'il propose, pas à la beauté de son design graphique (qui est inexistant).

Que cette entreprise, par ailleurs brillante, gaspille une bande passante incalculable pour un résultat graphique que personne n'admire, en dit long sur la mentalité cloisonnée de développeurs qui tiennent en plus haute estime la « compatibilité descendante » que la raison, l'ergonomie, ou leurs propres profits.

Que veulent dire les développeurs par « compatibilité descendante »? Il s'agit d'utiliser du code non-standard, propriétaire (ou désapprouvé) pour s'assurer que chaque visiteur fasse la même expérience, qu'il arbore Netscape Navigator 1.0 ou IE6. Tenu comme le Saint Graal de la pratique professionnelle, la compatibilité descendante sonne bien en théorie. Mais son coût est trop élevé, et la méthode a toujours été fondée sur un mensonge.

Il n'existe pas de vraie compatibilité descendante. Il y a toujours un point de rupture. Par exemple, ni Mosaic (le premier navigateur visuel) ni Netscape 1.0 ne reconnaissent les mises en page à base de tableaux HTML. Du coup, par définition, ceux qui utilisent ces navigateurs antiques ne peuvent sûrement pas vivre la même expérience que ceux qui visionnent le Web à travers des navigateurs apparus plus tard, comme Netscape 1.1 ou IE2.

Les développeurs et les clients qui luttent pour la compatibilité descendante choisissent inévitablement un « navigateur de base » (disons Netscape 3) au-delà duquel ils ne feront aucun effort. Pour reconnaître ce navigateur de base et ceux qui le suivent, les développeurs garnissent leur balisage d'une série de contournements non-standards destinés à des navigateurs spécifiques, qui ajoutent du poids à chaque page. En même temps, ils écrivent de multiples scripts pour accommoder les navigateurs qu'ils ont choisi de reconnaître, et utilisent une détection de navigateurs pour fournir à chacun le code qu'il préfère. Ce faisant, ces développeurs augmentent encore plus la corpulence de leur pages, ajoutent au fardeau de leurs serveurs, et garantissent que la course contre l'obsolescence perpétuelle continuera jusqu'à ce qu'ils n'aient plus d'argent ou d'emploi.

Alors que certaines entreprises minent leur propre rentabilité en essayant de faire que même les plus vieux navigateurs voient leurs sites exactement comme les nouveaux, d'autres ont décidé qu'un seul navigateur importait. Dans un effort peu judicieux pour réduire leurs dépenses, un nombre croissant de sites sont conçus pour fonctionner seulement dans Internet Explorer, et parfois même seulement sous Windows, excluant ainsi 15 à 25% de leurs visiteurs et clients potentiels.

Nous ne prétendons pas comprendre le modèle économique d'une entreprise qui dirait non à un quart de ses clients potentiels. Et le simple nombre de clients perdus par cette approche de myope devrait ahurir n'importe quel chef d'entreprise rationnel. Selon des statistiques compilées par les Sondages Internet NUA (http://www.nua.ie/surveys/), plus de 540 millions de personnes utilisaient le Web en Février 2002. Faites le calcul.

Admettons que vous n'ayez pas peur de perdre 25% des gens qui choisissent de visiter votre site. L'approche « IE seulement » n'a toujours aucun sens, puisqu'il n'y a aucune garantie que IE (ou même les navigateurs de bureau en tant que catégorie) va continuer à dominer l'espace web.

Quelques années avant l'écriture de ce livre, Netscape Navigator régnait sur un marché encore plus grand que celui d'Internet Explorer aujourd'hui. A l'époque, la sagesse dictait que Netscape était le seul navigateur important, et les développeurs codaient en conséquence. Quelques millions de dollars plus tard, le marché a changé. Les sites optimisés pour Netscape ont atterri dans la décharge en bordure de l'Autoroute de L'Information.

Le même destin attendrait-il les sites pour IE seulement ? Aussi inconcevable que cela paraisse, il n'y a aucun moyen de le dire. Sur le Web, la seule constante est le changement. Ajoutez à cela l'utilisation toujours plus répandue de dispositifs Internet non-traditionnels, et la conception pour les caprices d'un navigateur particulier commence à ressembler à une décision économique stupide -ce qu'elle est effectivement.

De plus, comme le montrera ce livre, les standards rendent possible de concevoir aussi facilement et rapidement pour tous les navigateurs et appareils que pour un seul. Entre les coûts exponentiels du versioning pour la compatibilité descendante et la futile myopie d'une construction pour un seul navigateur, les standards web proposent la seule approche de développement un peu sensée.

Ni les coûteuses techniques de versioning, ni la décision délibérée de ne reconnaître qu'un seul navigateur ou plate-forme n'aideront les sites d'aujourd'hui à fonctionner dans les navigateurs de demain, ou à prospérer dans le monde en mouvement des nouveaux systèmes de navigation. Si ces pratiques continuent, l'escalade des coûts et de la complexité se poursuivra jusqu'à ce que seules les plus grandes entreprises puissent se payer des sites web.

Microsoft a gagné la Guerre des Navigateurs mais nous avons tous temporairement perdu quelque chose de plus important : l'occasion de créer un Web ergonomique, accessible, construit sur des standards industriels communs. Nous l'avons perdu quand les concepteurs et les développeurs, se bousculant pour répondre à la demande de production pendant la brève explosion de l'Internet, ont appris des méthodes de création non-standards et spécifiques à certains navigateurs, nous conduisant ainsi à la situation actuelle, dont le nom est obsolescence.

Mais la période obsolescente du développement web se meurt alors que vous lisez ces mots, emportant avec elle d'innombrables sites. Si vous possédez, gérez, concevez ou montez des sites web, le glas sonne pour vous.

La maladie

Très tôt dans l'éducation d'un programmeur informatique, on lui apprend la phrase « Garbage In, Garbage Out. » En clair, dans le monde de la programmation, si vous écrivez votre code correctement, il marche. Si vous ne l'écrivez pas correctement, il plante. Des langages comme le C++ ou Java n'encouragent pas simplement une bonne méthode de codage, ils l'exigent.

De même, une des premières choses qu'apprend un graphiste est que la qualité du matériau d'origine détermine l'efficacité du produit final. Commencez avec une photo de haute qualité en haute définition, et la sortie imprimée ou l'image web sera bonne. Essayez de travailler à partir d'un cliché de mauvaise qualité ou d'une image web basse définition, et le résultat final ne vaudra même pas la peine d'être vu. Vous pouvez transformer un EPS de haute qualité en un logo web convenablement optimisé, mais vous ne pouvez pas convertir un GIF basse définition en un logo web, papier, ou TV de haute qualité. « Garbage In, Garbage Out ».

Mais les navigateurs dominants traditionnels ne fonctionnent pas de la même manière. Laxistes jusqu'à l'absurdité, ils engouffrent sans un hoquet le balisage incohérent et les mauvais liens de fichiers JavaScript, affichant le plus souvent le site comme s'il avait été créé correctement. Ce laxisme a encouragé les concepteurs et les développeurs front-end à développer des habitudes dont ils sont largement inconscients. En même temps, cela a persuadé les développeurs back-end et de programmes intermédiaires de considérer des technologies comme le XHTML, les CSS et le JavaScript comme indignement primitives.

Qui ne respecte pas son outil ne risque pas de l'utiliser correctement. Considérons l'extrait suivant, piqué sur le coûteux site e-commerce d'une entreprise concourant dans un marché difficile, et reproduit ici dans toute sa gloire bouffie :

<td width="100%"><font face="verdana,helvetica,arial"
size="+1" color="#CCCC66"><span class="header"><b>Rejoignez-nous !
</b></span></font></td>

L'absurde balise « ont » est une coquille de la balise désapprouvée font - une coquille répétée des milliers de fois dans tout le site, grâce à un outil de publication hautement efficace. Cette erreur mise à part, ce balisage peut vous sembler familier. Il ressemble peut-être même au balisage de votre propre site. Dans le contexte de cette page web, tout ce qui serait en fait nécessaire s'écrit comme suit :

<h2>Rejoignez-nous !</h2>

Associé à une règle appropriée dans une feuille de styles liée, le balisage plus simple et plus structurel ci-dessus fait exactement ce que faisait le balisage lourd, non-standard et invalide, tout en économisant les bandes passantes du serveur et du visiteur, et en facilitant la transition vers un site plus flexible basé sur du XML. Le même site de e-commerce inclut le lien JavaScript brisé suivant :

<script language=JavaScript1.1src="http://foo.com/Params.
richmedia=yes&etc"></script>

Entre autres problèmes, l'attribut language non fermé par des guillemets est collé à l'attribut src. Autrement dit, le navigateur est censé utiliser un langage de script inexistant ("JavaScript1.1src"). Selon toute logique, le site devrait planter, alertant les développeurs de leur erreur et leur intimant de la réparer illico. Pourtant jusqu'à récemment, le JavaScript sur ce site marchait dans les navigateurs dominants, perpétuant ainsi le cycle des sites mal créés et des navigateurs qui les aiment. Pas étonnant que les codeurs experts voient souvent le développement front-end comme une sorte de vaudou stupide, indigne de respect ou d'attention.

Mais alors que les nouveaux navigateurs se conforment aux standards web, ils deviennent de plus en plus rigoureux dans ce qu'ils attendent des concepteurs et des développeurs, et donc de moins en moins tolérants envers le code et le balisage incohérents. La règle du « Garbage In, Garbage Out » commence à prendre pied dans le monde des navigateurs, rendant nécessaire la connaissance des standards web pour quiconque conçoit ou produit des sites.

Les dégâts ne sont pas irréparables. Nous pouvons concevoir et monter des sites d'une meilleure manière, qui fonctionne dans nombre de navigateurs, de plates-formes et d'appareils, résolvant les problèmes d'obsolescence intégrée et d'exclusion d'utilisateurs, tout en pavant la voie à un Web bien plus puissant, plus accessible, et développé plus rationnellement.

Le remède au mal de l'obsolescence intégrée peut se trouver dans un noyau de technologies communément reconnues, collectivement appelées « standards web ». En apprenant à concevoir et à construire avec les standards web, nous pouvons garantir la compatibilité montante de tous les sites que nous produisons.

« Écrivez une fois, publiez partout », la promesse des standards web, est plus qu'un vœu pieux : elle s'accomplit aujourd'hui, avec les méthodes que nous explorerons dans ce livre. Mais alors que les principaux navigateurs actuels reconnaissent enfin ces standards et ces méthodes, le message n'a pas encore atteint de nombreux concepteurs et développeurs en activité, et de nouveaux sites sont toujours construits sur les sables mouvants du balisage et du code non-standards. Ce livre espère changer cet état de fait.

Le remède

Après une longue lutte opposant concepteurs et développeurs aux fabricants des principaux navigateurs, nous pouvons finalement employer des techniques qui garantissent l'apparence et le comportement de nos sites, non seulement dans le navigateur d'un seul constructeur, mais dans tous.

Martelées par les membres du World Wide Web Consortium (W3C) et autres organismes représentant les standards, reconnues par les navigateurs actuels développés par Netscape, Microsoft, et d'autres, des technologies comme les Feuilles de Style en Cascade (CSS), le XHTML, l'ECMAScript (la version standard du JavaScript) et le W3C DOM permettent aux concepteurs de :

Avant de pouvoir apprendre comment les standards accomplissent ces objectifs, nous devons examiner les anciennes méthodes qu'ils doivent remplacer, et découvrir comment exactement les vieilles techniques perpétuent le cycle de l'obsolescence. Le chapitre 2 vous révèlera tout.

Fiche technique

À propos de l'auteur

Jeffrey Zeldman est le directeur créatif ainsi que le rédacteur en chef du site A List Apart.
Son dernier livre, Designing With Web Standards, s’impose déjà comme une référence en matière de web design.

Articles du même auteur

Articles similaires

Voici la liste des dix articles les plus récents en rapport avec cet article :

Tous niveaux

Web design

© 2001-2014 Pompage Magazine et les auteurs originaux - Hébergé chez Nursit.com ! - RSS / ATOM - About this site