Le rendu final d'une page Web n'est pas le produit figé des règles de présentation fixée par son auteur : il résulte de la combinaison des 3 sources de styles de l'auteur, de l'agent utilisateur et de l'utilisateur lui-même.
Les règles de cascade CSS gèrent le rendu final d'une page Web en fonction de trois sources simultanées : les styles CSS auteur accompagnant le document, mais aussi les styles par défaut de l'agent utilisateur et les éventuels styles propres à chaque utilisateur. Dans cette combinaison, les styles par défaut du navigateur ont le poids le plus faible, tandis que ceux de l'utilisateur ont le poids le plus fort. Dans tous les cas, l'auteur devra tenir compte de ces styles par défaut du navigateur, et plus fortement encore des éventuels styles utilisateurs.
Chaque navigateur applique aux pages Web un ensemble de styles par défaut. Il peut s'agir d'un véritable document CSS, comme les fichiers /res/html.css et /resr/quirk.css utilisés par les navigateurs Firefox et Mozilla. Plus souvent, il s'agit d'un autre mécanisme faisant partie du moteur de rendu du navigateur et parvenant au même résultat (Opera, Internet Explorer). Notons enfin que les navigateurs ont parfois recours à des extensions CSS
, c'est à dire à des propriétés CSS n'appartenant pas aux spécifications CSS1 ou CSS2, mais préfigurant les futures spécifications CSS2.1 et CSS3 (par exemple, la propriété white-space: -moz-pre-wrap dans les navigateurs Gecko, préfigurant le
white-space: pre-wrap
CSS2.1). Il peut s'agir également d'extensions purement propriétaires (
-o-link et -o-link-source
dans Opera, -moz-binding dans Firefox).
Ces styles de l'agent utilisateur ont un double rôle :
Selon la spécification HTML4.01, ils doivent garantir « l'interprétation conventionnelle » des éléments (X)HTML. Il s'agit en particulier :
head du (X)HTML (propriété display: none) ;display: block et display: inline) ;display: list-item) et de leurs marqueurs ;display: table).Cette « interprétation conventionnelle » n'est normalisée, ni pour HTML4.01 (malgré une feuille de style indicative proposée par la spécification, ni pour les différentes variantes XHTML1.0 (aucune feuille de style de ce type n'y est proposée). Chaque navigateur a donc mis en place ses propres règles, plus ou moins étendues. On y trouve aussi bien des propriétés de marges et d'indentation de certains blocs de texte (titres, citations listes...), que la taille ou la graisse des caractères des titres, le soulignement des intitulés de liens, le comportement par défaut du pointeur de la souris au survol de certains éléments, etc. A titre d'exemple, voici un extrait des styles par défaut de Firefox :
/* Présentation des titres */
h1 {
display: block;
font-size: 2em;
font-weight: bold;
margin: .67em 0;
}
/* Soulignement des abréviations et acronymes renseignés */
abbr[title], acronym[title] {
border-bottom: dotted 1px;
}
/* Indentation des blocs de citation */
blockquote {
display: block;
margin: 1em 40px;
}
/* Mise en italique des address*/
address {
display: block;
font-style: italic;
}
On rencontre donc plusieurs différences de rendu par défaut d'un navigateur à l'autre. En particulier :
body
est doté de marges de 8px par Firefox et par Internet Explorer. Opera, lui, utilise un padding de la même dimension ;padding-left de 40px pour réserver l'espace où se placent les puces des éléments de liste (ul), Internet Explorer et Opera utilisent un margin-left (de même dimension) ;hr
est traitée par Internet Explorer comme un élément en ligne, et sa couleur par la propriété color, tandis que les autres navigateurs la considèrent comme un élément bloc stylé par la propriété background-color ;abbr et acronym dotés d'un attribut title explicitant leur signification sont soulignés en pointillés par Opera et les navigateurs Gecko. Internet Explorer n'applique aucun style par défaut à acronym (Il n'implémente pas abbr).Les styles par défaut des agents utilisateurs sont donc nécessaires, mais actuellement problématiques :
les feuilles de style fournissent les moyens de spécifier la restitution d'éléments arbitraires, y compris si l'élément est rendu comme étant de type bloc ou de type en-ligne. Cela peut être approprié, dans certains cas, tel qu'un style en-ligne pour les éléments d'une liste, mais généralement parlant, on décourage les auteurs de détourner l'interprétation conventionnelle des éléments HTML de cette façon.On rencontre donc de fréquentes interrogations sur la légitimité de telle ou telle combinaison de propriétés CSS, telles que : des paragraphes peuvent-ils être dotés de marqueurs ou numérotés, à la manière des éléments de liste ? Ou est-ce le signe qu'une liste aurait été plus appropriée ?
h1 car la taille est caractères est trop grande... J'utilise blockquote pour avoir un texte indenté... »). Ils ont également entraîné bon nombre de confusion sur le sens de certains éléments (Par exemple, entre b (mise en gras) et strong (emphase forte), i (mise en italique) et em (emphase simple)...). Ils ont enfin conduit à rigidifier certaines pratiques en règles de design ou d'ergonomie (« les hyperliens doivent être soulignés », etc.).La future spécification XHTML2 répondra à une partie de ces questions en normalisant une feuille de style par défaut pour les agents utilisateurs. D'ici là, à l'exception notable des contrôles de formulaires beaucoup plus liés à l'interface utilisateur, la présentation par défaut de chaque élément HTML peut être librement modifiée aussi bien par l'auteur que par l'utilisateur. Les seules contraintes finalement pertinentes sont celles de la lisibilité de son contenu, d'une présentation favorisant l'accès au sens, et de l'accessibilité aux personnes handicapées.
Côté client, les styles par défaut de l'agent utilisateur ne sont pas seuls susceptibles d'intervenir dans le rendu d'une page Web. En effet, différents agents utilisateurs, à commencer par les navigateurs graphiques, permettent à leur utilisateur d'imposer ses préférences de rendu, dans un souci de confort mais aussi d'accessibilité. Ces styles utilisateurs (« user style ») peuvent être définis :
Dans le premier cas, les options proposées dans l'interface des navigateurs limitent la portée des styles utilisateurs à quelques données élémentaires, dont :
Dans le second cas, si l'utilisateur écrit sa propre feuille de style « user » (ou reproduit l'une des nombreuses CSS utilisateur proposées sur le Web), il dispose alors de toute la puissance des styles CSS et peut adapter à sa guise le contenu et le rendu des pages Web :
marquee (display:block dans Opera, -moz-binding: none; dans Firefox), forcer le retour à la ligne dans les éléments pre (white-space: pre-wrap dans Opera, white-space: -moz-pre-wrap dans Firefox ), voire activer ou désactiver à volonté les objets flash intégré dans les pages (X)HTML ;[hreflang!=foo:after]
dans Opera ;cite indiquant la source des éléments de citation blockquote et q, dans Opera et les navigateurs Gecko, ou les
accesskeys non visibles (a[accesskey]:after {content: " [" attr(accesskey) "]"}) ;speech
pour le navigateur Opera en mode vocal ;a:after {content: " (" attr(href) ")"}).Il est évident que peu d'utilisateurs auront sans doute recours à une telle feuille de style « user » avancée, et que la plupart s'en tiendront aux options configurables depuis l'interface de leur navigateur. Notons cependant qu'Opera offre un choix extensible de feuilles de styles utilisateur activables à la volée, pour répondre à divers besoins d'accessibilité ou de développement. En revanche, le potentiel des CSS « user » est encore sous-exploité par les autres navigateurs graphiques.
Quelle est donc la portée finale des styles « user » ? Même en ne prenant en compte que les possibilités de personnalisation élémentaires offertes par les navigateurs les plus répandus, les auteurs ne peuvent ignorer le risque d'une conjonction malheureuse avec leurs propres CSS. Le simple choix d'une couleur d'arrière-plan par l'utilisateur peut suffire à rendre un document inintelligible, lorsque celle-ci se combine à une couleur similaire d'avant-plan côté auteur. De même, le non-affichage des images, ou une taille de caractère plus grande ou plus petite que ce qui était supposé par le designer peut compromettre l'accès au contenu. Dans l'immédiat, on peut retenir quelques précautions à prendre lors de la conception d'un design :
CSS toujours susceptible d'être neutralisé par un style utilisateur.La troisième et dernière source de style est la plus connue : les feuilles de styles associées à la page Web par leur auteur, par le biais des éléments link et style, de la règle CSS
@import ou de l'instruction <?xml-stylesheet?>.
La cascade CSS qui gère la combinaison finale des styles ci-dessus avec ceux prévus par les auteurs définit deux règles de priorité :
Certains agents utilisateurs appliquent par ailleurs un procédé d'adaptation supplémentaire au document. C'est typiquement le cas des navigateurs (X)HTML pour mobiles ou Web TV qui doivent redimensionner certains éléments, restructurer le layout et en modifier les couleurs afin d'optimiser le rendu sur les écrans de taille réduite aux capacités limitées (Small Screen Rendering d'Opera, Smart-Fit Rendering mode de NetFront 3.1, projet Mozilla du futur Minimo, etc.). Opera 8.0 étend ce processus d'adaptation au navigateur desktop avec le procédé ERA qui adapte les données de présentation de la page à la largeur réelle de la zone d'affichage ou de la page imprimée ;
Enfin, les différences d'implémentation CSS entre navigateurs et les bugs de certains d'entre eux limitent la portée de diverses possibilités offertes par les styles CSS. On peut citer comme exemple, parmi beaucoup d'autres :
E[title~="PDF"], E[lang|="en"]) qui ne sont pas supportés par Internet Explorer. La lisibilité du contenu ou l'accès à l'information essentielle ne doit donc pas reposer sur leur support ;Dans un certain nombre de cas, la tentation est grande de recourir à un « hack » CSS pour forcer la présentation ou le comportement voulu dans le ou les navigateurs problématiques. Sachant que la quasi-totalité de ces « hacks » reposent sur des combinaisons de bugs susceptibles d'être modifées dans de futures versions de ces navigateurs, ou sur des syntaxes invalidantes, ou ont des effets de bords imprévisibles selon les conditions utilisateur... Ne vaut-il pas mieux, dans ce cas, accepter que le rendu soit fonction des capacités du navigateur ?
Peut-on, dans ces conditions, prévoir un design au pixel près ? Peut-on vouloir forcer une présentation donnée ? Peut-on subordonner l'accès à une information au respect d'une règle de style ?
Il apparaît clairement que non. Dans tous les cas, le rendu final n'est donc pas conçu pour être un simple duplicata figé du projet du designer. L'ensemble du processus de rendu via CSS invite au contraire celui-ci à savoir composer avec l'interopérabilité et l'accessibilité, en lâchant prise sur le design souhaité : l'auteur propose, l'utilisateur et l'agent utilisateur disposent.