Adaptive web design - Aaron Gustafson.pdf

Propriété de david damour <[email protected]>customer 272758 at 2014-04-04 14:08:47 +0200272758

Créer des sites richesavec l’amélioration progressive

ADAPTIVEWEB DESIGN

Aaron GustafsonPréface de Jeffrey Zeldman

Le Web est en perpétuelle mutation : ses supports et ses usages, sa portée et ses

applications ne cessent de changer et d'évoluer. Si vous travaillez dans le Web, vous

avez certainement entendu parler l’amélioration progressive (progressive

enhancement). Mais que recouvre réellement cette notion ? Comment la rendre

opérante dans son travail de développement quotidien et dans le design de ses sites ?

Dans ce guide, Aaron Gustafson fait la genèse de l’amélioration progressive, explique

ses origines, sa philosophie, son fonctionnement et propose de nombreuses

techniques de mise en œuvre pour les langages HTML, CSS et JavaScript. Grâce à

l’amélioration progressive, vous remettrez les contenus au cœur de vos

développements, de façon à proposer des expériences qui servent les utilisateurs

plutôt que les navigateurs. Vous donnerez accès à vos contenus sans limite

technologique, pour les supports d’hier, d’aujourd’hui et de demain.

Adaptive Web Design constitue non seulement l’explication la plus claire et la plus

élégante de l’amélioration progressive que j’aie jamais lue, mais en plus, ce livre est

bourré de savoir-faire pratiques qui viennent s'installer directement dans votre

néocortex, grâce au style chaleureux et amical d'Aaron.

— Jeremy Keith, auteur de HTML5 pour les web designers

Enfin. L’amélioration progressive expliquée avec un parfait équilibre entre théorie et

pratique.

— Dan Cederholm, auteur de CSS3 pour les web designers

Aaron Gustafson a plus de 15 ans d’expérience dans le Web et a développé une connaissance profonde des standards du web, de l’architecture des sites, des stratégies de contenu et du design d’interface. Il dirige le Web Standards Projects (WaSP), est expert technique pourA List Apart, et contribue régulièrement à .Net Magazine.


ADAPTIVE WEB DESIGNCréer des sites riches avec l'amélioration progressive

Aaron Gustafson

Traduit par Olivier Engler

ADAPWEB.indb 1 17/04/13 12:47


Pearson France a apporté le plus grand soin à la réalisation de ce livre afin de vous

fournir une information complète et fiable. Cependant, Pearson France n’assume

de responsabilités, ni pour son utilisation, ni pour les contrefaçons de brevets ou

atteintes aux droits de tierces personnes qui pourraient résulter de cette utilisation.

Les exemples ou les programmes présents dans cet ouvrage sont fournis pour

illustrer les descriptions théoriques. Ils ne sont en aucun cas destinés à une utili-

sation commerciale ou professionnelle.

Pearson France ne pourra en aucun cas être tenu pour responsable des préjudices

ou dommages de quelque nature que ce soit pouvant résulter de l’utilisation de ces

exemples ou programmes.

Tous les noms de produits ou marques cités dans ce livre sont des marques déposées

par leurs propriétaires respectifs.

Publié par Pearson France

Immeuble Terra Nova II

74, rue de Lagny

93100 Montreuil

Tél : +33 (0)1 43 62 31 00

www.pearson.fr

Traduit par Olivier Engler

© 2013 Pearson France

Tous droits réservés

Titre original : Adaptive Web Design:

Crafting Rich Experiences with

Progressive Enhancement, by Aaron

Gustafson

Authorized translation from the

English language edition, entitled Adaptive

Web Design: Crafting Rich Experiences

with Progressive Enhancement by Aaron

Gustafson (ISBN 978-0-9835895-0-1),

published by Easy Readers. Copyright

© 2011 Aaron Gustafson. All rights reserved.

No part of this book may be reproduced

or transmitted in any form or by any

means, electronic or mechanical, including

photocopying, recording or by any infor-

mation storage retrieval system, without

permission from Pearson France.

Copyright Pearson France.

ISBN original : 978-0-9835895-0-1

© 2011 Aaron Gustafson.

All Rights reserved.

Aucune représentation ou reproduction, même partielle, autre que celles prévues à l’article L. 122-5 2̊

et 3̊ a) du code de la propriété intellectuelle ne peut être faite sans l’autorisation expresse de Pearson

France ou, le cas échéant, sans le respect des modalités prévues à l’article L. 122-10 dudit code.

No part of this book may be reproduced or transmitted in any form or by any means, electronic or

mechanical, including photocopying, recording or by any information storage retrieval system, without

permission from Pearson France. FRENCH Language edition published by Pearson France.

ADAPWEB.indb 2 17/04/13 12:47

ISBN : 978-2-7440-5600-0


Pour Kelly

ADAPWEB.indb 3 17/04/13 12:47


iv AdApTivE WEb dEsign

REMERCiEMEnTs

Sans les conseils et le soutien de tous mes amis et collègues de mon secteur

d 'activité, ce livre n'aurait jamais été écrit et je n'aurais jamais pu me placer

dans une position me permettant d'en envisager l'écriture. Je veux donc

prendre quelques instants pour leur exprimer ma sincère gratitude :

Pour Molly Holzschlag et Jeffrey Zeldman qui m'ont pris sous leurs ailes et

m'ont permis de renforcer mes compétences en tant que conférencier et auteur.

Et aux nombreux organisateurs de conférences et directeurs de publications

qui m'ont donné l'occasion de mettre ces compétences en pratique.

Pour Carolyn Wood qui m'a aidé à peaufiner mes premiers brouillons et

pour Krista Stevens qui a épuré mes arguments, fluidifié ma prose et calmé

le monsieur je-sais-tout au fond de moi.

Pour Craig Cook et Derek Featherstone qui ont poussé à ce que mon code

reste efficace et lisible. Merci aussi à tous les relecteurs qui m'ont donné de

précieux conseils (et des corrections) : Dan Cederholm, Simon Collison,

Kristina Halvorson, Christian Heilmann, Whitney Hess, Jeremy Keith, Dan

Rubin et Jonathan Snook.

Merci à l'équipe Easy Designs pour son souci des détails et son aide précieuse

dans la production de ce livre : Jessica Martin, Daniel Ryan, Jessi Taylor,

Matthew Turnure et Laura Helen Winn.

Pour Veerle Pieters qui a trouvé du temps dans son agenda chargé afin de

créer pour moi cette couverture absolument superbe.

Et enfin, merci à Kelly qui m'a dégagé du temps pour écrire ce livre, qui m'a

aidé à organiser mes idées et qui m'a encouragé à aller jusqu'au bout.

ADAPWEB.indb 4 17/04/13 12:47


TAbLE dEs MATiÈREs NP

REMERCiEMEnTs v

TAbLE dEs MATiÈREsvi AvAnT-pROpOs

1 CHApiTRE 1pEnsEZ À L'UTiLisATEUR, pAs AU nAvigATEUR

15 CHApiTRE 2AMÉLiORATiOn pROgREssivE AvEC LE HTML

39 CHApiTRE 3AMÉLiORATiOn pROgREssivE AvEC LE Css

67 CHApiTRE 4AMÉLiORATiOn pROgREssivE AvEC JAvAsCRipT

91 CHApiTRE 5AMÉLiORATiOn pROgREssivE ET ACCEssibiLiTÉ

109 CHApiTRE 6À EMpORTERindEX

ADAPWEB.indb 5 17/04/13 12:47


vi AdApTivE WEb dEsign

AvAnT-pROpOs

Par un glorieux après-midi de mars 2006, je passai en trombe avec un ami

devant l'hôtel Hilton du centre d 'Austin pour rejoindre la prochaine confé-

rence du festival SXSW Interactive quand un jeune inconnu nous arrêta

net dans notre course. Sans même se présenter, il nous annonça qu'il était

disponible pour prendre la parole lors de la conférence An Event Apart, un

événement destiné aux web designers que j'avais initié trois mois plus tôt avec

Eric Meyer. Je me suis alors tourné vers mon ami, prenant l'air faussement

enjoué de Mister Burns des Simpsons (ce qui n'est pas bon signe) et lui ai

demandé : "Qui est ce jeune arriviste impétueux, Smithers ?"

Le jeune arriviste impétueux est très vite devenu un de mes collègues les

plus intimes. Au fil des mois et des ans, Aaron Gustafson a produit du

code client et serveur pour quelques-uns des clients les plus exigeants de

ma société. Tout aussi important, il a brillamment assuré le rôle d'éditeur

technique de la troisième édition de Designing With Web Standards. Son

travail consistait surtout à informer Ethan Marcotte et moi-même des choses

que nous ignorions à propos des standards du Web. Imaginez ce que cela

représente. Depuis cinq ans maintenant, Aaron est un éditeur rigoureux

mais impartial pour la revue A List Apart ; il aide les auteurs à atteindre

leurs objectifs tout en s'assurant qu'ils restent toujours innovants, que leurs

méthodes sont accessibles et sémantiques et (grâce à ses connaissances

presque encyclopédiques) qu'ils créditent bien leurs prédécesseurs. Aaron

a aussi rédigé des articles fondamentaux pour la revue. Enfin, oui, il a pris

la parole à la conférence An Event Apart.

Vu mon expérience de l'homme et mon admiration pour son savoir et ses

compétences, j'ai été enthousiasmé lorsqu'Aaron m'a parlé de ce projet de

livre et m'a laissé en lire quelques chapitres. Ce n'est pas un livre de plus sur

le web design. C'est une pièce qui manquait à la littérature fondamentale

sur le sujet. Notre secteur d 'activité a longtemps manqué d'un guide des

meilleures pratiques de design web adaptatif et conforme aux standards. Avec

la déferlante des terminaux mobiles, les récentes améliorations des naviga-

teurs web sur ordinateur de bureau comme sur téléphone et les nouvelles

possibilités qu'apportent le HTML5, le CSS3 et les interfaces gestuelles,

ADAPWEB.indb 6 17/04/13 12:47


TAbLE dEs MATiÈREs NP

AvAnT-pROpOs vii

ceux qui conçoivent des sites web doivent plus que jamais disposer d'une

source fiable leur montrant comment tirer au mieux profit de ces opportunités

en créant du contenu compatible avec tous les modèles de navigateurs, tous

les formats d 'affichage et tous les niveaux de capacités. Cette source fiable

est entre vos mains.

La convergence entre ces nouveaux éléments et ces nouvelles opportunités

pousse les professionnels du Web à enfin envisager leur travail de design tel

qu'il aurait dû l'être depuis le début. Le design adaptatif est la voie à emprunter,

et personne ne maîtrise mieux qu'Aaron la pensée et les techniques néces-

saires pour la pratiquer avec excellence. Ces techniques et cette approche sont

exposées dans les pages qui suivent. Vous ne perdrez plus des journées entières

à vous demander comment concevoir de belles pages web en rédigeant du code

de qualité qui fonctionne pour tous les visiteurs. J'ai prévu de distribuer ce livre

à tous mes étudiants, et à tous ceux avec lesquels j'ai l'occasion de travailler. Je

vous invite à faire de même. Et maintenant, assez de préliminaires. Plongez-

vous dans la lecture et profitez-en bien !

Jeffrey Zeldman

Auteur de Designing With Web Standards 3rd Edition

ADAPWEB.indb 7 17/04/13 12:47

Propriété de david damour <[email protected]>customer 272758 at 2014-04-04 14:08:47 +0200272758ADAPWEB.indb 8 17/04/13 12:47


CHApiTRE 1

PENSEZ À L'UTILISATEUR, PAS AU NAVIGATEURSi vous avez un minimum d'expérience en design web, il est fort probable que

vous ayez entendu parler du concept "d'amélioration progressive" (ou que vous

l'ayez pratiqué). Vous savez donc qu'il s'agit en matière de design web du modèle

idéal vers lequel tendre. Mais qu'est-ce au juste que l'amélioration progressive ?

Quelle est sa signification ? Comment doit-on la mettre en pratique ? Et de

quelle manière peut-on incorporer cette approche à notre mode de travail dans

un contexte d'évolution rapide des langages et des navigateurs ?

Toutes ces questions sont très pertinentes et j'y réponds au long de ce livre.

Comme vous le constaterez, l'amélioration progressive n'est pas un problème

de gestion des différents navigateurs, ni de choix des versions de HTML ou de

CSS qu'il faut utiliser. Il s'agit d'une approche philosophique visant à produire

des situations qui permettent à vos utilisateurs d 'accéder au contenu du site

sans subir de contraintes technologiques.

Que demander de mieux ? Tout cela semble très séduisant, mais la quantité

de travail à prévoir paraît impressionnante. N'ayez crainte. Une fois que vous

aurez assimilé le principe de l'amélioration progressive, ou, mieux encore,

que vous aurez compris pourquoi cela fonctionne, vous verrez que tout cela

est fort simple.

Au cours de votre progression dans le livre, vous découvrirez de nombreux cas

pratiques d'application de l'amélioration progressive qui combinent le HTML,

le CSS et le JavaScript de façon à créer des sites web adaptatifs qui ne vont

ADAPWEB.indb 1 17/04/13 12:47


2 AdApTivE WEb dEsign

pas seulement convenir à vos utilisateurs, mais leur proposer une expérience

utilisateur satisfaisante, et ce, quels que soient le navigateur ou l'appareil avec

lesquels ils y accéderont.

Mais avant de plonger dans la pratique, il nous faut aborder le pourquoi et

le comment de l'amélioration progressive, c'est-à-dire les fondements de cette

philosophie.

s'AdApTER OU pÉRiRS'il faut attaquer le sujet par la base, l'amélioration progressive repose sur un

grand principe : la tolérance aux pannes.

Cette tolérance aux pannes désigne la capacité d'un système à continuer à

fonctionner même s'il rencontre une erreur imprévue. C'est cette capacité

qui permet à un lézard de faire repousser sa queue et au cerveau humain de

créer de nouvelles connexions neuronales lorsqu'il se remet d'un traumatisme

crânien. La nature se montre très friande de ce mécanisme de robustesse ou

de résilience, et l'humain s'est inspiré d'elle en adoptant ce principe dans ses

inventions, comme dans le cas des réseaux de distribution d'électricité intel-

ligents qui évitent ou réduisent l'impact des surcharges réseau en détectant

(et parfois en prévenant) les situations problématiques.

Que vous utilisiez le réseau web en tant que simple visiteur de sites ou en

tant que professionnel, vous profitez déjà en permanence de ce mécanisme

de tolérance aux pannes. Ce principe est en action dans les modes d 'achemi-

nement des paquets de données (les protocoles) entre le navigateur client et le

serveur web que vous voulez visiter, et il est même intimement imbriqué dans

les langages qui incarnent le Web d'aujourd'hui : le HTML et le CSS. Les

spécifications de ces deux langages édictent une obligation pour les naviga-

teurs d'ignorer ce qu'ils ne parviennent pas à interpréter. C'est cette condition

simple qui rend possible l'amélioration progressive. Mais nous y reviendrons

dans un instant.

Un autre aspect intéressant de la tolérance aux pannes est son ouverture

à l'évolution. Revenons au modèle qu'est la nature : vous voyez la capacité

d 'adaptation en action dans les régions ayant connu des changements clima-

tiques ou environnementaux suffisants pour forcer les organismes vivants à

choisir entre s'adapter, quitter les lieux ou périr.

ADAPWEB.indb 2 17/04/13 12:47


CHApiTRE 1 pEnsEZ À L'UTiLisATEUR, pAs AU nAvigATEUR 3

En 1977, les Îles Galapagos ont connu une sécheresse telle qu'elle a fait

fortement baisser la quantité de petites graines qui constituaient la nourriture

de prédilection des pinsons de Darwin (géospizes) habitant ces îles. Quatre-

vingt-cinq pour cent des géospizes sont morts de faim, seuls les plus gros

spécimens ayant survécu. Pourquoi ? Parce qu'ils possédaient un plus

grand bec capable de casser les enveloppes des graines plus grosses qui ne

manquaient pas. En temps normal, ces pinsons à grand bec n'avaient aucun

atout compétitif, mais avec la sécheresse, ils ont tiré avantage de la situation.

Non seulement ils ont survécu, mais ils ont transmis leurs gènes aux généra-

tions suivantes qui sont évidemment dotées d'un bec plus grand.

Figure 1.1 : Comparaison de la taille des becs des pinsons des Galapagos

(pinsons de Darwin ou Geospiza fortis) tirée d'une illustration du livre

Zoologie du voyage du H.M.S. Beagle, de John Gould.

Le HTML et le CSS ont plusieurs points communs avec les pinsons de

Darwin. Ils sont en effet également conçus pour être compatibles avec le futur,

ce qui signifie que tout ce qui fonctionne aujourd'hui fonctionnera encore

demain, l'an prochain et dans dix ans. Ce sont en quelque sorte des pinsons

parfaits : créés pour survivre quelle que soit l'ampleur des changements de

l'environnement de la navigation web.

Puisque ces langages ont été prévus pour évoluer dans le temps, les naviga-

teurs web ont été forcés de se conformer aux règles de tolérance aux pannes

en ignorant tout ce qu'ils ne savaient pas comprendre. C'est ce qui donne

aux langages cette capacité d'évoluer et de s'adapter sans jamais craindre

ADAPWEB.indb 3 17/04/13 12:47



d'atteindre un point à partir duquel le contenu et le style qu'ils véhiculent

risquent de devenir illisibles ou entraînent un blocage du navigateur. La

tolérance aux pannes permet de visiter un site web conçu en HTML5 avec

le navigateur en mode texte Lynx ou de profiter des nouveautés du CSS3 sans

craindre de se rendre inaccessible aux personnes utilisant Internet Explorer 6.

Il est capital de comprendre la tolérance aux pannes pour intégrer la notion

d 'amélioration progressive. La tolérance aux pannes permet à l'amélioration

progressive de fonctionner et garantit que tous les contenus diffusés sur le

Web sont accessibles à tout un chacun.

Puisque la tolérance aux pannes a été incorporée dès le départ dans les normes

des langages HTML et CSS, vous pourriez en déduire que les professionnels

du Web (comme nous) ont pris soin d'en reconnaître l'importance et la valeur

pour concevoir nos sites web. Hélas, cela n'a pas toujours été le cas.

dEs FAUTEs ÉLÉgAnTEsPendant la première décennie du Web, ce média a beaucoup évolué. Tout

au début est apparu le navigateur Mosaic du NCSA (National Center for

Supercomputing Applications de l'université de l'Illinois) ; c'était le premier

navigateur graphique et le HTML a accueilli l'élément nommé img. Puis

est arrivé l'audio, puis la vidéo, puis l'interaction. Rester en phase avec cette

évolution technologique effrénée était un véritable défi. Dans notre course en

avant, nous en avons oublié la tolérance aux pannes en cherchant à profiter

sans cesse des dernières techniques. Nombre de nos sites finissaient par ne

comporter que des cartes à liens pleine page posées sur des fonds JPEG

élégants. Certains devenaient dépendants des outils Flash et Director de

Macromedia. Peu de sites restaient facilement utilisables et il y en a moins

encore qui restaient accessibles à tous.

Cette époque a donné naissance à la théorie appelée "dégradation élégante"

(graceful degradation).

La dégradation élégante constitue le pendant philosophique de la tolérance

aux pannes, une parente superficielle et obsédée par les apparences, qui désire

uniquement mettre les plus riches atours et sortir avec les beaux garçons.

Dans le contexte du Web, la dégradation élégante revenait à rassasier les plus

récents et puissants navigateurs avec des mets de choix, tout en jetant quelques

ADAPWEB.indb 4 17/04/13 12:47



miettes aux pauvres hères qui approchaient avec leur minable navigateur

d 'ancienne génération.

À l'époque de l'apogée de cette dégradation élégante, notre obsession était de

garantir que nos sites seraient bien rendus par les navigateurs modernes les

plus utilisés. Les tests de compatibilité avec les anciens navigateurs, lorsque

nous en faisions, étaient repoussés au bas de notre liste de priorités.

Le raisonnement était limpide : le HTML et le CSS étant tous deux tolérants

aux pannes, l'utilisateur verrait toujours quelque chose s'afficher. Mais nous

ignorions que le JavaScript, comme d 'autres langages de programmation,

n'était pas tolérant aux pannes (si vous appelez par exemple une méthode

inexistante, vous faites subir une erreur au visiteur). Les scripts et applications

écrits en JavaScript doivent contenir des procédures spécifiques pour être

capables de survivre aux erreurs (par exemple en tentant d'exécuter la même

action par un autre moyen) ou du moins de pressentir une erreur potentielle

en quittant avant qu'elle ne se produise.

Rares étaient ceux qui prenaient ce genre de précautions, parce que nous étions

focalisés sur la marche en avant, à l'affût du dernier jouet avec lequel nous

pourrions embellir nos sites. Nous supposions que les anciens navigateurs ne

permettraient qu'une expérience inférieure. Nous justifiions en considérant

que le temps qu'il aurait fallu y consacrer pour au minimum s'assurer que le

résultat restait décent et sans erreur n'en valait pas la peine. Bien sûr, nous

gérions les erreurs les plus flagrantes, mais pour les autres, nous laissions

gentiment les utilisateurs se débrouiller. (Et c'est triste à dire, mais certains

parmi nous allaient jusqu'à bloquer l'entrée aux navigateurs qu'ils ne voulaient

pas prendre la peine de gérer.)

ÉMERgEnCE dU pRinCipE dE TOLÉRAnCEAprès quelque temps, des développeurs web avisés ont commencé à réaliser

que la prédilection de la dégradation élégante pour les images au détriment

du contenu allait dans la mauvaise direction. Ils constatèrent que la dégra-

dation élégante était la cause directe d'une réduction de la disponibilité et

de l'accessibilité des contenus. Ces concepteurs et développeurs virent que

le Web avait pour raison d'être la diffusion et la consommation de contenus

ADAPWEB.indb 5 17/04/13 12:47



(mots, images, vidéos, etc.) Ils décidèrent de reprendre les choses à zéro en

considérant leurs marquages, leurs styles et leurs choix d'interaction en tenant

compte de l'impact de ces choix sur la disponibilité des contenus.

En réorientant leurs efforts, les développeurs ont commencé à exploiter la

nature tolérante aux pannes du HTML et du CSS ainsi que le mécanisme

de détection d'erreurs de JavaScript, et à comprendre qu'une expérience du

visiteur positive ne devait pas être de type tout ou rien (c'était le cas sous l'effet

de la dégradation élégante). Au contraire, les technologies web pouvaient être

exploitées sous forme de strates se complétant les unes les autres en offrant une

expérience et un niveau d'interaction de plus en plus riches. Steve Champeon

du projet Web Standards Project a parfaitement capté l'essence de cette philo-

sophie en inventant l'expression "amélioration progressive"1.

délicieux à tous les niveauxJ'aime utiliser comme analogie de l'amélioration progressive la confiserie

M&M's. Au cœur de cette petite bille se trouve une cacahuète (vous le

saviez ?) Cette cacahuète est en soi une bonne source de protéines et de

graisses, un aliment que tout le monde apprécie (sauf ceux qui y sont aller-

giques, évidemment). De même, le contenu de notre site web doit pouvoir être

consommé même sans aucun embellissement.

Figure 1.2 : Un continuum alimentaire.

Enrobez cette cacahuète de chocolat et vous obtenez une friandise qui met

l'eau à la bouche et qui a bon goût, comme la cacahuète seule. De même, des

contenus bien présentés et organisés grâce aux styles CSS sont souvent plus

faciles à lire, et en tout cas, plus agréables à consommer.

1. http://www.hesketh.com/publications/inclusive_web_design_for_the_future/

ADAPWEB.indb 6 17/04/13 12:47



Si nous ajoutons une coquille d'enrobage sucré, l'expérience est encore

meilleure. De même, nous pouvons enrichir notre belle mise en pages avec

des interactions écrites en JavaScript qui simplifient la navigation parmi les

contenus ou les font apparaître d'une manière originale et attrayante.

Cette comparaison est bien sûr une simplification excessive de ce qu'est

l'amélioration progressive, mais elle vous procure une idée générale de son

fonctionnement. Les technologies sont appliquées sous forme de strates – le

HTML, puis le HTML avec le CSS, puis le HTML, le CSS et le JavaS-

cript –, afin de fournir des expériences différentes, dont chacune est aussi

pertinente que les autres (et aussi goûteuse). Et au centre de ces appareillages,

il y a la noix : de bons contenus.

Une approche partant du centreLe Web, c'est de l'information. Tous les jours, sur tous les sites, des informa-

tions sont diffusées, demandées et collectées. Ces échanges sont devenus des

éléments indispensables à la croissance du Web et vont sans aucun doute

continuer à soutenir son expansion permanente jusqu'à concerner tous les

aspects de notre quotidien.

Puisque cela représente un aspect important du Web, l'échange d'informa-

tions doit devenir notre objectif prioritaire lors de la construction de toute

interface web. L'amélioration progressive garantit que tous les contenus (les

informations que diffuse le site web) restent accessibles et utilisables par

n'importe qui, quelle que soit la situation géographique, le type d 'appareil

utilisé ou les capacités du logiciel d 'affichage de ces contenus. De même, les

outils de collecte de contenus (formulaires web, questionnaires, etc.) profitent

grandement de l'amélioration progressive, car elle leur garantit une exploitation

universelle, ce qui leur permet de mieux faire leur travail d'extraction.

Par définition, l'amélioration progressive s'intéresse à l'accessibilité, mais pas

dans le sens limité qu'on lui prête habituellement, à savoir celui d'ensemble des

efforts d 'aménagement visant à rendre du contenu accessible aux individus

ayant des besoins particuliers (handicap moteur, cérébral ou sensitif). Notre

amélioration progressive va plus loin en édictant que chacun de nous a des

besoins particuliers, ces besoins pouvant évoluer au cours du temps et en

fonction du contexte. Par exemple, lorsque j'accède à un site web depuis mon

smartphone, je suis limité visuellement par la résolution et la taille de l'écran

