Sprites et clipping

Toujours en quête de meilleures performances, je m’attarde et j’extrapole (un peu) sur les sprites CSS.

Sprites

Je l’avoue, bien que connaissant la technique, je n’y trouvais jusqu’alors pas une grande utilité (outre pour les changements d’états au survol).

Maintenant qu’il est question de performances, la réponse est toute autre et j’utilise bien plus souvent cette astuce. C’est un peu contraignant de produire des images démesurément grandes et de tout bien caler, mais on s’en sort quand même sans trop de heurts.

Je tâche toutefois de bien espacer mes sprites, pour permettre un agrandissement du texte dans le navigateur sans effet de bord sur l’affichage.

Clipping

De la même manière que je le fais maintenant pour mes images décoratives, je m’interrogeais sur la pertinence d’avoir une multitude d’images appelées dans le HTML. Pourquoi ne pas réduire de la même manière le nombre de requêtes ?

Je passe en revue plusieures solutions.

Techniques de masquages par CSS

<div style="width:100px;height:50px;backgroud-image:url(texte.png);">
    <span class="masquer">Texte</span>
</div>

Il s’agit là d’une technique plutôt connue mais qui pose je crois, pas mal de problèmes d’accessibilité. On s’empêche tout simplement d’utiliser des images de contenu et on ruse par CSS pour garantir un affichage conforme à grand coup d’images de fond.

Bref, on détourne le problème et on s’en crée des nouveaux… pas convaincu.

Images map

<img src="menu.png" alt="Menu" title="" width="150" height="50" usemap="#menu" />
<map id="menu" name="menu">
    <area alt="Lien 1" href="#lien_1" coords="0, 0, 75, 50" shape="rect"/>
    <area alt="Lien 2" href="#lien_2" coords="75, 0, 150, 50" shape="rect"/>
</map>

C’est déjà plus accessible. Mais on perd par contre toute information sémantique autour de nos liens et c’est un peu casse-pied à mettre en place. Pourquoi pas dans certaines occasions (typiquement une carte géographique).

Clipping

Je me souviens alors d’un vieil article de Laurent Denis sur le clipping et après avoir farfouillé un peu, on obtient quelque chose qui tient à peu prêt la route.

Qu’en pensez-vous ? Ça vaut le coup de se donner du mal comme ça pour les performances ?

Les inconvénients que j’y vois au premier abord sont :

  • le poids ajouté au fichier CSS (augmenté encore un peu plus pour notre ami IE) ;
  • l’accessibilité ;
  • la complexité relative de la technique ;
  • et surtout l’affichage un peu étrange de la page CSS désactivées et images activées.

Les avantages :

  • le nombre de requêtes HTTP réduit ;
  • l’accessibilité (merci Stéphane hein !) ;
  • la sémantique du code ;
  • et la possibilité de faire un changement d’image au survol sans ajout de JS.

13 commentaires ↓

#1 CUT HERE le 08.21.08 à 7:41

Je trouve ça tout de même plus compliqué. Au niveau des images de menu, ça n’est pas (pour moi) des images de contenus mais plutôt de l’interface.

#2 HeyTi1 le 08.21.08 à 9:24

hello a tous et a toutes.

alors pour moi la dernière solution ne me parrait pas bonne du tout et ceux pour plusieurs raisons :

1) séparation de la forme et du contenu ; en effet, dans le dernier cas, le contenu « text » est interne a l’image (bhououou pas bien), de ce fait nous ne sommes pas dans le respect des bonnes pratiques actions-design-datas séparés.

2) a tous nos amis dev back, celle-ci est pour vous. Dans la logique, plus aucuns sites n’utilisent de langages coté back, pour mettre en place ce type de menu, le dev back doit générer une image coté serveur avec les éléments du menu, je vous raconte pas la merde a mettre en place, et d’autant plus pour concilier les classes de clipping avec les éléments de menu en image générés en back.

