Schöneres Subpixelrendering in Chrome bald verfügbar

Schriftrendering von Firefox (oberhalb der Linie) und Chrome (unterhalb der Linie) unter Windows
Schriftrendering von Firefox (oberhalb der Linie) und Chrome (unterhalb der Linie) unter Windows. Text entnommen von Meinung Nr. 2f auf blogroyal.de

In absehbarer Zeit wird einer der nervigsten Bugs im Chrome unter Windows verschwinden (Feuerwerk!): Das Schriftrendering wechselt in Bälde von GDI zu DirectWrite, womit fehlerhaft dargestellte Schriften wie im obigen Bild der Vergangenheit angehören sollten.
In der Chrome Canary (Version 34) mit den aktivierten Flags --enable-direct-write und --no-sandbox (mehr dazu in Chrome mit Flags starten) funktioniert das Subpixel-Rendering schon wunderbar, so dass die vielen bestehenden Workarounds zur Behebung dieses Problems bald nicht mehr benötigt werden sollten.

Chrome mit Flags starten

Um den Funktionsumfang von Chrome/ Chrome Canary/ Chromium zu erweitern, besteht die Möglichkeit den Browser mit sogenannten „Flags“ zu starten. Flags sind Startparameter, die mit der Kommandozeile übergeben werden und Optionen wie beispielsweise das subpixel font scaling zur besseren Darstellung der Schrift aktivieren.

Flag-Aktivierung unter Windows

Chrome mit Flags unter Windows startenAuf einem Windows-Rechner muss nicht unbedingt die Eingabeaufforderung benutzt werden, um Chrome mit Flags zu starten. Einfacher ist es, wenn wie folgt vorgegangen wird:

Rechtsklick auf das Browser-Icon* > Eigenschaften im Kontextmenü auswählen > das gewünschte Flag an den Ziel-Wert anfügen.

Aus "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" wird "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --enable-direct-write --no-sandbox

*Funktioniert nicht mit Icons in der Taskleiste.

Flag-Aktivierung unter Mac OS X

Unter OS X kann das Terminal benutzt werden, um Flags zu übergeben:
$ /Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --enable-direct-write --no-sandbox

ACHTUNG!

Das Flag --no-sandbox deaktiviert Chromes Sandbox-Funktion und ist potentiell gefährlich. Daher geschieht die Deaktivierung auf eigene Gefahr und sollte keinesfalls bei einem Browser ausgeführt werden, der zum täglichen Surfen genutzt wird.

Links

How to run Chromium with Flags

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 */

Zielverzeichnis beim Entpacken von Archiven ändern

Kleine Sachen, die das Leben leichter machen: Um beim Entpacken das Zielverzeichnis eines Archivs zu ändern, muss der Parameter -d> mitgegeben werden:

unzip archiv.zip -d [Verzeichnis]

Beispiel

paul@athene:/var/www/paulchrablass$ unzip ghost-0.3.2.zip -d ghost

Damit wird das Archiv ghost-0.3.2.zip im Verzeichnis /var/www/paulchrablass/ in den neuen Ordner ghost entpackt.

Links

unzip manpage

OS X 10.8.4, Firefox 24 und die Scrollbars in der Responsive Design View

Scrollbars in der Responsive Design View liegen über dem SeiteninhaltAls ich am vergangenen Dienstag den frisch auf Version 24 aktualisierten Firefox benutze und mich daran machte, mein aktuelles Projekt in der Responsive Design View zu bearbeiten, wunderte ich mich etwas: Zuvor nebeneinander fließende Elemente brachen mit einem Mal um. Beim Blick in das Layout-Fenster vom Firebug fiel mir auf, dass die Seitenbreite quasi über Nacht von 320 auf 305 Pixel gesunken war. Wie konnte das passieren? Nach ein wenig Grübeln (und einer Tasse Kaffee) kam ich schließlich drauf: Die Scrollbars lagen nicht mehr über dem Inhalt, sondern daneben und beeinträchtigten somit dessen Breite. Äußerst unschön, denn dieses Verhalten stimmt nicht mit mobilen Endgeräten überein in denen Scrollbars über dem Inhalt liegen (mittlerweile ist dieser Bug dokumentiert und soll in Firefox-Version 27 behoben werden).

