Css3-Verläufe als Grafik exportieren

Der Export von Verläufen aus Grafiken in Css3 ist dank Tools wie dem Ultimate CSS Gradient Generator ein Kinderspiel. Manchmal besteht jedoch die Notwendigkeit, diesen Prozess umzukehren und einen Css3-Verlauf in eine Grafik umzuwandeln. Bislang kannte ich nur zwei Möglichkeiten, dies zu bewerkstelligen:

  • Einen Screenshot des Verlaufs anfertigen. Diese Methode ist jedoch ungeeignet, wenn der Verlauf Transparenzen enthält.
  • Den Verlauf in Photoshop/ dem Grafikprogramm der Wahl nachbauen. Bei Verläufen mit vielen color stops und Transparenzen ist das allerdings ein Heidenaufwand und auch ziemlich langweilig monoton

Darum habe ich mich etwas schlau gemacht und eine unglaublich einfache Methode gefunden, bei der die Art des Verlaufs (viele color stops, Transparenzen) keine Rolle spielt und die außerdem noch sehr schnell geht.

tl;dr

In Kurzform: Mit dem PhantomJS-Task rasterize wird der in einer separaten Datei liegende Verlauf gerendert und der Output als .png-Datei abgespeichert.

PhantomJS unter Mac OS X installieren

PhantomJS bezeichnet sich selbst als headless WebKit scriptable with a JavaScript API. Dahinter steckt eine über das Terminal bedienbare Webkit-Engine ohne GUI, mit der beispielsweise Tasks für Tests oder Screenshots automatisiert werden können.

Die Installation ist schnell erledigt: Gemäß Anleitung PhantomJS and Mac OS X wird ein Zip-Archiv heruntergeladen, entpackt und die ausführbare PhantomJS-Datei in den Ordner /usr/bin/local/ ($PATH) verschoben.
Da PhantomJS für seine Tasks auf JavaScript- oder Coffeescript-Dateien zurückgreift und ich diese nicht in /usr/bin/local/ rumliegen lassen wollte, habe ich einen anderen Ordner als Speicherort gewählt und einen auf /usr/bin/local/ verweisenden Symlink erstellt.

$ sudo ln -s /Pfad/zu/PhantomJS /usr/local/bin/

Eine Website rendern und den Output als .png speichern

Im extrahierten Zip-Archiv befindet sich auch ein examples-Verzeichnis, in dem die Datei rasterize.js liegt. Diese beinhaltet den benötigten PhantomJS-Task, der eine Website rendert und den Output in einem definierbaren Dateiformat speichert (mehr dazu auf der Seite Screen Capture im PhantomJS-Wiki).
Um nun allein den Verlauf abzuspeichern, muss dieser in vanilla Css in einer Beispiel-Html-Datei eingebunden werden. Ich habe mir dazu eine Datei gradient2image.html erstellt, die lediglich folgenden Code beinhaltete:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>gradient2image</title>
    <style>
      html,
      body {
        margin: 0;
        padding: 0;
        width: 100%;
        height: 100%;
        background: -webkit-linear-gradient(top, rgba(0,0,0,0) 0%,rgba(0,0,0,0.5) 45px,rgba(0,0,0,0.75) 60px,rgba(0,0,0,0.85) 75px,rgba(0,0,0,0.95) 90px,rgba(0,0,0,1) 135px,rgba(0,0,0,1) 100%);
       background: linear-gradient(to bottom, rgba(0,0,0,0) 0%,rgba(0,0,0,0.5) 45px,rgba(0,0,0,0.75) 60px,rgba(0,0,0,0.85) 75px,rgba(0,0,0,0.95) 90px,rgba(0,0,0,1) 135px,rgba(0,0,0,1) 100%);
      }
    </style>
  </head>
  <body></body>
</html>

Zu beachten ist dabei, dass PhantomJS eine vollwertige Webkit-Engine mit allen Stärken und Schwächen ist- daher müssen auch vendor prefixes angegeben werden, da es ansonsten vorkommen kann dass der Verlauf nicht angezeigt wird.

Nachdem die Datei angelegt ist, wird der rasterize-Task vom entsprechenden Ordner mit der Option, den Output als .png-Datei zu speichern, ausgeführt.

$ phantomjs rasterize.js /Pfad/zur/gradient2image.html /gewünschter/Output-Pfad/für/rasterize-output.png

Et voilà- da ist er, der Verlauf. Sauber exportiert von Css3 in eine .png-Datei.

Lesetipp: Ein Zwischenstand zu responsive images

