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.

svn remove rückgängig machen

Dateien, die mittels svn remove gelöscht wurden, können schnell und einfach mit dem folgenden Befehl wiederhergestellt werden:

$ svn export [Link/zur/Datei/im/Projektarchiv]@[Versionsnummer]

Die Revisionsnummer bezieht sich dabei auf die letzte Revision, in der die Datei noch existierte. Wenn also mit Revision 43 die Datei index.html gelöscht wurde, wählt man folglich Revision 42 um den letzten Stand der Datei vor der Löschung wiederherzustellen:

$ svn export https://subversion.paulchr.ablass.me/svn/starter-kit/trunk/index.html@42

Links

svn export

Nachtrag

In einer älteren Version des Artikels stand, dass Dateien mit svn update -r[Revisionsnummer] [Pfad/zur/Datei] wiederhergestellt werden können. Das ist leider nur halb richtig, da auf diese Weise wiederhergestellte Dateien nach dem nächsten svn update erneut gelöscht werden.

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.

Syntaxhighlighting in vim ändern

Normalerweise erkennt vim den Dateityp einer Datei sehr zuverlässig und wendet das richtige Syntaxhighlighting an. Dieses normalerweise schließt allerdings nicht unbedingt das Lösen von merge-Konflikten mit ein, so dass für diese Fälle der Dateityp manuell gesetzt beziehungsweise das richtige Syntaxhighlighting aktiviert werden muss. Dazu gibt es den Befehl :set syntax=[Syntaxkürzel].
Um also beispielsweise das Syntaxhighlighting einer Datei auf Php zu stellen, muss

:set syntax=php

eingegeben werden.

Links

Forcing Syntax Coloring for files with odd extensions

Danke, Jan!

Domainübergreifene Zugriffe auf Webfonts (CORS)

Gelegentlich werden Webfonts von einer anderen Domain/ einem anderen Server eingebunden (Cross Origin Request). Im Zuge dessen kann es vorkommen, dass der Zugriff auf diese Dateien auf Grund der Einhaltung der Same-Origin-Policy abgelehnt wird und die Schriften nicht geladen werden. Glücklicherweise gibt es mit Cross Origin Ressource Sharing (CORS) aber eine Methode, um diese Cross Origin Request zu ermöglichen. Dazu muss folgender Code in die .htaccess eingefügt werden:

# BEGIN CROSS ORIGIN RESSOURCE SHARING FOR WEBFONTS
<FilesMatch "\.(ttf|eot|woff)$">
    <IfModule mod_headers.c>
        Header set Access-Control-Allow-Origin "*"
    </IfModule>
</FilesMatch>
# END CROSS ORIGIN RESSOURCE SHARING FOR WEBFONTS

Dadurch wird das Aufrufen von Dateien der Formate ttf, eot und woff von fremden Origins ermöglicht.

Links

HTTP access control (CORS)
Same-origin policy

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.

Mit svn export veränderte Dateien wiederherstellen

Mit svn export kann durch Angabe des -r-Parameters ein älterer Stand einer Datei wiederhergestellt werden:
Beispiel:

$ svn export [Pfad/zur/Datei/im/Repo] -r[Revisionsnummer] [Pfad/zum/neuen/Dateispeicherort]

Lies: Exportiere Datei X aus Revision Y zu Speicherort Z.
Ein echtes Beispiel:

$ svn export sass/style.scss -r42 ~/Desktop/style.scss

Die Datei style.scss wird mit dem Stand aus Revision 42 aus dem Projektarchiv auf den Desktop exportiert.

Links

svn export

Weiterleitungen (redirects) in der .htaccess

Nachdem die letzten Tage eine ganze Reihe von Links zu seit Jahren nicht mehr existierenden Seiten hier angespült wurden und die Google Webmaster Tools schon mahnende Mails verschickten, habe ich mich schlau gemacht wie darauf am besten zu reagieren ist. Standardmäßig ist der Http-Status-Header im Falle einer nicht gefundenen Ressource 404, was aber eine an sich doch eher dürftige Information für den aufrufenden Client und auch den Googlebot ist.
Abhilfe schaffen Http-Statuscodes in der .htaccess-Datei.

Http-Statuscode 410: Ressource nicht mehr existent

RewriteEngine on
Redirect 410 /relativer/Link/zur/nicht/mehr/existierenden/Ressource/

Bei nicht mehr existenten Links empfiehlt es sich, den Statuscode 410 zurückzusenden, der ganz klipp und klar ausdrückt dass die angefragte Ressource nicht mehr vorhanden ist und man den Link darauf doch bitte entfernen soll.

Http-Statuscode 301: Ressource ist an einer anderen Adresse verfügbar

Redirect 301 /relativer/Link/zur/nicht/mehr/existierenden/Ressource/ /relativer/neuer/Link/zur/umgezogenen/Ressource/

Wenn sich hingegen nur der Link zu einer Ressource geändert hat, kann der anfragende Client mit Hilfe des 301-Statuscodes zur neuen Adresse umgeleitet werden.

Links

HTTP response codes