(d 'autant plus avec un navigateur qui permet de zoomer) et gestuellement

ADAPWEB.indb 7 17/04/13 12:47



par l'interface tactile pour activer les boutons et les liens, car mes doigts sont

moins précis qu'un pointeur de souris.

Nous avons dit plus haut que les sites conçus dans un esprit de dégradation

élégante fonctionnaient bien dans les navigateurs modernes, mais beaucoup

moins bien ou pas du tout dans les navigateurs plus anciens. Dans un sens

général, c'est comme si l'utilisateur visitait un parc d 'attractions : les plus

beaux manèges lui seraient interdits parce qu'il ne fait pas la taille suffisante.

De même, le visiteur qui ne possède pas le "bon" navigateur va subir des

problèmes (et des erreurs) pour accéder au contenu des sites, et encore, lorsqu'il

parvient à y accéder.

À l'opposé, un site web conçu en accord avec la philosophie d 'amélioration

progressive sera utilisable par tous, depuis tous les appareils, avec tous les

navigateurs. Bien sûr, le visiteur utilisant le navigateur en mode texte Lynx

n'aura pas la même expérience que celui qui possède la dernière version de

Safari, mais ce sera une expérience positive et non une absence de résultat.

Le contenu du site sera accessible dans une version édulcorée, ce qui n'est

nullement garanti dans l'approche de dégradation élégante.

Alors que leurs philosophies sont très différentes, l'amélioration progressive et

la dégradation élégante peuvent facilement se confondre en termes pratiques,

ce qui est dommage. Pour bien souligner ces différences, j'aime utiliser cette

formule : toutes les expériences conçues selon l'amélioration progressive

garantissent une dégradation élégante dans les anciens navigateurs, alors que

peu d'expériences conçues selon la dégradation élégante vont permettre une

amélioration progressive.

des limites ? Quelles limites ?Pendant l'âge d'or de la dégradation élégante, les sites web finissaient par

ressembler aux parcs d 'attractions évoqués plus haut : "Manège interdit aux

personnes mesurant moins de 1,20 m de hauteur". Le Web s'était rempli (il

l'est hélas encore) de sites affichant fièrement une mise en garde du style "Site

optimisé pour Netscape Navigator 4". Nous avons abandonné cette pratique

déplorable grâce à l'amélioration progressive et à la diffusion des standards

web, mais ce phénomène de cloisonnement est réapparu lorsque les sites ont

commencé à adopter la technique JavaScript nommée Ajax. De plus en plus

de sites ont réclamé la présence de JavaScript ou même restreint l'entrée à

certains modèles et versions de navigateurs. Nous assistions à une rediffusion

de cet épisode tant redouté de l'histoire du Web : le retour des sales méthodes

ADAPWEB.indb 8 17/04/13 12:47



de blocage des navigateurs et d'anti-ergonomie que nous pensions avoir défini-

tivement abandonnées.

Comme "avec le temps va, tout s'en va", la ferveur autour d 'Ajax s'est calmée

et nous avons pu recommencer à construire (et parfois à reconstruire) des

sites fondés sur Ajax conformes à l'approche d'amélioration progressive. Mais

un beau jour, il y eut la présentation d 'Apple HTML5 Showcase avec ses

superbes transitions et animations en CSS2. À peine avions-nous essuyé la

salive tombée sur nos bureaux que nous décidions, nombreux, d'incorporer ces

élégantes nouveautés dans nos sites, soit par impatience, soit sous la pression

de nos clients. Conséquence : ont commencé à se multiplier des sites qui

obligeaient leurs visiteurs à disposer d'une variante très récente de Webkit3

pour être vus (et au diable les quatre-vingts pour cent de navigateurs qui n'en

étaient pas dotés).

Mais les concepteurs de sites ont fini par comprendre que l'adoption de

technologies spécifiques allait à l'encontre de la philosophie d 'amélioration

progressive. Certains d'entre eux ont alors persisté en déclarant que cette

philosophie était limitante et sont revenus à l'ancienne approche de dégra-

dation élégante. Ils estimaient que l'amélioration progressive les obligeait à

prendre en charge les anciens navigateurs qui n'étaient pas aussi gratifiants

à utiliser. Ce que ces gens n'ont pas compris, c'est que ce n'était pas l'amélio-

ration progressive qui les bridait, mais leur mauvaise interprétation de cette

philosophie.

Il faut savoir que l'amélioration progressive ne se focalise pas sur les naviga-

teurs. Son but est de guider la conception de scénarii qui permettent aux

utilisateurs d 'accéder aux contenus sans subir de contraintes technologiques.

L'amélioration progressive ne vous demande pas de tenter de fournir la même

expérience sur différents navigateurs, et ne vous empêche nullement d'adopter

les dernières innovations ; elle vous demande uniquement de faire honneur

à vos contenus (et à vos visiteurs) en appliquant les technologies de façon

2. http://www.apple.com/html5/

3. Webkit est le moteur de rendu visuel utilisé par de nombreux navigateurs et applications.

Son support de CSS est excellent et il sait gérer certaines fonctions évoluées de CSS,

comme les animations CSS, bien mieux que d 'autres navigateurs. Webkit est utilisé par

les navigateurs Safari d 'Apple, Chrome de Google et les navigateurs Android, celui de

Symbian S60, Shiira, iCab, OmniWeb, Epiphany, pour n'en citer que quelques-uns. Il est

à la base du système WebOS de Palm et a été incorporé dans plusieurs produits Adobe

parmi lesquels AIR (Adobe Integrated Runtime) et la suite CS5.

ADAPWEB.indb 9 17/04/13 12:47



intelligente, sous forme de plusieurs strates, pour qu'à chaque niveau, l'expé-

rience soit concluante. Les navigateurs et les technologies surgissent puis

s'étiolent. Il est tout à fait possible de combiner l'amélioration progressive et

votre désir de vous montrer innovant en réalisant des choses étonnantes dans

les navigateurs, à condition de faire des choix avisés et de ne jamais perdre

de vue vos utilisateurs.

L'amélioration progressive pour un excellent service au clientSupposez un instant que vous soyez serveur dans un grand restaurant.

Votre travail et vos pourboires sont liés à votre attention aux détails et à la

perfection de votre service. Un critère de contrôle de votre attention consiste

à vérifier le niveau des verres d'eau de vos clients avant de venir les remplir.

Un serveur distrait laissera les verres vides plusieurs minutes. Quelqu’un

d'un peu plus concerné ne laissera pas les verres se vider plus qu'à moitié. Le

serveur attentif non seulement n'attendra pas que le verre soit à moitié vide,

mais il sera assez adroit pour remplir sans que le client s'en aperçoive. Vous

devinez quels clients quitteront le restaurant les plus satisfaits du service. Si

nous considérons seulement la bonne hydratation des clients, qui recevra le

meilleur pourboire, d 'après vous ?

Puisque nous sommes concepteurs et développeurs de sites web, nous devons

tendre vers la même excellence que le serveur idéal, mais ce n'est pas simple.

De même que le serveur ne peut savoir à l'avance à quel rythme ses clients

vont vider leurs verres, nous ne pouvons pas prévoir les besoins de chaque

visiteur de nos sites. Il nous faut les devancer. Si nous sommes vraiment

concentrés, nous saurons y parvenir sans que les visiteurs se rendent compte

que nous déployons tous ces efforts pour eux. Cet objectif devient aisément

accessible en adoptant l'approche orientée utilisateur et contenus de l'amé-

lioration progressive (et non l'approche de suiveur des dernières modes de la

dégradation élégante).

sAisissEZ L'OCCAsiOnLorsque vous démarrez un projet dans une perspective d 'amélioration

progressive, vous vous centrez d 'abord sur les contenus, puis sur tout ce qui

s'y ajoute. Cette approche par strates incarne la prévenance avec laquelle vous

répondez par avance aux attentes des visiteurs en gérant le contexte dans

lequel se fait l'accès aux pages web. Ce contexte est lié aux possibilités du

ADAPWEB.indb 10 17/04/13 12:47



navigateur et, dans une moindre mesure, aux capacités du matériel sur lequel il

fonctionne. Le but fi nal est d'adapter l'expérience du visiteur en conséquence.

Le premier niveau d'expérience correspond toujours à du texte. Dans cette

strate n'intervient aucune technologie remarquable ; le succès ou l'échec de

la visite ne dépend que des capacités littéraires du rédacteur du contenu. Il

est évident qu'un texte bien rédigé se rend ainsi universellement accessible

et fait faire un pas de géant en termes d 'accessibilité du contenu. Et quelles

que soient les évolutions à venir du langage HTML, l'impératif de tolérance

aux pannes imposée aux navigateurs dans leur interprétation du marquage

HTML garantit que le contenu marqué sera toujours accessible dans son

format le plus élémentaire : des chiff res et des lettres.

Le deuxième niveau d'expérience correspond à la sémantique du langage

HTML. Les éléments de langage et leurs attributs fournissent une description

de ce que signifi e le contenu et renseignent sur son contexte. Ils donnent des

informations importantes comme la mise en exergue de certains termes, la

source d'une citation ou la signifi cation d'une expression peu familière.

Minimales EvoluéesCApACiTÉs dU nAvigATEUR

sATi

sFAC

TiOn

UTi

LisA

TEUR

Figure 1.3 : Graphe de l'amélioration progressive.

Le troisième niveau d'expérience correspond à l'enrichissement audiovisuel

avec les styles CSS et l'ajout d'images fi xes, de sons et de vidéos. Comme le

HTML, le CSS est par nature tolérant aux pannes, les navigateurs ignorant

ce qu'ils ne savent pas interpréter ; c'est en cela que l'amélioration progressive

est possible au niveau du langage CSS.

ADAPWEB.indb 11 17/04/13 12:47



Le quatrième niveau d'expérience est celui des interactions avec le visiteur.

Dans le monde des standards, il s'agit presque toujours de code JavaScript,

même si d'autres technologies d'interaction web ont été employées, notamment

Flash ou même les applets Java.

Le dernier niveau d'expérience consiste à appliquer la spécification WAI-ARIA

(Web Accessibility Initiative's Accessible Rich Internet Applications) et les règles de

sémantique augmentées et meilleures pratiques qu'elle mentionne. Ces enrichis-

sements des pages web prennent la relève là où s'arrêtait normalement le HTML

(même si le HTML5 a incorporé dans son lexique quelques points sémantiques

évolués issus d 'ARIA).

Ces différentes strates (qui sont autant de niveaux de support) permettent

de proposer une expérience qui s'améliore progressivement d'une strate à la

suivante. Ce ne sont pas les seuls scénarii que vous pouvez présenter à vos

utilisateurs, mais elles constituent des jalons clairement identifiés sur le chemin

qui va de l'expérience minimale à l'expérience exceptionnelle. L'expérience

réelle d'un utilisateur peut varier à chaque niveau sur quelques points. Cela

reste sans conséquence sur le service offert aux utilisateurs tant que nous,

concepteurs, ne perdons pas de vue le principe d 'amélioration progressive.

En AvAnT, TOUTE !La suite du livre vous invite à visiter les différentes étapes sur l'autoroute de

l'amélioration progressive. Nous découvrirons successivement le marquage

HTML, les styles CSS, le JavaScript et enfin ARIA. Le périple sera illustré

par une page de démonstration qui met en pratique ces techniques d 'amélio-

ration progressive, à l'adresse Retreats4Geeks.com. Par principe, ce livre ne

prétend pas constituer une référence exhaustive des techniques d'amélioration

progressive. Les exemples sont épurés et se concentrent sur leur but premier :

vous présenter les meilleures pratiques pour vous permettre d 'adopter sur-le-

champ l'amélioration progressive dans vos projets.

ADAPWEB.indb 12 17/04/13 12:47



Figure 1.4 : La page de présentation d'un événement de formation sur le site

Retreats4Geeks.com qui sera étudiée tout au long de ce livre.

ADAPWEB.indb 13 17/04/13 12:47


"La signification est dans le

contenu du texte, pas dans la

forme des caractères."

— WiM CROUWEL

ADAPWEB.indb 14 17/04/13 12:47


CHApiTRE 2

AMÉLIORATION PROGRESSIVE AVEC LE HTMLQuand on parle de Web, le marquage HTML est incontournable. Il constitue

la fondation de toute mise en page réussie et de toute expérience utilisateur

positive. Que vous préfériez le HTML ou son cousin plus rigoureux XHTML,

chaque élément (balise) a un but clairement défini. La manière dont vous

utilisez ces éléments a un puissant impact sur l'expérience des visiteurs, en

bien ou en mal selon que vous en usiez ou en abusiez.

dU TERRAin vAgUE AU dROiT CHEMinLorsque nous avons commencé à concevoir des pages web, beaucoup d'entre

nous ont négligé l'importance d'un bon marquage. Ceux qui venaient du

monde de la programmation ont considéré que l'apprentissage du langage

HTML allait de soi, et n'ont donc jamais pris le temps d'étudier sa sémantique

particulière. Ceux qui venaient du monde de la création graphique n'ont pas

non plus senti l'importance de la sémantique. Nous nous sommes tous focalisés

sur la partie présentation des pages web et avons sauté sur la balise table

comme base de la technique de mise en page selon un quadrillage invisible.

Nous avons ensuite trouvé des tonnes d'utilisations nouvelles de l'élément

table, qui ne sont pour la plupart que des remplacements d'éléments séman-

tiques existants (et parfaitement gérés par les navigateurs) tels que les listes.

ADAPWEB.indb 15 17/04/13 12:47



Dans de nombreuses entreprises de la planète, les promoteurs d'une utili-

sation sémantique rigoureuse du langage HTML n'ont pas été entendus ;

leurs arguments étaient considérés comme relevant d'une position d'intellec-

tuels puristes, pour deux raisons principales : 1) force était de constater que

les anciens sites web se présentaient toujours très bien dans les nouveaux

navigateurs ; 2) comme bien des personnes ne souffrent d 'aucun handicap,

peu avaient eu l'occasion de ressentir l'importance d'une meilleure accessibilité

au Web. Et un jour, Google est arrivé et tout a changé. D'un seul coup, le

marquage sémantique redevenait un sujet important.

Google a été le premier moteur de recherche prenant en compte les éléments

sémantiques pour indexer les pages web. Se fondant au départ sur le très

élémentaire élément d 'ancrage (a) comme pierre angulaire de son algorithme

PageRank, Google est devenu le pionnier dans l'exploitation des marqueurs

sémantiques pour extraire du sens et de la pertinence des pages scrutées. Les

autres moteurs de recherche ont rapidement suivi, et les moteurs de recherche

se sont lancés dans la traque d 'autres éléments HTML porteurs de sens

dans les pages web (par exemple, les balises h1 qui contiennent normalement

l'information la plus importante d'une page). Le marquage sémantique est

ainsi devenu un critère significatif dans le monde des entreprises, puisque

son utilisation avisée permettait d'être mieux placé dans les résultats des

recherches, et en conséquence d 'augmenter les chances d'entrer en contact

avec de nouveaux clients.

LA FOndATiOn sÉMAnTiQUESi l'on compare le contenu au substrat, le marquage sémantique est le compost

que vous ajoutez pour garantir la fertilité de votre jardin. Il enrichit le contenu

en fournissant aux visiteurs des indices au sujet du contexte et des intentions

de l'émetteur, et en proposant des informations complémentaires au contenu.

Prenez comme exemple l'élément d 'abréviation abbr. Il sert à désigner une

abréviation (ou un acronyme, ce qui lui permet dorénavant de remplacer

l'élément acronym) :

Gatlinburg, <abbr title="Tennessee">TN</abbr>

Dans cet extrait HTML, vous voyez comment l'élément enrichit les deux

lettres "TN" en rappelant au visiteur qu'elles signifient "Tennessee".

ADAPWEB.indb 16 17/04/13 12:47


CHApiTRE 2 AMÉLiORATiOn pROgREssivE AvEC LE HTML 17

Le langage HTML a évolué sans cesse pour offrir de plus en plus d'options

de description des contenus que les éléments délimitent (encapsulent). La

publication de la norme HTML5 a donné naissance à une flopée de nouvelles

options sémantiques (telles que header) et à des enrichissements de quelques

éléments préexistants (comme l'élément abbr déjà cité, qui remplace l'élément

acronym). Nous utiliserons au cours de ce chapitre plusieurs éléments nouveaux

ou enrichis ; j'en profiterai pour donner quelques raisons d'y recourir pour

marquer les contenus.

L' heure est venue de passer à la pratique.

diRE CE QUE L'On vEUT FAiRE sAvOiRSi vous visitez la page web de Retreats 4 Geeks1, vous pouvez vous demander

par où commencer. Intéressons-nous au contenu le plus important qu'est le

nom du site et la série de liens qui mènent aux différentes sections de la même

page (pour l'exemple, le site ne compte qu'une page).

Figure 2.1 : La page du site web montrant le nom du site et les éléments de

navigation.

Intéressons-nous à cette page dans une approche de sémanticien, et

commençons par le logo de Retreats 4 Geeks2. C'est une image, et nous

1. Si vous n'avez pas encore téléchargé le fichier archive des exemples, faites-le maintenant

en vous rendant à l'adresse adaptivewebdesign.info. Cherchez le bouton Download the

project files.

2. Oui, je sais que vous pouvez aussi utiliser l'élément object ou définir un texte puis le

remplacer par une image avec des instructions CSS, mais je préfère m'en tenir au plus simple.

ADAPWEB.indb 17 17/04/13 12:47



utilisons logiquement un élément img pour la baliser. L' élément est assez

important, puisqu'il fournit un contexte pour toute la page. Nous devons

donc l'incorporer à un élément de titre h1, l'élément qui est réservé au contenu

majeur de la page.

<h1><img src="i/logo.png"/></h1>

Notre page d'exemple est écrite en HTML5, mais j'ai toujours été plus à l'aise

avec la sérialisation XML de ce langage et j'ai choisi de rester fidèle à cette

syntaxe (ce dont témoigne la barre oblique fermante de l'élément img). Il s'agit

plus d'une question de préférences que d'une obligation.

Au niveau des moyens de navigation locale, nous proposons une liste de liens

qu'il faut donc marquer en tant qu'éléments de liste. L'ordre des liens devant

correspondre à l'ordre des sections de contenu dans la page, nous opterons

pour une liste ordonnée (ol). Chaque lien est inséré dans un élément de liste

(li) à l'intérieur d'un élément d 'ancrage (a) :

<ol> <li><a href="#details">Details</a></li> <li><a href="#schedule">Schedule</a></li> <li><a href="#instructors">Instructors</a></li> <li><a href="#lodging">Lodging</a></li> <li><a href="#location">Location</a></li> </ol>

Au point où nous en sommes, nous avons fait les choix de marquage évidents,

en profitant des possibilités sémantiques offertes par le langage HTML depuis

ses origines. Voici encore un an, nous en serions restés là et aurions considéré

notre en-tête comme terminé, mais le HTML5 nous permet d'aller plus avant

au niveau de la sémantique et de l'accessibilité du contenu.

Traditionnellement, nous aurions eu recours à une division de page (div)

munie d'un identifiant sémantique (id) de valeur "header" pour regrouper

ces deux éléments. Vous vous souvenez sans doute que les divisions servent

à regrouper des éléments, mais qu'elles ne fournissent aucun contexte pour

préciser le domaine d'emploi ou la fonction du groupe (c'est d'ailleurs pourquoi

nous décidons de lui attribuer l'identifiant "header"). Le HTML5 introduit un

nouvel élément pour préciser la signification (la sémantique) d'une division.

Il s'agit de l'élément header.

ADAPWEB.indb 18 17/04/13 12:47



Un élément header sert à identifier le contenu de première importance d'une

page ou d'une section de page. Il permet d 'abord d'englober les en-têtes

ou groupes d'en-têtes (placés dans le nouvel élément hgroup), les aides à la

navigation et le contenu de sommaire ou d'introduction. Cet élément constitue

de ce fait le conteneur idéal pour le titre de page et la liste des ancrages qui

mènent à chacun des articles de notre page.

Le langage HTML5 offre une autre option encore plus appropriée pour la

navigation. Alors qu'auparavant, nous aurions identifié la liste ordonnée avec

"nav" ou "main-nav", nous pouvons avec le HTML5 profiter de son élément

nav pour exprimer de façon plus directe l'aspect sémantique que nous voulons

ajouter à la liste ol en fournissant cet identifiant sémantique id. L' élément

nav permet de réunir tout un groupe de liens et de fonctions de navigation

pour former l'équivalent sémantique du rôle de repère de l'élément ARIA

"navigation" (que nous décrirons dans le Chapitre 5).

Ces ajouts étant faits, le marquage de la section devient le suivant :

<header> <h1><img src="i/logo.png"/></h1>

<nav> <ol> <li><a href="#details">Details</a></li> <li><a href="#schedule">Schedule</a></li> <li><a href="#instructors">Instructors</a></li> <li><a href="#lodging">Lodging</a></li> <li><a href="#location">Location</a></li> </ol> </nav></header>

Ce marquage fonctionnera dans tous les navigateurs, même les plus anciens,

grâce à leur comportement consistant à ignorer tout ce qu'ils ne savent pas

interpréter. Les navigateurs les plus récents sauront bien sûr quoi faire des

éléments nouveaux, mais les plus anciens, comme le navigateur en mode texte

Lynx, pourront trouver le contenu et l'afficher. Ce marquage sans styles ni

interactivité JavaScript fonctionne et répond ainsi au deuxième niveau de

ADAPWEB.indb 19 17/04/13 12:47



support demandé dans l'approche d'amélioration progressive. (Souvenez-vous

que c'est le contenu qui constitue le premier niveau, si important).

invisibLE ET COnsULTATiFLe marquage est déjà bien formé, mais nous avons oublié un point important

qui participe à l'accessibilité : le texte palliatif (alternate text) pour remplacer

l'image de logo (exprimé par l'attribut d'élément alt). Rappelons que ce genre

de "texte alt"3 donne un minimum d'informations au sujet d'une image lorsque

l'utilisateur n'a pas accès à celle-ci, soit parce qu'il a désactivé l'affichage des

images, soit parce qu'il est malvoyant et utilise la fonction de lecture audio du

contenu de l'écran, d'où l'importance de cet attribut.

Voici comment j'ai donc ajouté un attribut alt très simple à l'exemple :

<h1><img src="i/logo.png" alt="Retreats 4 Geeks"/></h1>

Lorsque l'image est un logo ou qu'elle donne une information indispensable

pour comprendre l'objectif de la page ou pour décider de faire une action

majeure, il faut systématiquement penser à fournir du texte pour l'attribut

alt. Dans les autres cas (images d'illustration), vous pouvez tout à fait laisser

l'attribut alt vide (alt=""). J'irais même jusqu'à conseiller de fournir un attribut

alt vide pour toute image d'agrément, donc non vitale, et ce pour deux raisons :

1) personne n'éprouve le besoin de lire ou d'entendre lire des choses aussi

pathétiques que "Vue d'un homme souriant qui lance un frisbee à son Golden

Retriever", et personne n'a envie de rédiger ce genre de texte palliatif ; 2) les

lecteurs audio d'écran lisent le texte qu'ils trouvent dans les attributs alt, mais

ignorent les images dont cet attribut est vide4.

De même que l'attribut alt fournit du contenu de secours à une image, l'attribut

title permet de donner des informations complémentaires pour un élément.

Dans le cas des liens de navigation de notre précédent exemple, nous pouvons

3. Certaines personnes deviennent nerveuses en entendant parler de "balise alt" ou de "alt

tag", car les balises (éléments) et les attributs de balises sont deux choses très différentes

(les attributs s'appliquent à la balise ouvrante d'un élément). Si vous vous surprenez en

train de vouloir parler de balise pour alt, corrigez-vous et dites bien "attribut alt" ou "texte

alt".

4. Les lecteurs d'écrans prononcent le seul mot "image" lorsqu'ils rencontrent une image qui

n'est pas dotée d'un attribut alt. Ayez donc la délicatesse d 'ajouter cet attribut systémati-

quement, vide ou non.

ADAPWEB.indb 20 17/04/13 12:47



utiliser title pour donner à l'utilisateur des informations sur la cible de chaque

lien :

<li><a href="#location" title="Get the 411 on Gatlinburg, Tennessee">Location</a></li>

Plus bas dans la page, dans la section "location", l'attribut title fournit un

contexte au lien qui mène à la carte de situation :

<a href="http://maps.google.com/..." title="View Gatlinburg, Tennessee on Google Maps"> <img src="http://maps.google.com/..." alt="A map showing the location of Gatlinburg, Tennessee"/></a>

Figure 2.2 : Vue de la section location de la page avec le pointeur de souris

sur la carte.

sÉMAnTiQUE Ad HOCLe langage HTML regorge d 'attributs permettant d'enrichir les éléments

concernés. Certains de ces attributs ont un usage dédié, et c'est le cas de alt

ADAPWEB.indb 21 17/04/13 12:47



et de title, mais d 'autres, et ils sont nombreux, peuvent être employés pour

augmenter la densité sémantique accessible avec les possibilités initiales du

langage, et ce de façon moins formelle. Je veux bien sûr parler des attributs

id et class.

Lorsque Dave Raggett travaillait à la spécification5 du HTML 3.0, il y avait

introduit les nouveaux concepts de classification et d'identification, incarnés

respectivement par les attributs class et id6. Ces attributs n'ont été rendus

publics de façon formelle au sein du langage HTML que lors de la sortie du

HTML 4.0, mais les navigateurs les ont pris en compte à peu près à la même

époque que les feuilles de styles CSS (Cascading Style Sheet). Et le CSS

a introduit deux sélecteurs très simples destinés expressément à ces deux

attributs. Cela a entraîné dès le départ une certaine confusion au niveau de

la compréhension de l'usage attendu des attributs class et id.

Pendant des années, quasiment tous les développeurs web qui utilisaient les

styles CSS ont cru à une corrélation intentionnelle entre les attributs et les

sélecteurs. Ils étaient persuadés que class et id avaient été inventés pour

être utilisés avec les feuilles de styles. Les blâmer serait injuste, car la norme

CSS Level 1 n'offrait pas beaucoup de mécanismes pour sélectionner un

élément ; il semblait opportun de considérer les sélecteurs class (par exemple,

ul.menu) et id (par exemple, div#content) comme ayant été conçus (avec leurs

attributs respectifs) pour appliquer les styles de façon globale pour class et

locale pour id7.

Heureusement, nous savons dorénavant comment les attributs class et id

doivent être utilisés. L'attribut class a été créé spécialement pour répondre

5. Le HTML 3.0 constituait une spécification ambitieuse en apportant de nombreux

nouveaux attributs et balises, dont la plupart ont été abandonnés au moment où la norme

est arrivée à maturité avec la version HTML 3.2. Mais les deux attributs class et id

ont survécu à ce grand ménage. Il est amusant de constater que certaines des construc-

tions proposées à l'origine dans le HTML 3.0 ont refait leur apparition dans le monde

du HTML, soit officiellement dans la version HTML5, soit officieusement en tant que

microformats.

6. Il n'est pas inutile de remarquer que class et id ont fait une brève apparition dès la

spécification HTML 2 (http://www.ietf.org/rfc/rfc1866.txt), mais sans avoir été

formellement définis comme attributs. Ils servaient à faire la preuve du mécanisme de

tolérance à l'inconnu dont devaient être capables les navigateurs en ignorant les attributs

qu'ils ne reconnaissaient pas.

7. Le document de travail HTML 3 autorisait cette utilisation, parmi d 'autres. Il est dispo-

nible à l'adresse http://www.w3.org/MarkUp/html3/html3.txt.

ADAPWEB.indb 22 17/04/13 12:47



au faible nombre d'éléments disponibles dans le lexique de mots réservés du

HTML :

Le temps passant, les attentes des personnes évoluent et le langage HTML

sera de plus en plus sollicité. Un des indices de cette tendance est la pression

ressentie pour introduire toujours plus de balises. Le HTML 3.0 introduit

une technique pour créer des sous-classes d'éléments de façon ouverte.

Elle permet de différencier le rôle d'un élément de type paragraphe en tant

que couplet d'un quatrain, ou de dénoter un terme mathématique en tant

que tenseur. Cette possibilité de créer des distinctions à la volée permet

de gérer des styles de rendu spécifiques ou d'envisager des mécanismes

de recherche plus fins, sans pour autant compliquer le format général des

documents HTML8.

Le but de cet attribut est de lui faire englober une liste de sous-classes pour

l'élément auquel elles sont appliquées, les classes étant listées de la plus

générale à la plus spécialisée9 :

<a href="..." title="..."> <img class="illustration map" src="..." alt="..."/></a>

Dans la spécification, l'attribut id a été défini pour identifier un élément

individuel dans une page (et c'est pourquoi chaque élément id doit être

unique dans la même page). Dans la pratique, cet identifiant a été utilisé

comme point de référence pour une règle de style (#details { ... }), pour

un script (document.getElementById('details')) et pour un ancrage (<a

href="#details">). Vous vous souvenez que nous avons utilisé cet ancrage

pour la navigation plus haut dans ce même chapitre.

Toutes les informations relatives à un événement (un stage) Retreats 4 Geeks

sont réunies dans la même page. J'ai donc distribué les contenus dans plusieurs

éléments article10 ayant chacun son identifiant id unique. L'élément article

8. Tiré de la section "Scalability" de l'avant-projet de norme HTML 3 (voir la note 7).

9. Cette description est visible dans le projet HTML 3, à chaque fois que class est défini

pour un élément.

10. Sans vouloir entraîner une quelconque confusion, ajoutons que le HTML5 a aussi introduit

l'élément section (que nous utiliserons un peu plus loin). En langage HTML5, cet élément

désigne une section de contenu (vous l'aviez deviné ?). Du point de vue de la structure

globale, j'aurais pu déclarer la page en tant qu'article, en faisant de chaque sous-article une

section. J'ai pourtant choisi de définir plusieurs articles, car chaque section me semblait assez

ADAPWEB.indb 23 17/04/13 12:47



est apparu dans HTML5 pour contrôler du contenu constituant une partie

autonome du document : un article de journal, un message de blog ou, comme

dans notre exemple, un aspect distinct d'un sujet. Chacun des articles de la

page est alors ciblé par les liens de navigation en utilisant comme référence

d 'ancrage son identifiant id. Lorsque le visiteur clique sur un lien, cela le

mène directement au contenu associé :

<body> <header>

<h1><img src="/2010/retreat-js/i/logo.png" alt="Retreats 4 Geeks"/></h1>

<nav> <ol> <li><a href="#details" title="Find out what this retreat is all about">Details</a></li> <li><a href="#schedule" title="Get familiar with what this retreat will cover">Schedule </a></li> ... </ol> </nav>

</header> <div id="content">

<article id="details">...</article> <article id="schedule">...</article> ...

</div></body>

Les deux attributs class et id permettent à l'auteur de concevoir sa propre

sémantique en complément de celle définie dans la spécification. L'ensemble

indépendante des autres pour pouvoir éventuellement faire l'objet d'une page distincte.

La différence sémantique entre ces deux approches n'est normalement pas significative et

dépend d 'abord des préférences de l'auteur de la page.

ADAPWEB.indb 24 17/04/13 12:47



qui en résulte enrichit le marquage en signification. Le temps aidant, cela

aboutit à un ensemble de classifications et d'identifiants partagés par toute

la planète (par exemple, div#header et ul#nav). Ce jeu de classifications et

d'identifiants partagés a à son tour alimenté l'évolution du langage HTML (par

exemple avec les ajouts tels que les éléments header et nav du HTML5, vus

plus haut) et suscité l'apparition d'une série d'extensions au HTML conçues

de façon collaborative et connues sous le nom de "microformats".

COnvEnTiOns COdiFiÉEsLes microformats sont des spécifications non officielles produites de façon

collaborative pour définir les modalités de marquage de contenus de sorte

à exprimer des éléments de sémantique (et des métadonnées) au-delà de ce

qui est possible avec la norme HTML (ou XHTML). Par essence, un micro-

format formalise des conventions de codage. Ces conventions sont le fruit

des réponses trouvées sur le terrain pour constituer une spécification visant

à combler un manque ou une limitation de la norme HTML. Par exemple, le

HTML ne proposant aucune solution robuste pour marquer de façon précise

des données de contacts professionnels ou d'événements, la communauté a créé

des microformats pour répondre à ces besoins spécifiques mais très courants.

Le premier microformat a été suscité par le besoin d'exprimer des associations

entre des individus présents sur le Web. Il a été baptisé XHTML Friends

Network (abrégé "XFN"). Au sens strict, ce n'était pas un microformat car

le terme a été trouvé plus tard, mais XFN a constitué un parfait exemple

d'extension de la sémantique du HTML dans un domaine clairement délimité.

XFN a été conçu par Tantek Çelik, Matthew Mullenweg et Eric Meyer.

L'astuce de ce microformat a été d'employer un attribut rarement utilisé :

rel. Vous êtes sans doute familiarisé avec cet attribut rel, si vous l'avez

utilisé avec l'élément link pour référencer une feuille de styles externe

(rel="stylesheet"). Il permet donc de déclarer une relation entre la cible

d'un ancrage et la page actuelle. L' idée de XFN était simple : si j'ai besoin

de gérer un lien entre mon blog et celui d'un collègue, j'ajoute dans l'esprit

XFN un attribut rel="collegue" à mon lien. Pour faire un lien avec le blog

ADAPWEB.indb 25 17/04/13 12:47



de mon épouse, je spécifie rel="amie coloc epouse muse amour soutien"

parce qu'elle représente toutes ces qualités pour moi11

.

Vu ainsi, cet attribut se limite à fournir un complément d'informations

concernant une relation et des détails sur la nature de ce lien vers un autre

site. Cela dit, du fait que j'utilise cet attribut pour tous mes liens externes

depuis mon blog, et que mes collègues font de même, nous obtenons au final un

véritable réseau de liens dans lequel nous pouvons naviguer par programme,

ce qui crée une foule de nouvelles opportunités d'extraction et de réutilisation

de données.

C'est d 'ailleurs exactement ce qui s'est produit : le XFN s'est répandu comme

une traînée de poudre. Les concepteurs de logiciels ont ajouté ce microformat

dans leurs outils de création de blog (par exemple, WordPress, Movable Type)

et les créateurs des sites de Web social (par exemple, Twitter, Flickr, Last.fm)

ont commencé à ajouter aux pages des profils d'utilisateurs une section spéciale

rel="me" (regroupant les liens vers d 'autres sites web). Cela a permis l'appa-

rition d'outils comme Social Graph de Google pour constituer rapidement un

profil complet d'utilisateur en partant d'une seule adresse URL12

.

Nous fournissons un exemple d'utilisation du microformat XFN dans le pied

de page footer de notre page Retreats 4 Geeks13

:

<footer> <p id="copyright">©2010 Retreats 4 Geeks. All Rights Res.</p>

<p>Retreats 4 Geeks is an <a rel="me" href="http://easy-designs.net/"> Easy! Designs </a> venture.</p>

</footer>

11. Waouuuuuuuuu !

12. Pour en savoir plus sur l'API Social Graph, voyez la page http://code.google.com/apis/

socialgraph/. Glenn Jones s'est servi de cette interface API dans sa superbe librairie

JavaScript nommée Ident Engine (http://identengine.com/). Il l'a présentée dans le livre

A List Apart (http://www.alistapart.com/articles/discovering-magic/).

13. L' élément footer est une autre nouveauté de la spécification HTML5 prévue pour

englober des "méta"-informations pour un article, une section ou une page entière : nom

de l'auteur, droits intellectuels, etc.

ADAPWEB.indb 26 17/04/13 12:47



Après avoir ainsi commencé de façon très simple (mais puissante), les micro-

formats se sont multipliés pour répondre à de nombreux besoins très variés :

gestion des informations du profil d'un individu (hCard), gestion de listes

d'événements (hCalendar), syndication de contenus (hAtom), gestion de CV

(hResume), gestion de données de licences d'utilisation (rel-license), protection

contre les robots scruteurs (spiders) des moteurs de recherche (rel-nofollow) et

aide au marquage (rel-tag)14

.

Pour accompagner le développement de ces microformats, sont apparus

plusieurs outils pour les utiliser. La mention faite plus haut au Social Graph

de Google vous laisse deviner que les moteurs de recherche ont commencé

à tenir compte des microformats, au point parfois de classer les contenus

dotés de microformats avant les autres. Les extensions de navigateurs telles

qu'Operator15

et Oomph16

permettent à l'utilisateur d'extraire et de réutiliser

les contenus des microformats. Vous disposez en outre d 'analyseurs de micro-

formats pour quasiment tous les langages de programmation et des services

basés Web tels qu'Optimus17

ou H2VX18

, qui assurent un accès direct aux

contenus des microformats des sites.

Vous constatez que les microformats constituent une phase supplémentaire

dans la progression continue vers l'amélioration progressive. Ils nous permettent

de rendre nos sites web encore plus utiles à nos visiteurs. Ne trouvez-vous pas

vraiment intéressant de pouvoir, à l'aide d'un outil tel qu'Operator ou d'un

service tel qu'Optimus, permettre à nos utilisateurs d'importer un événement

dans leur agenda ou nos coordonnées dans leur carnet d 'adresses directement

depuis notre page web ? Personnellement, je trouve cela formidable.

Appelle-moi quand tu veux !Puisque notre site web de démonstration se consacre à un événement (un

stage de formation), nous pouvons commencer par adopter le microformat

hCalendar. Mais voyons d 'abord comment appliquer ce format hCard à mon

élément section dans l'élément article "Instructors". Passons en revue les

principales classes définies dans hCard.

14. La page Wiki des microformats (http://microformats.org/wiki/) propose la liste des

microformats avec la documentation d'utilisation.

15. http://kaply.com/weblog/operator/

16. http://visitmix.com/labs/oomph/

17. http://microformatique.com/optimus/

18. http://h2vx.com/

ADAPWEB.indb 27 17/04/13 12:47



CLAssE dEsCRipTiOnvcard Indique l'utilisation du microformat hCard. (Cette classe doit être la

classe de l'élément racine du contenu hCard.)

fn Abréviation de Formatted Name. Sert à englober le nom du proprié-

taire des données hCard.

url Indique qu'un lien guide l'utilisateur vers une page web décrivant la

personne concernée.

photo Dénote une photographie de la personne.

org Identifie l'entreprise ou l'organisation à laquelle appartient la

personne.

role Identifie la fonction de la personne dans l'entreprise/organisation.

Tableau 2.1 : Classes principales du microformat hCard.

Le microformat hCard compte bien d 'autres options de description du profil

d'un individu. Celles indiquées dans le tableau suffisent à nos besoins dans le

contexte de la page d'exemple Retreats 4 Geeks. Parmi ces cinq classes, seules

vcard et fn sont obligatoires.

Découvrons d 'abord le contenu sur lequel nous allons travailler :

<section id="aaron-gustafson"> <figure> <img src="i/aaron-gustafson.jpg" alt=""/> </figure>

<h1>Aaron Gustafson</h1> <p>Aaron has been working on the web for nearly 15 years and, in that time, has cultivated a love of web standards and an in-depth knowledge of website strategy and architecture, interface design, and numerous languages (including XHTML, CSS, JavaScript, and PHP). Aaron and his wife, Kelly, own <a rel="external" href="http://easy-designs.net">Easy! Designs</a>, a boutique web consultancy based in Chattanooga, TN. When not neck deep in code, Aaron is usually found evangelizing his findings and sharing his knowledge and passion with others in the field. </p>

ADAPWEB.indb 28 17/04/13 12:47



<p>Aaron has trained professionals at <cite>The New York Times</cite>, Gartner, and the US Environmental Protection Agency (among others), and has presented at the world's foremost web conferences, such as An Event Apart and Web Directions. He is Group Manager of the <a rel="external" href="http://webstandards.org"> Web Standards Project (WaSP)</a> and serves as an Invited Expert to the World Wide Web Consortium's <a rel="external" href="http://www.w3.org/2005/Incubator/owea/"> Open Web Education Alliance (OWEA)</a>. He created <a rel="external" href="http://ecsstender.org">eCSStender</a>, serves as Technical Editor for <a rel="external" href="http://alistapart.com"> <cite>A List Apart</cite></a>, is a contributing writer for <a rel="external" href="http://netmag.co.uk"> <cite>.net Magazine</cite></a>, and has filled a small library with his technical writing and editing credits. His next book, <cite>Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement</cite>, is due out in early 2011. </p> </section>

Vous constatez que l'élément section comprend un élément de titre h1. Ne

vous en inquiétez pas, car en HTML5, chaque section produit un nouveau

contexte dans lequel vous êtes autorisé à repartir du niveau de titre h1. Je

devine que cela va supposer un peu de temps pour vous y habituer, mais

c'est après tout très logique et cela permet bien de pallier le faible nombre de

niveaux de sous-titres19

.

Si vous avez bien étudié cet extrait, vous savez déjà à quel endroit doit être

placée chacune des classes de hCard. Je vais néanmoins les traiter une à une,

19. http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#sectioning-content

ADAPWEB.indb 29 17/04/13 12:47



à commencer par la plus simple, "vcard". Cette classification doit correspondre

à l'élément conteneur global, qui est ici l'élément section :

<section id="aaron-gustafson" class="vcard">

La classe suivante est celle qui va englober mon nom, donc "fn". Du fait que

mon nom est déjà indiqué comme contenu de l'élément de titre h1, nous

qualifions ce titre par la classe "fn" pour indiquer que le texte de l'élément

correspond à mon nom.

<h1 class="fn">Aaron Gustafson</h1>

Passons ensuite à la classe de l'adresse "url" menant à la page "Easy! Designs"

qui est un site web dont je détiens le contrôle :

... <a class="url" rel="external" href="http://easy-designs.net">Easy! Designs</a>, ...

En descendant, nous pouvons ensuite ajouter la classe "photo" à ma photo, qui

se trouve dans un élément figure, élément qui a été introduit dans HTML5

pour héberger un contenu non fractionnable, tel qu'une image ou un dessin

avec un titre en option (figcaption). Cet élément doit pouvoir être supprimé

du document sans en altérer le sens :

<figure> <img class="photo" src="i/aaron-gustafson.jpg" alt=""/></figure>

Il nous reste à insérer les deux classes "org" et "role" dans le dernier paragraphe

de ma biographie, mais un problème se pose. Plusieurs entreprises et organi-

sations sont citées. Laquelle choisir ? Et peut-on en mentionner plusieurs ?

Rien dans le microformat hCard n'interdit de désigner plusieurs entités et

plusieurs fonctions dans la même fiche hCard, mais en pratique rares sont

les analyseurs de microformats qui vont chercher plus loin que la première

occurrence rencontrée. En effet, les logiciels de gestion de carnet d 'adresses

ne savent souvent pas gérer plusieurs employeurs et plusieurs fonctions pour la

même personne. Pour simplifier, nous allons associer ces classes à ma première

fonction, celle de chef de groupe du projet des standards web (Group Manager/

Web Standards Project).

La classe "org" est facile à implanter, car la donnée "Web Standards Project"

est déjà dans un élément. En revanche, ma fonction est indiquée dans un

texte plus long sans être marquée par un élément spécifique. Pour ne cerner

ADAPWEB.indb 30 17/04/13 12:47



que mon premier rôle avec cette classe, nous allons ajouter un élément sans

signification sémantique comme b20 :

... He is <b class="role">Group Manager</b> of the <a class="org" href="http://webstandards.org">Web Standards Project (WaSP)</a> ...

Si nous regardons maintenant le résultat global, vous pouvez constater que les

aménagements liés au microformat hCard sont en fait assez limités :

<section id="aaron-gustafson" class="vcard"> <figure> <img class="photo" src="/events/2011/html5- css3/i/aaron-gustafson.jpg" alt=""/> </figure> <h1 class="fn">Aaron Gustafson</h1> <p>... Aaron and his wife, Kelly, own <a class="url" rel="external" href="http://easy-designs. net">Easy! Designs</a> ...</p> <p>... He is <b class="role">Group Manager</b> of the <a class="org" rel="external" href="http:// webstandards.org">Web Standards Project (WaSP)</a> ...</p> </section>

Pourtant, ces quelques ajouts permettent dorénavant de faire produire assez

aisément un profil de ma personne par un analyseur de microformats.

20. Et pourquoi l'élément b ? Pourquoi pas span ? En HTML5, l'élément b a été remis à

l'honneur pour englober une séquence de texte devant se démarquer visuellement du

reste du paragraphe sans pour autant prendre une importance particulière. Rien ne vous

empêche d'utiliser l'élément span, mais b est plus approprié et plus bref.

ADAPWEB.indb 31 17/04/13 12:47



Figure 2.3 : Informations de profil extraites d'une page web avec l'outil

Operator.

Un grand intérêt des microformats est que vous avez toute latitude dans la

manière de les utiliser. Les noms de classes ne doivent pas nécessairement

survenir dans un ordre précis (mais ils doivent être insérés dans un élément

parent de la classe appropriée) et leur contenu ne doit pas obligatoirement

correspondre à un format d'exportation prédéfini. Comme notre exemple

le montre, le microformat hCard ne doit pas même être marqué dans une

même partie comme une entrée d 'annuaire ; vous pouvez en distribuer les

ADAPWEB.indb 32 17/04/13 12:47



composants dans votre prose à la seule condition d'employer les noms class

appropriés pour désigner vos classes.

notez-le sur vos tablettes !Une fois les données pour hCard gérées, nous pouvons passer au microformat

hCalendar présenté plus haut. Avant de procéder au marquage, découvrons

quelques classes de hCalendar parmi les plus usitées.

CLAssE dEsCRipTiOnvevent Indique l'utilisation du microformat hCalendar pour un évé-

nement. (Cette classe doit être la classe de l'élément racine du

contenu hCalendar.)

dtstart Désigne la date de début de l'événement.

dtend Désigne la date de fin de l'événement.

summary Désigne le nom de l'événement.

location Désigne le lieu de déroulement de l'événement.

description Fournit des détails sur l'événement.

Tableau 2.2 : Classes principales du microformat hCalendar.

Puisque toute la page d'exemple est dédiée à l'annonce d'un événement, notre

processus d'injection de classes doit commencer plus haut dans l'arbores-

cence DOM. J'ai choisi de commencer au niveau du conteneur de contenu

(div#content), auquel j'ai associé la classe racine "vevent". Plus loin, le contenu

pour hCalendar sera englobé dans article#details. En appliquant ainsi la

classe principale à un élément ancestral, nous disposons de toute la souplesse

pour ajouter d 'autres propriétés hCalendar dans d 'autres éléments article :

<div id="content" class="vevent">

J'ai mentionné que le premier élément (article#details) devait contenir les

principales données de l'événement. Commençons par revoir le code source

dans son état avant application des classes de hCalendar :

<article id="details"> <header>

<h1>Join us for HTML5 & CSS3</h1>

ADAPWEB.indb 33 17/04/13 12:47

<p>8–10 April 2011</p> <p>Gatlinburg, <abbr title="Tennessee">TN</abbr></p> </header>

<figure> <img src="i/mountains.jpg" alt=""/> </figure> <section class="main">  </section>

</article>

Ce rapide survol a sans doute suffi pour repérer les points d'injection de la

plupart des classes hCalendar. Nous pouvons sur le champ insérer la balise

pour le nom de l'événement, c'est-à-dire le sommaire "summary" en dialecte

hCalendar :

<h1>Join us for <b class="summary">HTML5 & CSS3</b></h1>

Si nous progressons dans le code source, nous arrivons à la plage de dates

"8-10 April 2011". De façon traditionnelle, nous aurions utilisé des éléments

d'abréviation (abbr) pour marquer ces données, mais le HTML5 a introduit un

élément dédié au marquage d'une donnée temporelle qui se nomme time. Le

problème est que pour dénoter une date de début et une date de fin, il va falloir

diviser le contenu actuel en deux pour pouvoir définir deux éléments time.

Même si cela paraît étranger de prime abord, le plus logique consiste à englober

le seul chiffre "8" dans un premier élément time et la date complète "10 April

2011" dans le second. En effet, nous supposons que ce chiffre "8" isolé est

à comprendre comme le "8 avril 2011" sous forme abrégée (c'est pourquoi

l'élément abbr était approprié auparavant). L'élément time permet de gérer les

dates plus finement avec son attribut datetime. C'est ainsi que j'ai reformulé

la date de début en entier :

<p><time datetime="2011-04-08">8</time>–<time datetime="2011-04-10">10 April 2011</time></p>

ADAPWEB.indb 34 17/04/13 12:47

Les seules classes obligatoires dans hCalendar sont "summary" et la date de

début. Il suffirait donc d 'appliquer la classe "dtstart" au premier élément time

pour que le microformat soit valide. Mais puisque nous disposons d'une date

de fin, définissons cette autre classe dans la foulée21

:

<p><time class="dtstart" datetime="2011-04-08">8</time>–<time class="dtend" datetime="2011-04-10">10 April 2011</time></p>

Avançons un peu dans le contenu. Nous pouvons facilement coder le lieu de

l'événement avec "location" puisque le stage se déroule à Gatlinburg, TN :

<p class="location">Gatlinburg, <abbr title="Tennessee">TN</abbr></p>

Le dernier morceau de notre puzzle hCalendar correspond à la "description".

Le meilleur candidat pour le contenu de cet élément est la section principale

"main" de l'article :

<section class="main description"> </section>

Et voilà tout. Une fois les éléments du microformat en place, l'utilisateur peut

très facilement extraire l'événement et l'injecter dans son agenda.

21. Au moment où nous mettons sous presse, certains analyseurs de microformats ont des

soucis avec les nouveaux éléments et attributs du HTML5. C'est pour cette raison qu'il

est avisé de dupliquer la valeur de l'attribut datetime dans un titre de l'élément time ou

d'utiliser un élément title sur un élément abbr.

ADAPWEB.indb 35 17/04/13 12:47



Figure 2.4 : Informations extraites de ce code source avec l'outil Operator.

Ce second exemple pratique de microformat montre comment vous pouvez

directement enrichir un marquage déjà significatif afin d'améliorer le service

offert à l'utilisateur. De l'amélioration progressive bien comprise !

ADAPWEB.indb 36 17/04/13 12:47



RiEn dE TEL QUE dE bOnnEs bAsEsLe concept d 'amélioration progressive est souvent présenté en relation avec

le CSS et le JavaScript, mais il concerne tout autant le marquage HTML.

Comme ce chapitre l'a montré, chaque fois que nous avons ajouté un élément

significatif, nous avons augmenté la pertinence de la page en renforçant son

accessibilité et en la rendant plus facile à trouver par les utilisateurs grâce à

son meilleur statut dans les recherches organiques. Nous avons également

vu comment la classification et l'identification pouvaient rendre le langage

HTML encore plus expressif. Enfin, avec les microformats, nous avons vu

qu'en choisissant des noms, nous augmentions la densité sémantique et la

praticité du contenu ainsi marqué.

Le marquage sémantique est une étape essentielle dans l'approche d 'amé-

lioration progressive ; combiné à des contenus bien formés, il constitue la

fondation sur laquelle se construisent les éléments d'une expérience utilisateur

de qualité.

ADAPWEB.indb 37 17/04/13 12:47


"Le design est l'esprit même

d'une création humaine qui

s'exprime dans chacune

des couches successives qui

habillent le produit ou le

service."

— sTEvE JObs

ADAPWEB.indb 38 17/04/13 12:47


CHApiTRE 3

AMÉLIORATION PROGRESSIVE AVEC LE CSSSi l'on met de côté les quelques sites endormis qui se fondent encore sur des

éléments font et des images GIF d'écartement, le design web est dorénavant

mis en forme grâce aux styles CSS (Cascading Style Sheets). Bien sûr, vous

disposez aussi des techniques fondées sur Flash, SVG et canvas, mais si vous

voulez donner à vos contenus les meilleures disponibilité et accessibilité, vous

utilisez le HTML pour marquer le contenu et le CSS pour lui appliquer des

styles visuels.

Comme le HTML, le CSS est dès l'origine prévu pour être tolérant aux

pannes : un navigateur qui ne comprend pas une règle de style l'ignore et

poursuit son travail1 2

. En tenant compte de la façon dont le CSS a évolué,

nous pouvons facilement adopter le principe d'amélioration progressive en

tirant profit de cette tolérance pour créer des strates appropriées aux capacités

des différentes générations de navigateurs.

1. http://www.w3.org/TR/2009/CR-CSS2-20090908/syndata.html#parsing-errors

2. http://www.w3.org/TR/2009/CR-CSS2-20090908/syndata.html#unsupported-values

ADAPWEB.indb 39 17/04/13 12:47



CERTAinEs ERREURs sOnT sALUTAiREsCeci n'étant pas un livre sur le langage CSS, je ne vais pas passer en revue

toutes les options qu'il permet, mais me contenter d'un bref survol du fonction-

nement de CSS, car je pense que cela vous dotera d'une profondeur de vue

utile pour comprendre comment construire des architectures de sites à amélio-

ration progressive.

Fondamentalement, le CSS est une collection de jeux de règles lisibles par

les humains. Chaque règle est composée d'un sélecteur et d'un bloc déclaratif

regroupant une série de couples propriété-attribut (des déclarations), qui seront

appliqués à tout élément correspondant au sélecteur.

p { color: red; font-weight: bold;}

L'exemple précédent est du CSS élémentaire. Toute personne qui a utilisé

le CSS (et sans doute même la plupart de ceux ne l'ayant jamais utilisé)

peuvent à la simple lecture deviner que cette règle sert à sélectionner certains

paragraphes, puis à forcer leur texte à apparaître en gras et en rouge. Mais si

nous considérons le même exemple sous l'angle de la tolérance aux pannes,

les choses sont moins simples.

Lorsqu'un navigateur scrute un fichier CSS pour savoir comment afficher une

page, il lit chaque règle tour à tour et tente de l'interpréter. S'il lit une règle

qu'il ne sait pas gérer, cela déclenche une erreur d'analyse (parsing error). La

plupart de ces erreurs résultent d'une mauvaise rédaction de la règle CSS

(nom de propriété ou valeur mal écrite, signe de ponctuation manquant, etc.),

mais certaines, bien que conformes à la syntaxe du CSS, ne sont pas compré-

hensibles par l'analyseur.

En supposant que tous les signes de ponctuation sont en place (accolades,

points-virgules et deux-points), l'exemple précédent peut subir une erreur

d'analyse en cinq endroits :

ADAPWEB.indb 40 17/04/13 12:47


CHApiTRE 3 AMÉLiORATiOn pROgREssivE AvEC LE Css 41

p { color: red; font-weight: bold; }

1 2 3

4 5

1. Sélecteur : p

2. Nom de la première propriété : color

3. Valeur de la première propriété : "red"

4. Nom de la deuxième propriété : font-weight

5. Valeur de la deuxième propriété : "bold"

D'après la spécification, en cas d'erreur d'analyse de son analyseur, le

navigateur doit ignorer le composant de niveau supérieur de la règle dans

laquelle s'est produite l'erreur.

En supposant que le navigateur ne sait pas ce que signifie le mot clé CSS de

choix de couleur "red", il ignorera la déclaration color: red, mais appliquera

les autres (s'il les comprend). Il en va de même pour le mot clé de graissage

de font-weight nommé "bold". En revanche, si le navigateur ne comprend

pas le sélecteur (p), il ignorera tout le bloc de règles, même si les déclarations

individuelles qu'il contient sont de celles qu'il peut interpréter.

Le principe, très simple, est le suivant : personne ne pouvant prédire le futur de

la norme CSS, il est indispensable que les navigateurs ignorent les déclarations

et sélecteurs dont ils ne savent que faire. Comme en HTML, cela favorise

l'évolution du langage et permet d'appliquer l'amélioration progressive aux

pages web avec les styles CSS.

En ce qui concerne les propriétés, exploiter les erreurs d'analyse à votre profit

est assez simple et cela vous ouvre quelques possibilités étonnantes. Voici un

petit exemple d'utilisation du schéma de couleur RGBa de CSS3 :

p { background-color: rgb(137, 224, 160); background-color: rgba(180, 246, 248, .43);}

Un navigateur lisant cette règle va normalement comprendre le sélecteur

(le sélecteur de paragraphe courant p est le plus universel de tous), et donc

s'aventurer dans les détails du bloc pour tomber sur la première déclaration

ADAPWEB.indb 41 17/04/13 12:47



background-color. Cette propriété de couleur de fond de texte existe dans la

norme CSS depuis la version 1 ; le navigateur va donc la comprendre et ira

en lire la valeur. Justement, les codes de couleurs RGB font aussi partie de

la norme CSS depuis le début, et le navigateur saura quoi en faire. Puisque

tout s'est bien passé, l'analyseur transmet la règle au navigateur qui applique

background-color: rgb(137, 224, 160); à tous les paragraphes de texte

concernés. L'analyseur attaque ensuite la seconde règle.

Dans la seconde déclaration, la même propriété background-color est

redéfinie avec une nouvelle valeur (mécanisme de cascade). Nous savons

déjà que le navigateur comprend la propriété. Il va donc lire la valeur, qui

utilise la convention de codage RGBa. Si le navigateur la comprend, la valeur

est transmise à la propriété background-color en remplacement de la précé-

dente valeur RGB. En revanche, si RGBa n'est pas géré, une erreur d'analyse

survient et le navigateur ignore toute la déclaration. Le texte concerné sera

traité avec la valeur RGB pour background-color.

Bien sûr, si le navigateur gère la convention RGBa, il remplace la valeur de

background-color en conformité avec le mécanisme de "cascade" (premier C

de l'acronyme CSS). Je vais revenir plus en détail sur ce mécanisme dans la

suit du chapitre, mais voici sa règle de base : pour deux propriétés équivalentes

(ou identiques) la dernière définition prime.

Cette démonstration simple permet de voir comment on peut utiliser la

nature tolérante du CSS pour incorporer sans crainte des possibilités plus

sophistiquées que sauront exploiter les navigateurs les plus capables. Mais ce

mécanisme n'est pas limité au niveau des déclarations. Vous pouvez l'appliquer

pour masquer tout un groupe de jeux de règles au moyen d'un sélecteur plus

sélectif :

html[lang] p { /* Ici vient un bloc de règles très modernes */}

Un navigateur qui rencontre ce jeu de règles commence par évaluer le sélecteur.

Si le navigateur sait gérer les sélecteurs basés attribut (dans l'exemple, nous

désignons tous les paragraphes qui dépendent d'un élément html possédant un

attribut de langage), il va entrer dans les détails des règles pour appliquer les

déclarations qu'il sait gérer. Mais si le navigateur ne connaît pas les sélecteurs

complexes, l'erreur d'analyse fait ignorer tout le jeu de règles.

ADAPWEB.indb 42 17/04/13 12:47



Un exemple assez fameux d'emploi de cette technique de distribution sélective

de règles selon les capacités du navigateur (plutôt à titre d'illustration que

pour son effet pratique) est la page du jardin CSS Zen Garden d'Egor Kloos

intitulée "Gemination"3.

Figure 3.1 : La page Gemination dans IE6 (en haut) et dans IE7 (en bas).

Dans ce cas d'école, Egor Kloos a conçu une structure visuelle de base

destinée à la version 6 d'Internet Explorer et adopté la technique MOSe

3. http://www.csszengarden.com/062/

ADAPWEB.indb 43 17/04/13 12:47



("Mozilla/Opera/Safari enhancement")4 pour permettre aux navigateurs plus

récents de fournir un rendu visuel très différent.

Kloos s'est servi de quelques sélecteurs élémentaires pour la mise en pages

de base et d'autres sélecteurs plus complexes pour les styles évolués. Voici un

extrait de sa technique :

#intro { margin: 0; padding: 0; width: 660px; height: 80px; background: transparent url(introkop.gif) no-repeat right top;}

/* ... */

body[id=css-zen-garden] #intro { position: absolute; top: 0; left: 0; float: none; margin: 0; width: 100%; height: 350px; background: none;}

Suivant l'ordre des cascades successives, le navigateur gère d'abord la première

règle pour afficher la partie #intro. Il arrive ensuite à la règle plus évoluée du

même #intro. Si le navigateur sait gérer les sélecteurs à attribut (qualifiés),

le rendu de #intro va être radicalement changé. Dans le cas contraire, il ne

change pas.

Ce filtrage fondé sur les sélecteurs constitue une technique intéressante, mais

perturbe les auteurs de code CSS qui oublient que l'échec d'un tel sélecteur

composite (au moins deux instructions de sélection séparées par des virgules)

est total : tout le bloc de règles est ignoré :

4. Dave Shea, le mainteneur actuel du site CSS Zen Garden, avait introduit l'expression

en 2003, mais à l'arrivée d'Internet Explorer 7, il est tombé dans l'oubli parce que cette

nouvelle version ne souffrait pas des limitations de IE6 au niveau des sélecteurs. Le texte

original est disponible à l'adresse http://www.mezzoblue.com/archives/2003/06/25/mose/.

ADAPWEB.indb 44 17/04/13 12:47



p,p:not([title]) { color: red; font-style: bold;}

Dans l'extrait précédent, nous retrouvons les cinq causes d'erreur possibles vues

plus haut, et une cause de plus dans le deuxième sélecteur (p:not([title])).

Un navigateur qui ne comprend qu'un des deux sélecteurs (le p est universel)

va ignorer la totalité du jeu de règles et non seulement la variante qui cible les

seuls paragraphes de texte ne possédant pas l'attribut title.

Vous pourrez trouver ce choix illogique, mais c'est exactement ainsi que la

norme CSS 2.1 demande de procéder : "Toute l'instruction doit être ignorée

en cas d'erreur n'importe où dans le sélecteur, quand bien même la suite

du sélecteur semblerait exploitable"5. Lorsque vous savez cela, vous pouvez

prendre de meilleures décisions pour combiner les sélecteurs. Une règle globale

consiste à ne pas combiner des sélecteurs complexes avec des sélecteurs simples

(ce qui a été fait dans le précédent exemple), sauf si vous voulez que tous les

jeux de règles ainsi délimités deviennent inaccessibles aux anciens navigateurs.

Nous reviendrons dans quelques paragraphes à cette technique, mais après

ce bref détour du côté de la spécificité.

Le concept de spécificité est un autre concept majeur de CSS. Il détermine

le nombre d'éléments pouvant être sélectionnés par le même sélecteur. C'est

la seule technique qui permette d'outrepasser le mécanisme de cascade (nous

y revenons). Certains sélecteurs sont plus sélectifs que d'autres : un sélecteur

d'identifiant comme #intro est dix fois plus spécifique qu'un sélecteur de classe

comme vcard, lui-même plus précis qu'un sélecteur d'élément comme p)6.

L' évaluation de la spécificité d'un sélecteur est la somme des spécificités de

tous ses composants. Une règle dépendant d'un sélecteur spécifique aura

toujours priorité sur une règle liée à un sélecteur plus large, quel que soit

leur ordre d'apparition dans la cascade. Nous l'avons vu avec le sélecteur

d'attribut très futé du site d'Egor Kloos : la règle la moins spécifique apparaît

en dernier dans le fichier CSS, mais sa priorité reste inférieure à la première,

qui est donc celle appliquée.

5. http://www.w3.org/TR/2009/CR-CSS2-20090908/syndata.html#rule-sets

6. Pour en savoir plus sur l'évaluation du niveau de spécificité, vous pouvez consulter l'article

d'Andy Clarke "CSS Specificity Wars" (http://www.stuffandnonsense.co.uk/archives/

css_specificity_wars.html).

ADAPWEB.indb 45 17/04/13 12:47



Il faut du temps pour bien maîtriser ce concept de spécificité des sélecteurs.

Prévoyez quelques maux de tête si vous décidez d'appliquer tous vos styles

en relation avec des sélecteurs très pointus (avec un sélecteur à identifiant

pour chaque style). En effet, vous serez parfois forcé de définir des sélecteurs

encore plus spécifiques, combinant deux identifiants. Pour vous épargner de

déclencher une course à la spécificité, je vous conseille de vous retenir de

rendre vos sélecteurs trop spécifiques sans raison impérieuse.

Revenons au code d'Egor Kloos. Appliquons ce que nous venons d'apprendre

au niveau des erreurs d'analyse dans les sélecteurs combinés ; l'objectif sera

de réduire la spécificité des jeux de règles sophistiquées d'Egor sans perdre

l'esprit de son travail :

#intro { /* Ancienne présentation */}

/* ... */[foo], #intro { /* Nouvelle présentation évoluée */}

Dans cette reformulation, j'ai modifié le second jeu de règles en indiquant un

sélecteur combiné qui cible un élément possédant un attribut nommé foo et un

autre avec un identifiant nommé intro. L'astuce est que le premier sélecteur

(celui à attribut) est un leurre. Le nom d'attribut foo est non seulement non

standard, mais il n'est utilisé nulle part dans le code HTML de la page CSS

Zen Garden. L'ajout de ce sélecteur a pour seul effet de rendre le jeu de règles

invisible à tous les navigateurs qui ne savent pas gérer les sélecteurs à attributs.

Le point le plus important est que cette redéfinition ne modifie en rien l'impact

du sélecteur #intro : sa spécificité est la même qu'auparavant, ce qui garantit

que le mécanisme de cascade continue à déterminer l'application des styles.

Cette technique évoluée n'est sans doute pas celle que vous allez adopter

systématiquement en CSS, mais il sera utile de vous en souvenir lorsque

vous voudrez filtrer des jeux de règles sans altérer la spécificité d'un sélecteur.

En termes de maintenance, cette technique est déconseillée pour plus d'une

règle de temps à autre. Il existe d'autres méthodes pour effectuer du filtrage

en masse, et nous les découvrirons bientôt.

ADAPWEB.indb 46 17/04/13 12:47



divisER pOUR biEn RÉgnERLe mécanisme de "cascade" est un concept stratégique de CSS, nous l'avons

dit – comme nous avons déjà précisé que ce livre n'offrait pas de place pour

un rappel exhaustif du concept de cascade. Cependant, un point peut vous

permettre de devenir rapidement un expert en amélioration progressive :

l'ordre.

L'ordre compte, beaucoup.

Toutes choses égales par ailleurs en termes de spécificité, le résultat d'une

règle CSS dépend de la proximité entre la déclaration de style et son élément

cible. Nous avions vu ce point dans l'exemple qui réalisait deux affectations

de couleur de fond background-color. Il en va de même au niveau supérieur

de deux jeux de règles :

h1 { font-size: 2em;}

h1 { font-size: 3em;}

Cet exemple va affecter une valeur de 3em à la propriété font-size de tous

les éléments h1. Ce cas d'école définissant un second jeu de règles avec le

même sélecteur juste après le premier ne se rencontrera pas souvent, mais

quelque chose du même genre est moins rare. Prenons comme exemple les

images de l'élément article relatif à l'hébergement (nommé "Lodging") du site

de démonstration Retreats 4 Geeks :

ADAPWEB.indb 47 17/04/13 12:47

Figure 3.2 : Rendu de l'article Lodging.

Voici le code source HTML de cet article :

<article id="lodging"> <header> <h1>Where You’ll Stay</h1> </header> <figure class="frame focal"> <img class="inner" src="i/lodge.jpg" alt="" title="..."/> </figure> <section class="main">  </section> <aside class="extra"> <ul class="gallery"> <li> <figure class="frame"> <img class="inner" src="i/room.jpg" alt="" title="..."/>

ADAPWEB.indb 48 17/04/13 12:47

</figure> </li>  </ul> </aside> </article>

Vous remarquez que cet élément article définit la même valeur "frame" de

class pour chaque élément figure pour garantir la cohérence dans l'aspect

des contours d'image. L' image principale a reçu un complément de valeur

s'écrivant "focal". Cela permet d'appliquer deux règles CSS différentes de

même spécificité afin d'affecter les styles appropriés à figure.focal. Voici un

exemple de définition de règles avec une redéfinition :

.frame { margin: 0 auto 40px;}

.focal { margin: 0 20px 25px 30px;}

Ces deux jeux de règles s'appliquent à l'élément figure de l'image principale

de cet élément article (et de tous les autres éléments de même nom de la

page). Les deux sélecteurs ont la même spécificité, mais puisque le second jeu

redéfinit la propriété du premier, la valeur de la propriété margin de l'image

principale (celle sélectionnée par "focal") sera de "0 20px 25px 30px" au lieu

de "0 auto 40px."

Dans la pratique, les feuilles de styles contiennent souvent des centaines

de jeux de règles. Il devient alors facile de se faire piéger par les effets de la

proximité. Pour nous en prémunir, nous pouvons adopter une approche par

couches dans la conception CSS.

Si nous revenons un peu en arrière, nous constatons que le design d'un site

web comporte trois aspects majeurs : la typographie, les couleurs et la mise

en page. Chacun de ces aspects apporte quelque chose, participant ainsi au

résultat final. Pour ce qui concerne l'amélioration progressive en relation avec

le CSS, nous pouvons adopter la même répartition en plusieurs niveaux de

support bien distincts, en correspondance avec les capacités des navigateurs :

la typographie, puis la typographie avec des couleurs, et enfin, la typographie

avec des couleurs et une mise en page sophistiquée.

ADAPWEB.indb 49 17/04/13 12:47



Nous avons dit que l'ordre d'apparition des règles a son importance. Pour

concevoir de façon progressive, nous devons confronter notre désir de

distribuer les niveaux de conception à la logique de l'interprétation en cascade

de nos règles. D'un point de vue pratique, cela suppose d'édicter les groupes de

déclarations d'un même niveau dans un ordre défini : d'abord la typographie,

puis la mise en page et enfin les couleurs. Pourquoi dans cet ordre ? Nous y

reviendrons très bientôt.

Vous pouvez définir ces jeux de règles dans des fichiers de feuilles de styles

différents (importés ou liés) ou dans un seul gros fichier7. L'approche multi-

fichiers est facile à gérer et logique, mais elle a un coût en performances : il

faut rapatrier chaque feuille de styles dans une requête HTTP distincte. De

plus, certains navigateurs ne savent pas garder en cache local plus d'un niveau

de feuille de styles dans le sens descendant (celui d'une feuille importée dans

une autre). C'est la raison pour laquelle je trouve l'approche mono-fichier plus

sensée ; c'est celle adoptée pour le site de démonstration Retreats 4 Geeks.

Illustrons cette approche par niveaux de définition des styles en commençant

par la situation la plus simple : sans aucun style. La Figure 3.3 montre l'aspect

de la section sur l'hébergement (lodging) dans Safari. Seuls les styles par défaut

du navigateur sont appliqués.

7. Opter pour un fichier de feuilles de styles unique ne vous empêche pas de répartir les

règles dans plusieurs fichiers CSS. Il existe plusieurs outils du côté serveur pour combiner

des fichiers CSS en un seul. Vous profitez ainsi des deux avantages : vous importez les

fichiers de détails de style dans un fichier squelette destiné à les accueillir, fichier que

vous transmettez aux clients lors de leurs requêtes. Vous trouverez un exemple à l'adresse

http://www.easy-reader.net/archives/2010/07/11/template-based-asset-munging-in-expressionengine.

ADAPWEB.indb 50 17/04/13 12:47

lalchimiste

Highlight

lalchimiste

Highlight



Figure 3.3 : "Lodging" sans CSS.

Vous constatez que le contenu est tout à fait utilisable avec ces styles implicites.

L'apparence n'est pas sophistiquée, mais tout le contenu est lisible. En ajoutant

un niveau de règles typographiques, nous arrivons à l'aspect de la Figure 3.4.

ADAPWEB.indb 51 17/04/13 12:47



Figure 3.4 : "Lodging" agrémenté de styles typographiques.

L'amélioration est limitée, mais pas négligeable. Les navigateurs qui ont des

soucis dans le rendu des styles de mise en page CSS disposent ainsi d'un

niveau intermédiaire, ce qui est plus agréable pour les utilisateurs de ces

navigateurs que les forcer de subir les inconvénients d'une tentative de rendu

incomplète.

Le niveau suivant de support des styles est celui de la couleur. C'est celui qui

est en général accessible aux navigateurs en même temps que la typographie

de base (dans certains cas, cela va jusqu'aux images de fond). La Figure 3.5

montre la même page web avec les légers enrichissements apportés par la mise

en couleur du même article.

ADAPWEB.indb 52 17/04/13 12:47



Figure 3.5 : "Lodging" agrémenté de couleurs.

Nous sommes clairement dans un processus d'amélioration progressive.

Le dernier niveau d'application de styles qui nous intéresse ici est celui du

contrôle global de la disposition des éléments sur la page. Son résultat a été

montré quelques pages plus haut dans la Figure 3.2.

J'ai dit que tous ces niveaux seront définis dans le même fichier que j'ai

structuré en trois sections. Voici l'extrait des styles applicables aux images

de l'article "Lodging" :

/* =Typographie */img { display:block;}

/* =Mise en page */@media screen { .frame .inner { border: 10px solid; }}

ADAPWEB.indb 53 17/04/13 12:47



/* =Couleurs */.frame .inner { background-color: rgb(227, 222, 215); border-color: rgb(227, 222, 215);}

Vous avez certainement noté la présence du bloc @media qui englobe les règles

de style pour affichage sur écran. Cet élément n'est pas présent fortuitement :

il garantit que tous les clients profiteront des jeux de règles concernant la

typographie et les couleurs en isolant celles de l'affichage aux seuls navigateurs

qui savent gérer le type de média "screen". Le même principe est facilement

extensible aux impressions ou à tout autre média, mais nous verrons cela

plus loin.

L' élément @media a un autre avantage : les navigateurs vraiment anciens

(par exemple, Netscape 4) ne le comprenant pas, ils ignorent ce bloc et nos

styles de mise en page leur restent invisibles. Ces navigateurs profitent donc

sans perturbation des règles de typographie et même, pour la plupart d'entre

eux, de celles des couleurs.

Revenons à une question laissée en suspens : pourquoi ai-je relégué les règles

de couleurs en dernier ? Mon raisonnement est simple. J'adore les raccourcis

CSS qui permettent de combiner plusieurs règles en une seule. Nous en

avons rencontré une plus haut : border: 10px solid. Cette écriture abrégée

équivaut aux quatre lignes suivantes :

border-top: 10px solid;border-right: 10px solid;border-bottom: 10px solid;border-left: 10px solid;

Ce n'est pas tout. Chacune des ces déclarations est elle-même une version

raccourcie. Par exemple, border-top: 10px solid équivaut aux trois lignes

suivantes :

border-top-width: 10px;border-top-style: solid;border-top-color: inherit;

Vous voyez que les raccourcis CSS réduisent fortement la complexité des

feuilles de styles CSS.

Supposons que dans le précédent exemple, les jeux de règles pour les couleurs

aient été placés avant celles de mise en page. L'attribut border-color aurait

reçu la valeur gris clair, mais le raccourci border qui arrive après dans les

ADAPWEB.indb 54 17/04/13 12:47



règles de mise en page aurait annulé la valeur de border-color, parce que

la spécificité du jeu de règles est la même et que border redéfinit toujours

border-color, même de façon implicite (la valeur par défaut est "inherit", ce

qui entraîne la réutilisation de la couleur en vigueur pour le texte). Voici

pourquoi je conseille de placer les règles de couleurs en dernier. Les raccourcis

CSS sont très pratiques. Ils allègent l'écriture des jeux de règles et réduisent

la longueur du fichier, mais vous devez bien contrôler l'ordre dans lequel vous

les faites appliquer.

Puisque nous en sommes aux couleurs, j'en profite pour ajouter que dans

certains cas, vous voudrez utiliser la couleur dans un contexte spécifique à

la mise en page (par exemple pour une couleur de fond). Dans ce cas, il peut

être intéressant d'isoler une sous-section de vos règles avec @media, comme

nous l'avons fait pour tout le bloc de mise en page :

/* =Couleur */.frame .inner { /* Couleurs pour tous les médias */}

@media screen { .frame .inner { /* Couleurs spécifiques aux écrans */ }}

En partant des bases saines de notre infrastructure stratifiée, il devient très

simple d'ajouter des modules en fonction des besoins. Voici des exemples

d'effets (de style) :

/* =Couleurs */a:link, a:visited { color: rgb(180, 49, 25);}

a:hover { color: rgb(235, 123, 35);}/* ... */

/* =Effets */@media screen { a { transition-duration: .5s; }}

ADAPWEB.indb 55 17/04/13 12:47



Vous disposez maintenant d'une bonne connaissance des techniques

permettant d'exploiter le mécanisme de tolérance aux pannes de CSS pour

améliorer la qualité de la navigation. Nous pouvons donc aller plus loin en

ajoutant une autre couche d'enrichissements.

pETiT QUipROQUO, gRAnds EFFETsDe par sa tolérance aux pannes, le CSS est un complément presque idéal à

la panoplie des outils d'amélioration progressive. L' ignorance est souvent un

bien parce qu'elle nous permet de bien exploiter les nouveautés fonctionnelles

et syntactiques sans craindre de perturber les navigateurs qui ne suivent pas

la cadence. Mais que se passe t-il lorsqu'un navigateur croit qu'il comprend

une règle, mais qu'il la comprend mal ? Oui, je veux bien sûr parler d'Internet

Explorer.

IE9 a été lancé lorsque ce livre partait chez l'imprimeur. De ce que j'ai pu en

voir, il semble que ses auteurs ont bien répondu à leur promesse de conformité

aux standards (y compris le CSS), d'une manière totalement interopérable.

IE8 n'était pas non plus en retard par rapport à CSS, mais si vous repensez à

IE7 et (frisson) à IE6, les choses deviennent franchement sombres.

Fort heureusement, les brillants individus de Microsoft nous avaient concocté

une technique permettant d'isoler facilement les sections spécifiques à leurs

navigateurs dans le code CSS, JavaScript et même dans le marquage HTML :

les commentaires conditionnels8. Il s'agit exactement de ce à quoi vous pourriez

vous attendre : des commentaires HTML dans un format spécial qui sont pris

en compte par IE, mais ignorés par tous les autres navigateurs (après tout, ce

sont des commentaires).

Les commentaires conditionnels cadrent bien avec l'approche d'amélioration

progressive. En effet, même si l'amélioration progressive n'est pas directement

dépendante du type de navigateur, certains navigateurs ont besoin qu'on les

aide un peu à répondre aux attentes des utilisateurs. Les commentaires condi-

tionnels permettent aux concepteurs de cibler une ou plusieurs versions d'IE.

En voici un court exemple d'utilisation :

8. http://msdn.microsoft.com/en-us/library/ms537512(VS.85).aspx

ADAPWEB.indb 56 17/04/13 12:47



QUiTTER LA bAsELe réseau web forme une vraie rupture par rapport aux supports d'infor-

mation que nous connaissions jusque-là. Ce n'est pas un nouveau médium

imprimé, ni de la télévision, ni de la radio, ni un jeu vidéo, un kiosque ou une

application, mais un hybride de tous ces médias – et plus encore. Devant ce

constat, l'organisme de normalisation W3C a défini des possibilités de cibler

un média en particulier. Nous en avons profité plus haut dans le bloc @media,

mais vous êtes sans doute plus habitué à vous servir de déclarations media avec

des feuilles de styles liées ou imbriquées (grâce à l'attribut media) ou en tant

que suffixe des instructions @import.

C'est le W3C qui est le gardien de la liste des types de médias officielle, mais

il n'est pas réfractaire à l'enrichir en réponse aux évolutions technologiques.

Pour le moment, cette liste officielle normalise l'application de styles CSS aux

médias suivants : écran d'ordinateur, imprimé, télévisions, terminaux portables,

et dans les contextes des assistants d'accessibilité tels que les lecteurs d'écrans,

les imprimantes de braille, et les appareils à retour de force. En l'absence

d'indication de média cible, le choix implicite est l'écran d'ordinateur, "screen".

Au départ, les désignations de médias cibles sont univoques, mais comme avec

les sélecteurs, vous pouvez combiner plusieurs noms de médias en les séparant

par des virgules (la virgule a l'effet d'un OU logique). Dans l'exemple qui suit,

le fichier main.css sera appliqué aux deux types de médias "print" et "screen" :

<link rel="stylesheet" href="main.css" media="screen, print"/>

Les désignations de médias sont tolérantes aux pannes, mais le mécanisme

de tolérance est assez différent de celui qui s'applique aux sélecteurs (n'en

redoutez aucune confusion) : face à un type de média inconnu dans une liste

multiple à virgules, les types inconnus sont simplement ignorés et les types

connus sont pris en charge9.

Hélas, dans le cas des déclarations de médias pour @import, les versions d'IE

antérieures à la version 8 sèment la zizanie même pour les types de médias

qu'elles reconnaissent. C'est une raison de plus de s'en tenir à @media, sauf

lorsque vous voulez vraiment masquer certaines règles pour ce navigateur :

9. La spécification CSS 2.1 (http://www.w3.org/TR/2009/CR-CSS2-20090908/media.

html#media-types) aborde ce sujet pour @media et pour @import, mais elle est sans voix

pour le cas similaire des styles liés et incorporés. Cela dit, tous les navigateurs gèrent les

désignations de médias en HTML de façon homogène.

ADAPWEB.indb 58 17/04/13 12:47



@import ‘not-for-IE7-or-below.css' screen;@media screen, print, refrigerator { /* IE va pouvoir accéder à ces règles */}

Les désignations de médias sont très puissantes, puisqu'elles permettent de

créer des mises en page adaptées aux médias cibles. Un des premiers à avoir

utilisé cette technique est Eric Meyer. En l'an 2000, il nous a montré comment

abandonner les pages écran "adaptées aux imprimantes" en ajoutant une feuille

de styles spécifique à une sortie sur imprimante, disponible dans toutes les

pages web10

. Deux ans plus tard, Eric a étendu ce principe en nous montrant

comment utiliser du CSS avancé (tel que du contenu généré à la demande)

pour améliorer progressivement cette expérience11

.

Revenons à notre feuille de styles principale. Nous pouvons assez aisément

y ajouter un support d'autres médias grâce notre infrastructure stratifiée :

/* =Typographie *//* Typographie pour tous les médias */@media screen { /* Typographie réservée aux écrans */}@media print { /* Typographie réservée aux imprimantes */}

/* =Mise en page (Layout) *//* Mise en page pour tous les médias */@media screen { /* Mise en page réservée aux écrans */}@media print { /* Mise en page réservée aux imprimantes */}

/* =Couleurs *//* Couleurs pour tous les médias */@media screen { /* Couleurs réservées aux écrans */}@media print { /* Couleurs réservées aux imprimantes */}

10. http://meyerweb.com/eric/articles/webrev/200001.html

11. http://www.alistapart.com/articles/goingtoprint/

ADAPWEB.indb 59 17/04/13 12:47



Une autre approche consiste à regrouper tous les styles d'imprimantes dans

la même déclaration @media en fin de fichier :

/* =Typographie *//* Typographie pour tous les médias */@media screen { /* Typographie réservée aux écrans */}

/* =Mise en page *//* Mise en page pour tous les médias */@media screen { /* Mise en page réservée aux écrans */}/* =Couleurs *//* Couleurs pour tous les médias */@media screen { /* Couleurs réservées aux écrans */}

/* =Impression */@media print { /* Redéfinitions globales réservées aux imprimantes */}

Dans le cas de l'impression, ce regroupement dans une déclaration @media

est logique, mais il est préférable de distribuer les déclarations pour les autres

médias. Chaque projet étant différent, vous n'aurez qu'à faire des essais et voir

ce qui convient le mieux.

des déclarations de médias d'avant-gardeQuelques années après le support de l'indépendance des médias, le W3C a

renchéri en introduisant les requêtes de médias, une sorte de désignation de

média anabolisée. Ces requêtes fournissent des détails au sujet de l'environ-

nement du poste utilisateur, comme la largeur de la fenêtre du navigateur ou

son orientation (portrait ou paysage). La puissance des requêtes de médias

vous permet d'adapter finement vos designs à des terminaux spécifiques. Elles

représentent de ce fait un outil indispensable de plus pour l'amélioration

progressive.

ADAPWEB.indb 60 17/04/13 12:47



Grâce à une requête de média (que vous pouvez placer partout où vous placez

des désignations de médias normales), vous ajoutez dans une page un jeu de

règles adaptées aux capacités du logiciel agent utilisateur. Voyons un exemple :

@media (min-width:1025px) { /* ... */}

Ce groupe de jeux de règles n'entre en vigueur que si la largeur de fenêtre du

navigateur est égale ou supérieure à 1 025 pixels.

Le module CSS3 qui définit les requêtes de médias a atteint le niveau

Candidate Recommendation au milieu de l'année 2009. Il stipule comment

récupérer les dimensions de la fenêtre de navigateur, parmi d'autres paramètres

du terminal (orientation, nombre de couleurs affichables, résolution, etc.).

Actuellement, le standard ne gère pas encore toutes les propriétés, mais il y

en a assez pour que la technique soit digne d'intérêt.

Les requêtes de médias reprennent la syntaxe de désignation de média

standard en y ajoutant l'opérateur ET logique avec "and" et l'opérateur de

négation avec "not". Ils vous donnent un supplément de souplesse pour cibler

le média. Pour une cible écran de largeur supérieure à 1 024 pixels, nous

écrirons : screen and (min-width:1025px). Pour tous les médias sauf les

imprimantes, nous écrirons : not print. Cependant, il n'y a pas d'opérateur

OU. De ce fait, vous ne pouvez pas rédiger des requêtes conditionnelles aussi

complexes qu'avec un langage de programmation (comme dans l'expression A

et B ou B et C, mais pas A et C). Mais pour obtenir l'effet de l'opérateur OU,

il suffit d'utiliser une virgule.

Voici une requête de média composite assez complète suivie de commentaires

en décrivant le fonctionnement :

@media screen and (min-device-width:1024px) and (max-width:989px), screen and (max-device-width:480px), screen and (max-device-width:480px) and (orientation:landscape), screen and (min-device-width:481px) and (orientation:portrait) { /* Mise en page pour fenêtre de navigateur de moins de 990 pixels ou iPhone sous iOS3 ou iOS4 (ou équivalent) en mode Paysage ou iPad (ou équivalent) en mode Portrait */}

ADAPWEB.indb 61 17/04/13 12:47



Nous pouvons maintenant retoucher notre feuille de styles avec des requêtes

de médias de sorte à améliorer progressivement notre page en définissant une

mise en page fondamentale applicable aux anciens navigateurs et aux tablettes.

J'ai ensuite ajusté cette mise en page pour l'adapter aux navigateurs sur écran

de bureau comme aux petits écrans des téléphones portables :

/* =Mise en page minimale */@media screen { /* ... */}

/* =Mise en page complète */@media screen and (min-width:1025px) { /* ... */}

/* =Mise en page étroite */@media screen and (max-width:765px) { /* ... */}

La Figure 3.6 montre l'aspect des trois mises en page. Certaines différences

sont drastiques entre médias (par exemple, les modalités de navigation) et

d'autres plus subtiles (comme la fiche de contact au format carte postale qui

s'ajuste en largeur à l'écran). Sans entrer dans les détails de ces différences,

nous constatons que les requêtes de médias permettent de créer des mises en

page vraiment adaptatives uniquement par des styles CSS. Pour en savoir

plus au sujet des mises en page adaptatives, consultez la bibliographie en fin

de Chapitre 6.

ADAPWEB.indb 62 17/04/13 12:47



Figure 3.6 : Trois mises en page gérées par des requêtes de médias.

@media screen and (min-width:1025px) { /* ... */ }

ÉTROiT nORMAL/TAbLETTE

LARgE

@media screen and (max-width:765px) { /* ... */

}@media screen { /* ... */ }

ADAPWEB.indb 63 17/04/13 12:47



LA RiCHEssE À TOUs LEs ÉTAgEsNous avons découvert plusieurs techniques pour exploiter le langage CSS en

vue d'améliorer progressivement nos pages web. Certaines de ces techniques,

comme l'utilisation fructueuse des erreurs d'analyse, sont d'un emploi si simple

et si courant que vous allez sans doute les adopter immédiatement. D'autres,

comme la séparation en niveaux des règles de styles, peuvent vous demander

d'infléchir vos pratiques actuelles ou vous paraître totalement nouvelles.

En combinant finement ces techniques, niveau par niveau, vous êtes assuré

d'offrir à vos visiteurs une expérience de navigation optimale, quel que soit

le navigateur et le terminal d'accès.

ADAPWEB.indb 64 17/04/13 12:47


"Je n'accepte pas d'adopter un

outil avant d'être assuré que je

m'en servirai bien. Faire à moitié

dans ce domaine est pire que ne

rien faire. Les gens ne veulent

pas d'une interaction de mauvaise

qualité."

— sETH gOdin

ADAPWEB.indb 66 17/04/13 12:47


CHApiTRE 4

AMÉLIORATION PROGRESSIVE AVEC JAVASCRIPTLe 7 février 2011, peu de temps après que le groupe Gawker Media a lancé

le nouvel habillage unifié de ses différents sites (Lifehacker, Gizmodo, etc.),

les visiteurs de ces sites tombèrent sur un bel écran vide (voir Figure 4.1).

La nouvelle plate-forme était entièrement fondée sur JavaScript pour le

chargement de contenu dans les pages. Une erreur dans le code JavaScript

a fait que toutes les pages étaient affichées vides1. Cette erreur unique a

entraîné une "indisponibilité" de tous les sites (même si les serveurs restaient

opérationnels) de Gawker, ce qui leur a fait perdre des milliers de pages vues

et d 'affichages de bannières publicitaires. Cette perte sèche leur aurait été

épargnée s'ils avaient tenu compte des principes d 'amélioration progressive.

1. Cette avarie est racontée dans la page http://blogs.wsj.com/digits/2011/02/07/gawker-

outage-causing-twitter-stir/. Jeremy Keith et Mike Isolani ont fourni des commentaires

au sujet de la fiabilité JavaScript des sites Gawker (http://adactio.com/journal/4346/ et

http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs, respectivement).

J'ai ajouté mon grain de sel à l 'affaire (http://easy-reader.net/archives/2011/02/09/

you-cant-rely-on-javascript/).

ADAPWEB.indb 67 17/04/13 12:47



Figure 4.1 : Le site Lifehacker. Vide.

Rares sont les outils à pouvoir rivaliser avec JavaScript quand il s'agit d'animer

des pages web. Ce langage permet de créer des interactions sophistiquées et

des interfaces dynamiques. Les concepteurs web en sont depuis longtemps

convaincus et se sont jetés sur l'opportunité pour produire des pages plus

attrayantes, pour valider les formulaires, etc. De nos jours, un développeur

JavaScript n'a aucun mal à créer quelque chose d'étonnant en accord avec

l 'approche d 'amélioration progressive. Il n'en a pas toujours été ainsi.

Du milieu à la fin des années 1990, écrire du JavaScript était considéré comme

de la magie noire. Pour chaque bribe de code HTML un peu moins limpide,

nous aboutissions en général à dix fois pire en JavaScript parce que les deux

navigateurs phares de l'époque, Netscape et Internet Explorer, avaient deux

interprétations du langage HTML2 suffisamment divergentes pour que toutes

les sections vraiment captivantes deviennent horribles à rédiger.

2. Le langage JavaScript a été inventé par Brendan Eich. Il a vu le jour en tant que sous-système de

Netscape 2 fin 1995. Microsoft a ensuite créé son dialecte de JavaScript sous le nom "JScript"

(pour des raisons de droits intellectuels) et l'a lancé au cours de l'été 1996 avec Internet Explorer 3

(le premier navigateur à avoir intégré un support des styles CSS).

ADAPWEB.indb 68 17/04/13 12:47


CHApiTRE 4 AMÉLiORATiOn pROgREssivE AvEC JAvAsCRipT 69

Un exemple : pour trouver un élément (par exemple, #location) dans un

document (au sens strict, dans le DOM, Document Object Model), il fallait

deux conventions différentes :

document.layers['location']; // Netscapedocument.all['location']; // IE

Cette cacophonie nous a obligés à écrire quasiment tous nos scripts deux fois,

ou au moins à les truffer de fourches (des points où le script prend une voie ou

une autre selon le navigateur détecté), et nous avons fini par nous y perdre.

Comme décrit dans le Chapitre 2, la fin des années 1990 a été une période

frénétique sur le Web : c'était la guerre des navigateurs. Chaque nouvelle

version de Netscape et de Microsoft IE proposait de nouvelles fonctions aux

développeurs, dans l'espoir de capter la plus grande part de marché possible

parmi les navigateurs. Cette course à la suprématie a causé bien des soucis

aux développeurs ; les deux variantes incompatibles de JavaScript nous ont

obligés à passer tellement de temps à ajuster les divergences que nous perdions

de vue la façon dont fonctionnait le langage et omettions d 'apprendre à bien

l 'articuler avec le HTML et le CSS.

Un jour, l 'association ECMA (European Computer Manufacturers Association)

a standardisé JavaScript3 et l'organisme W3C a diffusé sa spécification DOM.

Les sables mouvants sur lesquels nous bâtissions ont enfin laissé place à du

sol stable sur lequel nous allions pouvoir envisager de meilleures façons de

réaliser les choses :

document.getElementById('location'); // DOM unifié

3. Netscape a soumis JavaScript à ECMA International comme candidat à un standard en

1996. La version standardisée de JavaScript a été nommée "ECMAScript", mais nous

utilisons toujours le nom JavaScript, sauf lorsque nous voulons parler de sa spécification.

ADAPWEB.indb 69 17/04/13 12:47



QUiTTER sA ZOnE dE COnFORTUne des premières leçons apprises une fois la poussière retombée était que

le langage JavaScript n'était pas la panacée pour l'interaction sur le Web. En

fait, le langage n'était pas si fiable que cela.

En effet, même une fois que le W3C a standardisé le modèle DOM et que les

navigateurs ont tous intégré le standard du langage, les divergences subsis-

taient ; elles étaient assez nombreuses entre les implémentations pour qu'il soit

impossible de présupposer la disponibilité de certaines méthodes, notamment

celles, vitales, de traversée de la structure arborescente du DOM, document.

getElementById() (pour accéder aux éléments d 'après leur identifiant) et

document.getElementsByTagName() (pour les trouver d 'après leur nom). En

outre, même lorsqu'un navigateur supportait totalement la norme JavaScript,

l'utilisateur (ou l 'administrateur informatique de son entreprise) gardait le

dernier mot en décidant ou pas d 'activer JavaScript sur le poste client4.

Nous avons fini par comprendre que le support de JavaScript n'allait pas de soi

et avons commencé à reformuler notre code source, à le rendre plus limpide,

plus facile à maintenir, et plus apte à gérer l'éventuelle absence ou difficulté

d 'accès au langage JavaScript. Intéressons-nous aux concepts discutés à cette

époque pour mieux comprendre comment bien exploiter JavaScript dans une

approche progressive.

Attention : À partir d'ici, nous allons lire du code source JavaScript. N'ayez

crainte si vous n'en avez jamais écrit ni lu, car je vais faire mon possible pour

expliquer ce qui se passe à chaque étape pour que vous ne perdiez pas le fil,

même si le code semble être écrit en sanscrit.

4. Pour les administrateurs informatiques, activer ou pas JavaScript était d 'abord un problème

de sécurité, mais les utilisateurs ont longtemps été invités à le désactiver pour éviter les

fenêtres surgissantes (popups) et publicités. Il est très facile de désactiver JavaScript en

accédant aux préférences du navigateur, mais il peut être bloqué par un pare-feu ou

désactivé pour toutes les applications par les administrateurs.

ADAPWEB.indb 70 17/04/13 12:47



Vers 100 % de fiabilitéIl n'était pas rare d'écrire (ou de lire) à l'époque des débuts de JavaScript des

gestionnaires d'événements onclick (du code exécuté en réaction à un clic sur

un élément de la page) qui définissaient des liens sans cible5 :

<a href="#" onclick="newWin( 'http://easy-designs.net/' );">Easy! Designs</a>

Si JavaScript est activé, le lien de l'exemple précédent provoque l 'appel à

une fonction sur mesure nommée newWin(), en lui transmettant la valeur

"http://easy-designs.net/". L'exécution de la fonction provoque l 'affichage

de la page visée dans une nouvelle fenêtre. En revanche, si JavaScript est

désactivé, le lien n'a aucun effet (nous en avions parlé en discutant des identi-

fiants dans le Chapitre 2). L'élément href pointe sur un identifiant id vide.

Quel est l'intérêt d'un lien qui ne fonctionne pas en l 'absence de JavaScript ?

Cela m'amène à présenter ma première maxime de l 'amélioration progressive

avec JavaScript :

1. Vérifiez que tout le contenu reste accessible et que toutes les actions indispensables restent opérationnelles même lorsque le Javascript est désactivé.

Le lien de l'exemple contrevient à cette règle (les sites de Gawker également),

mais c'est le cas de la majorité des sites web créés à la fin des années 1990

avec JavaScript. Le Web semblait infecté de sites réclamant le JavaScript

qui l'imposaient aux utilisateurs. Autrement dit, à cette époque le JavaScript

était envahissant. Les développeurs ont pris conscience du problème et ont

commencé à promouvoir une utilisation moins péremptoire de JavaScript.

Note : Je ne me fais pas ici l 'avocat des fenêtres popup ou de l'ouverture non

désirée de fenêtres par JavaScript, car ces techniques causent des soucis d 'acces-

sibilité et d'utilisation. En revanche, j'ai choisi cet exemple car il montre bien

l'évolution des pratiques d'écriture JavaScript d'une façon qui sera assez facile

à suivre. Soyez assuré que ce que vous apprendrez en suivant notre exemple

sera applicable à tout autre projet JavaScript.

5. Parmi les variations de cette vieille technique, citons le pseudo-protocole javascript (par

exemple, <a href="javascript:maFonction();">) et celle que je préférais, l'utilisation

combinée de ce pseudo-protocole et d'un gestionnaire d'événement inline (par exemple,

<a href="javascript:void(null)" onclick="maFonction();">).

ADAPWEB.indb 71 17/04/13 12:47



se montrer discretLe JavaScript discret (unobstrusive) est une expression globale qui désigne

une façon de programmer rendant la présence du JavaScript non indispen-

sable. Il garantit que le visiteur pourra accéder à toutes les pages et réaliser les

opérations demandées en n'ayant recours qu'aux éléments de base en langage

HTML et au protocole HTTP. La partie JavaScript vient s'ajouter à cette

base pour enrichir la page.

Cela vous rappelle quelque chose ? Le JavaScript discret s'accorde très bien

avec l 'approche d 'amélioration progressive, parce qu'il cantonne le code

JavaScript à un rôle d 'amélioration fonctionnelle, et n'en fait plus un acteur

incontournable.

Voici comment nous reformulons nos liens en JavaScript discret pour qu'ils

supportent l 'absence de JavaScript :

<a href="http://easy-designs.net/" onclick="newWin( this.href ); return false;">Easy! Designs</a>

Dorénavant, le lien pointe sur une adresse URL, ce qui lui assure de mener

quelque part sans JavaScript. Si le JavaScript est présent, cliquer sur le lien

lance la fonction newWin(), qui reçoit la valeur de l 'attribut href (autrement

dit, la valeur DOM this.href). L'autre grande différence de cette nouvelle

version est que le gestionnaire onclick renvoie la valeur faux ("return false"),

ce qui annule l 'action par défaut de l'événement (l 'affichage de la page visée),

puisque cette action HTML ferait doublon.

Nous venions ainsi de faire un premier grand pas dans la gestion d'une indis-

ponibilité de JavaScript, mais avions chemin faisant compris qu'il devait y

avoir de meilleures solutions à ce genre de scénarii.

Simplifier la maintenanceDans la prochaine étape d'évolution de ce code, nous exploitons l'antique

attribut rel (nous en avons parlé au Chapitre 2) pour extraire le code

JavaScript inline afin de le renvoyer dans un fichier externe, ce qui apporte

deux bénéfices : 1) cela ajoute du sens au lien et 2) cela simplifie la mainte-

nance des sites, puisque les programmeurs n'ont qu'un endroit JavaScript à

retoucher pour que la modification se propage à la totalité du site (c'est le même

argument que nous avions avancé pour externaliser les feuilles de styles avec

l 'attribut style).

ADAPWEB.indb 72 17/04/13 12:47



Voici le code HTML reformulé :

<a rel="external" href="http://easy-designs.net/">Easy! Designs</a>

Il devient alors très facile d 'appliquer ce gestionnaire d'événement à ce lien

et à tous les autres liens identifiés "external" :

var links = document.getElementsByTagName( 'a' ), rel, i = links.length;while ( i-- ) { rel = links[i].getAttribute('rel'); if ( rel && rel.match( /\bexternal\b/ ) ) { links[i].onclick = function(){ newWin( this.href ); return false; }; }}

Toutes ces conditions if et boucles while pouvant rebuter certains lecteurs,

je vous propose une visite guidée fonctionnelle de ce script : il regroupe dans

une variable links tous les liens trouvés dans la page, puis les visite un à un

en commençant par le dernier (étrangement, c'est un peu plus rapide qu'en

sens direct). Si le lien possède un attribut rel dont la valeur est "external", une

fonction anonyme est associée à l'événement onclick du lien. Cette fonction

va appeler la fonction newWin() (en lui transmettant la valeur de l 'attribut href

du lien, comme dans la version précédente) tout en provoquant, par renvoi de

false, l 'abandon de l 'action par défaut du clic.

Nous avons trouvé une solution satisfaisante et la plus discrète possible. En

2006, Jeremy Keith a donné le nom Hijax à cette technique. Ce nom est

intéressant : il combine le terme "hijack" (détournement), qui désigne la prise

de pouvoir du fonctionnement normal du lien, et le nom "Ajax", qui est le

mécanisme JavaScript permettant une interaction entre la page web et le

serveur sans requérir une réactualisation de la page dans le navigateur. Nous

ne savions pas à l'époque qu'Ajax, alors en pleine courbe ascendante, allait

nous obliger à retravailler la question sur un ou deux points au niveau de la

gestion d'événements JavaScript.

ADAPWEB.indb 73 17/04/13 12:47



gagner en souplesseNotre vieille technique d'affectation de gestionnaires d'événements ne tenait

plus la route face à l 'adoption à vaste échelle d 'Ajax6 et d 'autres techniques

pour modifier le contenu d'une page web à la volée. Voici pourquoi : au moment

où du nouveau contenu est injecté dans la page actuelle, et qu'il contient un lien

marqué rel="external", notre fonction spéciale n'a plus aucune chance d'être

associée à un gestionnaire d'événement onclick. Le script a normalement déjà

été exécuté lors du chargement initial de la page (window.onload()), donc avant

injection du nouveau lien par Ajax.

Nous affrontions là un vrai problème. Nous faisions apparaître le risque que

deux liens en théorie identiques se comportent différemment en pratique. Ne

serait-ce pas un problème d'ergonomie ?

Une solution évidente que certains ont alors prônée consiste tout simplement

à forcer une nouvelle exécution du script à chaque fin d'injection de données

HTML par Ajax. L'idée était trop bonne, car les appels à répétition de la

même fonction ralentissaient sensiblement le navigateur, qui devait à chaque

fois analyser tous les liens présents dans la page.

Christian Heilmann nous a alors rappelé fort à propos que tout événement

déclenché en relation avec un élément entraînait la traversée de l 'arbre DOM

depuis l'élément racine (html) jusqu'à l'élément cible (phase de capture d'évé-

nement), puis une seconde fois dans l 'autre sens (phase de bullage, bubbling)7.

Autrement dit, l'événement onClick d'un lien est géré deux fois pour chaque

élément dans l 'arborescence entre racine et cible8 (voir Figure 4.2). Il est plus

6. La technologie XMLHttpRequest est celle que nous utilisons pour soumettre des requêtes

au serveur afin d'envoyer et de recevoir des données sans forcer le navigateur à recharger/

réactualiser la page. Elle fut inventée chez Microsoft pour le logiciel Outlook Web Access,

introduite ensuite dans IE5, puis adoptée par tous les autres navigateurs et dorénavant

en cours de standardisation par le W3C. XMLHttpRequest est l'épine dorsale d 'Ajax

(Asynchronous JavaScript and XML), mais elle n'est pas cantonnée au langage XML. Le

"A" d 'Ajax signifie "asynchrone", parce que l'utilisateur n'a pas besoin d 'attendre le retour

de la réponse et peut continuer à interagir avec la page pendant que le script rapatrie des

données du serveur.

7. http://icant.co.uk/sandbox/eventdelegation/

8. En fait, pas deux fois dans tous les navigateurs. Le modèle de gestion d'événements de

Microsoft, appliqué dans toutes les versions d'IE avant la 9, ne sait gérer que la phase de

bullage en remontée d 'arbre d'un événement. Le modèle standard du W3C supporte la

phase de capture et celle de bullage.

ADAPWEB.indb 74 17/04/13 12:47



efficace de se placer en attente de l'événement au niveau d'un élément situé

plus haut dans l 'arborescence DOM (cela permet d 'associer un seul gestion-

naire plutôt que des dizaines). Cela permet aussi de déclencher des actions

pour du contenu dynamique, ce qui nous aide à gérer les problèmes de liens

similaires qui divergent.

Figure 4.2 : Captures et bullages d'événements.

Ce concept a été diffusé sous le terme de délégation d'événement, puisque le

même gestionnaire pouvait détecter des événements et déclencher des ordres

dépendants de l'élément déclencheur et pour son compte. Voici une reformu-

lation compacte de l'exemple précédent en utilisant la délégation d'événement :

document.body.onclick = function( e ) { // Harmonisation des modèles d'événements e = ( e ) ? e : event; var el = e.target || e.srcElement, rel; // Liens externes rel = el.getAttribute( 'rel' ); if ( el.nodeName.toLowerCase() == 'a' && rel && rel.match( /\bexternal\b/ ) ) { newWin( el.href ); // Annulation de l'action par défaut if (e.preventDefault) { e.preventDefault(); } else { e.returnValue = false; } }};

html

footersectionheader

head body

p p

a“Retreats 4 Geeks is an“ “venture.“

Phase de capture

Phase de bullage

Éléments concernés

Flux des événements

ADAPWEB.indb 75 17/04/13 12:47



Dans ce code, nous associons un gestionnaire d'événement à l'événement

onclick de l'élément principal body, ce qui établit l 'auditeur. Dans ce dernier,

nous cherchons l'élément cible (celui qui a été cliqué) puis vérifions que c'est

un élément d 'ancrage (a) doté d'un attribut rel dont la valeur est la chaîne

"external". Si toutes ces conditions sont remplies, nous appelons la fonction

newWin(), puis annulons l 'action par défaut de l'événement.

Cet exemple est spécifique, mais il montre pourquoi nous devons continuer

à faire évoluer notre approche des interactions fondées sur JavaScript. En

augmentant notre compréhension de JavaScript, nous obtenons des avantages

en termes d'amélioration progressive. Notre code devient plus efficace et moins

envahissant. Cela nous aide aussi à simplifier la maintenance et à augmenter

les performances.

FAiRE LE nÉCEssAiREArrivé en ce point, vous avez une certaine idée de ce qu'est du JavaScript

discret, mais nous n'avons pour le moment considéré l'expérience utilisateur

que du point de vue du document. Dans de nombreux domaines, les interac-

tions sont bien meilleures avec JavaScript que sans. Ainsi, la validation de

saisie de formulaire sur le poste client permet d'informer immédiatement

l'utilisateur des erreurs ou oublis de saisie sans l'obliger à transmettre d 'abord

les données au serveur.

ADAPWEB.indb 76 17/04/13 12:47



Figure 4.3 : Contrôle de disponibilité d'un pseudo dans Twitter.com.

Nous savons qu'une de nos contraintes est de garantir que l'interface peut

fonctionner sans JavaScript, mais comment faire lorsque le fonctionnement

de JavaScript requiert des marquages spécifiques ? La réponse m'amène à

formuler ma deuxième maxime d 'amélioration progressive avec JavaScript :

2. Utilisez Javascript pour générer les balises supplémentaires dont le script a besoin.

JavaScript est vraiment doué pour générer et modifier des balises en temps réel.

Lorsque vous devez enrichir une interface à l 'aide de JavaScript, commencez

par un groupe initial de balises et de styles signifiants et pratiques, puis réalisez

par le script les modifications HTML et CSS pour aboutir à votre nouvelle

interface, mais seulement une fois que vous avez vérifié qu'elle fonctionne

sans erreurs.

Voyons un exemple de mise en pratique de ces conseils en revenant à la page

Retreats 4 Geeks.

ADAPWEB.indb 77 17/04/13 12:47



Figure 4.4 : La page web Retreats 4 Geeks.

Un de mes objectifs ici était d'utiliser de façon efficace l'espace limité des

terminaux nomades. Les translations (navigation horizontale) sont exploitables

sur un petit écran, mais les zones cibles seront trop réduites pour être sélec-

tionnées sans effort. Je pourrais bien sûr basculer l 'affichage pour proposer

une navigation verticale, ce qui permettrait d'offrir des liens plus spacieux,

mais cela dévorerait trop de surface d'écran.

Une troisième approche consiste à créer une liste déroulante (dropdown),

soit en CSS, soit avec un élément select. La liste en CSS pur est tentante,

mais l 'autre a l 'avantage de présenter à l'utilisateur une interface qui lui sera

familière. J'opte donc pour l'élément select.

Je pars du marquage HTML du Chapitre 2 pour vous guider dans la création

d'un script qui va convertir le contenu de l'élément nav en un élément select

seulement lorsque les dimensions de l'écran deviennent inférieures à une

valeur plancher. Pour que le code reste assez simple à étudier, j'exploite la

librairie jQuery JavaScript9. Les librairies, fort pratiques, apportent toutes

faites des dizaines ou centaines de fonctions répondant aux besoins les

plus courants (comme l 'ajout et la suppression d'une classe class). Ne vous

inquiétez pas à la lecture du code ; je vais commenter son fonctionnement.

9. http://jQuery.com

ADAPWEB.indb 78 17/04/13 12:47



Nous isolons d 'abord le script dans une fonction anonyme10

qui sera exécutée

dès que les données du DOM seront disponibles, mais avant que soient

téléchargées les images, fichiers CSS et vidéos (à l'instant onDOMReady). Cela

rend l 'affichage de la page plus vif que si l'on doit attendre que tout ait été

rapatrié (à l'instant window.onload). Toute la suite du code sera placée dans

les limites de cette fonction :

$(function(){ // Les choses intéressantes seront ici.});

Nous pouvons créer les variables dont nous aurons besoin. Nous les regroupons

dans une déclaration var par souci de compacité (concept de minification)11

.

var$window = $(window), // Référence à la fenêtre$old_nav = $('#top nav > *'), // Récupère la navigation$links = $old_nav.find('a'), // Récupère les liensshowing = 'old', // Suivi de l'action en courstrigger = 765, // Largeur plancher de fenêtre$new_nav, $option, // Utilisées plus lointimer = null; // Un timer sera requis

Les commentaires doivent vous éclairer sur l'utilité de chaque variable.

Même si vous connaissez jQuery, vous pouvez vous demander pourquoi je

stocke les éléments dans des variables locales au lieu de faire directement

référence aux expressions fondées sur jQuery (comme dans $('#top nav> *'))

lorsque nous en avons besoin. En fait, j'ai de bonnes raisons de travailler ainsi :

les références locales réduisent l'impact de l'exécution du script sur les perfor-

mances parce que l 'affectation n'est faite qu'une fois et non à chaque rencontre

d'une utilisation de $(). Pour ne pas confondre les résultats de jQuery avec

les autres variables, j'ai fait débuter chaque nom de variable associée par le

signe dollar ($). Ces techniques sont employées tout au long du script ; ce sont

de bonnes pratiques qu'il est conseillé d 'adopter.

Les variables étant en place, vous pourriez penser que le moment est venu

de passer au noyau dur du script, mais il reste une précaution à coder avant

d'exécuter le code : vérifier que les éléments requis sont bien présents :

10. Une fonction anonyme n'est rien d 'autre qu'une fonction qui ne possède pas de nom.

11. http://www.alistapart.com/articles/javascript-minification-part-II/

ADAPWEB.indb 79 17/04/13 12:47



if ( $old_nav.length && $links.length ) { // Nous savons que les éléments DOM existent, // et nous pouvons les utiliser.}

Il est capital de tester les dépendances et j'y reviendrai dans la section suivante.

Passons maintenant à ce noyau dur. Nous commençons par générer la nouvelle

navigation fondée sur select en créant le bloc select, puis son premier élément

option :

$new_nav = $('<select></select>');$option = $('<option>-- Navigation --</option>') .appendTo($new_nav);

Une fois que nous disposons du nouveau marquage, nous pouvons balayer la

liste des liens récoltés (dans $links) pour construire une option pour chacun

d'eux en répétant l'élément option que nous venons de coder :

$links.each(function(){ var $a = $(this); $option.clone() .attr( 'value', $a.attr('href') ) .text( $a.text() ) .appendTo( $new_nav );});

Une fois tous les éléments options créés et ajoutés à select, nous terminons

en ajoutant des retouches de marquage et en configurant le gestionnaire pour

l'événement select onchange :

$new_nav = $new_nav .wrap('<div id="mobile-nav"/>') .parent() .delegate('select', 'change', function(){ window.location = $(this).val(); });

Il s'agit ici d'une version un peu simplifiée du vrai code de la page Retreats

4 Geeks (j'ai notamment supprimé quelques astuces de gestion des sauts

par # dans les adresses URL). Le but est de vous laisser vous concentrer sur

l'essentiel. Dans les trois premières lignes, nous imbriquons notre select

($new_nav) dans un élément div, puis réaffectons ce div à la variable $new_nav

en sorte que l'ensemble soit vu par JavaScript comme un paquet complet.

Dans la ligne suivante, j'utilise la délégation d'événement (décrite plus haut)

pour pouvoir surveiller l'événement onchange depuis un point plus élevé

ADAPWEB.indb 80 17/04/13 12:47



de l 'arbre DOM (en fait, du niveau de l'élément div). Nous associons une

fonction anonyme à l'événement pour injecter une nouvelle adresse dans la

barre d 'adresse du navigateur (ce qui fait afficher la nouvelle section de page

ou une autre page, selon le type de lien).

Et voilà ! Nous avons codé une navigation opérationnelle basée select. Voyons

maintenant comment l 'ajouter à la page quand les conditions en sont remplies.

Nous créons une autre fonction nommée toggleDisplay(), qui surveille la

largeur de fenêtre du navigateur et active un style de navigation ou l 'autre :

function toggleDisplay() { var width = $window.width(); if ( showing == 'old' && width <= trigger ) { $old_nav.replaceWith($new_nav); showing = 'new'; } else if ( showing == 'new' && width > trigger ) { $new_nav.replaceWith($old_nav); showing = 'old'; }}

Ici aussi, le script est un peu allégé, mais l'essentiel y est : la navigation est

changée si le plancher de largeur de fenêtre est franchi (trigger) et si le style

de navigation actuel n'est pas déjà le bon (selon la valeur de showing). Avec

cette fonction, il nous suffit de l'exécuter une fois pour initialiser les variables

et afficher le bon style de navigation dès le départ. Nous pouvons ensuite

l 'associer à l'événement de fenêtre onresize :

toggleDisplay(); // Initialise le bon style$window.resize(function(){ if ( timer ) { clearTimeout(timer); } timer = setTimeout( toggleDisplay, 100 );});

Vous pourriez vous demander pourquoi je ne transmets pas directement

toggleDisplay() comme gestionnaire d'événement ? Sachez que cela provo-

querait de multiples exécutions de la fonction (plusieurs centaines de fois)

pendant que l'utilisateur retaille sa fenêtre de navigateur. Pour limiter le

nombre d'exécutions (et éviter de surcharger le processeur du poste client),

le gestionnaire se fonde sur une minuterie (timer) pour n'appeler toggle-

Display() qu'après 100 millisecondes. Si la fonction est déclenchée à répétition

pendant une retaille de fenêtre, cela provoque la destruction de la variable

timer pour la recréer et repartir à zéro. C'est ce qui permet de n'appeler

ADAPWEB.indb 81 17/04/13 12:47



toggleDisplay() qu'une fois par retaille (sauf si l'utilisateur déplace sa souris

vraiment lentement).

Résultat ? Un excellent exemple d 'amélioration progressive avec Javascript.

Figure 4.5 : Une navigation basée select sur iPhone.

Cet exemple simple prouve que JavaScript est en mesure de générer ce dont

le script a besoin tout en écartant tout le superflu. Vous pourriez étendre cette

fonction pour qu'elle soit encore moins dépendante du balisage en permettant

de transmettre dynamiquement à la fonction un point de départ racine (qui est

ici le niveau des éléments enfants de nav). Je vous laisse chercher la réponse.

Expérimentez !

REsTER EXCELLEnTNous avons dit que la plupart des techniques d 'amélioration progressive au

niveau HTML et CSS étaient assez simples et faisaient peut-être déjà partie

de vos pratiques antérieures. En revanche, l 'amélioration progressive en JavaS-

cript est un peu plus complexe, car JavaScript ne peut pas être aussi tolérant

du fait que c'est un langage de programmation.

Les langages HTML et CSS décrivent du contenu et en organisent le rendu

visuel dans une fenêtre de navigateur. Le langage JavaScript s'en distingue, car

ADAPWEB.indb 82 17/04/13 12:47



il exécute des commandes dans le navigateur. Puisqu'ils dépendent de la bonne

réalisation d'une séquence d 'actions, les programmes JavaScript se bloquent

dès qu'ils rencontrent une erreur. Les causes de ces erreurs vont de la simple

faute de frappe à la boucle de répétition dont on ne sort jamais. Dans tous les

cas, lorsque vous écrivez du code qui ne convient pas au module interpréteur

de JavaScript du navigateur, vous recevez en pleine face un bon gros message

d'erreur, mais vos clients aussi. S'en passer serait salutaire.

Nous savons que la mise en place de l 'amélioration progressive n'est pas un

processus binaire qui se limite à évaluer si la technologie espérée existe ou non

sur le poste client. L'expérience utilisateur est au contraire variable à chaque

niveau selon les capacités de son navigateur. Si ce dernier sait gérer dès le

départ la convention de couleurs RGBa, mais pas les arrondis d 'angles, ce

n'est pas menaçant au point d'empêcher l'utilisateur de prendre connaissance

du contenu.

Nous devons adopter la même approche pour JavaScript ; abandonner tout

manichéisme. Sans vouloir abuser des métaphores culinaires, il nous faut

proposer les technologies à la carte en distribuant les fonctions en petits

paquets autonomes et bien délimités. Ces scripts multiples peuvent vérifier

leurs dépendances et décider de se poursuivre seulement si l'environnement

d'exécution et la page visée leur sont favorables.

Le précédent script de navigation fondé sur select donne un bon exemple

de mise en pratique de la première partie de ce concept ; il est entièrement

autonome. Cependant, il ne prend pas les précautions requises pour vérifier

ses nombreuses dépendances, parmi lesquelles la présence de l'incontournable

jQuery. Pour y parvenir, il nous faut enchâsser le tout dans une instruction

conditionnelle :

if ( typeof( jQuery ) != 'undefined' ) { // Le code existant se place ici}

Dans ce test, nous vérifions que l'objet nommé jQuery existe dans l'environ-

nement d'exécution, et cet objet est créé si la librairie jQuery est disponible,

ce qui détermine la valeur de "undefined". Le test de dépendance est une

technique vitale, qui vous évite de laisser survenir une erreur sur le poste

client, sans compter que cela peut vivifier le fonctionnement du navigateur

en empêchant l'exécution inutile de certains blocs de code.

ADAPWEB.indb 83 17/04/13 12:47



Voici un autre exemple qui pourra vous sembler familier :

if ( document.getElementById ) { // Code dépendant de document.getElementById() ici}

Nous nous assurons ainsi que la méthode de traversée de l 'arbre DOM

document.getElementById() existe avant de tenter d'y faire appel. Vous vous

souvenez que nous avions utilisé cette approche dans l'exemple de délégation

d'événement lors du test de event.preventDefault().

Revenons au test de la librairie jQuery. Voyons si nous pouvons être plus précis

en cherchant à connaître la version de jQuery, précaution indispensable si

vous utilisez une méthode qui n'est apparue que dans une version récente de

la librairie. Il est en général plus efficace de tester l'existence d'une méthode

en particulier, mais le test de version devient approprié pour une version de

librairie qui entraîne un remaniement profond de l'interface de programmation

API pour une méthode qui existait auparavant :

if ( typeof( jQuery ) != 'undefined' && parseFloat( jQuery.fn.jquery ) >= 1.4 ) { /* Code dépendant de jQuery 1.4 au minimum ici */}

Le test de dépendance vous évite les situations d'erreur et plus vous l'effectuez

tôt, plus vous économisez l'espace mémoire et le processeur lorsque le poste du

client ne dispose pas de l'environnement requis pour profiter de vos scripts.

jQuery n'est pas la seule dépendance de ce script : vous vous souvenez que nous

avions tenu compte de ses dépendances au balisage lors du test de longueur

des deux listes $old_nav et $links :

if ( $old_nav.length && $links.length ) {

Une fois cet autre test en place, le script va gentiment se terminer s'il constate

ne pas pouvoir fonctionner. Il ne perd pas de temps à créer des éléments ou à

implanter un gestionnaire d'événement inutilement.

En vous inspirant de l'exemple, vous trouverez des centaines d'occasions

d'interroger l'environnement du navigateur et la configuration de la page pour

décider de lancer ou pas un script. Vous pouvez tester l'existence d'un objet,

les dépendances aux balises, la disponibilité d'une méthode ou d'un cookie,

le support Ajax, etc. Il n'y a aucune raison de se priver d 'ajouter le code de

ADAPWEB.indb 84 17/04/13 12:47



test pour que les scripts repartent illico d'où ils viennent en toute discrétion

s'ils se sentent indésirables.

Le concept de test des dépendances est analogue aux requêtes de média du

CSS. Puisque nous venons d'en parler, il nous faut voir maintenant comment

bien gérer les interactions entre les scripts et les styles CSS.

EXÉCUTER AvEC sTYLELe CSS est un volet des dépendances de script dont nous n'avons pas encore

parlé. Dans neuf cas sur dix, si votre code JavaScript interagit avec le modèle

DOM, vous devez gérer le CSS d'une manière ou d'une autre. Dans l 'approche

d 'amélioration progressive, il faut choisir la meilleure manière d 'appliquer

et de contrôler les styles en JavaScript. Vous ne voudriez pas créer des inter-

faces qui perturberaient l'utilisateur par un fonctionnement défectueux. Nous

reviendrons sur ce sujet plus loin.

Notre compréhension des modalités d'interaction entre JavaScript et CSS a

beaucoup évolué au cours des dernières années. Dans les débuts du JavaScript,

la gestion des styles était quasiment absente des scripts ; tout était écrit en ligne

par modification de l 'attribut style des éléments :

function highlight() { var el = document.getElementById( 'message' ); el.style.color = '#f00'; el.style.backgroundColor = '#ffcfcf';}

Du point de vue de la maintenance du code, cette façon de faire est une

catastrophe. Au moindre changement de l 'aspect ou de la structure, vous

deviez aussi trouver un spécialiste du JavaScript. Efficacité nulle et viol de la

règle de séparation des couches fonctionnelles : en mélangeant présentation

et comportement, on rend le travail plus difficile dans les deux univers.

L'étape d'évolution suivante a consisté à stocker les données qui évoluent

dans des variables, soit dans le script, soit en transmettant ces données dans

un objet de configuration (en conservant sous le coude des valeurs par défaut

au cas où cette configuration serait contournée) :

function highlight( config ) { var el = document.getElementById( 'message' ); el.style.color = config.color || '#f00'; el.style.backgroundColor = config.backgroundColor

ADAPWEB.indb 85 17/04/13 12:47



|| '#ffcfcf';}

highlight({ color: '#ebebeb', backgroundColor: 'black'});

La mise à jour des chaînes ne requiert dorénavant que quelques connaissances

élémentaires en JavaScript, et toutes les règles de styles sont réunies en un seul

endroit, facilitant ainsi la maintenance.

Nous avons cependant constaté qu'il était beaucoup plus efficace d'extraire les

données des styles dans un fichier externe, puis de le solliciter en travaillant

avec la classe de l'élément de page visé :

function highlight() { document.getElementById( 'message' ) .className += ' highlight';}

Cela réduit le volume de code requis pour obtenir l'effet et entraîne moins

de manipulations du modèle DOM (l'effet sur les performances est énorme).

De plus, le CSS peut alors être retouché sans que l'on ait à modifier le code

JavaScript qui utilise ces styles.

Je ne vais pas m'engager dans l'intéressante discussion au sujet des manières

possibles de combiner scripts et styles tout en conservant assez de séparation

entre les deux domaines12

. Je considère plus important de passer un peu de

temps à découvrir quand et comment appliquer efficacement des styles depuis

un script. Ces points sont d'une grande importance et font donc l'objet de ma

troisième et dernière maxime de l 'amélioration progressive avec JavaScript :

3. Appliquer les styles seulement le moment venu.

Nous l 'avons déjà dit, les scripts qui exploitent les données DOM demandent

en général certaines modifications des styles, que ce soit pour déplier/replier

le contenu d'un élément, mettre en exergue les nouveaux contenus ou ajouter

des effets visuels à une interface glisser-déposer. Ce domaine d'exploitation

des styles est tout à fait recommandable, mais les développeurs ont souvent

12. J'ai donné un aperçu de ce sujet dans un article nommé "Keeping the hot side hot and the

cold side cold" dans Scroll Magazine (http://scrollmagazine.com/number-1/keeping-the-

hot-side-hot).

ADAPWEB.indb 86 17/04/13 12:47



pris l'habitude d 'appliquer les styles de chaque widget avant de savoir si ce

widget va effectivement être utilisé.

Prenons en guise d'exemple un widget accordéon à géométrie variable. Dans

ce type d'interface utilisateur, les blocs de contenu sont masqués et seul l'onglet

de chacun est visible. Si les styles de masquage des sections de contenus sont

appliqués par défaut et qu'il s'avère ensuite que le script ne peut pas être

exécuté, l'utilisateur ne peut plus cliquer sur les onglets pour afficher les détails.

Les styles auront été la cause d'une perte d 'accessibilité aux contenus pour la

simple raison qu'ils ont été appliqués trop tôt.

En revanche, si c'est le script qui déclenche l 'application des styles de l'état

initial une fois que son exécution a été confirmée, il n'y aura pas de problème.

Si le script ne peut pas être exécuté, les styles du widget ne sont pas appliqués

et le contenu reste visible, donc utilisable. En optant pour cette approche

d 'application des styles, vous gérez un jeu de règles pour le contenu lorsque

le widget n'est pas utilisable, et un second lorsqu'il l'est, optimisant ainsi les

deux situations.

Cela est-il possible ? Je réponds oui, c'est de l 'amélioration progressive mise

en œuvre à la perfection.

Figure 4.6 : Un widget accordéon avec la première section dépliée et les trois

autres repliées. Si l'on clique dans un onglet/titre d'une autre section, elle est

dépliée et la précédente est repliée.

ADAPWEB.indb 87 17/04/13 12:47



Une technique efficace pour gérer ce genre de styles d'interface conditionnelle

consiste à associer une classe "d 'activation" à l'élément racine du widget. Le

tableau suivant donne quelques exemples.

sTRATÉgiE CLAssE "sUspEndUE" CLAssE "ACTivÉE"Ajout d'un suffixe "-on" à la

classe de base

.accordion .accordion-on

Ajout d'une autre classe .auto-submit .auto-submit.active

Changement de forme de

la classe

.replace-me .replaced

Tableau 4.1 : Exploitation d'une classe "d 'activation".

Cette précaution vous assure de ne jamais appliquer de style avant qu'il soit

devenu nécessaire.

Un autre souci lié à l 'application des styles en JavaScript est le risque de

collisions. Il est capital d'isoler vos scripts les uns des autres pour éviter des

doublons de variables, de fonctions ou de méthodes. De même, il est conseillé

d'isoler les styles de script des autres styles. Vous ne pouvez pas prévoir quels

autres noms de classes seront en vigueur sur une page (surtout si vous concevez

des scripts que d 'autres vont réutiliser). Si vous n'isolez pas bien vos noms de

styles, ils peuvent déborder et occuper l'espace sémantique du reste de la page

(ils risqueraient d'être appliqués à des éléments de manière fortuite).

Pour isoler vos noms de styles, faites débuter le nom de chaque sélecteur par un

marqueur repérable qui aura très peu de chances d'entraîner un conflit avec un

autre élément class ou id dans la page. Personnellement, je fais commencer

les noms par celui de l'objet JavaScript concerné. Si je conçois par exemple

un widget accordéon nommé fort à propos WidgetAccordeon, je peux classer

l'élément racine activé sous le nom "WidgetAccordeon-on", puis déduire mes

styles de ce radical :

.WidgetAccordeon-on .heading { /* Styles de titrage */}

.WidgetAccordeon-on .content-block { /* Styles des blocs de contenu */}

ADAPWEB.indb 88 17/04/13 12:47



.WidgetAccordeon-on .content-block.collapsed { /* Styles des blocs de contenu repliés */}

Dans le sens inverse, il y a de faibles chances qu'une règle de style extérieure

vienne polluer le contenu du widget à cause des particularités de la spéci-

ficité et de la cascade. En anticipant ces problèmes, vous pouvez prendre les

mesures adéquates en rendant vos sélecteurs encore plus spécifiques ou, plus

radicalement, en définissant explicitement chacune des propriétés à contrôler

dans le widget au lieu de laisser les valeurs par défaut.

pLAniFiCATiOn ET RETEnUEIl est indéniable que l 'amélioration progressive en relation avec JavaScript

suppose plus d'efforts qu'avec le CSS et le HTML. En prenant le temps de

réfléchir aux nombreux facteurs qui influent sur la qualité de l'expérience

des utilisateurs, cela deviendra vite une seconde nature. Au moindre doute,

rappelez-vous les trois maximes :

1. Vérifiez que tout le contenu reste accessible et que toutes les actions indis-

pensables restent opérationnelles même lorsque le JavaScript est désactivé.

2. Utilisez le JavaScript pour générer les balises supplémentaires dont le

script a besoin.

3. Appliquez les styles seulement le moment venu.

En étant mieux armé pour tirer le profit maximal de la puissance de JavaScript,

vous êtes certain de prendre les meilleures décisions et d'obtenir des sites encore

plus ergonomiques.

ADAPWEB.indb 89 17/04/13 12:47


"Il faut bien des efforts pour se

bâtir une bonne réputation, mais

une seule mauvaise action fait

tout perdre."

— bEnJAMin FRAnKLin

ADAPWEB.indb 90 17/04/13 12:47


CHApiTRE 5

AMÉLIORATION PROGRESSIVE ET ACCESSIBILITÉEn février 2006, l 'association nationale des aveugles des États-Unis a intenté

un procès contre la société Target en raison de l'impossibilité d 'accéder à son

site web. Un mois plus tard, le procès a été transféré à la cour fédérale (à la

demande de Target). La société a tenté de faire rejeter la plainte, mais elle

a eu tort, puisque le procès est devenu une action collective que Target a

finalement éteinte en 2008 en payant plus de 6 millions de dollars US (sans

compter les frais d 'avocat).

Cette somme est remarquable quand on la rapproche de la raison première

du procès : Target n'avait tout simplement pas pris la peine de gérer les

problèmes d'accessibilité aux handicapés, dont ils avaient pourtant été avertis

au préalable. Il n'y avait pas de texte de rechange alt pour les images, ils utili-

saient énormément les mosaïques d'images avec liens et obligeaient à utiliser

la souris pour valider les formulaires. Ces différents petits soucis auraient pu

être réglés rapidement et facilement pour bien moins que 6 millions de dollars.

Personnellement, j'aurais réglé le problème contre quelques billets de 100.

Si vous n'avez pas encore été confronté à l 'accessibilité, qui est dans le cadre de

ce chapitre la mesure de facilité d'utilisation d'un site par les gens souffrant de

handicaps et par les technologies d'assistance correspondantes1, vous pourriez

1. Les technologies d 'assistance sont très variées. Les non-voyants utilisent des logiciels de

lecture audio du contenu de l'écran. Ceux dont la vision est faible peuvent zoomer sur le

texte dans le navigateur. Les malentendants utilisent des sous-titrages pour les vidéos.

ADAPWEB.indb 91 17/04/13 12:47



prendre peur parce qu'il faut tenir compte de nombreux critères. Même si vous

êtes un des utilisateurs ayant des "besoins spéciaux", il est fort probable que

votre expérience et que vos capacités ne soient pas les mêmes que celles des

autres. Vous pouvez par exemple souffrir de daltonisme élémentaire (absence

de vision du rouge et du vert), mais de façon moins lourde que d'autres. Même

avec ce handicap, vous ne pourrez pas aisément vous mettre à la place de

personnes qui souffrent de tétranopie (incapacité de voir le bleu et le jaune). Si

vous vous intéressez aux problèmes d 'accessibilité, que ce soit parce que vous

voulez que votre message puisse être accessible par le plus de gens possible, ou

parce que vous ne voulez pas que quelqu'un reste sur la touche, vous devrez

apparemment vous imposer une telle pression pour que les choses soient

parfaites qu'il ne peut en résulter qu'une appréhension certaine.

Vous serez heureux d'apprendre qu'en choisissant de concevoir et de développer

des sites web dans l 'approche d'amélioration progressive, vous améliorez aussi

l 'accessibilité. En effet, l 'amélioration progressive vous invite à concevoir vos

sites web d 'abord au service du contenu, ce qui vous amènera en général à

prendre la décision appropriée en termes d 'accessibilité. Mais il y a bien sûr

toujours moyen d 'améliorer les choses, et c'est la raison d'être de ce chapitre.

EnFin, TU ME vOisUne des techniques JavaScript les plus utilisées consiste à masquer et cacher

du contenu. Cela sert à concevoir des interfaces à onglets, des éléments pliables

et repliables, des gadgets en accordéon. Vous en trouverez partout. En soi, cette

pratique n'est pas critiquable, mais rares sont les personnes qui savent à quel

point les choix faits pour cacher du contenu ont une influence sur l 'accessibilité

de ce contenu par les technologies d 'assistance telles que les lecteurs d'écran.

Le tableau qui suit présente les différents mécanismes disponibles pour cacher

du contenu, chacun ayant un impact différent sur la page résultante.

ADAPWEB.indb 92 17/04/13 12:47


CHApiTRE 5 AMÉLiORATiOn pROgREssivE ET ACCEssibiLiTÉ 93

RÈgLEs Css EFFET visUEL EFFET d'ACCEssibiLiTÉ

visibility: hidden; L'élément est masqué sans

être supprimé du flux de

données (il occupe l'espace

correspondant).

Ce contenu est ignoré par les

lecteurs d'écran.

display: none; L'élément est supprimé du

flux et masqué, l'espace cor-

respondant étant récupéré.

Le contenu est ignoré par les

lecteurs d'écran.

height: 0; width: 0; overflow: hidden;

L'élément est replié et le

contenu est masqué.

Le contenu est ignoré par les

lecteurs d'écran.

text-indent: -999em; Le contenu est décalé pour

sortir de l'écran, ce qui

le masque, mais les liens

peuvent cibler les éléments

actifs. De plus, la translation

négative peut être insuffi-

sante pour bien cacher le

contenu.

Les lecteurs d'écran ont

accès aux contenus, mais

seulement au texte et aux

éléments inline.

position: absolute; left: -999em;

Le contenu est supprimé

du flux normal et décalé du

côté gauche. L'espace occupé

est réduit.

Les lecteurs d'écran ont

accès au contenu.

Tableau 5.1 : Mécanismes de masquage de contenu.

Les deux premières techniques sont les plus utilisées. display: none; est

exploitée par quasiment toutes les librairies JavaScript de notre planète, et

par la plupart des widgets JavaScript prédéfinis. Ces deux approches vous

conviendront si vous ne voulez pas que le contenu masqué soit lu par les

lecteurs d'écran. Dans le cas contraire, si vous voulez que le contenu soit lu,

même masqué, c'est la dernière option qu'il faut adopter.

Si vous avez prévu de concevoir votre propre librairie JavaScript, la technique

consistant à placer du contenu en dehors des limites de l'écran est assez simple

à mettre en place. Cela devient en revanche beaucoup plus difficile si vous

vous fondez sur une librairie JavaScript préprogrammée telle que jQuery

ou Prototype. En effet, cela suppose de pouvoir redéfinir certains éléments

internes à la librairie. Vous pouvez cependant parvenir à vos fins avec un

zeste d'intelligence.

ADAPWEB.indb 93 17/04/13 12:47



En effet, la plupart des librairies possèdent dans le cadre de leurs fonctions

d 'animation un mécanisme permettant de définir une fonction de rappel

(callback function). Ce genre de fonction est transmis par vous à une fonction

de la librairie (ou à une méthode d'un objet), à charge pour cet objet de

déclencher l'exécution de la fonction à un certain moment. Si vous avez déjà

utilisé JavaScript pour charger du contenu via Ajax, vous connaissez le concept

de fonction de rappel qui permet d'effectuer certains traitements en attendant

que les données demandées reviennent du serveur.

En général, les librairies JavaScript proposent une fonction de rappel capable

de s'exécuter à la fin d'une certaine activité. Certaines offrent en complément

des points d'ancrage à d'autres étapes de l'exécution d'une routine, par exemple

avant son commencement. Dans tous les cas, même sans ces ancrages complé-

mentaires, vous pouvez créer des mécanismes de masquage plus accessibles.

Prenons comme exemple l'extrait suivant fondé sur jQuery :

(function(){ var $button = $('#myButton'), $text = $('#myText'), visible = true; $button.click(function(){ if ( visible ) { $text.slideUp('fast'); } else { $text.slideDown('fast'); } visible = ! visible; });})();

Ce script cherche deux éléments nommés #myButton et #myText, en les affectant

à deux variables locales nommées $button et $text, respectivement. Il définit

ensuite une troisième variable locale nommée visible qui permet de suivre

l'état courant des choses. Le script affecte ensuite un gestionnaire d'événe-

ments onclick à l'élément #myButton pour inverser la visibilité de #myText en

modifiant sa hauteur. Très simple, non ?

Ce script fonctionne comme prévu, sauf que jQuery utilise display: none

lorsque vous appelez slideUp(). En conséquence, #myText est masqué par une

méthode qui en empêche la lecture par un lecteur d'écran. Nous pouvons

effectuer une légère retouche à ce code pour ajouter une classe qui nous appar-

tient afin de rendre le contenu masqué plus accessible :

ADAPWEB.indb 94 17/04/13 12:47



ou ARIA en abrégé (Web Accessibility Initiative's Accessible Rich Internet

Applications)2.

Masquer du contenu avec ARIA est très simple, puisqu'il suffit d 'adopter

l 'attribut aria-hidden.

<p aria-hidden="true">Devinez ? Je suis masqué mais accessible grâce à ARIA.</p>

ARIA propose une série de rôles, d'états et de propriétés prédéfinis qui

peuvent s'avérer très utiles pour concevoir un site fortement fondé sur JavaS-

cript. Et certains éléments seront utiles pour construire des applications très

interactives. Découvrons-les d 'abord.

EMbAUCHER dEs gUidEsUn des nombreux aspects par lesquels ARIA améliore l 'accessibilité d'une

page web consiste à proposer des rôles de repères et de structures. La plupart

de ces rôles constitue une formalisation des éléments sémantiques que nous

avons tenté d'appliquer depuis des années à des éléments HTML en ajoutant

une classification sémantique et des identifiants (nous l 'avions évoqué dans

le Chapitre 2). Les rôles de repère et de structure d 'ARIA (ainsi que les rôles

de widgets que nous verrons bientôt) doivent être affectés à des éléments au

moyen de l 'attribut nommé role.

Je sais ce que vous allez dire : role n'est pas un attribut reconnu dans

HTML 4.x, ni dans XHTML 1.x. C'est vrai. ARIA ajoute un certain nombre

d'attributs au lexique du HTML. Il en résulte que vous ne pourrez pas valider

vos pages avec les mêmes définitions de type de document que d'habitude.

Pour valider des pages utilisant ARIA dans l'un de ces deux langages, il vous

faudra utiliser un nouveau jeu de DTD3 ou bien faire le saut vers HTML5

qui reconnaît les attributs du type role.

Voici un premier exemple utilisant ARIA :

2. http://www.w3.org/TR/wai-aria/

3. Pour HTML 4.01 plus WAI-ARIA, le DOCTYPE est <!DOCTYPE html PUBLIC "-//W3C//

DTD HTML+ARIA 1.0//EN" "http://www.w3.org/WAI/ARIA/schemata/html4-aria-1.dtd">.

Pour le XHTML plus WAI-ARIA, le DOCTYPE est <!DOCTYPE html PUBLIC "-//W3C//DTD

XHTML+ARIA 1.0//EN" "http://www.w3.org/WAI/ARIA/schemata/xhtml-aria-1.dtd">.

ADAPWEB.indb 96 17/04/13 12:47



<ol role="navigation"> <li><a href="#details">Details</a></li> <li><a href="#schedule">Schedule</a></li> <li><a href="#instructors">Instructors</a></li> <li><a href="#lodging">Lodging</a></li> <li><a href="#location">Location</a></li> </ol>

Vous reconnaissez le code HTML du Chapitre 2, puisque c'est celui des

éléments de navigation de la page Retreats 4 Geeks. La seule différence est

l 'ajout à l'élément ol d'un attribut role dont la valeur est "navigation". Vous

aurez deviné que le repère ARIA nommé "navigation" permet de préciser qu'un

élément fait partie d'un mécanisme de navigation dans la page.

Tous les rôles de repérage d'ARIA fournissent des informations concernant les

différentes régions de la page et permettent de naviguer globalement. Certaines

technologies d 'assistance permettent à l'utilisateur d 'accéder à ces repères ;

il peut ainsi naviguer directement d'une région à l 'autre avec le clavier ou

un autre moyen. Ces repères sont les successeurs logiques de cette flopée de

liens "aller à"4. En revanche, les rôles structurels sont des outils d'organisation

proches des éléments HTML5 tels que section et article.

Vous vous souvenez peut-être que dans l'exemple original, nous avions englobé

l'élément de navigation ol dans un nouvel élément HTML5 nommé nav. Une

brève réflexion vous permettra de conclure que cet élément nav est équivalent

au niveau sémantique au rôle de repère de "navigation". Sachez dès à présent

que ce n'est pas le seul domaine de chevauchement entre HTML5 et ARIA.

Redondant et raisonnableLes deux spécifications (HTML5 et ARIA) ont progressé de façon indépen-

dante au cours de la même période. Chacune a cherché à répondre aux

problèmes qu'elle considérait comme les plus urgents dans la norme actuelle du

HTML. (De là, la redondance inévitable.) La spécification ARIA est à l'heure

actuelle un peu plus mûre pour devenir une recommandation que HTML5.

La plupart de ces caractéristiques particulières sont de ce fait incorporées au

projet HTML5, dont la spécification continue d'évoluer. Nous pouvons sans

4. Les liens "Aller à" sont ceux qui permettent de sauter directement à une autre région de la

page avec un ancrage. Ce sont ceux qui portent des légendes du style "Aller au contenu" ou

"Aller au menu". Ils étaient très utilisés depuis des années, mais les rôles de repères ARIA

les rendent redondants.

ADAPWEB.indb 97 17/04/13 12:47



grand risque nous attendre à ce que les deux spécifications aient suffisamment

fusionné pour qu'il n'y ait quasiment plus de redondances au moment où

HTML5 aura atteint le statut Candidate Recommendation.

Pour l'instant, il reste beaucoup de doublons entre ARIA et HTML5, d'abord

au niveau des rôles structurels, et un peu moins au niveau des rôles de repères.

Le Tableau 5.2 donne un aperçu comparatif entre la sémantique traditionnelle,

le rôle ARIA équivalent et l'élément HTML5 qui atteint le même objectif,

s'il existe.

sÉMAnTiQUE Ad-HOC

RÔLE ARiA ÉLÉMEnT HTML5

signiFiCATiOn

#header, #top banner header

(approx.)

Région de la page ciblée

au niveau site et non au

niveau page

#main, #content main aucun Contenu focalisé dans le

document

#extra, .sidebar

complementary,

note

aside Section complémentaire

du document reliée au

contenu principal (le

contenu "complementary"

reste significatif, même

séparé du principal).

#footer, #bottom

contentinfo footer Région contenant des

informations au sujet du

document

#nav navigation nav Région contenant des liens

de navigation

.hentry article article Région de la page consti-

tuant une section indépen-

dante du document

Tableau 5.2 : Comparaison entre sémantique traditionnelle, rôle ARIA et

élément HTML5 éventuel.

Pour l'instant, on remarque des allers-retours entre la communauté définissant

le HTML5 et les défenseurs de l 'accessibilité. La question est de savoir

comment gérer la redondance. En termes pratiques, même si vous avez

ADAPWEB.indb 98 17/04/13 12:47



opté pour les équivalences sémantiques HTML5 du ARIA, il est conseillé

d 'ajouter les rôles de repères ARIA en doublons parce que toutes les techno-

logies d 'assistance ne gèrent pas les éléments HTML5 correspondants. En

revanche, pour les rôles structurels, vous faites comme bon vous semble, car

ce sont des éléments d'organisation qui n'entrent pas en ligne de compte pour

les technologies d 'assistance aux utilisateurs.

Une rapide lecture du code source de la page Retreats 4 Geeks permet de voir

cette redondance dans les éléments nav et footer. Lorsque les technologies

d 'assistance seront mises à jour pour HTML5, nous pourrons supprimer les

attributs de rôles devenus inutiles et éclaircir un peu notre code.

En plus des doublons avec HTML5, ARIA comporte plusieurs rôles qui

dupliquent la sémantique disponible depuis longtemps en HTML. C'est par

exemple le cas des rôles de repères et de structures ARIA suivants : column-

header, definition, form, heading, img, list, listitem, row, rowheader et

separator. Certains d'entre eux sont en équivalence univoque avec le HTML

(par exemple,"form"), alors que d'autres sont des variantes plus générales de ce

dont nous disposons en HTML (par exemple, "list").

Alors que l'on peut aisément concéder qu'il y ait quelques chevauchements

entre ARIA et HTML5 en raison de leur développement parallèle, vous

pourriez vous demander pourquoi ARIA cherche à recréer des éléments

sémantiques qui existent en HTML depuis plus de dix ans. La réponse est très

directe : pour une raison ou une autre, certaines entreprises (<humhum>Google</

humhum>) aiment employer un balisage non sémantique (par exemple, div)

comme structure de base de l'interface, en exploitant JavaScript pour que le

résultat ressemble à un contrôle HTML natif. Rien que pour cette raison,

ARIA définit des rôles qui sont en chevauchement. Vous ne me verrez

jamais utiliser un élément div dans un rôle de formulaire "form" (j'utilise tout

simplement un élément form, merci). Mais on ne discute pas des Goo et des

couleurs…

Nous avions dit plus haut que la page Retreats 4 Geeks employait plusieurs

des éléments HTML5 équivalents en termes sémantiques aux rôles de repères

et de structures d 'ARIA (nav, footer, article). Nous avons ajouté l'équi-

valent en rôle ARIA afin d'être certains de servir le plus grand nombre de

visiteurs. (Rappelons qu'il s'agit bien de l'objectif primordial de l 'amélioration

progressive). Mais nous n'en avons pas fini. Comme le montre le Tableau 5.2,

l'équivalent sémantique du rôle ARIA "banner" en élément header du HTML5

ADAPWEB.indb 99 17/04/13 12:47



peut se discuter. Pour être absolument clair dans le service que je rends à mes

visiteurs, j'ai donc ajouté ce rôle :

<header role="banner">

Le seul rôle que nous n'avons pas encore abordé pour l'instant (il n'est pas

encore géré en HTML5) correspond à "main". Il permet de désigner le contenu

focalisé du document. Dans le Chapitre 2, j'avais choisi d'englober dans un

élément section les différents éléments article de la page. J'avais choisi le

même élément comme racine de notre micro-format hCalendar. Cet élément

section rêve d'endosser le rôle de "main" :

<section id="content" class="vevent" role="main">

Ces deux simples retouches nous ont permis de prendre en compte tous les

rôles de repères qu'il semble utile d'exploiter dans le site Retreats 4 Geeks. Au

passage, nous avons amélioré l 'accessibilité globale de la page en permettant

aisément aux utilisateurs des technologies d 'assistance de naviguer dans le

document.

indispEnsAbLEs indiCEs ?La spécification ARIA fournit aux utilisateurs les moyens de naviguer dans

les documents, mais elle propose d 'autres fonctions utiles, et notamment une

collection de rôles et d'états de widgets.

Un rôle de widget (un composant d'interface) correspond à la description du

rôle d'un élément. Ces rôles sont en général classés en deux catégories : ceux

qui s'intéressent à la structure et les autres. En d 'autres termes, il y a ceux

des conteneurs et ceux des contenus que sont les composants. Les conteneurs

sont les éléments qui hébergent les composants d'un widget de l'interface.

Prenons comme exemple l'interface à onglets de la Figure 5.1. Une interface

à onglets se fonde sur deux parties : une liste d'onglets et une collection de

panneaux correspondant à ces onglets. Il en résulte trois rôles distincts en

ARIA : les onglets qui portent le rôle de "tab", la liste d'onglets qui porte le rôle

de "tablist", et le panneau correspondant à chaque onglet qui porte le rôle

de "tabpanel". Les deux rôles "tab" et "tabpanel" sont des rôles de composants

alors que "tablist" est un rôle de conteneur (la liste qui contient les onglets).

ADAPWEB.indb 100 17/04/13 12:47



Figure 5.1 : Exemple d'interface à onglets.

La spécification ARIA définit toute une série de rôles de widgets. Cela vous

permet de construire des contrôles complexes de formulaires (par exemple,

des curseurs de réglage et des sélecteurs numériques rotatifs) ou bien des

menus arborescents, des boîtes de dialogue modales ou même des interfaces

glisser-déposer, et tout cela en garantissant l 'accessibilité. Au niveau des rôles

de structures, ARIA permet de redéfinir un élément HTML n'ayant aucun

sens pour qu'il en prenne un en termes fonctionnels.

<div role="button">Je ne suis pas un vrai bouton, mais je fais comme si sur le web</div>

Tout cela est très prometteur, mais pour qu'un widget fonctionne, il faut

du code JavaScript. Habituellement, c'est un contexte auquel l 'accessibilité

n'a pas accès. La principale raison pour laquelle les techniques du type

Ajax ne s'entendent pas très bien avec l 'accessibilité est liée au fait que le

langage HTML ne propose aucun mécanisme permettant au code JavaS-

cript d'informer l'utilisateur (ou la technique d 'assistance qu'il a choisie) en

temps réel, hormis les deux techniques très élémentaires et intrusives que

sont alert() et confirm() (on pourrait les comparer à des perturbateurs qui

crient du fond de la classe).

ADAPWEB.indb 101 17/04/13 12:47



Dans ARIA, la gestion du contexte est confiée à des "états". Un état ARIA

correspond à un groupe d 'attributs pouvant être appliqués à quasiment tous

les éléments. Certains états sont globaux (ils s'appliquent à tous les éléments),

alors que d 'autres sont spécifiques au contexte de certains widgets. Tous ces

états portent un nom commençant par "aria-". Ils transmettent des informa-

tions utiles au visiteur concernant ce qui a changé pour un élément désigné.

Saviez-vous que vous connaissiez déjà l'un des ces états : aria-hidden ? Cet

attribut aria-hidden a été vu en début de chapitre. Il accepte une valeur

booléenne ("true" ou "false") et indique à l 'agent du poste client ou la techno-

logie d 'assistance s'il faut ou non faire connaître à l'utilisateur le contenu

concerné. Parmi les autres états ARIA prédéfinis, nous pouvons citer aria-

disabled, aria-expanded, aria-invalid, aria-pressed et aria-selected.

Si nous revenons à l'interface à onglets de la Figure 5.1, nous pouvons tirer

profit de l'état aria-hidden pour contrôler l'état des panneaux et de l'état

aria-selected pour gérer l'état des onglets.

Mais la spécification ARIA va plus loin encore. Elle définit des attributs

d'états, mais également un certain nombre de propriétés pouvant être associées

à un élément. Citons notamment aria-label, aria-labelledby, aria-readonly

et aria-required. La lecture de cette liste vous permet de deviner que la

plupart de ces propriétés sont destinées aux composants des formulaires,

bien que certaines (par exemple aria-controls) puissent s'appliquer à notre

interface à onglets.

Vous vous doutez sans doute qu'aria-controls a besoin d'une référence

id comme paramètre. Cet identifiant doit correspondre à l'élément dont le

contenu ou la présence est contrôlé par un autre élément auquel l 'attribut est

appliqué. Dans notre interface à onglets, c'est l'onglet qui contrôle le panneau

associé (comme le montre la Figure 5.2). Une fois que cette relation entre

onglets et panneau est établie, nous pouvons établir une autre relation, en

exploitant aria-labelledby. Le fonctionnement est exactement le même que

pour aria-controls.

ADAPWEB.indb 102 17/04/13 12:47



role="tab" id="recipe-0-tab" aria-controls="recipe-0"

role="tabpanel" id="recipe-0" aria-labelledby="recipe-0-tab"

Figure 5.2 : Grâce aux propriétés ARIA, nous pouvons mettre en relation les

différents composants de l'interface.

Les états et les propriétés ARIA aident beaucoup à maintenir l'utilisateur

informé. Voyons un autre concept ARIA qui est simple et dont l'intérêt

pratique est évident : les régions actives (Live Regions).

MAis C'EsT vivAnT !L'apparition du mécanisme Ajax et de la recrudescence du JavaScript ont

eu pour résultat qu'une des choses les plus désagréables dans l'expérience

utilisateur est devenue la mise à jour en temps réel de certaines régions d'une

page. Cela entraîne de nombreux problèmes d'usage, les deux principaux

étant les suivants : 1) les technologies d 'assistance n'étaient pas informées des

changements et n'avaient aucun moyen d'informer l'utilisateur à leur tour ;

et 2) un utilisateur qui effectue un zoom ou qui défile sur un appareil à petit

écran n'est pas informé des mises à jour du contenu qui se produisent en

dehors de la zone affichée. La spécification ARIA propose un attribut qui

résout directement ce problème : aria-live.

ADAPWEB.indb 103 17/04/13 12:47



Le plus étonnant dans aria-live est sa simplicité. Il suffit d 'appliquer cet

attribut à un élément pour contrôler quand et comment sa mise à jour est

communiquée à l'utilisateur. L'attribut aria-live accepte l'une des trois

valeurs suivantes :

1. "off" lorsque les mises à jour sont fréquentes et de peu d'importance,

comme dans le cas d'un flux dynamique de votre compte Twitter (n'est-ce

pas ?) ;

2. "polite" pour les mises à jour assez importantes pour en informer l'utili-

sateur lorsqu'il ne fait rien d 'autre, ce qui peut être le cas des grands titres

d'un magazine web lorsqu'ils sont mis à jour ;

3. "assertive" pour les mises à jour suffisamment importantes pour devoir

être immédiatement annoncées, ce qui est le cas des messages de validation

de formulaire.

Dans notre site Retreats 4 Geeks, nous pouvons valablement appliquer

l 'attribut aria-live au formulaire de contact :

<article id="contact" aria-live="assertive">

Cette simple retouche permet de garantir que l'utilisateur sera informé de

toute erreur pendant le remplissage du formulaire et d 'avoir la confirmation

que le formulaire a bien été transmis.

AdOpTiOn ET MAnQUEsDepuis son lancement, ARIA a fait l'objet d'un bon accueil de la commu-

nauté web. Au jour où nous écrivons ceci, tous les grands navigateurs ont

incorporé une certaine dose de support ARIA, de même pour les outils de

lecture d'écran répandus tels que JAWS, Windows Eyes, NVDA et Orca. De

grandes entreprises comme IBM, Sun Microsystems, Adobe, Yahoo! et Google

travaillent d 'arrache-pied à augmenter l'efficacité et l'exhaustivité d 'ARIA.

La communauté JavaScript a aussi adopté ARIA, les deux outils Dojo Dijits5

et jQuery UI6 ayant incorporé les rôles, états et propriétés ARIA dans leurs

composants. La spécification est encore en cours de développement et aucune

mise en place n'est encore complète, mais les progrès sont permanents.

5. http://dojotoolkit.org/widgets

6. http://jqueryui.com/

ADAPWEB.indb 104 17/04/13 12:47



Ce serait péché de ma part de ne pas mentionner le principal problème qui

empêche ARIA de se fondre harmonieusement dans notre approche d 'amé-

lioration progressive, tout du moins au niveau des rôles et des états des widgets.

En effet, nous ne disposons d'aucun moyen de tester la disponibilité du support

ARIA dans le navigateur ou dans la technologie d'assistance. Nous ne pouvons

donc pas bien décider comment exploiter au mieux chaque widget. Derek

Featherstone avait soulevé ce problème dans son excellent article pour le site

A List Apart sous le titre "ARIA and Progressive Enhancement7". J'en conseille

la lecture à tous ceux qui veulent mieux comprendre ce problème. Pour le

moment, aucune solution n'a encore été trouvée, mais croisons les doigts.

LEs RACCOURCis CLAviER, C'EsT biEnLe dernier sujet que je veux aborder avant de clore ce chapitre est l 'accessibilité

au moyen du clavier. L'utilisation systématique de la souris et la multiplication

des appareils tactiles tels que les tablettes font qu'il est assez facile d'oublier

notre bon vieux clavier, ce qui serait une grave erreur. Le clavier reste un outil

extrêmement pratique, et il constitue l'interface de prédilection de la plupart

des utilisateurs non-voyants tout autant que des utilisateurs chevronnés.

Nous avons appris beaucoup en ce qui concerne le clavier au cours des

dernières années. Nous avons tout d 'abord compris que les touches d 'accès

constituaient une bonne idée, mais que dans la pratique ce n'était pas si

intéressant8. Nous avons également compris qu'une application trop rigou-

reuse de l 'attribut tabindex pouvait plonger les utilisateurs dans une frénésie

de sauts d'un élément à l 'autre (et un énervement certain)9. Ce que nous avons

surtout découvert, c'est que nous pouvions nous servir du code JavaScript pour

modifier dynamiquement la valeur de l 'attribut tabindex pour simplifier le

cheminement de l'utilisateur parmi les différents composants d'un widget

complexe, comme c'est le cas d'une interface à onglets ou d'un formulaire en

accordéon.

À quoi correspond cette technique appelée jonglage tabindex ? Au cours de

l 'année 2005 (on n'a pas retrouvé l'origine exacte), quelqu'un a découvert qu'en

donnant la valeur "-1" à l 'attribut tabindex d'un élément, cela écartait l'élément

7. http://alistapart.com/articles/aria-and-progressive-enhancement/

8. http://www.wats.ca/show.php?contentid=32

9. http://webaim.org/techniques/keyboard/tabindex

ADAPWEB.indb 105 17/04/13 12:47



de la séquence de focalisation par la touche Tab dans le document10

. Ce qui

est intéressant, c'est que bien que le composant concerné ne fasse plus partie

de la séquence de tabulation dans le document, on peut encore le cibler en

code JavaScript (avec element.focus()), ce qui ouvre de nouvelles possibilités

pour contrôler précisément l'expérience de l'utilisateur.

Parcourons un scénario typique en revisitant l'interface à onglets présentée

un peu plus haut :

1. L'utilisateur arrive dans l'interface à onglets et actionne la touche Tab de

son clavier, ce qui focalise sur le premier onglet (qui est associé au panneau

actuellement affiché).

2. S'il actionne à nouveau la touche Tab ou le bouton du clavier tactile, le

focus passe à l'élément de contenu ciblable suivant en quittant la section

des onglets. Cela ne l'emmène pas à l'onglet suivant dans la liste.

3. S'il maintient la touche Maj tout en actionnant la touche Tab, il revient dans

la liste des onglets et réactive l'onglet courant.

4. Il peut utiliser les flèches du curseur pour circuler parmi les différents

onglets de la liste, en affichant à chaque fois le panneau correspondant.

5. S'il actionne la touche EnTréE pendant qu'il navigue dans la liste des onglets,

il focalise sur le panneau correspondant à l'onglet actif.

Je reconnais que cela représente beaucoup d'utilisation de la touche Tab (et un

défi remarquable). Cependant, en jouant bien avec tabindex et en ajoutant un

peu de code JavaScript, vous y arrivez aisément. Voici comment :

1. Vous commencez par affecter la valeur "-1" au tabindex de chacun des

onglets et panneaux, ce qui les écarte de la séquence de tabulation de la

page.

2. Vous réaffectez ensuite la valeur "0" à l'onglet courant pour le rapatrier

dans la séquence de tabulation à sa position par défaut.

3. En JavaScript, vous pouvez ensuite régler dynamiquement la propriété

tabindex de chacun des onglets en fonction des commandes frappées au

clavier par l'utilisateur, par exemple les touches gauche, droite, haut et

bas. Vous permettez ainsi à l'utilisateur de se déplacer facilement dans

l'interface.

10. Ce comportement a été particulièrement intéressant parce que, selon la spécification du

W3C, tabindex ne pouvait accepter une valeur qu'entre 0 et 32 767.

ADAPWEB.indb 106 17/04/13 12:47



Voici un extrait de la méthode nommée swap() de TabInterface qui montre

comment jongler avec tabindex (vous y trouvez également un peu de manipu-

lation des attributs ARIA et d'interversion d'éléments class) :

function swap( e ) { // ... // Désactivation du panneau et de l'onglet actifs removeClassName( old_tab, 'active' ); old_tab.setAttribute( 'aria-selected', 'false' ); old_tab.setAttribute( 'tabindex', '-1' ); removeClassName( old_folder, 'visible' ); old_folder.setAttribute( 'aria-hidden', 'true' ); // Activation du nouveau panneau et onglet addClassName( tab, 'active' ); tab.setAttribute( 'aria-selected', 'true' ); tab.setAttribute( 'tabindex', '0' ); addClassName( new_folder, 'visible' ); new_folder.setAttribute( 'aria-hidden', 'false' ); // ...}

Pour voir cette technique en pleine action, allez découvrir TabInterface.js sur

le site Github11

.

AgissEZ… ACCEssibLEL'accessibilité est un sujet complexe. Un peu de temps est nécessaire pour vous

y habituer, mais cela deviendra ensuite une seconde nature. Comme toutes les

autres techniques de ce livre, l 'accessibilité devra de préférence être appliquée

en plusieurs niveaux, afin de construire l'interface utilisateur progressivement.

Vous pourrez ainsi créer un résultat qui répondra aux attentes de tous vos

utilisateurs.

11. http://github.com/easy-designs/TabInterface.js

ADAPWEB.indb 107 17/04/13 12:47


"Quand tu veux construire un

bateau, ne commence pas par

rassembler du bois, couper des

planches et distribuer du travail,

mais réveille au sein des hommes

le désir de la mer grande et belle."

— AnTOinE dE sAinT-EXUpERY

ADAPWEB.indb 108 17/04/13 12:47


CHApiTRE 6

À EMPORTER

Nous avons visité bien des aspects durant cette courte promenade ensemble.

Nous avons vu l 'amélioration progressive en action, en partant d'un simple

document texte pour aboutir à une page web attrayante, fonctionnelle et

restant accessible à tous. Le rythme de croisière a été soutenu, mais nous

espérons que vous repartez avec une idée plus précise de ce qu'est l 'amélio-

ration progressive, pourquoi cela fonctionne et comment l'incorporer dans vos

prochains projets, au niveau conception et développement. Vous avez peut-être

déjà mis en pratique certaines techniques.

Bien que ce livre soit de pagination réduite et que nous ayons la chance de

pouvoir faire appel à un excellent concepteur d'index, vous pourriez aisément

ne plus savoir où a été abordé un concept que vous voudriez revoir. Je fournis à

cet effet dans les pages suivantes un rapide résumé des principales techniques

présentées, avec des conseils d'utilisation.

Cette checklist de l 'amélioration progressive vous permettra de vérifier que

vous tenez compte avec toute la considération requise des aspects essentiels

de l 'amélioration progressive.

À votre tour de mettre tout cela en pratique en concevant des choses superbes !

ADAPWEB.indb 109 17/04/13 12:47



LA CHECKLisT dE L'AMÉLiORATiOn pROgREssivEContenu & HTML (Chapitre 2)

❏ Un MAnUsCRiT/TApUsCRiT biEn RÉdigÉ ET nE pERdAnT pAs sOn sEns LORsQU'iL EsT LU pAR Un LECTEUR ÉCRAn AUdiO

Il s'agit du niveau fondamental de l'expérience utilisateur ; il doit faire

l'objet de tous vos soins. Nous donnons quelques pistes dans la biblio-

graphie.

❏ CHOisissEZ vOs ÉLÉMEnTs HTML En FOnCTiOn dE LEUR signiFiCATiOn

Le simple fait de tirer profit de la sémantique standard des éléments

(balises) HTML représente un grand pas vers une meilleure accessi-

bilité (et optimise le travail des moteurs de recherche).

❏ EXpLOiTEZ LEs MiCRO-FORMATs pOUR pALLiER LEs MAnQUEs dU HTML

Les micro-formats forment des extensions au lexique HTML et

sont reconnus par de nombreux navigateurs et plusieurs moteurs de

recherche.

❏ sERvEZ-vOUs dEs CLAssiFiCATiOns pOUR REgROUpER dEs ÉLÉMEnTs QUi pARTiCipEnT À LA MÊME FOnCTiOn

La classification (au moyen de l 'attribut class, par exemple) donne du

sens aux éléments HTML pour lesquels le standard n'en fournit pas

assez et lorsqu'il n'existe pas de micro-format approprié.

❏ idEnTiFiEZ LEs ÉLÉMEnTs sTRUCTURAnTs

L'identification (par exemple par l'utilisation de l 'attribut id) est une

excellente solution pour ajouter du contexte à une région de page ou

une instance spécifique d'un élément de classification.

ADAPWEB.indb 110 17/04/13 12:47

CHApiTRE 6 À EMpORTER 111

Css (Chapitre 3)

❏ vÉRiFiEZ MinUTiEUsEMEnT vOs sÉLECTEURs COMpOsiTEs

Vous prenez des risques en mélangeant des sélecteurs de niveaux de

complexité très différents, car lorsque le navigateur ne comprend pas un

des sélecteurs, il ignore tout le jeu de règles. Cela devient en revanche

une bonne astuce si votre but est de masquer tout un jeu de règles pour

les anciens navigateurs.

❏ ORgAnisEZ vOs RÈgLEs Css En pEnsAnT AU MÉCAnisME dE CAsCAdE

L'ordre d 'apparition est significatif. Une bonne organisation de vos

règles de styles vous aidera à concevoir une structure à amélioration

progressive, ce qui rendra votre code CSS plus facile à maintenir.

❏ MAsQUEZ LEs JEUX dE RÈgLEs Css RÉCEnTEs AUX AnCiEns nAvigATEURs

Un des plus puissants outils CSS pour masquer sélectivement des jeux

de règles est le bloc @media.

❏ gÉREZ LEs divERgEnCEs d'iE AvEC dEs COMMEnTAiREs COndiTiOnnELs

Les anciennes versions d'Internet Explorer sont réputées pour leurs

imperfections. Les Commentaires Conditionnels du type <!--[if IE…

constituent la meilleure technique pour ajouter des correctifs en CSS et

en JavaScript selon la version d'IE. Pensez à les organiser en séquence

descendante, de la plus récente à la plus ancienne version à gérer.

❏ AssUREZ-vOUs d'AvOiR pRis En COMpTE LEs MÉdiAs ET COnTEXTEs dE RECHAngE

Les désignations et les requêtes de médias permettent d 'adapter le

rendu visuel et l'interaction aux possibilités du contexte d'utilisation.

ADAPWEB.indb 111 17/04/13 12:47



Javascript (Chapitre 4)

❏ vÉRiFiEZ QUE vOTRE COdE JAvAsCRipT REsTE disCRET ET nOn bLOQUAnT

Les scripts doivent être les plus génériques possible et rester le moins

possible imbriqués avec le marquage. C'est ce qui vous permettra de les

reformuler de façon indépendante. Vos scripts JavaScript ne doivent

pas dépendre d'un marquage spécifique, mais être assez souples pour

pouvoir s'adapter aux évolutions du contenu de la page.

❏ vÉRiFiEZ QUE TOUT LE COnTEnU EsT ACCEssibLE ET QUE TOUTEs LEs ACTiOns indispEnsAbLEs pEUvEnT ÊTRE FAiTEs MÊME LORsQUE LE JAvAsCRipT EsT dÉsACTivÉ

Vous ne devez pas rendre la présence de JavaScript obligatoire. Un

point, c'est tout. Lorsque vous voulez enrichir la page avec du JavaS-

cript, adoptez l 'approche Hijax.

❏ sERvEZ-vOUs dE JAvAsCRipT pOUR gÉnÉRER TOUT LE MARQUAgE sUppLÉMEnTAiRE QU'iL nÉCEssiTE

JavaScript est un excellent outil pour appliquer des traitements au

modèle DOM. Il n'y a donc aucune raison pour injecter de façon figée

le marquage qui n'a été ajouté que pour le fonctionnement du script.

❏ sERvEZ-vOUs dE JAvAsCRipT pOUR ACTivER LEs sTYLEs LiÉs AU sCRipT

Une des situations les plus navrantes consiste à englober du contenu

dans un composant widget puis à constater que le widget ne fonctionne

pas, parce que JavaScript est désactivé ou que le script contient une

erreur. Prévoyez une option binaire pour que JavaScript active les

styles liés au widget.

❏ COnCEvEZ dEs sCRipTs dÉdiÉs dÈs QUE C'EsT pOssibLE

Essayez toujours de concevoir des scripts pouvant fonctionner en

indépendance et appliquez les tests unitaires qui vous permettent de

vérifier qu'ils sont autonomes.

ADAPWEB.indb 112 17/04/13 12:47



Accessibilité (Chapitre 5)

❏ EMpLOYEZ dEs REpÈREs ARiA pARTOUT OÙ iLs sOnT AppROpRiÉs

Si vous travaillez en HTML5, certains repères ARIA vous sembleront

redondants, mais il vaut mieux les prévoir aussi pour être paré. Leur

utilisation est facile et ils peuvent fortement augmenter l 'accessibilité

de vos pages.

❏ sERvEZ-vOUs dEs RÔLEs ET dEs ÉTATs ARiA pOUR dOnnER AUX UTiLisATEURs dEs dÉTAiLs sUR LEs WidgETs

Lorsque vous implantez un widget conçu en JavaScript, les utilisateurs

ont peu d'indices sur ce que déclenche leur interaction avec lui. Les

rôles et les états remplissent cette absence.

❏ sERvEZ-vOUs dE TAbindEX pOUR gUidER L'UTiLisATEUR pARMi LEs ÉLÉMEnTs inTERACTiFs dE LA pAgE

L'attribut tabindex permet d'établir une trajectoire à travers la page, et

guide l'utilisateur vite et bien vers les repères importants. Vous pouvez

aller plus loin en exploitant JavaScript pour décider à la volée de ce

qui peut ou ne peut pas être focalisé en fonction des interactions de

l'utilisateur avec les composants de la page.

ADAPWEB.indb 113 17/04/13 12:47



bibLiOgRApHiEContenu et rédaction

Livres parus

The Elements of Content Strategy par Erin Kissane, A Book Apart, 2011

Disponible en français chez Eyrolles : Stratégie de contenu Web (ISBN :

2212132794), traduction de Muriel Vandermeulen.

Content Strategy for the Web par Kristina Halvorson, New Riders, 2009

Articles sur le Web

"Writing Content that Works for a Living" par Erin Kissane, A List Apart

http://www.alistapart.com/articles/writingcontentthatworksfora-living/

"Reviving Anorexic Web Writing" par Amber Simmons, A List Apart

http://www.alistapart.com/articles/revivinganorexicwebwriting/

"Better Writing Through Design" par Bronwyn Jones

http://www.alistapart.com/articles/betterwritingthroughdesign/

"Calling All Designers: Learn to Write!" par Derek Powazek, A List Apart

http://www.alistapart.com/articles/learntowrite/

"Attack of the Zombie Copy" par Erin Kissane, A List Apart

http://www.alistapart.com/articles/zombiecopy/

ADAPWEB.indb 114 17/04/13 12:47



Marquage HTML

Livres parus

HTML5 for Web Designers par Jeremy Keith, A Book Apart, 2010

Disponible en français chez Eyrolles : HTML5 pour les web designers (ISBN :

2212128614), traduction de Charles Robert.

Web Standards Solutions: The Markup and Style Handbook, Special Edition

par Dan Cederholm, Friends of ED, 2009

Disponible en français chez Pearson : Bonnes pratiques des standards du web

(ISBN : 2744025720), traduction de Sandrine Burriel.

Designing with Web Standards, 3rd Edition par Jeffrey Zeldman et Ethan

Marcotte, New Riders, 2009

Developing with Web Standards par John Allsopp, New Riders, 2009

Microformats: Empowering Your Markup for Web 2.0 par John Allsopp,

Friends of ED, 2007

Articles sur le Web

"Where Our Standards Went Wrong" par Ethan Marcotte, A List Apart

http://www.alistapart.com/articles/whereourstandardswentwrong/

"How to Grok Web Standards" par Craig Cook, A List Apart

http://www.alistapart.com/articles/grokwebstandards/

"Using XHTML/CSS for an Effective SEO Campaign" par Brandon

Olejniczak, A List Apart

http://www.alistapart.com/articles/seo/

ADAPWEB.indb 115 17/04/13 12:47



Css

Livres parus

CSS3 for Web Designers par Dan Cederholm, A Book Apart, 2010

Disponible en français chez Eyrolles : CSS3 pour les Web Designers (ISBN :

2212129874), traduction de Charles Robert.

CSS Mastery: Advanced Web Standards Solutions, Second Edition par Simon

Collison, Andy Budd, Cameron Moll, Friends of ED, 2009

Disponible en français chez Pearson : Maîtrise des CSS (2e édition) (ISBN :

2744024465) traduction de Patrick Fabre.

More Eric Meyer on CSS par Eric Meyer, New Riders, 2004

En français, voyez ce livre du même auteur chez Pearson : CSS, techniques

professionnelles pour mise en page moderne (ISBN : 2744025763).

Handcrafted CSS: More Bulletproof Web Design par Dan Cederholm et Ethan

Marcotte, New Riders, 2009

Bulletproof Web Design: Improving flexibility and protecting against worst-

case scenarios with XHTML and CSS (2nd Edition) par Dan Cederholm,

New Riders, 2007

Eric Meyer on CSS: Mastering the Language of Web Design par Eric Meyer,

New Riders, 2002

Articles sur le Web

"Adaptive Layouts with Media Queries" par Aaron Gustafson,

.Net Magazine, Issue 205

ADAPWEB.indb 116 17/04/13 12:47



"Responsive Web Design" par Ethan Marcotte, A List Apart

http://www.alistapart.com/articles/responsive-web-design/

"Accessible Data Visualization with Web Standards" par Wilson Miner,

A List Apart

http://www.alistapart.com/articles/accessibledatavisualization/

"Big, Stark & Chunky" par Joe Clark, A List Apart

http://www.alistapart.com/articles/lowvision/

"Elastic Design" par Patrick Griffiths, A List Apart

http://www.alistapart.com/articles/elastic/

"CSS Design: Going to Print" par Eric Meyer, A List Apart

http://www.alistapart.com/articles/goingtoprint/

Javascript

Livres parus

Bulletproof Ajax par Jeremy Keith, New Riders, 2007

DOM Scripting par Jeremy Keith, Friends of ED, 2006

En français, nous conseillons JavaScript, les bons éléments de Douglas

Crockford (ISBN : 2744025828).

Articles sur le Web

"Test-Driven Progressive Enhancement" par Scott Jehl, A List Apart

http://www.alistapart.com/articles/testdriven/

"Behavioral Separation" par Jeremy Keith, A List Apart

http://www.alistapart.com/articles/behavioralseparation/

ADAPWEB.indb 117 17/04/13 12:47



"Improving Link Display for Print" par Aaron Gustafson, A List Apart

http://www.alistapart.com/articles/improvingprint/

"JavaScript Triggers" par Peter Paul Koch, A List Apart

http://www.alistapart.com/articles/scripttriggers/

Accessibilité & ARiA

Livres parus

Designing with Progressive Enhancement: Building the Web that Works for

Everyone par Todd Parker, Scott Jehl, Maggie Costello Wachs, Patty Toland,

New Riders, 2010

Just Ask: Integrating Accessibility Throughout Design par Shawn Lawton

Henry, Lulu, 2007

Design Accessible Web Sites: 36 Keys to Creating Content for All Audiences

and Platforms par Jeremy Sydik, Pragmatic Bookshelf, 2007

Articles sur le Web

"Accessible Web 2.0 Applications with WAI-ARIA" par Martin Kliehm,

A List Apart

http://www.alistapart.com/articles/waiaria/

"HTML5 and the myth of WAI-ARIA redundance" par Steve Faulkner,

The Paciello Group Blog

http://www.paciellogroup.com/blog/?p=585

"DHTML Style Guide" par AOL Developer Network

http://dev.aol.com/dhtml_style_guide

"Making Compact Forms More Accessible" par Mike Brittain, A List Apart

http://www.alistapart.com/articles/makingcompactformsmoreacces-sible/

ADAPWEB.indb 118 17/04/13 12:47



"High Accessibility Is Effective Search Engine Optimization" par Andy

Hagans, A List Apart

http://www.alistapart.com/articles/accessibilityseo/

"What Is Web Accessibility?" par Trenton Moss, A List Apart

http://www.alistapart.com/articles/wiwa/

ADAPWEB.indb 119 17/04/13 12:47


ADAPWEB.indb 120 17/04/13 12:47

Symboles.accordion 88

.accordion-on 88

.auto-submit 88

.auto-submit.active 88

<humhum> 99

<!--[if 57

@import 58

#intro 44

@media 58

.replaced 88

.replace-me 88

Aa 16

Aaron Gustafson vi, 116

abbr 16

Accessibilité

ARIA 91

checklist 113

et clavier 106

redondance 98

accessibly-hidden 95

Accordéon 92

INDEX

acronym 16

Adobe 9, 104

Adoption et manques 104

Adresse URL 26

AIR 9

Ajax 8, 73, 94, 101

A List Apart vi

Aller à 97

alt 20

Amber Simmons 114

Amélioration progressive

checklist 110

concept 1

couches 10

exemple illustré 53

Ancrage 76

Android 9

Andy Clarke 45

Apple 9

ARIA

attributs 96, 102

concept 12

état 102

et clavier 107

mécanisme 96

ADAPWEB.indb 121 17/04/13 12:47


NP AdApTivE WEb dEsign


repère 97

aria-controls 102

aria-disabled 102

aria-expanded 102

aria-hidden 102

aria-invalid 102

aria-label 102

aria-live 103

aria-pressed 102

aria-readonly 102

aria-required 102

aria-selected 102

article 27, 49

Attribut

CSS 40

ARIA 96

Bb 31

background-color 42

Blog 23

body 75

bold 41

border 54

Braille 58

Brandon Olejniczak 115

Brendan Eich 68

CCacahuète 6

Callback function 94

Chrome 9

class 22, 49

Classe d'activation 88

Classe racine 33

Clavier 97, 105

color 41

columnheader 99

Commentaires Conditionnels 56

Contenu

accès 1

checklist 110

collecte 7

comparaison 51

et CSS 39

masquage 93

Contraintes technologiques 1

Craig Cook 115

CSS

2.1 45

3 61

amélioration progressive 39

checklist 111

couleurs 42

CSS3 4

démonstration 43

et accessibilité 93

et écrans 62

guerres 45

liste 78

ordre 47

pannes 6

sélecteur 45

syntaxe 40

tolérance 39

versions 1

DDaltonisme 92

Dan Cederholm 115

Darwin 3

datetime 34

Dave Shea 44

definition 99

Dégradation élégante 4

Délégation d'événement 75

Derek Featherstone 105

description 33

Director 4

display 93

div 18

ADAPWEB.indb 122 17/04/13 12:47


<CHApnUM> <TiTRE CHApiTRE> np

indEX 123

div#content 22

document.all 69

document.getElementById 69

document.layers 69

Dojo Dijits 104

DOM 33, 69, 85, 112

Dropdown 78

dtend 33

dtstart 33

Eeasy-designs.net 71

Easy! Readers 130

ECMA 69

ECMAScript 69

Écran

étroit 63

large 63

largeur 61

Egor Kloos 43

element.focus 106

Epiphany 9

Eric Meyer vi, 25, 116, 117

Erin Kissane 114

Ethan Marcotte 115, 116

FFeuille de styles

et XFN 25

figure.focal 49

Flash 4, 12

Flickr 26

fn 28

Fonction de rappel 94

fondation sémantique 16

font 39

font-size 47

font-weight 41

footer 26, 99

form 99

Frisbee 20

GGawker Media 67

Gemination 43

Géospize 3

getAttribute 73

GIF 39

Gizmodo 67

Glenn Jones 26

Google 104

Hh1 16, 47

H2VX 27

Handicap

et HTML 16

et web 91

hAtom 26

hCalendar 26, 33, 100

hCard 26, 28

header 17

heading 99

hgroup 18

highlight 85

Hijax 73, 112

href 71

hResume 26

html 42

HTML

3.0 22

4.0 22

5 23

amélioration progressive 15

attributs 21

checklist 110

élément 15

élément b 31

et ARIA 97

HTML5 4

ADAPWEB.indb 123 17/04/13 12:47




pannes 6

sémantique 11

versions 1

HTTP 50, 72

IIBM 104

id 18

Ident Engine 26

IE8 56

IE9 56

Îles Galapagos 3

Image 17, 39

img 17, 99

Internet Explorer 68

versions 43, 56

iPhone 82

JJava 12

JavaScript

absence 19

accessibilité 92

Ajax 8

checklist 112

code source 70

collisions de styles 88

dépendance 67

désactiver 70

discret 72

erreurs 6, 83

et ARIA 96

et clavier 106

et HTML 68, 77

fiabilité 71

librairie 93

principes 68

JAWS 104

Jeffrey Zeldman vii, 115

Jeremy Keith 67, 73, 115

Jeu de règles 46

Joe Clark 117

John Allsopp 115

jQuery 83, 93, 104

JScript 68

KKelly iv

Kiosque 58

LLecteur d'écran 20

Lézard 2

Lifehacker 67

list 99

Liste déroulante 78

listitem 99

location 21, 33

Lodging 47

lte 57

Lynx 4, 19

MMacromedia 4

Maggie Costello Wachs 118

main.css 57

Malentendants 91

Manège interdit 8

margin 49

Martin Kliehm 118

Matthew Mullenweg 25

max-width 63

Mémoire 84

Microformat 22, 25

Microsoft 74

Mike Brittain 118

Mike Isolani 67

Minuterie 81

M&M's 6

ADAPWEB.indb 124 17/04/13 12:47



indEX 125

Mosaic 4

MOSe 43

Movable Type 26

Mozilla 44

Nnav 78, 97

Navigateur

blocage de l'accès 5

guerre 69

Lynx 4

Mosaic 4

NCSA 4

Netscape 68

Netscape Navigator 8

Non-voyants 91

NVDA 104

Ool 18

onclick 72, 74

Onglets 100

Oomph 27

Opera 44

Operator 27, 36

Optimus 27

Orca 104

Ordre des jeux de règles 47

org 28

PPageRank 16

parseFloat 84

Parsing error 40

Patrick Griffiths 117

Peter Paul Koch 118

Petit quiproquo, grands effets 56

photo 28

Pinson de Darwin 3

Pixels 61

Planification et retenue 89

Principe de tolérance 5

Propriété

CSS 40

ARIA 102

Protocoles 2

Prototype 93

px 49

RRadio 58

rel 25, 72

rel-nofollow 26

rel-tag 26

Remerciements iv

Requête de média 61

Restaurant 10

Retreats 4 Geeks 47, 80, 99

Retreats4Geeks.com 12

RGB 42

RGBa 41

role 28, 96

row 99

rowheader 99

SSafari 9, 44

Scott Jehl 117

screen 63

Script

capture et bullage 75

exécution 74

exemple de masquage 95

indépendance 112

section 27

select 78

Sélecteur 40

Sémantique ad hoc 21

separator 99

ADAPWEB.indb 125 17/04/13 12:47




setTimeout 81

Shawn Lawton 118

Showcase 9

showing 81

Site web

en rideau 67

HTML5 4

minimaliste 6

smartphone 7

tolérance aux pannes 4

slideDown 94

slideUp 94

Smartphone 7

Social Graph 26

Sons 11

Spiders 26

Steve Champeon 6

style 85

stylesheet 25

summary 33

Sun Microsystems 104

Symbian 9

Ttab 100

tabindex 105

TabInterface 107

table 15

Tablette 63, 105

tablist 100

tabpanel 100

Tantek Çelik 25

Target 91

Technologies d'assistance 92

Télévision 58

Terminaux portables 58

Tests unitaires 112

Tétranopie 92

text-indent 93

time 34

title 20, 45

Todd Parker 118

Trenton Moss 119

trigger 81

Twitter 26

Typographie 49

Uurl 28

URL 26

Vvcard 28, 45

vevent 33

Vidéos 11, 79

visibility 93

WW3C 58, 74, 106

WAI-ARIA 12

Web

et clavier 105

et télévision 58

information 7

W3C 58

Webkit 9

WebOS 9

Web Standards Project 6

Widget 87, 100, 113

Wilson Miner 117

WIM CROUWEL 14

Windows Eyes 104

WordPress 26

XXFN 25

XHTML 25

XML 18

XMLHttpRequest 74

ADAPWEB.indb 126 17/04/13 12:47



indEX 127

YYahoo! 104

ZZen Garden 43

Zoom 91

ADAPWEB.indb 127 17/04/13 12:47


129

À pROpOs dE L'AUTEURAaron Gustafson travaille dans le monde du Web depuis quinze ans, ce qui

lui a permis de renforcer son intérêt pour les standards du Web et d 'acquérir

de solides connaissances sur la stratégie et l 'architecture des sites web, sur

la conception des interfaces et sur de nombreux langages (parmi lesquels

XHTML, CSS, JavaScript et PHP). Aaron et sa femme Kelly McCarthy

sont propriétaires d'Easy! Designs, une agence de consultants web située à

Chattanooga, Tennessee. Lorsqu'il n'est pas plongé dans le code, Aaron est

en général en train de porter la bonne parole et de partager ses connaissances

avec les autres acteurs du milieu du Web.

Aaron a formé des professionnels au New York Times, chez Gartner et à

l 'agence US Environmental Protection Agency (entre autres). Il a pris la parole

dans les conférences web les plus vues, et notamment An Event Apart et Web

Directions. Il est chef de groupe du projet WaSP (Web Standards Project) et

Invited Expert à l 'alliance OWEA (World Wide Web Consortium's Open

Web Education Alliance). Il est fondateur d'eCSStender, éditeur technique

chez A List Apart, contributeur pour .net Magazine et a commencé à se

constituer une petite bibliothèque à partir de ses travaux d'auteur et d'éditeur

technique.

ADAPWEB.indb 129 17/04/13 12:47



À pROpOs d'EAsY REAdERsLes livres Easy! Readers sont des publications explorant les meilleures

pratiques et les standards du Web à destination des professionnels. Le grand

praticien du Web Aaron Gustafson et d 'autres ténors du Web ont produit

une collection de livres qui proposent une approche globale du design de

sites web de haute tenue.

Très orienté ergonomie et accessibilité, Easy! Readers se donne pour objectif

de guider le lecteur dans les origines, la philosophie et l 'application pratique

des différents sujets liés aux standards du Web. Le réseau web est un média

en évolution permanente en termes d'étendue, d'audience et d'infrastructure.

Nous nous engageons à repérer, puis vous proposer des contenus pertinents

à propos de ces évolutions.

ADAPWEB.indb 130 17/04/13 12:47


Créer des sites richesavec l’amélioration progressive

ADAPTIVEWEB DESIGN

Aaron GustafsonPréface de Jeffrey Zeldman

Le Web est en perpétuelle mutation : ses supports et ses usages, sa portée et ses

applications ne cessent de changer et d'évoluer. Si vous travaillez dans le Web, vous

avez certainement entendu parler l’amélioration progressive (progressive

enhancement). Mais que recouvre réellement cette notion ? Comment la rendre

opérante dans son travail de développement quotidien et dans le design de ses sites ?

Dans ce guide, Aaron Gustafson fait la genèse de l’amélioration progressive, explique

ses origines, sa philosophie, son fonctionnement et propose de nombreuses

techniques de mise en œuvre pour les langages HTML, CSS et JavaScript. Grâce à

l’amélioration progressive, vous remettrez les contenus au cœur de vos

développements, de façon à proposer des expériences qui servent les utilisateurs

plutôt que les navigateurs. Vous donnerez accès à vos contenus sans limite

technologique, pour les supports d’hier, d’aujourd’hui et de demain.

Adaptive Web Design constitue non seulement l’explication la plus claire et la plus

élégante de l’amélioration progressive que j’aie jamais lue, mais en plus, ce livre est

bourré de savoir-faire pratiques qui viennent s'installer directement dans votre

néocortex, grâce au style chaleureux et amical d'Aaron.

— Jeremy Keith, auteur de HTML5 pour les web designers

Enfin. L’amélioration progressive expliquée avec un parfait équilibre entre théorie et

pratique.

— Dan Cederholm, auteur de CSS3 pour les web designers

Aaron Gustafson a plus de 15 ans d’expérience dans le Web et a développé une connaissance profonde des standards du web, de l’architecture des sites, des stratégies de contenu et du design d’interface. Il dirige le Web Standards Projects (WaSP), est expert technique pourA List Apart, et contribue régulièrement à .Net Magazine.

ISBN : 978-2-7440-5600-0

www.pearson.fr

adaptivewebdesign.info

Adaptive web design - Aaron Gustafson.pdf

Documents

Transcript of Adaptive web design - Aaron Gustafson.pdf