A Q&A on the Picture Element ist ein guter Ausgangspunkt, um sich auf den aktuellen Stand der Entwicklung bei responsives images zu bringen. Zum einen wird ein kurzer Abriss des bisherigen Entwicklungsprozesses gegeben und zum anderen bietet der Artikel genug Links und Schlagworte für eine vertiefende Recherche. Die momentan™ angestrebte Implementierung für responsive images besteht wohl aus einer Verschmelzung von srcset und dem <picture>-Element:

<picture>
    <source media="(min-width: 40em)" srcset="big.jpg 1x, big-hd.jpg 2x">
    <source srcset="small.jpg 1x, small-hd.jpg 2x">
    <img src="fallback.jpg" alt="">
</picture>

Mehr dazu kann man auf der Website der Responsive Images Community Group erfahren.

Lesetipp: faux bold vermeiden & verschieden fette Schriftschnitte richtig einbinden

Gerrit van Aaken erklärt in Webfonts: Fette Fehlerquelle, wie das Einbinden von unterschiedlich fetten Schnitten einer Schrift funktioniert. Eine sehr gute, aktuelle, deutsche Zusammenfassung zu einer Technik, die zum Handwerkszeug eines Frontend Developers gehört und die leider oft falsch genutzt wird.

color stops in Verläufen an der selben Position bei unterschiedlich hohen Elementen

Das Problem

In einem aktuellen Projekt kann auf Unterseiten einer Website ein Hintergrundverlauf zugeschaltet werden, der von transparent zu schwarz übergeht. Das ist erst einmal kein Problem, immerhin können mittlerweile sowohl kreisförmige als auch lineare Verläufe mit Css umgesetzt werden. Der Ultimate CSS Gradient Generator ist ein wunderbares Tool zur Umsetzung solcher Verläufe. Der benötigte lineare Verlauf sieht so aus:

background: linear-gradient(to bottom, rgba(0,0,0,0) 0%,rgba(0,0,0,0.5) 15%,rgba(0,0,0,0.75) 20%,rgba(0,0,0,0.85) 25%,rgba(0,0,0,0.95) 30%,rgba(0,0,0,1) 45%,rgba(0,0,0,1) 100%);

Der Verlauf wird dadurch einwandfrei gezeichnet- aber es gibt ein Problem: Auf unterschiedlich hohen Seiten sind die color stops zwar prozentual an der selben Position, nicht aber wenn es um die tatsächliche Position in Pixeln vom Beginn der Seite geht. 15% von 1000 Pixel entspricht natürlich einem anderen Wert als 15% von 833 Pixel. Ich habe eine Demo-Seite gebaut, auf der das Problem grafisch aufbereitet gezeigt wird.

Die Lösung(en)

Es gibt mindestens zwei Lösungswege für dieses Problem. Der eine besteht darin, dem Verlauf eine Größe zuzuweisen, während die andere Lösung mit Pixelwerten für die Position der color stops arbeitet.

Die Größe des Hintergrunds begrenzen

Mit der background-size-Eigenschaft kann die Größe eines Hintergrunds angegeben werden. Da ich in meinem Fall die Höhe des Verlaufs auf 650 Pixel begrenzen wollte, habe ich folgendes probiert:

background: linear-gradient(to bottom, rgba(0,0,0,0) 0%,rgba(0,0,0,0.5) 15%,rgba(0,0,0,0.75) 20%,rgba(0,0,0,0.85) 25%,rgba(0,0,0,0.95) 30%,rgba(0,0,0,1) 45%,rgba(0,0,0,1) 100%);
background-size: 100% 650px;

Dadurch wird gewährleistet, dass der Verlauf sich nicht mehr der Seitenhöhe anpasst, sondern exakt 650 Pixel in der Höhe annimmt. Das bringt allerdings ein neues Problem mit sich: Sobald die Seite höher als 650 Pixel ist, fehlt ab dieser Position der Hintergrund. Der Verlauf hört eiskalt auf und bleibt von 651 Pixel bis (beliebig hohe Zahl < 651 Pixel) transparent. Das Hinzufügen einer Hintergrundfarbe mittels background-color funktioniert leider nicht, da diese ansonsten den (semi-)transparenten oberen Teil des Verlaufs überlagert.
Daher schied diese Lösung leider aus und ein anderer Versuch musste unternommen werden, den Verlauf auf die gewünschte Art und Weise zeichnen zu lassen.

Pixelwerte in der Verlaufs-Eigenschaft

Beim Herumexperimentieren mit der Größe des Verlaufs entwickelte sich eine Idee: Wäre es nicht auch möglich, die Position der color stops Pixel zu definieren? Damit sollten die color stops auch bei verschieden hohen Verläufen an der selben Position stehen. Gesagt, getan:

