Für Menschen · Seien Sie begeistert und Sie werden begeistern !
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>
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 980 Beiträge, 18728 Kommentare in 14 Kategorien und 464 Tags.
Das Blog wird liebevoll mit xHTML & CSS in Handarbeit gestaltet. Erstellt mit ♥ zum Befüllen und Erhalten.
Design und Code ist unter Copyright
© 2001 - 2012 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?
15. Oktober 2010 um 16:48
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!
15. Oktober 2010 um 16:51
(Bitte an meinen letzten Beitrag anhängen - wenn möglich)
Ab welchen Browserversionen wird diese Sprites-Technik unterstützt?
15. Oktober 2010 um 17:14
@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.
25. Januar 2011 um 10:30
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
15. April 2011 um 17:15
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
18. November 2011 um 14:34
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