Ein temporärer Fix für dieses Problem bestand im Addieren von je 15 Pixel zu den entsprechenden Preset-Breiten der Responsive Design View. Etwas umständlicher zwar, aber es funktionierte.

Als ich dieses Problemchen jedoch kurz darauf mit meinen Frontend-Developer-Kollegen besprach, kam eine weitere Lösungsmöglichkeit zu Tage: Und zwar gibt es in den Systemeinstellungen unter Allgemein spezielle Settings für Rollbalken. Dort muss die Option Beim Scrollen aktiviert sein. Dies bewirkt, dass systemweit Scrollbars nur beim tatsächlichen Scrollen eingeblendet werden und dann über dem Fensterinhalt liegen- auch in der Reponsive Design View im Firefox 24.
Scroll-Einstellungen von OS X 10.8.4

Missglückte Anmeldeversuche von IP 72.233.119.245

Zu meiner großen Überraschung bekam ich heut Abend eine E-Mail mit folgendem Inhalt:

3 ungültige Anmeldeversuche (1 Sperrung(en)) von IP: 72.233.119.245
Letzter Anmeldeversuch erfolgte mit dem Benutzernamen: username

Ich benutze für meine WordPress-Installationen grundsätzlich das Plugin Limit Login Attempts, dass nach drei missglückten Anmeldeversuchen die IP des sich Einloggenden für eine bestimmte Zeit sperrt. Daher hätte ich mich erst einmal nicht groß wundern müssen, denn solche Versuche sich mit Standard-Nutzernamen-Passwort-Kombinationen einzuloggen und das Blog zu kapern sind nicht unbedingt selten.

Nein, was mich zum wundern brachte war der Umstand dass ich nach der großen Angriffswelle gegen WordPress-Installation im Frühjahr dieses Jahres einen zusätzlichen .htaccess-Schutz für mein Backend eingerichtet hatte. Daher stellte ich mir leicht nervös die Frage: Hatte jemand meine Login-Daten abgegriffen und machte sich nun daran, auch die WordPress-Loginmaske zu knacken?
Nach einer kurzen Suche dann aber die erlösende Antwort: Nein, falscher Alarm. Der Loginversuch von der IP 72.233.119.245 stammt im etwas weiteren Sinne von WordPress selbst. Dahinter steckt nämlich ein Crawler von Automattic, also der Firma die hinter WordPress steckt.

Nichtsdestotrotz kam mir das Spanisch vor: Wieso sollte sich ein Crawler mit dem Benutzernamen username bei mir einloggen wollen? Etwas aufschlussreicher war dann ein Thread in einem der WordPress-Supportforen. Dort meldeten sich auf die Frage eines Users, was es mit diesem Crawler auf sich hat, Automattic- bzw. WordPress-Entwickler zu Wort und erklärten, dass dies wohl die Server des Jetpack-Plugins sind, die mit meiner Seite kommunizieren:

When you combine how most XML-RPC endpoints work with how WordPress handles authentication, though, it turns out that, even though Jetpack uses it’s own OAuth-based authentication, we still have to send a username and password with the request. The Jetpack plugin tells WordPress to completely ignore that username and password, but we still have to send it to get things in WordPress working correctly.

Michael Adams (mdawaffe)

Kein Grund zur Beunruhigung also: Mein .htaccess-Schutz ist nicht ausgehebelt worden.

Sass-/ Compass-Encoding auf UTF-8 umstellen

Beim erstmaligen compass compile eines neuen Projekt wurde mir heute die folgende Fehlermeldung ausgegeben:

Invalid US-ASCII character "\xC3"

Sass und Compass bekommen ihre Encoding-Optionen von Ruby, dass sie wiederum vom Environment (sprich: Dem Server, auf dem es läuft) übernimmt.

