Es scheint, das Projekt ist wie vieles von Peter Kroener seinem Autorendasein zum Opfer gefallen. Schade drum!

Fazit: Nette Idee, aber man muss auch dranbleiben

Wir können das ja schonmal zu Turbine dazupacken, da es ja so auch schon sehr hilfreich ist, und entweder es entwickelt jemand anderes noch eine Code-Vervollständigung, oder wir machen das wenn wir mal was Muße haben. Hab Dir eine E-Mail geschickt.

Mein Kollege und ich haben mal was für Notepad++ fertig gemacht. Es ist zwar keine extra Extension aber eine kleine style.xml mit der man .cssp etwas besser darstellen lassen kann als es Notepad++ normalerweise macht.

Kann ich dir die Datei zukommen lassen? Vielleicht entwickelt ja jemand daraus eine Extension.

Henry Ford:

"Wenn ich die Menschen gefragt hätte, was sie wollen,
hätten sie gesagt: schnellere Pferde."

Ich finde, Dateigröße ist nur eines von vielen Kriterien von Turbine. Skalierbarkeit, Automatisierung, Wiederverwendbarkeit, Redundanz, Usability, Lesbarkeit, Zeitersparnis usw. sind weitere Kriterien. Allein das Auseinandersetzen mit Frameworks erweitert den Horizont und schenkt einem die Möglichkeit der Selbstreflexion.

Ich habe in der Zwischenzeit ein kleines Projekt mit Turbine umgesetzt. Fazit: Installation unter 5 Minuten, die Einarbeitungszeit war danke guter Doku niedrig (ca. 1/2 Stunde), der Output entspricht meinem manuellen CSS-Code. Ich habe das Menü über Variablen so erstellt, dass ich es für andere Projekt mit anderen Farben und Schriften schnell wiederverwenden kann. Beim nächsten Projekt spare ich also Zeit!

Ich kann mir gut vorstellen, dass ich mit der neuen Arbeitsweise Ideen zur Optimierung habe, die mir beim manuellen Codieren nicht gekommen wären.

@Schepp
Der Converter ist nicht perfekt, aber eine echte Arbeitserleichterung. Danke für den Tipp!

Ohne die geschweiftern Klammern lässt sich im NP kaum arbeiten

Zu Deinem Punkt: Klar bergen die neuen Möglichkeiten von Turbine Gefahren, keine Frage. Allerdings blüht einem das doch immer, wenn man sein Gehirn an der Garderobe abgibt.

Du kannst ja nun auch mit nacktem CSS schön viel Mist bauen (Stichworte: ComicSans-Farb-Augenkrebs, ineffiziente Selektoren, Oldschool-Parser-Hacks, etc.). Aber Du kannst Dir bei Turbine mehr Zeit für's Denken nehmen und musst weniger davon auf's Tippen vergeuden. Darum geht's uns letztendlich nur.

Und wer Lust hat, der nutzt ganz allein nur die Plugins und lässt die Syntaxlogik links liegen. Geht ja auch.

@antpaw
Die Transitions wie auch manch anderes haben wir noch außen vor gelassen. Erstere weil sie momentan nur in homöopathischen Dosen von den Clients unterstützt werden, die anderen weil sie zwar fast aber ebenfalls nicht ganz crossbrowser-tauglich sind. Und das war eigentlich die Prämisse, dass wir nur Plugins dazupacken, die überall Ergebnisse produzieren.

Einzige Ausnahme dieser Regel ist das borderradius-Plugin, das so heissbegehrt ist, dass wir es trotz fehlender IE-Unterstützung hineingenommen haben. Ob wir für den IE jemals die VML-gestützten runden Ecken nachrüsten steht in den Sternen. Die sind nämlich mit sehr viel Vorsicht zu genießen.

Alles, was es nicht in die Haupt-Turbine schafft, parken wir aber in einem Extras-Bereich. Dort findest Du derzeit 4 CSS3-Vendorprefix-Plugins, unter anderem auch Transitions. Bei Bedarf, einfach downloaden und bei Turbine dazuparken.

@eric eggert: probier einfach turbine oder sass aus. ich kenne keinen der das nach ein paar tage nicht für unersetzlich (in großen Projekten) hielt.

Mir ist es lieber, dass den Code, den ich bearbeite übersichtlich und einfach wartbar ist. Turbine ermöglicht das ohne auf Optimierungsmaßnahmen zu verzichten. Ich habe nämlich nicht genug Zeit um alle Varianten einer Eigenschaft zu suchen und optimiert habe ich bisher gar nicht. Wenn ich irgendeine Datei gebraucht habe, habe ich sie einfach eingebunden. Fertig und ein Request mehr.

Wenn ich stattdessen Turbine einsetze, dann kann die ausgelieferte CSS-Datei so kryptisch aussehen, dass nur ein richtiger CSS-Experte da noch etwas nachträglich ändern kann ohne neu Fehler einzubauen. Ich jedenfalls muss mit dieser optimierten CSS-Datei nicht arbeiten, weswegen ich da jede Optimierungsmöglichkeit nutzen kann, die Turbine kennt.

Ein CSS-Purist kann also auf Turbine verzichten, aber der Ansatz von intuitiven Code und zuschaltbarer Features und Optimierungsstrategien macht die Entwicklung um einiges effektiver und weniger fehleranfällig.

