10.08.07 // Why content and presentation separation in HTML is a myth

Jeff Croft just published an article about the attempt of separating content and presentation with HTML. He writes: “[T]he idea that a redesign of anything more than the most basic of sites will not require changes to (X)HTML markup is simply a myth.”

Of course he’s right and here’s why: HTML was never meant to be not altered on a redesign, because a HTML document doesn’t contain only content, it also contains structure. It’s quite important to take that point into consideration when talking about this issue.

But shouldn’t we separate content and presentation? Well, we do. Nowadays, websites are most of the time database powered, with huge content management systems. Contents is safely and independently stored in these databases. So what are you doing with your CMS: you take the content, add a document structure to it, then you’ll likely style the page and add some behavioral javascript. So in reality there are four different layers. In static HTML documents the non-separation of structure and content really stands in the way of redesigning a site effectively. But the W3C has an solution for this problem, too: XML and XSLT.

XML contains the content. A headline, body text, a picture reference. XSLT then adds the structure. The whole content should stay in a div with class="hentry" and the headline will be in a h1. It indeed is like templating in modern CMS, like using smarty or another php solution (like wordpress does) or something like Textpattern with it unique XML like tags.

If you’re doing a redesigning, let’s say going from a two to a three column layout, that’s not only a matter of changing how the page looks like. The whole structure of the site may change in that step. And that change should be reflected in the markup, too.

