CSS-Frameworks sind nicht unumstritten. Vor allem Coder, die im Übrigen die Auffassung vertreten, der beste Editor sei Vi halten gern regelrechte Kampfreden gegen die Verwendung vorgefertigter CSS-Module. Dabei gibt es gute Gründe für CSS-Frameworks. Der beste Grund aus meiner persönlichen Sicht ist die massive mögliche Zeitersparnis in der Projektabwicklung. Da der durchschnittliche Kunde heute nichts weniger gern rausgeben will als Geld, korrespondieren Kundenwunsch und Entwicklerziel unter Verwendung eines CSS-Framework schon einmal erheblich besser. Im Folgenden zeige ich den Einstieg (!) in das Rapid Prototyping mit dem Framework 960.
Konzept
Das Framework 960.gs gehört zu den schlanksten Vertretern seiner Art. Das Hauptfile “960.css” ist unkomprimiert und ganze 7 kb groß. So tritt 960 dem verbreiteten Vorurteil, Frameworks seien generell furchtbar aufgeblasen, wirkungsvoll entgegen. Die geringe Größe, besonders im Vergleich zu anderen CSS-Frameworks wie etwa Blueprint ist natürlich erkauft mit gewissen Limitierungen, die andere Frameworks so nicht haben. 960.gs ist nicht für jedes Projekt geeignet, elastische Layouts sind damit überhaupt nicht zu machen. Es hängt stark von Ihrer Kundenklientel ab, ob der Einsatz von 960.gs für Sie in Frage kommt.
Nach meiner Erfahrung ist es für über 90 Prozent aller Websites aus dem Bereich der KMU, also des Brot- und Butter-Geschäfts jedoch vollkommen ausreichend. Denn an diesen Stellen sitzen die konservativen Denker, die es nicht verstehen, nicht einmal akzeptieren, wenn eine Website nicht aussieht wie ein Flyer oder die Druckversion ihrer Preisliste.
960 verfolgt ein einfaches Konzept. Es teilt eine Website unter der Annahme einer Gesamtgröße von 960 Pixeln in der Breite in gleich große Spalten auf. Dazu wird wahlweise eine 16-Spalten-Matrix oder eine 12-Spalten-Matrix, das so genannte Grid verwendet. Im 12-Spalten-Grid ist jede Spalte 60 Pixel breit, im 16-Spalten-Grid erhält jede Spalte eine Breite von 40 Pixeln. Beiden Grids gemeinsam ist, dass der Abstand zwischen den Spalten jeweils 20 Pixel groß ist.
Layout entsteht nun durch die standardisierte Hinzunahme von Spalten zu Designblöcken. Die verfügbare Breite eines Elements im 12er Grid, welches ich zur Grundlage der weiteren Betrachtung mache, variiert daher von 60 bis 940 Pixel. Es existieren, wie der Name impliziert, 12 verschiedene Layoutblöcke, die sich, von 60 Pixeln ausgehend, immer unter Addition von 80 Pixeln errechnen. Demnach haben wir folgende Blöcke zur Verfügung: 60 (1), 140 (2), 220 (3), 300 (4), 380 (5), 460 (6), 540 (7), 620 (8), 700 (9), 780 (10), 860 (11), 940 (12). Die Zahlen in Klammern gewinnen später noch Relevanz. Da jede Spalte ein Margin von 10 Pixeln links und rechts hat, ist auch der größte Block lediglich 940 Pixel breit (940 + 10 + 10 = 960)
Grundlegendes Gestalten mit 960.gs
Die Anwendung des 960 ist auch, wenn man im CSS-Kontext mit dem Wort vorsichtig sein sollte, simpel. Wichtig ist, dass Sie die zu erstellende Website möglichst von Beginn an unter Zugrundelegung des entsprechenden Grids planen. Im Downloadpaket auf der Projektwebsite befinden sich neben den eigentlichen Frameworkdateien auch Templates für Fireworks, Illustrator, Photoshop, Visio, Omnigraffle (wtf?) und sogar Inkscape, so dass Sie die Anordnung der Site-Elemente bequem direkt auf dem Grid vornehmen können. Pen and Paper-Fans finden ein PDF zum Ausdrucken vor.
Gehen wir in der Trockenübung also einmal davon aus, dass Sie ein dreispaltiges Layout mit einer Sidebar links, einem Hauptcontentbereich in der Mitte und einer Sidebar rechts realisieren wollen. Der Hauptcontentbereich soll so groß sein, wie die beiden Sidebars zusammen. Header und Footer sollen jeweils alle drei Spalten umfassen. Natürlichsprachlich ausgedrückt sagen Sie 960 folgendes:
Nimm für den Header den größten Block, also die 12. Dann setze die linke Sidebar und nehme dafür einen Block der Größe 3. Für den Hauptbereich in der Mitte nimm einen Block der Größe 6 und die Sidebar rechts erhält einen Block der Größe 3 (3 + 6 + 3 = 12). Für den Footer setzen wir wieder einen Block der Größe 12 ein. Fertig. Klingt einfach? Ist es auch. Im Prinzip. Natürlich ist das durchschnittliche Real-World-Layout komplexer als das eben genannte, wird jedoch grundsätzlich genauso umgesetzt.
Die Größendefinition erfolgt dabei über CSS-Klassen mit dem simplen Namen grid_1 für den kleinsten Block und grid_12 für den größten. Verschiedentlich wird kritisiert, dass diese Klassennamen nicht semantisch sind, was richtig ist, sich aber durch die zusätzliche Vergabe einer ID unproblematisch beheben lässt. Den Gesamtcontainer definiert man ebenfalls als Klasse. Zur Verfügung stehen container_12 für das 12-Column-Grid und container_16 für das 16-Column-Grid. Analog zum 12-Spalten-System gehen die Namen im 16-Spalten-System schlicht von 1 bis 16.
Die maximale Zahl von 12 unterschiedlichen Blockgrößen erleichtert dem Seitenersteller die Arbeit natürlich per se schon einmal ungemein, da er lediglich im Zahlenraum von eins bis zwölf rechnen und sich nicht mit krummen Pixelwerten rumschlagen muss. Außerdem ist durch die Verwendung eines festen Grid auch eine etwa erforderliche Zusammenarbeit zwischen Designer und Programmierer einfacher, da sich beide von vornherein nur auf das zugrundeliegende Grid, respektive die dahinter stehenden Pixelwerte verständigen müssen.
Besonderheiten für besondere Situationen
Die wesentlichen Elemente der Verwendung des 960.gs sind genannt. Und in der Tat gibt es nur eine kleine, nicht einmal handvoll große weitere Zahl an Klassen, die es zu kennen gilt.
Verwendet man Blöcke innerhalb von Blöcken, um verschachtelte Layouts zu erzeugen, gibt es Probleme wegen der Tatsache, dass jedes Grid-Element sowohl links wie auch rechts ein Margin von 10 Pixeln hat. Grundsätzlich wäre es also möglich, zwei grid_3 mit jeweils 220px (=440px) in ein grid_6 mit 460px zu bewegen (220 + 20 + 220 = 460). Dennoch funktioniert das so nicht, denn links und rechts des grid_3 befindet sich jeweils ein weiteres Margin von 10px, so dass wir in Summe auf 480px kommen, was logischerweise nicht in einen Block mit 460px passt.
Für diese Zwecke gibt es die Klassen Alpha und Omega. Alpha wird als Klasse an das erste grid_3 gehängt und hat lediglich die Aufgabe, den linken Margin auf 0 zu setzen. Omega wird als zusätzliche Klasse an das zweite grid_3 gehängt und setzt dort den rechten Margin auf 0. Schon klappt es auch mit dem grid_6.
Als letztes sollten Sie noch die Klassen prefix_x und suffix_x kennen. Diese beiden werden benötigt, um Elemente irgendwo auf der Seite im Grid zu platzieren. Wollten wir also den kleinsten Block grid_1 nicht auf der ersten Spalte, wie es nach der Definition Standard wäre, sondern beispielsweise auf der zweiten Spalte positionieren, würde wir 960 sagen: Nimm ein grid_1 mit einem prefix_1 und einem suffix_10 (1 + 1 + 10 = 12). Sollte der Block auf der dritten Spalte sitzen, entsprechend grid_1 prefix_2 suffix_9 und so weiter.
Das war es. Mit diesem Wissen ausgestattet, können Sie ihre ersten gridbasierten Layouts in Angriff nehmen.
Beispiel: Dr. Web im groben Nachbau mit dem 960.gs
Unter der URL http://960.blogmanufaktur.de/ können Sie sich einen hemdsärmeligen Nachbau der Dr. Web-Startseite ansehen, die unter Verwendung des 960.gs in einer guten Viertelstunde entstand. Ich gebe folgend einen kurzen Abriss der Vorgehensweise.
Zunächst erstelle ich einen Projektordner. Ich nenne ihn 960 und verknüpfe ihn mit der Subdomain “960.blogmanufaktur.de”. In diesem Verzeichnis lege ich eine index.html, sowie die Ordner css, img und js an. Js brauchen wir für das Beispiel nicht. Die Macht der Gewohnheit…
Hernach lade ich von Dr. Web ein paar Grafiken herunter und speichere sie in das Verzeichnis img. Der Einfachheit halber habe ich den Plus-Login rechts oben, sowie die rechte Sidebar per Screenshot als Grafik gesichert und ebenfalls dort abgelegt.
Das 960.gs lege ich im Unterordner 960 innerhalb des Ordners css ab, mein eigenes Stylesheet drweb.css eine Ebene höher. So kann man nicht versehentlich an den Originalen des 960.gs rumfummeln.
In der index.html verknüpfe ich nun im Head die Stylesheets.
Unmittelbar nach dem Body-Tag ist dann das Grid zu definieren. Wie angekündigt, verwende ich das 12-Column-Grid. Den Header mit dem Dr. Web Logo und dem Screenshot des Plus-Logins teile ich in zwei grid_6 auf. Dem img-Tag habe ich in meiner drweb.css ein Top- und Bottom-Padding von 10 Pixeln beigegeben, damit die Elemente nicht direkt aufeinander hocken. Die Navigationsleiste setze ich als grid_12 über die volle Breite.
Unterhalb der Navigationsleiste teile ich den Platz in drei Spalten. Die linke Sidebar erhält eine Definition als grid_2, der Hauptcontent-Bereich wird als grid_7 angelegt und die rechte Sidebar definiere ich als grid_3 (2 + 7 + 3 = 12).
Die Anzeige für das Smashing Forum implementiere ich als separates Div innerhalb des Hauptbereiches, weise ihr grid_3 zu und füge alpha bei, damit die Grafik nicht im Vergleich zum darüber stehenden Text um 10 Pixel nach rechts verspringt.
Mir ist klar, dass die vorgestellte Implementation einiges an Eleganz zu wünschen übrig lässt, jedoch soll sie lediglich beispielhaft zeigen, wie zügig ein Prototyp unter Verwendung des 960.gs erstellt werden kann. Wenn ich de(r)m ein oder anderen Leser/in auf diese Weise Lust auf die Erkundung des 960.gs machen und vor allem etwa vorhandene Ängste davor nehmen konnte, hat dieser Beitrag hier sein Ziel voll erfüllt. ™
Weitere Beiträge:
- 5 Ideen wie Sie wiederkehrende Arbeitsschritte & Marketingprozesse gewinnbringend im Internet automatisieren! Ein Gastbeitrag von Robert Nabenhauer.
- Wachstum durch Facebook-Gewinnspiele: Wie Sie über Facebook virale Gewinnspiele & eine schnell wachsende Fangemeinde aufbauen
- Wie Sie aufmerksamkeitsstarke Prelaunch-, Launch- und Relaunch-Szenarien aufbauen und dabei Viralität, Spannung & Kaufkraft erzeugen
- Wie Sie waschechte Iphone-Apps mit PhoneGAP entwickeln, um am lukrativen App-Markt mitzumischen
- Wie Sie Ihr Shop-Sortiment so präsentieren, dass der Kunde in Zukunft mehr findet und eher kauft! Ein Gastbeitrag von Nicolas Schmidt-Voigt.
- 11 faszinierende BuddyPress-Plugins, um kostenlos aus WordPress ein soziales Netzwerk zu zaubern
- Die Vorboten einer neuen Internet-Industrie! Ein exklusiver Rückblick & Blick hinter die Kulissen der Clickbank-Exchange 2011 in New York.
Loading ...
Bei der naviliste hätte ich persönlich eher ein ul mit li’s (unordered list) gemacht.
Ich persönlich nutzte das 960 sehr gerne. Solange das Design auch für dies vorgesehen ist. Andererseits hat man schon eher Probleme als eine Hilfe.
hier noch einen Link:
http://www.divio.ch/blog/2009/05/26/divio-09-behind-the-scenes-2/
Gut zusammengefasst,
zwei Kritikpunkte: 4 CSS-Stylesheets im Head einbinden ist in punkto HTTP-Requests und damit performancetechnisch sicher mehr als suboptimal. In einer Produktionsumgebung sind diese zu einem großen Stylesheet zusammenzufassen (und da stoßen wir evtl. schon wieder an die Grenzen eines solchen Frameworks). Entscheidend für die Performance ist heutzutage nicht mehr die Größe der Dateien (die Leitungen sind in 99% der Fälle breit genug), sondern die Zahl der HTTP-Headerrequests !
Worauf du auch eingehen solltest ist der Umgang mit Browser-Inkompabilitäten – werden die im Framework abgefangen und wenn ja wie ?
PS: Vi bzw. VIM reicht mit vordefinierten Textblöcken und Syntaxhighlighting völlig, um mit einem CSS-Framework zeittechnisch locker mitzualten. Zumal sind Abrechnung auf Stundenbasis im Freelance-Webbereich ein Geschäftsmodell von vorgestern
…
“Entscheidend für die Performance ist heutzutage nicht mehr die Größe der Dateien …, sondern die Zahl der HTTP-Headerrequests”
Kann ich theoretisch nachvollziehen. Da mir aber der genaue technischer Hintergrund fehlt, meine konkrete Frage: Wo genau wirkt sich das negativ aus? Beim User, auf der Leitung, auf dem Anbieter-Server? Erhöht es nur den Rechenaufwand der Server respektive Stromverbrauch? Subjektiv gesehen merke ich doch als User an einer “dicken” Leitung keinen Unterschied, ob jemand eine oder 10 CSS-Dateien einbindet.
Ich hoffe auch, dass dieser Artikel Anfaenger ermutigen wird Frameworks zu benutzen. Meiner Ansicht ist das Blueprint Framework besser, da es 24 Grids zur Verfuegung stellt und auch flexibler bzgl. der Requests ist (ich habe derzeit 2 auf meiner Seite).
Und das mit den Requests ist auch nicht so eine “wilde” Sache. Zwar sprechen die fuehrenden CSS Gurus davon weniger Requests zu machen, dies gilt allerdings fuer hoch komplexe Seiten mit 10k+ unique Visitors. Von daher sind solche Frameworks sehr gut fuer KMU geeignet. Und fuer das schnelle Prototyping reicht es allemal!
@52eins: ein Unterschied gibt es bei langsamen Leitungen (speziell bei komplexen heterogenen Systemlandschaften). Mehr Requests bedeuten mehr Arbeit fuer die Firewall. Dies bedeutet laengere Ladezeit der Seite. Stromverbrauch und Serverlast sind vernachlaessigbar.
Guter Artikel, war Anfangs sehr skeptisch gegenüber CSS Frameworks. Werde es allerdings sicher in nächster Zeit einmal für ein Projekt ausprobieren.
@52eins
Die vielen HTTP Request bemerkt jeder einzelne. Denn für jede Datei muss der Browser eine neue Verbindung zu der spezifischen Adresse aufbauen. Das Aufbauen der Verbindung ist relativ langsam im Vergleich zum Download, daher ist es heute mit den schnellen Leitungen sinnvoller grössere, dafür wenigere Dateien zu machen.
Mal abgesehen davon, dass insbesondere dieses CSS-Framework uns quasi wieder in die Zeiten von Tabellen-Layouts führt: Der als Beispiel herhaltende HTML-Code ist leider nur wenig bis überhaupt nicht nach semantischen Gesichtspunkten aufgebaut (zusätzlich zu den nach Layout-Aspekten gewählten IDs wie “headerlinks” und “headerrechts”), was wiederum keine gute Werbung für CSS-Frameworks ist und Wasser auf den Mühlen von Kritikern dieser Frameworks.
Dieses Videotutorial erklärt das Ganze etwas besser: http://net.tutsplus.com/videos/screencasts/a-detailed-look-at-the-960-css-framework/
Ich bin echt am überlegen, das ist das erste Framework, das wirklich leicht zu bedienen ist.
Netter Artikel zum Thema und ein okayer Einstieg. Ich frage mich nur die ganze Zeit, warum die Code-Beispiele als Grafik eingebunden sind? Soviel zum Thema http-requests und ähm … Semantik.
“Und das mit den Requests ist auch nicht so eine “wilde” Sache. Zwar sprechen die fuehrenden CSS Gurus davon weniger Requests zu machen, dies gilt allerdings fuer hoch komplexe Seiten mit 10k+ unique Visitors.”
Sry, aber das ist Unfug. Wie einer meiner Vorredner schon sagte, zieht JEDER Request zwischen 50-100ms zusätzlicher Responsetime nach sich, bei Shared Hostern manchmal auch deutlich mehr, da der Server nicht jeden Taktzyklus auch auf allen gehosteten Domains gleichzeitig lauscht. Man sollte also sein “Ladefenster” so effizient wie möglich nutzen. Multipliziert wird diese Sache noch, wenn der z.b. PHP+MySQL laufen, da jede Anfrage z.b. noch eine DB-Abfrage triggern kann.
Kurz und gut : Während des Entwicklungsprozesses kann man gern auch mehrere CSS/Bilder der Übersichtlichkeit halber einbinden, bei der finalen,online gestellten Version AUF JEDEN FALL so wenig wie möglich, dies ist vollkommen zugriffsunabhängig !
“960.gs ist nicht für jedes Projekt geeignet, elastische Layouts sind damit überhaupt nicht zu machen.”
Schlecht recherchiert, da auf der Projektseite von 960 Links zu einer flexiblen [1] und elastischen [2] Portierung von 960 vorhanden sind.
[1] http://www.designinfluences.com/fluid960gs/
[2] http://csswizardry.com/typogridphy/
960 ist doch eher ein Baukasten als ein Framework. Mit so einem Grid-System ist man in speziellen Fällen sicher sehr schnell am Ziel, stößt man aber an die Grenzen wäre man mit einem echten Framework wie YAML besser beraten. Da müllt man den HTML-Quelltext auch nicht so extrem mit layoutspezifischen DIVs zu. Zudem lernt man beim Einstieg in YAML noch sehr viel über CSS.
@Paps: “Schlecht recherchiert”? Die beiden Links prangen auf der Site des 960.gs und sind kaum übersehbar.
Hätten hingegen SIE etwas recherchiert, hätten Sie festgestellt, dass es eben Lösungen sind, die nicht mit dem 960.gs, sondern unter erweiterter Verwendung desselbigen, mithin also nicht anhand des dokumentierten Standardumfangs erstellt worden sind.
Und wenn Sie dann schon so investigativ unterwegs sind, finden Sie vielleicht sogar noch den Weltnetzbeitrag, der zeigt, wie man Blueprint und 960.gs zusammen verwenden kann. Wären Sie dann nicht großartig?
Eben weil die beiden Links auf der Seite kaum übersehbar sind, wären diese eine Bereicherung des Beitrags gewesen, anstatt pauschal zu sagen, geht nich, auch wenn diese – wie gesagt – eine Portierung von 960.gs darstellen.
Ihr Artikel ist zwar für einen Einsteiger gut geschrieben, aber da nicht jede Seite in 960 Pixel fest betoniert ist, wäre ein Hinweis mehr als sinnvoll gewesen.
Genauso wie ger Hinweis auf das Variable Grid System [1] basierend auf 960.gs, welches – oh Wunder – auch auf der Seite verlinkt ist.
[1] http://www.spry-soft.com/grids/
Gut Paps. Danke für die konstruktive Kritik.
@all: Man kann mit dem 960.gs natürlich auch noch ganz andere Sachen tun. Es hängt lediglich davon ab, wie weit man den Ursprungscode verändern will oder kann. Ich empfehle da, wo man mit dem Leistungsumfang des 960.gs nicht mehr weiterkommt, ein anderes Framework in Erwägung zu ziehen. Ich empfehle NICHT, das 960.gs zu umzubiegen, dass es doch noch irgendwie passend gemacht ist. So führt man das Prinzip eines Framework, das ja gerade seine Stärke daraus bezieht, vorgefertigte Module und einen definierten Leistungsumfang zu bieten, nämlich ad absurdum.
Schließlich kauft man sich auch keine Textbausteinsammlung für sein Office und schreibt die dann alle um.
Hiho ich bin ein amateur und finde es wirklich super das Sie diesen Tutorial hier mit einer sehr ausführlichen Anleitung gepostet haben. Ich werde meinen nächsten Projekt mit 960.gs durchführen. Vielen Dank.