So laufen im allgemeinen Diskussionen zum Thema "Layouttabellen oder CSS-gestylte Boxen" ab. Es wird einfach nicht akzeptiert, wenn sich gerade jemand, der sich sehr intensiv mit allem Pro und Contra beschäftigt hat, nach reichlicher Überlegung an einer bestimmten Stelle für die Tabelle entscheidet.

Was mich an solchen Aussagen stört, sind die mangelnden Alternativen. Tabellen haben nun mal ein paar Eigenschaften, die mit CSS-gestylten Boxen nicht browserübergreifend zuverlässig nachgebildet werden können.

Aber die Standardistas haben ja schon eine Lösung parat: display:table & Co. machen es möglich, eine Tabelle mit einer div-css-Konstruktion nachzubauen. Endlich kann man ohne Missbrauch einer Tabelle ein Layout basteln, das wie eine Tabelle aussieht, und die Welt ist in Ordnung.

Ist sie das wirklich? Mal abgesehen davon, wann wir diese div-css-Tabellen allen verbreiteten Browsern anvertrauen können …

Ich habe mich mal ein wenig kundig gemacht und folgendes auf selfhtml zum Thema display:table & Co. gefunden:

Speziell für die Erzeugung von Tabellen mit Nicht-Tabellen-Elementen stehen weitere Angaben zu display zur Verfügung. Die entsprechenden Angaben lassen sich allerdings auch auf entsprechende HTML-Tabellenelemente anwenden. Gedacht sind sie aber eher für die tabellarische Darstellung von XML-Daten. Denn XML kennt kein Handling, um Daten als tabellarisch auszuzeichnen. Das muss die Style-Sprache übernehmen, mit deren Hilfe die XML-Daten angezeigt werden. In CSS hat man die display-Eigenschaft zu diesem Zweck auserkoren.

Wer also display:table & Co. verwendet, missbraucht genauso wie bei einer richtigen html-Tabelle eine Tabelle zu Layout-Zwecken, nur eben eine XML-kompatible Tabelle.

Auch display:table, display:table-row & Co. sind keinesfalls zu Layout-Zwecken erschaffen worden, sondern zur XML-kompatiblen Darstellung von tabellarischen Daten.

Die Syntax wird genauso aufgebaut wie bei einer html-Tabelle, nur eben mit DIVs und entsprechenden Klassen, somit ist die Anzeige nicht im (X)html definiert, sondern im Stylesheet.

Das entspricht zwar der Forderung nach Trennung von Inhalt und Layout, aber im Grunde werden auch hier (X)html-Elemente in Verbindung mit css-Eigenschaften für einen Zweck missbraucht, für den sie ursprünglich nicht gedacht waren, nämlich für Layout-Zwecke.

Also, wenn ich schon eine Tabelle für bestimmte Layout-Anforderungen “missbrauche”, dann doch lieber eine Tabelle, die auch von Browsern dargestellt wird, die diese css-Eigenschaften nicht interpretieren.

Und mit solchen Browsern werden wir wohl noch die nächsten 3-5 Jahre leben müssen, denn auch folgendes habe ich auf der oben verlinkten Seite (selfhtml), ein paar Zeilen weiter, gefunden:

Die Angaben zu den Tabelleneigenschaften werden von Netscape 6.0 interpretiert, vom Internet Explorer jedoch auch in der Version 7 noch nicht.

Das Thema display:table & Co. zieht sich ja schon seit geraumer Zeit durch die WebdesignBlogs. Das Thema “Layouttabellen” war für lange Zeit aus dem Focus verschwunden und ist eigentlich erst mit der Diskussion dieser css-Eigenschaften wieder ins Rampenlicht geraten.

Vielen Standardistas scheint aber nicht klar zu sein, dass mit display:table & Co eben auch eine Tabelle missbraucht wird, wenn diese Eigenschaften zu Layout-Zwecken eingesetzt werden.

Genaugenommen habe ich das auch nur “geahnt”, bis ich das Thema mal gegoogelt und auf selfhtml eine richtig gute Erklärung gefunden habe.

Vorher war mir völlig unklar, warum man etwas funktionierendes (html-Tabelle) durch ein div-css-Konstrukt ersetzen will. Die XML-Kompatibilität ist jedoch eine einleuchtende Erklärung.

Gleichzeitig habe ich aber auch verstanden, dass es sich bei diesem div-css-Konstrukt genauso um eine Tabelle handelt wie bei einer richtigen html-Tabelle, also ursprünglich nicht zum Layouten gedacht.

Ein wichtiges Ziel des W3C war es damals, Microsoft und den IE in die Schranken zu weisen. Es kann ja nicht sein, dass ein Marktführer bestimmt, was Standard wird und was nicht. Und so kam es, dass sich das eigentlich sinnvolle Boxmodell des IE nicht durchsetzen konnte, weil das W3C sein (weniger sinnvolles) Boxmodell zusammen mit den anderen Browserherstellern durchgepeitscht hat.

