Gedanken zur Vorverarbeitung

Ich habe in letzter Zeit so ziemlich alles, was ich mache, mit Sass erstellt. Hier sind ein paar Gedanken zu dieser Reise. Von Hindernissen über Stolpersteine bis hin zu Ablehnung. Von Apps und Teams bis hin zu Workflows und Syntax.

Du musst lokal arbeiten

Der wichtigste Grund, warum ich auf den Zug aufgesprungen bin, war, dass ich meine Angewohnheit, live per FTP zu bearbeiten, aufgegeben habe. Ja, Coda ist großartig, aber es führt zu schlechten Angewohnheiten. Es macht es viel zu einfach, live statt lokal zu arbeiten¹.

Lokal zu arbeiten hat offensichtliche Vorteile. Nämlich: 1) Es ist schnell. 2) Du kannst nach Herzenslust Dinge bearbeiten, ohne dir Sorgen zu machen, dass du eine Live-Seite kaputt machst. 3) Es ermöglicht dir, effektiv in einem Team über Versionskontrolle zu arbeiten (dazu später mehr).

Also mach es einfach. Wenn du nur an statischen Seiten arbeitest, kannst du einfach damit anfangen. Arbeite von einem Ordner auf deinem Computer aus. Wenn du an PHP-Seiten arbeitest (z. B. WordPress, Joomla, PHP, Vanilla, CodeIgniter, CakePHP und eine Million weitere), ist die Verwendung von MAMP (mein Screencast) ideal. Natürlich gibt es Varianten von MAMP für alle Plattformen.

Wenn du etwas wie Ruby oder Python verwendest, weißt du wahrscheinlich sowieso, wie man so etwas einrichtet, also bist du auf der sicheren Seite.

Jetzt, da ich hauptsächlich an Projekten arbeite, die auf meinem lokalen Rechner laufen, ist die Verwendung von Präprozessoren einfach. Ich verwende ein paar fantastische Apps, auf die ich später eingehen werde.

Kommandozeile bla bla bla

Ich bin Designer! Ich weiß nicht, wie man die Kommandozeile benutzt, und ich sollte es auch nicht müssen.

Das hört man sehr oft in Bezug auf SASS. Hier ist die Sache: Ich bin ganz bei dir. Ich hasse die Kommandozeile. Du musst sie nicht benutzen. Ich tue es, fast nie, für nichts².

Andere Ablehnungsgründe

So kindisch das auch erscheinen mag, ein weiterer Grund, warum ich so lange gebraucht habe, um auf den Präprozessor-Zug aufzuspringen, war die Community. Und ich bin nicht allein damit.

Mann, normalerweise atmet man nur über Präprozessoren und CSS, und die LESS/SASS-Leute stürzen sich mit Windhundgeschwindigkeit auf einen.

— Eric A. Meyer (@meyerweb) 26. Januar 2012

Es ist schwer, überhaupt etwas über Präprozessoren zu sagen, geschweige denn etwas vage Negatives, ohne angegriffen zu werden.

Lange Zeit dachte ich: Ich schreibe jeden Tag CSS. Ich kenne CSS ziemlich gut. Mein Workflow ist in Ordnung. Ich bin produktiv. Warum muss sich etwas ändern?

Die wahre Antwort ist, dass sich nichts ändern muss, wenn du es nicht willst. Wenn du mit dem, was du tust, vollkommen zufrieden bist: viel Erfolg.

Ich kann dir sagen, dass ich, nachdem ich den Sprung gewagt habe, tatsächlich produktiver bin. Und ich schreibe besseres CSS. Und die Projekte, an denen ich arbeite, sind dadurch in einem besseren, wartbareren Zustand. Und in manchen Fällen schneller³. Mein Rat ist: Lass dich nicht beirren. Mach einfach dein Ding. Wenn du Zeit hast, probiere es aus. Und probiere es an einem echten Projekt aus. Nur ein bisschen herumprobieren zählt nicht. Du musst es wirklich ausprobieren, um zu sehen, wie es mit deinem Alltag funktionieren könnte.