3) D’une manière générale, les navigateurs modernes (j’ai bien dis modernes) ont un lissage de police assez agréable pour peu que la taille de celle-ci soit relativement grosse. je ne connais pas un client qui n’ai pas accepté d’avoir ses typos de menu en texte (bon ça nécessite de batailler un peu l’argumentaire mais c’est souvent efficace).

c’est vrais que le problème d’agrandissement de typo coté client avec les images de fond en css est problématique.

#3 Vincent le 08.21.08 à 9:34

J’ai pris l’exemple d’un menu de navigation pour illustrer la technique mais ça pourrait coller à n’importe quelle image de contenu hein… :)

#4 HeyTi1 le 08.21.08 à 9:38

ouai j’ai bien compris vincent 😀

#5 Vincent le 08.21.08 à 9:52

Petite précision : pour le moment le survol ne marche pas sous IE 6… étrange.

#6 Vincent le 08.21.08 à 10:07

Etienne : alors c’est moi qui ne comprends pas tout à tes retours. 😉

Peu importe que l’image présente un texte ou pas au final, la technique est intéressante non ?

Et je n’ai pas compris non plus ce qu’il se passe en back-office.

Bref, je ne dois pas être bien réveillé encore.

#7 Stéphane Deschamps le 08.21.08 à 13:24

Ma remarque du jour : l’inconvénient des sprites sur des images, c’est dans le cas où les CSS sont désactivées, comme tu l’as noté. (et tu as bien fait de le noter, sinon le vilipendage aurait été salé, HAHAHA, je suis diabolique).

Je prends toujours les CSS et le JS comme la cerise sur le gâteau : amélioration de l’interface (respectivement de son design et de son comportement), et on part évidemment toujours du principe que l’un comme l’autre peuvent casser (lenteur réseau, déconnade d’une ressource liée, etc.).

Là si pour une raison ou une autre la CSS ne se charge pas (me revoilà avec mon téléphone mobile, talalaaaa !), c’est carrément hideux et plus ou moins inutilisable, sauf à se référer au texte alternatif, ce que ne font pas les humains sains d’esprit qui ne travaillent pas dans notre domaine.

Donc pour moi, les sprites pour les CSS, oui, mais les sprites pour les images, non !

Votez pour moi ! Je vous promets une abrogation généralisée des images en sprites si je suis élu !

#8 Stéphane Deschamps le 08.21.08 à 13:28

J’oubliais, pour conclure (et pour arrêter de dire des bêtises deux minutes) : il faudrait retirer l’accessibilité des avantages des sprites, donc.

#9 Vincent le 08.21.08 à 13:32

Mes illusions de conquête du monde (Web) volent en éclats. Snif !

#10 Shemu le 08.21.08 à 13:41

Pour l’agrandissement du texte sur une technique de sprite, en théorie ce n’est pas un problème puisque que tu utilises une image de fond avec tes tailles fixes. Ainsi tu dois fixer les dimensions de ton sprite pour empêcher la flexibilité de ses zones. PS : A quand Herzog ? :o)

#11 Eric le 08.29.08 à 16:53

Stéphane, les sprites sont toujours pour les images, mais pour les images décoratives (donc logiquement déclarées dans la CSS, oui). Je sais que c’est ce que tu sous-entendais mais je préfère le mettre au clair.

J’ai trop souvent vu des gens lire les conclusions sans les comprendre et je ne voudrai pas qu’on me dise « ah non, ne fais pas de sprites avec tes images ».

#12 ellm le 09.11.08 à 15:41

Si les inconvénients et avantages donnés à la fin du billet concernent la comparaison Sprites / Clipping, alors je ne vois pas bien l’intérêt du dernier point des avantages. Avec les Sprites non plus il n’y a pas d’ajout de JS, il me semble.

Comment ça j’essaie sournoisement de diminuer le nombre d’avantages… meuuuh non. ^^

#13 Vincent le 09.11.08 à 15:49

Tiens, salut Etienne ! :)

Non non, je ne compare pas sprite et clipping, je ne parle que du clipping dans ce paragraphe.


Laisser un commentaire

Mise en forme : vous pouvez utiliser la syntaxe Markdown. Vous verrez, c’est chouette !