Nach dem Motto "Der klügere gibt nach" verwendet der IE ab Version 6 im standardkompatiblen Modus (bei korrektem Doctype) das uns heute allen bekannte Boxmodell, das wohl in der Zukunft als "content-box" eines von mehreren Boxmodellen sein wird.

Nun geisterten bereits vor einiger Zeit Meldungen durch Klein-Bloggersdorf, dass mit CSS3 ein alternatives Boxmodell namens "border-box" eingeführt werden soll. Der aufmerksame Leser mit (X)html- und CSS-Kenntnissen hat sofort bemerkt, dass es sich hier um das Boxmodell des IE handelt, das im Machtkampf zwischen Microsoft und W3C zu Zeiten der Browserkriege im Zuge der Vernunft von Microsoft fallen gelassen wurde.

Jetzt musste sich das W3C natürlich den Vorwurf gefallen lassen, dass es sein unvernünftiges Boxmodell damals aus Prinzip durchgepeitscht hat, und nun still und leise das besiegte, aber sinnvolle IE-Boxmodell, wenn auch nur als Alternative, wieder einführen will.

Das geht natürlich so nicht, also wird in CSS3 wahrscheinlich zum ganz grossen Schlag ausgeholt und gleich 4 Boxmodelle etabliert, von denen eines zufällig und logischerweise dem alten IE-Boxmodell entspricht.

Die 4 Boxmodelle in CSS3

 Angedacht sind folgende 4 Boxmodelle:

content-box

hierbei handelt es sich um dasBoxmodell, das wir alle kennen: width bezieht sich auf den Inhalt, padding, border und margin kommen noch dazu und bestimmen die Geamtbreite, die die Box einnimmt:

1 x width + 2 x padding + 2 x border + 2 x margin

padding-box

width schliesst padding mit ein, Gesamtbreite der Box:

1 x width + 2 x border + 2 x margin

border-box

Das alte IE-Boxmodell, width schliesst padding und border mit ein, Gesamtbreite der Box:

1 x width + 2 x margin

margin-box

width schliesst padding, border und margin mit ein, Gesamtbreite der Box:

1 x width

Eingebunden werden diese CSS-Eigenschaften mit

{… box-sizing:border-box; …}

Was wird kommen?

Nun, niemand weiss nichts so genaues. Border-Box ist wohl gesetzt, inwieweit auch die anderen Boxmodelle zum Standard erhoben werden steht wohl noch in den Sternen. Und es wird wohl ein paar weitere Jahre dauern, bis wir diese Boxmodelle allen verbreiteten Browsern anvertrauen können.

Eines sehe ich jedoch ganz klar kommen:

Wenn ich an die verschiedenen Bugs in den verschiedenen Browsern schon bei EINEM Boxmodell denke (und das bei weitem nicht nur im IE), wird mir beim Gedanken an eine Zukunft mit 4 verschiedenen Boxmodellen schon ganz schlecht.

Browser A hat ein Problem mit padding-box, Browser B versagt bei border-box, Browser XYZ …

Deshalb habe ich mir einen eigenen Umgang mit den Boxmodellen angewöhnt. Jeder Bereich (header, locator, sidebar, footer usw.) hat ein äusseres und ein inneres div.

Das äussere div bekommt per CSS lediglich Angaben zu width, float und clear. Kein padding, kein margin, kein border und auch sonst nix. Diese äussere Box bleibt also unsichtbar und nimmt aber in allen Browsern den gleichen Platz ein.

Die innere Box bekommt KEINE Angaben zu width und float, somit dehnt sie sich immer zu 100% innerhalb der äusseren Box aus. Diese innere Box wird nun per CSS gestaltet und kann mittels margin innerhalb der äusseren Box zurechtgerückt werden.

Nur so ist das Layout weitgehend browser- und zukunftssicher. Aber dazu habe ich ja schon vor langer, langer Zeit etwas gerschrieben:

CSS Boxmodell Chaos – die Lösung »

Diese Diskussionen entgleisen nicht selten, die einen setzen auf geduldige Aufklärung, die anderen "rezensieren" Internetseiten, bei denen Webstandards nicht eingehalten werden und gehen dabei nicht gerade zimperlich zu Werke.

Wie kann man nun Webdesigner und Webagenturen dazu bewegen, auch unter der Oberfläche ordentliche Arbeit abzuliefern?

Ob hier besserwisserische Belehrungen mit teilweise beleidigendem Vokabular zu einer Besserung führen wage ich zu bezweifeln. Mit den Webstandards ist das nämlich so eine Sache. Eine erst kürzlich veröffentlichte Studie hat nämlich festgestellt, dass lediglich ca. 4% aller Internetseiten den Validitätstest im W3C-Validator bestehen.

Da kommen die Browserhersteller nicht mehr raus. Die Fehlertoleranz der Browser hat diese Entwicklung aber erst möglich gemacht. Es galt bei den Browserherstellern vor Jahren wohl als Tugend, möglichst auch noch den fehlerhaftesten (X)html-Code so zu interpretieren, wie es der Autor wohl wollte. Das hatte auf breiter Front einen schlampigen Umgang mit (X)html seitens der Webdesigner zur Folge.

