Styles auteur, utilisateur et agent utilisateur : 3 raisons de lâcher prise sur votre design

Openweb.eu.org > Articles  > Styles auteur, utilisateur et agent utilisateur : 3 raisons de lâcher prise sur votre design

Abstract

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.

Article

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.

Les styles par défaut de l'agent utilisateur

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 les Règles d'accessibilité des agents utilisateurs, ils doivent garantir en toutes circonstances l'accès à une « version brute » du document (X)HTML qui préserve le minimum vital de présentation nécessaire à sa compréhension, lorsqu'aucunes autres données de présentation auteur ou utilisateur ne sont prises en compte ;
  • Selon la spécification HTML4.01, ils doivent garantir « l'interprétation conventionnelle » des éléments (X)HTML. Il s'agit en particulier :

    • de masquer la section head du (X)HTML (propriété display: none) ;
    • de différencier les éléments blocs et les éléments en ligne (propriétés display: block et display: inline) ;
    • de permettre le rendu des éléments de liste (display: list-item) et de leurs marqueurs ;
    • de permettre le rendu des tableaux (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 :

  • L'élément body est doté de marges de 8px par Firefox et par Internet Explorer. Opera, lui, utilise un padding de la même dimension ;
  • Tandis que Firefox utilise un 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) ;
  • La ligne de séparation horizontale 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 ;
  • Les éléments 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 :

  • D'une part, malgré leur relative homogénéité d'un navigateur à l'autre, les quelques différences rencontrées peuvent compliquer la tâche aux auteurs se fiant au rendu de leur document dans un seul navigateur. Le cas typique est celui de la suppression ou de la modification de l'indentation à gauche des éléments de liste dans un menu en colonne : un auteur se basant sur le rendu dans Firefox verra sa mise en page se dégrader fortement dans Opera et Internet Explorer. Les auteurs doivent donc tenir compte des propriétés pertinentes pour chaque navigateur, à défaut d'entreprendre leur totale suppression (Voir les essais en ce sens d'Eric Meyer et de Tantek Çelik).
  • D'autre part, la spécification HTML4.01 reste vague quant à la marge de manoeuvre laissée aux auteurs envers cette « interprétation conventionnelle ». Tout au plus peut-on y lire que : 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 ?
  • Enfin, leur rôle étant incorrectement perçu par de nombreux auteurs, ces styles par défaut ont souvent favorisé des choix de balisage en fonction du seul rendu visuel, et non de la pertinence structurelle (« je n'utilise pas 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.

Les styles utilisateur

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 :

  • soit via l'interface utilisateur du navigateur (Menu Préférences > Style de Page dans Opera, menu Outils > Options Internet dans IE, Menu Outils > Options > Générales dans Firefox) ;
  • soit sous forme d'une feuille de style à part entière, écrite comme toute autre CSS, enregistrée localement et appliquée par le navigateur aux pages Web consultées.

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 :

  • Les couleurs d'arrière-plan et d'avant-plan par défaut ;
  • Les polices et tailles de caractères par défaut (avec la possibilité de sustituer les polices utilisateurs à celles de l'auteur, ou de spécifier une taille de caractère minimale) ;
  • L'apparence et le comportement des hyperliens au survol de la souris (couleur, soulignement) ;
  • L'affichage des images.

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 :

  • Pour supprimer par exemple des contenus publicitaires dans Firefox ou Opera ;
  • Pour empêcher le défilement des éléments 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 ;
  • Pour corriger le résultat d'un bug de rendu de son navigateur, tel que le sélecteur d'attribut [hreflang!=foo:after] dans Opera ;
  • Pour tirer parti d'un contenu non exploité par défaut par le navigateur, tel que l'attribut 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) "]"}) ;
  • Pour permettre la restitution des pages Web sur un media que leurs auteurs n'ont pas pris en compte, à l'exemple des feuilles de styles speech pour le navigateur Opera en mode vocal ;
  • Pour améliorer l'impression des pages Web en forçant celle des URL après les liens (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 :

Les styles auteurs

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é :

  • Les styles de l'auteur l'emportent sur ceux de l'agent utilisateur... dans la mesure où les propriétés nécessaires ont été spécifiées ;
  • Les styles de l'auteur l'emportent sur ceux de l'utilisateur... sauf lorsque celui-ci, par le biais de la propriété !important, décide de les outrepasser, ou que ses préférences sont exprimées par le biais des options offertes par le navigateur.

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 :

  • Les sélecteurs d'attribut évolués CSS2 (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 ;
  • Le modèle de boîte spécifique suivi par Internet Explorer Windows 5.x dans tous les cas, et par IE6.0 en mode Quirks, qui perturbe les mises en pages ne laissant pas un jeu suffisant entre des éléments adjacents (en particulier quand interviennent des flottants) ;
  • La position fixe, non supportée par Internet Explorer Windows jusqu'à la version 6.0 comprise, etc.

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 ?

Conclusion : lâchons prise !

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.

À propos de cet article

  • Openweb.eu.org
  • Profil : Débutant, Expert
  • Technologie : CSS
  • Thème : Mise en page
  • Auteur :
  • Publié le :
  • Mise à jour : 2 juillet 2008

Vos commentaires

modération a priori

Attention, votre message n’apparaîtra qu’après avoir été relu et approuvé.

Qui êtes-vous ?
Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Suivre les commentaires : RSS 2.0 | Atom