Diagnosen, die auf »itis« enden, bezeichnen in der Medizin das Krankheitsbild der Entzündung. Wenn nun von Divitis die Rede ist, dann bezeichnet diese Wortkreation wohl tatsächlich eine Krankheit, die Krankheit des übermäßigen und vollkommen unkontrollierten Einsatzes von DIV-Tags zum Zusammenbasteln des Inhalts einer Webseite.
Das Problem begann, als es in Mode kam, eine Website – die ominöse Homepage – sein eigen zu nennen. Jeder wollte dieses Statussymbol. Eine eigene Webadresse macht schon etwas her. Die Zeiten haben sich geändert, eines jedoch bleibt. Eine eigene Website gehört einfach dazu. Vor allem Firmen kommen heute kaum noch ohne eine Internetpräsenz aus.
Irgendwann kam jedoch der Punkt, an dem die alt hergebrachte Art und Weise eine Webseite zu strukturieren nicht mehr sehr beliebt noch angesehen war, nämlich die Strukturierung mittels Tabellen. Was also tun.
Viele Probleme, mit denen man als »Webdesigner« zu tun hat, sind darauf zurück zu führen, dass nicht alle Browser das gleiche tun, geschweige denn, sich an gemeinsame allgemeingültige Grundsätze halten – die Spezifikationen. Tabellen waren DAS Mittel, um diesem Problem im gewissen Maße Herr zu werden.
Nun aber zum Hauptproblem! Jeder darf sich Webdesigner nennen, und jeder, der sich auf dem Feld der Entwicklung von Webseiten bewegt, hat den heiligen Gral der Erkenntnis auf seinem Schreibtisch stehen. Jeder hat das ultimative Rezept. Leider verbreiten sich im Internetzeitalter Informationen schneller, als es einem manchmal lieb sein kann. Und so kursierten schnell Lösungen für das Tabellenproblem, denn Tabellen waren plötzlich gar nicht mehr so angesagt. Ganz im Gegenteil, es entwickelte sich sozusagen ein Antipattern[1], etwas, das gut dazu zu verwenden war, die Arbeit anderer zu bewerten, und das nicht immer positiv.
Qualität und Professionalität gehen aber nicht mit der Berufsbezeichnung einher, sondern sind das Ergebnis strukturierter Arbeit, durchdachtem Vorgehen und dem gewissen Blick für das große Ganze.
Und genau an dieser Stelle unterscheidet sich der wahre Fachmann vom Rest der Welt. Die Fähigkeit objektiv Lösungen zu bewerten und auf deren Basis geeignete Lösungen zu entwickeln, ist der deutlich bessere Weg.
Wer nun auf die Idee kommt, Tabellen aus dem Layout einer Webseite zu verbannen, ist sicher auf dem richtigen Weg, wenngleich es natürlich Anwendungsfälle für die Benutzung von Tabellen gibt. Eine weniger gute Idee ist es allerdings, sich daran zu machen, und dem nächsten Trend hinterher zu laufen: DIVs! Der pragmatische Ansatz, die alten Layouts zu modernisieren, in dem einfach alles auf DIVs umgebaut wird, ist sicher der falsche Weg.
Ein Symptom der Divitis ist, dass das Verhältnis zwischen Markup und eigentlichem Inhalt eines Dokumentes gegen Null tendiert. Tabellen sind in dieser Hinsicht bereits verschwenderisch, DIVs lösen ein Problem jedoch auch nicht. Viel Markup, wenig Inhalt, keine Struktur! Darüber hinaus, und dazu muss man nicht einmal den eigentlichen (X)HTML-Code der Webseite gesehen haben, sprechen umfangreiche Stylesheets dafür, dass etwas nicht stimmen kann, oder das Ergebnis ein wenig weiter vom Optimum entfernt ist, als erwartet. Die Verschachtelung von DIVs hat schließlich nur ein Ziel, bestimmtem Inhalt ein bestimmtes Aussehen zu geben und an einer bestimmten Position anzuzeigen. Zusammenhängende Strukturen sind im Dokument kaum zu erkennen.
Eine (etwas ältere) Liste der an Divitis erkrankten, unter Umständen prominenten Websites, ist hier zu finden. Allein ein Blick auf die Tabelle (ja, hier ist die Tabelle einmal für den richtigen Zwecke eingesetzt worden) verrät schon das ganze Ausmaß des Problems.
Was aber ist der Grund dafür? Wie kommt es zu Divitis? Oft beginnt man damit, ein Layout zu erstellen, noch bevor der Inhalt auch nur in Ansätzen ausgearbeitet ist. Das ist nicht weiter verwerflich, wenn man nicht von Beginn an das Ziel vernachlässigt oder es gar aus den Augen verliert. Was möchte man mit einer Webseite erreichen? Das Transportieren von Informationen ist noch immer das vorrangige Ziel, oder sollte es zumindest sein. Der zentrale Punkt ist also die Information, der Inhalt und nicht das Layout. Gut strukturierter Inhalt kann immer auf jede erdenkliche Art dargestellt werden. Dafür ist nicht viel nötig.
Gute Kenntnisse über die Möglichkeiten von CSS und nicht zuletzt über die richtige Verwendung von (X)HTML reichen bereits aus.
Leider sind nicht sehr viele Profis mit den Spezifikationen von HTML und XHTML vertraut, so scheint es zumindest. Wie das Problem des schlechten Codes eigentlich entsteht, müsste dem Fachmann eigentlich auffallen. Nämlich die falsche Verwendung der verschiedensten HMTL-Tags.
Jedes Element, das in (X)HTML spezifiziert ist, hat eine Bedeutung, eine Semantik. Diese Semantik bestimmt, wie und für welchen Zweck ein Element eingesetzt werden kann und darf. Leider gibt es niemanden, der die korrekte Verwendung überprüft, so dass fehlerhafte Verwendungen oft gar nicht auffallen. Die Browser werden es schon anzeigen, und wenn nicht, noch ein paar DIVs und Styles …
Die Gute Nachricht ist, es gibt eine Lösung. Die schlechte Nachricht ist, sie macht Arbeit. Arbeit kostet jedoch Geld, Nerven und fordert Disziplin.
Gehen wir das Problem doch einmal anders an. Nehmen wir an, wir machen uns zuerst Gedanken über den Inhalt einer Seite. Er muss nicht perfekt sein, aber eine Struktur sollte er besitzen. Das ist Arbeit, und es macht sicher mehr Spaß im Grafik-Programm des Vertrauens ein paar Pixel hin und her zu schieben. Dennoch wird sich der Aufwand lohnen, dann nämlich, wenn das Ergebnis auch wirklich den Erwartungen entspricht, weniger Nerven kostet und einen ganz anderen Qualitätslevel erreicht.
Wir haben also Inhalt. Als Faustregel gilt, der Inhalt ist perfekt strukturiert, wenn man durch einfaches Austauschen eines Stylesheets das Layout komplett ändern kann, OHNE Anpassungen am Markup. Erlaubt sind aber nur Element-Definitionen und möglichst wenig Identifikatoren und Klassen. DIVs sind ebenfalls tabu! Ein Hauptaugenmerk sollte dafür auf Gewichtgebende-Elemente wie Überschriften (<h1>…<h6>), Hervorhebungen (<strong>, <em>) usw. gelegt werden. Text braucht Struktur, um alle wichtigen Informationen auffindbar und ansprechend zu verpacken.
Einen guten Artikel über Trennung von Inhalt und Layout findet man auf InRetis.
Nun fehlt uns noch das Salz in der Suppe. Menüs, Banner, … einfach all das, was in der heutigen Zeit eine Webseite zu einer richtig guten Webseite macht. InRetis verwendet dafür folgende Aufteilung:

