Dr. O. Hoffmann
Gelehrsamkeit entspricht dem Gedächtnis,
Fähigkeit und Geschicklichkeit entsprechen dem Geist.
Novalis
Wie ist nun ein Projekt mit Stilvorlagen zügig
und effektiv zu erstellen? Folgendes Kochrezept mag
da mit Gewinn zu verfolgen sein. Notwendige Zutaten
sind das Beherrschen der Syntax von XHTML und CSS
oder doch alternativ die Kenntnis, wo darüber
Dokumentationen zu finden sind (Siehe Menüpunkt
Verweise).
Im Folgenden also eine Liste für systematisches
Vorgehen:
Diese Struktur sollte eigentlich für alle
Seiten des Projektes praktisch die gleiche sein, um dem
Projekt eine Identität zu geben.
Die Seite sollte mit diesen logischen Elementen
möglichst einfach aufgebaut sein.
Nur zwei logische Elemente wie Menü und Inhalt
werden für den Besucher sehr übersichtlich
wirken.
Mit drei bis sechs Elementen wird es einem bereits
gelingen, dem Projekt eine eigene Identität zu
geben.
Spätestens ab zehn Elementen wird der Nutzer eher
verwirrt und die Seite wirkt überladen.
Typische logische Elemente sind zum Beispiel:
Im sogenannten Kastenprinzip oder auch Box-Modell
überträgt sich
die logische Struktur auf einfache rechteckige
Kästen, die in der XHTML-Datei oft
mit div
-Elementen realisiert werden, die den Inhalt
der logischen Struktur umschließen (genaugenommen
hat jedes XHTML-Element einen entsprechenden Bereich
- Box, Kasten, der formatiert werden kann).
Sofern ein Element mit passender Bedeutung in XHTML
verfügbar ist, ist dies natürlich dem div
vorzuziehen.
Dies sind dann Elemente mit semantischer Bedeutung - es ist umgekehrt
übrigens falsch, ein Element mit semantischer Bedeutung für etwas
anderes zu verwenden als die definierte semantische Bedeutung.
Für listenähnliche Strukturen wie
vertikale Navigations-Menüs sind auch Elemente wie
ul
oder ol
geeignet, weil die
Logik eines solchen Menüs eine Liste ist.
Tabellen sind hingegen zur allgemeinen
Strukturierung zu vermeiden, sofern
sie nicht direkt die Funktion einer Tabelle haben.
Das Element span
eignet nur sehr eingeschränkt,
weil innerhalb eines span
-Bereiches nur andere
inzeilige Elemente auftreten können.
In der XHTML-strict Variante
dürfen span
und andere inzeilige Elemente nur in einem Block-Element wie
zum Beispiel div
auftreten.
Mit CSS ist allerdings auch eine starre
Tabellenformatierung möglich, dazu werden
die (div
-)Kästen mit den entsprechenden
Attributen von display
gemäß CSS 2 ausgestattet,
ohne überhaupt nur das XHTML-Tabellen-Element
zu verwenden.
Sofern es XHTML-Elemente gibt, die die inhaltliche Bedeutung
des Elementes beschreiben, werden diese also statt div
oder
span
verwendet. Für Überschriften sind
nach wie vor h?
-Elemente zu verwenden, für Listen
ol
oder ul
, und so weiter.
div
und span
sind an sich
funktionslose Elemente, die nur zum Einsatz kommen,
wenn die logische Struktur nicht von XHTML-Elementen
abgedeckt wird - etwa bei einer so abstrakten Einteilung wie
Menü, Inhalt, Kopf, Fuß einer Seite.
Wichtig ist hier schon einmal das globale Strukturieren des gesamten Projektes in Einzelseiten mit kompakten, abgeschlossenen Informationseinheiten. Es kann sinnvoll sein, erst einmal auf einem Blatt Papier eine Projektgliederung, ein Inhaltsverzeichnis zu skizzieren und Kerninhalte stichwortartig festzuhalten.
Ein Problem, welchem der Nutzer heute leider auf vielen Seiten
begegnet, ist eine gewisse Strukturlosigkeit und das Verlieren im
Beliebigen.
Hier gilt es, sich und die jeweilige Einzelseite auf das
Wesentliche zu konzentrieren: Das Hauptthema, die
eigentliche Funktion der Seite.
Als Faustformel kann gelten: Jede Seite des Projektes hat
eine Hauptfunktion, ein Thema. Darauf bezieht sich der
Inhalt der Einzelseite und auch die Überschrift,
der Inhalt erfüllt die Funktionsanforderung. Der
Inhalt muß zur Überschrift passen. Daneben
sollte die Seite möglichst wenig weiteren Inhalt
enthalten. Akzeptable Nebeninhalte sind natürlich
das Menü, der Projektkopf und -fuß.
Auf Nebenthemen, die vom Hauptinhalt ablenken, sollte
verzichtet werden, diese sollten jeweils auf einzelne
Seiten ausgelagert werden. Die Struktur der Einzelseite
sollte möglichst einfach sein und nicht mit
Unwichtigem verwirren. Näher werde ich hier auf
die hohe Kunst des Schreibens nicht weiter eingehen,
das gehört bereits zum wirklich schwierigen Teil
des Unterfangens und wird in dem Artikel 'Ausgezeichnet
Schreiben' (Texte schreiben) dieses Projektes
angeschnitten.
Diese reine XHTML-Version sollte auch ohne CSS ansehnlich sein
und funktionieren, die komplette Information der Seite
enthalten und vor allem muß sie mit einem Text-Darstellungsprogramm
funktionieren.
Sie sollte keine Formatierung das direkte Aussehen betreffend enthalten, keine
Positionierung, Farben, Größenangabe etc
(ohnehin nur möglich in den transitional-Varianten von (X)HTML).
Um eine einheitliche Anzeige bei verschiedenen Darstellungsprogrammen zu erhalten,
ist am einfachsten XHTML zu verwenden.
Wer aus irgendwelchen Gründen dennoch nur HTML verwenden möchte
oder aber das XHTML an bestimmte Programme nur als text/html
ausliefert, muß eine Dokumenttyp-Angabe exakt nach der
W3C-Vorgabe an den Beginn des Dokumentes zu stellen.
Nur so ist gewährleistet, daß die Programme die Seite standardkonform darstellen.
Bei fehlerhafter oder fehlender Dokumenttyp-Angabe arbeiten viele
Programme nicht standardkonform sondern im sogenannten Quirks-Modus,
der teilweise Anzeigefehler älterer Darstellungsprogramme beibehält.
Zu formatierende Elemente sind mit geeigneten
Universalattributen zu versehen (class
, id
).
Individualformate (id
-Attribut) und Klassen
(class
-Attribut) verdienen dabei noch die besondere Aufmerksamkeit
des Autors.
Der Wert eines Klassenattributes sollte die Funktion des zugehörigen
Elementes kurz beschreiben (menue, projektkopf, projektfuss, seiteninhalt,
kapitelueberschrift, abschnittsueberschrift, fussnote etc) und nicht das geplante
Erscheinungsbild, welches sich ändern kann und keine
Strukturinformation enthält (grossgruen, kursivklein etc).
Bei id
-Attributen kann ähnlich vorgegangen werden, sind jedoch
viele id
-Attribute vorhanden, wird man für einige vielleicht eher
eine systematische Bezeichnung vorziehen (zitatanker1, zitatanker2,
absatz1 etc).
Abkürzungen sind mindestens beim ersten Auftauchen
mit dem Element abbr
oder acronym
zu versehen
und zu erläutern, zum Beispiel mit einem
title
-Universalattribut. Ein Akronym ist übrigens eine spezielle
Sorte von Abkürzung. Die Buchstaben in einem Akronym werden
nicht einzeln ausgesprochen, sondern als eigenständiges Wort,
Beispiele:
NATO,
UNO,
ASCII,
LASER, wobei Laser bereits so schnell in den
allgemeinen Sprachgebrauch übergegangen ist, daß man es schon
als normales Wort oder zumindest als Anglizismus durchgehen lassen kann.
XML oder
XHTML
sind hingegen Abkürzungen, die nicht als Wort ausgesprochen werden,
daher wird für sie das Element abbr
verwendet.
Azubi,
email,
etc sind hingegen
Abkürzungen, die sich aus Teilen von Wörtern zusammensetzen,
die nicht nur Anfangsbuchstaben sind, auch für diese wird abbr
verwendet,
ebenso für sogenannte Siglen wie zum Beispiel
z.B. oder
s.o., für die es auch keine
besondere Kennzeichnung gibt, wo also ebenfalls abbr
zum Einsatz kommt.
Ebenso sollten andere erklärungsbedürftige Begriffe
entweder direkt erläutert werden, oder
ebenfalls mit einem title
-Universalattribut
verziert werden. Das geht zum Beispiel,
indem man den Begriff mit dem Element span
umschließt
und diesem ein geeignetes title
-Universalattribut
zuweist, welches erklärenden Charakter hat.
Bilder und ähnliche nicht-Text-Elemente sind mit sinnvollem Alternativtext zu versehen, welcher eine Alternative zum Element darstellt, dieses also ersetzt, wenn es nicht anzeigbar ist. Rein dekorative Platzhalter-Bilder sollten etwa ein Leerzeichen als Alternativtext bekommen, Bilder mit Trennfunktion zum Beispiel einen Strich oder Punkt, allgemein ein Zeichen, welches die gleiche Funktion übernehmen kann. Dabei ist es nett, wenn der Autor daran denkt, daß Vorleseprogramme solche Zeichen vorlesen. Punkt ist einsilbig und kurz und gut geeignet.
Wichtige Strukturen sollten auch das Universalattribut
title
bekommen. Verweise, die ein neues Anzeigefenster
öffnen, sind ebenfalls eindeutig als solche
zu kennzeichnen - auch hier kann das title
-Attribut
verwendet werden. Solche Verweise mit neuem Fenster sind generell besser zu
vermeiden.
Bei einem Verweis auf externe Inhalte ist ebenfalls eine entsprechende
Information im Attribut title
vorzuziehen, als dem Nutzer
die Entscheidung aus der Hand zu nehmen, wie der neue Inhalt angezeigt werden
soll.
Ganz allgemein sollte bei der Erstellung des XHTML-Dokumentes
nach Kriterien der Barrierefreiheit und der Zugänglichkeit
vorgegangen werden (siehe unter dem Menüpunkt Verweise
die einschlägigen Seiten). Das verbessert nicht nur
die Zugänglichkeit mit jeglichem Darstellungsprogramm für alle
internet-Teilnehmer, das verbessert auch die Lesbarkeit des
Inhaltes ungemein.
Java-script gehört wie CSS gar nicht zum eigentlichen Inhalt des
Projektes.
Bei java-script sollte also ähnlich wie bei CSS auf eine strikte
Trennung zwischen Inhalt (XHTML) und der Präsentation desselben
geachtet werden (CSS, java-script).
Ebenso wie CSS wird java-script am besten in einer externen
Datei notiert, in welcher lediglich über das
Dokument-Objekt-Modell die Präsentation des Inhaltes beeinflußt wird.
Dies Konzept geht von drei Schichten aus - die primäre Schicht mit dem
eigentlichen Inhalt wird mit XHTML realisiert. Weitere Schichten
sind optional und ändern nichts am Inhalt.
Die zweite Schicht bestimmt die Dekoration des Inhaltes mit Stilvorlagen mit
CSS. Diese zweite Schicht bietet also alternative Darstellungen
des Inhaltes der primären Schicht.
Die dritte Schicht kann weitere alternative Präsentationen des Inhaltes
ermöglichen, die mit java-script über das Dokument-Objekt-Modell erreicht werden
können, indem auf die erste und die zweite Schicht zugegriffen wird, um die
Präsentation zu manipulieren.
Die zweite und die dritte Schicht bieten so auch erweiterte Möglichkeiten, die
Ergonomie der jeweiligen alternativen Präsentation zu optimieren oder die
Präsentation an besondere Möglichkeiten oder Einschränkungen bestimmter Nutzergruppen
anzupassen.
Blinde oder sehbehinderte Nutzer haben etwa andere Bedürfnisse als solche mit besonderen
Anforderungen an Privatsphäre oder Stabilität und Sicherheit des Darstellungsprogrammes
oder solche mit Konzentrationsproblemen, die davon profitieren mögen, mit einer massiv
interaktiven Präsentation des Inhaltes über längere Zeit Interesse zu behalten.
Andere Besonderheiten mögen sich aus den speziellen Eigenschaften des Darstellungsprogrammes
ergeben.
Die Festlegung der Positionierung und Ausrichtung der zentralen Strukturelemente kann erst einmal auf einem einfachen Blatt Papier erfolgen, um nicht durch Probleme der technischen Realisation behelligt zu werden. Der erfahrene Autor kann das auch in Gedanken vorbereiten und direkt am Rechner umsetzen. Auch verschiedene Varianten und Anordnungen können alternativ vorbereitet werden und dem späteren Nutzer zur Auswahl angeboten werden - bekanntlich sind ja die Geschmäcker und Bedürfnisse verschieden. CSS ist ideal, um dem Nutzer hier entgegenzukommen und ihm etwas Spannendes zu bieten.
Ist dem Punkt gefolgt worden, nur wenige zentrale Strukturelemente in einem Dokument zu verwenden, so ist nun nur noch darauf zu achten, daß auch deren Anordnung ähnlich einfach, übersichtlich und robust ist. Der Leser soll also nicht durch zuviel Komplexität versunsichert werden, sondern immer das Gefühl der kompletten Kontrolle und Übersicht haben, um sich in dem Projekt wohlzufühlen.
Bei der Ausarbeitung der Stilvorlagen sind absolute
Größenangaben (Pixel, Millimeter, Zentimeter, pt, pc etc)
für eine Darstellung in Anzeigemedien mit unbekannter Größe des
Anzeigebereiches ungeeignet. Bei Darstellungsprogrammen sind die Abmessungen des Anzeigebereiches
generell nicht bekannt. Bei der Druckerausgabe hingegen kann das Papierformat
festgelegt werden (was aber auch Probleme geben kann, wenn der Nutzer nicht über
das gewünschte Format verfügt). Statt absoluter Maßangaben sind solche
in 'em', 'ex' und Prozent vorzuziehen.
Sehr gut geeignet ist natürlich auch die Reihe
xx-small, x-small, small, medium, large, x-large, xx-large,
beziehungsweise relativ: larger, smaller für die Schriftgröße.
Es sollte daran gedacht werden, daß kleinere Schriftgrößen als vom
Nutzer am Darstellungsprogramm voreingestellt nicht funktionieren müssen.
Die voreingestellte entspricht 1em, 100% oder medium. In solchen
Fällen kann etwa 0.5em für die Schriftgröße beim Nutzer
auch völlig korrekt als 1em dargestellt werden. Zu bedenken ist auch immer,
daß die Angaben zur Schriftgröße auf die gerade im Programm verfügbaren
Größen gerundet werden.
Bildelemente sind jedoch in Problemfällen dadurch
zu berücksichtigen, daß Extremalgrößen
(min-width, max-width
etc) vorgegeben werden.
Notfalls, besonders auf dynamisch erzeugten Seiten, auf
denen Bilder von Nutzern angezeigt werden sollen, kann es
sinnvoll sein, diese Bilder bei der Eingabe auf eine
verträgliche Pixel-Größe zu reduzieren oder
aber dies wird mit CSS gesteuert, indem eine extra img-Klasse
angelegt wird, bei der max-width
ebenfalls in 'em'
oder Prozent angegeben werden kann, passend zum Maßstab
des Elternelementes, also des umgebenden Kastens.
Angaben in 'in', 'cm'
oder 'mm'
sind praktisch nur sinnvoll in Zusammenhang mit
maßstäblichen Darstellungen.
Typographische Einheiten wie 'pt' oder 'pc'
eignen sich praktisch nur für typographische Zwecke, eventuell
für die Druckerausgabe, wo der Nutzer aber besser auch selbst
entscheiden sollte, wie groß die Schriftgröße sein soll.
Allgemein lesbarer Text sollte nicht damit formatiert werden.
Ebenso ungeeignet sind Schriftgrößenangaben in
'px' (Pixel) für den Bildschirm. Bei den Nutzern
können die Sehgewohnheiten und die Auflösung des
Monitors (Pixel pro Millimeter) ganz unterschiedlich sein.
Eine der Stärken von XHTML liegt gerade darin, daß
das Programm die Formatierung im Wesentlichen selbst vornimmt,
je nach Größe des Anzeigefensters.
Diese Fähigkeit mit absoluten Angaben in Pixeln oder
Zentimetern abzuwürgen oder in ein enges Korsett zu
stecken, hieße nur die eigene Ignoranz für das
gesamte Medium offenzulegen. Solche starren Layouts eignen
sich für Litfaßsäulen, nicht für
internet-Seiten.
Als Faustregel kann gelten: Absolute Angaben niemals
für fließenden Text vorgeben - vor allem
nicht für die Schriftgröße und eigentlich
auch nicht für die Zeilenhöhen, Texthöhen und Textbreiten.
Relativ unbedenklich sind absolute Angaben hingegen für
die Festlegung von rein dekorativen Elementen wie Randabstand
zu anderen Elementen und Rahmendicken. Sinnvoll oder gar notwendig
sind absolute Angaben in Pixeln bei der Einbindung von
Pixelgraphik, um grobe Störungen des Layouts durch
die Graphik zu vermeiden.
Wird ein Element mit der Positionierung fixed
verwendet,
ist besser darauf zu achten, daß dieses beim testweisen
Wechsel auf die Positionierung static
keine anderen
Elemente überdeckt, denn browser der vierten Generation
beherrschen fixed
nicht und verwenden stattdessen fehlerhaft dann
static
(kann oft durch eine vorherige Angabe von
position: absolute
korrigiert werden). Solche fixed
-Elemente sollten auch niemals und
unter keinen Umständen bei allen plausiblen
Fenstergrößen aus einem Fenster herausragen -
der überstehende Teil wird dem Nutzer der Seite nicht
mehr zugänglich sein!
Formate für CSS-Elementarelemente,
-Pseudoelemente und eigene Strukturen
mit ähnlicher Bedeutung festlegen.
Dazu gehören auch Individualformate (id
-Attribut) und Klassen
(class
-Attribut) für projektspezifische Textformatierungen wie
besondere Überschriften und sonstige Textauszeichnungen.
Wichtig zu wissen: XHTML-Elemente haben eine Vorformatierung vom
Darstellungsprogramm, besonders für margin
und padding
,
und einige andere Eigenschaften der Elemente, die von Programm zu Programm leicht variieren
können. Zum Beispiel realisiert Opera die Listeneinrückungen
anders als Mozilla. Um ein einheitliches Erscheinungsbild zu erreichen,
sind gegebenenfalls die Vorformatierungen durch das Programm
durch explizite eigene Angaben zu überschreiben - im Falle der
Listen also die explizite Angabe von
margin-left
und padding-left
.
Sofern bereits Eigenschaften von CSS3 verwendet werden, sollte zunächst eine einfache Stilvorlage mit CSS2 erstellt werden, die komplett funktioniert. Dann werden die neuen Eigenschaften von CSS3 ergänzt, die gegebenenfalls die von CSS2 überschreiben. Da alte Programme die neuen Eigenschaften ignorieren, bleibt es bei diesen bei der einfachen Darstellung, während die neuen Programme die neuen Eigenschaften interpretieren können. Weil verschiedene Programmversionen verschiedene Module von CSS3 interpretieren werden oder auch nicht, ist es letztlich bei jeder neuen Eigenschaft zu empfehlen, zu testen, ob eine partielle Interpretation noch zu einer sinnvollen Darstellung führt. Als Alternative kann es auch sinnvoll sein, gut sichtbar eine Auswahl von verschiedenen Stilen bereitzustellen, wobei die einfacheren komplett auf CSS3 verzichten. So kann der Nutzer gegebenenfalls immer noch selbst umschalten, wenn etwas gar nicht funktioniert.
Zunächst werden die Stilvorlagen mit aktuellen Darstellungsprogrammen getestet. Es sollte eine Feinabstimmung des Layouts auf kleine Unterschiede und verbliebene Schwächen in der CSS-Interpretation erfolgen, so daß sich für jedes aktuelle Darstellungsprogramm ein ansehnliches Resultat mit derselben Stilvorlage ergibt.
Wie im vorherigen Abschnitt bereits erläutert, können neue Eigenschaften von CSS3 ein differenziertes Vorgehen nahelegen, wobei ältere Programme dann eben nur eine einfachere Darstellung umsetzen können als neue Programmversionen. So ist es dann auch gut möglich, neue Eigenschaften zu benutzen, auch wenn alte Programme diese nicht interpretieren. Man darf dann nur keine einheitliche Darstellung erwarten.
Nach dem Test mit aktuellen Programmen kommt der Test mit alten Darstellungsprogrammen, so weit diese noch verfügbar sind. Vermutlich wird hier keine Feinabstimmung mehr möglich sein, folglich sind nicht behebbare Mängel zu notieren.
Sofern nicht mehr vorhanden oder als generelle Alternative empfiehlt sich auch hier, alternative Stilvorlagen verfügbar zu machen, die nur sehr einfache Dekorationen umsetzen. Im Zweifelsfalle sollte es auch immer möglich sein, Stilvorlagen komplett abzuschalten. Da nicht bei allen Programmen solch eine Möglichkeit eingebaut ist oder dem Nutzer bekannt sein muß, sollte sich der Autor dann um eine davon unabhängige Möglichkeit bemühen, etwa mit einer alternativen leeren Stilvorlage.
Gegebenenfalls ist also für alte Programme
eine hinreichend einfache CSS-Fassung zu entwerfen, also
vor allem ohne Positionierung und
Größenbegrenzungen oder Eigenschaften aus CSS 3.
Eventuell für spezielle bekannte Programme besondere
Versionen anlegen, die näher an das eigentliche
Layout herankommen. Ob sich das lohnt, hängt auch
davon ab, wie oft solch ein altes Programm nocht genutzt wird und
ob man es selbst für Tests noch verfügbar hat.
Wenn dann eine browser-Weiche erstellt werden
soll, ist zu gewährleisten, daß eine
Zuordnung für jegliches Darstellungsprogramm sinnvoll
erfolgt, insbesondere für solche, die dem
Autor noch gar nicht bekannt sind.
browser-Weichen sind besonders kritisch, weil
damit Programme hundertprozentig genau ausselektiert
werden müssen.
Zum Beispiel reicht es nicht, nur nach der Zeichenfolge
'MSIE' oder gar 'Mozilla/4' zu suchen,
um genau diese Programme auszuwählen. Bei letzterer
Auswahl erwischt man fast alle Darstellungsprogramme der vierten
Generation, nicht nur Netscape4. Bei ersterem kann
man auch Opera erwischen, besonders wenn
es unter microsoft windows läuft, der meist viel
mehr CSS interpretieren kann als der
msie selbst. Ähnliches gilt für Konqueror.
Auch eine Unterscheidung in msie und sonstige ist
Unfug, denn es gibt sowohl ein paar Programme, die
CSS schlechter interpretieren als dieser und
einige, die dies deutlich besser können. Und
beim msie selbst hängen die Fähigkeiten
von der Version ab.
Bewährt hat sich eine Methode für den
besonders kritischen msie mittels der von der Firma
microsoft dafür entwickelten 'conditional comments',
die von anderen browsern ignoriert werden. Darauf wird unter
dem Menüpunkt 'Dilemma' weiter eingegangen, wo
auch einige Ideen für Macken anderer älterer
Darstellungsprogramme angegeben sind. Jedenfalls ist es immer besser,
Programme gezielt über ihre Fähigkeiten
zu selektieren als über ihren Namen. Zumindest bei
Opera, den Geckos und Konqueror ist die Entwicklung sehr
rasant, effektiver ist es da meist, den Entwicklern einen
Fehlerbericht zu schicken, statt Fehler für eine bestimmte
Version zu kompensieren.
Bei der Druckerversion kann es zum Beispiel sinnvoll
sein, Menüs mit display: none
zu verbergen und
zum Sparen von Farbe schlicht schwarzen Text auf
weißem Grund zu verwenden.