Heute könnte es sich ein Browserhersteller gar nicht mehr leisten, einen Browser herauszubringen, der bei fehlerhaftem (X)html den Dienst quittiert und eine weisse Seite oder eine Fehlermeldung anzeigt. Einen solchen Browser würde wohl niemand nutzen, da man ja damit nur ca. 4% aller Internetseiten zu sehen bekäme.

Trotzdem könnten die Browserhersteller etwas tun. Sie könnten an prominenter Stelle auf der Oberfäche des Browsers gut sichtbar und einladend einen Button integrieren, mit dem jedermann die aktuelle Seite mit dem Validator des W3C validieren kann. Dann könnte jeder, den es interessiert, auch und vor allem die Auftraggeber und Betreiber der Seite, diese auf Einhaltung der anerkannten Webstandards prüfen.

Das würde zumindest die Webdesigner und -agenturen, die Webdesign gewerblich und professionell anbieten, gehörig unter Druck setzen. Die Auftraggeber könnten zumindest einen Teilaspekt einer ordentlichen, professionell gestalteten Internetseite überprüfen.

Dass valider Code noch lange kein sauberer, moderner und "guter" Code ist weiss ich auch. Aber man kann wohl davon ausgehen, dass die Webdesigner, die auf valides (X)html achten, in der Regel auch in anderen Bereichen Qualität abliefern. Und genau die würden davon profitieren, wenn jeder Browser einen solchen "Validierungsbutton" gut sichtbar auf der Bedienoberfläche hätte.

Es wird einfach aneinander vorbei diskutiert.

Deshalb habe ich mich entschlossen, diese Begriffe mal auf meinem eigenen Blog zu klären, damit meine Kommentare nicht länger werden als die Beiträge der Autoren. Jetzt kann ich einfach hierher verlinken .

• Layout mit fixer Breite
• Liquides oder fluides Layout
• Elastisches Layout (Zoomlayout)
• Was ist eigentlich flexibles Layout ?
• Was bringt die Zukunft?

Layout mit fixer Breite

Bei einem Layout mit fixer Breite wird width für alle Elemente (Boxen, Bilder usw.) in px formatiert. Bei Textvergrösserung verändern sich die horizontalen Abmessungen der Seite nicht, die Seite wächst nur nach unten, durch die grössere Schrift und die damit verbundenen Zeilenumbrüche im Fliesstext.

Ist der Viewport kleiner als die horizontale Breite der Seite, entsteht ein horizontaler Scrollbalken. Der Viewport ist das Browserfenster abzüglich Scrollbalken, Kopf- und Fussbereich des Browsers und evtl. Sidebars (z. B. Bookmarks oder Favoriten).

Hier gibt es keine Missverständnisse, das ist so ziemlich jedem klar.

Beispiel: dieses Blog

Übrigens: genaugenommen lassen sich richtig fixe Layouts in der derzeitigen Browserlandschaft gar nicht umsetzen, weil alle Browser ausser dem IE auch in px definierte Schriften vergrössern. Was wir als fixes Layout bezeichnen, ist eigentlich nur ein horizontal fixes Layout, vertikal ist es flexibel.

Bei einem richtig fixen Layout müssten wir nicht nur width in px auszeichnen, sondern auch height und die Schriftgrösse. Dann würden aber (ausser im IE) die Inhalte nach unten aus den Boxen herauswachsen, sobald man die Schrift vergrössert. Die Inhalte würden sich überlagern oder verschwinden, je nach dem, wie der overflow definiert ist.

Wir machen also alle eigentlich nur mehr oder weniger flexible Layouts, entweder nur vertikal flexibel oder vertikal und horizontal flexibel . Das ist natürlich ein wenig provokant, theoretisch und verquer gedacht, aber ich habe schon irgendwie bewusst als Zwischenüberschrift "Layout mit fixer Breite" gewählt statt einfach nur "fixes Layout". 

nach oben

Liquides oder fluides Layout

Liquides (auch fluid genanntes) Layout bezieht sich auf das Verhalten von Flüssigkeiten (liquid) und Gasen (fluid).

Flüssigkeiten und Gase breiten sich in ihrem Behälter aus, auf die Internetseite bezogen heisst das, dass sich die Seite horizontal dem zur Verfügung stehenden Viewport anpasst, und zwar automatisch, ohne dass der Nutzer etwas dazu tun muss.

Erreicht wird das, indem width für die Grundelemente einer Seite, die für die horizontalen Abmessungen der Seite zuständig sind, in % ausgezeichnet werden. Bilder usw. werden in der Regel weiterhin in px ausgezeichnet oder gar nicht.

Um zu vermeiden, dass die Seite unter extremen Bedingungen schlimm aussieht oder schlecht benutzbar oder lesbar ist, wird einem liquiden Layout oft mittels der CSS-Eigenschaften minwidth und maxwidth eine Mindestbreite und eine maximale Breite in px zugewiesen.

Horizontale Scrollbalken entstehen erst, wenn minwidth unterschritten wird oder ein Wort oder ein Element zu gross für den Viewport ist.

