Clever CleverCSS

In welcher Reihenfolge man CSS-Eigenschaften notieren soll, haben wir nun wohl genug diskutiert, kommen wir nun zu etwas völlig anderem: programmiertes CSS.

Hatte schon die Idee (in Webkit bereits testweise implmentiert) von Konstanten in CSS die Welt in Aufregung versetzt, dürfte man CleverCSS – the pythonic way of webdesign als die endgültige Gotteslästerung betrachten. Um es kurz zu machen zitiere ich flugs:

CleverCSS is a small markup language for CSS inspired by Python that can be used to build a style sheet in a clean and structured way. In many ways it’s cleaner and more powerful than CSS2 is.

Hmmm… pythonic, das könnte meinem Wunsch nach Formatierung und Sauberkeit doch entgegenkommen. Und CleverCSS kann einige witzige Sachen, ausser einfach CSS wieder raus zu printen. Bspw. gibt es einen grouping operator, der Attribute zu Gruppen zusammenfasst. So:

#main p
  font->
    family: Verdana, sans-serif
    size: 1.1em
    style: italic

Ausgegeben würde hierfür:

#main p {
    font-family: Verdana, sans-serif;
    font-size: 1.1em;
    font-style: italic;
}

Mal bitte, das ist ja lustig. Und dann wirds spannend, CleverCSS beherrscht natürlich Konstanten, um z.B. Farbwerte einmalig festzulegen und editierbar zu machen. Ich weiß schon, nichts, was man nicht auch mit suchen & ersetzen erschlagen kann… nur, CleverCSS kann damit auch ein wenig rechnen:

background-position: $foo + 2 + 3 $foo - 2

