Warum man Inhalt und Layout nicht trennen kann
02.04.2009 in: CSS, Markup, Sprache und Webdesign • 9 Kommentare
Letzte Änderung: 24.02.2010, 15:58 Uhr.
Jeder Webentwickler durchläuft (mindestens) drei Phasen:
- Totale Verwirrung: Markup, CSS, Zeichenkodierung und Scriptsprachen sehen wie ein riesiges Durcheinander aus, das sich unmöglich lernen läßt. Die Suche nach dem Tutorial bringt zu viele Ergebnisse. Diskussionen in Fachforen versacken allzu oft in Mißverständnissen.
Symptomatische Leitmotive: Jeder hat DSL. Alle Webseiten müssen überall gleich aussehen. Wenn nicht, optimiert man eben für einen Browser und weist darauf hin. Im Zweifel hat der User Schuld. - Erste Orientierung: Man beginnt meistens mit HTML und CSS und hält sich dabei an »Merksätze«, die man bei Leuten abholt, die erfolgreich vortäuschen, eine Autorität zu sein.
Symptomatische Leitmotive: Tabellen sind böse. Das W3C ist gut. XHTML ist die Zukunft. Validiere deine Stylesheets. Trenne Layout und Inhalt. - Ernüchterung: Man begreift, daß fast alle Merksätze falsch sind, Lügen, die eine Weile bei der Strukturierung des Wissens helfen, aber schlußendlich überwunden werden müssen, wenn man gute Webseiten entwickeln will. Diese Phase des skeptischen Pragmatikers erreichen bedrückend wenige Entwickler.
Symptomatische Leitmotive: Glaube nichts. Denke selber. Wenn ein Argument nicht durch Logik und Empirie begründet wird, ist es falsch oder wertlos.
Die angeblich erreichbare Trennung von Layout und Inhalt finde ich besonders schädlich: Sie schafft im Kopf des Entwicklers ein falsches Modell seiner Werkzeuge und Produkte und bremst somit seine eigene Entwicklung.
Warum?
Fangen wir erst einmal beim Layout an, und hier bei dem, was es nicht ist: Design.
Unter Design verstehe ich bewußtes Gestalten. Webdesign umfaßt so unterschiedliche Fachgebiete wie Informationsdesign (wann und wie sage ich was?), Interaktionsdesign (wie reagiere ich auf meine Besucher) und auch Interface- oder zu Mühdeutsch: Schnittstellendesign.
Layout gehört zum letztgenannten Punkt, füllt ihn aber nicht ganz aus. Es umfaßt vor allem die Ausgabe in visuellen Medien: Farbe, Form, Position, Makrotypographie. Ob man auch Mikrotypographie (wie beispielsweise die Wahl der Anführungszeichen und Pfeile) hier einsortiert oder die akustische Ausgabe – das soll uns hier nicht interessieren.
Das Wichtigste ist: Layout erfüllt einen Zweck.
Es transportiert durch alle oben genannten Mittel eine Botschaft an den Leser, hüllt Texte und Bilder in einen Kontext. Man stelle sich die Webseiten der SPD in Blau-Gelb vor – oder die der Efa mit einem animierten Hintergrundbild. Ein gutes Layout sagt etwas, ist Teil des Inhaltes.
Natürlich lassen sich Text- und Bildinhalte auf der Seite des Servers von anderen Elementen der Ausgabe trennen. So liegt dieser Text hier in einer Datenbank, während das HTML-Gerüst und die Stylesheets in einer Vorlage (Template) sitzen. Aber das ist keine Trennung in der Wahrnehmung der Leser, und sie ist auch alles andere als vollkommen: Ich habe die Vorlage extra so entwickelt, daß sie weitschweifige Texte wie diesen hier fassen kann.
Was ich für den Empfänger getrennt habe, sind nicht etwa Inhalt und Layout, sondern Struktur und Präsentation. Die Struktur ist das Markup (hier HTML 5) und die Reihenfolge der Abschnitte (Navigation, Text, Fußzeile). Die Präsentation wird durch CSS gesteuert.
Im Grunde war das eine ganz einfache logische Operation. Man kann kein gutes Layout entwerfen, wenn man Gegenstand und Länge der zu erwartenden Texte nicht kennt. Umgekehrt paßt nicht jeder Text in in jedes Layout. Beides muß gut aneinander angepaßt – gestaltet – werden, das ist kein Zustand, sondern ein Prozeß.
Um also von Phase 2 nach Phase 3 zu gelangen muß ein Entwickler das separat Gelernte – Markup, CSS, Bildbearbeitung und das Schreiben lesbarer Texte – im Kopf zu einem Ganzen fügen. Ein Modell, das genau das Gegenteil von ihm verlangt, wird ihn dabei mehr behindern als die Lähmung beider Hände.
Wer also zwischen Inhalt und Layout einen Unterschied sieht – ja, ich beende diesen Text mit einem entstellten Oscar-Wilde-Zitat – hat keines von beidem.
Ja, die Trennung von Struktur und Präsentation ist deutlich präziser als jene von Inhalt und Layout. Diesen Fokus hast Du gut vermittelt. Das Einschränkende daran ist das Befreiende daran: Der durch (X)HTML-Elemente strukturierte Inhalt ist unabhängig von seiner Präsentation.
Dass zum Inhalt (nicht zur Struktur...) auch die mediale Präsentation gehört, unterschreibe ich. Das ist übrigens der Fokus, den "Anfänger" als einzigen haben: Es muss erst einmal gut aussehen ( was immer das auch bedeutet).
Ich halte das für Haarspalterei der Begrifflichkeiten.
Natürlich trennst du Inhalt (= Struktur) vom Design (=Präsentation). Das dabei die Struktur u.U. auch eine gewissen Anteil Präsentation hat, liegt daran, dass HTML im Browser auch dargestellt wird. Es kommt also nicht im klassischen Sinne zu einer echten Trennung der Verantwortlichkeiten, die Grenze verwischt.
Ich kenne diese Trennung hauptsächlich aus der Programmierung, wo sie zum Teil sehr weit geht (Stichwort MVC). Aber z.b. in PHP vom Prinzip her aufgeweicht ist - dort ist das vermischen von HTML (Design) und Code (Struktur) der Grund für den Erfolg gewesen, den man heute versucht mit Templatesystem wieder rückgängig zu machen, was meines erachtens Unsinn ist, da PHP an sich ein Templatesystem ist. In anderen Sprachen sieht es aber anders aus und dort ist die Trennung von Inhalt (=Code) und Layout (=HTML) wichtig, weil Logik und Empirie gezeigt haben, dass man so besser damit arbeiten kann.
Darüber hinaus sehe ich "Merksätze" auch nicht als Dogma, sondern als Anhaltspunkte die bei der Entwicklung im Hinterkopf sein sollen und oftmals auch sehr verschieden ausfallen, da je nach tiefe der Abstraktion es auch nicht leicht ist verschiedene Verantwortlichkeiten sinnvoll zu trennen (für mich persönlich ist es z.b. beim MVC Pattern die Trennung zwischen Model und Controller, die ich nie 100% hinkriege).
Doch der Vorteil liegt auf der Hand, durch Trennung von Verantwortlichkeiten fällt es (für den Entwickler) leichter das Ergebnis anzupassen. Genau wie du es ja auch machst, du trennst Text, HTML und CSS. Der Empfänger spielt in diesem Prozess ja gar keine Rolle, der ist für nur wichtig wenn es um das Endergebnis geht. Und das muss man halt als Layout/Präsentation/Design bezeichnen, daher ist die Begrifflichkeit "Trennung von Inhalt und Präsentation" verwirrend, meint aber nicht mehr als das der Entwickler die Orte von HTML und CSS trennt und im Idealfall beides austauschen kann.
(Ach und dass mit den Tabellen, war zumindest aus meiner Sicht immer so gemeint, dass Tabellen möglichst nicht zu Layoutzwecken gebraucht werden, was früher ja Standard war und genau das sagt ja auch der Artikel auf "Vorsprung durch Webstandards". Tabellen für Daten waren nie böse)
@Struppi: Aus deiner, der Perspektive des Programmierers, die ich ja oft auch einnehmen muß, sind Inhalt und Layout zwei möglichst streng zu separierende Objekte. Und das ist auch richtig so; alles andere führt zu schlampigem Code.
Aber als Gestalter muß ich immer mehrere Perspektiven gleichzeitig beachten. Eine, ja die wichtigste, ist die des Empfängers. Und für den transportiert auch das Layout eine Botschaft: Es drückt aus, was der Sender von sich und vom Empfänger für ein Bild hat; es kann die Aussagen der Texte verstärken oder aufheben. In diesem Sinne ist eben Layout auch Inhalt.
Wer nur den Prozeß der technischen Erzeugung im Blick hat, kann keine gute Webseiten bauen. Wer ihn nicht versteht – auch nicht.
Deine Zweifel an zusätzlichen Template-Schichten in PHP teile ich übrigens ohne Widerspruch. Das war einer der ausschlaggebenden Punkte, weshalb ich mich für WordPress entschieden habe.
Oh, und Tabellen wurden ursprünglich eigens fürs Layout erschaffen. Aber das führt jetzt zu weit …
Struppi am 21.04.2009 · 16:58
Ich glaube nach wie vor, dass du die Begrifflichkeit zu eng siehst.
HTML hat ja durchaus Elemente, die etwas darstellen, z.b. Bilder und natürlich stellt eine Überschrift auch etwas dar, trotzdem gehört das Bild und die Überschrift zum Inhalt.
Ich würde die Begriffe sogar andersherum als du verwenden. Man trennt Layout und Inhalt, aber beides gehört zur Präsentation. Sowie du es in dem Artikel beschrieben hast, erst durch die Verbindung mit der Farbe des Layouts wird der Inhalt zu einer SPD Präsentation.
Letztlich willst du, wenn ich dich richtig verstanden habe, ja auch nicht darauf hinaus, dass man sein HTML und CSS Code miteinander vermischt, sonder nur das bei der Entwicklung immer an das Ganze gedacht wird, was in meinen Augen eine Selbstverständlichkeit ist, aber oft fällt deshalb die technische Trennung schwer und deshalb halte ich solche Leitsätze für wichtig. Da bei der Entwicklung, sei es einer Internetseite oder eines Programms, immer wieder die Versuchung eintritt, mal schnell etwas zu "hacken" und dabei Techniken zu vermischen, weil am Schluss ja eh alles zusammen kommt.
Ich kann davon ein Lied singen, weil ich gerade an einer Anwendung sitze, die ich vor 6 Jahren programmiert habe und jetzt seit ein paar Wochen dran sitze, um den Code komplett auf ein Templatesystem umzustellen und den ganzen HTML Code aus dem Programmcode raus zu kriegen.
Deshalb finde ich solche Merksätze gut und sie helfen mir zumindest auch viel bei der Entwicklung
Im Grunde habe ich gegen einen zu engen Begriff von »Inhalt« geschrieben. Jede Ausgabe an den Nutzer (meinst du das mit »Präsentation«?) ist ein Inhalt, wird von ihm interpretiert und zum Entziffern weiterer Inhalte benutzt.
Und ja, du hast mich richtig verstanden: Ich will keinesfalls Markup und CSS unnötig stark miteinander verbunden sehen. Der Blick aufs Ganze, darauf, wie das Ergebnis all der im Hintergrund separierten Techniken beim Empfänger ankommt – der ist nicht so selbstverständlich. Zumindest ist das meine Erfahrung.
Ein ewig prominentes Beispiel dafür ist die Schriftgröße: Von Leuten, die das Lesen am Bildschirm gewohnt sind und die gute Augen haben, wird dieser Wert nicht etwa im eigenen Browser angepaßt, sondern sie regeln sie auf ihren Webseiten herunter, im Stylesheet.
Die Botschaft an den Leser: Ich weiß besser als du selbst, was gut für dich ist, und es ist mir egal, wenn du das nicht einsiehst.
Natürlich nehmen die Gedanken im Kopf gerade nicht diesen Verlauf, sondern der Autor begreift nicht, daß er damit seine Glaubwürdigkeit insgesamt verspielt. Wenn er in seinen Texten dann über sein Ziel »barrierearme Webseiten« schreibt, hebt er diese Aussage durch die Layout-Komponente seines Inhaltes wieder auf.
Und genau diesen Punkt will ich ans Licht heben: Wer meint, Layout sei kein Inhalt, wird dieses Problem nicht einmal erkennen. Und wie soll er es dann beheben?
OK, das verstehe ich ;-)
Pointiert und Gut
Die Aufteilung in die 3 Phasen finde ich spitze. Wer möchte nicht bis Phase 3 aufsteigen?
Sicher kann man Dinge überspitzt darstellen, damit man andere anregt über einen Aspekt nachzudenken. Es wird hier die wichtigste Methode bei kopflastigen Aufgaben angesprochen: "Die Methode des genauen Hinsehens".
Rippie am 26.06.2011 · 21:07
Ein tolles Thema und ein super Beitrag dazu.
Ich bin auf diese Seite gestoßen, weil ich wissen wollte wo das Layout, von dem mir in jedem "Hilfe-Forum" erzählt wird, aufhört und wo der Inhalt beginnt.
Auf meine Verwirrtheit hin, wurde mir gegenüber geäußert, dass ich weder von CSS noch von HTML eine Ahnung hätte. Die Verwirrung auflösen konnte jedoch keiner.
Für mich ist TEXT klar als Inhalt zu definieren. Ein Banner ist für mich ein Teil des Layouts.
Eigentlich wäre die ganze Frage überflüssig, wenn einem nicht überall eingeredet werden würde, dass man für ein CSS-Layout keine Tabellen verwendet. Sicher ist es nicht zeitgemäß den Basis-Entwurf der Container nicht als Tabelle darzustellen, aber was ist, wenn man eine Seite hat, die neben der Navi noch ein darüber anwählbares Haupmenü im Main-Container aufweißt. Ist dieses Hauptmenü denn jetzt Inhalt oder Layout?
Ist es also sinniger eine CSS-Liste zu einer Tabelle zu formen und mit 50 Klassen und ID´s zu formatieren oder das Gleiche über eine einfache Tabelle mit 5 Klassen/ID´s zu lösen.
Zum Text... ich hätte gerne etwas mehr gelesen. Die Überschrift ist Interessanter als der Text selbst. :D
@Rippie: In dem von dir beschriebenen Fall geht es nicht ums Aussehen, sondern darum, wie du das Aussehen erzeugst. Eine Tabelle ist dazu ebensowenig nötig wie etliche Klassen oder ID-Attribute. Sie verursacht aber enorme Probleme, wenn sie auf einem kleinen Bildschirm ausgegeben wird, und dann wird sie tatsächlich zur Aussage, also zum Inhalt.
Die Botschaft: Leser, du bist mir egal. Ich wollte nur schnell fertig werden.