medamind

über den CSS Quicky und Anarchie

Nun muss ich auch noch was zu der CSS Thematik sagen, die ja in den letzten Tagen sehr ausgiebig und zum Teil kontrovers durchgekaut - nein sagen wir lieber - diskutiert wurde.
Gerade mache ich mal wieder eine TYPOlight Seite. TYPOlight macht es einem nicht gerade leicht, die “schnelle Nummer” zu fahren, wenn es um Stylesheets geht.
Und so fallen mir einfach ein paar ganz pragmatische Punkte ein und das TYPOlight Problem natürlich auch.
Ich war ja schon höchst verwundert, als ich kürzlich die Tipps zur CSS Optimierung gelesen habe, - gute Sachen dabei, auch ein paar Selbstverständlichkeiten, mit allem kann ich mich allerdings nicht wirklich anfreunden, vor allem weiß ich aber jetzt eines: ich bin nicht perfekt und muss mich optimieren. Nein, es waren ja nicht mal Tipps. Das nennt sich dann schon .
Und nun erst kürzlich die , die ja eine recht nach sich gezogen haben.
Für mich ist das l’art pour l’art, ein nice to know, das gerade, was einige Aspekte des Ausmistens betrifft, in den wenigsten Fällen praxistauglich ist und vor allem aus meiner Erfahrung ebenso wenig praxisnah.

Die Optimierung der Optimierung

Noch nie hat mich ein Kunde darauf aufmerksam gemacht, dass er ein optimiertes CSS möchte.
Und ehrlich gesagt, wüsste ich gar nicht, wie ich das eigeninitiativ überhaupt “verkaufen” sollte.
Denn Kunde weiß (in den meisten Fällen) nicht, was CSS wirklich ist, der Kunde will ein Layout und kein CSS. Das ist auch okay so - dafür gibt es ja die, die es wissen. Und wenn man es für sich selbst macht na gut, da kann man dann optimieren bis zum bitteren Ende.
Wenn es hier um Optimierung und Ladezeiten eines Templates oder wie auch immer das heißen mag geht, dann fängt das an bei Graphiken, aber es wird ad absurdum geführt, wenn wir hier über ein paar KB sprechen, die ein einzeilig formatiertes CSS weniger haben mag als ein mehrzeiliges.
Dazu sei vielleicht kurz noch hinzugefügt: ich arbeite mit eine ganz stinknormalen, aber in meinen Augen guten Texteditor, nämlich Ultraedit auf dem PC und Smultron auf dem Mac. Beides mag ich sehr gerne.
Ich habe also nichts, was mir Stylesheets optimiert und ich brauch das auch nicht, fand ich jedenfalls bis vor einigen Tagen und Wochen.

Time is Money

Klar - effiziente Arbeitsweise ist das A und O.
Wenn ich vor lauter Optimierung und semantischer Durchstrukturierung erstmal neu die Logik des Ganzen durchschauen muss, weil schnell dann doch noch ein paar Änderungen nötig sind oder das Ganze nun doch drei Pixel nach links muss, dann kann das nicht der Sinn der Sache sein.
Änderungen am Stylesheet müssen schon deshalb schnell gehen, weil es für mich wichtig ist und der, für den ich das mache, hätte das ja sowieso lieber gestern als heute und auch daher ist es legitim. Und damit ist alle andere Zeitverschwendung nicht gerechtfertigt. Also: Übersicht. Findet Ihr das von links nach rechts übersichtlich, ich finde es von oben nach unten und mit ein bisschen Platz dazwischen übersichtlich.

Semantik - oder wo fängt der Wahnsinn erst an?

Da fällt das “active” und “inactive”. Tja. Da kann man lange intern oder extern darüber diskutieren, beispielsweise wenn man die Zeit totschlagen möchte.
Nur bringt das manchmal schon mal deshalb nichts, weil das CMS genau diese Begrifflichkeiten vorgibt. Nun könnte man natürlich auch das noch ändern und damit wieder Zeit totschlagen. Ist das Qualitätsmanagement? Ich weiß nicht - vielleicht hab ich da ja was falsch verstanden?
Sowas wäre bei mir mein Privatvergnügen. Wieder einmal: verkaufen (im wörtlichen sowie übertragenen Sinn) könnte ich sowas sicherlich niemandem.