Das täte background-position: 15 8; ergeben. Mit CleverCSS kann man beinahe richtig rechen, sogar mit Farben (#fff - #ccc => #333333). Und als wär das nicht schon genug: es gibt auch noch einen ganzen Satz Methoden, wie Number.abs(), String.length(delimiter), Color.brighten(amount) oder String.split(). Klingt doch spannend.

Allen Features zum Trotze muss man natürlich die Frage nach dem Sinn stellen. Ehrlich gesagt: weiss ich noch nicht. Fällt mir aber sicherlich noch ein. Zusammenhänge könnten Frameworks, Templatesysteme, …, ja was?

Prädikat: unbedingt mal runterladen und ausprobieren.

You never have expected…

Hallo, hier spricht die heilige CSS-Inqisition. Sie hätten das sicherlich nicht erwartet, aber hier ging es ja schon das eine oder andere Mal um CSS-Codepoetrystyleguidespießereien, da kann ich natürlich kaum an mich halten, wenn in einem von mir hochgelobten Webmagazin derartig hahnebüchener Blödsinn verzapft wird.

Andreas Dölling ist laut Autorenangbae Webentwickler, kann es aber nicht lassen, seine Nase immer wieder in Bereiche zu stecken, die ihn eigentlich gar nichts angehen, und seine Meinung dazu kundzutun. Schon passiert würde ich mal sagen, obwohl ich dachte, dass CSS einen Webentwickler sehr wohl etwas angeht.

Zunächst einmal ist es natürlich eine super Sache, seine CSS-Klassen gut und semantisch zu benennen, es werden auch wirklich schöne und einleuchtende Besipiele genannt, die Herr Dölling einem alten Hasen abgescahut hat bzw. zu denen ihn das Qualitätsmanagement einer professionellen Firma gezwungen hat. Scheinbar aus Rachen gegen die Affront jedoch hat sich Herr Dölling noch einige Reste eigenen CSS-Stils bewahrt und die haben es in sich. Mein Vorschlag dazu: auf gar keinen Fall nachmachen!

Anordnung von CSS-Eigenschaften

Es wird empfohlen, Eigenschaften in der Reihenfolge der Wichtigkeit zu notieren, wobei in fünf Wichtigkeitsgruppen eingeteilt wird (Verhalten, Position und Dimension, Abstände und Rahme, Schriftgröße und Zeilenhöhe, Hintergrund und übrige Eigenschaften). Dämliche Idee numero uno: erstens halte ich die Wichtigeit von CSS-Eigenschaften für höchst diskutabel, das kommt halt immer auf den Fall an, in Wahrheit ist dies ein willkürliche Festlegung. Wogegen man eigentlich gar nichts einwenden kann, denn wenn es keine logische Reihenfolge gibt ist koordninierte Willkür der einzige Weg. Nur sind diese Gruppen schwer vemittelbar: man muss lernen, was zu welcher Gruppe gehört, lernen in welcher Reihenfolge die Gruppen anzuordnen sind und innerhalb der Gruppen, gibt es gar keine definierte Reihenfolge. Stellen sie sich einmal vor, sie sind Qualitätsmanager und sollen nun dieses Regelwerk an diverse Webentwickler und -dekorateure kommunizieren. Schönen Dank. Ich sag’s mal in CSS-Inquisitions-Sprache: wird sich nicht durchsetzen. Zu kompliziert, zu schwierig umzusetzen.

Der Gegenvorschlag bleibt bestehen: CSS-Eigenschaften immer in aplhabetischer Reihenfolge notieren. Das ist einfach, versteht jeder, ist eine nachprüfbare, also durchsetzbare Regel und super umsetzbar. Und führt auch auf lange Sicht zu lesbaren Stylesheets.

Einrückung und Umbrüche

Endgültig die Haare zu Berge stehen einem dann, wenn man die Idee zum quer schreiben liest. Herr Dölling, lassen sie sich an dieser Stelle einmal folgendes sagen: wer quer schreibt, ist noch lange kein Querdenker, eher schon ein Quertreiber. Mal davon abgesehen, dass die letzte Übersichtlichkeit, die Herrn Döllings drolliger Dialekt noch bietet, einzig und allein durchs Synthaxhighlighting zustande kommt, ist dies ein CSS-Code der sagt: »Fass mich nicht an! Mein Autor ist so von sich selbst überzeugt, dass er nicht glaubt, dass jemand anderes ausser er selbst Änderungen vornehmen möchte.« Danke schön.

Sowas darf man sicherlich auf den Server stellen, es spart eine Menge Platz und sicherlich das eine oder andere Byte an Gewicht. Aber während der Entwicklungszeit ist so eine Schreibweise einfach nur eins: kontraproduktiv. Man stelle sich nur vor, man soll jetzt hier eine CSS-Regel hinzufügen, womöglich nach der vorgenannten Fehllehre, sozusagen irgendwo in der 400 Zeichen langen Zeile. Wir wünschen fröhliches horizontal scrollen. Das ist wirklich eine dumme Idee. Auf gar keinen Fall nachmachen.

Hoffe, das war jetzt inquisitorisch genug, war ja auch so gewünscht. Da kann einem aber auch der Geduldsfaden reissen. Schon passiert: hier habe ich eine Videoaufnahme davon:

httpv://www.youtube.com/watch?v=gldlyTjXk9A

Nachtrag: ich habe heute morgen in meiner grenzenlosen Weisheit Dämlichkeit diesen Artikel aus Versehen gelöscht und musste z.T. von Hand restoren, dabei sind die Pingbacks flöten gegangen. Sorry.

Zitat des Tages

I’ve often seen features cut from a product launch in favor of generating “better” documentation.

David Verba in Sketching in Code: the Magic of Prototyping.

Manchmal denke ich, hier, diesseits des großen Teiches, machen wir Webentwicklung irgendwie noch mit Hammer und Meißel. So ein bißchen, als wären wir Steinzeitmenschen, die eben zusehen dürfen, wie der Stamm nebenan das Feuer kultiviert, das Rad erfindet etc., aber unser Stammesältester unterbindet den neumodischen Kram.

CSS Coding Guidelines II

Teil 1 wurde ja schon ausgiebig diskutiert, daraus habe ich schon einiges mitgenommen. Machen wir also fröhlich weiter mit meinen Ideen, wie man CSS am besten notiert…

dr. who
»It’s not everything that bad…« ©BBC

Kommentare

Mehrzeilige Kommentare, mit Einrückung et al. sind zu platzieren:

  • am Beginn jeder Datei
    • mit Angabe wozu und an welcher Stelle das Stylesheet benötigt wird, kurze Inhaltsangabe o.ä.
    • Abhängigkeiten
  • vor jedem Themenabschnitt

Codebespiel: mehrzeiliger Kommentar

/**
 * Hello World
 * Dies ist ein mehrzeiliger Kommentar
 */

In allen anderen Fällen ist der Zeilenkommentar zu nutzen

Codebespiel: einzeiliger Kommentar

/* Dies ist ein einzeiliger Kommentar */

Leerzeilen

Einzelne Regeln sind durch 1 Leerzeile voneinander zu trennen. Es sollten niemal mehr als 2 Leerzeilen aufeinander folgen.

Codebespiel: Leerzeilen

.note { border: 1px solid #000; }
 
.black_note {
    background: #ff00ff;
    color: #000;   
}

Anm.: Bitte den Code immer so leserlich wie möglich gestalten. Optimierung des CSS auf Größe wird in späteren Buildprozessen umgesetzt und ist vom Layout unabhängig.

Kurzschrift-Eigenschaften

Wo immer möglich und sinnvoll sollen die Deklarationen in Kurzschreibweise zusammengefasst werden.

Codebespiel: Kurzschreibweisen 1

.small {
    background: transparent url(img/border-bottom.gif) repeat-x bottom;
    border: 1px solid #000;
}

Trotzdem bitte flexibel bleiben und davon abweichen, wenn es sinnvoll ist:

Codebespiel: Kurzschreibweisen 2

a:link {
    background: transparent url(img/sprite.gif) no-repeat 0 0;
}

a:hover {
    background-position: 0 -16px;
}

Best practice

Bitte jede Deklaration immer mit einem Semikolon abschließen.

Namen

  • alle Namen in Kleinbuchstaben
  • zusammengesetzte Namen mit _ (underscore) verbinden
  • eher aber kurze Namen suchen, höchstens 1 Zusammensetzung
  • Update: Klassennamen verraten nicht das Aussehen eines Elementes. (via) D.h. Klassen heissen nicht „.grey-border“ oder ähnliches.

Reservierte IDs: folgende IDs sind in der Regel für das HTML-Gerüst vergeben und sollen außerhalb dessen nicht benutzt werden:

  • #wrapper
  • #container
  • #header
  • #content
  • #sidebar
  • #footer

To be continued.

CSS Coding Guidelines I

the doctor
The Doctor. © BBC

Begriffsklärung

Codebespiel: Begrifflichkeiten

h2 { color: #000; }
  • Diese Codezeile ist eine CSS-Regel (rule)
  • h2 ist (hier) ein Selektor (selector)
  • color: #000; ist die Deklaration (declaration)
  • color ist eine Eigenschaft (property)
  • #000 ist ein Wert (value)

Nachzulesen beim W3C.

Schreibweisen

  • Alle IDs und Klassennamen klein schreiben
  • Alle Selektoren klein schreiben
  • Alle Deklarationen klein schreiben
  • Alle Werte klein schreiben

Codebespiel: Schreibweisen

h2, #container, .formbox { color: #efe; }

Leerzeichen (Space)

  • Zwischen Deklaration und Wert (nach dem Doppelpunkt)
  • nach Kommata
  • bei einzeligen Selektoren nach { und vor }
  • nach /* und vor */

Einrückung

  • Selektor auf eigener Zeile, dahinter {-Klammer
  • Deklarationen (1 pro Zeile) eingerückt um vier Leerzeichen
  • }-Klammer am Ende wieder ausgerückt

Codebespiel: Einrückung 1

.note {
    border: 1px solid #000;
    color: #ff0000;
    margin-bottom: 10px;
}

Ausnahme: Selektor mit nur 1 Deklaration wird einzeilig geschrieben

Codebespiel: Einrückung 2

.note { border: 1px solid #000; }

Regeln, die sich auf Kindelemente beziehen, werden an der Mutter-Regel ausgerichtet.

Codebespiel: Einrückung 3

.note {
    border: 1px solid #000; 
}
    .note p {
        padding: 4px 2px;
    }

To be continued. Update: Teil 2 ist fertig.

Scalr – EC2 Framework

Ich war gestern schon kurz über Scalr gestolpert, zusammen mit einem Kollegen hatten wir aber beschlossen: gute Idee, aber das können dann ja andere für uns testen. Denn »Scal(e)r« versprciht wirklich ziemlich viel mit ziemlich wenig Aufwand, da kann man schon mal mißtrauisch werden. Kurz gesagt: Scalr ist ein Framework, das Amazons EC2 Cloud nutzt, um dort komplette und vor allem ausfallsichere Serverumgebungen mit Web- und Datenbankserver plus Loadbalancer zur Verfügung zu stellen und zu verwalten. Das könnte ja interessant sein. Kaum habe ich das gestern nicht gebloggt, kommt nachmittags ein Dienstleister und bietet uns genau dasselbe in zartrosa an. Und heute nacht ist es dann auch schon bei Techcrunch. Könnte also doch etwas dran sein.