Um dieses Problem zu beheben, können zum einen die Locales (Spracheinstellungen) des Systems angepasst werden oder aber „nur“ das Encoding von Sass/ Compass auf UTF-8 umgestellt werden.

Locales umstellen

Achtung: Ich habe, was Server-Geschchichten angeht, maximal Achtelwissen und frage lieber sachkundige Mitmenschen. Daher verweise ich gern auf den Wiki-Artikel Locales unter Ubuntu konfigurieren.
In meinem konkreten Fall bekam ich (wie immer) schnell und kompetent Support von meinem Hoster Uberspace, der mit freundlicherweise die benötige Zeile Code gleich per Mail schickte:

export LC_CTYPE="en_US.UTF-8"

Hat bei mir funktioniert:

[user@server ~]$ locale
LANG=
LC_CTYPE=en_US.UTF-8

Encoding von Sass/ Compass ändern

Um das Encoding von Sass/ Compass zu ändern, muss in der config.rb-Datei folgende Zeile Code eingefügt werden:

Encoding.default_external = 'utf-8'

Quellen

Encoding error on compass font-face mixin

Lesetipp: Designing In The Open

Brad Frost redesigned die Website der Greater Pittsburgh Community Food Bank. Das Besondere daran? Jeder Schritt des Redesigns wird öffentlich gemacht. „Designing in the Open“ heißt diese Methode, die laut Brad eine ganze Reihe von Vorteilen (aber natürlich auch einige Nachteile) bietet. Im Beitrag werden diese ausführlich genannt, nebst Beispielen von ähnlichen Projekten sowie hilfreichen Tipps, wie dem Kunden so etwas nahe gebracht werden kann.

Die Redesign Timeline hat mir bereits etwas neues gezeigt: Zum einen das Content Inventory, dass ich schon oft vermisst habe (aber so leider noch nie angelegt habe) und zum anderen das Pattern Lab, dass ich gern für meine nächsten Projekte ebenfalls bauen möchte.

PuTTY-Theme-Einstellungen ändern

Auf meinem Windows-7-Laptop ist PuTTY das Tool meiner Wahl, um mich via ssh mit meinem Webspace zu verbinden. Weil mir die Default-Darstellung nicht unbedingt zusagte und ich ein großer Fan des Monokai-Themes bin, lag nichts näher als dieses Farbschema auch in PuTTY zu aktivieren.

Der erste Schritt besteht im Erstellen einer .reg-Datei mit den Monokai-Farben als Inhalt.

Dazu einfach den obigen Text kopieren, in eine leere Datei in einen beliebigen Texteditor einfügen und als monokai.reg abspeichern. Selbstverständlich ist auch jeder andere Dateiname in Ordnung.

Im Abschnitt

[HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions\monokai]

ist der String monokai am Ende der Zeile wichtig, da dies der Name der Session ist die im PuTTY-Sessions-Manager geladen werden muss um auch wirklich das Monokai-Theme zu aktivieren.

Um eine bereits existierende Session mit dem gewünschten Theme zu benutzen, muss der Name der Session an Stelle von Monokai in die .reg-Datei eingetragen werden. Wenn also wie bei mir die Session „Uberspace“ heißt, dann wird aus

[HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions\monokai]

folglich

[HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions\Uberspace]

.
PuTTY-Session-Manager
Nachdem der gewünschte Sessionname eingetragen ist, müssen die Settings aus der frisch erstellten .reg-Datei lediglich in der Systemregistry gespeichert werden. Dazu mit rechts auf die Datei klicken, im nun erscheinenden Kontextmenü „Zusammenführen“ aktivieren und die aufploppenden Sicherheitshinweise bestätigen.

Von nun sollte im PuTTY-Session-Manager entweder die Session „Monokai“ (wenn keine bestehende Session eingetragen wurde) oder aber die angepasste bestehende Session mit dem Monokai-Theme ladbar sein.

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