Sommaire

  1. Introduction
  2. Historique
  3. Standards du Web
  4. Structure et présentation
  5. (X)HTML
  6. CSS
  7. Accessibilité
  8. URL
  9. Références
  10. Glossaire
  11. Traduction

1. Introduction

Ce document a pour but de vous expliquer comment et pourquoi les standards du Web vous permettent de construire des sites Web plus vite et à moindre coût, tout en offrant une meilleure expérience utilisateur. Vous découvrirez également des méthodes de travail, des recommandations et des conseils pratiques pour produire des sites de qualité accessibles au plus grand nombre.

2. Historique

Dans la seconde moitié des années 90, alors qu'Internet et le Web devenaient grand public, les navigateurs Web n'implémentaient pas encore les CSS (Cascading Style Sheets), ou juste assez pour que les développeurs Web les utilisent pour contrôler quelques éléments de présentation d'un document HTML. Les lacunes dans le domaine sont compréhensibles, étant donné que la spécification CSS 1 a été publiée en 1996 et CSS 2 en 1998.

Le manque de support CSS dans les navigateurs combiné aux exigences des graphistes d'un contrôle au pixel près - comme c'est le cas dans le milieu de l'édition - a conduit vers une perversion du langage HTML à des fins de présentation. Un exemple de ce phénomène est apparu lorsque des designers se sont rendus compte qu'en affectant l'attribut border="0" pour cacher les bordures d'un tableau, une grille invisible et utilisable pour la mise en page se formait. On a aussi été amené à utiliser des GIF transparents - donc invisibles - pour caler des mises en page.

Comme le langage HTML n'a jamais été conçu pour régir la présentation de documents, on a utilisé des détournements, balises propriétaires, ou plus généralement, de code invalide. La validation était un processus que très peu de gens connaissaient ou utilisaient. Le terme de tag soup (littéralement "soupe de balises") définit à merveille ce genre de code.

3. Standards du Web

Standards du Web, quésako ?

Les standards du Web sont des technologies établies par le W3C et d'autres organismes de normalisation pour créer et interpréter du contenu Web. Ces technologies sont conçues pour créer des documents pérennes et accessibles à tous.

Langages structurels

Langages de présentation

Modèle d'objet

Langages de script

Le présent document se concentre sur XHTML 1.0 pour la structure, CSS 1 et 2 pour la présentation, et ECMAScript 262 pour le script.

Quand on dit d'un document qu'il est conforme aux standards du Web, on admet, en plus des technologies évoquées ci-dessus, qu'il :

