<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Commentaires sur : Des sprites jusqu&#8217;à plus soif</title>
	<atom:link href="http://performance.survol.fr/2008/06/des-sprites-jusqua-plus-soif/feed/" rel="self" type="application/rss+xml" />
	<link>http://performance.survol.fr/2008/06/des-sprites-jusqua-plus-soif/</link>
	<description>Quelques mots pour des sites web rapides</description>
	<lastBuildDate>Sat, 06 Feb 2010 16:59:18 +0100</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Par : Point trop n&#8217;en faut — Performance web</title>
		<link>http://performance.survol.fr/2008/06/des-sprites-jusqua-plus-soif/comment-page-1/#comment-807</link>
		<dc:creator>Point trop n&#8217;en faut — Performance web</dc:creator>
		<pubDate>Wed, 24 Jun 2009 10:01:33 +0000</pubDate>
		<guid isPermaLink="false">http://performance.survol.fr/?p=45#comment-807</guid>
		<description>[...] à plusieurs de ces publications à propos des sprites CSS, il est temps de faire ici un petit complément sur le [...]</description>
		<content:encoded><![CDATA[<p>[...] à plusieurs de ces publications à propos des sprites CSS, il est temps de faire ici un petit complément sur le [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : Florent V.</title>
		<link>http://performance.survol.fr/2008/06/des-sprites-jusqua-plus-soif/comment-page-1/#comment-520</link>
		<dc:creator>Florent V.</dc:creator>
		<pubDate>Sun, 14 Dec 2008 12:22:21 +0000</pubDate>
		<guid isPermaLink="false">http://performance.survol.fr/?p=45#comment-520</guid>
		<description>C&#039;est effectivement un problème de mise en pratique plutôt qu&#039;un défaut inhérent à la technique. Prenons par exemple ta présentation faite à l&#039;AFUP, slide 38: tu reprends une image utilisée par Google Search (google.com, google.fr…), qui suggère très fortement une utilisation abusive. J&#039;ai vérifié sur une page de résultat, et on a bien affaire dans certains cas à une technique de remplacement d&#039;image, même si je dois avouer que dans l&#039;ensemble ils ont très bien fait les choses. Je m&#039;inquiète un peu pour le logo «Google Checkout» et certaines images de bouton (type fermeture de fausse fenêtre), par contre.

Il reste que dans les recommandations sur l&#039;utilisation des sprites mentionnent rarement la question de l&#039;accessibilité. Voir par exemple: http://developer.yahoo.com/performance/rules.html#opt_sprites

Du point de vue strict de la performance (au sens technique, pas commercial), utiliser les sprites y compris pour des boutons d&#039;action sans intitulé fait parfaitement sens. Est-ce le rôle des publications sur la performance web de mentionner ce problème potentiel? Je pense que oui.</description>
		<content:encoded><![CDATA[<p>C&#8217;est effectivement un problème de mise en pratique plutôt qu&#8217;un défaut inhérent à la technique. Prenons par exemple ta présentation faite à l&#8217;AFUP, slide 38: tu reprends une image utilisée par Google Search (google.com, google.fr…), qui suggère très fortement une utilisation abusive. J&#8217;ai vérifié sur une page de résultat, et on a bien affaire dans certains cas à une technique de remplacement d&#8217;image, même si je dois avouer que dans l&#8217;ensemble ils ont très bien fait les choses. Je m&#8217;inquiète un peu pour le logo «Google Checkout» et certaines images de bouton (type fermeture de fausse fenêtre), par contre.</p>
<p>Il reste que dans les recommandations sur l&#8217;utilisation des sprites mentionnent rarement la question de l&#8217;accessibilité. Voir par exemple: <a href="http://developer.yahoo.com/performance/rules.html#opt_sprites" rel="nofollow">http://developer.yahoo.com/performance/rules.html#opt_sprites</a></p>
<p>Du point de vue strict de la performance (au sens technique, pas commercial), utiliser les sprites y compris pour des boutons d&#8217;action sans intitulé fait parfaitement sens. Est-ce le rôle des publications sur la performance web de mentionner ce problème potentiel? Je pense que oui.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : Éric</title>
		<link>http://performance.survol.fr/2008/06/des-sprites-jusqua-plus-soif/comment-page-1/#comment-497</link>
		<dc:creator>Éric</dc:creator>
		<pubDate>Tue, 09 Dec 2008 12:40:35 +0000</pubDate>
		<guid isPermaLink="false">http://performance.survol.fr/?p=45#comment-497</guid>
		<description>Déjà : uniquement pour les images décoratives. Ca ne concerne pas les images de contenu, et ça ne concerne que des images qui ne sont pas indispensables à la compréhension. Bref, de la décoration. Du coup pour moi le problème d&#039;accessibilité est de fait limité.

Il n&#039;est pas question de cacher les intitulés pour les remplacer par un sprite (ce dont tu parles), mais d&#039;ajouter une icone décorative à côté de cet intitulé pour aider l&#039;utilisateur. Pas de problème spécifique d&#039;accessibilité donc. 


Qu&#039;on soit clair, je ne parle PAS de remplacement d&#039;image ici. Et ton problème d&#039;accessibilité est lié au remplacement d&#039;image, pas au sprite.

 Sauf cas exceptionnel celui qui supporte CSS saura tirer profit des règles de positionnement de background donc ça ne posera pas de problème. Si tu te débrouilles bien, dans une majorité des cas tu peux trouver un moyen de positionner ton sprites pour que ça ne &quot;casse&quot; pas même si on augmente les taille de police. Bref, il y a des exceptions mais dans l&#039;ensemble ça fonctionne sans dégats ici aussi.


Après dans CSS3 il y a des moyens de découper l&#039;image précisément (au lieu de simplement la positionner avec le risque de voir les autres icones à côté) et de remplacer le contenu de manière propre (sans aucun risque d&#039;accessibilité). Mais ... en CSS3, donc pas pour tout de suite.</description>
		<content:encoded><![CDATA[<p>Déjà : uniquement pour les images décoratives. Ca ne concerne pas les images de contenu, et ça ne concerne que des images qui ne sont pas indispensables à la compréhension. Bref, de la décoration. Du coup pour moi le problème d&#8217;accessibilité est de fait limité.</p>
<p>Il n&#8217;est pas question de cacher les intitulés pour les remplacer par un sprite (ce dont tu parles), mais d&#8217;ajouter une icone décorative à côté de cet intitulé pour aider l&#8217;utilisateur. Pas de problème spécifique d&#8217;accessibilité donc. </p>
<p>Qu&#8217;on soit clair, je ne parle PAS de remplacement d&#8217;image ici. Et ton problème d&#8217;accessibilité est lié au remplacement d&#8217;image, pas au sprite.</p>
<p> Sauf cas exceptionnel celui qui supporte CSS saura tirer profit des règles de positionnement de background donc ça ne posera pas de problème. Si tu te débrouilles bien, dans une majorité des cas tu peux trouver un moyen de positionner ton sprites pour que ça ne &laquo;&nbsp;casse&raquo;&nbsp; pas même si on augmente les taille de police. Bref, il y a des exceptions mais dans l&#8217;ensemble ça fonctionne sans dégats ici aussi.</p>
<p>Après dans CSS3 il y a des moyens de découper l&#8217;image précisément (au lieu de simplement la positionner avec le risque de voir les autres icones à côté) et de remplacer le contenu de manière propre (sans aucun risque d&#8217;accessibilité). Mais &#8230; en CSS3, donc pas pour tout de suite.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : Florent V.</title>
		<link>http://performance.survol.fr/2008/06/des-sprites-jusqua-plus-soif/comment-page-1/#comment-493</link>
		<dc:creator>Florent V.</dc:creator>
		<pubDate>Tue, 09 Dec 2008 11:09:23 +0000</pubDate>
		<guid isPermaLink="false">http://performance.survol.fr/?p=45#comment-493</guid>
		<description>Hello,

Je m&#039;étonne qu’Aurélien ou Stéphane n&#039;aient pas relevé — au moins à titre d&#039;avertissement — les gros problèmes d&#039;accessibilité potentiels. Ils parlent du cas des images de fond utilisées comme illustration (ou permettant de préciser un intitulé, mais dans tous les cas on a un intitulé), et du risque de voir apparaitre plusieurs icônes pour un même item, par exemple. C&#039;est effectivement un problème (pour ne pas parler des sprites sous la forme de grilles qui demandent d&#039;utiliser un élément vide en HTML si on veut réellement placer une image comme icône sans afficher d&#039;autres images plus à droite, sous le texte), mais c&#039;est loin d&#039;être le principal.

Le principal problème, c&#039;est l&#039;utilisation d&#039;éléments vides ou d&#039;éléments au texte caché (liens et boutons sans intitulé ou liens et boutons dont on cache les intitulés en CSS) pour créer des boutons cliquables à partir d&#039;une image de fond. Ce n&#039;est pas un problème limité aux sprites, mais la technique des sprites incite très clairement à ce type de pratique. Il suffit de voir les images données comme exemple, dans lesquelles on retrouve souvent des boutons et icônes dont on peut supposer qu&#039;ils seront utilisés sans texte HTML visible.

La technique des sprites serait réellement intéressante si elle permettait d&#039;éviter cet écueil, c&#039;est à dire si on pouvait:

1. utililiser l&#039;élément IMG (avec attribut alt) pour afficher une portion d&#039;image et pas l&#039;image complète;
2. utiliser un mécanisme HTML ou CSS standard pour dire «telle portion de telle image est un équivalent strict du contenu de tel élément».

Vu qu&#039;aucune de ces deux solutions n&#039;existe, il y a un risque fondamental pour l&#039;accessibilité des interfaces. Il appartient bien sûr à chaque intégrateur de faire les choses au mieux, mais vu les mythes sur les remplacement d&#039;images accessibles largement répandus j&#039;ai bien peur qu&#039;attirer l&#039;attention sur les sprites ne bénéficie aux performances qu&#039;au détriment de l&#039;accessibilité.

Sinon, dans l&#039;absolu, propriété content + data URI + CSS variables/constants, peut-être un coup à jouer à l&#039;avenir?</description>
		<content:encoded><![CDATA[<p>Hello,</p>
<p>Je m&#8217;étonne qu’Aurélien ou Stéphane n&#8217;aient pas relevé — au moins à titre d&#8217;avertissement — les gros problèmes d&#8217;accessibilité potentiels. Ils parlent du cas des images de fond utilisées comme illustration (ou permettant de préciser un intitulé, mais dans tous les cas on a un intitulé), et du risque de voir apparaitre plusieurs icônes pour un même item, par exemple. C&#8217;est effectivement un problème (pour ne pas parler des sprites sous la forme de grilles qui demandent d&#8217;utiliser un élément vide en HTML si on veut réellement placer une image comme icône sans afficher d&#8217;autres images plus à droite, sous le texte), mais c&#8217;est loin d&#8217;être le principal.</p>
<p>Le principal problème, c&#8217;est l&#8217;utilisation d&#8217;éléments vides ou d&#8217;éléments au texte caché (liens et boutons sans intitulé ou liens et boutons dont on cache les intitulés en CSS) pour créer des boutons cliquables à partir d&#8217;une image de fond. Ce n&#8217;est pas un problème limité aux sprites, mais la technique des sprites incite très clairement à ce type de pratique. Il suffit de voir les images données comme exemple, dans lesquelles on retrouve souvent des boutons et icônes dont on peut supposer qu&#8217;ils seront utilisés sans texte HTML visible.</p>
<p>La technique des sprites serait réellement intéressante si elle permettait d&#8217;éviter cet écueil, c&#8217;est à dire si on pouvait:</p>
<p>1. utililiser l&#8217;élément IMG (avec attribut alt) pour afficher une portion d&#8217;image et pas l&#8217;image complète;<br />
2. utiliser un mécanisme HTML ou CSS standard pour dire «telle portion de telle image est un équivalent strict du contenu de tel élément».</p>
<p>Vu qu&#8217;aucune de ces deux solutions n&#8217;existe, il y a un risque fondamental pour l&#8217;accessibilité des interfaces. Il appartient bien sûr à chaque intégrateur de faire les choses au mieux, mais vu les mythes sur les remplacement d&#8217;images accessibles largement répandus j&#8217;ai bien peur qu&#8217;attirer l&#8217;attention sur les sprites ne bénéficie aux performances qu&#8217;au détriment de l&#8217;accessibilité.</p>
<p>Sinon, dans l&#8217;absolu, propriété content + data URI + CSS variables/constants, peut-être un coup à jouer à l&#8217;avenir?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : laurent</title>
		<link>http://performance.survol.fr/2008/06/des-sprites-jusqua-plus-soif/comment-page-1/#comment-368</link>
		<dc:creator>laurent</dc:creator>
		<pubDate>Thu, 09 Oct 2008 07:37:36 +0000</pubDate>
		<guid isPermaLink="false">http://performance.survol.fr/?p=45#comment-368</guid>
		<description>Je n&#039;affirme rien, je ne fais que poser la question... et en même temps je ne tiens pas compte de l&#039;impression de chacun... si on s&#039;en tenait à nos impressions on serait toujours à croire que la force de la gravité attire de la même manière une plume et un boulet de canon.
Le seul moyen de le savoir serait d&#039;utiliser deux classes heavy-cls (avec un image de 200ko) et light-cls (avec une image de 1px sur 1px) et d&#039;afficher dans une page 99  et 1 ... relever la mémoire pour IE, Opéra... et de switcher light-cls avec heavy-cls et regarder la nouvelle place mémoire utilisée. En 2009 on risque de se pencher sur le problème et à ce moment je ferais les tests et je vous tiendrais informé. Si quelqu&#039;un a du temps pour tester ca avant... l&#039;info m&#039;intéresse :) Merci</description>
		<content:encoded><![CDATA[<p>Je n&#8217;affirme rien, je ne fais que poser la question&#8230; et en même temps je ne tiens pas compte de l&#8217;impression de chacun&#8230; si on s&#8217;en tenait à nos impressions on serait toujours à croire que la force de la gravité attire de la même manière une plume et un boulet de canon.<br />
Le seul moyen de le savoir serait d&#8217;utiliser deux classes heavy-cls (avec un image de 200ko) et light-cls (avec une image de 1px sur 1px) et d&#8217;afficher dans une page 99  et 1 &#8230; relever la mémoire pour IE, Opéra&#8230; et de switcher light-cls avec heavy-cls et regarder la nouvelle place mémoire utilisée. En 2009 on risque de se pencher sur le problème et à ce moment je ferais les tests et je vous tiendrais informé. Si quelqu&#8217;un a du temps pour tester ca avant&#8230; l&#8217;info m&#8217;intéresse :) Merci</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : Éric</title>
		<link>http://performance.survol.fr/2008/06/des-sprites-jusqua-plus-soif/comment-page-1/#comment-341</link>
		<dc:creator>Éric</dc:creator>
		<pubDate>Fri, 03 Oct 2008 13:39:27 +0000</pubDate>
		<guid isPermaLink="false">http://performance.survol.fr/?p=45#comment-341</guid>
		<description>Anthony Ricaud me dit qu&#039;il a posé la question à l&#039;équipe webkit. D&#039;après eux une image n&#039;apparait qu&#039;une seule fois en mémoire si elle est toujours référencée par la même URL. 
Il ajoute, et je suis d&#039;accord, que c&#039;est assez logique et qu&#039;il serait étonnant que d&#039;autres moteurs fonctionnent différemment.

Reste donc le fait qu&#039;on charge une grosse image pour potentiellement ne pas tout utiliser, mais là franchement c&#039;est moi qui vais affirmer que si vous ne faites pas n&#039;importe quoi, c&#039;est plus que négligeables dans le cas qui nous préoccupe.

(Note: Anthony n&#039;arrive pas à envoyer son commentaire, je ne sais pas pourquoi. Si quelqu&#039;un est dans la même situation, envoyez moi un mail)
(qui n&#039;arrive pas à poster de commentaire, je ne sais pas pourquoi</description>
		<content:encoded><![CDATA[<p>Anthony Ricaud me dit qu&#8217;il a posé la question à l&#8217;équipe webkit. D&#8217;après eux une image n&#8217;apparait qu&#8217;une seule fois en mémoire si elle est toujours référencée par la même URL.<br />
Il ajoute, et je suis d&#8217;accord, que c&#8217;est assez logique et qu&#8217;il serait étonnant que d&#8217;autres moteurs fonctionnent différemment.</p>
<p>Reste donc le fait qu&#8217;on charge une grosse image pour potentiellement ne pas tout utiliser, mais là franchement c&#8217;est moi qui vais affirmer que si vous ne faites pas n&#8217;importe quoi, c&#8217;est plus que négligeables dans le cas qui nous préoccupe.</p>
<p>(Note: Anthony n&#8217;arrive pas à envoyer son commentaire, je ne sais pas pourquoi. Si quelqu&#8217;un est dans la même situation, envoyez moi un mail)<br />
(qui n&#8217;arrive pas à poster de commentaire, je ne sais pas pourquoi</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : Éric</title>
		<link>http://performance.survol.fr/2008/06/des-sprites-jusqua-plus-soif/comment-page-1/#comment-335</link>
		<dc:creator>Éric</dc:creator>
		<pubDate>Fri, 03 Oct 2008 10:03:38 +0000</pubDate>
		<guid isPermaLink="false">http://performance.survol.fr/?p=45#comment-335</guid>
		<description>C&#039;est une technique employée avec succès partout où je l&#039;ai vue, sur IE aussi, sans faire ramer le navigateur. J&#039;aurai donc tendance à dire &quot;foncez&quot;.

Maintenant un test objectif n&#039;est jamais de trop donc je t&#039;invite à tester, et à nous faire des retours si tu vois quelque chose d&#039;étrange. Je doute cependant que cela puisse être un problème dans ce cas précis.</description>
		<content:encoded><![CDATA[<p>C&#8217;est une technique employée avec succès partout où je l&#8217;ai vue, sur IE aussi, sans faire ramer le navigateur. J&#8217;aurai donc tendance à dire &laquo;&nbsp;foncez&raquo;&nbsp;.</p>
<p>Maintenant un test objectif n&#8217;est jamais de trop donc je t&#8217;invite à tester, et à nous faire des retours si tu vois quelque chose d&#8217;étrange. Je doute cependant que cela puisse être un problème dans ce cas précis.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : laurent</title>
		<link>http://performance.survol.fr/2008/06/des-sprites-jusqua-plus-soif/comment-page-1/#comment-334</link>
		<dc:creator>laurent</dc:creator>
		<pubDate>Fri, 03 Oct 2008 07:10:41 +0000</pubDate>
		<guid isPermaLink="false">http://performance.survol.fr/?p=45#comment-334</guid>
		<description>La gestion de la mémoire n&#039;est pas le fort d&#039;IE, et pour le confort de l&#039;utilisateur on doit faire très attention aux problèmes de mémoire.
Je travail sur des RI.A. et quand tu te retrouves avec un IE ou FF utilisant 2Go de mémoire après 20 minutes d&quot;utilisation, je te jure que ca fait pas plaisir à l&#039;utilisateur, surtout si au final on aboutit à un plantage du navigateur.
Alors d&#039;accord, on aura gagné quelques secondes au chargement de la page mais si c&#039;est au prix d&#039;un redémarrage du navigateur au bout de quelques minutes d&#039;utilisation, ou pire un redémarrage de l&#039;ordinateur, je doute que l&#039;utilisateur apprécie ce petit bénéfice :)</description>
		<content:encoded><![CDATA[<p>La gestion de la mémoire n&#8217;est pas le fort d&#8217;IE, et pour le confort de l&#8217;utilisateur on doit faire très attention aux problèmes de mémoire.<br />
Je travail sur des RI.A. et quand tu te retrouves avec un IE ou FF utilisant 2Go de mémoire après 20 minutes d&raquo;&nbsp;utilisation, je te jure que ca fait pas plaisir à l&#8217;utilisateur, surtout si au final on aboutit à un plantage du navigateur.<br />
Alors d&#8217;accord, on aura gagné quelques secondes au chargement de la page mais si c&#8217;est au prix d&#8217;un redémarrage du navigateur au bout de quelques minutes d&#8217;utilisation, ou pire un redémarrage de l&#8217;ordinateur, je doute que l&#8217;utilisateur apprécie ce petit bénéfice :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : Éric</title>
		<link>http://performance.survol.fr/2008/06/des-sprites-jusqua-plus-soif/comment-page-1/#comment-333</link>
		<dc:creator>Éric</dc:creator>
		<pubDate>Thu, 02 Oct 2008 12:31:27 +0000</pubDate>
		<guid isPermaLink="false">http://performance.survol.fr/?p=45#comment-333</guid>
		<description>Sérieusement je ne sais pas. C&#039;est à tester.
Ce qui est sur c&#039;est que même sur les petites machines c&#039;est au final plus performant côté utilisateur. Donc que même si ça occupait plus de mémoire, c&#039;est tout de même au bénéfice de l&#039;utilisateur. Le bénéfice de l&#039;utilisateur reste ce qui reste le plus important, et troquer une ressource chère contre une ressource pas chère est toujours pertinent.</description>
		<content:encoded><![CDATA[<p>Sérieusement je ne sais pas. C&#8217;est à tester.<br />
Ce qui est sur c&#8217;est que même sur les petites machines c&#8217;est au final plus performant côté utilisateur. Donc que même si ça occupait plus de mémoire, c&#8217;est tout de même au bénéfice de l&#8217;utilisateur. Le bénéfice de l&#8217;utilisateur reste ce qui reste le plus important, et troquer une ressource chère contre une ressource pas chère est toujours pertinent.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : laurent</title>
		<link>http://performance.survol.fr/2008/06/des-sprites-jusqua-plus-soif/comment-page-1/#comment-332</link>
		<dc:creator>laurent</dc:creator>
		<pubDate>Thu, 02 Oct 2008 10:29:10 +0000</pubDate>
		<guid isPermaLink="false">http://performance.survol.fr/?p=45#comment-332</guid>
		<description>l&#039;idée est intéressante mais cotés mémoire pour les navigateurs ?
En flash, un sprite, une fois dans la bibliothèque peut être utlisé 1 000 000 de fois sans nécessité d&#039;avantage de mémoire mais sous IE, ou FF ou opéra, comment gère t&#039;il l&#039;image en mémoire si celle ci est utilisée à plusieurs endroits différents ? Quelqu&#039;un sait ?
On travail sur des IHM de plus en plus gourmand en mémoire avec les framework javascript etc... je trouve que ca a son importance.</description>
		<content:encoded><![CDATA[<p>l&#8217;idée est intéressante mais cotés mémoire pour les navigateurs ?<br />
En flash, un sprite, une fois dans la bibliothèque peut être utlisé 1 000 000 de fois sans nécessité d&#8217;avantage de mémoire mais sous IE, ou FF ou opéra, comment gère t&#8217;il l&#8217;image en mémoire si celle ci est utilisée à plusieurs endroits différents ? Quelqu&#8217;un sait ?<br />
On travail sur des IHM de plus en plus gourmand en mémoire avec les framework javascript etc&#8230; je trouve que ca a son importance.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
