TIL: Sass-Kommentare in komprimierten CSS-Dateien

Die Regel

Während eines Projektes macht man so einige Kommentare in seine Sass-Dateien um vielleicht ungewöhnlichen Code, der evtl. nur für eine Rückwärtskompatibilität (Hallo IE…) nötig ist, zu erläutern. Im Build-Prozess werden diese meist bei einer Komprimierung der finalen CSS-Datei entfernt (Sass-Parameter –style compressed), was durchaus auch gewollt ist um dem Website-Nutzer nur den Code übertragen zu müssen, der für die Darstellung der Website nötig ist.

Die Ausnahme

Manchmal ist es aber doch von Nöten, dass ein Kommentar in der finalen CSS-Datei erhalten bleiben muss. Heutzutage ist dies gerade oft bei Web-Fonts erforderlich, da der Kommentar über der @font-face Definition die Lizenz festlegt und nicht entfernt werden darf.

Die Lösung

Schreibt man in seiner Sass-Datei nun am Anfang statt des gewöhnlichen Block-Kommentars /* einfach /*! bleibt der gesamte Code-Block unkomprimiert erhalten, währnd der Rest der CSS-Datei von Kommentaren und unnötigen Leerzeichen befreit ist.

/*
Dieser Kommentar wird entfernt fuer die Ausgabe.
*/


/*!
Dieser Kommentar hingegen wird genau so in der CSS-Datei auftauchen.
*/

Bessere Semantik: Eigene Tags nutzen mit HTML5 Custom Elements

Semantik hat mir bei HTML schon immer gefallen,
<div>-Suppen vermeide ich wann immer möglich und schöpfe gerne die Markup-Möglichkeiten aus. Dementsprechend hab ich mich auch größtenteils über die neuen Elemente von HTML5 gefreut. Noch im Fluss, aber schon weit gediegen, sind die Custom Elements der Web Components – also die Nutzung von eigens definierten Tags, ähnlich wie man es von XML-Dokumenten kennt. Eine Ausrede à la „es gab kein passendes Tag“ ist damit also passé.
Bessere Semantik: Eigene Tags nutzen mit HTML5 Custom Elements weiterlesen

HTML5 template-Tag

Template-Technologien für’s Backend gibt es zuhauf (Smarty, Template-Toolkit,…), aber seit dem im Frontend immer mehr dynamisch an Code erstellt wird hat sich auch dort die Notwendigkeit für Template-Techniken ergeben. Da die Frontend-Script-Sprache Nummer 1 nun mal JavaScript ist lag es nahe, dass auch die Templates in JavaScript verwaltet werden, so entstanden beispielsweise Template-Systeme wie „mustache.js„.
Als Frontend-Entwickler möchte man allerdings eigentlich nicht Scripts und Markup vermischen. Haben wir es die letzten Jahre nun endlich hinbekommen, dass Markup, Scripts und Layout sauber getrennt sind würden Frontend-Templates in JavaScript das ganze wieder zunichte machen. Doch das Allzweck-Buzzword HTML5 hat da etwas in der Pipeline: das <template>-Tag. HTML5 template-Tag weiterlesen

Shadow DOM Grundlagen

Das Shadow DOM ist eine versteckte Hierarchie innerhalb des DOMs der Hauptseite. Den Shadow DOM kennen wir eigentlich schon länger. Am offensichtlichsten zeigt er sich beim <iframe>, denn jedem ist klar, dass sich innerhalb dieses Tags das DOM der eingebeteten Seite befindet. Etwas weniger offensichtlich zeigt er sich beim <video>-Tag. man baut nur das <video>-Tag ein, jedoch gibt es automatisch auch Elemente für die Navigation, die ja auch Objekte sein müssen. Diese Tags sind alle vordefiniert und können nur verwendet werden, jedoch lässt sich ein Shadow DOM mit Hilfe von JavaScript auch selbst erzeugen und nutzen. (Prefixes derzeit noch nötig) Shadow DOM Grundlagen weiterlesen