Die Apps

Ich habe nur Erfahrung mit Mac-Apps. Tut mir leid. Ich bin sicher, es gibt auch gute für andere Plattformen.

Die App, mit der ich all diese Präprozessor-Vorteile kennengelernt habe, war LiveReload (Screencast). Ich bin immer noch ein Fan. Es ist jetzt im App Store für 9,99 $ erhältlich. Es ist eine Menüleisten-App, bei der ein Klick auf das Symbol in der Menüleiste ein Fenster mit Optionen öffnet.

Du sagst LiveReload, dass es einen bestimmten Ordner überwachen soll. Wenn sich eine Datei in diesem Ordner ändert, wird die Vorverarbeitung ausgelöst. Es kann eine ganze Reihe von Präprozessoren verarbeiten. Für CSS: LESS, SASS (mit Compass) oder Stylus. Für JavaScript: CoffeeScript oder IcedCoffeeScript. Für HTML: HAML, Jade, Slim oder Eco.

Nachdem es vorverarbeitet wurde, wird die Seite in dem/den Browser(n) neu geladen, in dem/denen du die Browser-Erweiterungen installiert hast. Wenn du nur CSS geändert hast, fügt es die Stile ohne eine Seitenaktualisierung in die Seite ein. Das ist besonders nützlich, wenn du etwas auf einer Seite in einem bestimmten Zustand gestaltest. Nehmen wir an, ein Klick öffnet ein Dialogfeld, und du versuchst, dieses Dialogfeld zu gestalten. Mit LiveReload kannst du dieses Dialogfeld geöffnet lassen, und die neu eingefügten Stile wirken sich darauf aus, was bedeutet, dass du nicht viel Zeit mit Klicken und erneutem Klicken verschwendest.

Aber ich bin kürzlich zu CodeKit gewechselt. Die Benutzeroberfläche von CodeKit ist schöner, hat mehr Funktionen (z. B. Bildoptimierung, JS-Verkettung) und weniger seltsame Einschränkungen (du wählst, ob Dateien vorverarbeitet werden und wohin sie gehen, im Gegensatz zu LiveReload, wo du sie einmal importierst und sie dann nie wieder kompilieren kannst). Das Einzige, was ich vermisse, ist die Fähigkeit von LiveReload, CSS einzufügen, ohne die Seite neu zu laden, eine nützliche Funktion für Websites mit komplexen Zuständen, die mehrere Schritte erfordern, um die Seite nach einem Neuladen wieder in diesen Zustand zu versetzen. Update April 2012: CodeKit führt jetzt Live-Injektion von CSS durch.

Es gibt jedoch ein paar Dinge, die mir an LiveReload nicht gefallen. Eines ist der Bildschirm, auf dem man die Ausgabepfade für den kompilierten Quellcode festlegt.

Bemerke die ausgegrauten Felder? Es versucht, schlau zu sein und bemerkt, dass du diese Datei anderswo eingefügt hast. Daher wird sie nicht kompiliert. Aber was ist, wenn du sie aus einem anderen Grund kompilieren möchtest? Pech gehabt, keine Möglichkeit, das zu tun. Es ist einfach keine großartige Benutzeroberfläche und der Einstieg kann etwas schwierig sein.

Und hier kommt CodeKit ins Spiel. CodeKit hat eine wunderschöne Benutzeroberfläche.

Es ist sehr einfach, die Dateipfade zu ändern, wohin Dateien kompiliert werden. Und ich musste es nie anlernen, es scheint die Verzeichnisstruktur zu erkennen und auf Anhieb richtig zu verstehen. Es werden auch Dateien ausgegraut, die eingefügt sind, aber du kannst das einfach ein- und ausschalten.

