Das OOP Programmierparadigma sollte ja aus den gängigen Programmiersprachen bekannt sein. Für die, die von OOP jetzt das allererste mal etwas höhren eine kurze Erklärung, ohne zu technisch zu werden: Die Techniken der objektorientierten Programmierung unterstützen uns dabei, Software einfacher erweiterbar, besser testbar und besser wartbar zu machen.
Wie kann man solch ein Schema nun für CSS benutzen. Nicole Sullivan hat sich mit dieser Problemstellung befasst und herausgekommen ist dabei ein objektorientiertes CSS Framework namens OOCSS. Die Beschreibung verspricht viel “for high performance webapplications and sites”. Klingt gut.
Mit OOCSS soll es möglich sein performante, wartbare Seiten zu erstellen die obendrein noch Webstandards konform sind. Dafür sind 2 “Grundsätze nötig auf die OOCSS baut. Die Struktur vom Aussehen zu trennen und die verschiedenen Bereiche (Container: Head, Sidebar usw.) vom Inhalt.
Das Projekt liegt bislang noch in einer Alphaversion vor. Aber ansehen kann man sich das ganze auf jeden fall. Ich finde es sehr interessant und hoffe ich komme mal dazu es bei einem Projekt einsetzen zu können.
Habt ihr schon mit OOCSS gearbeitet? Was haltet ihr davon? Über Kommentare freuen wir uns wie immer.
Soweit nicht anders gekennzeichnet, stehen alle Inhalte auf miyuato.com unter
einer
martin
am Jun 16th, 2009
@ 23:02:
hallo,
ich habe mir auch grad die präsentation von nicole sullivan beim ydn angesehn und finde den ansatz durchaus interessant.
allerdings denke ich dass sich das nur für wirklich große seiten, wie eben yahoo, eignet.
meine vermutung ist, dass man bei kleineren apps oder seiten durch geschickte verwendung der normalen CSS selektoren durchaus effizienteren code produzieren kann.
mittlerweile würde ich auch davon absehen den code den man als produktiv version im einsatz hat auch als direktes entwicklungs exemplar zu verwenden.
es kommen immer mehr tools mit denen es möglich wird CSS sehr gut wartbar und wiederverwendbar zu schreiben, sei nur mal LESS (http://lesscss.org/) genannt.
ich diskutier gern weiter,
martin
Oliver Klee
am Jun 16th, 2009
@ 23:46:
Hallo Martin,
danke für den Link, ein sehr interessanter Ansatz muss ich sagen. Wenn ich das richtig verstehe fügt less dem CSS sprachfeatures hinuz welches es so in der art nicht hat um dadurch besser wartbares CSS zu schreiben. Vorraussetzung ist allerdings das man ruby auf seinem Server laufen hat. Dies wäre vielleicht in manchen Fällen ein Problem, für dieses spezielle Tool.
Sicher muss man sehen welches Framework man verwendet für welchen Zweck. Grundsätzlich bin ich allerdings für den Einsatz von Frameworks.
Es reicht natürlich nicht aus, einfach das Framework zu nehmen und hinzuklatschen. Es muss natürlich entsprechend optimiert werden, auf die eigenen Bedürnisse. Das man bei jedem Framework ein wenig overhead hat lässt sich denke ich nicht vermeiden.
Für mich hier alleine lohnt sich die Trennung von Entwicklungsversion und Produktivversion noch nicht. Es ändern sich noch ziemlich oft Elemente etc.
“not” macht erfinderisch und von daher seh ich persönlich noch sehr viele tolle Entwicklungen auf uns zukommen.
Wie stehst du den dem Einsatz von Frameworks, jetzt speziell html/css Frameworks, gegenüber?
Liebe Grüße
Oliver
martin
am Jun 17th, 2009
@ 16:59:
hallo oliver,
less benötigt zwar ruby allerdings muss less nicht zwangsweise auf dem server ausgeführt werden. dann muss die neue ‘kompilierte’ CSS datei allerdings noch auf den server geladen werden, was ja auch automatisch geht.
ich denke es lohnt sich immer produktiv und entwicklungsversion voneinander zu trennen da man so auch erst den produktivcode ändert wenn man sich sicher ist das alles funktioniert.
das ist nicht gegeben wenn man direkt an der produktivversion rumpfuscht.
der ansatz bei less ist ja, dass man in der entwicklungsversion einige features hat, die CSS nicht nativ unterstützt und somit schneller refaktorisieren kann und auch insgesamt flexibler in der entwicklung ist.
zum thema frameworks:
ich denke frameworks können die entwicklungs zeit zum fertigen prototype eherblich beschleunigen aber gleichzeitig den ‘aufräum-prozess’–in dem der overhead des frameworks entfernt wird–verlängern.
der genannte aufräum-prozess ist ja wenn man alles von hand schreibt nicht erforderlich.
im endeffekt würde ich aber auch zu einem framework greifen, da man so schneller zu ergebnissen kommt und diese leicht ändern kann.
optimierung muss sowieso immer betrieben werden.
960gs gefällt mir dabei am besten, da es sehr klein ist, bluefish am schlechtesten, weil es das genaue gegenteil ist und alle möglichen schnick schnack dabei hat.
(ich kenne aber auch nicht sehr viele)
freue mich schon auf die antwort,
martin
@mklappstuhl auf twitter falls dus hast
Oliver Klee
am Jun 17th, 2009
@ 17:32:
Hallo Martin,
Ja, natürlich kann man das dann alles automatisiert bewerkstelligen. Sollte auch kein Grund gewesen sein, warum ich less ablehnen würde. Im Gegenteil, ich sehe mir das am Wochenende mal genauer an, weil ich denke das es ein hilfreiches Tool ist.
Ok, erwischt. Im Grunde habe ich ganz zu Anfang die strikte Trennung von Entwickler und Produktivversion beachtet. Als dann immer viele kleine Änderungen kamen, lies ich mich dazu verleiten sie direkt in der Produktivversion zu ändern. Man mag vielleicht von Faulheit sprechen, aber ich gelobe Besserung.
Persönlich habe ich bisher nur mit Yui Grids und YAML Erfahrung gesammelt. Wobei mich YAML am meisten überzeugt, vor allem im Hinblick auf den Internet Explorer.
Einen weiteren Vorteil beim Einsatz von Frameworks sehe ich wenn man im Team arbeitet. Man hat eine gemeinsame Codebasis und sozusagen dann auch Richtlinien an was sich die Entwickler zu halten haben. Das es in der Praxis ein wenig anders ist, als beschrieben, ist klar.
Zum Thema Zeitersparnis: Im Grunde hat man die eigentlich kaum. Wie du das ja bereits beschrieben hast. Zumal ich nicht glaube das man den kompletten overhead entfernen kann. Aber optimieren in jedem Fall.
Andererseits denke ich aber auch, dass es kein Patentrezept gibt wie man etwas lösen kann. Mit/ohne Framework. Ich denke das es genauso wenig schwerwiegende gegen den Einsatz von Frameworks gibt, wie wenn man alles “from the scratch” hochzieht. Um diesen allgemeinen Gedanken an dieser Stelle mal einzuwerfen.
Ich gehöre, auch wenn ich Twitter nicht abgeneigt bin, nicht zu den Nutzern dieses Dienstes. Vielleicht magst du mir das ja mit ein paar tollen Argumenten Schmackhaft machen?
Nochmal zu less: hast du damit schon gearbeitet? Und magst mir verraten wie es sich in der Praxis “anfühlt”.
Abendgruß
Oliver
martin
am Jun 17th, 2009
@ 21:29:
auch einen schönen abend,
auf twitter findest du sachen wie less
reicht das?
ich dachte am anfang auch es ist quatsch aber wenn man sich erstmal eingelebt hat ist es nett.
habe noch keinen praktischen einsatz für less gehabt, kenn es ja selber erst seit einigen tagen.
ich würde mich freuen wenn wir die diskussion auf skype o.ä. auslagern könnten,
bin eigentlich sehr schreibfaul.
hab bei skype den selben namen wie bei twitter, meld dich wenn du magst.
ansonsten schau ich auch hier nochmal vorbei.
bis dann,
martin
martin
am Jun 26th, 2009
@ 11:31:
http://github.com/anthonyshort/csscaffold/tree/master
auch ein interessanter ansatz.
unterstützt den objekt-orientierten ansatz besser als LESS.
viele grüße
Oliver Klee
am Jun 29th, 2009
@ 09:47:
hallo martin,
danke für den Link! Ich sehe mir das mal an.