Dabei muss man jedoch in Kauf nehmen, dass ältere Browser minwidth und maxwidth nicht interpretieren.

Beispiel: meiert.com

nach oben

Elastisches Layout (Zoomlayout)

Lange bevor der Opera den Seitenzoom eingeführt hat, den inzwischen nahezu alle modernen Browser anbieten, haben findige Webdesigner eine Möglichkeit gefunden, die horizontale Ausdehnung einer Internetseite an die Schriftgrösse anzulehnen. Den ach so modernen Seitenzoom gab es also schon lange vor dem Opera, allerdings wurde er nicht durch den Browser erzeugt, sondern durch den Webdesigner mittels CSS.

Die horizontale Ausdehnung aller Elemente einer Internetseite wird in em ausgezeichnet, incl. der Bilder und aller anderen Objekte. Das erzeugt einen Seitenzoom bei Vergrösserung der Schrift, unabhängig davon, ob der Browser einen Seitenzoom hat oder nicht. Alle Boxen, Container, Bilder und anderen Elemente wachsen mit der Schriftgrösse.

Das nennt man elastisches Layout, weil sich die Seite verhält wie ein Luftballon, den man aufbläst. Mit dem grösser werdenden Luftballon wird auch alles, was da drauf gedruckt ist, grösser: Schriften, Bilder, Logos usw. Die Haut eines Luftballons ist elastisch.

Bei einer solchen Seite ist es egal, ob man den Textzoom oder den Seitenzoom benutzt, sie verhält sich immer gleich, immer wie im Seitenzoom. Deshalb werden diese Layouts auch Zoomlayout genannt.

Seitenzoom für alte Browser, sozusagen … Beispiel: zdf.de

nach oben

Was ist eigentlich flexibles Layout?

Hier scheiden sich die Geister. Wann ist eine Website flexibel? Genau hier entstehen die Missverständnisse in den vielen Diskussionen.

Fix steht für ein Layout mit fester, in px ausgezeichneter Breite.

Flexibel heisst zunächst einmal "nicht fix", dazu gehören ganz klar liquide / fluide Layouts. Die meisten zählen aber auch die elastischen Layouts zu den flexiblen Layouts. Flexibel als Oberbegriff für alles, was nicht fix ist.

Man kann das aber auch anders sehen.

Bei Seitenzoom verhält sich nämlich eine elastische Seite genauso wie eine Seite mit fixer Breite.

Bei Schriftvergrösserung verhält sich eine elastische Seite wie eine Seite mit fixer Breite bei Seitenzoom. Das Layout bleibt erhalten, die Seite wächst insgesamt, mit all ihren Elementen.

Das ist, zugegeben, sehr verwirrend. Wozu gehört denn nun das elastische Layout, ist es ein flexibles Layout oder ein auf die Spitze getriebenes fixes Layout, das auch bei Schriftvergrösserung erhalten bleibt, nur eben grösser wird?

Den Begriff "flexibles Layout" als Oberbegriff für liquide und elastische Layouts und alle möglichen Mischformen dieser beiden zu verwenden, ist meiner Meinung nach falsch und stiftet nur Verwirrung. Flexibel sind meiner Meinung nach nur liquide Layouts, da sich diese ohne Zutun des Nutzers flexibel an den Viewport anpassen.

Ich sehe 3 grundsätzliche Designvarianten::

• Layout mit fester Breite (fixes Layout)
• liquid / fluides Layout (flexibles Layout)
• elastisches Layout (Zoomlayout)

Natürlich gibt es auch gemischte Layouts. Ein elastisches Layout kann durchaus fixe Elemente beinhalten, in einem liquiden Layout kann man elastische Elemente anordnen usw.

Grundsätzlich sollten aber diese 3 Layout-Varianten klar sein, bevor man in einem Forum oder Blog mitreden will.

Den Begriff "flexibles Layout" sollte man vermeiden, da auf Grund der weit verbreiteten unklaren Verwendung dieses Begriffes Missverständnisse  vorprogrammiert sind.

nach oben

Was bringt die Zukunft?

Da in der Zukunft wohl alle Browser sowohl Textzoom als auch Seitenzoom anbieten werden, wird das elastische Layout als Stilmittel wohl überflüssig werden. Das erledigen dann die Browser mittels Seitenzoom.

Ein elastisches Layout nimmt dem Nutzer die Freiheit zu entscheiden, ob er nur die Schrift oder die ganze Seite vergrössern will, es wird immer die ganze Seite vergrössert. Ein Nutzer mit einem schmalen Viewport wird nur die Schrift vergrössern wollen, um horizontale Scrollbalken zu vermeiden. Bei einem elastischen Layout geht das aber nicht.

Liquides Layout wird auch weiterhin ein Stilmittel des Webdesign bleiben. Mit minwidth und maxwidth wird man das dann auch zunehmend gut steuern können, irgendwann wird der IE6 die gleiche Bedeutung haben wie heute der NN4.

Generell könnte ich mir vorstellen, dass das Verhalten von Internetseiten in der Zukunft immer weniger vom Webdesigner beeinflussbar sein wird.

