Accueil > weblog
- Lire le billet précédent - Lire le billet suivant -
Par Laurent Denis, le 24 octobre 2004.
Il arrive régulièrement que l'on braque les projecteurs sur une propriété CSS ou un élément HTML jusque-là peu employé, et dont on découvre tout à coup sinon l'existence, du moins les multiples possibilités d'utilisation. Généralement, après une période d'enthousiame et d'inventivité plus ou moins heureuse, on en vient à un usage plus limité, mais plus raisonné de l'outil en question (voir la mode des listes de définition par exemple).
Il semble, à lire Raphael Goetter et sa collègue Nanoum, que ce soit aujourd'hui le tour de la propriété content liée aux sélecteurs :before et :after. Aussi me permettrais-je de proposer cette petite anayse de leur usage :
Dans ce premier cas de figure, nous ne génèrerons aucun contenu à proprement parler. Il s'agit simplement d'utiliser les sélecteurs :before ou :after et la propriété content pour rendre visible un contenu HTML existant mais non rendu visuellement par le navigateur graphique.
Le cas type est celui des nombreux attributs peu ou pas exploités par nos navigateurs actuels :
hreflang indiquant la langue primaire du document cible d'un lien a ;rel et rev indiquant la relation entre la source et le document cible d'un lien a ;cite indiquant l'URI de la source d'une citation blockquote ou q ;datetime indiquant la date d'une modification du contenu balisé à l'aide de ins ou de del ;cite indiquant l'URI d'un document justifiant une modification du contenu balisé à l'aide de ins ou de del ;alt véhiculant le descriptif abrégé d'une image img, qui peut être utilisé comme légende de celle-ci ;longdesc véhiculant l'URI du descriptif détaillé d'une image img ;id qui permet de créer un lien direct vers la section correspondante du contenu (div ou titre hn concerné) ;Dans plusieurs des cas ci-dessus, nous avons affaire à une URL qu'il est alors possible de transformer en pseudo-lien cliquable (par le biais du menu contextuel).
Dans le même ordre d'idée, content, :before et :after permettent également d'enrichir le rendu du document lorsqu'il est imprimé, en y faisant figurer le contenu d'attributs habituellement ignoré dans le media print :
href) ;abbr et acronym) à la suite de leur intitulé, ou plus élégamment en affichant la signification du sigle suivie de celui-ci entre-parenthèses, ce qui est plus conforme aux usages de l'écrit (attribut title) ;Nous pouvons encore jouer de même sur le media et ces sélecteurs pour enrichir le rendu oral du document dans un navigateur vocal comme Opera 7.60, ou faire de même dans le media projection.
Dans la catégorie "extrême", nous pouvons exploiter ces sélecteurs et la propriété content pour rendre visible les informations habituellement masquées dans le head du document : title et liens relatifs, mais aussi style et liens vers les feuilles de style, meta et autres link rel="alternate" indiquant par exemple l'URL des fils RSS. On peut ainsi créer une feuille de style alternative amusante, ou simuler les affichages d'un navigateur texte. Plus sérieusement, une feuille de style utilisateur de ce type est un outil de test et de débogage précieux sous Opera.
Dans chacun de ces cas, rien n'est ajouté au document brut, et nous ne faisons que suppléer aux limitations ou aux carences des outils de navigation actuels qui n'exploitent qu'une faible part du contenu HTML. Nous ne rendons donc aucune infomation-clé dépendante du fonctionnement de notre astuce CSS, et notre document n'y perd ni en accessibilité ni en interopérabilité.
Notons cependant une fausse bonne idée classique dans ce domaine : générer à l'aide d'un content et d'un :after l'affichage de l'accesskey d'un lien : cette information sera absente dans les navigateurs textes et dans de nombreuses configurations de lecteurs d'écran... alors qu'elle est justement destinée en particulier à leur utilisateurs ;
Une autre idée discutable consisterait à remplacer la date explicite d'un document par le rendu CSS de l'attribut datetime d'un ins englobant le contenu (voir le code source de la page d'accueil de ce site). Il serait certes apparemment élégant d'utiliser ainsi le seul élément HTML capable de véhiculer explicitement une information de date, en remplaçant dans un blog par exemple :
<div class="post"> <p class="date">2004-10-24</p> ... </div>
...Par :
<ins datetime="2004-10-24">
...
</ins>
ins:before {
display: block;
content: attr(datetime);
}
Mais là encore, nous conditionnerions l'accès à l'information au support de cet aspect de la technologie CSS. Il convient donc d'être prudent : CSS n'est pas un moyen fiable pour suppléer réellement aux carences des navigateurs dans l'exploitation du HTML.
Notons pour conclure cette partie que le champ d'application de CSS n'est pas limité au HTML, et que cette combinaison :after, :before et content permet tout aussi bien d'autoriser l'affichage graphique (et anecdotique) de documents XML du type RSS, ou FOAF.
[edit] En conclusion de cette partie, je reprendrais en fait l'excellente formulation de David Latapie (voir commentaires ci-dessous) selon lequel
.ins:before est un hack. Non pas un hack pour un navigateur, mais un hack pour tous les navigateurs. Mais ce n'en est pas moins un hack... ins:before est une vraie bonne idée, à partir du moment où l'on se souvient qu'un hack participe du confort, pas de l'accès.
L'utilisation la plus neutre de ces outils consiste en fait à insérer des motifs graphiques dans la présentation du document :
Vous êtes dansqui améliore le rôle de "fil d'Ariane" donné au titre
h1 :
<h1>
<a href="/" title="..." accesskey="1">Blog & Blues</a>
<span>
>
<a href="..." title="...">Novembre 2004</a>
–
<a href="..." title="...">Thème : <abbr>(X)HTML</abbr> - <abbr>CSS</abbr></a>
</span>
</h1>
h1 span:before {
content: "Vous êtes dans "
}Cette fois, une partie du rendu visuel sera bien conditionné à l'implémentation des sélecteurs :before ou :after et la propriété content, mais ceci ne concerne aucune information nécessaire à l'accès au contenu. Nous sommes entièrement dans le domaine de la présentation CSS.
La facilité d'utilisation de la propriété content et l'apparente économie de gestion de contenu ainsi réalisée peuvent cependant conduire à un abus aussi dommageable pour le sens que pour l'accessibilité : retirer un contenu HTML pour en faire un contenu généré CSS, autrement dit, utiliser CSS pour ajouter au document une information nécessaire à sa compréhension ou son utilisation. Ceci concerne en particulier :
Si CSS offre effectivement les moyens de générer du contenu, il serait plus exact et plus prudent de parler de pseudo-contenu, en réalité absent du document, et donc inexistant pour une large partie des utilisateurs, et pour la quasi-totalité des "machines" d'indexation, de traduction, etc.
1. Le 25 octobre 2004 à 01:49, de Empyrée
Réflexions sur la génération automatique
Laurent Denis, que je ne vous ferais pas l?insulte de présenter (bon allez, si quand même : chantre de l?accessibilité et rédacteur Openweb) s?est fendu d?un excellent billet sur la génération automatique de contenu. Il y relate plusieurs...
Les trackbacks pour ce billet sont temporairement fermés en raison d'une série d'attaques de spam.
Commentaires
Moz, le 24 octobre 2004
Et tout ça est invisible dans IE.
Laurent Denis, le 24 octobre 2004
Tout comme, à l'inverse, Opera est actuellement le seul à appliquer la propriété content à n'importe quel sélecteur, et pas seulement à :before et :after... Cela n'a aucune importance dès lors qu'on ne détourne pas cette propriété de son usage, c'est à dire générer du superflu
mee2, le 24 octobre 2004
C'est un peu comme utiliser des tableaux pour la présentation, mais dans l'autre sens; avant, on utilisait HTML pour la présentation, maintenant, on prend CSS pour faire le contenu. =)
Laurent Denis, le 24 octobre 2004
On va beaucoup plus loin que les abus éventuel visés ici, mais en poussant un peu le bouchon, on arriverait à faire une pseudo-page générée en CSS, dont le code HTML se réduirait à quelque-chose comme:

<body>
<div id="header"></div>
<div id="content">
<div id="section1"></div>
<div id="section2"></div>
<div id="section3"></div>
</div>
<div id="menu"></div>
<div id="footer"></div>
</body>
David Latapie, le 24 octobre 2004
Excellent article, sur lequel j'émettrais un seule réserve.
J'utilise sur mon blog la méthode du ins:after. Je ne crois pas que ce soit un problème.
L'information est là, comme tu le dis, elle n'est juste pas gérée par les navigateurs. Tous les navigateurs que je connait (c'est-à-dire principalement graphiques) signaleront la mise à jour. Certes, ils ne rendent pas la date mais ce n'est pas, il me semble, au webmestre de pallier les défaillances du navigateur.
ins:before est un hack. Non pas un hack pour un navigateur, mais un hack pour tous les navigateurs. Mais ce n'en est pas moins un hack
À quoi sert un hack ? À rendre la lecture plus confortable, *pas* à la rendre possible.
Ma conclusion est que ins:before est une vraie bonne idée, à partir du moment où l'on se souvient qu'un hack participe du confort, pas de l'accès.
Je ne suis pas sûr de m'être fait comprendre, là.
Laurent Denis, le 24 octobre 2004
Tu te fais très bien comprendre, et ton blog (dont il faut saluer le design particulièrement harmonieux) l'illustre bien : tu utilise ins:after pour **les mises à jour de tes billets, et non pour la date du billet lui-même**, laquelle figure "en dur" dans le HTML.
Il faudrait que je prenne le temps d'écrire cela proprement.
Ce que je visais ici à propos d'<ins> était une de mes propres tentations : ayant délimité chaque billet par un <ins datetime="..."> dès sa mise en ligne, il serait tentant de considérer que je n'ai plus à y répéter la date de publication dans le contenu...
Bien-sûr, cette idée de délimiter un billet entier a-priori à l'aide d'un <ins> est discutable, puisqu'<ins> vise une modification du contenu, et non sa création...
Là, c'est moi qui ne suit pas sûr de me faire comprendre
David Latapie, le 25 octobre 2004
Merci Laurent pour les compliments. Rendons à César ce qui lui appartient, Olivier Meunier et Maurice Svay ont une grande part de responsabilité dans mon blog (même si je assez fier de mes propre ajouts).
Je voulais initialement te laisser une petite réponse mais les deux lignes se sont transformées en deux paragraphes puis en deux chapitres… Finalement, un article de réponse me semble plus approprié.
David Latapie, le 25 octobre 2004
J'ai oublié de dire:
Je te retourne ta première phrase : tu te fais très bien comprendre ;-) et je partage les même doutes quant à un ins a priori.
Mothendur, le 25 octobre 2004
J'ai été effaré de voir un très recent thread sur GeckoZone où certains participants (même un admin) n'arrivaient pas à comprendre que ces contenus générés en CSS ne faisaient pas partie du document, et n'avaient d'un but décoratif et non sémantique...
douru, le 04 novembre 2004
"On va beaucoup plus loin que les abus éventuel visés ici, mais en poussant un peu le bouchon, on arriverait à faire une pseudo-page générée en CSS, dont le code HTML se réduirait à quelque-chose comme:
<body>
<div id="header"></div>
<div id="content">
<div id="section1"></div>
<div id="section2"></div>
<div id="section3"></div>
</div>
<div id="menu"></div>
<div id="footer"></div>
</body>"
Excuse moi, mais qu'a de mal cette méthode ? Elle est très claire...
J'aurais besoin de plus d'éclaircissement sur ton point de vue là....
facko, le 04 novembre 2004
Oui, moi non plus. Les css servent bien à définir l'aspect graphique du site, non ?
Cette méthode permet bien ceci.
Quelquechose semble m'échapper.
Si on veut définir l'aspect graphique de la section 1 (dans lequel on pourrait mettre disons les news...)
puis la sesction 2 dans lequel on mettrait heu...autre chose.
Je vois pas vraiment le problème de proceder de cette façon ?
Laurent Denis, le 05 novembre 2004
@douru, facko> Je voulais dire que le code ci-dessus serait accompagné d'une CSS du type:
#header {
content:"_ici le titre du site_";
display: ...
}
#section1 {
content: "_ici le texte de la section 1_";
...
}
qui **déplacerait** le contenu du HTML vers la CSS. Autrement dit, le <body> du document se réduirait vraiment au code ci-dessus.
(Ce code apparemment fantaisiste serait aujourd'hui parfaitement fonctionnel dans Opera qui supporte la propriété content appliqué à tous les sélecteurs, à la manière CSS3).
Douru, le 05 novembre 2004
D'accord, je comprend beaucoup mieux. D'un coup, j'avais eu peur car la structure de mon site ressemblait beaucoup à celle citée.
Mais là, je suis entièrement d'accord avec toi. Les CSS doivent rester pour la présentation. Quoique ça m'a fait pensé au fait que content pourrait servir à changer le contenu d'un élément en fonction de la feuille de style choisie. Cela peut être pratique pour par exemple changer le titre de la page en fonction de celle-ci par exemple..
Les commentaires pour ce billet sont temporairement fermés en raison d'une série d'attaques de spam.