Kommentare (Abonnieren)

  1. Link zu diesem Kommentarxwolf

    10. August 2007, 21:20 Uhr

    Ich finde die Argumentation nicht schlüssig.

    Denn sie geht allein davon aus, daß bei Jeff Crofts bisherigen Relaunches es nicht möglich war, weil die bisherigen Frameworks nicht asureichend waren.
    Er schreibt im Artikel: 1. Non-semantic class name hurt nothing. 2. The productivity and efficiency boost we got by all designers using a consistent framework that already accommodated for browser issues was enormous. 3. We were never, ever going to redesign our sites without changing the (X)HTML. It’s a nice thought, but it’s also a total pipe dream.

    Punkt 1 sagt garnichts. DIe Punkte 2 und 3 dagegen sprechen doch eher dafür, daß die verwendeten Frameworks entwedre nicht flexibel und universell genug waren, oder aber das Jeff Croft nicht fähig genug war. (Was ich mal verneinen möchte).

    Natürlich kann nicht jedes Framework beliebig angepasst werden. Dazu muss dieses schon sehr durchdacht sein. Ich hab selbige Arbeit zusammen mit Michael Charlier bei einem Projekt mal gemacht und wir haben dementsprechend auch Monate dazu verwendet ein Markup zu schafen, welches einserseits barrierefrei, andererseits Flexibel wie Zengarden ist, ohne dabei aber an Divitis zu erkranken. Das Ergebnis – und mitlerweise fast 40 Webauftritte mit 5 verschiedenen Verfahren zur Contenterstellung gibt dem Projekt recht. Es geht.
    YAML ist ein ähnliches Projekt.
    Doch solche universellen Frameworks brauchen nun mal Zeit. Zeit die man für einen einzigen normalen Webauftritt niemals aufbringen kann als Agentur.
    Zudem: Wenn es Jeff Croft um Webauftritte geht, die jetzt Relauncht wurden, müssen diese und die dort verwendeten Frameworks bereits entsprechend alt sein. Zu alt um neue Techniken und neue Erfahrungen zu beinhalten.
    Lange Rede kurzer SInn: Die Erfahrung die Jeff Croft da gemacht hat, mag zwar für alte Websites gelten, die mit verweiswasfür einen Framework gemacht wurden (vielleicht ja mit Frontpage- oder Dreamwürg 4-Vorlagen), aber man sollte sie nicht verallgemeinern.

  2. Link zu diesem KommentarEric Eggert

    10. August 2007, 23:18 Uhr

    Ich finde deine Argumentation nicht schlüssig.

    Wenn du in YAML 3 Spalten hast, dann hast du col1, col2 und col3 als Bezeichnung für die drei Spalten. Wenn du jetzt aber einen Text, einen Teil von Spalte 1 in Spalte 3 anzeigen willst, dann kannst du YAMLn bis dir die Finger bluten, du kommst nicht umhin das HTML, den Inhalt dort ausgeben zu lassen wo er hin soll – in Spalte 3. Und das ist eine Sache der Struktur des HTML-Dokuments, das hat nichts, aber auch gar nichts mit der Präsentation zu tun. Es gibt dann eben andere Kontexte für diesen Text.

    Ein ganz einfaches Beispiel: Mit YAML kannst du dein 3-Spalten-Layout natürlich neu stylen, das ist kein Problem. Aber vielleicht hat man in Spalte A die beiden Produkte P1 und P2 und in Spalte C die Produkte P3 und P4. Und für das Redesign will der Auftraggeber P1 und P3 in die A-Spalte und nur Produkt P4 in die C-Spalte. Dann kommst du nicht darum den Quelltext zu verändern.

    Außerdem scheint dir die Argumentation Jeff Crofts völlig abzugehen, er spricht sich gerade FÜR ein Framework aus. Und bei dem Framework – sagt er – kann man dann auch gerne diese Präsentationsklassen hernehmen. Und wenn dann ein Redesign ansteht und man den einen Container in 4 statt 3 Spalten teilen will, dann darf man auch gerne im HTML-Quelltext die Klasse von .theecols in .fourcols ändern.

  3. Link zu diesem Kommentarxwolf

    11. August 2007, 10:08 Uhr

    Ich glaub das Problem liegt in verschiedenen Sichtweisen auf die Art des Templates.
    Bei einer Trennung des von Content und Layout wie ich sie praktiziere, werde ich den Inhalt nie in 3 Bereiche trennen. Inhalt ist immer und grundsätzlich im Contentbereich – egal wie der Inhalt gestaltet wird.
    Die Gestaltung bezieht sich hauptsichlich dann auf die Struktur und die Optik der (dynamischen) Teile die nicht zum Content gehören. Vom Content selbst ändere ich über CSS meist nur Schriftstile und die Art der Darstellung von Absätzen und Blöcken (z.B. auch mit floats).
    Ich gebe dir recht, daß es nicht funktioniert, wenn man seinen Inhaltsteil in Bereiche aufteilt nur weil man die in einem Design anders darstellen will. Und deswegen braucht man ein Template, welches genau sowas nicht tut. Das dann dem CSS-Designer etwas mehr Gehirnschmalz abgefordert wird, sollte kein Hindernis sein :P

    Hm.. kann sein, daß wir dasselbe meinen, aber uns missverstanden.

  4. Link zu diesem KommentarEdoardo

    11. August 2007, 16:01 Uhr

    »Ein ganz einfaches Beispiel: Mit YAML kannst du dein 3-Spalten-Layout natürlich neu stylen, das ist kein Problem. Aber vielleicht hat man in Spalte A die beiden Produkte P1 und P2 und in Spalte C die Produkte P3 und P4. Und für das Redesign will der Auftraggeber P1 und P3 in die A-Spalte und nur Produkt P4 in die C-Spalte. Dann kommst du nicht darum den Quelltext zu verändern.«

    Da ändert sich aber einfach nur der Inhalt der Seite. Logisch daß man da im HTML-Quelltext was ändern muß. Die Struktur ändert sich nicht.

  5. Link zu diesem Kommentar/T

    13. August 2007, 10:58 Uhr

    Wolf, wenn ich neue Features auf einer Seite einbaue, die die Präsentation ändern, dann brauche ich unter Umständen »Hooks«, um diese Änderungen in die Seiten bzw. Templates einzuhängen. Was wiederum bedeutet, dass ich u.U. irgendwelche Container o.ä. mit für aussenstehenden sinnbefreiten IDs einbauen muss und damit in die Struktur eingreife.