Schon heute wird die Vorgabe einer fixen Breite von den Browsern mittels Seitenzoom ausser Kraft gesetzt. Welcher Webdesigner hätte denn vor ein paar Jahren schon gedacht, dass die Browser aus seinem fixen Layout ganz einfach mittels Seitenzoom ein elastisches machen???

Vielleicht wird ja in nicht allzu ferner Zukunft auch ein elastisches Layout durch die Browser ignoriert werden. Es wird dann 2 Buttons geben, gleichberechtigt und friedlich nebeneinander auf der Oberfläche, Textzoom und Seitenzoom. Wo man draufdrückt, das passiert, egal, was im CSS steht.

Dann entscheidet endlich der Nutzer, wie sich die Seite verhält, ob nur der Text grösser wird oder die ganze Seite, unabhängig davon, was der Webdesigner vorgibt. Wir Webdesigner bestimmen dann nur noch, wie die Seite beim Aufruf unter den Standardeinstellungen aussieht, fixe Breite oder bildschirmfüllend / liquid.

Dann wird es nur noch fest oder flüssig geben, fix oder liquid, und wenn jemand von flexibel spricht wird dann eindeutig sein, was er gemeint hat.

CMSimple speichert alle Inhalte in eine einzige html-Datei und legt anhand der Überschriften h1 – h3 eine Seitenstruktur an. Zur Datensicherung ist nur der Download der content.html notwendig, dazu braucht man kein ftp-Programm, das kann man ganz einfach in der Admin-Ebene erledigen.

Aber ich will mich hier gar nicht weiter auslassen, ich habe CMSimple eine eigene Seite spendiert:

CMSimple bei ge-webdesign.de »

Wie so oft gibt es hier kein allgemeingültiges Rezept. Bei kleinen, überschaubaren Seiten ist das bestimmt nicht notwendig, bei ellenlangen Linklisten oder Navigationsstrukturen kann es aber durchaus sinnvoll sein.

Wenn man nun einfach unterschiedliche Farben nimmt oder mit untersrichen oder nicht unterstrichen arbeitet, kann es sein, dass man irgendwann, wenn ca. die Hälfte der Seiten besucht ist, gar nicht mehr weiss, welche Farbe die noch nicht besuchten Links und welche die bereits besuchten Links kennzeichnet. Es sei denn, man nimmt die üblichen Farben, blau für noch nicht besuchte und violett für besuchte Links.

Das mag aber für so manchen Designer zu langweilig sein. Ausserdem sieht das nicht unbedingt schön aus.

Nun ist mir da eine Idee gekommen: besuchte Links werden einfach abgehakt, das verstehen auch Internet-Neulinge, und alle Links sehen gleich aus, besuchte und noch nicht besuchte. Neben den visited Links erscheint lediglich ein kleines Häkchen, da war ich schon, erledigt, eben abgehakt.

Das Häkchen ist ein kleines gif, 16 x 16px mit transparentem Hintergrund, für normale Schriftgrösse. Das Aussehen der visited Links definiere ich mittels CSS:

a:visited {
background: url(bildordner/visited.gif) right bottom no-repeat;
color: #0033cc;
text-decoration: none;
padding: 0 16px 0 0;
}

Das ganze sieht dann so aus:

noch nicht besuchter Link
bereits besuchter Link

Dabei ist es meist sinnvoll, diese Definition auf bestimmte IDs zu beschränken, so dass Links im Kopf oder im Fuss der Seite weiterhin normal angezeigt werden. Auf meiner Internetseite habe ich die visited Links nur für die Navigation und den Inhalt so definiert.

Ein paar kleine Problemchen kann es bei Bildlinks geben. Die verschiedenen Browser setzen das Häkchen an unterschiedlichen Positionen, teilweise auch gar nicht, das Häkchen verschwindet dann wohl unter dem Bild. Deshalb hier eine kleine Demonstration und Anleitung, mit Code-Beispielen und Erläuterungen:

Demoseite zur Gestaltung von visited Links mit Häkchen »

Auf meiner Webdesign-Seite habe ich das bereits umgesetzt: »

Gerade die beabsichtigte Einführung von content-box und border-box in CSS 3 würde das Boxmodell-Chaos, das mit dem Aussterben der älteren Versionen des IE schon fast Geschichte war, wieder zur Geissel der Webdesigner machen.

Die Übergangszeit, bis alle aktuellen Browser CSS 3 ausreichend verstehen und content-box bzw. border-box korrekt darstellen, wäre einfach zu lang.

Lest hierzu meinen Artikel:

CSS, die Browser und die Tücken des modernen WebDesign »

Um die Tabelle für die neuen Layout-Aufgaben fit zu machen, werden folgende neue html-tags in die HTML 5 Spezifikation aufgenommen:

<table type="data"> für Datentabellen

<table type="layout"> für Layouttabellen

Bei Layout-Tabellen kann dann getrost auf thead, tfoot usw. verzichtet werden.

