Read the original version in english.
Detta dokument finns även på svenska.
Tämä dokumentti on saatavilla myös suomeksi.
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.
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.
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.
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.
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.
Un document du W3C pour améliorer la qualité du code de votre site
Feuille de route du WASP (Web Standards Project)
Explications par le WASP sur les standards du Web et des avantages de leur utilisation
Un article de Netscape DevEdge, traduit par Clark, montrant comment une entreprise peut gagner de l'argent avec les standards du Web.
Un article d"OpenWeb visant les décisionnaires dans les domaines du marketing, de la communication et des TIC.
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>.
À 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.
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.
Les diapos d'une conférence qui s'est tenue à Seybold en 2003.
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.
Pour baliser des titres, utilisez <h1>, <h2>, <h3>, <h4>, <h5> or <h6> selon le niveau de titrage, <h1> correspondant au niveau le plus haut.
<h1>Titre du document</h1> <h2>Sous-titre</h2>
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.
<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.
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>.
<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>
<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>
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.
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.
<p>Selon le W3C <span class="quote">”La présentation des éléments dépend de l'agent utilisateur”</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>”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.”</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.”
<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.
<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.
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>).
<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>
| 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.
Une excellente ressource pour comprendre le raisonnement du balisage sémantique
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.
Utilisez toujours des minuscules et mettez les attributs entre guillemets. Toutes les balises et les attributs doivent être en minuscules. Tous les attributs doivent être mis entre guillemets.
Incorrect : <A HREF="index.html" CLASS=interne>
Correct : <a href="index.html" class="interne">
Fermez toutes les balises.
En HTML, certaines balises n'ont pas besoin d'être refermées. Elles se
ferment automatiquement quand l'élément suivant débute. Ceci est
interdit en XHTML. Toutes les balises doivent être fermées, même celles
qui n'ont pas de contenu, comme <img>.
Incorrect : <li>Item 1
Correct : <li>Item 1</li>
Incorrect : <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Correct : <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>
Incorrect : <br>
Correct : <br />
Incorrect : <img src="image.jpg" alt="">
Correct : <img src="image.jpg" alt="" />
Les attributs ne peuvent être abrégés. En HTML, il est possible de raccourcir certains attributs. XHTML l'interdit.
Incorrect : <input type="checkbox" id="checkbox1" name="checkbox1" checked>
Correct : <input type="checkbox" id="checkbox1" name="checkbox1" checked="checked" />
Spécifiez tous les attributs obligatoires. XHTML impose des attributs obligatoires pour certaines balises. Par exemple, toutes les balises <img> nécessitent un attribut alt.
Incorrect : <img src="image.jpg" />
Correct : <img src="image.jpg" alt="" />
N'utilisez pas des éléments dépréciés. Quelques balises et attributs qui sont autorisés en HTML 4 sont dépréciés en XHTML. Par exemple : <font>, <center>, alink, align, width, height (pour certaines balises) et background.
N'utilisez pas de caractères illégaux.
Certains caractères doivent être remplacés par leurs entités HTML avant
d'être insérés dans un document XHTML. Par exemple, les guillemets
doubles " sont remplacés par ” et l'apostrophe ' par ’
Le Web Standards Project demande au W3C quand et pourquoi utiliser HTML ou XHTML.
Un article d'A List Apart, traduit par Pompage, sur la transition entre HTML et XHTML
Une bonne explication de l'utilisation d'XHTML et de CSS
Le W3C explique la différence entre XHTML 1.0 et HTML 4.
Un résumé des différences entre XHTML 1.0 strict et transitionnel
Le Web Standards Project demande au W3C quel type MIME choisir pour HTML et XHTML et pourquoi.
Un résumé des types de médias utilisables pour des documents XHTML
Un article sur l'utilisation des différents types MIME pour XHTML
Un résumé des balises et attributs dépréciés en XHTML 1.0
Le guide d'HTML Dog concernant les balises et attributs à ne pas utiliser en XHTML
Un document du W3C sur les types MIME et XHTML
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">
Un article d'A List Apart, traduit par Pompage, sur l'importance et la manière d'utiliser le DOCTYPE
Un résumé expliquant comment les différents DOCTYPE influent sur les navigateurs dotés du doctype switching
La liste officielle des déclarations de DOCTYPE valides du W3C
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" />
Le Web Standards Project demande au W3C comment les auteurs de pages Web doivent spécifier leur encodage de caractères.
Un article sur les différents jeux de caractères
Une explication sur l'usage de caractères nationaux et spéciaux dans les documents HTML
Un tutoriel sur le choix et la déclaration d'encodage de caractères
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.
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.
Éric Meyer décrit quatre façons de cacher CSS à certains navigateurs.
Une grande collection de techniques pour cacher CSS aux navigateurs.
Un document expliquant les différentes manières d'améliorer l'expérience utilisateur pour les personnes utilisant des navigateurs modernes.
Il existe plusieurs façons d'appliquer CSS aux éléments d'un document HTML.
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>
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.
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.
Une explication sur, entre autres, l'importation CSS et les types de médias.
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.
Avec l'aide de ses lecteurs, Dave Shea a constitué une liste de conseils pratiques sur CSS.
John Gallant et Holly Bergevin expliquent comment écrire des CSS compactes.
Une très bonne explication sur les différents sélecteurs CSS et leur fonctionnement
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.
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.
Valider d'abord. Lorsque vous testez ou déboguez, commencez d'abord par valider vos codes HTML et CSS. Beaucoup de problèmes peuvent venir d'un code invalide.
Tester d'abord dans le navigateur le plus conforme, puis dans les autres. Si vous utilisez un ancien navigateur avec une implémentation incorrecte des CSS pour tester, votre CSS sera mécaniquement adaptée à celui-ci. Si vous le testez dans un navigateur plus moderne, il se pourrait que le rendu ne soit pas celui que vous attendiez. La bonne démarche consiste à faire fonctionner votre page dans un navigateur conforme aux standards, puis d'adapter le code aux navigateurs plus anciens.
Comprendre le modèle de boîte CSS. Pour obtenir la largeur ou la hauteur réelle d'un bloc, il faut ajouter le padding et la taille de la bordure (border) à la largeur (width) ou à la hauteur (height), selon le cas. Dans Internet Explorer 5.* pour Windows, le padding et la bordure sont intégrés dans la hauteur ou dans la largeur.
Supposez que vous ayez la CSS suivante :
div.boite {
width:300px;
padding:20px;
border:10px solid;
}
La largeur totale du bloc sera de 360 pixels.
10 + 20 + 300 + 20 + 10 = 360
Dans Internet Explorer 5.* pour Windows, la largeur totale sera de 300 pixels, tandis que la largeur du contenu sera de 240 pixels.
300 - 10 - 20 - 20 - 10 = 240
Pour
contourner ce problème, vous pouvez utiliser un hack CSS pour fournir
des valeurs différentes en fonction du modèle de boîte du navigateur.
Autrement, vous pouvez éviter de spécifier à la fois la largeur et le padding ou la bordure d'un élément.
Pour une explication plus complète sur le modèle de boîte, reportez-vous au document Box model.
Spécifier des unités pour les valeurs numériques non-nulles. CSS impose de spécifier des unités pour des propriétés comme width, height et font-size. La valeur 0 fait exception. En effet, dans ce cas, l'unité est superflue, puisque 0 c'est 0, quelle que soit l'unité.
Comprendre les flottants. Le concept des flottants peut être difficile à appréhender, pourtant il est très important car il est fréquemment utilisé dans les mises en page CSS. Parmi les excellents articles sur le sujet, on citera Containing Floats, Floatutorial et Float: The Theory.
"LoVe/HAte". Définissez les pseudo-classes pour les liens suivant l'ordre Link, Visited, Hover et Active.
"TRouBLed". Lorsque vous utilisez des notations abrégées pour des éléments margin, padding ou border, faites-le dans le sens des aiguilles d'une montre : Top, Right, Bottom, Left
Nommez les classes et les ID par leur fonction et non par leur aspect. Si vous appelez une classe .petitBleu
et que vous décidez par la suite de changer le texte en plus gros et en
rouge, le nom de la classe vous induira en erreur. Mieux vaut utiliser
des noms qui décrivent la fonction ou la structure comme " copyright "
ou " important ".
CSS utilise des minuscules. Les valeurs des attributs HTML class et id utilisent des minuscules quand ils sont utilisés avec CSS (voir CSS2 syntax and basic data types).
Vérifiez vos id. Les attributs id doivent être appliqués de manière unique dans un document alors que plusieurs éléments peuvent utiliser la même classe.
N'utilisez que des caractères autorisés pour les class et les id. Class et id
ne peuvent contenir que des caractères [A-Za-z0-9] ou un tiret (-) et
ne peuvent pas commencer par un tiret ou un chiffre (voir CSS2 syntax and basic data types).
Commentez correctement. Les commentaires commencent par /* et terminent par */ en CSS.
/* ceci est un commentaire */
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.
Un exemple montrant comment créer une mise en page simple avec un en-tête, deux colonnes et un pied de page.
Une liste de liens vers différents modèles de mise en page CSS
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.
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.
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.
Liens vers des articles permettant de construire des tableaux accessibles
Un article sur l'utilisation des tables pour la mise en forme des données tabulaires
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.
Un article de WebAIM sur les formulaires accessibles
Un article pour réaliser des formulaires plus accessibles
É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.
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 (&).
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.
Un article expliquant les problèmes avec certains types d'URL et comment les améliorer
Ou pourquoi il faut terminer les URL avec une barre oblique "/"
Une série de liens vers des articles et des tutoriels sur les URL
Une sélection de livres, de sites Web et de listes de diffusion recommandés.
Un livre retraçant un projet qui explique comment utiliser CSS.
La suite de Eric Meyer on CSS
Le livre de référence expliquant les recommandations CSS
Expérience concrète de la conception et du développement Web utilisant les standards.
Livre complet sur l'accessibilité et son application aux sites Web
Une liste de diffusion consacrée aux cas pratiques utilisant CSS.
Site Web richement doté en termes de tutoriels HTML et CSS, articles et références.
Un grand nombre d'exemples montrant comment utiliser CSS pour habiller totalement différemment le même document HTML.
Plusieurs articles remarquablement écrits sur CSS
Articles, démonstrations, bugs des navigateurs, entre autres
Un webzine hebdomadaire qui explore le design, le développement, la sémantique des contenus Web avec une approche spécifique centrée sur les techniques et les avantages des standards.
Une liste de diffusion pour les créateurs du Web. La plupart des discussions tournent autour de la conception et du développement Web.
La spécification officielle du W3C, traduite par Karl Dubost
Site Web richement doté en termes de tutoriels HTML et CSS, articles et références
Le livre de Joe Clark sur l'accessibilité disponible en ligne
Le livre de Mark Pilgrim sur l'accessibilité, traduit par Karl Dubost.
Les recommandations officielles du W3C en matière d'accessibilité Web
Compilation d'informations du W3C sur les outils pour évaluer et améliorer l'accessibilité des sites Web.
" Le Web Standards Project est une coalition luttant pour des standards assurant la simplicité et l'accès pour tous aux technologies du Web. "
La mission de MACCAWS est de fournir aux professionnels du Web les ressources nécessaires pour promouvoir les standards du Web sous un jour commercial pour les clients. Deux documents sont tout particulièrement intéressants : Ce que tout possesseur de site Web devrait savoir au sujet des standards ou introduction aux standards Web et Aller de l'avant avec les standards Web.
Le guide de Dave Shea, traduit par Chantal Ide, pour tous les débutants utilisant les standards du Web.
La spécification officielle du W3C
Site Web richement doté en termes de tutoriels HTML et CSS, articles et références.
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.
Des commentaires, des questions, des suggestions ? Faites-le savoir à l'auteur
© Copyright 2004 Roger Johansson