background: linear-gradient(to bottom, rgba(0,0,0,0) 0%,rgba(0,0,0,0.5) 98px,rgba(0,0,0,0.75) 163px,rgba(0,0,0,0.85) 195px,rgba(0,0,0,0.95) 228px,rgba(0,0,0,1) 293px,rgba(0,0,0,1) 100%);

Wie auf der Demo-Seite ersichtlich ist, funktioniert diese Methode ausgezeichnet und löst das Problem.

Maskierungszeichen in Css

Gelegentlich besteht die Notwendigkeit, bestimmte Zeichen(folgen) in Css zu maskieren, um zu verhindern dass sie gemäß ihres ursprünglichen Einsatzzweckes ausgeführt werden. Beispielsweise, wenn größere Codeblöcke mit dazugehörigen Kommentaren auskommentiert werden sollen:

/* Auskommentierung
.extended_subnav {
    width: 211px;
    position: absolute;
    z-index: 10;
    right: 0; /* Analog zum padding-right von .mod_subnav */
    top: 30px;
    display: none;
    opacity: 0;
    @include single-transition(opacity, 3s, ease-in-out);
}
Auskommentierung Ende */

Die Auskommentierung hört nach dem inneliegenden Kommentar auf und kann so ihren Zweck nicht erfüllen. Um das zu verhindern, kann entweder dieser Kommentar gelöscht werden (nicht sinnvoll) oder aber die Kommentaranfang und -ende signalisierenden Slashes werden mit einem Maskierungszeichen (escape character) maskiert (sinnvoll).

Maskierungszeichen

Wie das Maskieren genau funktioniert, hat Mathias Bynens in seinem Artikel CSS character escape sequences detailliert erklärt und weist auf die eleganteste und einfachste Lösung hin:

The second option is far more elegant though: just escape the character using a backslash (\), e.g. + would escape into \+.

Angewendet beim obigen Code-Schnippsel sieht das so aus:

/* Auskommentierung
.extended_subnav {
    width: 211px;
    position: absolute;
    z-index: 10;
    right: 0; \/* Analog zum padding-right von .mod_subnav *\/
    top: 30px;
    display: none;
    opacity: 0;
    @include single-transition(opacity, 3s, ease-in-out);
}
Auskommentierung Ende */

Aggressives Firefox-Schriftcaching mit Versionsnummern austricksen

Sämtliche Firefox-Versionen, die ich unter Ubuntu, Windows 7 und Mac OS X benutze, speichern einmal geladene Webfonts sehr aggressiv. Aggressiv bedeutet in diesem Fall, dass ein normales Löschen des Caches zum Neu-Laden der Schrift nicht ausreicht, stattdessen muss zusätzlich noch der Browser neu gestartet werden. Da dies im Entwicklungsprozess doch eher unschön ist, bin ich dazu übergegangen eingebundene Webfonts mit einer Versionsnummer innerhalb des @font-face-Blocks zu versehen. Beim Ändern der Schrift erhöhe ich die Versionsnummer manuell und zwinge Firefox so, die Schrift neu zu laden. Klappt wunderbar und ist wesentlich entwicklerfreundlicher als das Schließen und Wiederöffnen des Browsers.

@font-face {
    font-family: '[Iconfont-Name]';
    src:url('../fonts/[Iconfont-Name]/[Iconfont-Name.eot]?1.0');
    src:url('../fonts/[Iconfont-Name]/[Iconfont-Name.eot]?1.0#iefix') format('embedded-opentype'),
        url('../fonts/[Iconfont-Name]/[Iconfont-Name.woff]?1.0') format('woff'),
        url('../fonts/[Iconfont-Name]/[Iconfont-Name.ttf]?1.0') format('truetype'),
        url('../fonts/[Iconfont-Name]/[Iconfont-Name.svg]?1.0#[Fragmentbezeichner]') format('svg');
    font-weight: normal;
    font-style: normal;
}

Initial-Werte für Css-Eigenschaften

Gelegentlich passiert es, dass mir nicht sofort der Initial-Wert für bestimmte Css-Eigenschaften einfällt. Um in solchen Momenten nicht wild zu raten oder aber versehentlich einen falschen Wert aufzuschreiben (wieso das keine gute Idee ist, schreibt Divya Manian in Safe CSS Defaults), empfiehlt sich ein Blick in diese Liste von Initial-Werten für sehr viele Css-Eigenschaften.

Eine Alternative dazu ist das Projekt CSS Values: Auf der Website gibt man einfach die gewünschte Eigenschaft ein und erhält sowohl eine Liste der möglichen Werte als auch weiterführende Links zu dieser Eigenschaft.