Um die Barrierefreiheit einer solchen Lösung zu gewährleisten, kann man die Tabellenzellen in einer Layouttabelle numerieren. Eine Vorlese-Software würde nämlich eine solche Layouttabelle Zeile für Zeile und Zelle für Zelle abarbeiten. Mit der Vergabe einer Nummer kann man festlegen, in welcher Reihenfolge die Tabellenzellen vorgelesen werden, unabhängig von der Tabellenzeile, zu der diese Zelle gehört:

<td num="1">

Der Inhalt dieser Zelle wird nun von einer Vorlese-Software zuerst vorgelesen.

Mit dieser Regelung will das W3C vor allem auch den Hompage-Bastlern entgegenkommen, die mit dem immer komplexer werdenden CSS so ihre Probleme haben.

Das W3C will in den nächsten Jahren weitere Formatierungs-tags in die HTML 5 – Spezifikation aufnehmen. Damit soll weniger versierten Webgestaltern ermöglicht werden, wieder reine HTML-Seiten zu erstellen, ohne in den Gestaltungsmöglichkeiten eingeschränkt zu sein.

Da freue ich mich doch schon auf die vielen schönen reinen HTML-Seiten, die dann wohl wieder im Netz auftauchen werden, und die endlosen Diskussionen der modernen Standardistas mit den nun wieder gestärkten HTML-Puristen

Es scheint aber Leute zu geben, die einen neuen Browserkrieg vom Zaun brechen wollen. Diesmal ist das Motto "Alle gegen den IE". Erinnert mich irgendwie an Don Quichotte und seinen Kampf gegen die Windmühlen.

Dieser "neue Browserkrieg" kommt in Form von fragwürdigen Kampagnen daher, wie z. B.

• Zu cool für IE »
• Verdreht den IE-Nutzern den Kopf »
• Ignoriert den Internet Explorer »

Die Inhalte dieser Kampagnen reichen von "Lasst doch unsere genialen Seiten im IE aussehen wie sie wollen" bis zu "IE aussperren".

Ersteres ist zwar akzeptabel, aber nach meiner Meinung unklug. So kann man vielleicht mit dem Netscape 4.x umgehen, mit dem IE6 aber noch nicht.

Das zweite ist dann schon nicht mehr akzeptabel, das zeugt von einer gewissen Ignoranz gegenüber Leuten, die das Internet zwar gerne nutzen, aber nicht als ihren Lebensinhalt betrachten.

Bemerkenswert ist, dass solcher Unfug von Leuten kommt, die ansonsten Barrierefreiheit und browserunabhängiges Webdesign propagieren.

Microsoft (MS) hat mit seinem IE vieles richtig gemacht, was sich leider durch das Erscheinen anderer Browser und falsche Webstandards nicht durchsetzen konnte.

1. Beispiel: Das IE-Boxmodell war RICHTIG! Width definiert die Gesamtbreite der Box, padding und border liegen innen, margin aussen. Das kennt man auch aus dem richtigen Leben. Die Bebauungsgrenze von Grundstücken (meist 3 m) liegt innerhalb der Grundstücksgrenze (padding), und wenn ich eine 2 m dicke Mauer baue (10 px border), muss ich das auch auf meinem Grundstück (also innerhalb von width) machen. Wie kann man nur auf die Idee kommen, padding und border ausserhalb von width zu platzieren?! (css-Boxmodell)

Richtig lustig wird es erst werden, wenn mit css 3 content-box und border-box kommen! Wie lange wird es dauern, bis das alle Browser wissen? Wer heute html für die Zukunft schreibt, wird nicht darum herumkommen, durch Verschachtelung von 2 Boxen width und float (äussere Box) von padding, border und margin (innere Box) zu trennen. Und dieses Boxmodell-Chaos schreibe ich nicht IE und MS zu, sondern dem falschen CSS-Boxmodell, das sich leider durchgesetzt hat.

2. Beispiel: Man kann Schriften in px (absolut) oder in % oder em (relativ) formatieren. Warum eigentlich, wenn dann die Browser beides gleich behandeln? Wenn ich als Designer dem Browser sage, die Schrift soll 12px gross sein, dann soll sie auch nicht vergrössert werden. Hier ist der IE der einzige Browser, der sich richtig verhält. Alle anderen Browser nehmen mir eine Gestaltungsmöglichkeit, wenn sie in px definierte Schrift vergrössern. Es ist Sache des Designers, Fliesstext NICHT in px zu definieren. Der Browser hat einfach nur die Anweisung des Designers zu akzeptieren, und das tut nur der IE.

Mit dem aufkommenden Seitenzoom wird sich dieses Problem allerdings von selbst erledigen.

3. Beispiel: Der IE 7 zoomt beim Seitenzoom eine im body platzierte Hintergrundgrafik nicht mit, und das ist auch gut so. Das gibt mir eine weitere Gestaltungsmöglichkeit. Wenn ich will, dass die Hintergrundgrafik mit gezoomt wird, kann ich ja dem body margin:0 geben und die ganze Seite in ein div packen. Wenn ich dann die Hintergrundgrafik in diesem div platziere, wird sie auch mit gezoomt. Ich als Designer kann nun entscheiden, ob die Hintergrundgrafik mit gezoomt werden soll oder nicht.

