Wat is de meest efficiënte indeling van een sprite map?

[Wiethoofd]

Wat is qua filesize van de sprite map en de hoeveelheid (extra) CSS het meeste efficiënt om je spritemap in te delen? Natuurlijk uitgaand van minified CSS en gecrushte png's.

Er zijn meerdere opties om je spritemap in te delen, hieronder een paar voorbeelden

:hover onder de reguliere afbeelding Alles naast elkaar De wat inefficiënte gegroepeerde versie

Alles onder elkaar

:hover rechts van reguliere afbeelding

Helaas zijn er geen handige CSS-regels om bij een hover een achtergrondafbeelding alleen horizontaal of verticaal te verplaatsen, dus je zit altijd met een stijlregel per item en ook heeft elke :hover per item een regel.

Cascading Stylesheet:

/* Helaas bestaan deze (nog) niet */
:hover { background-position-x: -16px; }
:hover { background-position-y: -16px; }

edit:

Background-position-x en -y schijnen wel te werken in Internet Explorer 5+

edit:

In de CSS3 spec staan -x en -y wel gespecificeerd...

[ Voor 14% gewijzigd door Wiethoofd op 29-03-2011 15:23 ]

[himlims_]

denk dat 't afhankelijk is van de pagina waar de content getoond moet worden.
maar puur afgaande op neutrale situatie zou ik de voorkeur uitten over de :hoover rechts van ...

[CH4OS]

Het voordeel van zo'n spritemap moet ik nog zien, enige verschil die ik mij zo kan bedenken is minder HTTP requests, maar dat zou anno 2011 ook zo'n issue niet meer mogen zijn.

[MoietyMe]

Naast elkaar is naar mijn ervaring het kleinst in KB, hoe gek ook.

background-position-x/y werkt alleen niet in Firefox en Opera. Webkit en Trident ondersteunen dit wel.

[ Voor 44% gewijzigd door MoietyMe op 29-03-2011 15:30 ]

[Bosmonster]

CptChaos schreef op dinsdag 29 maart 2011 @ 15:25:
Het voordeel van zo'n spritemap moet ik nog zien, enige verschil die ik mij zo kan bedenken is minder HTTP requests, maar dat zou anno 2011 ook zo'n issue niet meer mogen zijn.

Bij een beetje druk bezochte site scheelt het je zo miljoenen requests voor kleine plaatjes.

Voor de bezoeker is vooral merkbaar dat de pagina sneller opbouwt.

Good Fella schreef op dinsdag 29 maart 2011 @ 15:29:
Naast elkaar is naar mijn ervaring het kleinst in KB, hoe gek ook.

De grootte van de PNG lijkt me nogal een non-issue in deze.

Ik zou hem gewoon opbouwen zodat het makkelijk leesbaar, uitbreidbaar en georganiseerd is.

[ Voor 27% gewijzigd door Bosmonster op 29-03-2011 15:38 ]

[André]

CptChaos schreef op dinsdag 29 maart 2011 @ 15:25:
Het voordeel van zo'n spritemap moet ik nog zien, enige verschil die ik mij zo kan bedenken is minder HTTP requests, maar dat zou anno 2011 ook zo'n issue niet meer mogen zijn.

Ik heb dit 'probleem' al bij veel sites aangepakt en ik kan je verzekeren dat de impact groter is dan je denkt. Het grootste probleem is dat een gemiddelde browser maar 6 items per hostnaam tegelijk kan downloaden. Als je dan 60 plaatjes hebt betekent dat ze in 10 batches ingeladen moeten worden. Daarnaast heb je 60 http connecties waarbij cookie info en andere meuk ook iedere keer opnieuw heen en weer gestuurd worden. Als je dat vervangt door 1 plaatje heb je 1 request en blijven er 5 lijnen over om andere zaken te downloaden. Kb's maken in dit verhaal weinig uit, bandbreedte is er vaak wel genoeg.

[Peter]

Wiethoofd schreef op dinsdag 29 maart 2011 @ 15:16:

edit:

In de CSS3 spec staan -x en -y wel gespecificeerd...

Nee, dat is absoluut niet de specificatie. In de specificatie wordt enkel van background-position gesproken.

