1

Onderwerp: Sprites, automatisch of handwerk?

Eenvoudige vraag, hoe gaan jullie om met sprites?
- Online tools (vb: http://spritegen.website-performance.org/)
- Offline tools (bestaan er goede offline tools?)
- Zelf gemaakte tools
- Of gewoon handwerk...

Zelf produceer ik ze meestal handmatig met 10x10 grid in photoshop. Op zich zou ik dit wel willen automatiseren, maar waar ik met de automatische tools tegenaan loop is het volgende:
- Tooltje genereert sprite met bijv. 10 plaatjes.
- 1 van deze plaatjes wordt 5px groter, waardoor (een aantal) coordinaten in de sprite wijzigen.
- Image cache en CSS cache worden niet direct geforceerd, waardoor er scheve sprites ontstaan.

Of bijvoorbeeld ook:
- Je hebt een sprite van 10 plaatjes via tool komen ze op alfabetische volgorde.
- Nu komt er een plaatje bij die qua alfabet tussen de andere plaatjes verschijnt.
- Ook hier weer; cache van browsers/css/images zorgen voor rare plaatjes.

Nu kun je caching-headers wel forceren, maar zoals jullie weten is de ene browser de andere niet wink


Eigenlijk zoek ik een tooltje, waarmee het genereren van sprites semi-automatisch gaat.
Nu heb ik eerder dit soort plugins geprobeerd, maar ook hiermee ging het niet 100% soepel:
Fireworks: http://www.andrewingram.net/articles/ge … fireworks/
Photoshop: http://asouza.com/blog/?p=119

De vraag is, bestaan er bijvoorbeeld dit soort (online/offline) tooltjes:
http://img208.imageshack.us/img208/7607/csssprite.png

2

Re: Sprites, automatisch of handwerk?

Ken je http://spriteme.org/ en http://compass-style.org/help/tutorials/spriting/?

Nog een handig tooltje: http://www.spritecow.com/

3

Re: Sprites, automatisch of handwerk?

Compass in combinatie met Sass, zie de link van Krijn. Met de hand maken is killing als je eens iets wilt aanpassen zónder hier meer dan 1 minuut aan te besteden smile Caching probleem is hiermee ook opgelost: Compass bakt een sprite met een bestandsnaam met een wisselende fingerprint/digest. Als je sprite "foo" heet, dan maakt Compass er "foo-24bc6ef.png" van bijv (digest is gebaseerd op de inhoud van het bestanden en dus altijd uniek voor een nieuwe sprite).

4

Re: Sprites, automatisch of handwerk?

Waarom zou je deze dag nog sprites gebruiken? IE8+ en elke andere moderne browser ondersteunen base64 encoded images die je inline in je CSS kan stoppen.

Dit is makkelijk te bereiken met een klein php scriptje b.v. met een regular expression erin.

Voor IE6/7 (als het nodig is dat deze compatible blijven) kan je dan eventueel een 2e file outputten die de images gewoon los laad. IE6/7 mensen zijn het toch wel gewend dat hun site traag laadt.

Allereerst scheelt het een hoop ontwikkeltijd, en daarnaast is het ook nog is sneller. Met sprites eindig je afhankelijk van het type site met miminaal 2 sprites, een horizontal en een vertical. Door dit in je CSS te houden bespaar je nog eens 2 roundtrips naar de server (per request, want cached images zijn nog steeds een roundtrip)!

5

Re: Sprites, automatisch of handwerk?

Compass is inderdaad een aardige oplossing. Mits de ontwikkel omgeving van het project dit ondersteund. (Soms heb ik die optie niet)
Overigens is het aanpassen met de hand niet zo heel lastig. Wel is het zo dat je hier afspraken over moet maken. Van links naar rechts, met of zonder tussenruimtes etc.

IE6/7 mensen zijn het toch wel gewend dat hun site traag laadt

Geen sterk argument. Zorgwekkend zelfs. Voor wie maak je de front-end? Voor jezelf of voor je gebruikers? Deze gebruikers hebben vaak geen ander optie dan te blijven werken met deze browsers. Laten we het dan niet nog vervelender voor ze maken.

Web designer
Work:Lunatech Research
Twitter: @dutchcelt
Blog: dutchcelt.nl

6

Re: Sprites, automatisch of handwerk?

Egor Kloos schreef:

IE6/7 mensen zijn het toch wel gewend dat hun site traag laadt

Geen sterk argument. Zorgwekkend zelfs. Voor wie maak je de front-end? Voor jezelf of voor je gebruikers? Deze gebruikers hebben vaak geen ander optie dan te blijven werken met deze browsers. Laten we het dan niet nog vervelender voor ze maken.

Hangt geheel van je doelgroep af. Ga jij vliegtickets verkopen waar jan en alleman je klant is, en je dus een grote omzet factor per bezoeker heb, ga inderdaad sprites gebruiken en focus je op IE6/7. Maak jij een website voor binnen mensen van de IT sector, verdoe je je tijd hier mee.

Een jaar geleden was ik het met je eens geweest, maar het gebruik IE6 en 7 is de afgelopen 2 jaar zo sterk gedaald dat het gewoon niet financieel te vertegenwoordigen is deze nog langer tot in detail te onderhouden. Een suboptimale ervaring voor deze gebruikers is dan ook zeker het overwegen waard, zeker aangezien ze met de browser features al waarschijnlijk een hoop ervaring missen.

Waar je je eerder op zou moeten focussen bij deze gebruikers is de trage javascript engine.

Overigens, IE7 zit nog maar op 4.39% volgens statcounter, afhankelijk van je doelgroep is er een grote kans dat je nagenoeg geen IE7 gebruikers heb.

7

Re: Sprites, automatisch of handwerk?

Nog vergeten trouwens, sprites zijn uberhaupt niet altijd een heilige graal, hangt weer tevens geheel van je gebruikt af. Waar je mee moet oppassen is dat als je sprites te groot worden, je geheugen gebruik van je browser kan ook flink omhoog gaan. Stel jij hebt een leuke sprite, met heel veel losse images er in, dan word er per image de hele sprite in het geheugen geladen.

Tevens is het geheugen gebruik van de image vele malen groter dan de download size van de image. Images die je download zijn compressed terwijl vaak intern in de browser de images uncompressed worden gestored.

8

Re: Sprites, automatisch of handwerk?

Ik durf te wedden dat niet iedereen het zo fijn heeft als op fronteers.nl :] http://fronteers.nl/_tmp/really-tempora … 01111.html