Um dies zu erreichen, werden fünf Bereiche benötigt (der Fußbereich fehlt in der Grafik). Und genau hier kommen nun DIVs zum Einsatz, und zwar entsprechend ihrer durch die Spezifikation vorgegebene Semantik. Ein DIV ist ein Container, nicht mehr und nicht weniger.
Als Kompromiss werden diese DIVs durch Identifikatoren mit Layout-Informationen versorgt. Dies bricht ein wenig die Trennung von Inhalt und Layout auf, beschränkt die Verflechtung von Styles im Dokument aber auf ein Minimum.
Anmerkung: Dieses Vorgehen ist nicht perfekt, und lässt sich durch die Verwendung geeigneter Selektoren in Bezug auf die Trennung besser lösen. Dies ist jedoch als Kompromiss zwischen Einfachheit und Konzepttreue zu werten.
Das Layout macht auch in Bezug auf das verwendete Markup Kompromisse. Im Kopfbereich werden die verschiedenen Elemente dadurch in Position gebracht, dass hier ebenfalls DIVs verwendet werden. Zählt man aber die verwendetet DIVs im gesamten Dokument, wird man sehen, dass man in diesem Fall mitnichten von Divitis sprechen kann.
DIVs sind nicht böse. Sie haben ihren Zweck. Werden sich so verwendet, wie es in der Spezifikation definiert ist, werden sie mit Bedacht eingesetzt, so sind sie ein guter Helfer für bestimmte Aufgaben. Ein übermäßiger oder gar exzessiver Gebrauch allerdings führt zu Divitis. Schwer wartbare und unübersichtliche Dokumente sind die Folge. Nicht zuletzt das überproportionale Anwachsen von Style-Definitionen ist ein Indikator dafür. Zeit gegen zu steuern.
[1] Antipattern: Antimuster oder entgegegesetztes Muster, Vorlage zu einem nicht zu empfehlenden Vorgehen.
31.08.2010 by Marco Hillebrecht Kategorien: Blog Tipps und TricksEine perfekte Webseite bedeutet nicht zuletzt, dass neben der Angabe des benötigten DOCTYPEs, einem soliden (X)HTML-Code-Gerüst und natürlich fehlerfreiem Code die Struktur der Webseite besondere Aufmerksamkeit erhält. Strukturelle Überlegungen dienen hierbei vor allem dazu, die Webseite auch aus Sicht des Codes übersichtlich zu halten, und dem Inhalt eine Struktur zu verleihen. Nicht zuletzt ergibt sich der Inhalt eines Dokumentes vor allem aus den Informationen, die für Menschen gedacht und lesbar sind. Alle anderen Daten sind Auszeichnungen, also Markup, der dazu dient, die Informationen des Dokuments inhaltlich zu strukturieren und maschinenlesbar zu machen.
Eine gute Struktur zeichnet sich dadurch aus, dass das Verhältnis zwischen eigentlichem Text und Markup möglichst groß ist. Das bedeutet, je weniger Markup, desto gewichtiger (auch für Suchmaschinen) ist der eigentliche Inhalt. Hierbei kommt es jedoch zu einem Problem. Code, der auf diese Weise gestaltet ist, vernachlässigt jegliche Art der Präsentation des Inhalts. Eine aktuelle Webseite lebt aber genau von dieser Präsentation. Grafiken, Farben, Banner, und Elemente außerhalb des eigentlichen Inhalts (z.B. Menüs) sind essentieller Bestandteil moderner Webseiten. Wie jedoch soll eine anspruchsvolle Präsentation erreicht werden, die darüber hinaus auch noch leicht pfleg- und wartbar ist? Kurzum, die Struktur des Dokumentes und somit seines Inhalts ist die Basis für ein perfekte Webseite. Sie ist das Bindeglied zwischen Dokument und Inhalt. Eine gute Struktur erleichter es erheblich, den Inhalt anprechend zu verpacken, ihm ein Layout zu geben.
Das Stichwort hier sind „Cascading Stylesheets (CSS)“ als Werkzeug für die Trennung von Inhalt und Layout. Der Einsatz von CSS ermöglicht es, das Design fast vollständig vom Inhalt zu separieren. Warum dies so wichtig ist, und wie man eine wirklich gute Struktur erhält, auf die sich jedes mögliche Layout anwenden lässt, soll nun gezeigt werden.
Folgender Code-Ausschnitt ist ein Beispiel dafür, wie zu den Anfangszeiten des Internet, noch bevor die Möglichkeit CSS zu gebrauchen verbreitet war, Layouts erzeugt wurden.
An diesem Beispiel kann man erkennen, wie eng verwoben die Layoutinformation und der eigentlichen Inhalt der Webseite sind. Jedem Element muss, wenn man es denn von der Standardformatierung abweichend behandeln will, eine Layoutinformation mitgegeben werden. Dies ist auch mit CSS nicht anders, jedoch wird bei der Verwendung von CSS dieses Problem deutlich eleganter gelöst. Die Problematik in diesem Beispiel ist aber vor allem die, dass bei Änderungen von Farben oder Positionen, diese an jeder Stelle im Code gemacht werden müssen. Vor allem bei größeren Websites kann dies mit erheblichem Aufwand verbunden sein.
Was also tun? Wir brauchen eine Möglichkeit Layouts zentral zu definieren, um sie mehrfach verwenden zu können. Die Vermeidung von doppeltem Code hilft zu dem, die zu übertragene Datenmenge schlank und die Dokumente klein zu halten. Was dazu fehlt, ist, eine Möglichkeit zu haben, einmal definierte Stile an den verschiedensten Stellen zu referenzieren. Und genau das bietet uns CSS.
Es ist nicht Sinn und Zweck dieses Artikels, eine umfassende Erläuterung zu CSS zu geben. Das Wichtigste soll aber an dieser Stelle und grundlegende Überlegungen angestellt werden, die helfen, zu verstehen, wie ein Dokument in idealer Weise aufgebaut ist.
Wie nun werden Stile definiert, auf die im Dokument referenziert werden kann?
Hierzu gibt es verschiedene Möglichkeiten.
Inline-Definitionen werden auf folgende Weise notiert:
Styles, die inline an ein Element gebunden werden unterscheiden sich nicht sehr von der Vorgehensweise im obigen Negativbeispielt. Warum?
Diese Art der Angabe von Style-Informationen macht im Prinzip das gleiche wie im obigen Bespiel, bedient sich aber lediglich dem Mittel CSS. Dies ist ein gutes Beispiel dafür, wie CSS nicht zwangsläufig zu besseren Ergebnissen in Bezug auf die Wartbarkeit oder Übersichtlichkeit des Codes führt. CSS ist also kein Allheilmittel. Vor allem aber nicht dann, wenn es falsch eingesetzt wird.
Eine Möglichkeit, die diese Variante bietet, und bei der sie (gut) eingesetzt werden kann, ist zur Entwicklungszeit. Auf diese Weise lassen sich schnell Dinge probieren und entwickeln, in fertigem Code hat diese Möglichkeit jedoch nichts zu suchen.
IDs sind eine Möglichkeit, Elementen eines Dokumentes eindeutige IDs zu geben. Eindeutig bedeutet selbstverständlich, dass diese ID nur ein einziges Mal innerhalb eines Dokumentes verwendet werden darf. So ist es nun möglich eine Definition zu erstellen, die gerade genau für dieses eine Element greift.
Dies ist in sofern ein Fortschritt, als dass nun die Layout-Definition an anderer Stelle als am Element selbst erfolgen kann. Die Kopplung von Inhalt und Layout wird auf diese Weise schon ein wenig aufgebrochen. Des weiteres ist weniger Code direkt am Element notwendig, so dass das Dokument auf diese Weise übersichtlicher wird.
Noch einen Schritt weiter gehen Klassen. Klassen stellen, wie der Name schon andeutet, gemeinsame Definitionen für ein Klasse von Elementen zur Verfügung. Alle Elemente, die zu einer Klasse gehören bekommen so dieselben Style-Definitionen zugewiesen.
Das globale Ändern einer Farbe beispielsweise ist so auf einfachere Weise möglich. Die Änderung an einer Stelle in den CSS-Definitionen ändert die Farbe bei allen Elemente, die zu der entsprechenden Klasse gehören.
Die Vermeidung duplizierten Codes wird so vermieden. Es muss also nicht ein und dieselbe Definition an vielen Stellen im Dokument eingefügt werden. Das erleichtert wieder die Handhabung UND fördert nicht zuletzt die Wartbarkeit.
Ähnlich der Klassen funktionieren Element-Definitionen. Diese Defintionen werden über den Namen des (X)HTML-Tags an jedes Element der Seite gebunden. Auf diese Weise ist es möglich, eine Definition zu erstellen, die dokumentweit für alle Elemente des gleichen Namen gilt.
Hier bleibt anzumerken, dass es sicher nicht der beste Weg ist, Style-Informationen in einem Dokument direkt zu notieren. Dies gilt für Identifikatoren und Klassen ebenso wie für Inline- und Elementdefinitionen. Ziel muss es immer sein, den (X)HTML-Code frei von Informationen zu halten, die dem Layout dienen. In der Praxis ist dies schon wegen der diversen Unzulänglichkeiten der verschiedenen Browser nicht immer einfach. Dennoch muss das Ziel klar sein: strikte Trennung von Inhalt und Layout!
Natürlich verfügt CSS über weitere Methoden und Mechanismen, die bei richtiger Verwendung ein mächtiges Werkzeug sind. Selektoren, Vererbung und Vorrangregeln sind hier die Stichworte. Leider würde eine detaillierte Abhandlung darüber den Rahmen dieses Artikels bei weitem sprengen.
Jedes HTML-Element hat eine bestimmte Bedeutung. Der durch diesen Tag ausgezeichnete Text erhält durch die richtige Verwendung von HTML-Tags eine bestimmte semantische Bedeutung.
<p></p> zum Beispiel steht für einen Text-Absatz. Die Semantik des in diesem Tag enthaltenen Textes erschließt sich also durch die Auszeichnung mittels <p>. Durch die Verwendung dieses Tags wird der verwendete Text semantisch zu einem Absatz.
Für jeden Zweck gibt es in (X)HTML ein Element, das zur Auszeichnung verwendet werden kann, um eine bestimmte Semantik zu erzeugen. Leider wird dies viel zu oft vernachlässigt. Divitis, also der exzessive und zum Teil semantisch einfach falsche Gebrauch von Bereichen (DIVs), ist ein gutes Beispiel hierfür.
Eine wichtige Regel also ist: Jedes HTML-Element hat seine eigene Semantik, und sollte dieser entsprechend eingesetzt werden!
Anhand eines Menüs soll nun gezeigt werden, wie zum einen die strikte Trennung von Design und Information erfolgen kann, zum anderen auch, wie die Semantik der verfügbaren HTML Elemente genutzt werden kann, um diese Trennung durchzusetzen.
Wie man sieht, enthält der Code des Beispiels kaum noch sichtbare Verknüpfungen zu Layout-Informationen. Lediglich id="nav" und das link-Tag stellen noch einen Bezug her. Sucht man nun nach Infomationen darüber, wie die ausgezeichneten Elemente mit Layout-Informationen versehen werden, so ist die referenzierte Stylesheet-Datei der richtige Ort. Hier und nur hier, wird bestimmt, wie der Inhalt layoutet wird.
Genauso wichtig aber ist, dass hier bewusst Wert auf die semantisch korrekte Verwendung von HTML-Tags gelegt wurde. Nimmt man an, dass die Links eines Menüs, egal ob nun in horizontaler oder vertikaler Ausrichtung, einer Liste gleichen, so bietet es sich natürlich an, diese auch mit der Semantik einer Liste zu versehen. Über die Verwendung von Stylesheets ist es nun möglich, dieser Liste das gewünschte Layout zu geben.
Der obige Code ist schlank, übersichtlich aber vor allem leicht zu erfassen. Sicher mag dies ein recht einfache Beispiel sein, jedoch muss dies das Ziel der Bemühungen sein, wenn man die perfekte Webseite entwickeln will.
Teil 5 unserer Artikelreihe 10 Tipps für eine perfekte Webseite trägt den Titel
DIVitis? – Ist meine Webseite krank?. In diesem Artikel wird noch einmal genauer beleuchtet, was der Sinn von (X)HTML eigentlich ist, und welche Bedeutung die semantisch korrekte Verwendung der zur Verfügung stehenden Tags hat.
Der vorherige Beitrag aus unserer Reihe »10 Tipps für eine perfekte Webseite« hat sich damit befasst, wofür ein DOCTYPE verwendet wird, und warum dieser so wichtig ist. In diesem Artikel soll nun eine komplette Vorlage zur Erstellung einer perfekten Webseite entwickelt werden, das (X)HTML-Code-Gerüst!
Nach der Deklaration des DOCTYPE folgen nun eine ganze Reihe von Angaben und Definitionen, die für den korrekten Aufbau einer Webseite benötigt werden. Einige dieser Angabe sind zwar optional, erfüllen aber dennoch eine wichtige Aufgabe, wenn es darum geht, das Optimum mit einer Webseite zu erreichen. Diese Angaben können Meta-Daten sein, die es den Suchmaschinen erlauben (oder eben auch nicht), die vorliegende Seite zu indexieren, Snippets im Suchergebnis anzuzeigen, …
Welche Elemente des Codes einer Webseite zwingend erforderlich sind, welche Elemente zum guten Stil gehören und welche Elemente einen darüber hinausgehenden Zweck erfüllen, wollen wir in Teil 3 unserer Artikelreihe »10 Tipps für eine perfekte Webseite« vorstellen.
Die Auszeichnungssprache HTML basiert im Kern auf der Verwendung von sogenannten Tags. Dieses Tags sind es, aus denen die Struktur einer Webseite erzeugt wird, und deren Zweck es ist, die enthaltenen Informationen zu strukturieren. Zwar ist es möglich, mittels HTML den enthaltenen Informationen ein Aussehen zuzuweisen, jedoch ist dies KEIN guter Stil, und erschwert die Entwicklung und die Wartung einer Webseite zum Teil erheblich.
In der Informatik allgemein ist es üblich, jedem Teil eines Ganzen nur eine Verantwortlichkeit zu übertragen UND doppelten Code zu vermeiden. Der Sinn ist einleuchtend. Wird doppelter Code verwendet, so kann sich die Fehlersuche in der Hinsicht erschweren, dass ein und derselbe Fehler an vielen Stellen im Code vorhanden sein kann. Wird nun eine Änderung gemacht, muss diese zwangsläufig an vielen Stellen gemacht werden. Wird nur ein Vorkommen vergessen oder übersehen, so kommt es zu schwer behebbaren Fehlern. Ebenso verhält es mit den Verantwortlichkeiten. Wird ein Teil eines Ganzen mit mehreren Verantwortlichkeiten ausgestattet, so kann es sein, dass nicht genau festgestellt werden kann, welcher Code nun welches Ergebnis erzeugt. Auch dies erschwert wieder die Fehlersuche.
Teil 4 der Artikelreihe »10 Tipps für eine perfekte Webseite« wird sich genau damit befassen. Der Trennung zwischen Inhalt und Darstellung. Durch diesen Ansatz sollen die eben genannten Probleme vermieden werden.
Aber zurück zum Thema. (X)HTML wird verwendet, um die Struktur einer Seite zu definieren, die Inhalte logisch auszuzeichnen und für den Browser verwertbar zu machen. Und genau das ist der Zweck von HTML. Informationen so zu verpacken, dass Browser die enthaltenen Informationen verarbeiten können.
Schematisch besteht ein (X)HTML-Dokument aus zwei übergeordneten Bereichen:
Dieser Bereich steht immer am Beginn einer (X)HTML-Datei und enthält maximal zwei Blöcke an Information.
Für den Fall, das XHTML als DOCTYPE verwendet wird, beginnt die Datei mit
Diese Zeile teilt dem Browser mit, dass das vorliegende Dokument nach den Regeln von XML (Version 1.0) aufgebaut ist. Die verwendete Zeichenkodierung ist UTF-8. Diese Zeichenkodierung definiert, welche Kodierung dem Dokument selbst zugrunde liegt, nicht die Zeichenkodierung des Inhaltes des Dokumentes. Zu dem besagt diese Zeile, dass das vorliegende Dokument gültig (valide) gemäß der Spezifikation von XML sein muss, denn es handelt sich ja um ein XML_Dokument. Hierbei ist speziell auf korrekte Verschachtelung der HTML-Elemente zu achten sowie der Regel, dass zu jedem öffnenden auch schließendes Tag gehört.
Danach folgt der DOCTYPE.
Welchen DOCTYPE Sie verwenden, richtet sich nach den technischen Gegebenheiten sowie den eigenen Vorgaben. Eine ausführliche Beschreibung darüber, wie DOCTYPEs verwendet werden, finden Sie in Teil 2 unserer Artikelreihe »10 Tipps für eine perfekte Webseite«.
Beispiel:
Im Code-Bereich des Dokumentes werden nun die eigentlichen Inhalte angegeben und ausgezeichnet. Alles, was hier notiert wird, muss nun den Regeln von HTML bzw. XHTML gehorchen. Hierbei gibt es sehr wohl Unterschiede. Einige der wichtigsten Unterschiede seien hier kurz erläutert.
Je nachdem, welcher DOCTYPE verwendet wird, muss das vorliegende Dokument verschiedenen Regeln gehorchen. Im Falle von XHTML sind dies die folgenden:
HTML-Dokumente können, sollten aber nicht, lockerer gestaltet sein.
Folgende Code-Gerüste geben das Minimum dessen an, was für ein Dokument auf Basis von HTML oder XHTML zwingend erforderlich ist.
Es sei erwähnt, dass durch die Browser nicht geprüft wird, ob die vorliegenden Dokumente korrekt im Sinne der Spezifikation sind. Es werden also auch Dokumente zur Anzeige gebracht, die nicht valide oder konform zur Spezifikation sind. Das bedeutet jedoch nicht, dass es eine gute Idee ist, nicht gültige oder wenigstens korrekte Dokumente zu erstellen. Je nach Browser kann es zu gravierenden Anzeigeunterschieden kommen, wenn der Code nicht korrekt ist.
Einige wichtige Ergänzungen, die im Kopfbereich (head) der Webseite notiert werden, sollen hier genannt werden. Alle Angabe sind in XHTML-Notation.
Entgegen der Angabe der Zeichenkodierung für das vorliegende Dokument im XML-Header bezieht sich diese Angabe darauf, welche Zeichenkodierung für den Inhalt der Webseite verwendet wird. Fehlt diese Angabe, kann es zu Anzeigefehlern kommen, da der Browser fälschlicher Weise eine falsche Zeichnkodierung voraussetzt. Gut zu beobachten ist dieses Phänomen, wenn eine Webseite auf einem Macintosh und einem PC betrachtet wird. Fehlt diese Angabe, setzt der Macintosh Unicode voraus, und kann z.B. Umlaute nicht darstellen. Daher: immer angeben, welcher Zeichkodierung der Inhalt eines Dokumentes folgt.
Angabe der relavanten Schlüsselwörter (Keywords) des aktuellen Dokumentes. Wichtig: Nur Schlüsselwörter verwenden, die auch tatsächlich im Text vorkommen. Suchmaschinen bewerten es unter Umständen negativ, wenn Keywords verwendet werden, die nicht im Text vorhanden sind.
Kurze Beschreibung des Inhalts der Seite. Dies kann von Suchmaschinen verwendet werden, um im Suchergebnis anzuzeigen, welchen Inhalt der Besucher zu erwarten hat.
Verwenden Sie diesen Tag, um dem Crawler der Suchmaschinen mitzuteilen, ob das vorliegende Dokumente indexiert werden soll. Dieses Beispiel erlaubt der Suchmaschine die vorliegende Seite in den Index aufzunehmen UND den enthaltenen Links zu folgen.
Und nun, zu guter Letzt das komplette Code-Gerüst.
Natürlich kann es sinnvoll sein, das hier vorgestellte Gerüst um weitere Angaben zu erweitern. Dies richtet sich vor allem danach, welcher Ausrichtung die Seite folgt. Vor allem in Richtung Suchmaschinen und einer dahin gehenden Optimierung können weitere Elemente hinzukommen. Die Bedeutung dieser Elemente mag ebenso gewichtig sein, wie die der bisher genannten. Eine eingehende Erläuterung in Rahmen dieses Artikels ist jedoch nicht möglich.
Bemühen Sie sich, stets valide und (syntaktisch) korrekte Dokumente zu erstellen und an den Client zu liefern. Vor allem die Konsistenz in der Anzeige, die Verarbeitungsgeschwindigkeit und nicht zuletzt die Qualität Ihres Produktes werden es Ihnen danken. Sicher gibt es immer einen leichtern Weg, der im ersten Moment einfacher, besser und einfach unproblematischer erscheint. Die Erfahrung zeigt jedoch, dass Einfachheit ein lohnendes Ziel ist. Jedoch muss immer die Qualität im Vordergrund stehen. Machen Sie es „so einfach wie möglich, aber so komplex wie nötig“! Gerade bei der automatischen Verarbeitung von Daten sind Regeln außerordentlich wichtig. Zwar kommt man im Bereich der Webentwicklung auch gut zurecht, wenn man nicht alle Regeln genau nimmt, eine zu lockere Auslegung dieser Regeln wird sich aber früher oder später rächen.
Machen Sie sich Ihr eigenes Bild.
Tipp 4: Trennung von Inhalt und Layout
31.08.2010 by Marco Hillebrecht Kategorien: Blog Tipps und TricksBisher haben wir uns in der Artikelreihe damit befasst, was für eine Webseite essentiell ist, nämlich fehlerfreier Code. Nun ist es Zeit, auf die in diesem Artikel angerissenen Punkte näher einzugehen und Schritt für Schritt zu zeigen, wie ein Webdokument aufgebaut ist, und was bei dessen Aufbau zu beachten ist. In den nächsten Folgen dieser Artikelreihe soll es also darum gehen, wie ein vollständiges Webdokument definiert wird.
Neben den reinen Nutzdaten, benötigt ein solches Dokument noch eine Reihe weiterer Angaben, die es dem verarbeitenden Programm, meist einem Browser, ermöglichen, den enthaltenen Code fehlerfrei und eindeutig zu interpretieren.
Teil 2 unserer Artikelreihe »10 Tipps für eine perfekte Webseite« befasst sich mit einem wesentlichen Bestandteil eines jeden Webdokumentes, dem DOCTYPE.
Der DOCTYPE– genauer die Dokumenttypdefinition (englisch Document Type Definition, DTD) – kann als ein Satz von Regeln betrachtet werden, die beschreiben, wie ein Dokument eines bestimmten Typs aufgebaut sein muss.
Genauer gesagt teilt die DOCTYPE-Definition dem verarbeitenden Programm mit, welche Art von Code das zu verarbeitenden Dokument enthält und entsprechend welcher Regeln der Code erstellt wurde. Somit wird durch den DOCTYPE quasi die Syntax definiert, der das Dokument gehorcht. Ein Programm erhält somit einen wertvollen Hinweis darauf, wie der vorliegende Code zu behandeln ist.
Hierbei kann es durchaus zu gravierenden Unterschieden in der Darstellung kommen, da nicht alle Elemente, die durch HTML definiert werden, in allen Dokumenttypen erlaub sind. Dazu aber später mehr.
Es gibt eine Vielzahl von Dokumenttypen. Für die Verwendung innerhalb einer Webseite kommen aber nur ein paar wenige infrage.
Ein HTML- oder XHTML-Dokument wird nach einem festen Schema aufgebaut. Dieses Schema ist in der Dokumenttypdefinition spezifiziert. In dieser Spezifikation ist auch enthalten, welcher der verschiedenen Spezifikationen das aktuelle Dokument unterliegt.
Um ein gültiges (valides) Dokument zu erstellen, ist es immer erforderlich, den verwendeten Dokumenttypen zu spezifizieren, und sich an die Regeln des angegebenen Dokumenttyps zu halten. Im Umkehrschluss bedeutet dies, dass ein Webdokument, also eine Webseite, nie ein gültiges Dokument sein kann, wenn es auf die Angabe des DOCTYPE verzichtet. Zwar ist es keine zwingende Voraussetzung, einem Browser ein valides Dokument vorzusetzen, was aber passieren kann, wenn man dies dennoch tut, ist einleuchtend.
Kennt der Browser den vorliegenden DOCTYPE nicht, wird versuchen, den vorliegenden Code dennoch zu interpretieren. Dies geschieht in der Annahme, dass das vorliegende Dokument einem Standard-DOCTYPE genügt. Auf Basis dieser Annahme wird er nun versuchen, das Dokument zu interpretieren. Sicher wird er zu einem Ergebnis kommen, das Ergebnis mag aber weit von der Erwartung entfernt sein. Um dies zu vermeiden, empfiehlt sich die Angabe des DOCTYPES. Zum einen um Fehlinterpretationen vorzubeugen und auszuschließen, aber auch um die Regel einzuhalten, dass für gültige Dokumente die Angabe des DOCTYPES zwingend erforderlich ist. Hier schließt sich nun der Kreis.
Nachdem wir uns nun darüber einig sind, dass ein DOCTYPE für jedes Webdokument nicht nur Sinn macht, sondern auch zwingend vorgeschrieben ist, wollen wir uns ansehen, wie und wo diese Definition in ein Webdokument eingefügt wird.
Sinn macht die Angabe des DOCTYPES natürlich nur am Beginn eines Dokumentes. Auf diese Weise wird dem verarbeitenden Programm die Möglichkeit gegeben, diesen auf einfache Weise zu extrahieren.
Der genaue Aufbau eines (X)HTML-Dokumentes ist Thema in Teil 3 dieser Artikelreihe.
Für die Verwendung in Webdokumenten existieren sieben wichtige Dokumenttypdefinitionen. Welche Variante Verwendung findet, hängt zum einen von der Intention des Dokumentes ab, zum anderen aber auch von den technischen Gegebenheiten. Generell ist es immer zu empfehlen, die Variante zu wählen, die striktere Vorgaben in Bezug auf die Syntax macht. Zwar wird der Aufwand bei der Erstellung des Codes etwas höher ausfallen, da nicht alle Elemente irgendwo verwendet werden können, die Ausführungsgeschwindigkeit ist aber evtl. höher. Der Grund dafür ist, dass durch die strikteren Vorgaben bei der Interpretierung des Codes entsprechenden Optimierungen vorgenommen werden können. Und natürlich, das Finden von Fehlern wird zum Teil deutlich vereinfacht.
Folgende Varianten stehen zur Verfügung
HTML 4.01 Transitional
HTML 4.01 Strict
HTML 4.01 Frameset
XHTML 1.0 Transitional
XHTML 1.0 Strict
XHTML 1.0 Frameset
XHTML 1.1
Eine allgemeingültige Lösung zur Auswahl des richtigen DOCTYPEs gibt es nicht. Wir, d.h. die Entwickler von i:MotioN, haben aber natürlich einen klaren Favoriten:
XHTML 1.0 Strict
Warum aber verwenden wir diesen DOCTYPE für unsere Projekte? Die Gründe sind folgende:
All diese Gründe haben ein Ziel, nämlich qualitativ hochwertigen Code. Durch die strikten Vorgaben in Bezug auf den Aufbau des Codes ist es möglich, Fehlerquellen zu vermeiden, die Fehlerfindung zu erleichtern und nicht zuletzt die Ausführungsgeschwindigkeit zu steigern. Nicht zuletzt führt eine hohe Qualität auch dazu, dass Anzeigen konsistenter und somit vorhersagbarer werden, schon zur Entwicklungszeit. Das spart nicht nur Arbeit und somit Zeit während der Entwicklung sondern vereinfacht auch das Finden von Fehlern.
Fazit: Strikte Vorgaben darüber, wie Code zu gestalten ist, mögen auf den ersten Blick als gängelnd und überflüssig erscheinen. Bei genauerer Betrachtung hilft dies jedoch vor allem Fehler zu vermeiden und sogar Geschwindigkeitsvorteile zu erzielen. Jeder, der sich mit der kommerziellen Entwicklung von Webseiten beschäftigt, muss ein Interesse daran haben, qualitativ hochwertige Ergebnisse zu liefern. Die einfache Verwendung des richtigen DOCTYPE fördert und fordert auf simpelste Weise. Ein Aufwand der sich lohnt.
Und um diese Thema geht es das nächste Mal:
Tipp 3: Das (X)HTML-Code-Gerüst
31.08.2010 by Marco Hillebrecht Kategorien: Blog Tipps und TricksDies ist nun also Teil 1 unserer Artikelreihe »10 Tipps für eine perfekte Webseite«. Im Rahmen dieser Reihe wollen wir einen kleinen Einblick geben, was nötig ist, um eine professionelle Webseite zu erstellen, und woran man eine gute Seite erkennt. Ein Blick hinter die Fassade kann sich immer lohnen, vor allem wenn man beurteilen möchte, ob Preis und Leistung der eigenen Seite stimmen. Hierbei wollen wir den Fokus vor allem auf den Code der Seiten selbst, also den (X)HTML-Code legen. Schließlich wird das was Sie sehen, durch diesen Code erzeugt. Lassen Sie uns schauen, wie aus einer einfachen Webseite die perfekte Webseite wird.
Der Code einer Webseite, also eines einzelnen Dokumentes, das aus dem Netz abgerufen und im Browser zur Anzeige gebracht wird, kann mitunter sehr komplex sein. Genau hier beginnen die Probleme. Leider werden auch Webseiten von einem Browser zur Anzeige gebracht, die genaugenommen gar nicht anzeigefähig sind, weil sie nämlich gegenüber der Definition von (X)HTML fehlerhaft sind. In »richtigen Programmiersprachen« wird beim Auftreten fehlerhafter Anweisungen die weitere Verarbeitung abgebrochen. Dies macht auch Sinn, da durch die falsche Verwendung von Anweisungen das Programm evtl. aber sogar der Rechner zum Absturz gebracht werden kann.
Im Browser sind die Folgen nicht derart dramatisch, denn jeder Browser ist gewissermaßen gutmütig, und verzeiht den einen oder anderen Fehler. Darüber hinaus handelt es sich bei HTML-Code nicht um ausführbaren Code, der direkt im Prozessor des Rechners ausgeführt sondern vom Browser interpretiert wird. Leider verhalten sich alle Browser unterschiedlich, und somit kann die Anzeige entsprechend stark variieren. Vor allem dann, wenn fehlerhafter Code verhindert, dass der Browser diesen korrekt interpretieren kann. Er wird Annahmen treffen, und versuchen, doch noch ein Ergebnis zustande zu bringen. Eines aber ist sicher, den Erwartungen wird dieses Ergebnis mit großer Wahrscheinlichkeit nicht entsprechen.
Die Definition von »fehlerfrei« ist komplex, jedoch im Bezug auf die syntaktische Fehlerfreiheit von Code eher einfach.
Das bedeutet also, dass der Code einer Webseite dann fehlerfrei (valide) ist, wenn er ausnahmslos die Regeln, wie sie in der HTML-Spezifikation des W3C definiert sind, einhält. Leider aber gibt es an dieser Stelle zwei Probleme. Erstens, auch wenn der HTML-Code einer Webseite valide ist, so kann es doch vorkommen, dass das Ergebnis im Browser mangelhaft aussieht, es zu Anzeigefehlern kommt. Dies hat den Grund, dass es noch immer einige Browser mit der Standardkonformität nicht so genau nehmen. Zweitens, Browser melden die Fehler im Code nicht an den Benutzer.
Zumindest für den zweiten Fall gibt es allerdings Abhilfe. HTML-Validator, ein Plugin für den Firefox-Browser, ermöglicht es, auf den ersten Blick zu erkennen, ob die vorliegende Seite fehlerfrei im Sinne der HTML-Spezifikation ist. Darüber hinaus kann aber auch ein Online-Tool des W3C verwendet werden, um eine bestimmte Seite auf Fehlerfreiheit zu überprüfen. Mit diesem Link überprüfen Sie zum Beispiel diese Seite auf Fehler.
Je nach verwendetem DOCTYPE, ist die Verwendung bestimmter HTML-Elemente zwingend vorgeschrieben. Zu Dieser Gruppe von Elementen gehören DocType-übergreifend die Wurzelelemente html, head und body. Ein Dokument ohne diese Elemente wird zwar noch immer zu einer Anzeige führen, ist aber keinesfalls korrekt. Hierbei ist es nur der Gutmütigkeit des jeweiligen Browsers zu verdanken, dass etwas angezeigt wird. Dazu zählt auch das Element title, welches zum Beispiel in den XHTML-Varianten zwingend vorgeschrieben ist. Natürlich macht dieses Element auch bei der Verwendung eines anderen DOCTYPEs Sinn, da der Inhalt dieses Elementes in der Titelzeile des Browsers angezeigt wird, sowie von Suchmaschinen zur Bewertung des Inhaltes einer Seite herangezogen wird.
Merke: Zu fehlerfreiem Code gehört immer, die zwingend erforderlichen (X)HTML-Elemente (in der vorgesehenen Weise) zu verwenden. Eine gute Referenz zu den exitierenden HTML-Elementen und deren Verwendung ist unter SELFHTML zu finden.
Zu jedem öffnenden Tag gehört ein schließendes Tag. Dabei spielt der DOCTYPE keine Rolle. Ausnahmen machen an dieser Stelle jedoch wieder die verschiedenen Browser, deren Hang zur Gutmütigkeit bei der Interpretierung des Codes, schon einmal ermöglicht, den ein oder anderen schließenden Tag unter den Tisch fallen zu lassen. Dies führt oft jedoch wieder zu Problemen. Vor allem dann, wenn Folgefehler durch das Weglassen von schließenden Tags provoziert werden. Ab einem gewissen Punkt kann der Browser den Code nicht mehr korrekt interpretieren.
Merke:
Zu jedem öffnenden Tag gehört schließendes Tag. IMMER!
Ein Browser stellt eine Webseite dar, indem er die in der Adresszeile angegebene Datei vom Server abruft, und den Inhalt der Datei interpretiert. Hierbei folgt er gewissen Regeln, die durch die Sprachdefinition von (X)HTML vorgegeben sind. In der Sprachdefinition ist ebenfalls vorgegeben, welche Elemente innerhalb welcher Elemente verwendet werden dürfen. Verschachtelungsfehler entstehen dann, wenn entweder nicht zulässige Elemente innerhalb anderer Elemente verwendet werden, dies aber laut Sprachdefinition nicht erlaubt ist. Vor allem aber die Nichteinhaltung der Reihenfolge von öffnenden und schließenden Elementen führt dazu, dass die Anzeige des Browsers nicht dem entspricht, was erwartet wird. Hier ein Beispiel:
korrekt: <p><div></div></p>
Fehler: <p><div></p></div>
Attribute von HTML-Elementen dienen dazu, ein Element näher zu beschreiben, und mit weiteren Eigenschaften zu versehen. Welche Attribute mit welchem Element verwendet werden dürfen ist Teil der Spezifikation. Genau diese Spezifikation beschreibt auch, wie diese Attribute korrekt verwendet werden.
Merke:
Jedes Attribut muss in Hochkommata(") angegeben werden! Attribute dürfen nur dort verwendet werden, wo sie laut Spezifikation vorgesehen sind.
So ist es richtig (XHTML-Notation):
<img src="…" width="10" height="10" alt="ein Bild" />
So ist es NICHT richtig (XHTML-Notation):
<img src=… width=10 height=10 attribut=text />
Die DOCTYPE-Definition gibt in jedem Dokument an, nach welchem Teil der (X)HTML-Spezifikation sich das vorliegende Dokument richtet. Diese Angabe verwendet der Browser, um zu bestimmen, welcher Anzeigemodus verwendet wird. Fehlt die DOCTYPE-Deklaration, nimmt der Browser an es handele sich um die Standard-Defintion. Auch hier kann es so wieder zu ungewünschten Effekten bei der Anzeige kommen. Es empfiehlt sich also, die Deklaration des verwendeten DOCTYPE in jedes Dokument einzufügen.
Genau um dieses Thema geht es im nächten Artikel dieser Reihe:
Tipp 2: Kein Dokument ohne DOCTYPE!
Wer kennt sie nicht die Probleme beim Entwurf eines Layouts für eine Webseite und der letztendlichen Umsetzung derselben. Oft werden gelungene Layouts dadurch kompromittiert, dass bei der Überführung in den entsprechenden (X)HTML-Code, Kompromisse gemacht werden müssen. Der Grund hierfür ist meist, dass die verschiedenen Browser den Inhalt auf unterschiedliche Weise interpretieren, und sich nicht immer an die gängigen Standards halten. Manchmal mögen die Auswirkungen gering sein, manchmal kosten sie viel (Test)Arbeit und somit Geld. Wenn man jedoch ein paar Grundregeln beachtet, lassen sich nicht nur diese Probleme reduzieren, sondern auch noch bessere Ergebnisse erzielen und das zu einem angemessenen Preis. Unsere Artikelreihe soll ein kleiner Helfer sein, der die wichtigsten Probleme beim Codieren einer Webseite aufzeigt und Lösungsansätze vorstellt, die helfen, die häufigsten Probleme mit einfachen Mitteln in den Griff zu bekommen.
Wenn man in den Weiten des Netzes unterwegs ist, vielleicht um nach Anregungen zu suchen, so kommt es vor – mehr oder weniger oft – dass man es sich nicht verkneifen kann, sich einmal den Code anzusehen, der hinter der Präsentation einer Webseite steht. Welcher (X)HTML-Code führt zu der Anzeige im Browser, die gerade betrachtet wird? Wie machen es andere? Dabei kommen immer wieder Dinge zum Vorschein, die im besten Fall zum Schmunzeln anregen, die aber auch haarsträubend sein können. Manchmal machen sich Fehler sogar in offensichtlicher Weise bei der Darstellung bemerkbar — das Schlimmste, was passieren kann.
Unsere Artikelreihe »10 Tipps für eine perfekte Webseite« beschäftigt sich mit den häufigsten Fehlern, die beim Erstellen einer Webseite in Bezug auf den Code anzutreffen sind. Hierbei soll es vor allem darum gehen, zu zeigen, wie valides Markup erzeugt wird, und was darüber hinaus zu beachten ist. Die dynamische Erzeugung diese Codes mittels der verschiedenen Skriptsprachen soll nicht Teil der Artikelreihe sein. Wir möchten Ihnen vermitteln, waroauf Sie achten müssen, wenn Sie eine professionelle Seite betreiben wollen, und woran Sie einen Profi erkennen können.
Hier nun unsere zehn Tipps, für eine – zumindest was den Code anbelangt – perfekte Webseite.
Tipp 1: Fehlerfreier Code
Tipp 2: Kein Dokument ohne DOCTYPE!
Tipp 3: Das HTML-Code-Gerüst
Tipp 4: Trennung von Inhalt und Layout
Tipp 5: DIVitis? Ist meine Webseite krank?
[1] Artikel auf Spiegel-Online zum Thema Browsersicherheit