CodeKit ist auf LESS, Sass, Stylus, CoffeeScript und HAML beschränkt. Das fand ich etwas einschränkend, da ich Jade verwendet habe, um HTML in einigen Projekten vorzuverarbeiten. Jade ist in der Lage, HTML-Includes zu verwenden, was enorm nützlich sein kann.

Die Fehlerberichterstattung in CodeKit ist sehr gut. Es ist klar, was los ist, und es fühlt sich gut an, wenn man es behoben hat.

Im Gegensatz dazu schiebt sich bei LiveReload ein kleines Fenster von oben rechts auf deinem Bildschirm herunter, mit schlecht abgeschnittenem Text und ohne Schließen-Button, und schiebt sich einfach wieder weg, sobald du den Fehler behoben hast.

CodeKit kann auch die Stileinfügung, die LiveReload kann, nicht durchführen. So denkt der Entwickler darüber

@chriscoyier Ich bin unschlüssig. Es hat etwas Beruhigendes, EINE Aktualisierung geschehen zu sehen.

— Bryan Jones (@bdkjones) 6. Februar 2012

Update: CodeKit führt jetzt Live-Injektion durch.

Letztendlich denke ich, dass CodeKit im Moment mein Favorit ist. Was es herausstechen lässt, sind all die zusätzlichen Funktionen. Es kann automatisch CSS segnen. Es kann JavaScript verketten und minifizieren. Es kann dir sagen, welche Dateien eine andere bestimmte Datei importieren. Und vielleicht mein Favorit: Es kann Bilder mit einem Klick optimieren.

Teams

Ein weiteres mögliches Hindernis beim Umstieg auf Präprozessoren: die Arbeit im Team. Insbesondere ein Team, in dem mehrere Personen dieselben CSS-Dateien bearbeiten wie du. In diesem Fall müssen all diese Personen mit derselben Präprozessor-App eingerichtet werden, die du verwendest (du könntest verschiedene verwenden, das ist in Ordnung. Am besten, sie verwenden alle dieselben Kernversionen des Präprozessors). Du kannst nicht zulassen, dass einige Leute die .css-Dateien bearbeiten und andere die .scss-Dateien. Diese Änderungen an den .css-Dateien werden einfach überschrieben, wenn jemand das nächste Mal kompiliert und committet. Präprozessoren sind in dieser Hinsicht unerbittlich. Sie sagen nicht: "Hey, es sieht so aus, als ob diese .css-Datei anders ist als beim letzten Kompilieren, möchtest du dir das zuerst ansehen?" Nein, sie schreiben einfach darüber.

Es ist jedoch machbar. Innerhalb kurzer Zeit haben wir Wufoo komplett auf SASS umgestellt. Genauer gesagt, wir haben einen Teil auf LESS umgestellt, dann einen Teil auf Stylus und dann alles auf SASS. Puh. Lob dafür an Kevin. Wir verwenden auch bei allen Neuentwicklungen von SurveyMonkey ein großes Set von Design Patterns, die alle SASS verwenden.

Wenn jemand Teamstrategien für Präprozessoren hat, wäre das wertvoll zu teilen!

Compass

Ich bin mir sicher, dass es Leute gibt, die verärgert sind, weil ich Compass nicht verwende. Ich weiß, ich weiß. Ich sollte es tun. Aber offensichtlich bin ich langsam bei diesen Dingen. Ich möchte Dinge so tief wie möglich verstehen, bevor ich weitermache, und Compass ist mir immer noch ein bisschen zu schick. Wenn jemand keine Ahnung hat, was Compass ist: Es ist ein großes Set von Add-Ons für SASS. Das bedeutet im Wesentlichen, dass du Dinge, die du wahrscheinlich Projekt für Projekt auf die gleiche Weise schreiben müsstest, nicht selbst schreiben musst. CSS3-Mixins, Grid-Helfer, Sprite-Helfer, Dateipfad-Helfer und vieles mehr.