Sencha: Fastbook – Facebook-App in HTML5

Die Entwickler von Sencha haben sich herausgefordert gefühlt, als Mark Zuckerberg sagte, dass Facebook die App wieder umstellt von HTML5 auf eine native App. Also fingen sie an eine App in HTML5 zu bauen und siehe da: sie funktioniert und ist schnell. Neben einem direkten Vergleich findet man im Blog bei Sencha auch noch einige technische Erklärungen.

The Making of Fastbook: An HTML5 Love Story

Accessibility: Kontrast-Verhältnis Text- zu Hintergrundfarbe

Auf ihrer Website hat die Frontend-Entwicklerin Lea Verou heute ein neues Tool von sich vorgestellt: Contrast Ratio mit dem es einfach möglich ist das Kontrast-Verhältnis gegen die WCAG 2.0 Richtlinien zu testen. Accessibility: Kontrast-Verhältnis Text- zu Hintergrundfarbe weiterlesen

Windows in VM und ungültige gültige Zertifikate

Neulich hat mich den halben Vormittag ein nerviges Problem beschäftigt. Ich arbeite an einem Mac und um Websites im IE zu testen habe ich eine virtuelle Maschine (VirtualBox) mit einer Windows-Installation in der ich den Internet Explorer nutze. Brauche ich die VM nicht friere ich den aktuellen Zustand ein. Neulich wollte der IE nun kein Cookie für einen Login speichern, weil er meinte, dass das SSL-Zertifikat der https-Verbindung abgelaufen bzw. nicht aktuell sei.

Windows in VM und ungültige gültige Zertifikate weiterlesen

CSS Caching

Idealerweise sollte man das Caching selbst in die Hand nehmen, um die Kontrolle zu haben und es nicht einfach dem Browser überlassen. Es sollte aber auch immer die Möglichkeit geben einen Cache ungültig zu machen, sodass die Datei vor Ablauf des Caches neu geladen wird. Man stelle sich vor, das Caching für eine CSS-Datei ist auf einen Tag festgelegt, dann muss aber schnell ein Bugfix raus, jedoch bekommen die meisten User den Bugfix erst nach 24 Stunden mit, weil ihr Browser die CSS-Datei solange noch aus dem Cache lädt.

Cache einrichten

Um die Kontrolle zu übernehmen, arbeiten wir mit einer .htaccess-Datei, in der wir das Apache-Modul mod_expires verwenden. Der folgende Code aktiviert für alle Dateien vom Typ text/css ein Caching von 3 Tagen.

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/css "access plus 3 days"
</IfModule>

Beim ersten Abruf des CSS bekommt der Browser den ETag der Datei mit und speichert sich diesen. Bei der nächsten Anfrage des Browsers sendet dieser also erstmal lediglich seinen lokal gespeicherten ETag an den Server, dieser vergleicht den empfangenen ETag mit dem der vorliegenden Datei. Weicht dieser ab, wird die Datei mit dem Statuscode 200/OK gesendet. Hat sich der ETag nicht geändert, sendet der Server nur den Statuscode 304/Not Modified zurück und der Browser greift auf die im Cache liegende Datei zurück.

Caching ohne Cache-Control

Das klingt etwas verwirrend. Hat man keine Möglichkeit das Caching mittels ETag zu steuern, ist man erstmal etwas hilflos. Der Browser entscheidet selbst, ob und wie lange er die Datei aus dem Cache liest, bevor er sie wieder erneut vom Server anfragt. Prinzipiell ist sowas nicht kritisch, doch gerade wenn man einen Bugfix online stellt, der möglichst schnell bei jedem User ankommen soll oder wenn ein neues Feature bereitgestellt wird, wo sich die Templates geändert haben und das alte CSS nicht mehr zu den neuen Templates passt, da würde man gerne forcieren, dass der Browser des Users die Datei neu lädt.