De "background-position-[xy]" properties zijn meerdere keren voorgedragen, waaronder eens door ondergetekende, maar worden niet opgenomen omdat het gebruik van achtergronden als sprites -ondanks dat er niet echt een beter alternatief is- als hack gezien wordt. In essentie is het dat ook, want dat is niet waarvoor een achtergrond bedoeld is.

Wat je nog als mogelijke oplossing kunt bekijken, is het gebruik van data: URLs in combinatie met een stylesheet voor Internet Explorer 6 en 7 die naar losse plaatjes linkt. Nadeel is dat je CSS groter wordt, voordeel dat het geen enkel extra request nodig heeft.

[.oisyn]

CptChaos schreef op dinsdag 29 maart 2011 @ 15:25:
Het voordeel van zo'n spritemap moet ik nog zien, enige verschil die ik mij zo kan bedenken is minder HTTP requests, maar dat zou anno 2011 ook zo'n issue niet meer mogen zijn.

Jij bent duidelijk niet naar de t.net developer summit geweest

[Alfredo]

De indeling van je spritemap is niet tot weinig relevant voor de bestandsgrootte van de PNG zelf. De filtermethodes werken lijn per lijn, maar de eigenlijke compressie gebeurt over heel de afbeelding in zijn geheel. Bij je inefficiënt gegroepeerde sprite heb je natuurlijk meer (transparante) pixels, wat je uiteindelijk wel in de bestandsgrootte zal zien. Maar met een degelijke encoder mag het verschil niet dermate groot zijn.

Je kan wel optimaliseren bij het encoden van de afbeelding zelf. Zorg ervoor dat er geen extra metadata toegevoegd wordt, vermijdt truecolor en alpha (zeker niet met 16 bits per channel) maar opteer voor geïndexeerde afbeeldingen. Een goede encoder zal ook meerdere pre-filters uitproberen en heeft een degelijke implementatie van het Deflate-algoritme. Nadelig is dan wel dat het langer gaat duren om een afbeelding te encoden, zeker als het formaat groter wordt.

[10goto10]

André schreef op dinsdag 29 maart 2011 @ 15:40:
[...]

Ik heb dit 'probleem' al bij veel sites aangepakt en ik kan je verzekeren dat de impact groter is dan je denkt. Het grootste probleem is dat een gemiddelde browser maar 6 items per hostnaam tegelijk kan downloaden. Als je dan 60 plaatjes hebt betekent dat ze in 10 batches ingeladen moeten worden. Daarnaast heb je 60 http connecties waarbij cookie info en andere meuk ook iedere keer opnieuw heen en weer gestuurd worden. Als je dat vervangt door 1 plaatje heb je 1 request en blijven er 5 lijnen over om andere zaken te downloaden. Kb's maken in dit verhaal weinig uit, bandbreedte is er vaak wel genoeg.

Precies, bovendien zijn er cosmetische voordelen. Als je een icoontje hebt dat veranderd op 'n mouseover, dan wordt dit tweede plaatje pas ingeladen als je voor de eerste keer hovert. Als dit iets langer dan een kleine 100 miliseconden duurt zie je dit al, bijv. doordat er tijdelijk een transparante image placeholder van de browser wordt getoond, of gewoon even niks. Dit valt op en is lelijk. Bij een sprite is het plaatje al geladen en is je hover naadloos.

Maar om de vraag van OP te beantwoorden: ik denk dat de paar extra bytes van je indeling naar keuze in het niet vallen bij de verminderde HTTP-requests en het hierboven beschreven cache-effect. Gewoon zo min mogelijk loze ruimte overhouden, zou ik zeggen!

[ Voor 9% gewijzigd door 10goto10 op 29-03-2011 22:16 ]

[TheBorg]

Inderdaad, je kunt al je preloader ellende in de prullenbak gooien.

Ik doe het meestal gewoon onder elkaar, behalve de hovers, die doe ik naast het normale plaatje:
button1, button1:hover
button2, button2:hover
plaatje
dingetje
button36, button36:hover
etc.

[Wiethoofd]

TheBorg, volgens mij is dat juist weer inefficiënt, je kunt dan beter 2x een los plaatje zonder hover naast elkaar zetten, dan zit je niet meer met loze witruimte. Om dan overzichtelijk te blijven alle pics met hover bovenaan en onderin de losse afbeeldingen per 2 op een rij.
Ik heb nu:

Het blijft jammer dat zelfs background-position-x en -y niet volledig ondersteund worden door de grote browsers of zelfs als -moz of -o of -webkit property. (op webkit browsers dus na, maar dan moet je alsnog crossbrowser aan de slag met de normale background-position...)

[TheBorg]

De witruimte maakt me niet uit. Vaak is het hele ding bijv. 1000px breed omdat er ook een header of weet ik wat in zit. De sprite map wordt altijd kleiner dan de losse plaatjes bij elkaar, ook al gebruik je heel veel witruimte. Daarnaast is voor mij het primaire doel om het aantal requests terug te brengen.

Bij YouTube lijkt het wel of ze het plaatje automatisch genereren:


Ik doe het altijd met de hand maar op deze pagina staan wat tooltjes om te helpen bij het maken van sprites:
http://techgyo.com/index....st-css-sprite-generators/

[10goto10]

Ik zou zeggen: ga tot bijv. ongeveer 250 pixels breed, en begin dan op de volgende regel. Dan kun je makkelijk plaatjes blijven toevoegen, want of ze nou op "volgorde" staan of niet maakt niets uit. Je geeft toch gewoon in je CSS de X en Y aan voor ieder icoontje, het maakt voor je browser niet uit of de hover-versie 112 pixels verderop staat of er direct naast.

Maar at the end of the day: doe wat je het handigst lijkt

Edit: TheBorg hierboven heeft een mooi voorbeeldplaatje. Als je kijkt zie je dat alle "»"-achtige plaatjes zo'n beetje random geplaatst zijn. Zou wel klote zijn dat als je opeens een nieuwe staat erbij wil (bijv. "tijdelijk niet beschikbaar") en dan alle plaatjes moet opschuiven om plaats te maken, en daarna je CSS aan te passen... brrr

[ Voor 33% gewijzigd door 10goto10 op 29-03-2011 22:53 ]

[OkkE]

Ik vond dit ook een interessant artikel over o.a. dit onderwerp:
Styling Elements With Glyphs, Sprites and Pseudo-Elements.

[R4gnax]

Wiethoofd schreef op dinsdag 29 maart 2011 @ 15:16:
Wat is qua filesize van de sprite map en de hoeveelheid (extra) CSS het meeste efficiënt om je spritemap in te delen? Natuurlijk uitgaand van minified CSS en gecrushte png's.

[...]

Helaas zijn er geen handige CSS-regels om bij een hover een achtergrondafbeelding alleen horizontaal of verticaal te verplaatsen, dus je zit altijd met een stijlregel per item en ook heeft elke :hover per item een regel.

Zet alles zo dicht mogelijk op elkaar, maar voor mainenance wèl op een regelmatig rooster. Wat betreft plaatsing en CSS regels voor hover ben je niet gelimiteerd tot alleen background-position. Plaats je sprites absoluut gepositioneerd m.b.v. :before of :after en je kunt ook van clipping rectangles en offsets gebruik maken. Daarmee wordt het vrij makkelijk om met background position x/y positie (op een regelmatig rooster) te regelen en daarna m.b.v. clipping rectangles en margins een shift (van één rooster element) naar de regel daaronder of de kolom daarnaast voor elkaar te krijgen in één generieke hover/focus regel.

[DeepFreeze.NL]

Ik ben hier gister toevallig ook mee bezig geweest. Ik heb gebruik gemaakt van dit tooltje, ideaal!

[.oisyn]

DeepFreeze.NL schreef op woensdag 30 maart 2011 @ 09:39:
Ik ben hier gister toevallig ook mee bezig geweest. Ik heb gebruik gemaakt van dit tooltje, ideaal!

Cool tooltje. Maar meteen maar even een berichtje geplaatst over de gebruikte terminologie (een sprite is gewoon een enkel plaatje binnen een, wat ze dus eigenlijk bedoelen, sprite map)

[ Voor 3% gewijzigd door .oisyn op 30-03-2011 11:16 ]

[André]

Het tooltje is wel handig maar niet zaligmakend, je moet achteraf vaak nog een paar wijzigingen in de CSS en spritemap aanbrengen. Wel kan het veel tijd schelen.