Lisez-moi S.V.P. 

W3C

Les problèmes courants des agents utilisateurs

Il était une fois un agent utilisateur...

Note du W3C du 28 janvier 2003

Cette version :
http://www.w3.org/TR/2003/NOTE-cuap-20030128
Dernière version :
http://www.w3.org/TR/cuap
Version précédente :
http://www.w3.org/TR/2001/NOTE-cuap-20010206
Traductions de ce document :
http://www.w3.org/QA/translations#cuap
Rédacteur :
Karl Dubost, W3C
Auteurs et contributeurs :
Voir les remerciements.

Résumé

Ce document explique quelques erreurs courantes des agents utilisateurs, qui sont dues à une mise en œuvre incorrecte ou incomplète des spécifications, et suggère des remèdes. Il suggère également quelques « bonnes pratiques » quand les spécifications elles-mêmes ne définissent aucun comportement particulier (par exemple, face aux situations d'erreur). Ce document ne constitue pas l'ensemble complet des principes directeurs pour le bon comportement des agents utilisateurs.

Ce document n'incrimine aucun agent utilisateur particulier. Le W3C n'assure pas de manière générale le suivi des bogues ou des erreurs des mises en œuvre. Ces informations sont généralement collectées par les éditeurs des logiciels en question ou par des tiers.

Statut de ce document

Statut de la publication

Ce document, qui représente une mise à jour d'une précédente note, a été publié le 28 janvier 2003 et mis à disposition par le rédacteur et les auteurs seulement comme partie de leurs travaux en tant que participants de l'Équipe du W3C à l'activité Assurance Qualité. La publication de cette note par le W3C n'implique pas son adhésion, ni celle de l'Équipe ou des membres du W3C.

Ce document peut, à tout moment, être mis à jour, remplacé et rendu obsolète par d'autres documents.

Commentaires

Le W3C ne s'engage pas formellement à investir de ressources supplémentaires dans les thèmes abordés par cette note. Cependant, les commentaires sont bienvenus et l'équipe Assurance Qualité du W3C est susceptible de publier une version amendée, si tant est que la quantité et la qualité des commentaires reçus le méritaient ou l'exigeaient. Bien que des commentaires précédents aient été incorporés à cette version, certains d'entre eux font toujours l'objet de débats qui pourraient être rajoutés dans une version ultérieure. Nous prévoyons de publier dans les prochains mois une nouvelle version améliorée de ce document, qui empruntera la même organisation que la note CHIPS. Cette future version résoudra les problèmes liés à XHTML, à la déclaration du type de document (DOCTYPE) et aux espaces de nommage.

Veuillez envoyer vos commentaires sur la liste de diffusion du groupe d'intérêts Assurance Qualité à www-qa@w3.org (archives publiques).

On peut trouver une liste des erreurs reconnues et des corrections proposées à http://www.w3.org/QA/2002/12/cuap-errata.

Traductions

Les traductions de ce document sont bienvenues. Toutefois, avant de commencer une traduction, veuillez vous assurer d'avoir lu les informations à propos des traductions, dans notre FAQ sur les droits d'auteur, et vérifié la liste des traductions existantes de ce document (disponible à http://www.w3.org/QA/translations#cuap).

Autres rapports techniques et publications du W3C

On peut trouver une liste des rapports techniques et publications du W3C, y compris les avant-projets et les notes, à http://www.w3.org/TR/.


Table des matières


Introduction

Ce document explique quelques erreurs courantes des agents utilisateurs (navigateurs, robots, etc.), dues à la mise en œuvre incorrecte ou incomplète des spécifications, et suggère des remèdes. Il suggère également des « bonnes pratiques » quand les spécifications elles-mêmes ne définissent aucun comportement particulier (par exemple, face aux situations d'erreur).

Ce document n'aborde que les aspects côté client du protocole HTTP, les personnes recherchant les problèmes de mise en œuvre de HTTP dans les serveurs Web devraient se tourner vers la contrepartie serveur Web de ce document : Les problèmes courants des mises en œuvre de HTTP [CHIPS].

Ce document ne répond pas aux problèmes d'accessibilité des agents utilisateurs. Veuillez vous reporter aux principes directeurs pour l'accessibilité des agents utilisateurs 1.0 [UAAG10] pour des renseignements sur la façon de concevoir des agents utilisateurs qui soient accessibles aux personnes déficientes.

La portée de ce document

Ce document, qui réunit les problèmes connus et/ou les bonnes pratiques des mises en œuvre des agents utilisateurs et leur mise en œuvre, est destiné :

À moins d'une mention particulière, ce que l'on désigne dans le document par « HTTP » correspond à RFC2616, alias HTTP/1.1 [RFC2616].

Ce document ne revêt pas de conformité per se, mais puisqu'il traite de la mise en œuvre et de l'utilisation de spécifications normatives (telle que HTTP/1.1), on devrait considérer cet ensemble de principes comme une avancée vers la conformité à ces spécifications.

Le plus souvent possible, on mentionnera les références pour chaque point de contrôle.

Ce document emploie les mots-clés de RFC 2119 [RFC2119] (DOIT, PEUT, DEVRAIT, etc. en lettres capitales) quand il s'agit de comportements clairement définis par une spécification normative. Quand ils ne sont pas en lettres capitales, on devrait les interpréter comme des mots dans la langue courante et non comme des mots-clés RFC2119.


1. La convivialité

Cette section se concentre sur l'expérience utilisateur, y compris la personnalisation, l'interface utilisateur et d'autres questions de convivialité. Certains des points de contrôle suggérés ici dépendent des agents utilisateurs employés et parfois ne peuvent pas être mis en œuvre selon les mises en œuvre.

1.1 Quand l'utilisateur suit un lien vers une ancre cible, mettre en évidence la localisation de la cible.

Techniques :

Références :

1.2 Si l'utilisateur essaye de suivre un lien qui est rompu car l'ancre désignée est absente, informer l'utilisateur de la rupture du lien.

Il y a de nombreuses façons d'indiquer à l'utilisateur la rupture d'un lien. Le comportement recommandé est le suivant :

Incorrect : Certains agents utilisateurs effectue un défilement vers le haut ou le bas du document quand l'utilisateur essaye de suivre un lien rompu. On décourage ce comportement qui ne permet pas de le distinguer du celui correct correspondant à une cible située au début ou à la fin d'un document.

Références :

1.3 Permettre à l'utilisateur de récupérer des ressources Web même si le navigateur ne peut les restituer.

Les agents utilisateurs peuvent être incapables de restituer certains types de contenu trouvés sur le Web, que ce soit nativement ou au travers d'un module externe (par exemple, un contenu XML, une feuille de style XSLT, un document RDF, une défintion de type de docuemnt (DTD), un schéma XML, etc.). Les agents utilisateurs devraient laisser les utilisateurs récupérer et sauvegarder ces ressources, sinon ils pourraient ne pas pouvoir accéder du tout au contenu Web en question.

1.4 Quand l'utilisateur demande à imprimer un jeu d'encadrement, permettre à l'utilisateur de sélectionner entre un cadre individuel et le jeu d'encadrement pour une impression.

La présentation du jeu d'encadrement pourrait être obtenue, par exemple, en :

Remarque : Les auteurs n'encouragent pas les producteurs de contenu Web à utiliser des cadres dans la mesure où ceux-ci peuvent entraîner des problèmes de convivialité et d'accessibilité.

Références :

1.5 Ajouter la gestion directe des nouveaux systèmes d'adresse URI.

Par exemple, permettre aux utilisateurs d'associer des programmes externes aux systèmes d'adresse URI. L'agent utilisateur devrait signaler à l'utilisateur s'il ne reconnaît pas un système d'adresse URI dans le contenu.

Exemple :

Un utilisateur peut souhaiter que le système "tel" (par exemple, tel:+33-4-12-34) interagisse avec son téléphone. Ou, encore, souhaiter que le système "irc" (par exemple, irc://irc.example.org/) active un agent IRC sur sa station de travail et lance une connexion vers le serveur indiqué.

Incorrect : Certains agents utilisateurs ignore la partie système (celle avant le caractère « : »), quand ce système leur est inconnu, interprètent ce caractère deux-points comme s'il était codé par "%3A" puis traitent l'adresse URI comme s'il s'agissait d'une adresse URI relative, produisant généralement une rupture de lien (et plongeant les utilisateurs dans la confusion).

Références :

1.6 Permettre à l'utilisateur de surclasser tout mécanisme d'estimation des adresses URI ou des mots-clés.

De nombreux agents utilisateurs pallient aux adresses URI incomplètes en appliquant une série de transformations dans l'espoir de créer une adresse URI qui fonctionne. Par exemple, nombre d'agents utilisateurs transforme la chaîne www.w3.org en une adresse URI http://www.w3.org/. L'utilisateur devrait pouvoir contrôler, par exemple, si taper un mot-clé va initier une recherche sur le Web ou si l'agent utilisateur va lui ajouter un « http://www. » initial et lui adjoindre un « .org/ ».

1.7 Avertir les utilisateurs des documents ou des transferts incomplets.

La restitution d'un document incomplet, comme si celui-ci était complet, embrouillera vraisemblablement l'utilisateur. Une partie du document sera manquante, par conséquent certaines ancres pourraient être absentes, entraînant une rupture potentiell de certains liens. L'agent utilisateur devrait signaler à l'utilisateur qu'un document est incomplet.

La spécification HTTP/1.1 décrit ce comportement des caches au niveau du protocole. On devrait signaler à l'utilisateur les réponses partielles par un avertissement.

Références :

1.8 Fournir un mécanisme permettant l'expiration d'une information d'authentification.

Nombre de navigateurs permettent à une configuration de sauvegarder une information d'authentification HTTP [RFC2616, RFC2617] (« enregistrer mon mot de passe »). Ils devraient aussi permettre à l'utilisateur l'« évacuation » à la demande de cette information d'authentification. Par exemple, l'utilisateur peut vouloir laisser l'agent utilisateur en fonctionnement, mais lui indiquer d'oublier le mot de passe d'accès à son compte bancaire.

Incorrect : La plupart des agents utilisateurs considèrent que l'information d'authentification (par exemple, un mot de passe), qui est fournie par l'utilisateur pour un couple serveur/domaine lors d'une session, est inamovible pour la durée de la session.

1.9 Quand une ressource Web contient des métadonnées reconnaissables par l'agent utilisateur, permettre à l'utilisateur la consultation de ces métadonnées.

Les métadonnées (des données à propos de données) peuvent fournir aux utilisateurs un contexte très utile concernant des informations sur le Web. Par exemple, les métadonnées concernant un livre pourraient comprendre l'auteur du livre, le titre, la date de publication, l'éditeur, etc. (cf. l'initiative Dublin Core [DC] pour des renseignements sur les métadonnées de type librairie). Les auteurs introduisent des métadonnées dans les documents HTML au travers de divers éléments et attributs (par exemple, les éléments TITLE et ADDRESS, les attributs "alt", "title" et "summary", etc.). Les langages, tel que le langage cadre de description des ressources [RDF], permettent aux utilisateurs de peupler le Web avec des métadonnées d'une grande richesse. Les agents utilisateurs devraient fournir une interface utilisateur qui autorisent les utilisateurs à prendre connaissance des métadonnées. L'interface utilisateur pourra varier en fonction du langage de balisage sous-jacent. Par exemple, nombre de navigateurs graphiques restituent l'attribut HTML "title" (par exemple, sous forme d'une infobulle) quand l'utilisateur sélectionne ou survole un élément comprenant cet attribut.

Références :

1.10 Permettre à l'utilisateur de conserver les traces des requêtes HTTP POST achevées.

Les utilisateurs peuvent souhaiter suivre et archiver les requêtes HTTP POST pour les mêmes raisons qu'ils peuvent souhaiter suivre et archiver les courriers électroniques. Par exemple, si l'utilisateur effectue la commande d'un livre au travers d'un formulaire et que ce formulaire utilise une requête POST, celui-ci devrait pouvoir enregistrer les informations concernant cette transaction.

Références :

1.11 Permettre à l'utilisateur de mettre des signets sur les ressources négociées.

Le protocole HTTP/1.1 [RFC2616] permet à l'agent utilisateur de requérir la représentation d'une ressource qui convient le mieux à ses besoins (langue, type de média, etc.) : on appelle ce mécanisme « négociation de contenu ».

Quand une ressource est négociée, l'utilisateur peut vouloir placer un signet d'une version particulière de celle-ci. Par exemple, un document est peut-être disponible en plusieurs langues avec la même adresse URI et l'utilisateur peut vouloir orienter quelqu'un vers la version canadienne de ce document, qui a une adresse URI différente.

Dans un tel cas, il devrait être possible de placer un signet soit sur l'adresse URI originale, soit sur l'adresse URI de la vue obtenue par l'utilisateur. On pourrait interpréter l'adresse URI originale comme étant l'objet générique et le document récupéré comme une vue de cet objet.

Le placement d'un signet d'une version particulière d'une ressource négociée n'est pas toujours possible avec la sémantique HTTP parce que, premièrement, la version particulière peut ne pas avoir sa propre adresse URI et, deuxièmement, même si c'était le cas, HTTP ne garantit pas que l'agent utilisateur en sera informé.

HTTP/1.1 définit le champs de l'en-tête Content-Location comme moyen pour le serveur d'indiquer l'adresse URI de la variante, et certains serveurs fournissent correctement cette en-tête la plupart du temps au moment de la négociation. Cependant, l'en-tête Content-Location a aussi d'autres usages et sa présence dans une réponse ne signifie pas forcément qu'une négociation de contenu sera intervenue.

Références :

1.12 Gérer des mécanismes de codage de transfert économes en temps et émettre des en-têtes TE annonçant leur reconnaissance.

HTTP/1.1 [RFC2616] autorise le codage de transfert. Comme exemple de codage, la compression des données qui accélère la navigation Web au travers d'une connexion lente.

Le mécanisme de négociation du codage de transfert HTTP/1.1 a été conçu de manière à éviter l'intervention de l'utilisateur final. En utilisant le protocole HTTP, les mises en œuvre des serveurs, des serveurs mandataires et des agents utilisateurs vont pouvoir déterminer entre elles le codage de transfert le plus efficace et l'utiliser. Plus on favorise ces mécanismes, mieux c'est.

Les utilisateurs pourraient avoir des connaissances suffisantes ou obtenir l'aide d'interfaces utilisateurs pour ajuster ce processus au-delà de ce qui peut être réalisé automatiquement. L'agent utilisateur devrait permettre à l'utilisateur de régler le codage de transfert dans la requête HTTP qui est émise.

Références :

1.13 Employer la langue de l'interface utilisateur comme valeur par défaut pour la négociation de la langue.

L'utilisateur devrait pouvoir définir le jeu des langues que l'agent utilisateur utilisera pour la négociation de la langue.

Au cas où l'utilisateur ne définit aucune langue, l'agent utilisateur peut indiquer la langue de son interface utilisateur comme langue préférée, tout en autorisant les autres langues de moindre préférence, par exemple, en envoyant :

Accept-Language: dk, *;q=0.5

Références :

1.14 Seulement annoncer dans l'en-tête Accept-encoding le codage que vous acceptez vraiment.

Un certain nombre de sites Web souffrent d'une bande passante surchargée. En modifiant le moteur de scripts côté serveur pour gérer un codage de compression ou en insérant un serveur mandataire de compression, il est possible de réduire spectaculairement les coûts de fonctionnement. Le mauvais côté, c'est que nombre d'agents utilisateurs annoncent pouvoir gérer une compression/décompression gzip tandis qu'ils en sont incapables en réalité.

Références :

1.15 Se rappeler les redirections traversées.

Quand le navigateur rencontre une redirection, il devrait se remémorer l'adresse URI originale ainsi que l'adresse URI cible afin de marquer les liens déjà visités.

2. La restitution

Cette section se concentre sur les questions relatives aux feuilles de style et aux types des liens.

2.1 Mettre en œuvre les feuilles de style de l'utilisateur. Autoriser l'utilisateur à faire une sélection entre les feuilles de style de l'auteur et les siennes, ou les ignorer toutes.

Une feuille de style est un ensemble de règles qui régissent la manière de restituer un document sur le moniteur graphique d'un ordinateur de bureau, sur du papier, comme parole synthétisées, etc. Un document peut avoir plusieurs feuilles de style associées et les utilisateurs devraient pouvoir choisir d'autres feuilles de style.

Références :

2.2 Respecter les descripteurs de média lors de l'application des feuilles de style.

Certains langages de balisage et de feuille de style autorisent les auteurs (par exemple, la construction @media dans [CSS2], l'attribut media dans [HTML 4.01]) à concevoir des documents qui seront restitués différemment en fonction des caractéristiques de l'appareil de sortie, pour un affichage graphique, un écran de télévision, un appareil mobile, un synthétiseur de parole, un terminal Braille, etc.

Références :

2.3 Si une feuille de style CSS manque, l'ignorer et poursuivre le traitement.

Les utilisateurs doivent pouvoir consulter un contenu même en l'absence de feuilles de style CSS.

Incorrect : Pour certains agents utilisateurs, l'absence des feuilles de style provoque une erreur irrémédiable ou la non restitution du contenu.

Références :

2.4 Mettre en œuvre les types de lien HTML 4 reconnus.

La section 6.12 de la recommandation HTML 4.01 [HTML 4.01] liste quelques types de lien qui peuvent être utilisés par les auteurs pour faire des estimations sur les ressources Web désignées. Cette liste comprend les types alternate, stylesheet, start, next, prev, contents, glossary et d'autres. Bien que la spécification HTML 4.01 ne définisse pas de restitution ou de comportement particuliers pour ces types de liens, les agents utilisateurs devraient les interpréter de manière utile. Par exemple, les types de lien start, next, prev et contents peuvent servir à construire une table des matières ou à identifier l'ordre d'impression des documents, etc.

3. La mise en œuvre des protocoles

Cette section se concentre sur la mise en œuvre des protocoles de réseau employés pour le téléchargement des ressources issues du Web.

3.1 Sauvegarder les ressources récupérées du Web sur le système local en utilisant les conventions de nommage appropriées du système.

Le type de média d'une ressource récupérée par HTTP [RFC2616] est déterminé par le type de contenu et le codage renvoyés par le serveur dans les en-têtes de réponse.

Si l'utilisateur désire sauvegarder une ressource localement, l'agent utilisateur devrait respecter les conventions de nommage des fichiers du système (par exemple, les images PNG ont habituellement l'extension .png).

Exemple :

http://www.w3.org/TR/1999/REC-html401-19991224/html40.ps est une vue de la version PostScript compressée dans le format gzip de la spécification HTML 4.01. Les en-têtes HTTP envoyées par le serveur comprennent :

Content-Type: application/postscript; qs=0.001
Content-Encoding: gzip

Sauvegardé localement, le nom de fichier sur la plupart des ordinateurs devrait être html40.ps.gz pour que les applications puissent reconnaître le type du fichier.

Incorrect : La sauvegarde de ce document PostScript compressé sous la forme html40.ps peut vraisemblablement embrouiller d'autres applications.

Références :

3.2 Respecter le type de média d'une ressource si celui-ci est donné explicitement par l'en-tête HTTP Content-Type.

Exemple :

Si un document est renvoyé avec pour l'en-tête Content-Type la valeur "text/plain", l'agent utilisateur NE DOIT PAS restituer le document à partir d'une autre valeur estimée pour l'en-tête Content-Type (par exemple, comme "text/html").

Référence :

3.3 Respecter le jeu de caractères d'une ressource quand il y en a un explicite.

Les agents utilisateurs doivent respecter le jeu de caractères quand il est indiqué explicitement dans l'en-tête de réponse. Le jeu de caractères peut être donné par les en-têtes HTTP Content-Type et/ou la solution de repli interne du document (l'élément HTML meta, etc.).

Références :

3.4 Ne pas traiter les redirections temporaires HTTP comme des redirections permanentes.

La spécification HTTP/1.1 [RFC2616] définit plusieurs types de redirections. Les deux les plus courantes sont désignées par les codes 301 (permanente), et 302 ou 307 (temporaire) :

Incorrect : Les agents utilisateurs montrent habituellement à l'utilisateur (dans l'interface utilisateur) l'adresse URI qui est l'aboutissement d'une redirection temporaire (302 ou 307), comme ils le feraient pour une redirection permanente (301).

Références :

3.5 Si un nom d'hôte a plusieurs entrées DNS, les essayer toutes avant de conclure au non-fonctionnement du site Web.

Nombre de sites Web ont un seul nom d'hôte, comme « www.example.org », qui se résoud en plusieurs serveurs pour répartition de la charge ou redondance. Qu'un serveur soit injoignable, les autres peuvent encore l'être, par conséquent les navigateurs devraient essayer de contacter tous les serveurs d'un site Web avant de conclure que le site est hors service.

Par exemple, la bibliothèque libwww agit correctement et vérifie le temps de réponse de toutes les adresses IP ; une fois cela fait, elle effectue un tri sur toutes les adresses et retient la meilleure. On peut en voir un exemple dans la mise en œuvre en code source libre de la classe de service de noms de domaine.

3.6 Lister seulement les types de média reconnus dans l'en-tête HTTP Accept.

Le protocole HTTP/1.1 [RFC2616] définit la négociation de contenu. L'agent utilisateur, qui émet une requête, donne la liste des types de média qu'il est prêt à recevoir ; le serveur renvoie alors une représentation de l'objet requis, dans l'un des formats indiqués, quand il est disponible.

Quand des entités sont incorporées dans un document (telles que les images dans les documents HTML), Les agents utilisateurs devraient seulement envoyer les en-têtes Accept des formats qu'ils reconnaissent.

Exemple :

Si un agent utilisateur peut restituer des images JPEG, PNG et GIF, la liste des types de média acceptés devrait comprendre les types image/jpeg, image/png, image/gif.

Incorrect : Les agents utilisateurs ne devraient pas envoyer une en-tête HTTP Accept: */*, puisque le serveur pourrait gérer des types de contenu que l'agent utilisateur ne pourrait pas. Par exemple, si un serveur est configuré de sorte que les images SVG soient préférées aux images PNG, un agent utilisateur qui ne reconnaît que les formats PNG, GIF et JPEG recevra du SVG (non reconnu) plutôt que du PNG (reconnu).

Remarque : Certains agents utilisateurs envoient une en-tête Accept qui propose l'instruction "*/*" à la fin, après tous les types de contenu reconnus. De cette façon, le serveur est libre d'envoyer la ressource dans tout format, qui pourra alors être traité par l'utilisateur avec un autre outil.

Références :

4. La gestion des adresses URI

Les ressources se localisent sur le Web en utilisant des identificateurs de ressource uniformes [RFC2396]. Cette section présente la façon dont les agents utilisateurs devraient gérer les adresses URI.

4.1 Prendre en charge l'identificateur de fragment de l'adresse URI quand la requête HTTP est redirigée.

Quand une ressource (URI1) a bougé, une redirection HTTP peut en indiquer la nouvelle localisation (URI2).

Si URI1 comprend un identificateur de fragment #frag, alors la nouvelle cible que l'agent utilisateur devrait essayer d'atteindre serait URI2#frag. Si URI2 comprend déjà un identificateur de fragment, alors #frag ne doit pas lui être adjoint et la nouvelle cible est URI2.

Incorrect : La plupart des agents utilisateurs interprètent bien les redirections mais n'ajoutent pas l'identificateur de fragment à la nouvelle adresse URI, ce qui embrouille en général l'utilisateur parce qu'il se retrouve en fin de compte avec la mauvaise ressource.

Références :

Exemple :

Supposons qu'un utilisateur demande la ressource localisée à http://www.w3.org/TR/WD-ruby/#changes et que le serveur redirige l'agent utilisateur sur http://www.w3.org/TR/ruby/. Avant de rapporter cette dernière adresse URI, le navigateur devrait lui adjoindre l'identificateur de fragment #changes : http://www.w3.org/TR/ruby/#changes.

Remerciements

Le rédacteur voudrait remercier les membres suivants de l'équipe du W3C pour l'élan initial qui a conduit à la création de ce document. Hugo Haas a été l'auteur principal de la première version de ce document :

Le rédacteur voudrait aussi remercier les personnes suivantes pour leur relecture du document :

Références

CC/PP
« Les profils composés capacité/préférence (CC/PP) : un cadre côté utilisateur pour la négociation de contenu », Franklin Reynolds, Johan Hjelm, Spencer Dawkins, Sandeep Singhal, 27 juillet 1999.
Disponible à http://www.w3.org/1999/07/NOTE-CCPP-19990727/.
CHIPS
« Les problèmes courants des implémentations de HTTP », Olivier Thereaux, 28 janvier 2003.
Disponible à http://www.w3.org/TR/2003/NOTE-chips-20030128/. Dernière version disponible à http://www.w3.org/TR/chips.
CSS2
« Les feuilles de style en cascade, niveau 2 », Bert Bos, Håkon Wium Lie, Chris Lilley, Ian Jacobs, 12 mai 1998.
Disponible à http://www.w3.org/TR/1998/REC-CSS2-19980512/.
DC
Dublin Core.
Disponible à http://www.dublincore.org/.
HTML 4.01
« La spécification HTML 4.01 », Dave Raggett, Arnaud Le Hors, Ian Jacobs, 24 décembre 1999.
Disponible à http://www.w3.org/TR/1999/REC-html401-19991224/.
PURL
« Introduction aux localisateurs de ressource uniformes persistents », Keith Shafer, Stuart Weibel, Erik Jul, Jon Fausey.
Disponible à http://purl.oclc.org/OCLC/PURL/INET96.
RDF
« La spécification du cadre de description des ressources (RDF) - modèle et syntaxe », Ora Lassila, Ralph R. Swick, 22 février 1999.
Disponible à http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/.
RFC1630
« Les identificateurs de ressource uniformes dans le WWW », T. Berners-Lee, juin 1994.
Disponible à http://www.ietf.org/rfc/rfc1630.txt.
RFC2119
« Les mots-clés à utiliser dans les RFC pour indiquer les niveaux d'exigence », S. Bradner, mars 1997.
Disponible à http://www.ietf.org/rfc/rfc2119.txt
RFC2396
« Les identificateurs de ressource uniformes (URI) : syntaxe générique », T. Berners-Lee et al., août 1998.
Disponible à http://www.ietf.org/rfc/rfc2396.txt.
RFC2616
« Le protocole de transfert hypertexte -- HTTP/1.1 », R. Fielding et al., juin 1999.
Disponible à http://www.ietf.org/rfc/rfc2616.txt.
RFC2617
« L'authentification HTTP : accès par authentification de base et prétraitée », J. Franks et al., juin 1999.
Disponible à http://www.ietf.org/rfc/rfc2617.txt.
RFC2717
« Les procédures d'enregistrement des noms de systèmes d'adresse URI », R. Petke et al., novembre 1999.
Disponible à http://www.ietf.org/rfc/rfc2717.txt.
RURL
« La gestion des identificateurs de fragment dans les URL redirigés », B. Bos, 30 juin 1999.
Disponible à http://www.ics.uci.edu/pub/ietf/http/draft-bos-http-redirect-00.txt.
SCHEMES
« Un index des systèmes d'adressage WWW », Dan Connolly, 2000.
Disponible à http://www.w3.org/Addressing/schemes.
SCHEMES-IANA
« Les systèmes des identificateurs de ressource uniformes (URI) », IANA.
Disponible à http://www.iana.org/assignments/uri-schemes.
SELECTORS
« Les sélecteurs », Daniel Glazman et al., 13 novembre 2001.
Disponible à http://www.w3.org/TR/2001/CR-css3-selectors-20011113/.
UAAG10
« Les principes directeurs de l'accessibilité pour les agents utilisateurs 1.0 », Jon Gunderson, Ian Jacobs, 17 décembre 2002.
Disponible à http://www.w3.org/TR/2002/REC-UAAG10-20021217/.
UAWP
« Les axiomes de l'architecture du Web : les points de vérification des agents utilisateurs », Tim Berners-Lee, 1998.
Disponible à http://www.w3.org/DesignIssues/UserAgent.
XML-STYLE
« Associer des feuilles de style aux documents XML version 1.0 », James Clark, 29 juin 1999.
Disponible à http://www.w3.org/1999/06/REC-xml-stylesheet-19990629/.