Wie Kraut und Rüben

Die Alternative zu starren Regeln heißt ja nicht automatisch Wildwuchs.
Und klar: ich habe einen entscheidenden Vorteil und kümmere mich selbst um meinen Code. Trotzdem sind wir ja hier nicht bei einem riesigen Java Projekt sondern bei einem simplen Stylesheet, das nur eines sein muss:
richtig und übersichtlich sein.
Interessant wird es dann übrigens bei dann doch größeren Angelegenheiten wie ein CSS für Docbook oder sowas und auf der Ebene macht das dann vielleicht auch wieder Sinn.

Das CMS macht einen Strich durch die Rechnung

Zum Thema der inneren Gliederung und der Reihenfolge von Anweisungen fällt mir sofort TYPOlight ein. Ein von mir sehr geschätztes System, das aber eine mittelgroße Macke mitbringt: das Handling von Stylesheets. Die unterliegen nämlich auch der Versionierung und der “Kontrolle des Systems”, was Vor und Nachteile hat.
Man hat, sofern man nicht mit einem Pikobello Stylesheet bereits in die TYPOlight Installation geht, zwei Möglichkeiten:

• alle Stylesheets von Beginn an in TYPOlight anlegen und mit dem integrierten Editor bearbeiten, bzw. ein neu importiertes Stylesheet ab sofort im Editor zu bearbeiten oder
• jedesmal das Stylesheet neu zu importieren. Raufladen reicht nicht, denn das gefällt der Versionierungsengine nicht.

Der Editor hat auch seine Grenzen.
Er mag für Anfänger super sein, weil sehr fehlerresistent; wenn es schnell gehen muss, ist er etwas umständlich, behäbig und vor allem: er unterstützt nur die wesentlichen CSS Anweisungen. Bei text-transform fängt es schon an: das muss ins Feld “eigene Anweisungen” und steht dann automatisch immer unten angehängt. Keine Chance dies zu ändern, außer über Variante zwei, die aber auch zeitintensiv ist.
Ach ja und er macht sozusagen sein eigenes CSS. Was ich also wie abkürze und zusammenfasse, das entscheidet TYPOlight für mich.
Und dann hat TYPOlight noch eine weitere gewöhnungsbedürftige Eigenschaft:
Kommentare der Form
/***********************************
* hier kommen die wichtigen Styles
************************************/
werden automatisch zu Gruppen (das ist ein eher virtuelles Konzept, aber manchmal recht praktisch) und nicht nur das: hier sortiert TYPOlight auch noch automatisch.
Wenn man also unter dem Aspekt des cascading und der Vererbungslehre seine Kommentare ergänzt, sollte man das im Auge behalten, sonst passieren spannende Sachen.
Und die Formatierung der Kommentare geht auch verloren.
Alles in allem ist nach einem Import also nichts mehr so wie es war bei TYPOlight.

Nicht ganz unkritisch dieses Feature und bei mir auch nicht sonderlich beliebt. Das haben die TYPOlight Macher wohl auch schon gemerkt und ich glaube, eine Verbesserung dieser Geschichte ist für irgendeine Folgeversion schon in Planung.

Es lebe…

Soll ich TYPOlight deshalb verfluchen? Soll ich mich auf den Standpunkt stellen, hier hätte ich nicht genug Flexibilität, um mein CSS zur absoluten Perfektion zu bringen?

Nein, das tue ich nicht, ich arrangiere mich damit und habe mir inzwischen eigene Workflows zugelegt, um das teilweise umständliche Vorgehen wenigstens ein bisschen zu beschleunigen und natürlich so viel Vorarbeit wie möglich schon vor dem CSS Import mitzubringen. Und irgendwie kommt es ja dann auch noch so ein bisschen wenigstens auf den Inhalt an oder?

Garantiert, verbessern kann man an sich und damit vielleicht auch am Code? -, egal was es ist, immer was. Vom Postulat des besseren WebCSSdesigns halte ich allerdings nicht wirklich viel, ebensowenig wie von der

teutonische Ordnung

wie es so nett formuliert.

Da schließe ich mich dann lieber der an oder bleibe Anarchist.

Trotzdem schön, dass ihr drüber geredet habt, zum Lesen war es wirklich amüsant.

Bildnachweis: wieder mal Flickr und wieder mal ein richtig .