Nutzung von Sass (SCSS) in TYPO3-Projekten

TYPO3 & Sass (SCSS)

Möchte man die CSS-Coding-Effizienz steigern, dann kommt man um Sass kaum herum.  Da SCSS vom Browser jedoch nicht direkt interpretiert werden kann, muss ein Compiler zwischengeschaltet werden, der den SCSS-Input in den gewünschten CSS-Output für TYPO3 verwandelt. So kann man für Responsive Webdesign-Templates z.B. mit Bootstrap auf die SCSS Quelldateien zurückgreifen.

Was ist Sass (SCSS)?

Einfach gesagt ist Sass eine Funktionserweiterung für CSS, die es dem Benutzer durch Variablen und Funktionen wie z.B. Nesting ermöglicht, effizienter zu arbeiten.

SCSS-Input Beispiel:
$font-stack:    Helvetica, sans-serif;
$primary-color: #333;

body {
  font: 100% $font-stack;
  color: $primary-color;
}
CSS-Output Beispiel:
body {
  font: 100% Helvetica, sans-serif;
  color: #333;
}

 

Wie kann ich Sass (SCSS) in TYPO3 nutzen?

Wir haben uns damit beschäftigt, einen Weg zu finden, Sass (SCSS) in unseren TYPO3-Workflow zu integrieren. Dabei haben wir verschiedene Ansätze untersucht:

  1. SCSS wird direkt in der IDE über „Ruby On Rails“ kompiliert und wir integrieren die fertigen CSS Dateien in unser TYPO3-Projekt.
  2. Wir nutzen die „Sass.js API“, um SCSS-Dateien clientseitig in CSS-Code zu verwandeln.
  3. Über die TYPO3-Extension „DynCss“ ist es möglich, SCSS-Dateien serverseitig zu kompilieren und das Ergebnis direkt ins Projekt zu integrieren.
1. SCSS wird direkt in der IDE verarbeitet

Viele IDEs bieten die Möglichkeit, einen Sass-Compiler für SCSS anzuknüpfen. Dazu muss eine „Ruby on Rails“ geschaffen werden, wo der Sass-Compiler den SCSS-Code direkt in CSS verwandelt und anschließend in eine entsprechende Datei schreibt. Eine Anleitung, wie Sie die Umgebung installieren können, finden Sie hier: http://sass-lang.com/install

Der Vorteil dieser Methode ist, dass ausschließlich fertige Dateien in das TYPO3-Projekt eingespielt werden, die Performance so nicht darunter leidet und man stets die volle Kontrolle über die Art und Weise der Kompilierung hat.

Der Nachteil ist, dass man für die Entwicklung von einer bestimmten Arbeitsumgebung abhängig ist, welche auf allen Arbeitsrechnern gleich sein muss, um Fehler zu vermeiden und einen flüssigen Ablauf zu ermöglichen.

2. Nutzen der „Sass.js API“

Bei dieser Methode werden die SCSS-Dateien direkt in das TYPO3-Projekt eingebunden. Zusätzlich wird die „Sass.js API“ genutzt, um die Dateien clientseitig in CSS-Code zu verwandeln und somit für den Browser lesbar zu machen.

Der Vorteil dieser Methode ist, dass die Kompilierung direkt im TYPO3-Projekt erfolgt und somit unabhängig von der Arbeitsumgebung ist. So können Korrekturen schnell und sogar direkt über das TYPO3-Backend vorgenommen werden.

Der Nachteil ist, dass das JavaScript zusätzliche Ressourcen für die Kompilierung benötigt. Bei größeren Projekten, welche ohnehin schon viele Skripte benötigen, ist von dieser Methode abzuraten. Zusätzlich kommt es zu Darstellungsproblemen, sollte der Benutzer das Ausführen von JavaScript unterbinden.

3. Die TYPO3-Extension DynCss (dyncss) mit DynCss – SCSS Parser (dyncss_scss)

Diese TYPO3-Extension nutzt die PHP-basierte „SCSSPHP“-Bibliothek als Compiler und funktioniert serverseitig. Über TypoScript werden alle SCSS-Dateien und die Verarbeitungsoptionen definiert. Als Ergebnis werden CSS-Dateien generiert und in das Frontend übergeben. Dies funktioniert ebenfalls mit LESS.

Der Vorteil dieser Methode ist, dass man hier eine Lösung direkt im TYPO3-Projekt hat, welche keine besonderen Performance-Einbußen verursacht. Die fertigen SCSS-Dateien werden, wie von CSS-Dateien gewohnt, direkt in das Projekt integriert und von der Extension verarbeitet und ausgegeben.

Der einzige Nachteil ist, dass kein Sass verarbeitet wird, sondern nur SCSS oder LESS.

Fazit

Die „Sass.js API“ kommt für uns als JavaScript-basierte Lösung nicht in Frage.
Da wir alle TYPO3-Projeke teambasiert bearbeiten und deshalb auf 100%ige Kompatibilität angewiesen sind, haben wir von Variante 1 Abstand genommen.

Für uns ist die Variante 3 die praktikabelste, so können wir mit SCSS entwickeln und die Extension übernimmt die Kompilierung dort wo diese benötigt wird. Die Performance auf dem von uns getesteten System ist gut und ob dies auch beim realen Projekt so bleibt, wird sich im Praxistest zeigen.

Weiterführende Links

Sass: Syntactically Awesome Style Sheets
Ruby On Rails
Sass.js API
TYPO3-Extension DynCss
TYPO3-Extension DynCss – SCSS Parser
SCSSPHP-Bibliothek

2 Kommentare Schreibe einen Kommentar

  1. Kann es sein das im Fazit von der Variante 3 als praktikabelste Lösung gesprochen wird ?
    Immerhin wird im ersten Satz JavaScript schon ausgeschlossen!

    Gibt es mittlerweile funktionale Varianten für Sass? Scss ist zwar nur unwesentlich mehr Schreibarbeit aber Sass von mir dennoch bevorzugt.

    Antworten

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.