Blog

Fürs Web soll man bekanntermaßen das Bildmaterial so klein wie möglich halten, damit die Datenübertragungsmenge gering und somit der Seitenaufbau schnell ist.

Fotos müssen also komprimiert werden. Im Regelfall eignet sich das Dateiformat JPG für Web-Fotos, weil es auch bei Bildern mit vielen feinen Farbabstufungen ohne zu stark sichtbaren Qualitätsverlust ganz gut in der Dateigröße reduziert werden kann. Eine gute Qualität auch bei sehr starker Kompression verspricht Caesium. Selbst bei 90-prozentiger Kompression soll es kaum Verluste erzeugen.

Nun, das kann ich nicht bestätigen. Ich habe drei eigene Fotos in der Auflösung 3072 x 2304 mit Caesium komprimiert, zunächst mit 90-prozentiger Qualität. Die Dateigröße schrumpfte dabei in zwei Fällen um etwa die Hälfte, in einem Fall um etwa zwanzig Prozent. Das hört sich viel an, ist aber eigentlich nichts Besonderes. Als ich dieselben Bilder mit IrfanView auf eine Qualität von 90 Prozent brachte (ohne weitere Kompressionsmaßnahmen), kam ich auf ungefähr dieselben Dateigrößen, sogar etwas kleiner. Ein Unterschied zu den Ergebnissen von Caesium war mit dem Auge nicht erkennbar.

Und als ich in IrfanView noch das RIOT-Plugin mit seinem Chroma Subsampling anwendete, wurden die Dateien noch ein bisschen kleiner.

Doch Caesium verspricht ja, dass man seine Bilder bis zu 90 Prozent ohne Qualitätsverlust komprimieren kann – anders gesagt, die JPG-Qualitätseinstellung von 10 Prozent soll nicht erkennbar sein. Ich habe es ausprobiert. Und natürlich bilden sich hier Artefakte: feine Farbabstufungen werden zu hässlichen großen Flächen mit nur wenigen Abstufungen. Man nennt das auch Klötzchenbildung.

Dazu kommt, dass Caesium meinen Rechner (zugegeben: alter Pentium-IV mit nur einem Prozessorkern) ziemlich belastet hat. Natürlich verkleinert man Fotos im Normalfall erst einmal, bevor man sie fürs Web weiter verarbeitet. Aber ich wollte ja testen.

Fazit: Mit IrfanView und RIOT-Plugin erzielte ich qualitativ gleiche und dabei noch kleinere Bilder als mit Caesium.

Caesium ist kostenlos, aber es wird um eine Spende gebeten. IrfanView ist nur für private Nutzung kostenlos. Auch hier wird um eine Spende gebeten. Die kommerzielle Lizenz mit lebenslangen Updates kostet lediglich 10,– Euro.

In einem Online-Artikel in Internet World Business vom 20.07.2011 werden sieben Dinge aufgezählt, die man beim Webdesign unbedingt vermeiden sollte.

Nun gut, es sind sieben alte Hüte. Dennoch finde ich den Artikel sinnvoll, denn solche Webdesign-Sünden haben sich wohl auch in 2011 noch nicht herumgesprochen. Natürlich kann man einen Mangel an Wissen in diesem Bereich keinem privaten Homepage-Bastler vorwerfen. Doch ich bin vor ein paar Monaten auf einige im Jahr 2011 erstellte Websites eines Mitbewerbers gestoßen, die – kein Scherz! – noch mit Frames gefrickelt worden sind.

Und sicherlich stößt man gelegentlich noch auf andere als die im Artikel genannten Webdesign-Fehltritte. Aber genug davon. Konzentrieren wir uns lieber wieder aufs Gute, Wahre und Schöne!

CSS Lint ist ein kostenloser Online-Dienst, mit dem man seinen CSS-Quellcode prüfen lassen kann. Man kopiert einfach den Text seiner CSS-Datei in das Eingabefeld hinein, lässt das Programm ein kurzes Weilchen arbeiten und schon erhält man eine Auflistung der eventuellen Fehler und Warnungen.

Verbesserungsvorschläge werden gleich mitgeliefert, sodass man seine CSS-Angaben korrigieren kann. Bei meinen Tests ließ sich der Code etwas entschlacken, außerdem wurde ein doppeltes Semikolon bemängelt, das ich übersehen hatte (obwohl mein Editor Webocton Scriptly solche Fehler rot markiert). Zu viele solcher Hinweise sind natürlich für den Webdesigner nicht sehr schmeichelhaft, und deshalb schmückt sich CSS Lint auch mit dem Slogan »Will hurt your feelings«.

Allerdings muss ich sagen, dass ich nicht mit allen Ver­besserungs­vor­schlä­gen ganz einverstanden bin. Wenn ich zum Beispiel eine Angabe mache wie hr.abstand, dann will ich eben einen bestimmten Abstand speziell für horizontale Trennlinien angeben und beim späteren Durchsehen meines Codes wissen, dass der Abstand nur für horizontal rules gelten soll.

Es stimmt: ich könnte statt dessen einen Kommentar einfügen. Der würde dann auch nicht beanstandet werden. W3C-konform ist meine Art der Auszeichnung aber trotzdem. Denn so lässt sich ja dieselbe Bezeichnung verschiedenen HTML-Tags zuordnen – schließlich will man manchmal (um bei diesem Beispiel zu bleiben) verschiedenen HTML-Tags verschiedene Abstände geben. Unterschiedliche Bezeichnungen würden hier nur verwirren, und Konstrukte wie .abstand-hr und .abstand-p finde ich schwachsinnig.

Trotzdem: ich denke noch mal drüber nach.

http://csslint.net/
http://scriptly.webocton.de/