CSS Sprites einfach erklärt

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.

Comments

  
  1. Jonas says:

    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.

  2. Jared says:

    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-bildern

    Nicht immer anwendbar aber mir hats schon öfter gute Dienste geleistet

    lg
    Jared

  3. gr4y says:

    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?

  4. @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. @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.

  6. Markus says:

    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 :-)

  7. @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

  8. Ralf says:

    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.
    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? ;) ). Bei jedem Hover müsste man trotzdem warten bis das komplette Sprite geladen wurde. Einspareffekt: Null.

    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.

  9. Markus says:

    @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 :-)

  10. Ralf says:

    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.

  11. datenkind says:

    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.

  12. Monika says:

    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

  13. Ralf says:

    @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.

  14. datenkind says:

    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 … ;)

  15. Ralf says:

    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.

  16. datenkind says:

    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.

  17. Ralf says:

    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.

  18. datenkind says:

    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.

  19. Jared says:

    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..

  20. Ralf says:

    Weil Blogs zum Diskutieren da sind. Es könnten auch Zwetschgen und Pflaumen sein. Das hat aber mit "Köpfe einschlagen" nichts zu tun.

  21. Jared says:

    Oh entschuldige meinen Einwand! lol Den rest denk ich mir

  22. Ich weiß mein Kommentar kommt reichlich spät, aber:

    @Ralf:
    Fakt ist, wenn Google es nutz (Sprite), dann ist es gut ;)
    (siehe Link)

  23. Ferro says:

    Perfekt, genau das hatte gesucht, hab zwar hier ein Buch rumliegen aber bis ich das gefunden habe war Google schneller... Vielen Dank

  24. micha says:

    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. realloc says:

    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.

  26. Pepe says:

    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!

  27. Mike Küster says:

    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 ;)

  28. Tom says:

    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!

  29. Nudge says:

    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?

  30. TLux says:

    Ich habe mal eine Frage bezüglich der Effektivität von Sprites anhand eines Anwendungsbeispieles.

    Warum ich überhaupt Sprites nutzen möchte:
    Bei einigen meiner Seiten flackert das hover-Bild (CSS) beim ersten "Rüberfahren" mit der Maus. Das finde ich nicht schön, weil es die "Programmierung" nicht rund wirken lässt.

    Anwendungsbeispiel:
    Ich habe jetzt eine Navigation die im normalen Linkzustand einfach nur eine Hintergrundfarbe hat. Wen ich also mit der Maus nicht auf dem Link bin, ist der Hintergrund z.B. rot. Diese Farbe vergebe ich mit "background: FARBE;"

    Die Hovergrafik soll nun z.B. ein Icon vor dem Navigationstext enthalten.

    Wenn ich jetzt also eine in der breite verdoppelte Grafik nehme, die eine Hälfte mit der Hintergrundfarbe des Links im "Normalzustand" einfärbe und die andere Seite mit Hintergrundfarbe und Icon versehe, ist das dann noch effektiv?

    Das Problem mit den flackernden Hover-Bilder sollte damit behoben werden, aber die Größe der Grafik wächst natürlich. Wie groß sollte das Sprites-Bild höchstens sein, damit es schnell läd?

    Danke!

    • @TLux: das kann man nicht sagen; diese Technik wendet man an, damit man Requests spart. Die eigentliche Grafik sollte noch immer so klein wie möglich sein. Die Browserversion ist fast egal; die Elemente werden mit CSS2 unterstützt und daher muss der Browser CSS2 verstehen.

  31. TLux says:

    (Bitte an meinen letzten Beitrag anhängen - wenn möglich)

    Ab welchen Browserversionen wird diese Sprites-Technik unterstützt?

  32. Julian says:

    Hallo,
    da eine meiner seiten lange Wartezeiten hat, da die ganzen Grafiken einzeln geladen werden mussten, war ich auf der suche nach einer Anleitung für sprites! Habe keine bessere gefunden wie diese hier. Tolle Arbeit und Danke
    lg

  33. Ra says:

    Guten Tag,
    da diese Diskussion schon etwas veraltet ist kommt mein Beitrag wohl etwas zu spät, jedoch möchte ich auf die Diskussion von oben noch einmal kurz eingehen:

    CSS Sprites sind durchaus sinnvoll, gerade wenn man sich, wie wir Webentwickler, auch mit Themen wie IE 6 beschäftigen muss. Ein alter IE kann nunmal nur 2 HTTP Requests gleichzeitig abfeuern. Ergo ist CSS Sprites extrem sinnvoll. Und auch in Navigationsleisten sind diese ebenfalls sinnvoll, sollte man einen Hover Effekt nutzen. Denn auch wenn man sagt, das man beileibe nicht jeden Link klickt bei dem Besuch einer Webpage, so werden doch trotzdem viele Hover Effekte geladen, während man mit der Maus sinnlos durch die Gegend eiert, ergo werden diese Bilder, falls man es so löst, ebenfalls geladen.
    Und dieses Speicher Argument ist nunmal leider an der oberen Grenze zur Lächerlichkeit.
    Ein .gif mit icons oder ein paar Background images ist keine 100kb groß. Sagen wir in der Sprite datei sind 100 icons und die datei ist 100 kb groß, so wäre durch meta daten, verschlüsselung etc. das Volumen wenn man nur 50 der icons so zieht bereits größer.
    Natürlich muss man differenzieren, wann dieses Verfahren Sinn macht. Aber für jeden Hover Effekt einen http request zu starten ist höchst fragwürdig.

    So long

  34. Steev says:

    Hallo Community,

    ich habe teilweise mit Kopfschütteln die Beiträge gelesen, ne ne!
    Wozu die ganze Aufregung - alles hat sein Pro und Kontra!

    Webdesigner, die sich Gedanken über die Gestaltung einer Webseite machen, werden jeder für sich ein Maß finden, dies so oder so einzusetzen... ich meine, wer eine Firmenseite gestaltet, kopiert sich nicht nur Source-Code irgendwo heraus und stückelt hier und da was zusammen!

    Die meisten behaupte ich mal, werden bei Kenntniss über einige Pro und Kontras ein Mittelmaß wählen und die Sprites ihrer Webseite in MEHRERE Grafiken aufteilen, werden wahrscheinlich auch einzelne Sprites nachladen, wo es eher Sinn macht.

    Ein Pro-Argument, das ich mal von einer Firmenseite gehört habe, ist:
    "Die Browser machen es einem heute sehr leicht, einzelne Bilder einer Webseite zu klauen und selber zu benutzen, selbst wenn 1x1 Pixel im Vordergrund stehen und der Sprite als Hintergrund basiert - Es macht Bilderklauern viel zu viel Arbeit, sich die gefunden Sprites aus einer Gesamtgrafik zu "schneiden", wenn sie solche auf anderen Seiten einfach fertig(!) klauen bzw. speichern können!"

    Das Argument finde ich gut !!!
    Und teilt man die Sprites noch klever in mehrere kleinere Grafiken (evtl. max. 100kb) auf, je nach Kategorie der Webseite oder Rubrik, dann finde ich das einen gelungenen Kompromiss!

    Ansonsten - alles wird GUT ... xD

    Viel Spaß beim CSS,
    beste Grüße
    Steev :-)

Trackbacks

  1. [...] Frank Bültge gibt es einen sehr guten Artikel über CSS-Sprites, und warum man sie verwenden sollte. Kurz [...]

  2. [...] Infos: CSS-Tricks: CSS Sprites: What They Are, Why They’re Cool, and How To Use Them bueltge.de CSS Sprites einfach erklärt A List Apart CSS Sprites: Image Slicing’s Kiss of Death (Plus kleine Geschichtsstunde zur [...]

© 2014, since 2005 bueltge.de [by:ltge.de] · Theme is built by ThemeShift