9

Re: Sprites, automatisch of handwerk?

Krijn Hoetmer schreef:

Ik durf te wedden dat niet iedereen het zo fijn heeft als op fronteers.nl :] http://fronteers.nl/_tmp/really-tempora … 01111.html

Hehe, dat is wel heel ideaal idd.

10 Laatst bewerkt door Bas van Dorst (09-11-2011 21:07:24)

Re: Sprites, automatisch of handwerk?

Roy Tomeij schreef:

[..]Compass bakt een sprite met een bestandsnaam met een wisselende fingerprint/digest. Als je sprite "foo" heet, dan maakt Compass er "foo-24bc6ef.png" van bijv (digest is gebaseerd op de inhoud van het bestanden en dus altijd uniek voor een nieuwe sprite).

Thanks! Van dat laatste voordeel was ik eigenlijk niet op de hoogte. Ik ga dit binnenkort eens testen.


Johan Schuyt schreef:

Waarom zou je deze dag nog sprites gebruiken? IE8+ en elke andere moderne browser ondersteunen base64 encoded images die je inline in je CSS kan stoppen.

Met base64 wordt je plaatje in totaal 5-30% groter dan een orgineel. Je kunt dit met gzip optimaliseren, maar het wordt er nooit beter op. Tevens als je alles in je CSS gooit moet je browsers eerst het gehele bestand downloaden voordat er ook maar "iets van CSS" te zien is. Met sprites of gewone images gaat dit parallel.