Mein Problem ist, dass ich noch nicht bereit bin, all diese Dinge abzugeben. Ich möchte meine eigenen schreiben. Ich bin mir sicher, der Tag wird kommen, an dem ich das aufgebe, aber er ist noch nicht gekommen.

Kleine Dinge, die mich ins Stolpern gebracht haben

Dieser Artikel begann mit diesem Titel, bevor er sich zu all dem hier ausweitete. Aber was soll's, ich dachte, ich nehme diese kleinen Anekdoten trotzdem mit auf, die mir beim Lernen ein paar Momente der Verzweiflung beschert haben.

Da ich meine eigenen CSS3-Mixins schreibe, habe ich vielleicht ein Mixin für box-shadow wie dieses

@mixin drop-shadow ($x: 1px, $y: 1px, $blur: 2px, $spread: 0, $alpha: 0.25) {
  -webkit-box-shadow: $x $y $blur $spread rgba(0, 0, 0, $alpha);
  -moz-box-shadow:    $x $y $blur $spread rgba(0, 0, 0, $alpha);
  box-shadow:         $x $y $blur $spread rgba(0, 0, 0, $alpha);
}

Es ist voll von sinnvollen Standardeinstellungen, sodass die Standardverwendung einfach so aussehen kann

.module {
  @include drop-shadow();
}

Oder wenn ich spezifischer werden möchte, kann ich jeden Teil angeben

.module {
  @include drop-shadow(5px, 5px, 2px, -2px, 0.5);
}

Aber was, wenn ich mehrere box-shadows machen möchte? Dieses Mixin ist dafür nicht bereit. Für diese Fälle bereite ich auch super generische Mixins vor, die den Spezifikationsnamen haben

@mixin box-shadow ($string) {
  -webkit-box-shadow: $string;
  -moz-box-shadow:    $string;
  box-shadow:         $string;
}

Dieses nimmt nur einen einzigen Parameter, alles, was ich ihm geben möchte. Die Verwendung könnte also so aussehen

/* Bad! doesn't work! */
.stack {
   @include box-shadow(
        1px 1px   0 rgba(0,   0,   0,   0.100),
        3px 3px   0 rgba(255, 255, 255, 1.0),
        4px 4px   0 rgba(0,   0,   0,   0.125)
   );
}

Aber das funktioniert nicht. All diese Kommas darin verwirren SASS. Es wird denken, dass du versuchst, mehrere Parameter an ein Mixin zu übergeben, das nur für einen eingerichtet ist. Du kannst auch nicht einfach Anführungszeichen um den Wert setzen, den du übergeben möchtest, das funktioniert nicht. Die Antwort ist, die Technik mit den doppelten Klammern zu verwenden

@include box-shadow(( whatever, you, want, just, one, param ));

Eine weitere Sache, die mich durcheinander gebracht hat, war der Versuch, Variablen innerhalb von Werten zu verwenden, wobei die Variable nur ein Teil des Wertes war. Im Grunde sind Variablen super einfach

$red: #F00;

.red {
   color: $red;
}

Aber ich habe versucht, dies zu tun

$path: "/images/";

body {             /* Bad! No! */
   background: url($path + texture.jpg);
}

Damit das funktioniert, musst du die Hash-/Klammer-Methode verwenden

$path: "/images/";