Damit wir uns nicht falsch verstehen, ich rede hier nicht von Sicherheitslücken oder Bugs wie dem doppelten margin auf der float-Seite. Das sind eindeutig Fehler und Bugs. Fehler und Bugs sind aber nicht nur im IE zu finden.

Und ich bin kein IE-Fan! Wenn ich nicht gerade Internetseiten teste, surfe ich mit Firefox. Aber bevor man z. B. das Boxmodell-Chaos dem IE anlastet, sollte man vielleicht doch mal nachdenken.

Das Problem des IE ist halt seine Marktführerschaft. Weil der IE beim Windows eben mit drauf ist, nutzen den gerade die Leute, die gar nicht verstehen, wovon wir hier reden, und die ihren Browser nie updaten. Der Firefox bringt ein neues update, und nach ein paar Wochen ist das Problem erledigt. Ein IE6 bleibt dagegen so, wie er eben beim Kauf des Computers drauf war. Und damit müssen wir eben leben.

Wenn ich diese Leute erreichen will, muss ich halt meine Seiten so gestalten, dass sie auch im IE6 ordentlich dargestellt werden. Und das ist eigentlich ganz einfach, deshalb werden die Internetseiten, die ich zur Zeit mache, bis runter zum IE 5.5 getestet.

Weil der Browserkrieg den normalen Internet-Nutzer nicht interessiert.

Eine neue Sau wird durchs Dorf getrieben: Abstrafung bezahlter Links durch Google!

Na endlich – habe ich gedacht. Mir kann ja nix passieren – habe ich gedacht. Ich mache keine Werbung auf meinen Seiten, ich kaufe und verkaufe keine Links, und sowas wie trigami ist sowieso das letzte. Wird Zeit, dass gegen dieses Treiben mit bezahlten Links und bezahlten Blogbeiträgen mal was getan wird.

Nach einem ausgiebigen Rundgang durch Klein Bloggersdorf zu diesem Thema habe ich mir dann aber doch Gedanken gemacht zur allmächtigen Dominanz von Google, schliesslich betreibe ich ja auch einen Internet-Handel, der fast ausschliesslich von den guten Platzierungen bei Google unter einigen Suchbegriffen lebt. Und wer weiss schon, was Google morgen so einfällt.

Diese Gedanken haben mich dann veranlasst, meine geschäftlichen Seiten www.schlauchboote-spezial.de (ein wenig Eigenwerbung wird doch hier wohl erlaubt sein ) mal zu checken, und siehe da: von pr5 auf pr3-4 abgerutscht! Dabei handelt es sich um statische Seiten, kein Blog, kein CMS, keine Werbung und keine bezahlten Links!

Das gleiche ist mit allen meinen statischen Seiten passiert, alle werbefrei und frei von bezahlten Links. Daran kann es also nicht liegen.

Ich muss dazu sagen, dass meine Seiten erst Anfang des Jahres um durchschnittlich pr1 (Startseite von 4 auf 5) gestiegen sind, Google hats gegeben, Google hats genommen. Da ich so einiges an Internetseiten betreibe, habe ich die natürlich ordentlich miteinander verlinkt, teilweise mit kleinen Linkfarmen unterhalb der Inhalte. Ich gehe davon aus, dass diese Links nach dem Update von Google nun anders gewertet werden.

In vielen Blog- und Forendiskussionen wird auch vermutet, dass die Blogs pauschal im PageRank abgewertet wurden, weil auch durch die hohe Vernetzung der Blogs durch die Blogrolls und die Backlinks aus den Kommentaren, Pings, RSS-feeds usw. eine Linkpopularität erzeugt wird, die dem Wert der jeweiligen Seite nicht angemessen ist. Aber auch das kann es nicht sein, mein Blog ist durch das Update von pr0 auf pr4 gesprungen, obwohl ich nur sehr sporadisch mal was schreibe.

Nun ist mir der Google PageRank so ziemlich schnuppe, auch wenn ich nach erreichen von pr5 auf einigen meiner Seiten das Gefühl hatte, als ob ich auf eine der unzähligen Spam-Mails zur Penisverlängerung erfolgreich geantwortet hätte .

Wichtig ist mir einzig und allein die Platzierung meiner Seiten in den Suchergebnissen, und da hat sich nichts geändert. Ich hoffe, dass das so bleibt.

Da der Google PageRank nach meinen ersten Analysen kaum Auswirkungen auf die Platzierung in den Suchergebnissen hat, könnte Google dieses Modell eigentlich ganz abschaffen. Es ist genauso krank wie die Votingsysteme beim Eurovision Song Contest oder bei Deutschland sucht den Superstar .

Vor allem bei WordPress Installationen in einem Unterverzeichnis der Domain und beim Einsatz des rewrite-Modules für "schönere" url ist einiges zu beachten.

1. Inhaltsbezogene Referenzierung