Johan Schuyt schreef:

Door dit in je CSS te houden bespaar je nog eens 2 roundtrips naar de server (per request, want cached images zijn nog steeds een roundtrip)!

Dat is afhankelijk van de concurrent connections in je browser. Als je 40 resources en 8 concurrent connections (Opera 10+) dan heb je maar 5 RTT. Die 2 sprite-images maken dus niet het verschil in RTT.


Johan Schuyt schreef:

Hangt geheel van je doelgroep af. Ga jij vliegtickets verkopen waar jan en alleman je klant is, en je dus een grote omzet factor per bezoeker heb, ga inderdaad sprites gebruiken en focus je op IE6/7. Maak jij een website voor binnen mensen van de IT sector, verdoe je je tijd hier mee.

Mwa, dat vind ik niet. Het zijn JUIST developers die willen dat de website goed werkt in alle browsers. Kijk naar Tweakers.net, die zijn toch ook gewoon compatible met diverse browsers?! Ik vind niet dat dit de reden is om IE7 niet meer te ondersteunen.


Johan Schuyt schreef:

Stel jij hebt een leuke sprite, met heel veel losse images er in, dan word er per image de hele sprite in het geheugen geladen.

Klopt, soms zijn sprites een hel voor het geheugen. Echter als je goed omgaat met sprites, merkt de gebruiker daar niets van en heeft het alleen een positief effect (pagina staat sneller op het scherm)

11

Re: Sprites, automatisch of handwerk?

Bas van Dorst schreef:
Roy Tomeij schreef:

[..]Compass bakt een sprite met een bestandsnaam met een wisselende fingerprint/digest. Als je sprite "foo" heet, dan maakt Compass er "foo-24bc6ef.png" van bijv (digest is gebaseerd op de inhoud van het bestanden en dus altijd uniek voor een nieuwe sprite).

Thanks! Van dat laatste voordeel was ik eigenlijk niet op de hoogte. Ik ga dit binnenkort eens testen.

Ik verwijs je graag naar mij adventsartikel: http://fronteers.nl/blog/2011/12/front- … -languages  smile

12 Laatst bewerkt door Mallory van Achterberg (15-12-2011 12:06:41)

Re: Sprites, automatisch of handwerk?

krijn schreef:

Ik durf te wedden dat niet iedereen het zo fijn heeft als op fronteers.nl :] http://fronteers.nl/_tmp/really-tempora … 01111.html

Firefox 16.2

O_o

Bas schreef:

Met base64 wordt je plaatje in totaal 5-30% groter dan een orgineel. Je kunt dit met gzip optimaliseren, maar het wordt er nooit beter op. Tevens als je alles in je CSS gooit moet je browsers eerst het gehele bestand downloaden voordat er ook maar "iets van CSS" te zien is. Met sprites of gewone images gaat dit parallel.

Ik had lunch met wat Perl mensen gisteren waar er praat was over base-64 plaatjes en Kindles en andere e-readers.
Omdat ze zo langzaam waren te downloaden en omdat de browsers niet wisten de dimensions totdat de plaatjes gedownload waren, hadden ze een Perl script geschreven die de dimensions uit van de base-64 gehaald en apart naar de browser gestuurd, voor sneller painting/rendering.  o_O

13

Re: Sprites, automatisch of handwerk?

Bas van Dorst schreef:

Met base64 wordt je plaatje in totaal 5-30% groter dan een orgineel. Je kunt dit met gzip optimaliseren, maar het wordt er nooit beter op. Tevens als je alles in je CSS gooit moet je browsers eerst het gehele bestand downloaden voordat er ook maar "iets van CSS" te zien is. Met sprites of gewone images gaat dit parallel.

Alleen is die 5 tot 30% extra vaak te verantwoorden op vooral tragere connecties: mijn telefoon haalt liever 1 bestand van 100KB binnen dan 20 van 5KB. De overhead van steeds nieuwe connecties maken is bijv. op mobiel verre van optimaal.