body {
   background: url(#{$path}texture.jpg);
}

// or

body {
   background: url($path + "texture.jpg");
}

Und noch eine letzte Kleinigkeit, die verwirrend sein könnte. Das Zeichen & hat eine besondere Bedeutung beim Verschachteln. Es entspricht dem Selektor bis zu diesem Punkt. Zum Beispiel

a {
  color: red;
  &:hover {
    color: pink;
  }
}

wird zu

a { 
  color: red;
}
a:hover {
  color: pink;
}

Du hast wahrscheinlich schon Beispiele wie dieses gesehen. Bei einfachen Beispielen wie diesem kommt es nicht ganz zur Geltung, aber ob du es glaubst oder nicht, Verschachtelung fühlt sich sehr schnell natürlich an und du wirst es lieben.

Aber zurück zu diesem &-Zeichen.

Du musst nicht dies tun

.module {
   & h3 {
   }
   & p { 
   }
}

Das ist durch die Verschachtelung impliziert, du brauchst das & dort nicht zu verwenden. Du brauchst es nur, wenn es kein Nachfahren-Selektor (Leerstelle) sein soll. Es kann besonders sexy werden, wenn du das & später im Selektor verwendest. Zum Beispiel, wenn du Modernizr verwendest, um nach mehreren Hintergründen zu suchen

body {
  .multiplebgs & {
  }
  .no-multiplebgs & {
  }
}

Das gibt dir eine wirklich saubere Verzweigung, wie du mit der Situation der Unterstützung und Nicht-Unterstützung umgehen möchtest, während der Code logisch innerhalb der body { } Anweisung verschachtelt bleibt.

Dieser verdammte FTP-Workflow

Selbst wenn ich dich davon überzeugt habe, lokal zu arbeiten, Versionskontrolle zu verwenden und Präprozessoren zu nutzen, bleibt immer noch das Problem der Bereitstellung. Dein Workflow könnte tatsächlich einen Schritt zurück in der Effizienz machen, wenn du vom Live-Bearbeiten zum lokalen Arbeiten übergehst, und wenn du live gehen möchtest, musst du geänderte Dateien manuell auf den Server hochladen. Ich fürchte, ich habe keine großartige Antwort für dich.

Nettuts hat es mit „The Perfect Workflow“ behandelt, aber das basiert auf einem GitHub Post-Commit Hook, der eine PHP-Datei trifft, die `git pull`s, was auf keinem Server funktioniert, auf den ich Zugriff habe, und es ist selten, dass ein Shared Host das überhaupt zulässt, wie ich das verstehe.

Hier glänzt App-basiertes Cloud-Hosting wirklich. Apps wie Heroku für Ruby oder PHPFog für PHP fügen sich nahtlos in deinen Git-basierten Versionskontroll-Workflow ein. Du kannst einen Befehl für das Pushen in das Repository und einen weiteren für die Live-Bereitstellung haben, oder du kannst es so einstellen, dass beim Pushen in das Repository automatisch live geschaltet wird.

Diese Cloud-Hosts funktionieren jedoch nicht für jeden. Als ich noch Agenturarbeit geleistet habe, lief die überwiegende Mehrheit auf irgendeinem generischen Shared Hosting. Du könntest immer Git auf diesen Servern installieren, dann, nachdem du Dinge in dein Repository gepusht hast, per SSH auf den Server zugreifen und von dort aus git pullen. Das ist besser, aber immer noch irgendwie umständlich und erfordert die Verwendung der Kommandozeile.

Idealerweise könnten Apps wie Git Tower deine Git Repos verwalten und auch FTP handhaben, indem sie Dateien auf Befehl hochladen, von denen sie wissen, dass sie veraltet sind.

Für diejenigen, die am FTP⁴-Workflow festhalten und keine Angst vor Kommandozeilen-Kram haben, sieht dieses vielversprechend aus.

Die anderen CSS-Präprozessoren

Wie ich bereits klargestellt habe, habe ich mich vorerst für SASS als meinen CSS-Präprozessor entschieden. Aber was ist mit LESS und Stylus?

LESS war der erste, den ich ausprobiert habe, und ehrlich gesagt mag ich ihn immer noch. Mir gefällt sehr gut, wie alle Klassen, die du schreibst, automatisch als Mixins wiederverwendbar sind. Zum Beispiel

.screen-reader-text {
   position: absolute;
   top: -9999px;
   left: -9999px;
}
label {
  .screen-reader-text;
}

Das ist verdammt nützlich und prägnanter als SASS es wäre. Mir wurde jedoch gesagt, dass das Vermischen von Klassen und dem Konzept von Mixins grundlegend fehlerhaft sei. Ich bin mir nicht sicher, warum, aber so ist es nun mal. Wenn jemand das erklären möchte, bin ich gespannt.

Ein großer Ablehnungsgrund, den ich bei LESS hatte, war, dass ich Fehler bekam, nur weil ich die standardmäßige @keyframe Animationssyntax verwendete. Letztendlich musste ich diese Dinge in eine andere Datei auslagern, aber diese Dateien mussten .css sein, um den Fehler nicht auszulösen, und dann konnte ich sie auch nicht @importieren (Inhalt wörtlich einschließen), weil die Dateiendung nicht stimmte. Vielleicht haben sie das behoben, ich bin mir nicht sicher.

Stylus ist auch nett, hauptsächlich wegen seiner Flexibilität. Es wird dich bei weitem nicht so sehr anmeckern wie die anderen. Dinge wie geschweifte Klammern und Semikolons sind optional, nicht zwingend erforderlich. Obwohl Stylus nett und mächtig und robust ist, denke ich letztendlich, dass die Entwicklung dahinter nicht stark genug ist, um mir Vertrauen einzuflößen. Es ist hauptsächlich ein Typ (TJ Holowaychuk).

SASS hat sich letztendlich durchgesetzt, weil es am ausgereiftesten ist, am einfachsten Informationen und Hilfe dazu zu finden sind, die aktivste und robusteste Entwicklung zu haben scheint und die wenigsten Fehler aufweist.

Tutorials hier und abschließende Worte

Nur um es klarzustellen: Ich werde SASS hier nicht in grundlegende CSS-Tutorials aufnehmen. CSS wird sehr wahrscheinlich SASS überleben. Und außerdem denke ich, dass das Verständnis von CSS weitaus wichtiger ist als eine spezifische Präprozessor-Art, Dinge zu tun. Wenn mich ein CSS-Neuling fragen würde, ob er SASS lernen sollte, während er CSS lernt, würde ich wahrscheinlich nein sagen. Lerne, wie CSS funktioniert, und schaue dir dann später an, wie Präprozessoren dir helfen können. Das ist das Gegenteil von dem, was ich über JavaScript und jQuery denke, wo ich finde, dass es in Ordnung ist, zuerst jQuery zu lernen. Komisch.

Im Wesentlichen denke ich, dass du wissen solltest, wie es ist, wirklich gutes CSS zu schreiben. Wie diese endgültige CSS-Datei aussieht. Die Datei, die der Browser liest und verarbeitet, um Websites zu gestalten. Verwende dann einen Präprozessor, um diese endgültige, fabelhafte CSS-Datei einfacher zu schreiben und zu warten.

Der Punkt ist: Schreibe dein Sass/Less so, dass die Ausgabe genau so ist, wie du dein CSS ohne es geschrieben hättest.

— Chris Coyier (@chriscoyier) 2. Februar 2012

---

¹ Ja, es hat Subversion eingebaut, aber es fühlt sich ein bisschen angeflanscht an. Wenn du auf Subversion stehst (und das ist in Ordnung, es ist einfach), denke ich, dass du mit Versions besser dran bist.

² Abgesehen von solchen Kleinigkeiten oder bei der Arbeit, wo ich lokale Server starten muss, die Python und so etwas ausführen. Aber selbst dann nur widerwillig.

³ Bei Wufoo sind wir vom On-the-fly-Kombinieren und Minifizieren von Skripten mit PHP zum Kombinieren und Minifizieren über Präprozessoren übergegangen, was die Serverlast verringert und zu noch effizienter komprimiertem CSS geführt hat.

⁴ Mit FTP meine ich offensichtlich SFTP.