Abonniere die neusten Artikel via RSS-Feed oder Atom und verfolge die Kommentare ebenso via RSS-Feed oder Atom-Feed
Anzeige
Die Webkrauts haben das Thema „Hoverffekte mit CSS-Sprites“ schon vor langer Zeit aufgegriffen und erklärt, ausführlich. Dies soll hier nicht statt finden. Aber es ist immer noch eine relativ selten verwendete Technik und viele arbeiten dann mit Lösungen via JavaScript um die Bilder zum richtigen Zeitpunkt zu laden. Dies ist nicht nötig, mit Hilfe der Technik der CSS-Sprites kann man den unschönen Effekt, der auftritt bei MouseOver von Bildern als Link, beheben. Das ist wenig im Aufwand und bringt viel im Aussehen und Benutzerfreundlichkeit.
Um auf diese Technik nochmal und vereinfacht aufmerksam zu machen, habe ich mal ein sehr einfaches und, so denke ich, überschaubares Beispiel erstellt. Ansehen, verstehen und Nutzen war die Devise.
Die vielen kleinen Spielereien, die dann daraus resultieren sind auf vielen Beiträgen im Netz nachzulesen.
Die Nutzung von CSS-Sprites hat Vorteile:
In wenigen Punkten und Erklärungen ist die Lösung zu sehen. Wie das ganze dann in Benutzung aussieht, dass sieht man oben am Start des Artikels oder im Beispiel in der Experimente-Box.
Das Bild kann natürlich mehrfach verwendet werden. Eventuell benötigt man das Logo auch in anderen Darstellungen auf der Seite, ohne hover-Effekt. Damit lohnen sich solche Lösungen richtig. Man nutzt dann eben nur den Bereich, der zu sehen sein soll.
125px breit und 60px hoch; 5px Abstand sind zwischen den einzelnen Bildern des Ganzen
Im Grund greift das CSS nur auf das ID zu und erzeugt den Effekt durch die Pseudeklasse hover.
Die Höhe und Breite ergibt sich aus der Größe des eigentlichen Einzelbildes, in diesem Beispiel 60px.
#image-link {
width: 60px;
height: 60px;
text-decoration: none;
display: block;
background: url('images/fb-sprite.png') 0 0;
}
#image-link:hover, #image-link:active {
background-position: 60px 0;
}
Die Angabe 0 0 muss bei background nicht vergeben werden; nur wenn es eine Verschiebung geben soll. Genauso könnte man das Beispiel hier auch anders herum nutzen. Dafür müsste man lediglich die Positionswerte für die ID image-link tauschen.
#image-link {
width: 60px;
height: 60px;
text-decoration: none;
display: block;
background: url('images/fb-sprite.png') 60px 0;
}
#image-link:hover, #image-link:active {
background-position: 0 0;
}
In diesem Bespiel dient ein einfacher Link als Demonstration, natürlich kann man hier alle bekannten Möglichkeiten aufgreifen und beispielsweise schöne Navigation erstellen.
<a href="#" id="image-link"> </a>
Kommentarregeln: Bleib cool, kritisch ist in Ordnung, aber wenn du unhöflich bist, dann lösche ich deinen Kommentar. Bitte benutze deinen persönlichen Namen oder Initialen und nicht den Namen eines Unternehmens, dies würde als Spam gewertet und wird gelöscht. Der Zusammenhang zwischen Namen und URL sollte nicht offensichtlich auf Spam hindeuten! ♥ Ansonsten, vielen Dank für den Kommentar und viel Spaß mit meinem Blog.
händischer Spam:
Beachte die Kommentarregeln, jede Form von versuchtem Spam wird gelöscht. Warum und wieso steht in einem meiner Beiträge.
Bezug auf Textstellen:
Du kannst direkt bezug auf Textstellen im Beitrag nehmen. Dazu muss lediglich der Bereich im Artikel markiert werden; daraufhin erscheint ein Button, der den markierten Text in das Kommentarfeld übernimmt und als Zitat auszeichnet. Die Funktion ist nur bei aktivem JavaScript nutzbar.
xHTML:
Du kannst folgende Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <code> <pre> <em> <strong> <strike> <ul> <ul> <li>
Achte darauf, wenn du Code im Kommentar hinterlegen willst, dann muss der Code maskiert sein. Dann wird er nicht interpretiert. Der Code muss mit Hilfe von HTML-Entities dargestellt werden, d.h. dass man z.B. < als < und > als > einfügt.
E-Mail-Benachrichtigung bei neuen Kommentaren ?
Wenn der Haken in der Checkbox gesetzt ist, dann wirst du über neue Kommentare vie E-Mail informiert. Der Versand erfolgt nur, wenn du die URL in der Bestätigungs-E-Mail genutzt hast oder schon Abonnent hier im Blog bist.
Kommentar erscheint nicht:
Alle Kommentare werden manuell geprüft, freigegeben und nach Möglichkeit beantwortet. Bitte um etwas Geduld und Nachsicht.
Identifikationsbilder (Avatare):
Auf Gravatar.com kann man sich mit seiner E-Mail-Adresse registrieren und ein Bild hochladen, dann erscheint dieses Gravatar hier und in vielen weiteren Blogs.
Spamschutz:
Das Kommentarformular ist mit einem Spamschutz ausgerüstet. Solltest du diesen Artikel ohne JavaScript besuchen und kommentieren wollen, so muss du die Frage beantworten und das jeweilige Wort in das Textfeld eingeben.
bueltge.de [by:ltge.de] wird von Frank Bültge geführt, administriert und gestaltet. Alle Inhalte sind persönlich von mir ausgewählt und erstellt, nach bestem Gewissen und Können, was die Möglichkeit von Fehlern nicht ausschließt.
Das Weblog wird angetrieben von WordPress und aktuell gibt es 892 Beiträge, 16496 Kommentare in 14 Kategorien und 450 Tags.
Das Blog wird liebevoll mit xHTML & CSS in Handarbeit gestaltet.
Design und Code ist unter Copyright
© 2001 - 2010 bueltge.de [by:ltge.de]
5. Juni 2008 um 12:11
Der große Vorteil liegt meiner Meinung nach darin, dass der :hover-Zustand bereits mitgeladen wird, da ja direkt die komplette Grafik beim Seitenaufbau geladen wird. So lassen sich auch komplette Navigationen inkl. aller Schaltflächen (link, hover, active, evtl visited) in einer Grafik realisieren. Je nach Link wird dann nur die entsprechende Position in der Grafik angegeben.
Beim hinzufügen von Navigationspunkten oder einer grafischen Überarbeitung spart man hierbei vor allem massiv Zeit, wenn nur eine Grafik ausgetauscht werden muss.
5. Juni 2008 um 12:17
Nur als klitzekleine Ergänzung
:
Bertdesign hat da eine schöne Alternative aufgezeigt mit der man nicht für jedes Bild eine css klasse/id erstellen muss!
http://www.bertdesign.de/webdesign/designen/tutorial-css-hover-mit-verlinkten-bildernNicht immer anwendbar aber mir hats schon öfter gute Dienste geleistet
lg
Jared
5. Juni 2008 um 12:34
Naja ich finde das man solche Hover-Effekte mit Javascript einfacher bekommt. Ich habe eine Javascript-Funktion die mit der ID des Bildes arbeitet und dann die entsprechende Hover-Grafik nimmt. Bei CSS wäre das viel mehr Code.
Und mal ehrlich, wenn auf jeder Webseite Javascript verwendet wird, warum sollte ich das dann nicht auch nutzen?
5. Juni 2008 um 12:39
@Jonas: sehe ich auch so und habe es daher nochmal in extrem einfacher Form dargestellt.
@gr4y: Weil man es oft deaktiviert - Theme Sicherheitsrisiko, zumindest im Unternehmensumfeld.
5. Juni 2008 um 12:44
@Jared: Das Prinzip ist das gleiche. Das Bild kannst du zig mal verwenden. Man könnte auch im Bild viele Details nutzen und nur den bereich nutzen, den man benötigt. So lädt man für mehrere Anwendungen nur ein Bild. Im hiesigen Bsp. sind es nur zwei Bilder, die man aber schon 4 mal nutzt.
5. Juni 2008 um 16:48
Wie schön, dass mein Beispiel hier aufgegriffen wird
Ach ja: Der IE unterstützt :hover ja nur unzureichend (siehe hier) - daher müsste man ja in jedem Fall einen Link nutzen, um auch dort den Effekt zu erhalten (oder?).
Der Unterschied zu meiner Idee ist ja die Nutzung des Hintergrundbildes, während ich normal eingebundene Bilder verwende - was bei dynamisch eingebundenen Bildern sicherlich einiges an Arbeit spart
5. Juni 2008 um 17:23
@Markus: IE-Problem ist leider nicht weg zu diskutieren. Auf die vielen kleinen Details gehe ich fast nie ein, weil ich den IE vernachlässige (damit soll keine Diskussion entfacht werden, ich weiß, dass Können Agenturen und Firmen etc. nicht) - aber ich, denn das hier ist privat.
Den Unterschied habe ich erkannt, musste es nur mal in Ruhe lesen. Worauf ich hinaus will, ist die mehrmalige Verwendung von Bildern. Bei geschickter Überlegung kann man so eine Menge an Last sparen.
LG Frank
5. Juni 2008 um 17:50
Warum sparen CSS-Sprites Bandbreite? Ich sehe schon die vielen kunterbunten Navigationen, bei denen 50% der Bilder nie das Licht des Internets erblicken weil niemand drauf klickt.
). Bei jedem Hover müsste man trotzdem warten bis das komplette Sprite geladen wurde. Einspareffekt: Null.
Deiner Theorie folgend, wäre es das beste alle Hintergrundbilder in einem Sprite zu vereinigen und dann immer nur das Sprite zu verschieben. Ergebnis wäre dann wahrscheinlich ein riesiges Bild (1MB? 2MB?
Ich bleibe lieber dabei und verpasse im CSS jedem Zustand seine eigene Grafik. Wirklich Interessant finde ich den von Jared verlinkten Lösungsansatz. Bei Links und anderen nebensächlichen Effekten finde ich CSS-Sprites hingegen einfach übertrieben.
5. Juni 2008 um 20:08
@Ralf: Warum man besser CSS-Sprites statt einzelner Bilder benutzen sollte erklärt Chris Coyier sehr anschaulich in einem ausführlichen Artikel. Man verringert durch Sprites die Anzahl der http-Requests, dadurch kann die Seite schneller geladen werden.
Abgesehen davon: Wenn für eine Navigation Hintergrundbilder genutzt werden, dann würde ich mir die Mühe machen, eine Liste mit entsprechenden Einträgen per CSS in die einzelnen Hintergrund-Bilder einzupassen. Dann ließe sich ein einziges CSS-Sprite für alle Navigationselemente nutzen, was letztendlich eine massive Ersparnis an http-Requests sowie zu ladendem Content ist. Vom zu schreibenden Code mal ganz abgesehen…
Ach ja: Schön, dass dir mein Beispiel gefällt
6. Juni 2008 um 13:31
6. Juni 2008 um 16:46
Ich will die Technik an sich nicht verteufeln. Man kann sie, wie gezeigt, sehr sinnvoll einsetzen. Hier wird aber evt. das falschen Beispiel (Navigation) verwendet. Um es mal überspitzt auszudrücken: Jeder wird mit diesem Beispiel anfangen und es ausbauen. Am Ende wird nur noch eine einzige Grafik geladen um möglichst viele HTTP-Requests einzusparen und alle Grafiken/Hintergründe werden über ein einziges CSS-Sprite realisiert.
Dummerweise werden i.d.R. alle Seitenelemente im Browsercache abgelegt. Und dann schlummert dort eine riesige Grafik von der u.U. zwei oder drei kleine Bereiche verwendet werden. Und genau hier liegt wohl auch der Denkfehler. Denn es wird ja nicht bei jedem Mouse-Hover ein HTTP-Request abgesetzt, sondern die Grafik wird aus dem Cache geholt. Somit habe ich vielleicht 10 HTTP-Request gespart. Dafür aber jede Menge an unnötigen Daten übermittelt.
Am Ende zahlt dann der Seitenbetreiber ggf. sogar noch drauf. Denn er versendet unnötig Daten und erhöht somit den Traffic. Zudem müllt er unnötig die Festplatten der Besucher voll. Bei den heutigen Festplatten wahrscheinlich kein merklich großer Effekt. Aber schauen wir uns mal den Asus EEE-PC an. Der muss alles in 4GB Flashspeicher ablegen. Ist der Speicher voll, holt er sich die Grafik jedesmal neu. Hätte man nun alle Grafiken in ein einziges CSS-Sprite gepackt, würden Besucher mit einem EEE-PC schnell ins Hintertreffen geraten. EEE-PC-Benutzer surfen gerne von Unterwegs, dazu sind die winzlinge ja wie gemacht. Denkt man dann mal an die volumenbezogenen Tarife fürs mobile Surfen, würde ich als Besucher schnell mal stinkig werden wenn mir plötzlich jede Webseite ihr komplettes Grafikreportoir um die Ohren haut.
7. Juni 2008 um 14:09
Ich weiß nicht in was für Relationen du denkst. Wo ist bei einer Menügrafik von rund 72 kB das Problem (siehe Apple)? Auf die kommst du genauso, also würdest du jede Grafik einzeln nutzen – und die werden auch in deinen Cache geladen, vor allem, wenn du darauf wert legst, dass der :hover-Status ohne Flackern stattfinden soll, dann lädst du mindestens die Hälfte aller Grafiken in deiner Situation vor.
So, und nun vergleichen wir das mit einem einzigen Request bei einer Grafik. Hmm, lässt sich meiner Meinung nach nicht mehr viel zu sagen. Ergo hat man mit einem Sprite mehr gespart als mit dutzenden Einzelgrafiken.
Wie gesagt, deine Relationen passen nicht. Du redest von 1–2 MB pro Grafik, was völliger Quatsch ist.
8. Juni 2008 um 10:50
Ralf ich bin da uneingeschränkt deiner Meinung. Unabhängig davon, grade bei einer Navi habe ich dann *Schriftvergrößerung* ausgeschaltet, oder die Bildchen sehen sehr "kreativ" aus.
Auch private Seiten werden von IE usern betrachtet.
Wenn ich schau wann ich den meisten Traffic habe, arbeiten 90% der Leute nur mehr nächtens, --- 
lg
8. Juni 2008 um 18:00
@datenkind: Les noch mal genau nach. Ich habe nicht geschrieben 1-2MB PRO Bild, sondern pro CSS-Sprite. Und ich weiß auch ganz genau das es genug Wahnsinnige gibt die eben genau das machen: Alle Grafiken in EIN CSS-Sprite packen und dann munter CSS-Rumgeschubse spielen.
Bei JQuery ist es das gleiche. Selbst wenn nur ein oder zwei Effekte verwendet werden, wird gleich mal auf ein super fettes Framework zurück gegriffen. Warum? Nicht weil die Arbeit bei den 20 Zeilen JS leichter wäre, sondern weil es irgendwie modern ist Frameworks einzusetzen. Das gleiche kannst du bei den derzeit ach so beliebten CSS-Frameworks beobachten. Einfach mal einsetzen und tonnenweise unnötige Daten verschicken. DSL sei dank merkt der Hobbywebmaster ja nix davon.
Mit den CSS-Sprites ist es das gleiche. Sie werden wahllos eingesetzt weil sie ja so modern sind. Und sie sparen ja auch noch ein oder zwei HTTP-Requests. Leute die mit der Einsparung der HTTP-Requests argumentieren, haben i.d.R. keine Ahnung davon. Sie haben es irgendwo mal gelesen. Mehr nicht.
Wenn ein paar zusätzliche HTTP-Requests, vor allem bei ständig abgerufenen Elementen wie der Navigation, Probleme bereiten, dann hat dein Webserver ein gravierendes Problem. Nicht der Webdesigner.
Da sind wir dann an einem Punkt wo der Teufel mit dem Belzebub ausgetrieben wird. Der Server lahmt? Ach dann hauen wir mal den Webdesigner was auf die Finger. Soll der doch zusehen das die Webseite schneller lädt. Das der Server irgendwie völlig beschissen konfiguriert ist, oder gar auf der völlig falschen Hardware läuft (512MB RAM reichen doch aus oder? Hab ich auch im PC, der läuft astrein...). Warum soll also der Webdesigner mit Haken, Ösen und Tricks die Arbeit des Hosters machen? Sorry, das ist für mich absoluter Blödsinn.
Und wie ich schon gesagt hatte, die immer häufiger anzutreffenden mobilen Geräte (EEE-PC, Handy, usw) bleiben bei der Diskussion wieder völlig außen vor. Niemand macht sich Gedanken über Datenvolumen und schmalspurige Bandbreiten.
Wenn du wirklich HTTP-Requests einsparen willst, dann mach deine Seiten doch in Flash. Ein Request und alle Daten sind da. Da flackert nix, da flimmert nix dafür macht es hübsch Dingdong-Plingplong wenn du es willst.
8. Juni 2008 um 23:36
Bei „pro Grafik“ habe ich mich in der Tat falsch ausgedrückt – ich meinte eben „pro Sprite“. Ich glaube nicht, dass ein halbwegs firmer Mensch sich hier austobt, als gäb’s kein morgen. Allein aus der Komplexität des Stylesheets, die hieraus resultiert, wird sich sowas nicht einstellen. Menschen sind faul.
Zum Thema Requests kann ich nur noch sagen, dass es ein Webentwickler schlicht beachten muss, wie effetkiv die Kommunikation zwischen Server und Client läuft, ob der Server nun eine Rechensau ist oder nicht. Ein paar Requests bei mehreren tausend Besuchern im Monat heißt schlicht und ergreifend Kostensparen. Ich kann nicht einfach nach einem größeren Server schreien, wenn ich die Ursache nicht angehe. Siehe dein Teufel/Belzebub-Thema.
Ansonsten: Bleib einfach mal sachlich, wir sind alle erwachsen. Mkay?
Und was zum Henker ist Flash …
9. Juni 2008 um 14:10
9. Juni 2008 um 17:16
Was ist denn besser? Die doppelte Menge an Daten übertragen oder ein Request mehr? Diejenigen die mit volumenbasierten Tarifen ins Netz gehen werden bestimmt nicht jubeln wenn sie auf ihre Kosten anderer Leut's Server schonen. Und ich bezweifel mal das der Server schneller wird nur weil er plötzlich mehr Daten pro Besucher ausliefern muss.
Das ein Webdesigner schlau arbeiten sollte steht außer Frage. Aber wie wäre es denn damit auf Kinkerlitzchen und unnötige Effekthascherei zu verzichten? Vielleicht ist weniger der erste Schritt zum Mehr.
Sollte der Server dann immer noch leiden weil er zwei anstatt einem Request verarbeiten muss, sollte man sich ggf. mal die Einstellungen des Servers genauer anschauen. Eine andere Möglichkeit wäre auch sich mal Gedanken um eine andere Software zu machen. Auf alle Fälle würde ich als erstes den Server, Technik und Software optimieren als mit so schwachen Argumenten wie "ein paar Request einsparen" irgend einem Trend hinter her zu hecheln.
9. Juni 2008 um 20:01
Sorry, aber willst du’s nicht verstehen? Es ist schnurz-egal, ob deine Navi aus vielen Einzelbildern (unterschiedliche Status) oder eben aus einem besteht. Die Datenmenge ist nahezu gleich, wenn nicht sogar mehr als bei einem einzelnen Sprite.
Und warum soll man auf halbwegs ansehnliche Darstellung im Jahre 2008 verzichten? Minimalistisch ist eines, das kann teilweise extrem genial sein. Aber Kundenwebsites lechzen nach „Überzeug mich, ich will dein Kunde werden“, da kommst du an modernen Techniken nicht vorbei.
Du hast natürlich recht, dass man sich an der eigentlichen Website totoptimieren kann, wenn der Server grützig konfiguriert ist. Aber es gibt eben Probleme und es gibt Ursachen.
Lies dir einfach mal Exceptional Perfomance von Yahoo durch und denk nochmal über das Thema nach.
9. Juni 2008 um 21:38
Es ist nun einmal nicht egal ob sie aus Einzelbildern oder aus Sprites besteht. Ein Bild wird nur dann geladen, wenn es angezeigt wird. Ein Sprite wird selbst dann komplett geladen, wenn selbst nur 1% davon angezeigt / benutzt wird.
Schreit eine Webseite mich an, knallt sie mich mit Informationen, Effekten und Pipapo voll, kaufe ich definitiv nichts. Genau solche Grundeinstellungen, Webseiten MÜSSEN knallbunt sein um erfolgreich zu sein, zeigen das der Kunde und seine Wünsche von Vorne bis Hinten ignoriert wird. Welcher Kunde kommt denn an und sagt das er nichts gekauft hat weil die Webseite zu langweilig war?
Gerade hier ist weniger viel Mehr. Dem Kunden die Informationen geben die er braucht, ihn nicht mit Klickibunti nerven und schon gar nicht mit zwanzig tollen Kirmeseffekten vom Kauf abhalten weil sein IE5 die nicht anzeigen kann und stattdessen lieber abschmiert.
da merkt man das Webdesigner nach Aufwand bezahlt werden. Noch ein Bildchen mehr, nochmal 50 Euro verdient. Und damit der lahme Server nicht schlapp macht, denkt man sich krude Techniken aus um das ganze Gedrösel doch noch an den Mann zu bringen.
Vielleicht solltest du dir mal vor Augen halten das nicht alle Netzbenutzer so netzaffin sind das sie täglich mit neuem Quatsch überrascht werden müssen. CSS-Sprites finden mit Sicherheit ihren Platz (siehe Beispiel von Jared). Aber bevor man sich Gedanken über neue Gimmicks macht, sollte man sich mal lieber überlegen ob das was man da so produziert, auch wirklich das ist was brauchbar (benutzbar) ist.
9. Juni 2008 um 22:34
Baoh, was geht denn? Ich weiß echt nicht, was dein Problem ist bzw. was du einfach nicht am Thema CSS-Sprites kapieren willst. Dass diese Technik kein Mensch dazu nutzt, um alle Bildelemente seines 5000-Seiten-Bilderkochbuchs nutzt, sollte doch auch nur im geringsten klar sein, oder? Dass man diese Technik für Elemente nutzt, die sowieso (!) generell dargestellt werden, klingt doch, hoffe ich, auch für dich logisch, oder?!
Und nur, weil ich sage, dass man im Jahre 2008 durchaus moderne Techniken zur Websitegestaltung nutzen kann (und sollte), habe ich _nirgends_ behauptet, dass das in knallbuntem Augenkrebsrisiko enden soll. Les endlich mal die Kommentare und diskutiere auf dieser Basis, nicht auf deiner steifen 1998-Entwicklungsebene.
Und, 2004 (!) hat A List Apart das erste Mal großartig über CSS Sprites geschrieben, und das sind vier Jahre. Und vier Jahre haben nichts, aber auch gar nichts mit „neuen Gimmicks“ zu tun!
Und nochmal extra zwei Links für dich. Bin ja nicht so …
eins
zwei
Habe fertig.
10. Juni 2008 um 15:47
Das sind nur CSS-Sprites.
Warum man sich deswegen so dermaßen die Köpfe einschlagen muss ist mir unbegreiflich. Es macht im Web doch eh jeder was er will..
10. Juni 2008 um 21:01
Weil Blogs zum Diskutieren da sind. Es könnten auch Zwetschgen und Pflaumen sein. Das hat aber mit "Köpfe einschlagen" nichts zu tun.
11. Juni 2008 um 11:43
Oh entschuldige meinen Einwand! lol Den rest denk ich mir
28. August 2008 um 18:46
3. Januar 2009 um 08:42
11. Januar 2010 um 16:35
Ich weiß mein Kommentar kommt reichlich spät, aber:
@Ralf:
Fakt ist, wenn Google es nutz (Sprite), dann ist es gut
(siehe Link)
13. Januar 2010 um 21:46
Perfekt, genau das hatte gesucht, hab zwar hier ein Buch rumliegen aber bis ich das gefunden habe war Google schneller... Vielen Dank
8. Februar 2010 um 10:56
Zum Thema der Disskussion von "datenkind" und "Ralf": Das witzige ist, dass ihr beide Recht habt
CSS-Sprites sind eine tolle Sache um den Seitenaufbau zu beschleunigen, vorausgesetzt sie werden sinnvoll eingesetzt. Das trifft btw. auf so ziemlich alles beim Thema Webdesign zu. Eine XHTML-Seite ist nicht perse "besser" als eine HTML4-Seite.
Ergo: Der Effekt der durch CSS-Sprites gesparten Requests muss selbstverständlich einen evtl. überflüssigem Traffic positiv entgegen stehen. Wenn man eine große Navi mit nicht optimierten Bildern (pro Grafik > 50 kb) mit CSS-Spites umsetzt, ist man selber Schuld und es tritt genau das ein was Ralf sagt: es werden unnötige Daten übertragen. Nutzt man CSS hingegen bei einer kleinen Navi mit Bilder, die jeweils 10kb oder kleiner sind sodass das ganze Sprite unter 100 kb bleibt, so kann eine Umsetzung mittels CSS-Sprites durchaus sehr sinnvoll sein. Gerade aber wenn man Sptites nicht nur für die Navi sondern auch für andere Designelemente der Seite nutzt (weil man z.B. runde Ecken auch im IE haben möchte) fährt man mit CSS-Spites besser, da diese Grafiken in jedem Fall geladen werden.
Trotzdem sind CSS-Spites etwas für Fortgeschrittene. Wer keine Ahnung hat Bilder für's Web zu optimieren oder sinnvolles HTML zu schreiben, der braucht sich damit gar nicht erst zu beschäftigen. Vielleicht kommt ihr beide ja auf diesem Nenner zusammen.
micha
25. Februar 2010 um 18:46
Inzwischen gibt es auch tatsächlich Anwendungsfälle, die den Einsatz von Sprites nicht nur rechtfertigen, sondern (aus Performance-Gründen) sogar notwendig machen. Die Icons diverser Social Networks, die man heutzutage auf vielen Blogs findet, lassen sich platzsparend in einem Sprite unterbringen und wesentlich schneller ausliefern.
2. März 2010 um 10:33
Hallo Leute, sorry das ich bei der Diskussion nicht gleich mitmache, aber ich hätte noch eine Frage:
(unter der Voraussetzung das die Menüs dynamisch sind!)
Bis an hin konnte man für eine Button-Leiste ein Hintergrund-Fetzten von 2 Pixeln nehmen der mit 2 oder 3 Zuständen definieren und dann repetieren.
Die Frage: Kann ich das mit einem Sprite auch machen und den 2 Pixel Fetzen in den drei Zuständen definieren und als hover Hintergrund stellen?
Währe cool wenn da jemand ein Beispiel Posten könnte. Danke!
2. März 2010 um 11:24
@Pepe: ja, geht genauso - dazu gibt es auch Tutorials im Netz
10. März 2010 um 02:10
Danke für die Tipps und Links. Ich habe hier eine Navigation im Backend eines Shop-Systems, die über 50 einzelne, kleine Grafiken verwendet. Also 50 HTTP Request statt einem einzigen. Dabei wird das Menü (inkl. Grafiken) komplett geladen und per JavaScript beim überfahren mit der Maus eingeblendet.
An dem Teil werde ich die CSS - Sprites einmal austesten
18. Juli 2010 um 01:22
Abschließend, da das Für und Wieder bereits mehr als erörtert wurde und das teilweise sogar fachlich, möchte ich meinen Beitrag dazu kürzer fassen und den Zweiflern an dieser Technik zu bedenken geben, das sich bereits ganze Horden von Joomla-Entwicklern und deren Templatedesigner dieser Technik verschrieben haben.
Das tun die sicherlich nicht deshalb, weil sie eingefleischte Javahasser sind, sondern weil in der Entwicklung von modernen Webanwendungen und Internetpräsenzen die Usability (und somit auch Ladezeiten und Fehleranfälligkeit) im Vordergrund stehen.
Wie auch immer, ich habe diese Technik auf etlichen URLs angewendet und finde sie einfach zu warten und leicht einzubinden.
CSS ist heute nunmal einfach klasse!
4. August 2010 um 11:32
Interessante Technik...
Ich frage mich gerade, ob ein Browser auch immer Bilder am Rand abschneiden muss...
Könnten evtl. andere Reader das Bild komplett und damit überlappend darstellen?