Auch wenn Turbine in einigen Fällen den Code unnötig aufbläht, ich kann das immer noch besser: Einfach eine weitere CSS-Datei eingebunden und schon ist die Ladezeit länger als würde ich das ganze erst Turbine vorwerfen.

Ich benutze zwar mittlerweile selbst häufig einen Verbund aus SASS bzw. SCSS, Compass und Lemonade. Ich nutze dabei aber bewusst nur Dinge für die automatische Generierung von Vendor-Prefixes (solange sie nötig sind) und CSS-Sprites. Alles andere birgt in meinen Augen die Gefahr, dass genau solcher aufgeblasener Code entsteht, wie im Beispiel.

Ich mache mir lieber ein paar Gedanken zum Aufbau meiner CSS-Datei und spare dann an Dateigröße und zu wartendem Code, als bei den zu tippenden Klammern.

Disclaimer: jeglicher Shell-Output, der auf externe Plugin-Resourcen, also Bilder oder HTCs verweist, hat in der Shell (und nur da) einen falschen Pfad (betroffen wäre zum beispiel der Verweis auf das für Opera generierte Gradient-SVG, aber auch manche IE-Heilpflaster)

Ich denke mal, dass es hier gengügend Leute gibt – nicht nur du – die effektives und schlankes CSS schreiben können. Wenn sich aber ein Entwickler mit einer Möglichkeit befasst, die es ihm erleichtern können sein Werkzeug vielleicht noch effektiver zu nutzen, dann sind solche Ansätze doch super.

Es gibt zwei Seiten der Medaille, ich betrachte die andere Seite. Das finde ich nur fair. Jemand der den Artikel (und die Kommentare) liest soll wissen, dass es auch andere Meinungen dazu gibt.

@Maik
Danke Dir ebenfalls! Und der Vlad ist ein sehr, sehr spendabler. Allenfalls liegt's an meiner eigenen Lahmarschigkeit was das Anmelden bei Flattr & Co angeht (VGWort-Extended Anmeldung ist in der Mache)

@Eric
Wir zwingen Dich zu nichts, Du darfst das ruhig nicht benutzen. Ich verstehe auch Deine Bedenken als CSS-Purist.

Was Dein Code-Zitat angeht, so ist das ganz klar Bloat ein schnell konstruiertes Beispiel, das aufzeigen soll, in welchen Situationen man über Sektorverschachtelung nachdenken kann. Diese Aufgabe erfüllt es auch.

Der Browser-Sniffer ist kein fester sondern ein optionaler Bestandteil, dessen Nachteile wir nicht unter den Tisch fallen lassen, sondern an folgender Stelle einen prominenten Platz einräumen: http://turbine.peterkroener.de/docs.php#plugins-sniffer

Natürlich ist CSS nicht schwer, allerdings finde ich es nie verkehrt, wenn man Optimierungspotential ausschöpft und solche Wege nutzt. Gerade das Thema Variablen ist doch genial.

Zum Glück gibt’s keinen Nutzungszwang, also schon einfach mal deine Nerven.

#header ul a:link, #header ul a:visited,
#header ol a:link, #header ol a:visited,
#header p a:link, #header p a:visited,
#footer ul a:link, #footer ul a:visited,
#footer ol a:link, #footer ol a:visited,
#footer p a:link, #footer p a:visited {
text-decoration: underline;
}
#header ul a:active, #header ul a:hover,
#header ol a:active, #header ol a:hover,
#header p a:active, #header p a:hover,
#footer ul a:active, #footer ul a:hover,
#footer ol a:active, #footer ol a:hover,
#footer p a:active, #footer p a:hover {
text-decoration: none;
}

dann glaube ich, dass es da ein grundlegenden Hang zu bloatcode gibt, ein

#header a:link, #header a:visited, #footer a:link, #footer a:visited {text-decoration:underline;}
#header a:active, #header a:hover, #header a:focus, #footer a:active, #footer a:hover, #header a:focus {text-decoration:none;}

reicht in dem Fall doch bei weitem aus. Das eingebaute Browser-Sniffing ist dann nur noch die Höhe und kann nicht nachhaltig sein. CSS ist nicht schwer, es ist robust und schnell. Warum man noch eine Sprache auf einer Meta-Ebene lernen soll werde ich nie verstehen.

@Vlad: Gib dem Schepp ruhig was ab von meinen flattr-Cents

keine Sorge, Schepp wird was bekommen.

Turbine steht bei meinem nächsten Projekt auf jeden Fall auf dem Zettel.

@Vlad: Gib dem Schepp ruhig was ab von meinen flattr-Cents

ich habe eine einige Zeit mit scaffold und sass herumexperimentiert und fand das Ergebnis sehr gut. Meiner subjektiven Meinung nach rendern Browser sauber verschachtelte CSS-Anweisungen schneller, als unstrukturierte Anweisungen.

Bei den Beispielen von Turbine sehe ich viele Parallelen. Ich stehe den Framework aufgrund der Zeitersparnis sehr positiv gegenüber.

Habt ihr auch vor, einen css2cssp Konverter zu programmieren? Dann kann man alte Projekte auf Turbine umstellen:-)

Liebe Grüße
und danke für die gute Arbeit!

Bertram