Skip to content

nanoc 4.0.0 beta 1

Bereits mehrfach hatte ich über nanoc berichtet, dessen Entwicklung nunmehr wieder mit Elan fortschreitet.

Seit einigen Tagen gibt es die erste Beta-Version von nanoc 4.0 mit bereits teilweise angepasster Dokumentation - und obwohl dieses Release eigentlich keine neuen Features enthalten, sondern nur den Code für zukünftige Veränderungen vorbereiten soll, gibt es einige Neuigkeiten zu vermelden:

  • In den Rules können nunmehr erweiterte Platzhalterzeichen (Globs) verwendet werden. Gab es bisher nur die Möglichkeit, * und + zu verwenden, bspw. in der Form /projects/*/, gibt es in nanoc 4.0 neue Möglichkeiten wie * contra ** oder Zeichensätze wie [abcdefg] oder auch Auswahllisten wie {foo,bar}. Vermutlich wird das der neue Default.

  • Von manchem lange erwartet gibt es in der neuen Version zwei verschiedene Formate für Items, also einzelne Quelltextdateien: full format (neu) und stripped format.

"nanoc 4.0.0 beta 1" vollständig lesen

nanoc und MySQL

Ein static site generator wie bspw. nanoc erzeugt, wie der Name schon sagt, im wesentlichen statische Seiten ohne - zumindest serverseitige - dynamische Elemente, oder schlicht: HTML-Dateien. Dennoch ist es möglich, solchen Webpräsenzen eine begrenze “Dynamik” zu verleihen, und dies nicht nur durch Einbindung von Drittanbieter-Diensten wie bspw. der Kommentar- und Diskussionsplattform Disqus - soll sich der Inhalt einer oder mehrerer Seiten ändern, müssen sie eben neu generiert werden.

Üblicherweise wird die Neugenerierung immer dann (manuell) veranlasst, wenn eine neue Seite oder ein neuer Beitrag (in einem statisch generierten Blog) verfasst oder ein bestehendes Quelldokument verändert worden ist. Jedoch kann eine Neugenerierung der Seiten auch angestoßen durch externe Ereignisse erfolgen. Man könnte bspw. immer dann, wenn ein neuer Beitrag eines bestimmten Accounts auf Twitter veröffentlicht wird, diesen Tweet in die Webseiten einbinden und dann die dadurch veränderten Seiten neu generieren - oder, bspw., einen RSS-Feed regelmäßig (täglich, stündlich, …) auslesen und bei einer Änderung die betreffenden Seiten der (eigentlich statischen) Webpräsenz neu generieren und auf diese Weise einen Newsticker einbinden, der allerdings nicht in Echtzeit “tickt”. Sehr häufig ist eine solche Echtzeit-Aktualisierung aber auch gar nicht nötig, weil sich Änderungen ohnehin nur in größeren Zeitabständen ergeben und es unschädlich ist, wenn sie mit einer gewissen Verzögerung angezeigt werden. So bindet bspw. der CCCS in seinen durch nanoc erzeugten Webseiten die Tweets des Accounts @cccs ebenso ein wie eine Übersicht der Blogbeiträge von Aktiven des Vereins. Die entsprechenden Daten werden in regelmäßigen Abständen ausgelesen, danach werden dann - wenn erforderlich - die betreffenden Webseiten neu erzeugt.

Die Dynamik lässt sich aber noch deutlich weiter treiben.

"nanoc und MySQL" vollständig lesen

nanoc: Auswahl des Templates via YAML

Nicht selten lassen sich die meisten Seiten einer Webpräsenz aus demselben Template erzeugen, wohingegen einige Ausnahmefälle einer Sonderbehandlung bedürfen - bspw. die Startseite oder landing page, die oft anders gestaltet ist als der Rest der Webseiten, und sei es nur, dass sie keine oder andere Navigations-Elemente aufweist oder mehrspaltig statt einspaltig (oder umgekehrt) dargestellt werden soll.

Mag es bei der Verwendung von nanoc für eine singuläre Ausnahme noch sinnvoll sein, sie explizit in die - bereits erläuterte - Rules-Datei aufzunehmen, gibt es für diese Aufgabenstellung eine sehr einfache Lösung: ein abweichendes Template kann nämlich im YAML-Metadatenblock jeder Seite angegeben werden.

Sollen nun die Webseiten einer Präsenz normalerweise das Template namens default verwenden, die Startseite aber das Template startpage, so erhält die Quellcode-Datei der Startseite einen entsprechenden Eintrag in ihre YAML-Metadaten, bspw. template: startpage, und die Rules-Datei erhält dann im compile-Block an der passenden Stelle - statt layout 'default' - die Anweisung layout item[:template] || 'default'.

Man kann auch - wie es der CCCS tut - die Variante “gar kein Template” direkt mit aufnehmen:

  1. if item[:template]!=‘none’
  2.   layout item[:template] || ‘default’
  3. end

nanoc-Rules "passthrough" und "ignore"

Ich nutze mittlerweile für eine ganze Reihe (meist eher einfacher) Webpräsenzen den static site generator nanoc. nanoc, geschrieben in Ruby, erzeugt anhand vorgegebener Regeln aus einer Verzeichnisstruktur mit Quellcode-Dateien in verschiedenen denkbaren Formaten und Seiten-Templates unter Anwendung von Filtern und ggf. ergänzenden (in Ruby geschriebenen) Modulen eine (grundsätzlich) statische, d.h. aus einzelnen HTML-Dateien bestehende, Website. Man kann sich das beispielsweise an den Webseiten des CCCS ansehen.

"nanoc-Rules "passthrough" und "ignore"" vollständig lesen

Blogparade: Webspace-Inventar

Über Dirk und onli stieß ich auf die BlogparadeWebspace-Inventar: Was ist auf deinem Webspace installiert?”. Ich kann mich nicht erinnern, mich jemals an einer Blogparade beteiligt zu haben, aber warum nicht?

Genannt sind in der Folge nur Dienste, die auf Webspace / Servern außerhalb meines heimischen Netzwerkes installiert sind - und große Überraschungen sind vermutlich nicht dabei. Über die meisten der Dienste habe ich bereits gebloggt, so dass entsprechende Beiträge über das jeweilige Tag in der Seitenleiste abrufbar sind.

  • Serendipity ist die Blog-Engine, die auch dieses Blog seit 2005 betreibt. Ich glaube nicht, dass ich dazu noch viel schreiben muss. :-)

  • Auch Wordpress bedarf sicherlich keiner Vorstellung mehr; es handelt sich um die wohl am weitesten verbreitete Blog-Engine, die oft auch als “CMS für Arme” hüstel Verwendung findet und die ich seit vergangenem Jahr teste.

  • Dokuwiki nutze ich in einer Multisite-Installation als Wiki, aber auch als mein “CMS für Arme” für einige kleinere Webseiten. Dokuwiki wird sehr aktiv entwickelt, ist leichtgewichtig, weil es keine Datenbank benötigt, sondern alle Seiten-Revisionen als Dateien speichert, ist durch Module leicht erweiter- und durch Templates gestaltbar (für beides gibt es eine große Auswahl), und es hat eine Rechteverwaltung mit Benutzern und Benutzergruppen, denen unterschiedliche Rechte für einzelne Seiten, aber auch für Namespaces zugewiesen werden können.

  • Die von mir gehosteten Git-Repositories sind über das Web via Gitweb zugänglich, also über die Weboberfläche, die bei git direkt dabei ist.

  • Mantis verwende ich für einige Projekte als Bugtracker. Er lässt sich mit dem Source-Integration-Plugin insoweit mit git verknüpfen, als Commits, die eine Issue-ID referenzieren, mit dem entsprechenden Mantis-Eintrag verknüpft werden bzw. dieser ggf. als erledigt markiert wird. Das ist allerdings in meinem Fall über das Parsing der Webseiten von Gitweb realisiert und geht daher regelmäßig bei jedem größeren Update von Gitweb erst einmal kaputt …

  • Auf der Suche nach einer Foto-Galerie ist mir Piwigo als Alternative zu Gallery ans Herz gelegt worden. Bisher bin ich ganz zufrieden, allerdings nicht der große Fotograf, weshalb ich die Software bisher kaum genutzt habe und daher wenig beitragen kann (das ist alles schon so lange her). Einen Blick ist es aber wert.

  • Für meine Mailman-Mailinglisten gibt es natürlich auch ein Webinterface.

  • phpMyAdmin nutze ich direkt aus der Debian-Paketverwaltung als Weboberfläche für mySQL.

  • Piwik ist das von mir an manchen Stellen genutzte freie Webstatistik-System. Viel Erfahrung habe ich damit noch nicht.

  • Für ältere Webseiten benutze ich teilweise aus historischen Gründen noch awstats, ein Tool zur statistischen Auswertung und Visualisierung von (Webserver-)Logfiles, also quasi die statische Version von Piwik.

Außerdem laufen hier und dort eigene kleinere Entwicklungen, die aber bislang nicht für Dritte verfügbar sind.

Gerne ausprobieren würde ich gelegentlich:

  • TinyTinyRSS als Ersatz für Feedly.
  • Einen URL-Verkürzer.
  • Etherpad.
  • Ob ich Owncloud wirklich brauchen würde, weiß ich nicht.

Und was habt ihr so installiert?

WinSCP und die automatische Synchronisierung

Manche Hilfsmittel sind nicht nur höchst praktisch, sondern auch ganz einfach - wenn man sie denn einmal gefunden oder kennengelernt hat.

Ich arbeite in der Regel auf meinem Desktoprechner wie auf dem Laptop unter Windows; so bearbeite ich auch Webseiten, Webapplikationen oder Scripts, die dann allerdings unter Linux laufen müssen. Ich habe bisher den Aufwand einer kompletten Testumgebung unter Windows gescheut; sicherlich könnte ich, wenn ich wollte, Apache und PHP dort installieren, wahrhscienlich auch MySQL, aber spätestens bei Shell- oder Perl-Scripts wird’s dann schwierig, weil sich manche Operationen, die unter einem Unix durchaus elegant sind, unter Windows so nicht ohne weiteres umsetzen lassen.

Daher übertrage ich während der Arbeit regelmäßig die geänderten Dateien per SCP/SFTP auf einen lokalen oder externen Server und teste sie dort; dieser zusätzliche Arbeitsschritt ist kaum ein Problem. Jedenfalls nicht, so lange man an nur einer Datei arbeitet. Besteht ein Projekt aber, wie so oft, aus einer Vielzahl von untereinander abhängigen Dateien (dem Script, Modulen und Konfigurationsdateien, oder einem Template, Funktionen und CSS-Styles), die zudem jeweils in ihren eigenen Verzeichnissen liegen, ist es recht aufwendig, mal diese, mal jene Datei hochzuladen und vor allem dabei keine zu vergessen. Oft schon habe ich mich darüber geärgert, aber erst kürzlich festgestellt, dass ich mich gar nicht zu ärgern brauche.

“Entferntes Verzeichnis aktuell halten” heißt die wunderbar praktische Funktion.

Der von mir verwendete Client WinSCP bietet nämlich genau für meinen Workflow eine wunderbare Unterstützungsfunktion: er kann nicht nur Verzeichnisse vergleichen oder synchronisieren oder Verzeichniswechsel im lokalen Dateisystem auf dem externen Dateisystem des Servers parallel nachvollziehen - nein, WinSCP kann vor allem ein lokales Verzeichnis dauerhaft überwachen und jede neue oder geänderte Datei sofort hochladen und - auf Wunsch - auch jede lokal gelöschte Datei sofort auf dem Server löschen. Dabei können zudem bestimmte Dateien per vordefinierter Maske vom Abgleich ausgeschlossen werden - bspw. das Verzeichnis .git oder alle Sicherungsdateien *.bak.

Und schon ist ein lästiger Zwischenschritt eliminiert: jede lokal geänderte Datei kann sofort auf dem Server getestet werden. Wunderbar!

Serendipity 2.0.1

Heute wurde das erste kleinere Wartungsupdate von Serendipity veröffentlicht, das (Maintenance-)Release 2.0.1.

Neben einer sicherheitsrelevanten Änderung, deren zugrundeliegende Schwachstelle aber nur durch eingeloggte Autoren ausgenutzt werden konnte, gab es einige kleinere Änderungen vor allem rund um CSS und Javascript.

Die größte Änderung ist allerdings gar nicht das Release selbst, und sie findet sich auch nicht in dem Blog-Post, mit dem das Release angekündigt wurde: das Update kann jetzt automatisch aus dem Admin-Interface erfolgen, wie man das u.a. von Wordpress schon länger kennt. Beim Login wird man - wenn aktiviert - mit einem Hinweis auf das Update begrüßt und kann es auch direkt installieren. Und wie bei Serendipity fast immer: es funktioniert einfach!

Markup-Formate konvertieren

In meiner Reihe “Webdesign anno 2015” habe ich versucht, einen Überblick über Techniken und Tools zu geben, die letztlich jedermann die Gestaltung moderner, gut aussehender Webseiten ermöglichen. Das hatte natürlich einen konkreten Anlass: ich bin dabei, allmählich und sehr langsam - im Rahmen der mir bleibenden zeitlichen Möglichkeiten - verschiedene ältere Webpräsenzen zu überarbeiten und inhaltlich wie optisch und technisch auf den heutigen Stand zu bringen.

Eine große Erleichterung ist dabei die automatische Konvertierung von “klassischem” HTML in HAML und/oder Markdown. Ein machtvolles Werkzeug für solche Konvertierungsaufgaben ist pandoc; es geht aber oft auch eine Nummer kleiner, ganz simpel per cut & paste online:

Wenn nur eine Handvoll Seiten - oder Teile einer Seite - zu konvertieren sind, reicht (mir) das vollständig aus.

Webseiten und Webapplikationen erstellen und pflegen

Viele der in den vergangenen vier Wochen dargestellten Möglichkeiten rund um die Gestaltung von Webangeboten lassen sich ohne größeren technischen Aufwand umsetzen. Will man jedoch Templates einsetzen, andere (vereinfachte) Auszeichnungssprachen wie Markdown in HTML konvertieren oder CSS-Präprozessoren wie LESS oder SASS einsetzen, bedarf es dazu entsprechender Software.

Content Management Systeme (CMS)

In Betracht kommen insoweit - wie schon in meinem einleitenden Übersichtsbeitrag dargestellt - zunächst Content Management Systeme (CMS), die üblicherweise einerseits die Bearbeitung von Vorlagen und Inhalten direkt über das Web ermöglichen und die fertigen Webseiten “dynamisch” beim Aufruf erzeugen. Stattdessen lassen sich auch Blogsysteme oder Wikis verwenden, zumal sich diese teilweise in ihren Funktionen durchaus an CMS annähern.

Beispiele für CMS sind

Eine umfangreiche Übersicht, die allerdings auch Wikis und Blogs enthält, findet sich bspw. in der englischsprachigen Wikipedia.

Static Site Generators

Im Gegensatz zu CMS erzeugen Static Site Generators “statische” HTML-Dateien, die nur bei einer Veränderung neu erzeugt werden müssen. Das ermöglicht natürlich keine Reaktionen auf Benutzereingaben; oft ist solche Interaktion für eine Website aber jenseits eines Kontakt- oder auch Kommentarformulars gar nicht notwendig. Die Belastung für den Webserver ist bei der Auslieferung statischer Seiten natürlich geringer; auch besteht keine Gefahr durch die Ausführung möglicherweise unsicheren Codes. Zudem ist Webspace ohne Scriptsprachen und Datenanbindung oft günstiger zu haben …

Beispiele für Static Site Generators sind

Eine umfangreiche Liste mit fast 400 Static Site Generators, die zudem nach Kriterien wie Lizenz oder Programmiersprache sortiert werden kann, bietet reichliche Auswahl. Alternativ dazu kann man sich eine Aufstellung der beliebtesten Open-Source Static Site Generators zeigen lassen.

Web Application Frameworks

Wo Webseiten vor allem Texte (und Bilder) enthalten, bieten Webapplikationen mehr (oder primär) Interaktion - im Prinzip handelt es sich um Software, die nicht lokal, sondern über das Web läuft. Gekennzeichnet sind sie durch Reaktionen auf Nutzereingaben, die Anbindung von Datenbanken und ihre Dynamik - also das genaue Gegenteil “statischer” Seiten. CMS, Wikis, Blogs und Co. sind Beispiele für Webapplikationen.

Auch und gerade hier gilt natürlich, dass nicht nur Struktur (HTML) und optische Repräsentation (CSS), sondern auch Ausgabe bzw. Darstellung (Template) und die dahinterstehende Programmlogik strikt voneinander getrennt werden sollten: Model–view–controller (MVC) ist das Stichwort. Das Äquivalent zu CMS und Static Site Generators für Webapplikationen wären Web Application Frameworks, die in der Regel Templates (“Views”) mit Daten(bank)modellen (“Models”) und der entsprechenden Ablaufsteuerung (“Controllers”), also der eigentlichen Programmlogik, verbinden.

Gerne würde ich mich auch damit näher beschäftigen - bisher fehlte mir aber die Zeit und Gelegenheit, in dieser Richtung mehr zu unternehmen als mich zu belesen. Interessant klingen insoweit im Bereich der PHP-basierten Frameworks bspw.

Abschließend daher nun die Frage: Kennt sich jemand unter den Lesern mit einem dieser Frameworks (oder überhaupt mit Frameworks auf PHP-Basis) aus, kann Erfahrungen teilen oder Empfehlungen geben? Ich würde mich freuen!

Dieser Beitrag gehört zur Reihe “Webdesign anno 2015”.

Wie man verlorene Adobe-Seriennummern wiederfindet

Die Idee, für eine hier vorhandene Version von Adobe Acrobat nach einigen Jahren einmal ein Update auf die aktuelle Version zu kaufen, erscheint gar nicht schlecht (auch wenn man sich über die Preispolitik leicht wundern darf - der Preis in EUR ist deutlich höher als in US-$).

Schön also, dass es eine günstigere Update-Version gibt, die gegenüber der Vollversion deutlich Geld spart. Blöd allerdings, wenn man - Ordnung muss sein! - vor dem Installieren der Update-Version die zum Update berechtigende Vorversion schon gelöscht hat. Hält alles schon ordentlich, führt aber natürlich zum Fehlschlagen der Update-Prüfung.

Kein Problem: man muss ja nur die Seriennummer der alten Version eingeben. Wenn man die allerdings nicht wiederfindet und sie auch nicht online bei Adobe registriert ist, warum auch immer … ist das eher schlecht.

Vorausgesetzt, man hat jetzt wenigstens noch ein Backup, das zeitlich vor der Deinstallation liegt, ist aber immer noch nicht aller Tage Abend. Falls also noch einmal jemand außer mir vor dem Problem steht, die Seriennummer einer Adobe-Acrobat-Installation aus einem Backup auszulesen, seien ihm folgende Schritte ans Herz gelegt:

  1. Im Backup das Verzeichnis \Program Files (x86)\Common Files\Adobe\Adobe PCD\cache suchen.

  2. Die dort vorhandene Datei cache.db mit einem Leseprogramm für SQLite-Dateien öffnen, bspw. dem DB Browser for SQLite. Die Seriennummer findet sich dort in codierter Form im Datenfeld SN.

  3. Die Seriennummer konvertieren, bspw. via Adobe Serial Algorithm.

Ich buche das jetzt alles unter der Überschrift “wenn man mal eben schnell vor dem Zubettgehen noch etwas ausprobieren will” ab, bedanke mich herzlich beim Autor von How Do I Find My Adobe Acrobat Serial Number? und mache mich nunmehr (einige Stunden verspätet) auf die Suche nach meinem Schönheitsschlaf.

Templates und Template Engines

HTML und CSS, Frameworks wie Bootstrap, Web- und Iconfonts, LESS oder SASS bieten viele Möglichkeiten zur Gestaltung standardkonformer, gut lesbarer und auf verschiedenen Endgeräten nett anzusehender Webseiten. Eine größere Webpräsenz komplett “von Hand” zu pflegen macht allerdings wenig Spaß - und ist auch alles andere als professionell oder eine gute Idee.

Denn regelmäßig ist eine Website oder auch eine Webapplikation gekennzeichnet durch ein “Grundkorsett”, das mit wechselnden Inhalten gefüllt wird. So wird sich meist ein einheitliches Gestaltungskonzept mit Kopf- und/oder Fußzeile, mit einer oder mehreren Spalten und einer Navigation auf allen Seiten wiederfinden. Dieses Grundgerüst der ganzen Webpräsenz sollte sich dann nicht per copy & paste auf jeder Einzelseite wiederholen, sondern vielmehr in Form einer Vorlage, eines Templates, vorliegen, um dann jeweils mit spezifischen Inhalten gefüllt zu werden. Auch ist es - gerade bei Webapplikationen - sinnvoll, die “Technik” von der “Darstellung” zu trennen, damit Änderungen am Design nicht zwingend Änderungen an der Programmierung erfordern und umgekehrt. (Und, natürlich, damit verschiedene Teams an der optischen Darstellung der Seiten und der dahinterstehenden Programmlogik arbeiten können).

Auf diese Art und Weise arbeiten bspw. Blogsysteme wie Wordpress (mit eigenen Template-Funktionen) oder Serendipity (wo das Template-System Smarty genutzt wird) und natürlich auch Content Management Systeme (CMS) oder static site generators.

Das Prinzip ist immer gleich: ein Grundgerüst und mögliche Inhalte werden getrennt definiert, wobei das Grundgerüst oft aus einer HTML-Datei besteht. In dieser (HTML-) Datei können Platzhalter (Variablen) durch passenden Text ersetzt und andere Dateien eingebunden werden, Codefragmente (in einer Programmiersprache wie Perl, PHP, Python oder Ruby und/oder in einer speziellen Template-Sprache) eingebaut und/oder sogar statt HTML andere Auszeichnungssprachen verwendet werden. Das kann “dynamisch” bei jedem Aufruf der Seite erfolgen, ggf. mit Caching, oder die Webseiten können einmal aus ihren Quelltexten generiert werden und dann “statisch” online gestellt - und nur bei Änderungen aktualisiert - werden.

"Templates und Template Engines" vollständig lesen

Installation von nanoc unter Windwows 7

Über nanoc, einen Generator für statische Webseiten, hatte ich hier im Blog bereits berichtet. Bislang nutze ich ihn auf verschiedenen Linux-Maschinen ohne Probleme, wollte ihn aber nunmehr auch auf meinem Laptop unter Windows 7 installieren, um auch ohne Netzanbindung das eine oder andere ausprobieren zu können.

Installationsanleitung

Ausgehend von einer über Google gefundenen Anleitung gestaltet sich die grundsätzliche Installation unter Windows überraschend einfach und problemlos:

  • Zunächst benötigt man Ruby - dankenswerterweise gibt es dafür einen Windows-Installer zum Download. Empfohlen wird derzeit Ruby 1.9.3.

    • Bei der Installation sollten die Optionen Add Ruby executables to your PATH und Associate .rb and .rbw files with this Ruby installation ausgewählt werden. Ggf. wird ein Reboot erforderlich.
    • Testen lässt sich die Installation bspw. durch den Aufruf des interaktiven Interpreters mit irb (verlassen wird er mit quit) und durch den Aufruf von gem --version, um zu testen, ob auch der Paketmanager RubyGems installiert und lauffähig ist.
  • nanoc selbst wird dann einfach vermittels gem install nanoc installiert. Das funktionierte bei mir erfreulicherweise ohne jedes Problem; auch der Aufruf war sofort möglich.

  • Die Installation von Win32::Console verbessert ggf. die Darstellung und kann ebenso einfach mit gem install win32console erfolgen.

  • Fehlt zum Abschluss noch ein integrierter Webserver, falls man einen solchen nicht bereits zur Verfügung hat: gem install adsf ermöglicht es, die generierte Webpräsenz mittels nanoc view unter http::/localhost:3000 anzuschauen.

  • Nutzt man weitere Filter und Funktionen wie kramdown oder ähnliches, sind die entsprechenden Gems nachzuinstallieren. Gebräuchlich mag bspw. gem install kramdown haml rubypants sein.

So weit, so gut. Endlich mal ein Fall, wo die Installation eher “unixoider” Software unter Windows ohne größere Probleme funktioniert, könnte man denken.

Und dann kam LESS.

"Installation von nanoc unter Windwows 7" vollständig lesen

Serendipity 2.0

Was lange währt, wird wirklich gut.

Nach dem zweiten Release-Candidate ist nun Serendipity 2.0 released und hier für dieses Blog installiert, wo sich im Dreivierteljahr seit dem Relaunch auch die Beta-Versionen schon bewährt haben.

Was andere dazu sagen

[Dieser Eintrag wurde nachträglich um weitere Beiträge in anderen Blogs ergänzt.]

LESS, SASS und Co.

LESS? SASS? Hä?

LESS und SASS (Syntactically Awesome Stylesheets) sind CSS-Präprozessoren; man könnte sie vielleicht auch als CSS-Compiler bezeichnen. Sie erzeugen aus einer CSS-ähnlichen, aber mächtigeren Sprache gültige CSS-Dateien, konzeptionell entfernt ähnlich der Art und Weise, in der bspw. PHP und andere in der Webentwicklung verwendete Scriptsprachen HTML erzeugen.

Wenn man ein einheitliches Design für seine Webseiten erstellen möchte, ist es oft wichtig, dass die einzelnen Elemente aufeinander abgestimmt sind. So sollten sich bspw. Schriftgrößen von Text und Überschriften miteinander harmonieren, vielleicht finden sich auch bestimmte charakteristische Farbelemente, die das Seitendesign prägen. Wäre es nicht schön, wenn man mit wenig Aufwand Änderungen an allen notwendigen Stellen vornehmen könnte, also bspw. die bisher verwendete Farbe x überall durch die Farbe y ersetzen? Oder die Schriftgröße des Fließtextes erhöhnen und dabei die Schriftgröße von Überschriften und anderen, besonderen Elementen proportional ändern? Das und mehr geht mit LESS und SASS.

Sowohl LESS als auch SASS sind notwendiger oder ergänzender Bestandteil der von mir bereits vorgestellten Frontend-Frameworks und für diejenigen, die damit umgehen können, fraglos ein wichtiger Bestandteil zeitgemäßer Webentwicklung.

(Ich zähle mich allerdings nur sehr bedingt zu diesem Personenkreis, weshalb dieser Überblicksartikel ein gewisses Wagnis darstellt - ich erzähle hier mehr oder weniger als Blinder von der Farbe).

LESS

LESS bietet die Möglichkeit, Variablen zu definieren - bspw. eine bestimmte Farbe - und diese Variablen dann in CSS-Definitionen zu verwenden. Ändert man die Variable, ändern sich - nach der Neucompilierung - alle damit verbundenen Definitionen.

Mixins heben dieses Konzept auf eine neue Ebene: sie ermöglichen es, ganze CSS-Definitionen in andere Definitionen zu importieren und dabei ggf. noch Parameter zu übergeben. Auch hier gilt natürlich wieder: ändert man das Mixin, ändern sich alle Defitionen, die es importieren.

Darüber hinaus erlaubt LESS den Einsatz von Funktionen und Operatoren. So kann bspw. eine bestimmte Schriftgröße für den Fließtext vorgegeben und dann definiert werden, dass die Überschriftenebene <h6> genau so groß, aber fettgedruckt sein soll, die Überschriftenebene <h5> aber 1.1x so groß und die Ebene <h1> 2x so groß. Farben können als “10% heller” (oder dunkler, oder satter, oder …) als eine andere Farbe definiert werden, ohne dasss dies jeweils manuell in Farbwerten berechnet werden müsste - und ändert man die zur Grundlage genommene Farbe, ändern sich auch die anderen, daraus “berechneten” Farben automatisch mit!

Schließlich bietet LESS die Möglichkeit, CSS-Definitionen ineinander zu verschachteln, also bspw. zunächst grundsätzliche Eigenschaften einer Klasse und dann bestimmter Elemente dieser Klasse zu definieren.

Wem das alles zu trocken klingt, der findet auf LESScss.de eine Erläuterung mit Beispielen, die vollständige Dokumentation, Downloadmöglichkeiten und mehr in deutscher Sprache.

SASS

Für SASS … gilt im Prinzip dasselbe, was ich zuvor bereits gesagt habe; nur habe ich SASS bisher nicht selbst ausprobiert. :-)

Mehr zu SASS gibt es (in englischer Sprache) auf SASS-lang.com, einen Vergleich der beiden Sprachen (Stand 2012) bspw. bei CSS-Tricks.

Würde ich mehr davon verstehen, könnte ich sicherlich auch die bestehenden Unterschiede, Vorteile und Nachteile der beiden Sprachen darstellen; insoweit muss ich leider passen und freue mich auf die Ergänzungen und Richtigstellungen in den Kommentaren.

Dieser Beitrag gehört zur Reihe “Webdesign anno 2015”.

[Dieser Eintrag wurde nachträglich im Februar 2015 veröffentlicht.]

Webfonts und Iconfonts

Webseiten vermitteln in der Regel Informationen und bestehen daher auch - im Regelfall sogar: weit überwiegend - aus Text. Text, der möglichst angenehm zu lesen sein soll, und dabei am besten noch gut aussehen. Zu bedenken sind daher die Auswahl einer geeigneten Schriftgröße, ein passender Zeilenabstand und eine lesefreundliche Zeilenlänge - aber auch eine gut lesbare und “schöne” Schriftart. Die Zeiten von “Serifenschrift, alternativ serifenloser Schrift auf weißem Hintergrund” sollten im Jahr 2015 eigentlich vorbei sein, gibt es doch genügend Auswahl.

Allerdings: es genügt - wie immer - nicht, einfach eine hübsche Schrift auszuwählen und dann auf dem eigenen Rechner zu testen, wie die Seite damit aussieht, denn der Browser greift bei der Schriftdarstellung auf die Schriften zurück, die ihm das System zur Verfügung stellen kann. Ist eine Schrift lokal nicht verfügbar, wird stattdessen eine - hoffentlich angegebene - (generischere) Alternative verwendet:

 font-family: Verdana, Arial, Helvetica, sans-serif;

Das kann dann immer noch ungefähr so aussehen, wie man sich das vorstellt … oder eben auch nicht.

Webfonts

Eine alternative Vorgehensweise bieten “Webfonts” - seit CSS 2 kann nämlich eine Schriftart via @font-face (Erläuterung) eingebunden bzw. nachgeladen werden. Das hat den Nachteil eines (zumeist nur leicht) verzögerten Aufbaus der Seite und - gerade bei langsamen, ggf. mobilen Verbindungen - eines (merklich) größeren Donwload-Volumens, aber den Vorteil, dass eine große Auswahl tatsächlich überall verfügbarer Schriften bereitsteht.

Als Quelle bietet sich zunächst Google Fonts an, wo Google über 600 Schriftarten in allen Variationen zur freien Verfügung bereitstellt. Wem das nicht genügt, der kann auf kostenlose Alternativen wie Fontsquirrel oder kostenpflichtige Angebote zurückgreifen, bspw. von Typekit aus dem Hause Adobe, von fonts.com aus dem Hause Monotype oder von MyFonts.

In jedem Fall sollte man nicht übersehen, dass zumeist verschiedene Schriftschnitte benötigt werden, also unterschiedliche Schriftstärken (mager, normal, halbfett, fett), Schriftlagen (normal, kursiv) oder auch Schriftbreiten (schmal, normal, weit). Daher muss man bei kostenlosen Anbietern wie Google Fonts das Einbinden aller benötigten Schriftschnitte bedenken und vor allem bei kostenpflichtigen Anbietern prüfen, ob der angegebene Preis auch alle erwünschten oder erforderlichen Schriftschnitte umfasst.

"Webfonts und Iconfonts" vollständig lesen
tweetbackcheck