Nun, der Hash-Wert einer Datei ändert sich immer, wenn sich auch die Datei ändert – das können wir uns zu Nutze mache.

Statt:
<link rel="stylesheet" type="text/css" href="standard.css" />

Binden wir folgendes ein (am Beispiel mittels PHP):
<link rel="stylesheet" type="text/css" href="standard-<?php echo hash_file("md5", "standard.css"); ?>.css" />

Die Funktion hash_file() ist seit PHP 5.1.2 verfügbar. Was bewirkt das nun? Auf dem Server liegt nach wie vor nur die Datei standard.css, jedoch lassen wir den Browser glauben, dass wir z.B. die Datei
standard-bfa0b1fd14b9d8e0a6dcf4bd0ab623e1.css
einbinden. Der Hash-Wert einer Datei bleibt gleich, solange sich an der Datei nichts ändert. Jedoch wird nur eine Kleinigkeit am Inhalt der Datei geändert, so ändert sich auch automatisch der Hash-Wert. Die Hexadezimal-Zahl nach dem Bindestrich ändert sich also jedes Mal, wenn wir eine Änderung an standard.css vornehmen. Da der Browser glaubt, dass eine komplett andere Datei eingebunden wird, wird die Datei definitiv neu vom Server geladen.

So weit so gut, jedoch liegt ja auf dem Server aber immer nur die standard.css-Datei und keine Datei, die den langen Zahlencode im Dateinamen beinhaltet. Damit die Datei trotzdem gefunden wird bemühen wir das Apache-Modul mod_rewrite. Folgenden Code schreiben wir in die .htaccess-Datei:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} ^(.*)-([a-f0-9]+)\.css$
RewriteRule ^(.*)-([a-z0-9]+)\.css$ $1.css

Die erste Zeile schaltet nur die RewriteEngine ein. In der zweiten Zeile wird die Bedingung definiert: Sie lautet, dass der Dateiname mit einer beliebigen Zeichenkette beginnt, dann folgt ein Bindestrich, anschließend eine Zeichenkette, die aus 0-9 und a-f besteht und zum Schluss endet der Dateiname auf .css. Die dritte Zeile ist nun die eigentliche Rewrite Regel: Der Teil des Dateinamens vor dem Bindestrich wird  genommen und serverintern wird eine Datei aufgerufen, die so lautet und auf .css endet.

Bei dieser Methode ist natürlich auch weiterhin direkt standard.css abrufbar, denn darauf passt die Rewrite-Bedingung nicht.

HTML5 Offline-Reader Web-App mit LocalStorage und Appcache

Dieses Projekt liegt jetzt schon bestimmt 4-5 Monate fast fertig bei mir rum, heute Abend hab ichs dann mal finalisiert. Es geht darum mittels HTML5 Elementen eine Web-App zu schreiben, die das offline lesen von Artikeln ermöglicht. Verwendete Techniken sind der LocalStorage des Browsers und der Appcache, also die Möglichkeit mittels Manifest-Dateien mehrere Dateien anzugeben, die der Browser offline zwischenspeichern soll. HTML5 Offline-Reader Web-App mit LocalStorage und Appcache weiterlesen

Adobe Shadow – Vereinfachung für mobile Web-Development

Es gibt ein neues Tool von Adobe in den Adobe Labs, es nennt sich „Adobe Shadow“ und hilft beim entwickeln von mobilen Websites. Das ganze besteht aus einem Chrome-PlugIn für den Desktop und einer App fürs mobile Test-Gerät (Android und iOS).

Voraussetzung ist, dass sich beide Geräte im selben (WLAN-)Netz befinden. Entweder finden sie sich selbst oder man gibt in der App die IP des Rechners an, mit dem man gerade arbeiten möchte.

Adobe Shadow – Vereinfachung für mobile Web-Development weiterlesen