Bilder, Videos usw., die ich in meine Beiträge oder Seiten einbinden will, lade ich am besten in Unterverzeichnisse hoch, die ich zuvor direkt im Rootverzeichnis meiner Domain anlege, z. B.:

www.domain.de/wordpress_bilder
www.domain.de/wordpress_videos

Aus dem Rootverzeichnis meiner Domain heraus kann ich ganz einfach referenzieren, indem ich mit einem Slash beginne:

<img src="/wordpress_bilder/bild.gif" alt="">

Das funktioniert immer, egal in welchem Unterverzeichnis meine WordPress-Installation liegt und was ich in meinen rewrite-Regeln festgelegt habe. Deshalb soll es das zur inhaltsbezogenen Referenzierung auch schon gewesen sein, das kann sich jeder selbst organisieren.

2.Themebezogene Referenzierung

Bei den folgenden Code-Beispielen gehe ich davon aus, dass themebezogene Bilder und Grafiken im Verzeichnis .../themes/mein_theme/images/ abgelegt sind.

Im Prinzip kann ich auch Grafiken und Elemente, die zum Theme gehören, aus dem Rootverzeichnis heraus referenzieren, wenn folgende 2 Bedingungen erfüllt sind:

• Wordpress ist im Rootverzeichnis der Domain installiert
• Die rewrite-Regeln (für "schönere" url) sind auf "Standard" eingestellt

Die Referenzierung sieht dann ungefähr so aus:

<img src="/wp-content/themes/mein_theme/images/bild.gif" alt="">

Der Slash am Anfang der Referenzierung sagt dem Browser, dass der Pfad im Rootverzeichnis der Domain beginnt.

Wenn ich das Theme aber auch problemlos in andere WordPress Installationen übernehmen will, gibt das Probleme, weil ich nicht wissen kann, ob die oben genannten Bedingungen erfüllt sind.

2.1. WordPress ist in einem Unterverzeichnis installiert

Wenn WordPress in einem Unterverzeichnis der Domain installiert ist, funktioniert die Referenzierung aus dem Rootverzeichnis der Domain heraus nicht mehr universell in allen WordPress Installationen, da ich nicht wissen kann, wie der andere sein Unterverzeichnis für die WordPress Installation genannt hat.

Solange jedoch die rewrite-Regeln auf "Standard" gestellt sind, funktioniert folgende Art der Referenzierung:

<img src="wp-content/themes/mein_theme/images/bild.gif" alt="">

Hier wurde der erste Slash weggelassen, WordPress referenziert nun relativ aus dem WordPress Installationsverzeichnis heraus.

Wenn aber die rewrite-Regeln nicht auf "Standard" gestellt sind, kann auch diese Art der Referenzierung Probleme bereiten.

2.2. Die rewrite-Regeln sind nicht auf "Standard" gestellt

In diesem Fall kann es sein, dass WordPress Verzeichnisse referenziert, die physikalisch auf dem Server gar nicht vorhanden sind, z. B.:

http://www.domain.de/wordpress-verzeichnis/category/alle-beitraege

Das Verzeichnis "category" ist auf dem Server physikalisch gar nicht vorhanden, es wird nur durch das rewrite-Modul in der Adresszeile des Browsers angezeigt, um eine "schöne" url zu erzeugen.

Der Browser kann das Bild nicht finden, denn er referenziert ab dem Ende der obigen Adresszeile so weiter, wie ich es in die header.php, sidebar.php oder footer.php usw. geschrieben habe.

Was da für eine Referenz erzeugt wird, kann man sehen, wenn man den nun erscheinenden Platzhalter mit der rechten Maustaste anklickt und im Kontextmenü auf "Eigenschaften" klickt, so habe ich das ganze auch herausgefunden.

Ich hatte ein kleines gif-Bildchen als Trennstrich in die Sidebar integriert. Das hat auch bei den Beiträgen und den statischen Seiten funktioniert, aber sobald eine Kategorie (bei mir "Thema" genannt) aufgerufen wurde, war der Trennstrich weg.

Das lag an der Referenzierung ".../category/...", also über ein Verzeichnis, das es physikalisch auf dem Server nicht gibt.

2.3. So geht es: relative Referenzierung mit php

Um ein Theme für alle Bedingungen fit zu machen, kann ich WordPress dazu bringen, die zum Theme gehörenden Elemente relativ aus dem Theme-Verzeichnis (.../themes/mein_theme/) heraus zu referenzieren. Dazu bietet WordPress diesen schönen template-tag an:

<?php bloginfo('stylesheet_directory'); ?>

Das "stylesheet_directory" ist in WordPress definiert und ist das Verzeichnis der style.css des Themes: ".../themes/mein_theme/".

Ein Bild, das zum Theme gehört und im Verzeichnis ".../themes/mein_theme/images/" hinterlegt ist, kann ich mit folgendem Code zuverlässig in die header.php, sidebar.php oder footer.php usw. einbinden:

<img src="<?php bloginfo('stylesheet_directory'); ?>
/images/bild.gif" alt="">

Nun kann ich mein Theme problemlos in andere WordPress Installationen einbinden oder grosszügig zum Download anbieten .