Notez que " fonctionne dans n'importe quel navigateur Web " ne veut pas dire " offre le même rendu graphique dans tous les navigateurs ". Faire un document visuellement identique dans tous les navigateurs est presque impossible. Même un site n'utilisant que des images ne peut le garantir. Un document publié sur le Web sera consulté par une grande variété de navigateurs fonctionnant sur divers systèmes d'exploitation, avec des écrans (s'il y en a un) de tailles et de résolutions différentes, et ce, par des utilisateurs ayant peut-être changé les paramètres par défaut (taille de police, etc.). Accepter cette réalité vous rendra la vie bien moins frustrante. N'importe quel créateur de site doit bien comprendre qu'il existe des pré-requis techniques à prendre en compte, de la même manière qu'il y en a pour les gens qui travaillent dans le monde de l'édition papier, réalisent des films ou des émissions télévisées.

Pourquoi utiliser les standards du Web ?

Certains développeurs Web ont une réticence à utiliser les standards. Les arguments habituels sont " C'est trop difficile ", " Ma méthode marche de toute manière " ou " Mes outils produisent du code invalide ".

Il est normal d'avoir cette réaction épidermique et de rechigner à apprendre quelque chose de nouveau en abandonnant des méthodes auxquelles on est habituées. Néanmoins, avec un peu de recul, vous découvrirez vite que les avantages des standards du Web sont nombreux. Quelques exemples :

Les standards du Web peuvent vous faire économiser du temps et de l'argent, tout en offrant une meilleure expérience utilisateur à vos visiteurs. De plus, les standards du Web constituent la voie du futur. Si vous ne les utilisez pas déjà, il est temps de vous y mettre, sinon vous risqueriez de manquer le coche.

En savoir plus :

Validation

On appelle " validation " le processus consistant à contrôler que la structure obéit aux règles du langage utilisé dans le document. Vous pouvez le comparer à un système de correction syntaxique orthographique ou grammatical.

La validation est une étape importante du développement Web. Beaucoup d'erreurs difficiles à déceler apparaissent lors de cette phase. Celles-ci peuvent être aussi triviales qu'une faute de frappe ou, au contraire, contenir une syntaxe de balise ou d'attribut invalide.

Malheureusement, de nombreux programmeurs ne valident pas leurs documents. Certaines personnes ne connaissent pas le processus, d'autres oublient de valider et d'autres encore ignorent intentionnellement cette étape. Cette situation peut être facilement imputée aux concepteurs des navigateurs Web. La plupart d'entre eux font tout pour interpréter au mieux du HTML invalide, essayant de deviner les intentions de l'auteur au lieu d'afficher un message d'erreur. C'est ce comportement qui a encouragé la généralisation d'un balisage HTML bancal. Le problème avec ce genre de code, c'est que le rendu est imprévisible, car il dépend de la manière dont le navigateur interprète les erreurs.

Il n'y a aucune raison de ne pas valider son HTML et sa CSS. Au contraire, il n'y a que des avantages.

Why we won't help you offre une excellente explication sur ces avantages. L'article explique aussi pourquoi il peut être difficile d'obtenir de l'aide sur des forums ou des listes de discussion si vous n'avez pas validé vos documents au préalable.

Plusieurs éditeurs HTML tels que BBEdit ou Homesite ont des outils de validation intégrés. Si votre outil de développement Web n'offre pas cette fonctionnalité, vous pouvez utiliser les outils de validation en ligne du W3C :

La compréhension des messages d'erreur peut parfois se révéler ardue. Une erreur survenant tôt dans le document peut engendrer une série d'erreurs en cascade. Réparer la première erreur et valider à nouveau sa page permettra souvent de réduire le nombre d'erreurs d'une manière significative. Quelques erreurs parmi les plus communes sont expliquées dans Common XHTML Validation Errors, proposé chez Black Widow Web Design.

S'assurer que son code est valide est toujours une bonne chose, mais il arrive que certaines erreurs de validation soient difficiles à éviter. L'exemple le plus connu est l'insertion de Flash dans un document HTML ou d'un autre contenu nécessitant un plugin. Pour en savoir plus, consultez cet article : Flash Satay: Embedding Flash While Supporting Standards ; ou cet autre : Embedding flash without <embed>.

4. Structure et présentation

À propos des standards du Web, on insiste souvent sur l'importance de la séparation entre la structure et la présentation. La différence entre les deux peut paraître compliquée au premier abord, a fortiori si vous n'êtes pas habitué à penser en termes de structure sémantique de document. Pourtant, ce distinguo est très important à assimiler, car vérifier l'apparence avec des CSS devient beaucoup plus simple si structure et présentation sont séparées.

On entend par structure les éléments obligatoires du document, ainsi que le balisage sémantiquement correct du contenu.

La présentation correspond à la mise en forme du contenu. Dans la plupart des cas, la présentation s'identifie au " look " du document, mais cela peut aussi comprendre la façon dont un document " sonne " dans le cas d'un navigateur vocal.

Séparez au maximum la structure de la présentation. Idéalement, vous devriez avoir un document HTML qui comporte la structure et le contenu, mais dont la présentation serait contrôlée par CSS.

La séparation entre le contenu et la présentation n'est pas encore très répandue sur le Web pour le moment. Dans la plupart des sites, le balisage HTML manque à la fois de structure et de sémantique.

La mise en page par tableaux

Afin de séparer la structure de la présentation, vous devez utiliser CSS plutôt que des tableaux pour confectionner la présentation d'un document. Si vous êtes habitué à utiliser des tableaux pour la mise en page, vous pourrez trouver cela peu commode ou incongru, mais ce n'est pas aussi sorcier que cela en a l'air. Il existe beaucoup de ressources sur le Web, et les bénéfices sont tellement nombreux que cela vaut vraiment le coup de l'apprendre.

En savoir plus :

HTML sémantique

L'autre pan de la séparation entre la structure et la présentation touche au balisage sémantique. Quand un élément XHTML ayant un sens structurel correspondant à celui du contenu existe, il n'y a aucune raison d'en utiliser un autre à la place. En d'autres termes, n'utilisez pas CSS pour rendre un élément HTML visuellement identique à un autre élément HTML. Par exemple, n'utilisez pas un <span> au lieu d'un <h1> pour signifier un titre.

En utilisant du HTML sémantique, les différentes parties de votre document auront du sens pour n'importe quel navigateur Web, que ce soit le tout dernier navigateur graphique, une ancienne version qui ne gère pas CSS ou un navigateur texte dans un terminal Unix.

Titres

Pour baliser des titres, utilisez <h1>, <h2>, <h3>, <h4>, <h5> or <h6> selon le niveau de titrage, <h1> correspondant au niveau le plus haut.

Exemples :
<h1>Titre du document</h1>
<h2>Sous-titre</h2>

Titre du document

Sous-titre

Paragraphes

Utilisez la balise <p> pour baliser des paragraphes. N'utilisez pas un <br /> pour créer des espaces entre les paragraphes. Les marges entre les paragraphes sont contrôlées par CSS et nécessitent que les paragraphes soient correctement balisés.

Exemple :
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing
elit. Donec risus. Ed rhoncus sodales metus. Donec adipiscing
mollis neque. Aliquam in nulla.</p>

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec risus. Sed rhoncus sodales metus. Donec adipiscing mollis neque. Aliquam in nulla.

Listes

Une liste doit être balisée comme une liste. Il existe trois types de listes en XHTML : les listes non-ordonnées, les listes ordonnées et les listes de définitions.

Les listes non-ordonnées, aussi connues sous le nom de " listes à puces ", commencent par un <ul> et terminent par un </ul>. Chaque élément de la liste est contenu dans une balise <li>.

Les listes ordonnées commencent par <ol> et finissent par </ol>.

Les listes de définitions sont un peu différentes et peuvent être utilisées pour baliser une liste de termes et de descriptions. Les listes de définitions commencent par un <dl> et finissent par un </dl>. Chaque terme décrit est contenu dans une balise <dt> et la description est contenu dans une ou plusieurs balises <dd>.

Exemples :
<ul>
    <li>Item 1</li>
    <li>Item 2</li>
    <li>Item 3</li>
</ul>
<ol>
    <li>Item 1</li>
    <li>Item 2</li>
    <li>Item 3</li>
</ol>
  1. Item 1
  2. Item 2
  3. Item 3
<dl>
    <dt>Site Web</dt>
    <dd>Ensemble de pages Web liées entre elles émanant
    d'une société ou d'une personne individuelle.</dd>
    <dt>Page Web</dt>
    <dd>Unité basique d'information sur le Web contenant
    du texte, des images ou d'autres médias.</dd>
</dl>
Site Web
Ensemble de pages Web liées entre elles émanant d'une société ou d'une personne individuelle.
Page Web
Unité basique d'information sur le Web contenant du texte, des images ou d'autres médias.

Grâce à CSS, il est possible d'utiliser des listes sans qu'elles soient nécessairement présentées de manière traditionnelle. Une barre de navigation est ainsi une liste de liens. L'avantage d'utiliser une liste pour baliser un menu est que le menu aura du sens, même si le navigateur ne supporte pas CSS.

Citations

La balise <q> est censée être utilisée pour des citations courtes dans le flux du document. Théoriquement, les navigateurs Web devraient afficher automatiquement des guillemets avant et après le contenu de la balise <q>. Malheureusement, beaucoup de navigateurs ne le font pas. Au point où l'emploi de cette balise peut poser des problèmes. C'est pourquoi beaucoup recommandent de ne pas l'utiliser et d'insérer les guillemets manuellement. On pourra utiliser des éléments <span> dotés d'une classe spécifique et les styler avec CSS.

Pour des citations plus longues - un paragraphe ou plus -, il faut utiliser la balise <blockquote>. CSS peut ensuite styler la citation. Notez que le texte n'est pas autorisé directement à l'intérieur de la balise <blockquote>, on l'entoure généralement d'une balise <p>. L'attribut cite peut être employé pour fournir une URL indiquant la source de la citation.

Exemples :
<p>Selon le W3C <span class="quote">&rdquo;La présentation
des éléments dépend de l'agent utilisateur&rdquo;</span>.</p>

Selon le W3C ”La présentation des éléments dépend de l'agent utilisateur”.

<blockquote cite="http://www.w3.org/TR/1999/REC-html401-19991224/
struct/text.html">
    <p>&rdquo;Ce chapitre traite de la structuration du texte.
    Les éléments de présentation du texte (éléments
    d'alignement, de police, ..., les feuilles de style,
    etc.) sont abordés par ailleurs dans cette
    spécification. Pour avoir des informations sur les
    caractères, veuillez consulter la section sur le
    jeu de caractères du document.&rdquo;</p>
</blockquote>

“Ce chapitre traite de la structuration du texte. Les éléments de présentation du texte (éléments d'alignement, de police, ..., les feuilles de style, etc.) sont abordés par ailleurs dans cette spécification. Pour avoir des informations sur les caractères, veuillez consulter la section sur le jeu de caractères du document.”

Emphase

<em> est utilisé pour marquer l'emphase, tandis que <strong> le renforce. La plupart des navigateurs affichent du texte avec emphase en italique et en gras pour une forte emphase. Néanmoins cela n'a rien d'obligatoire et pour s'assurer du rendu, mieux vaut le spécifier dans la CSS. Évitez d'utiliser l'emphase quand vous ne voulez obtenir qu'un effet visuel.

Exemple :
<p>Un texte <em>mis en emphase</em>  est généralement affiché
en italique tandis qu'un texte <strong>en emphase forte</strong>
est le plus souvent affiché en gras.</p>

Un texte mis en emphase est généralement affiché en italique tandis qu'un texte en emphase forte est le plus souvent affiché en gras.

Tableaux

En XHTML, les tableaux ne devraient pas être utilisés pour la mise en page. Cependant, l'utilisation de tableaux reste nécessaire au balisage de données tabulaires. Pour rendre les tableaux de données aussi accessibles que possible, il est important de connaître et d'utiliser les différents composants des tables. Par exemple, les titres de colonnes (<th>), les résumés (avec l'attribut summary) et les légendes (<caption>).

Exemple :
<table class="example" summary="Ce tableau montre
l'augmentation de la population annuelle en Suède de
1999 à 2003.">
    <caption>Augmentation de la population en Suède,
    1999–2003</caption>
    <tbody>
        <tr>
            <td> </td>
            <th scope="col">1999</th>
            <th scope="col">2000</th>
            <th scope="col">2001</th>
            <th scope="col">2002</th>
            <th scope="col">2003</th>
        </tr>
        <tr>
            <th>Population</th>
            <td scope="row">8 861 426</td>
            <td scope="row">8 882 792</td>
            <td scope="row">8 909 128</td>
            <td scope="row">8 940 788</td>
            <td scope="row">8 975 670</td>
        </tr>
        <tr>
            <th>Augmentation</th>
            <td scope="row">7 104</td>
            <td scope="row">21 366</td>
            <td scope="row">26 368</td>
            <td scope="row">31 884</td>
            <td scope="row">34 882</td>
        </tr>
    </tbody>
</table>
Augmentation de la population en Suède, 1999–2003
1999 2000 2001 2002 2003
Population 8 861 426 8 882 792 8 909 128 8 940 788 8 975 670
Augmentation 7 104 21 366 26 368 31 884 34 882

Pour une description plus détaillée des tableaux et de leur utilisation, lisez Tables in HTML documents et HTML Techniques for Web Content Accessibility Guidelines 1.0.

En savoir plus :

5. (X)HTML

Il est possible d'utiliser HTML 4.01 pour construire des sites Web modernes, structurés et valides. Néanmoins, pour s'habituer à faire du code clair et sémantique et pour mieux se préparer à une possible transition au langage XML ou ultérieur, je recommande l'utilisation d'XHTML 1.0 strict pour les nouveaux sites. C'est d'ailleurs cette version qui est employée dans les exemples de ce document.

XHTML 1.0 est la reformulation d'HTML 4.0 en XML 1.0, conçue pour remplacer HTML. L'utilisation d'XHTML 1.0 Strict -que je recommande- n'autorise pas le balisage à des fins de présentation (HTML 4.01 strict ne le permet pas non plus, mais je me concentre ici sur XHTML). De cette manière, XHTML impose la séparation entre la structure et la présentation.

XHTML 1.1, la dernière version en date d'XHTML, est techniquement un peu plus complexe à utiliser dans la mesure où la spécification indique que les documents devraient être envoyés avec le type MIME application/xhtml+xml. Il n'est pas interdit d'utiliser text/html, mais ce n'est pas recommandé. En ce qui concerne XHTML 1.0, le type MIME application/xhtml+xml devrait également être utilisé, mais le text/html est envisageable si votre contenu est compatible HTML. Le document du W3C XHTML Media Types décrit les différents types MIME qu'il est possible d'utiliser.

Malheureusement, certains anciens navigateurs, dont Internet Explorer, n'interprètent pas l'en-tête application/xhtml+xml. Ils peuvent aboutir à afficher le code source brut ou à refuser purement et simplement d'afficher la page.

Si vous voulez utiliser application/xhtml+xml, vous devriez laisser le serveur détecter si le navigateur appelant le document est en mesure de gérer ce type MIME. Utilisez text/html pour les autres navigateurs.

Si vous utilisez PHP comme langage côté serveur, vous pouvez utiliser le script suivant pour servir les documents avec un type MIME différent selon les navigateurs :

<?php
if (stristr($_SERVER[HTTP_ACCEPT], "application/xhtml+xml") || 
stristr($_SERVER["HTTP_USER_AGENT"],"W3C_Validator")) {
    header("Content-Type: application/xhtml+xml; charset=iso-8859-1");
    header("Vary: Accept");

    echo("<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n");
    }
else {
    header("Content-Type: text/html; charset=iso-8859-1");
    header("Vary: Accept");
    }
?>

Le script vérifie que l'agent utilisateur envoie un en-tête HTTP indiquant qu'il accepte la valeur application/xhtml+xml ou qu'il s'agit du validateur HTML du W3C qui, bien que n'envoyant pas cet en-tête gère correctement l'application/xhtml+xml. Si l'une de ces conditions est vraie, le serveur envoie la page avec le type MIME application/xhtml+xml. On envoie par ailleurs une déclaration XML à ces navigateurs. Pour les autres, notamment toutes les versions d'Internet Explorer, le document est envoyé comme text/html. Aucune déclaration XML n'est ajoutée au document, action qui ferait basculer IE pour Windows en mode "quirks", ce qui n'est pas le but de l'opération.

Après l'en-tête Content-Type, un en-tête Vary est également envoyé pour indiquer aux systèmes de cache intermédiaires, tels que les serveurs de proxy, que le Content-Type dépend des capacités du client à recevoir le document.

Pour un script plus avancé, lisez Serving up XHTML with the correct MIME type. Ce script prend en compte le "q-rating" de l'agent utilisateur (la capacité à gérer les types MIME que celui-ci annonce) et convertit XHTML en HTML 4 avant d'envoyer le document en text/html pour ceux qui ne supportent pas le application/xhtml+xml.

Voici un script similaire pour ceux qui utilisent ASP et VBScript.

<%
If InStr(Request.ServerVariables("HTTP_ACCEPT"), "application/xhtml+xml") > 0 
Or InStr(Request.ServerVariables("HTTP_USER_AGENT"), "W3C_Validator") > 0 Then

    Response.ContentType = "application/xhtml+xml"
    Response.Write("<?xml version=""1.0"" encoding=""iso-8859-1""?>" & VBCrLf);
Else
    Response.ContentType = "text/html"
End If
Response.Charset = "iso-8859-1"
%>

Notez que si le type MIME est application/xhtml+xml, certains navigateurs tels que Mozilla n'afficheront pas les pages contenant des erreurs de syntaxe. Ceci peut être intéressant durant le développement, mais peut poser des problèmes sur un site en production où des non-experts en XHTML assurent la mise à jour. A moins que vous ne vous assuriez que le code reste valide. Dans ce cas, vous pourrez préférer utiliser HTML 4.01 strict.

Découvrez ci-dessous une liste des points les plus importants concernant l'utilisation d'XHTML plutôt que de HTML.

En savoir plus :

Doctype

Actuellement, très peu de documents ont un DOCTYPE correct ou une DTD (Document Type Declaration). Ces deux éléments ont longtemps été plus décoratifs que fonctionnels. Mais depuis quelques années, la présence d'un DOCTYPE peut influer grandement sur le rendu d'une page dans un navigateur Web.

Tous les documents HTML et XHTML doivent avoir une déclaration de DOCTYPE pour être valides. Le DOCTYPE déclare la version de HTML ou d'XHTML utilisée. Celle-ci est utilisée par le validateur pour déterminer si la page est conforme, et par les navigateurs Web pour choisir le mode de rendu. Si le document contient un DOCTYPE correct, beaucoup de navigateurs basculeront en mode " standard ", ce qui veut dire qu'ils suivront de plus près la spécification CSS. Le rendu du document sera également plus rapide, car le navigateur n'aura pas à interpréter et à essayer de compenser du code HTML invalide. Cela réduira en outre les différences d'interprétation entre les navigateurs.

Le DOCTYPE suivant déclare le document en XHTML 1.0 strict provoquant pour les navigateurs doté du " doctype switching " le basculement vers le mode " standard ".

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
En savoir plus :

Encodage de caractères

Tous les documents XHTML doivent spécifier leur encodage de caractères.

La meilleure façon de spécifier le type d'encodage que vous utilisez est de configurer le serveur pour qu'il envoie un en-tête HTTP content-type indiquant cet encodage. Pour plus d'informations sur le sujet, reportez-vous à la documentation du logiciel de votre serveur Web.

Si vous utilisez Apache, vous pouvez spécifier l'encodage des caractères en ajoutant une ou plusieurs règles à votre fichier .htaccess. Par exemple, si tous vos fichiers utilisent utf-8, ajoutez ceci :

AddDefaultCharset utf-8

Pour spécifier un encodage pour les fichiers portant une extension spécifique, utilisez ceci :

AddCharset utf-8 .html

Si votre serveur vous offre le support du langage PHP, vous pouvez utiliser le code suivant pour spécifier l'encodage de caractères :

<?php
    header("Content-Type: application/xhtml+xml; charset=utf-8");
?>

Pour envoyer vos pages en HTML, changez application/xhtml+xml en text/html. Si, pour une raison ou pour une autre, vous n'êtes pas en mesure de configurer correctement le serveur web pour spécifier l'encodage de caractères, utilisez une balise <meta> dans votre section <head>. Il est bon de spécifier l'encodage de cette manière, même si votre serveur est correctement configuré.

Par exemple, la balise <meta> suivante indique au navigateur que l'encodage ISO-8859-1 est utilisé dans le document.

<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1" />
En savoir plus :

6. CSS

Cantonné jusqu'à présent au seul habillage du texte, CSS peut maintenant être employé pour contrôler la mise en page d'un document. Néanmoins, utiliser efficacement cette méthode nécessite une approche quelque peu différente de celle reposant sur la mise en page en tableaux.

Un code XHTML sémantiquement correct est nécessaire pour pleinement profiter de la puissance de CSS pour la mise en page.

Support des navigateurs

Comme mentionné plus haut, le support CSS des navigateurs s'est grandement amélioré ces dernières années. Malheureusement, tous les développeurs de navigateurs n'ont pas l'air de s'intéresser à l'implémentation de standards ouverts, rendant ainsi le niveau de support CSS variable d'un navigateur à un autre. Divers bugs logiciels s'ajoutent à cela, faisant que les navigateurs ne réagissent pas comme ils le devraient.

Actuellement (2004), les navigateurs les plus respectueux des normes CSS sont Mozilla (et les navigateurs basés sur son moteur, Gecko : Firefox, Camino, Netscape 6+), Opera et Safari (ainsi que les autres navigateurs utilisant WebCore : OmniWeb 4.5 et ultérieurs). Internet Explorer 5/Mac et Internet Explorer 6/Win n'offrent pas le même niveau de support, mais gèrent la plupart des éléments de base. Pour sa part, IE5.* pour Windows supporte quelques règles CSS, mais rencontre des problèmes que vous devrez prendre en compte. Les versions antérieures d'Internet Explorer n'ont pas de support CSS notable. Il en va de même pour les versions de Netscape antérieures à la 6e.

Puisque la majorité des internautes utilise actuellement Internet Explorer pour Windows, vous devrez souvent l'utiliser comme le plus petit dénominateur commun. Cela ne veut pas dire que vous ne pouvez ou devez pas utiliser les capacités CSS avancées pour améliorer le rendu sur les autres navigateurs.

Tous les navigateurs ne disposent pas d'un support CSS leur permettant de rendre un site Web qui utilise pleinement CSS pour créer une mise en page esthétique. Heureusement, sur la plupart des sites, seul un faible pourcentage de visiteurs utilise un navigateur trop ancien pour afficher une mise en page CSS correctement.

Il est important de noter que ces internautes ne se verront pas interdire l'accès au site. Dans les années 90, les scripts de détection des navigateurs redirigeaient tous ceux utilisant un mauvais navigateur (comprenez généralement tous, sauf Internet Explorer pour Windows) vers une page leur demandant de mettre à jour leur navigateur pour pouvoir accéder au site.

De nos jours, il est possible de gérer plus intelligemment les navigateurs non supportés. L'un des grands avantages de l'utilisation d'un code XHTML logique et sémantique est de rendre lisible et utilisable des documents, même sans CSS. La présentation - la façon dont la page s'affiche - ne sera pas la même que sur un navigateur évolué, mais le contenu sera accessible. La plupart du temps pour les visiteurs, le contenu est plus important que la présentation.

C'est pourquoi, envoyer une page non stylée pour les anciens navigateurs est une meilleure démarche que de leur interdire l'accès à votre site.

Il y a plusieurs façons de procéder. L'une des plus fréquentes est d'utiliser la commande @import pour lier la feuille de style associée à la page. Netscape 4 et d'autres anciens navigateurs ne comprennent pas cette syntaxe et n'importeront donc pas la feuille de style. Il y a beaucoup de façons de cacher CSS aux navigateurs. La plupart de ces méthodes reposent sur des bugs d'interprétation CSS. Ce qui signifie qu'il y a toujours un risque qu'une mise à jour d'un navigateur répare le bug utilisé pour lui cacher la CSS, mais pas la raison qui vous a poussé à utiliser cette astuce. Moins vous utiliserez ce genre de procédé, mieux ce sera.

Évidemment, vous pouvez utiliser une technologie serveur pour déterminer quel navigateur appelle vos pages et envoyer différentes CSS (ou aucune) en conséquence. Dans ce cas, une maintenance régulière est à assurer pour ne pas envoyer une mauvaise CSS quand un navigateur nouveau ou mis à jour apparaît.

En savoir plus :

Les différentes méthodes pour appliquer CSS

Il existe plusieurs façons d'appliquer CSS aux éléments d'un document HTML.

Feuille de style externe

Conserver les règles CSS dans un ou plusieurs fichiers séparés offre plusieurs avantages. Le document HTML devient plus léger, les fichiers CSS sont stockés en cache par les navigateurs qui n'ont ainsi à les télécharger qu'une fois et, enfin, l'édition d'un seul fichier vous permet de changer l'apparence d'un site Web entier. Un fichier CSS externe peut ressembler à ceci :

h1 {
    font-weight:bold;
}

Remarque : il n'y a pas de balise <style> dans une feuille de style externe.

Vous pouvez lier une feuille de style à un document HTML en utilisant une balise <link>

<link rel="stylesheet" type="text/css" href="styles.css" />

ou en utilisant une règle @import dans une balise <style>

<style type="text/css">
@import url("styles.css");
</style>

Feuille de style en ligne

En utilisant l'attribut style, vous pouvez appliquer un style CSS directement à une balise HTML

<h1 style="font-weight:bold;">Rubrique</h1>

Cette méthode devrait être évitée dans la mesure où cela entremêle structure et présentation.

Feuille de style interne

Une feuille de style interne est incluse dans une balise <style>, elle-même incluse dans la balise <head>

<style type="text/css">
h1 {
    font-weight:bold;
}
</style>

Ceci devrait aussi être évité car HTML et CSS gagnent à être dans des fichiers séparés.

En savoir plus :

Syntaxe CSS

Une règle CSS est composée d'un sélecteur suivi d'une ou plusieurs déclarations. Le sélecteur détermine sur quelle(s) balise(s) la règle influe. Chaque déclaration est composée d'une propriété et d'une valeur. Le bloc déclaratif est entouré d'accolades ({}) et chaque déclaration termine par un point-virgule (;)

Une règle CSS simple ressemble à ceci :

p {
    color:#0f0;
    font-weight:bold;
}

Dans ce cas, p est le sélecteur, ce qui signifie que la règle s'applique à toutes les balises <p> du document. La règle a deux déclarations qui vont rendre simultanément tout le texte contenu dans la balise <p> en vert et en gras.

Pour une description plus détaillée des règles CSS, vous pouvez vous reporter par, exemple, au CSS Beginner's Guide, à CSS from the Ground Up ou à un livre sur CSS.

Pour en savoir plus :

Balises et classes superflues

Lorsqu'on commence CSS, on commet souvent l'erreur d'utiliser des balises XHTML redondantes, des classes superflues ou des <div> inutiles. Ceci n'entraîne pas nécessairement que le code sera invalide, mais cela entre en contradiction avec un des objectifs de la séparation entre la structure et la présentation, à savoir obtenir du code plus simple et plus propre.

Un exemple d'utilisation superflue de balises XHTML :

<h3><em>Titre</em></h3>

Si vous voulez rendre votre titre en italique, utilisez CSS pour styler la balise <h3>

h3 {
    font-style:italic;
}

L'utilisation excessive d'attributs peut aboutir à ce genre de code :

<div id="principal">
    <div class="contenuPrincipal">
        <p class="texteContenuPrincipal">
            Lorem ipsum dolor
        </p>
    </div>
</div>

Alors que ceci suffit :

<div id="principal">
    <div>
        <p>
            Lorem ipsum dolor
        </p>
    </div>
</div>

Pour contrôler les éléments contenus dans div#principal, vous pouvez utiliser les sélecteurs contextuels dans le code CSS. Dans notre exemple, on pourrait faire ceci :

div#principal p {
    /* règles CSS */
}

Dans la plupart des cas, CSS peut être utilisé pour styler du code XHTML logique sans avoir à rajouter du code superflu. Néanmoins, certaines situations peuvent le nécessiter.

Astuces CSS

Bien entendu, lorsque vous commencerez à utiliser CSS sérieusement, vous rencontrerez à coup sûr des problèmes d'une nature ou d'une autre. Certains de ces problèmes seront dus à des erreurs d'interprétation CSS, d'autres à des spécifications imprécises et d'autres, enfin, aux bugs des navigateurs eux-mêmes. La CSS Scrib Sheet est une compilation de conseils pratiques collectés par Dave Shea. Voici quelques-uns des plus importants, ainsi qu'une poignée d'autres qui n'y figurent pas.

Mise en page CSS

Il existe beaucoup d'exemples et de tutoriels pas à pas sur l'utilisation de CSS pour la mise en page. La bonne méthode consiste à commencer par une mise en page simple, apprendre comment cela fonctionne, puis continuer avec des gabarits plus complexes.

En savoir plus

7. Accessibilité

L'accessibilité ne concerne pas uniquement les visiteurs handicapés, même si c'est une des principales raisons pour y accorder de l'importance. Un site Web accessible fonctionne mieux pour tous, handicapés ou non, et peut ouvrir son accès à plus de navigateurs sur plus de supports.

Une contre-vérité répandue consiste à dire qu'un site Web accessible est nécessairement moins esthétique ou visuellement moins abouti qu'un autre qui ne l'est pas. Ceci est faux. La vaste majorité des mesures d'accessibilité n'affecteront en rien l'apparence visuelle d'un site.

Voici un exemple de l'utilité de l'accessibilité pour tous. Imaginez un formulaire d'inscription pour un séminaire. À l'intérieur de celui-ci, vous pouvez choisir parmi trois villes. Chacune d'entre elles est placée à côté d'un bouton radio. Si le développeur n'a pas intégré la notion d'accessibilité, toutes les personnes utilisant un navigateur graphique devront cliquer sur le minuscule bouton radio pour choisir la ville. Au contraire, une personne ayant des notions d'accessibilité aura légendé les boutons radio avec la balise <label>, permettant ainsi de cliquer sur le nom de la ville pour la sélectionner. Laquelle de ces deux méthodes vous paraît simplifier l'utilisation du formulaire ?

Utiliser du code XHTML sémantique et structuré vous amènera tout naturellement à réaliser un site Web accessible. Pour vous donner une idée rapide du niveau d'accessibilité de votre document, essayez de le visualiser avec un navigateur texte tel que Lynx pour voir si le contenu reste significatif. Ceci est loin d'être le seul test d'accessibilité que vous devez mener, mais c'est un excellent début.

Cadres (frames)

Beaucoup de développeurs Web apprécient de diviser la fenêtre du navigateur en plusieurs parties indépendantes composées chacune d'un document HTML séparé. Cette méthode peut être commode pour une application de type Intranet. Sur un site Web grand public, les inconvénients à l'employer sont si nombreux qu'il vaut mieux y renoncer.

De plus, vous vous compliquez la vie. Un site Web utilisant des cadres est toujours plus complexe à réaliser.

Tableaux

Beaucoup de gens interprètent la consigne " N'utilisez pas de tableaux pour la mise en page " comme " N'utilisez plus du tout de tableaux. " Ce n'est pas ainsi que cela devrait être interprété. Si vous balisez des données tabulaires, celles-ci ont leur place dans un tableau. Néanmoins, il est important de savoir que lorsque vous utilisez des données tabulaires, il existe de nombreux moyens de les rendre plus logiques et accessibles.

En savoir plus

Formulaires

Les formulaires sont souvent inutilement complexes à utiliser, et ce, à cause d'une construction sans logique ou de l'absence de code HTML comportant les balises existantes pour améliorer la simplicité et l'accessibilité. Les balises <label>, <fieldset> et <legend> ont été conçues pour être utilisées.

Une question fréquente revient sur la mise en page des formulaires. Certains les considèrent comme des données tabulaires et utilisent en conséquence un tableau, tandis que d'autres recommandent l'emploi de CSS. Utilisez l'une ou l'autre méthode, mais dans le cas du tableau, assurez-vous que le formulaire ait du sens et soit utilisable quand le tableau est présenté de manière linéaire.

En savoir plus

Javascript et les cookies

Évitez de faire reposer le fonctionnement de votre site sur javascript. Il y a plus de gens que vous ne le croyez qui ont désactivé javascript ; que ce soit pour des raisons de sécurité ou pour éviter les fenêtres volantes non sollicitées ou pop-ups. Ils peuvent également utiliser un navigateur qui ne supporte pas javascript. Selon TheCounter.com, 6% des internautes ne disposent pas de javascript. W3Schools.com en dénombre 8%.

La plupart des utilisations de javascript ne créent pas de réel bénéfice pour l'utilisateur. Bien sûr, il est des situations où javascript peut être employé pour améliorer l'expérience utilisateur. Par exemple, pour la validation a priori lors du remplissage des formulaires.

Cela ne veut pas pour autant dire qu'il faut cesser d'utiliser javascript. Cela veut simplement dire qu'il faut éviter que le site nécessite impérativement javascript pour fonctionner.

Il en est de même pour les cookies. Ne construisez pas un site qui ne fonctionne pas si le visiteur n'accepte pas les cookies.

8. URL

Ce chapitre ne porte pas spécifiquement sur les standards du Web ou sur l'accessibilité, mais il a sa place car la manière dont une URL est construite influe grandement sur la façon dont un site est indexé par les moteurs de recherche et sur la facilité de son utilisation par les visiteurs.

Certains moteurs ne suivent pas les liens vers les URL contenant une query string. Ce genre d'URL est très fréquent dans les sites Web dynamiques utilisant une base de données pour alimenter leur contenu et ressemble à ce genre d'exemple :

http://www.domaine.com/produits.asp?item=34627393474632&id=4344

La façon la plus simple de construire une URL plus lisible pour un moteur de recherche et aux êtres humains est de la faire ressembler à un répertoire. L'exemple ci-dessus pourrait ainsi ressembler à quelque chose comme :

http://www.domaine.com/produits/item/34627393474632/id/4344/

Le serveur Web interprète ainsi la nouvelle URL, la convertit en interne vers l'URL originale et complète avec la query string. À la fin de ce chapitre, vous trouverez des liens vous donnant plus d'informations sur la manière de le faire.

Encore mieux, bien qu'un peu plus compliqué, il est possible de changer les URL complètement pour les rendre lisibles à des êtres humains.

http://www.domaine.com/produits/fleurs/tulipes/

Les avantages de ce genre d'URL sont : un meilleur référencement par les moteurs de recherche, une meilleure lisibilité pour les êtres humains et l'anonymat sur la technologie serveur que vous utilisez. Étant donné que vos URL ne contiennent pas d'extension de fichier spécifique, tels que .asp, .cfm, .cgi ou .jsp, cela simplifie la transition de technologie serveur si cela devenait nécessaire.

Si vous choisissez d'utiliser des query string dans vos URL, il est important de convertir vos esperluettes (&) en entité HTML (&amp;). Si vous l'omettez, certains navigateurs interpréteront l'esperluette comme le début d'une entité HTML. Et, si le texte la suivant correspond à une entité HTML, l'URL sera automatiquement convertie, brisant ainsi la query string.

En savoir plus

9. Références

Une sélection de livres, de sites Web et de listes de diffusion recommandés.

Livres

CSS

Développement Web en général

HTML

Accessibilité

Standards du Web

XHTML

10. Glossaire

Accessibilité
Un site Web accessible est consultable et utilisable par tout le monde, quel que soit son matériel ou son logiciel et quel que soit ce qu'il utilise pour naviguer sur le site.
Balisage
Baliser un document c'est lui donner sa structure et son sens. Sur le Web, on utilise HTML ou XHTML.
CSS (Cascading Style Sheets)
Ensemble de règles décrivant comment un document devrait être présenté.
HTML (HyperText Markup Language)
Langage de balisage utilisé pour définir la structure logique d'un document.
Présentation
Façon dont la page apparaît visuellement (ou auditivement).
Standards du Web
Les standards du Web sont des technologies édictées par le W3C et d'autres organismes de standardisation, et qui sont utilisées pour créer et interpréter du contenu Web. Ces technologies sont conçues pour rendre les documents pérennes et accessibles au plus grand nombre.
Structure
Parties obligatoires d'un document, plus le balisage logique du contenu.
Validation
Processus par lequel on s'assure que le document obéit aux règles syntaxiques du ou des langages Web qu'il utilise. On peut comparer ce processus à une correction orthographique et grammaticale.
W3C (World Wide Web Consortium)
Organisation qui développe les spécifications, les recommandations et les outils pour le Web.
XHTML (Extensible HyperText Markup Language)
Version d'HTML reformulée pour se conformer aux règles syntaxiques d'XML.
XML (Extensible Markup Language)
Langage de balisage ressemblant à HTML, mais qui permet à l'auteur de décrire des données en définissant des balises personnalisées.

Et que penser des sites de casino ? Ils utilisent en effet bien souvent des CSS, même s'il s'agit parfois de sites presqu'autogénérés... Ce sont des sites à forte diffusion visités par un auditoire très varié. En effet, ils envoient parfois beaucoup de courriel (indesirables?) en effectuant la promotion de leur casino en ligne sans depot. Ce stratagème leur permet d''avoir des visiteurs utilisant tous les navigateurs et toutes les versions. Il faut que leurs codes soient solides.

11. Traduction

Traducteur et relecteur final
Clément Hardouïn
Relecteurs
Catherine Saguès, Normand Lamoureux, Simon Georget et Denis Boudreau.