Bei diesem Dokument handelt es sich um eine Übersetzung eines
W3C-Textes.
Dieser Text ist urheberrechtlich geschützt; bitte beachten Sie
die nachfolgenden Hinweise des Originaldokuments.
Die Rechte an der Übersetzung liegen bei den Übersetzern
und dem Verlag Addison-Wesley.
Die Übersetzung hat keine durch das W3C legitimierte,
normative Wirkung. Das einzige maßgebliche Dokument ist
das englische Original.
Bitte senden Sie Fehler und Korrekturen zur deutschen Fassung
an die Übersetzer.
Kommentare der Übersetzer, die als solche gekennzeichnet sind,
unterliegen dem Urheberrecht der Übersetzer. Sie sind nicht
Bestandteil des Ursprungsdokuments.
Diese Veröffentlichung ist eine Vorveröffentlichung.
Kein Teil dieses Textes darf kopiert werden. Alle Rechte vorbehalten.
Nach Abschluss der Arbeit wird das endgültige Dokument unter
der oben angegebenen Adresse veröffentlicht. Die jetzige Veröffentlichung
während der laufenden Arbeit dient zur Information von Interessierten und
zur Prüfung durch die Fachöffentlichkeit. Sollten Sie Fehler finden oder
Verbesserungsvorschläge haben, schicken Sie diese bitte per Mail
an die Übersetzer.
Folgende Teile liegen noch in Englisch vor und müssen noch
in deutscher Fassung
generiert werden: (a) Gesamtinhaltsverzeichnis (b) Index
Das Tabellenmodell von HTML gestattet Autoren die Anordnung von
Daten – Text, vorformatierter Text, Bilder, Links, Formulare,
Formularfelder, andere Tabellen und so weiter – in Zellen,
die in Zeilen und Spalten angeordnet sind.
Jeder Tabelle kann eine Beschriftung zugewiesen werden (siehe
das Element CAPTION), die eine kurze Beschreibung der
Intention der Tabelle enthält. Zum Nutzen der Leute, die
sprach- oder braille-basierte Benutzerprogramme verwenden, kann
auch eine längere Beschreibung angegeben werden (über das
Attribut summary).
Tabellenzeilen können in Kopf-,
Fuß- und Rumpfbereiche geordnet werden (über die Elemente
THEAD, TFOOT bzw. TBODY). Zeilengruppen vermitteln
zusätzliche Strukturinformationen und können von
Benutzerprogrammen auf eine Weise dargestellt werden, die diese
Struktur unterstützt. Benutzerprogramme können die
Bereiche Kopf, Rumpf und Fuß ausnutzen, um das von den Kopf-
und Fußbereichen unabhängige Scrollen von Rumpf-Bereichen
zu unterstützen. Werden lange Tabellen gedruckt, können
die Kopf- und Fußinformationen auf jeder Seite, die
Tabellendaten enthält, wiederholt werden.
Autoren können auch Spalten
gruppieren, um zusätzliche Strukturinformationen
anzubieten, die von Benutzerprogrammen verwertet werden
können. Des Weiteren können Autoren Spalteneigenschaften
zu Beginn einer Tabellendefinition deklarieren (über die
Elemente COLGROUP und COL), damit Benutzerprogramme die Tabelle
inkrementell darstellen können, anstatt vor der Darstellung
auf die Übertragung aller Tabellendaten zu warten.
Tabellenzellen können entweder
»Kopfinformationen« (siehe Element TH) oder »Daten« (siehe Element TD) enthalten. Zellen können sich
über mehrere Reihen oder Spalten erstrecken. Das
Tabellenmodell von HTML 4 gestattet es Autoren, jede Zelle so zu
beschriften, dass nicht visuelle
Benutzerprogramme Kopfinformationen über die Zelle
einfacher an den Benutzer weitergeben können. Diese
Mechanismen unterstützen nicht nur Benutzer mit
Sehbehinderungen immens, sie ermöglichen es multimodalen
kabellosen Browsern mit begrenzten Anzeigemöglichkeiten (z.B.
web-fähige Pager und Telefone) Tabellen zu verarbeiten.
Tabellen sollten nicht ausschließlich als Mittel zum Layout
von Dokumentinhalt verwendet werden, weil dies Probleme mit sich
bringen kann, wenn der Inhalt auf nicht visuellen Medien ausgegeben
wird. Wenn Graphiken verwendet werden, können diese Tabellen
zudem Benutzer dazu zwingen, horizontal zu scrollen, um eine
Tabelle zu betrachten, die auf einem System mit einem
größeren Bildschirm erstellt wurde. Um diese Probleme zu
minimieren, sollten Autoren eher Stylesheets als Tabellen
verwenden.
Anmerkung der Übersetzer:
Diese Aussagen müssen wir – so richtig sie in ihrem
Anliegen sind – unter praktischen Gesichtspunkten etwas
relativieren.
Richtig und wichtig ist: Tabellen sind ein Struktur-,
kein Layoutmittel. Mangels Alternativen wurden und werden
sie häufig für Layoutzwecke »missbraucht« und
führen zu den erwähnten Problemen bei nicht visueller
Darstellung. Leider scheitert die vorgeschlagene Alternative,
Stylesheets zu verwenden, im Moment oft noch in der Praxis,
mindestens dann, wenn etwas komplexere Layouts realisiert werden
sollen. Die Ursache liegt in den visuellen Benutzerprogrammen, von
denen selbst aktuelle Versionen mit Stylesheets nicht so umgehen,
wie es erforderlich wäre, sei es nun durch Bugs oder
unvollständige Unterstützung von Stylesheets.
Um es noch einmal deutlich zu sagen: Wir unterstützen hier
nicht die Verwendung von Tabellen für Layoutzwecke, weisen nur
auf die praktischen Schwierigkeiten hin, die Alternativen zurzeit
noch mit sich bringen.
Die ergänzende Aussage, dass Tabellen zum horizontalen
Scrollen zwingen können, ist ebenfalls richtig, jedoch nicht
so absolut, wie sie sich vielleicht liest. Nicht die Erstellung auf
größeren Bildschirmen ist die Ursache, sondern mangelndes
Bewusstsein dafür bei so manchem Autor, der ihnen ein zu
starres Layout aufzwingt – übrigens auch da, wo Tabellen
nicht »missbraucht«, sondern ihrer Intention entsprechend zur
strukturierten Präsentation von Informationen eingesetzt
werden. Mehr dazu lesen Sie in unseren Anmerkungen weiter unten in
diesem Kapitel, in den Abschnitten, die sich mit Breitenvorgaben
beschäftigen.
Der vorgeschlagene Einsatz von Stylesheets löst das Problem
der zu großen Breiten übrigens nicht. Sie bieten zwar
deutlich umfangreichere Möglichkeiten der visuellen
Gestaltung, haben den wichtigen Vorteil, dass sich mit ihrer Hilfe
die Präsentation vom Inhalt trennen lässt, führen
aber ansonsten zu durchaus ähnlichen Problemen bei allzu
starren Vorgaben. Ob feste Positionen durch Dummy-Graphiken –
dem meistgehassten beliebten Hilfsmittel der Tabellenlayouts
– erreicht werden, durch unflexible Breitenvorgaben oder
durch Positionierung mit Hilfe von Stylesheets, macht im Ergebnis
nicht wirklich einen Unterschied. Vermeiden oder wenigstens
minimieren lässt sich des Problems nur durch bewusstes
Herangehen seitens der Autoren.
Das eben Gesagte ändert natürlich nichts daran, dass
Stylesheets das Mittel der Wahl sein sollten, wenn es um
Layoutfragen geht. Ein Beispiel, wie man ein häufig
verwendetes – heute vielfach noch mit Hilfe von Tabellen
erreichtes – Layout mittels Stylesheets realisieren kann,
finden Sie am Ende dieses Kapitels.
Anmerkung der Übersetzer:
Es gibt noch einen anderen Blickwinkel darauf, ob Tabellen der
Strukturierung oder dem Layout dienen: Selbstverständlich
können Tabellen nur tabellarische Daten
strukturieren. Beispiele für solche Daten sind in diesem
Kapitel zahlreich zu finden. Sind die Daten aber gar nicht
tabellarischer Natur, dann dient eine Tabelle vermutlich
automatisch als Layout-Werkzeug.
Eine Alternative zu HTML-Tabellen bietet sich dank XML:
Tabellarische Daten lassen sich mit solchen Elementnamen
strukturieren, die eine Aussage über den Inhalt der Daten
machen. Im Abschnitt 17.1 der kommentierten CSS2-Übersetzung
finden Sie ein Beispiel für eine Tabelle mit den Elementnamen
liga, verein, punkte,
tore und so weiter. Es ist unmittelbar klar, dass es
um irgendwelche Sportdaten geht. Die Formatierung als Tabelle
erfolgt dort mit CSS. Bei dieser Vorgehensweise hat sich dann
endgültig die Frage erledigt: »Struktur oder Layout?«
Dank der Modularisierung von XHTML lässt sich so etwas
einfach mit XHTML kombinieren: Ein »liga«-Modul für die
Sportdaten könnte den XHTML-Modulen hinzugefügt
werden.
Hier folgt eine einfache Tabelle, die einige Eigenschaften des
HTML-Tabellenmodells illustriert. Die folgende
Tabellendefinition:
<TABLE border="1"
summary="Diese Tabelle zeigt einige Statistiken über
Fruchtfliegen: durchschnittliche Höhe und
Gewicht und Anteil derjenigen mit roten Augen
(für Männchen und Weibchen).">
<CAPTION><EM>Eine Testtabelle mit zusammengefassten Zellen</EM></CAPTION>
<TR><TH rowspan="2"><TH colspan="2">Durchschnitt
<TH rowspan="2">Rote<BR>Augen
<TR><TH>Höhe<TH>Gewicht
<TR><TH>Männchen<TD>1.9<TD>0.003<TD>40%
<TR><TH>Weibchen<TD>1.7<TD>0.002<TD>43%
</TABLE>
könnte auf einem tty-Gerät wie folgt dargestellt
werden:
oder wie diese durch ein graphisches Benutzerprogramm:
Anmerkung der Übersetzer:
Benutzer der Betriebssysteme Linux und Unix
werden unter tty-Gerät eher eine Gerätedatei für
serielle Geräte vermuten, in diesem Fall ist aber der Ausdruck
eines klassischen Fernschreibers (Teletype Terminal) gemeint.
Dieses Attribut bietet eine Zusammenfassung der Intention und
der Struktur der Tabelle für Benutzerprogramme, die den Inhalt
für nicht visuelle Medien wie Sprach- oder Braille-Browser
ausgeben.
Dieses Attribut gibt die gewünschte Breite der gesamten
Tabelle an und ist für visuelle Benutzerprogramme vorgesehen.
Ist der Wert eine Prozentangabe, dann ist der Wert relativ zur
verfügbaren horizontalen Ausdehnung des Benutzerprogramms. Ist
keine Breite angegeben, wird die Tabellenbreite durch das
Benutzerprogramm festgelegt.
Anmerkung der Übersetzer:
Genauer gesagt gibt das Attribut align die Position der Tabelle in Bezug auf den
beinhaltenden Container an. Dieser Container kann zum Beispiel auch
eine Tabellenzelle einer übergeordneten Tabelle sein, und
nicht unbedingt das Dokument selbst. Die Tabelle wird dann folglich
innerhalb der Tabellenzelle ausgerichtet.
Das Element TABLE enthält
alle anderen Elemente, die Beschriftung, Zeilen, Inhalt und Format
angeben.
Die folgende informelle Liste zeigt, welche Operationen
Benutzerprogramme ausführen können, wenn sie eine Tabelle
darstellen:
Dem Benutzer die Tabellenzusammenfassung (summary) zur Verfügung stellen.
Autoren sollten eine Zusammenfassung des Tabelleninhalts und der
Struktur anbieten, damit Nutzer nicht visueller Benutzerprogramme
die Tabelle besser verstehen können.
Die Überschrift darstellen, sofern eine definiert
ist.
Den Tabellenkopf darstellen, sofern einer angegeben ist. Den
Tabellenfuß darstellen, sofern einer angegeben ist.
Benutzerprogramme müssen wissen, wo Kopf und Fuß
darzustellen sind. Ist das Ausgabemedium zum Beispiel
seitenorientiert, müssen Benutzerprogramme den Kopf an den
Beginn und den Fuß an das Ende jeder Seite stellen.
Ähnlich verhält es sich, wenn das Benutzerprogramm einen
Mechanismus zum Scrollen von Zeilen besitzt; dann kann der Kopf am
Anfang des Scrollbereichs und der Fuß an dessen Ende
stehen.
Die Zellen Zeile für Zeile und angeordnet in
entsprechenden Spalten zwischen dem Kopf und dem Fuß
darstellen. Visuelle Benutzerprogramme sollten die Tabelle so formatieren wie
HTML-Attribute und Stylesheet-Angaben es vorgeben.
Das HTML-Tabellenmodell wurde so entworfen, dass
Benutzerprogramme mit Unterstützung des Autors Tabellen inkrementell darstellen
können (d.h., wenn Tabellenzeilen eintreffen), anstatt auf
alle Daten warten zu müssen, um mit der Darstellung zu
beginnen.
Damit ein Benutzerprogramm eine Tabelle in einem Zug darstellen
kann, müssen Autoren ihm Folgendes mitteilen:
Die Breite dieser Spalten. Im Abschnitt »Berechnen der Spaltenbreite« finden Sie
Details, wie diese Information angegeben werden kann.
Genauer gesagt kann ein Benutzerprogramm eine Tabelle in einem
Zug darstellen, wenn die Spaltenbreiten durch eine Kombination der
Elemente COLGROUP und COL spezifiziert sind. Sind irgendwelche
Spalte mit relativen oder prozentualen Werten angegeben (siehe
Abschnitt »Berechnen der
Spaltenbreite«), müssen Autoren auch die Breite der
Tabelle selbst angeben.
Die Richtung einer Tabelle ist entweder
die geerbte Richtung (Standard ist von links nach recht) oder die
vom Attribut dir angegebene Richtung für das
Element TABLE.
Für eine Tabelle von links nach rechts ist die Spalte Null
auf der linken Seite und die Zeile Null befindet sich oben.
Für eine Tabelle von rechts nach links ist die Spalte Null auf
der rechten Seite und die Zeile Null befindet sich oben.
Teilt ein Benutzerprogramm einer Zeile zusätzliche Zellen
zu (siehe Abschnitt »Berechnen der
Spaltenanzahl einer Tabelle«), werden zusätzliche
Zellen für »links-nach-rechts«-Tabellen an der rechten
Seite und und für »rechts-nach-links«-Tabellen auf der
linken Seite hinzugefügt.
Beachten Sie, dass TABLE das einzige
Element ist, für welches das Attribut dir die visuelle Reihenfolge der Spalten
umkehrt; eine einzelne Tabellenzeile (TR) oder eine
Spaltengruppe (COLGROUP) kann nicht
unabhängig umgekehrt werden.
Ist das Attribut dir für das
Element TABLE angegeben, wirkt sich das Attribut
ebenfalls auf den Text innerhalb der Tabellenzellen aus (weil das
dir-Attribut von Block-Level-Elementen
vererbt wird).
Um eine Tabelle von rechts nach links festzulegen, verwenden Sie
das Attribut dir wie folgt:
<TABLE dir="RTL">
...der Rest der Tabelle...
</TABLE>
Die Richtung des Texts in individuellen Zellen kann durch die
Angabe des Attributs dir in dem Element
verändert werden, das die Zelle definiert. Bitte lesen Sie den
Abschnitt 8.2, »Spezifizierung der Richtung von
Text und Tabellen« für weiterführende
Informationen zum Thema Textflussrichtung.
Visuelle Benutzerprogramme erlauben sehenden Benutzern sowohl
durch die Kopfzeilen als auch durch die Überschrift, die
Struktur der Tabelle schnell zu erfassen. Folglich werden
Überschriften oft nicht als Zusammenfassung der Intention und
der Struktur der Tabelle ausreichen, wenn Benutzer darauf
zugreifen, die auf nicht visuelle Benutzerprogramme angewiesen
sind.
Autoren sollten deshalb
darauf achten, zusätzliche Informationen
anzubieten, die die Intention und die Struktur zusammenfassen, und
zwar mit Hilfe des Attributs summary des Elements
TABLE. Dies ist besonders wichtig für
Tabellen ohne Überschriften. Beispiele weiter unten zeigen die
Verwendung des Attributs summary.
Visuelle Benutzerprogramme sollten vermeiden, irgendwelche Teile
der Tabelle, einschließlich der Überschrift, abzuschneiden, es
sei denn, es ist eine Möglichkeit gegeben, alle Teile zu
erreichen, zum Beispiel über horizontales oder vertikales
Scrollen. Wir empfehlen, dass die Überschrift auf die gleiche
Breite gesetzt wird wie die Tabelle (siehe auch den Abschnitt »Empfohlene
Layout-Algorithmen« im Anhang B).
Tabellenzeilen können mit den
Elementen THEAD, TFOOT und TBODY in einen Tabellenkopf, einen
Tabellenfuß und in einen oder mehrere Rumpfbereiche unterteilt
werden. Diese Teilung ermöglicht Benutzerprogrammen, das
Scrollen vom Tabellenrümpfen unabhängig vom Tabellenkopf
und -fuß zu unterstützen. Werden lange Tabellen gedruckt,
können Informationen des Tabellenkopfes und -fußes auf
jeder Seite mit Tabellendaten wiederholt werden.
Tabellenkopf und -fuß sollten Informationen über die
Tabellenspalten enthalten. Der Tabellenrumpf sollte Zeilen mit
Tabellendaten enthalten.
Anmerkung der Übersetzer:
Die CSS2-Spezifikation nennt die folgenden Angaben als
Voreinstellungen für die Elemente THEAD, TBODY und
TFOOT.
Weiter sagt CSS2, dass Druckprogramme diese Einstellung so
interpretieren können, dass die
table-header-group (also der Tabellenkopf) und die
table-footer-group (also der Tabellenfuß) bei
mehrseitigem Druck auf jeder Seite wiederholt werden. Ein Test mit
aktuellen Browsern zeigt, dass sich einige tatsächlich so
verhalten, falls die CSS-Angabe vorhanden ist. Interessanterweise
wiederholen diese Programme den Kopf und Fuß beim Ausdruck
nicht, wenn die CSS-Anweisungen fehlen; obwohl die Einstellungen
für HTML automatisch gelten sollten. Es empfiehlt sich also,
die gezeigten CSS-Anweisungen in eigene Stylesheets
aufzunehmen.
Wenn vorhanden, enthält jedes THEAD, TFOOT und TBODY eine Zeilengruppe. Jede
Zeilengruppe muss mindestens eine Zeile, definiert durch das
Element TR, enthalten.
Dieses Beispiel beschreibt die Reihenfolge und Struktur von
Tabellenkopf, -fuß und -rümpfen.
<TABLE>
<THEAD>
<TR> ...Kopfinformation...
</THEAD>
<TFOOT>
<TR> ...Fußinformation...
</TFOOT>
<TBODY>
<TR> ...erste Zeile mit Daten von Block eins...
<TR> ...zweite Zeile mit Daten von Block eins...
</TBODY>
<TBODY>
<TR> ...erste Zeile mit Daten von Block zwei...
<TR> ...zweite Zeile mit Daten von Block zwei...
<TR> ...dritte Zeile mit Daten von Block zwei...
</TBODY>
</TABLE>
TFOOT muss vor TBODY innerhalb einer TABLE-Definition stehen, so dass
Benutzerprogramme den Fuß darstellen können, bevor alle
(der eventuell zahlreichen) Datenzeilen empfangen werden. Das
Folgende fasst zusammen, welche Tags erforderlich sind und welche
weggelassen werden können:
Der Start-Tag TBODY ist immer
erforderlich, außer die Tabelle enthält nur einen
Tabellenrumpf und keinen Tabellenkopf oder -fuß. Das End-Tag
TBODY kann immer problemlos weggelassen
werden.
Die Start-Tags für THEAD und TFOOT sind erforderlich, wenn Tabellenkopf
bzw. -fuß vorhanden sind, jedoch können die End-Tags
immer problemlos weggelassen werden.
Konforme Parser von Benutzerprogrammen müssen diese Regeln
aus Gründen der Abwärtskompatibilität immer
befolgen.
Die Tabelle des vorherigen Beispiels könnte durch Weglassen
bestimmter End-Tags verkürzt werden:
<TABLE>
<THEAD>
<TR> ...Kopfinformation...
<TFOOT>
<TR> ...Fußinformation...
<TBODY>
<TR> ...erste Zeile mit Daten von Block eins...
<TR> ...zweite Zeile mit Daten von Block eins...
<TBODY>
<TR> ...erste Zeile mit Daten von Block zwei...
<TR> ...zweite Zeile mit Daten von Block zwei...
<TR> ...dritte Zeile mit Daten von Block zwei...
</TABLE>
Die Bereiche THEAD, TFOOT und TBODY müssen die
gleiche Spaltenanzahl enthalten.
Spaltengruppen gestatten Autoren
die Erzeugung von strukturellen Bereichen innerhalb einer Tabelle.
Autoren können diese Struktur durch Stylesheets oder
HTML-Attribute (z.B. das Attribut rules für
das TABLE-Element) hervorheben. Ein Beispiel
der visuellen Darstellung von Spaltengruppen enthält die Beispieltabelle in Abschnitt 11.5.
Eine Tabelle kann entweder eine einzige implizite Spaltengruppe
(kein COLGROUP-Element begrenzt die Spalten)
oder eine beliebige Anzahl expliziter Spaltengruppen (jede begrenzt
durch die Instanz eines COLGROUP-Elements)
enthalten.
Das Element COL gestattet Autoren, ein Attribut
für mehreren Spalten gemeinsam zu verwenden, ohne irgendeine
strukturelle Gruppierung damit zu verbinden. Das Element COL erstreckt sich über die Anzahl
der Spalten, die sich die Attribute des Elements teilen werden.
Dieses Attribut gibt eine Standardbreite für jede Spalte in
der aktuellen Spaltengruppe an. Zusätzlich zum Standard
(Pixel, Prozent und relative Werte) gestattet dieses Attribut die
besondere Form »0*« (Null Stern), was bedeutet, dass die
Breite jeder Spalte in der Gruppe die minimale Breite ist, die
notwendig ist, um den Spalteninhalt darzustellen. Dies bedeutet,
der gesamte Inhalt einer Spalte muss bekannt sein, bevor ihre
Breite richtig errechnet werden kann. Autoren sollten sich dessen
bewusst sein, dass die Angabe von »0*« Benutzerprogramme daran
hindert, eine Tabelle imkrementell darzustellen.
Dieses Attribut wird in jeder Spalte in der Spaltengruppe
überschrieben, in der width über
ein COL-Element spezifiziert ist.
Das Element COLGROUP erzeugt eine
explizite Spaltengruppe. Für die Angabe der Anzahl der Spalten
in der Spaltengruppe gibt es zwei, sich gegenseitig
ausschließende Möglichkeiten:
Das span-Attribut des Elements
(Standardwert 1) gibt die Anzahl der Spalten in der Gruppe an.
Jedes COL-Element in der COLGROUP repäsentiert eine oder
mehrere Spalten in der Gruppe.
Der Vorteil des span-Attributs ist es, dass
Autoren Informationen über Spaltenbreiten zusammenfassen
können. Enthält eine Tabelle vierzig Spalten, jede mit
einer Breite von 20 Pixeln, ist es einfacher, Folgendes zu
schreiben:
Ist es notwendig, eine einzelne Spalte innerhalb einer Gruppe
auszugrenzen (z.B. für Formatinformationen, um eine Breite
anzugeben usw.), müssen Autoren diese Spalte mit einem COL-Element identifizieren. Um in einem
solchen Fall der letzten Spalte der vorhergehenden Tabelle ein
bestimmtes Format zuzuweisen, grenzen wir sie wie folgt aus:
Das Attribut width des
Elements COLGROUP wird an alle 40 Spalten vererbt.
Das erste COL-Element bezieht sich auf die ersten 39
Spalten (ohne ihnen etwas Besonderes zuzuweisen) und das zweite
weist der vierzigsten Spalte einen id Wert zu, so dass
Stylesheets sich darauf beziehen können.
Die Tabelle im folgenden Beispiel enthält zwei
Spaltengruppen. Die erste Spaltengruppe enthält 10 Spalten und
die zweite 5 Spalten. Die Standardbreite für jede Spalte in
der ersten Spaltengruppe ist 50 Pixel. Die Breite jeder Spalte in
der zweiten Spaltengruppe wird die minimal benötigte für
diese Spalte sein.
Dieses Attribut, dessen Wert eine Ganzzahl größer 0
sein muss, gibt die Anzahl der Spalten an, die vom Element COL »aufgespannt« werden; das Element
COL teilt sich seine Attribute mit allen
Spalten, über die es sich erstreckt. Der Standardwert für
dieses Attribut ist 1 (d.h., das Element COL bezieht sich auf eine einzige Spalte).
Ist für das span-Attribut N
> 1, teilt das aktuelle COL-Element seine
Attribute mit den nächsten N-1 Spalten.
Dieses Attribut gibt eine Standardbreite für jede Spalte
an, über die sich das aktuelle COL-Element
erstreckt. Es hat die gleiche Bedeutung wie das Attribut width für das Element COLGROUP und überschreibt es.
Das Element COL gestattet Autoren, Attributangaben
für Tabellenspalten (in Gruppen) zusammenzufassen. COL gruppiert Spalten
nicht strukturell, denn das ist Aufgabe des
Elements COLGROUP. COL-Elemente sind
leer und dienen nur als Unterstützung für Attribute. Sie
können innerhalb oder außerhalb einer expliziten
Spaltengruppe (d.h., dem COLGROUP-Element)
erscheinen.
Das Attribut width des
Elements COL bezieht sich auf die Breite jeder
Spalte innerhalb der Spannweite des Elements.
Es gibt zwei Möglichkeiten, die Anzahl der Spalten in einer
Tabelle zu bestimmen (in der Reihenfolge ihrer Priorität):
Enthält das Element TABLECOLGROUP- oder COL-Elemente, sollten Benutzerprogramme
die Anzahl der Spalten durch folgende Addition errechnen:
Verwende für jedes COL-Element den Wert
seines span-Attributs (Standardwert 1).
Ignoriere für jedes COLGROUP-Element, das
mindestens ein COL-Element enthält, das span-Attribut eben dieses COLGROUP-Elements. Vollziehe für
jedes COL-Element die Berechnung aus Schritt
1.
Nimm für jedes leere COLGROUP-Element den
Wert seines span-Attributs (Standardwert
1).
Ansonsten, wenn das Element TABLE keine COLGROUP- oder COL-Elemente enthält, sollten
Benutzerprogramme die Anzahl der Spalten aufgrund der Anforderung
der Tabellenzeilen bestimmen. Die Anzahl der Spalten ist gleich der
Anzahl der Spalten, die von der Zeile mit den meisten Spalten
gefordert wird, eingeschlossen Zellen, die sich über mehrere
Spalten erstrecken. Für jede Zeile, die weniger als diese
Anzahl Spalten hat, sollte das Ende mit leeren Zellen
aufgefüllt werden. Das »Ende« einer Zeile ist
abhängig von der Tabellenrichtung.
Es ist ein Fehler, wenn Tabellen COLGROUP oder COL-Elemente enthalten und die beiden
Berechnungen nicht die gleiche Spaltenanzahl ergeben.
Hat das Benutzerprogramm die Anzahl der Spalten in einer Tabelle
berechnet, kann es die Spalten in Spaltengruppen einteilen.
Zum Beispiel sollten für jede der folgenden Tabellen die
beiden Spaltenberechnungsmethoden drei Spalten ermitteln. Die
ersten drei Tabellen können inkrementell aufgebaut werden.
Autoren haben drei Möglichkeiten die Spaltenbreite
anzugeben:
Fest
Eine feste Breitenangabe wird in Pixeln angegeben (z.B. width=»30«). Eine feste Breitenangabe
ermöglicht einen inkrementellen Aufbau.
Prozentual
Eine prozentuale Angabe (z.B. width=»20%«) basiert auf dem Prozentsatz
des horizontalen Raums, der für die Tabelle zur Verfügung
steht (zwischen dem aktuellen linken und rechten Rand, gleitende
Objekte eingeschlossen). Beachten Sie, dass dieser Raum nicht von
der Tabelle selbst abhängig ist, und prozentuale Angaben
deshalb einen inkrementellen Aufbau gestatten.
Proportional
Proportionale Angaben (z.B. width=»3*«) beziehen sich auf den
horizontalen Raum, der von der Tabelle gefordert wird.
Wird der Tabellenbreite über das Attribut width des Elements TABLE ein fester Wert zugewiesen,
können Benutzerprogramme die Tabelle sogar mit proportionalen
Spalten inkrementell aufbauen.
Hat die Tabelle jedoch keine feste Breite, müssen
Benutzerprogramme alle Tabellendaten empfangen, bevor sie den
horizontalen Raum ermitteln können, der von der Tabelle
benötigt wird. Nur dann kann dieser Raum den proportionalen
Spalten zugeordnet werden.
Gibt ein Autor keinen Informationen zur Breite einer Spalte an,
ist ein Benutzerprogramm eventuell nicht in der Lage, die Tabelle
inkrementell zu formatieren, weil es auf die Übertragung der
gesamten Spaltendaten warten muss, um die entsprechenden Breiten
zuzuordnen.
Erweisen sich Spaltenbreiten als zu eng für den Inhalt
einer bestimmten Tabellenzelle, müssen Benutzerprogramme die
Tabelle eventuell neu aufbauen.
Anmerkung der Übersetzer:
Die Möglichkeit, dass eine Tabelle inkrementell aufgebaut
werden kann, ist ein wichtiger, aber nicht der einzige Aspekt, den
Autoren bei Vorgaben zu Tabellen- bzw. Spaltenbreiten beachten
sollten. Eine feste Vorgabe in Pixeln etwa kann Tabellen sehr
»starr« werden lassen. Im Extremfall würde dies zu dem
Ergebnis führen, dass vorhandene Fenster- oder Frame-Breiten
nicht ausreichen; die Nutzer müssten dann scrollen. Wenn diese
Gefahr besteht und es sich nicht gerade um sehr lange Tabellen
handelt, ist es daher im Interesse einer benutzerfreundlichen
Darstellung sicher legitim, auch einmal auf inkrementellen Aufbau
zu verzichten. Besonders wichtig ist dann jedoch, dass der
Platzbedarf für eventuell enthaltene Objekte und Graphiken,
deren Ladezeiten naturgemäß größer sind,
angegeben wird (zum Beispiel über width- und height-Attribute).
Web-Seiten werden zunehmend dynamisch generiert, sei es aus
Datenbanken oder durch Einbeziehung wechselnder Inhalte aus anderen
Quellen. Auch in diesen Fällen ist besondere Sorgfalt beim
Tabellendesign geboten: Da der Autor den Inhalt der Tabelle zum
Zeitpunkt ihrer Erstellung noch nicht kennt, muss er sie so
gestalten, dass sie sich flexibel sowohl an Nutzer und ihre
Umgebungen, als auch auch an wechselnde Inhalte anpasst. Feste
Vorgaben können dabei ausgesprochen hinderlich sein.
Die Tabelle in diesem Beispiel enthält sechs Spalten. Die
erste gehört nicht zu einer expliziten Spaltengruppe. Die
nächsten drei gehören zur ersten expliziten
Spaltengruppe, und die letzten beiden gehören zur zweiten
expliziten Spaltengruppe. Diese Tabelle kann nicht inkrementell
formatiert werden, weil sie proportionale Breitenangaben für
Spalten enthält und keinen Wert für das width-Attribut des TABLE-Elements.
Wenn das (visuelle) Benutzerprogramm die Tabellendaten empfangen
hat, wird der verfügbare horizontale Raum vom Benutzerprogramm
wie folgt zugewiesen: Zuerst wird das Benutzerprogramm den Spalten
eins und zwei je 30 Pixel zuweisen, dann wird der minimal
nötige Raum für die dritte Spalte reserviert. Der
verbleibende horizontale Raum wird in sechs gleich Teile geteilt
(weil 2* + 1* + 3* = 6 Teile). Spalte vier (2*) bekommt zwei dieser
Teile, Spalte fünf (1*) bekommt einen Teil und Spalte sechs
(3*) erhält drei.
Wir haben den Wert des Attributs align in der dritten Spaltengruppe auf
»center« gesetzt. Alle Zellen in jeder Spalte dieser Gruppe
erben diesen Wert, können ihn jedoch auch überschreiben.
In der Tat tut das letzte COL genau das, indem
es angibt, dass jede Zelle in der Spalte, für die es gilt, am
Zeichen »:« ausgerichtet wird.
In der folgenden Tabelle gestattet die Spaltenbreitenangabe dem
Benutzerprogramm, die Tabelle inkrementell zu formatieren:
Die ersten zehn Spalten werden jeweils 15 Pixel breit sein. Die
beiden letzten Spalten werden jeweils die Hälfte der
verbleibenden 50 Pixel unter sich aufteilen. Beachten Sie, dass die
COL-Elemente nur auftauchen, damit ein id-Wert für die letzten beiden
Spalten angegeben werden kann.
Anmerkung: Obwohl das Attribut width des Elements TABLE nicht missbilligt ist, werden
Autoren angehalten, Stylesheets zur Angabe von Tabellenbreiten zu
verwenden.
Das Element TR fungiert als Behälter für
eine Zeile von Tabellenzellen. Der End-Tag kann weggelassen
werden.
Diese Beispieltabelle enthält drei Zeilen, jede eingeleitet
durch ein TR-Element:
<TABLE summary="Diese Tabelle zeigt die Anzahl der
Tassen Kaffee, die von jedem Senator
konsumiert werden, die Art des Kaffees
(koffeinfrei oder normal) und, ob er mit
Zucker getrunken wird.">
<CAPTION>Von jedem Senator konsumierte Tassen Kaffee</CAPTION>
<TR> ...Eine Kopfzeile...
<TR> ...Erste Zeile mit Daten...
<TR> ...Zweite Zeile mit Daten......der Rest der Tabelle...
</TABLE>
<!ELEMENT (TH|TD) - O (%flow;)* -- table header cell, table data cell-->
<!-- Scope is simpler than headers attribute for common tables -->
<!ENTITY % Scope "(row|col|rowgroup|colgroup)">
<!-- TH is for headers, TD for data, but for cells acting as both use TD -->
<!ATTLIST (TH|TD) -- header or data cell --
%attrs; -- %coreattrs, %i18n, %events --
abbr%Text; #IMPLIED -- abbreviation for header cell --
axisCDATA #IMPLIED -- comma-separated list of related headers--
headersIDREFS #IMPLIED -- list of id's for header cells --
scope%Scope; #IMPLIED -- scope covered by header cells --
rowspanNUMBER 1 -- number of rows spanned by cell --
colspanNUMBER 1 -- number of cols spanned by cell --
%cellhalign; -- horizontal alignment in cells --
%cellvalign; -- vertical alignment in cells --
>
Dieses Attribut gibt die Liste der Kopfzellen an, die
Kopf-Informationen für die aktuelle Datenzelle beinhalten. Der
Wert dieses Attributs ist eine durch Leerzeichen getrennte Liste
von Zellnamen; diese Zellen müssen durch Angabe ihres id-Attributs benannt werden. Autoren
verwenden das headers-Attribut im
Allgemeinen, um nicht visuellen Benutzerprogrammen bei der
Darstellung von Kopfinformationen für Datenzellen zu helfen
(z.B. wird die Kopfinformation vor den Daten der Zelle gesprochen),
jedoch könnte das Attribut auch in Verbindung mit Stylesheets
verwendet werden. Siehe auch: das Attribut scope.
Dieses Attribut gibt die Gruppe der Datenzellen an, für
die die aktuelle Kopfzelle Kopfinformationen bereit hält.
Dieses Attribut kann anstelle des Attributs headers verwendet werden, insbesondere
für einfache Tabellen. Ist dieses Attribut angegeben, muss es
einen der folgenden Werte haben:
row: Die aktuelle Zelle enthält
Kopfinformationen für den Rest der Zeile, die sie enthält
(siehe auch den Abschnitt über Tabellenrichtung).
col: Die aktuelle Zelle enthält
Kopfinformationen für den Rest der Spalte, die sie
enthält.
rowgroup: Die Kopfzelle enthält
Kopfinformationen für den Rest der Zeilengruppe, die sie enthält.
colgroup: Die Kopfzelle enthält
Kopfinformationen für den Rest der Spaltengruppe, die sie enthält.
Dieses Attribut sollte verwendet werden, um eine
abgekürzte Form des Zellinhalts zur Verfügung zu stellen
und könnte von Benutzerprogrammen dargestellt werden, wenn es
anstelle des Zellinhalts sinnvoll ist. Abgekürzte Namen
sollten kurz sein, weil Benutzerprogramme sie wiederholt darstellen
könnten. Zum Beispiel könnten Sprachsythesizer den
abgekürzten Kopf wiedergeben, der zu einer bestimmten Zelle
gehört, bevor dieser Zellinhalt selbst wiedergegeben
wird.
Dieses Attribut kann dazu verwendet werden, eine Zelle in
konzeptionelle Kategorien einzuordnen, die als Achsen in einem
n-dimensionalen Raum betrachtet werden können.
Benutzerprogramme können Benutzern Zugang zu diesen Kategorien
gewähren (z.B. könnte der Benutzer nach allen Zellen
fragen, die zu bestimmten Kategorien gehören, das
Benutzerprogramm könnte eine Tabelle in Form eines
Inhaltsverzeichnisses darstellen usw.). Bitte lesen Sie den
Abschnitt »Zellen
kategorisieren« für weiterführende Informationen.
Der Wert dieses Attributs ist eine durch Kommata getrennte Liste
von Kategorienamen.
Dieses Attribut gibt die Anzahl der Zeilen an, über die
sich die aktuelle Zelle erstreckt. Der Standardwert dieses
Attributs ist eins (»1«). Der Wert Null (»0«) bedeutet,
dass sich die Zelle von der aktuellen Zeile bis zur letzen Zeile
des Tabellenabschnitts erstreckt (THEAD, TBODY oder TFOOT), in dem die Zelle definiert
ist.
Dieses Attribut gibt die Anzahl der Spalten an, über die
sich die aktuelle Zelle erstreckt. Der Standardwert dieses
Attributs ist eins (»1«). Der Wert Null (»0«) bedeutet,
dass sich die Zelle über alle Spalten von der aktuellen Spalte
bis zur letzten Spalte der Spaltengruppe (COLGROUP) erstreckt, in der die Zelle
definiert ist.
Missbilligt.
Ist dieses Boolesche Attribut angegeben, deutet es visuellen
Benutzerprogrammen, dass sie den automatischen Zeilenumbruch
für diese Zelle ausschalten sollen. Stylesheets sollten anstelle
dieses Attributs verwendet werden, um Umbrucheffekte zu erzielen.
Anmerkung: Wird dieses Attribut nicht
sorgfältig verwendet, können ausgesprochen breite Zellen
das Ergebnis sein.
Tabellenzellen können zwei Informationsarten enthalten:
Kopfinformationen
und Daten. Diese
Unterscheidung verhilft Benutzerprogrammen dazu, Kopf- und
Datenzellen unterschiedlich darzustellen, selbst wenn keine
Stylesheets vorhanden sind. Zum Beispiel könnten
Benutzerprogramme Text in Kopfzellen in fettgedruckter Schrift
darstellen. Sprachsynthesizer könnten die Kopfinformationen in
einem anderen Tonfall sprechen.
Das Element TH definiert eine Zelle, die
Kopfinformationen enthält. Benutzerprogrammen stehen zwei
Arten der Kopfinformationen zur Verfügung: der Inhalt des
Elements TH und der Wert des Attributs abbr. Benutzerprogramme müssen
entweder den Inhalt der Zelle oder den Wert des Attributs abbr darstellen. Für visuelle Medien
kann das Letztere angebracht sein, wenn ungenügend Platz zur
Darstellung des gesamten Zelleninhalts zur Verfügung steht.
Für nicht visuelle Medien kann abbr als
Abkürzung für Tabellenköpfe verwenden, wenn diese
zusammen mit dem Inhalt der Zellen, für die sie gültig
sind, wiedergegeben werden.
Die Attribute headers und scope gestatten es Autoren ebenfalls,
nicht visuellen Benutzerprogrammen bei der Verarbeitung der
Kopfinformationen zu helfen. Bitte lesen Sie die Informationen und
Beispiele im Abschnitt »Kopfinformationen mit Datenzellen
verknüpfen« für nicht visuelle
Benutzerprogramme.
Das Element TD definiert eine Zelle, die Daten
enthält.
Zellen können leer sein (d.h. keine Daten enthalten).
Zum Beispiel enthält die folgende Tabelle vier Spalten mit
Daten, jede mit einer Spaltenbeschreibung als Überschrift.
<TABLE summary="Diese Tabelle zeigt die Anzahl der
Tassen Kaffee, die von jedem Senator
konsumiert werden, die Art des Kaffees
(koffeinfrei oder normal) und, ob er mit
Zucker getrunken wird.">
<CAPTION>Von jedem Senator konsumierte Tassen Kaffee</CAPTION>
<TR>
<TH>Name</TH>
<TH>Tassen</TH>
<TH>Kaffeesorte</TH>
<TH>Zucker?</TH>
<TR>
<TD>T. Sexton</TD>
<TD>10</TD>
<TD>Espresso</TD>
<TD>Nein</TD>
<TR>
<TD>J. Dinnen</TD>
<TD>5</TD>
<TD>Koffeinfrei</TD>
<TD>Ja</TD>
</TABLE>
Ein Benutzerprogramm, das die Tabelle über ein
tty-Gerät ausgibt, könnte dies wie folgt darstellen:
Name Tassen Kaffeesorte Zucker?
T. Sexton 10 Espresso Nein
J. Dinnen 5 Koffeinfrei Ja
Zellen können sich über mehrere Zeilen oder Spalten
erstrecken. Die Anzahl der Zeilen oder Spalten, über die sich
die Zelle erstreckt, wird von den Attributen rowspan und colspan der Elemente TH und TD angegeben.
In dieser Tabellendefinition geben wir an, dass sich die Zelle
in Zeile vier, Spalte zwei über drei Spalten
einschließlich der aktuellen Spalte erstrecken soll.
Diese Tabelle könnte von einem visuellen Benutzerprogramm
auf tty-Gerät wie folgt ausgegeben werden:
Von jedem Senator konsumierte Tassen Kaffee
--------------------------------------
| Name |Tassen|Kaffeesorte|Zucker?|
--------------------------------------
|T. Sexton|10 |Espresso |Nein |
--------------------------------------
|J. Dinnen|5 |Koffeinfrei|Ja |
--------------------------------------
|A. Soria |Nicht verfügbar |
--------------------------------------
Das nächste Beispiel zeigt (mit Hilfe von Tabellenrahmen)
wie Zelldefinitionen, die sich über mehr als eine Zeile oder
Spalte erstrecken, die Definitionen der weiteren Zellen
beeinflussen:
Weil sich Zelle »2« über die erste und zweite Zeile
erstreckt, wird die Definition der zweiten Zeile dies
berücksichtigen. Deshalb definiert das zweite TD in Zeile zwei in diesem Fall die dritte
Zelle der Zeile. Visuell könnte die Tabelle von einem
tty-Gerät wie folgt dargestellt werden:
Ein graphisches Benutzerprogramm hingegen könnte dies so
darstellen:
Beachten Sie: Wenn das TD, welches Zelle
»6« definiert, weggelassen worden wäre, wäre eine
zusätzliche leere Zelle durch das Benutzerprogramm
hinzugefügt worden, um die Zeile zu vervollständigen.
Ähnlich erstreckt sich Zelle »4« in der folgenden
Tabellendefinition:
Ein graphisches Benutzerprogramm könnte dies so
darstellen:
Übereinander liegende Zellen zu definieren, ist ein Fehler.
Benutzerprogramme können sich in der Behandlung dieses Fehlers
unterscheiden (zum Beispiel kann die Darstellung variieren).
Das folgende nicht gültige Beispiel zeigt, wie jemand
übereinander liegende Zellen erzeugen könnte. In dieser
Tabelle erstreckt sich Zelle »5« über zwei Zeilen und
Zelle »7« erstreckt sich über zwei Spalten, so gibt es
eine Überlappung in der Zelle zwischen »7« und
»9«:
Anmerkung: Der folgende Abschnitt
beschreibt die Tabellenattribute in HTML, die die visuelle
Formatierung betreffen. Als diese Spezifikation 1997 das erste Mal
veröffentlicht wurde, stellte [CSS1]
nicht alle Mechanismen zur Verfügung, um alle Aspekte der
visuellen Tabellenformatierung zu kontrollieren. Seit dieser Zeit
hat [CSS2] Eigenschaften hinzugefügt, die
eine visuelle Formatierung von Tabellen gestatten.
Dieses Attribut gibt an, welche Linien zwischen den Zellen
innerhalb einer Tabelle angezeigt werden. Die Darstellung von
Linien ist abhängig vom Benutzerprogramm. Mögliche Werte:
none: Keine Linien. Dies ist der
Standardwert.
groups: Linien erscheinen nur zwischen
Zeilengruppen (siehe THEAD, TFOOT und TBODY) und
Spaltengruppen (siehe COLGROUP und COL).
rows: Linien erscheinen nur zwischen Zeilen.
cols: Linien erscheinen nur zwischen Spalten.
all: Linien erscheinen zwischen allen Zeilen und
Spalten.
Dieses Attribut gibt die Breite (nur in Pixeln) des Rahmens um
eine Tabelle an (siehe Anmerkung unten für weitere
Informationen über dieses Attribut).
Um die Zellen einer Tabelle auseinander zu halten, können
wir das Attribut border des
Elements TABLE verwenden. Betrachten wir ein
vorhergehendes Beispiel:
<TABLE border="1"
summary="Diese Tabelle zeigt die Anzahl der
Tassen Kaffee, die von jedem Senator
konsumiert werden, die Art des Kaffees
(koffeinfrei oder normal) und, ob er mit
Zucker getrunken wird.">
<CAPTION>Von jedem Senator konsumierte Tassen Kaffee</CAPTION>
<TR>
<TH>Name</TH>
<TH>Tassen</TH>
<TH>Kaffeesorte</TH>
<TH>Zucker?</TH>
<TR>
<TD>T. Sexton</TD>
<TD>10</TD>
<TD>Espresso</TD>
<TD>Nein</TD>
<TR>
<TD>J. Dinnen</TD>
<TD>5</TD>
<TD>Koffeinfrei</TD>
<TD>Ja</TD>
</TABLE>
Im folgenden Beispiel sollte das Benutzerprogramm einen
fünf Pixel breiten Rand auf der linken und auf der rechten
Seite der Tabelle darstellen und Linien zwischen jeder Spalte.
So könnte die Darstellung in einem visuellen
Benutzerprogramm aussehen:
Die folgenden Einstellungen sollten von Benutzerprogrammen aus
Gründen der Rückwärtskompatibilität
überwacht werden:
Die Angabe border=»0«
impliziert frame=»void« und, wenn nicht
anders angegeben, rules=»none«.
Andere Werte für border
implizieren frame=»border« und, wenn nicht
anders angegeben, rules=»all«.
Der Wert »border« im Start-Tag des Elements TABLE sollte wie der Wert des Attributs frame interpretiert werden. Er
impliziert rules=»all« und irgendwelche
Standardwerte (ungleich Null) für das Attribut border.
Zum Beispiel sind die folgenden Definitionen
äquivalent:
Anmerkung: Das Attribut border definiert auch das
Erscheinungsbild der Rahmen für die Elemente OBJECT und IMG, verwendet jedoch
andere Werte für diese Elemente.
Dieses Attribut bestimmt die Ausrichtung der Daten und die
Anordnung von Text in einer Zelle. Mögliche Werte:
left: Daten fließen nach links/Text links
ausrichten. Das ist der Standardwert für Tabellendaten.
center: Daten zentrieren/Text zentrieren. Das ist
der Standardwert für Tabellenköpfe.
right: Daten fließen nach rechts/Text rechts
ausrichten.
justify: Richtet Text an beiden Rändern
aus.
char: Richtet Text an einem bestimmten Zeichen
aus. Unterstützt ein Benutzerprogramm diese Zeichenausrichtung
nicht, ist das Verhalten bei Angabe dieses Werts nicht
definiert.
Dieses Attribut bestimmt die vertikale Position von Daten
innerhalb einer Zelle. Mögliche Werte:
top: Zelldaten werden am oberen Rand der Zelle
ausgerichtet.
middle: Zelldaten werden vertikal in der Mitte der
Zelle ausgerichtet. Dies ist der Standardwert.
bottom: Zelldaten werden am unteren Rand der Zelle
ausgerichtet..
baseline: Befindet sich in einer Zeile eine Zelle
mit einem valign-Attribut, das diesen Wert trägt,
sollten alle Zellen dieser Zeile ihre Textdaten so anordnen, dass
die erste Textzeile jeder Zelle auf einer gemeinsamen Grundlinie
erscheint. Diese Beschränkung wirkt nicht auf die folgenden
Textzeilen in diesen Zellen.
Dieses Attribut gibt ein einzelnes Zeichen in einem
Textfragment an, dass als Achse für die Ausrichtung fungiert.
Der Standardwert für dieses Attribut ist das
Dezimaltrennzeichen der aktuellen Sprache, die durch das Attribut
lang eingestellt ist (z.B. der Punkt
(».«) im Englischen und das Komma (»,«) im
Französischen). Benutzerprogramme müssen dieses Attribut
nicht unterstützen.
Ist dieses Attribut gesetzt, gibt es den Randabstand zum ersten
Ausrichtungszeichen in jeder Zeile an. Enthält eine Zeile kein
Zeichen zur Ausrichtung, sollte sich das Ende der Textzeile
horizontal zur Ausrichtungsposition verlagern.
Wird charoff verwendet, um den Abstand eines
Zeichens zur Ausrichtung anzugeben, wird die Richtung des Abstands
durch die aktuelle Textflussrichtung bestimmt (die durch das
Attribut dir angegeben ist). Verläuft der Text
von links nach rechts (Standard), wird der Abstand vom linken Rand
gemessen. Verläuft der Text von rechts nach links, ist der
Abstand vom rechten Rand maßgebend. Benutzerprogramme
müssen dieses Attribut nicht unterstützen.
Anmerkung der Übersetzer:
Derzeit verbreitete Browser unterstützen das Attribut charoff nicht.
Die Tabelle in diesem Beispiel richtet einige Währungswerte
an einem Dezimalpunkt aus. Wir setzen das Ausrichtungszeichen
explizit auf ».«.
Enthält der Inhalt einer Zelle mehr als eine Instanz des
Ausrichtungszeichens, das durch char angegeben ist
und der Inhalt bricht um, ist das Verhalten von Benutzerprogrammen
nicht definiert. Autoren sollten deshalb achtsam mit char umgehen.
Anmerkung: Visuelle Benutzerprogramme
zentrieren TH-Elemente im Allgemeinen vertikal und
horizontal in einer Zelle und stellen sie in fettgedruckten
Buchstaben dar.
Die Ausrichtung von Zellinhalt kann Zelle für Zelle
angegeben oder von einschließenden Elementen wie Zeilen,
Spalten oder der Tabelle selbst vererbt werden.
Die Rangfolge (vom höchsten zum niedrigsten Rang) für
die Attribute align, char und charoff ist die folgende:
Ein für ein Element innerhalb der Zelldaten gesetztes
Ausrichtungsattribut (z.B. P).
Ein für eine Zelle gesetztes Ausrichtungsattribut (TH und TD).
Ein für ein Spaltengruppen-Elements gesetztes
Ausrichtungsattribut (COL und COLGROUP). Ist eine Zelle Teil eines
mehrspaltigen Bereiches, wird die Ausrichtungseigenschaft von der
Zelldefinition am Anfang des Bereiches vererbt.
Ein für eine Zeile oder ein Zeilengruppen-Element
gesetztes Ausrichtungsattribut (TR, THEAD, TFOOT und TBODY). Ist eine Zelle Teil eines
mehrzeiligen Bereiches, wird die Ausrichtungseigenschaft von der
Zelldefinition am Anfang des Bereiches vererbt.
Ein für die Tabelle gesetztes Ausrichtungsattribut (TABLE).
Der Standardausrichtungswert.
Die Rangfolge (vom höchsten zum niedrigsten Rang) für
die Attribute valign (wie auch
für die anderen vererbten Attribute lang, dir und style) ist die folgende:
Ein für ein Element innerhalb der Zelldaten gesetztes
Attribut (z.B. P).
Ein für eine Zelle gesetztes Attribut (TH und TD).
Ein für eine Zeile oder ein Zeilengruppen-Element
gesetztes Attribut (TR, THEAD, TFOOT und TBODY). Ist eine Zelle Teil eines
mehrzeiligen Bereiches, wird die Ausrichtungseigenschaft von der
Zelldefinition am Anfang des Bereiches vererbt.
Ein für ein Spaltengruppen-Elements gesetztes Attribut (COL und COLGROUP). Ist eine Zelle Teil eines
mehrspaltigen Bereiches, wird die Ausrichtungseigenschaft von der
Zelldefinition am Anfang des Bereiches vererbt.
Außerdem bestimmen bei der Darstellung von Zellen Spalten
bevorzugt vor Zeilen die horizontale Ausrichtung, während bei
vertikaler Ausrichtung Zeilen Vorrang vor Spalten haben.
Die Standardausrichtung für Zellen ist abhängig vom
Benutzerprogramm. Jedoch sollten Benutzerprogramme den
voreingestellten Wert der aktuellen Textflussrichtung anpassen
(d.h., nicht nur »left« in allen Fällen).
Benutzerprogramme, die den Wert »justify« des Attributs align nicht unterstützen, sollten
den Wert der vererbten Textflussrichtung an seiner Stelle
verwenden.
Anmerkung: Beachten Sie,
dass eine Zelle ein Attribut nicht von seinem Elternelement erben
kann, sondern von der ersten Zelle in einem Bereich. Dies ist eine
Ausnahme von den allgemeinen Vererbungsregeln für
Attribute.
Dieses Attribut gibt an, wie viel Leerraum das Benutzerprogramm
stehen lassen soll zwischen der linken Seite der Tabelle und der
linken Seite der am weitesten links stehenden Spalte, der oberen
Kante der Tabelle und der Oberkante der obersten Zeile und so fort
für die rechte Seite und die Unterkante. Das Attribut gibt
ebenfalls an, wieviel Freiraum zwischen Zellen bleiben soll.
Dieses Attribut gibt die Größe des Leerraums zwischen
dem Rand der Zelle und ihrem Inhalt an. Ist der Wert dieses
Attributs eine Pixelmaß, sollten alle vier Ränder diesen
Abstand vom Inhalt haben. Ist der Wert des Attributs ein
prozentuales Maß, sollten der obere und untere Rand
gleichermaßen vom Inhalt abgesetzt werden, basierend auf einem
prozentualen Anteil des zur Verfügung stehenden vertikalen
Raums, der linke und der rechte Rand sollten gleichermaßen vom
Inhalt abgesetzt werden, basierend auf einem prozentualen Anteil
des zur Verfügung stehenden horizontalen Raums.
Diese beiden Attribute kontrollieren die Abstände zwischen
und innerhalb von Zellen. Die folgende Darstellung illustriert die
Beziehung zwischen ihnen:
Im folgenden Beispiel gibt das Attribut cellspacing an, dass Zellen voneinander
und vom Tabellenrahmen 20 Pixel Abstand halten sollten. Das
Attribut cellpadding gibt an,
dass der obere Rand der Zelle und der untere Rand der Zelle jeweils
einen Abstand von 10% des verfügbaren horizontalen Raums
(zusammen 20%) zum Zellinhalt halten sollen. Ähnlich werden
der linke Rand der Zelle und der rechte Rand der Zelle jeweils
einen Abstand von 10% des verfügbaren horizontalen Raums
(zusammen 20%) einhalten.
Hat eine Tabelle oder eine gegebene Spalte eine feste Breite,
könnten cellspacing und cellpadding mehr Raum fordern als
zugewiesen ist. Benutzerprogramme können diesen Attributen
Vorrang vor dem Attribut width
gewähren, wenn Konflikte auftreten, jedoch sie sind nicht dazu
verpflichtet.
Nicht visuelle Benutzerprogramme wie Sprachsynthesizer und
Braille-basierte Geräte könnten die folgenden Attribute
der Elemente TD und TH verwenden, um
Tabellenzellen intuitiver darzustellen:
Für eine gegebene Datenzelle listet das Attribut headers auf, welche Zellen relevante
Kopfinformationen bieten. Zu diesem Zweck muss jede Kopfzelle
über ein id-Attribute benannt werden. Beachten Sie,
dass es nicht immer möglich ist, eine klare Trennung zwischen
Kopf- und Datenzellen zu machen. Sie sollten das TD-Element für solche Zellen zusammen
mit dem id- oder scope-Attribut
verwenden, je nachdem, welches sinnvoll ist.
Für eine
gegebene Kopfzelle teilt das Attribut scope dem Benutzerprogramm mit, für
welche Datenzellen dieser Kopf Informationen bereithält.
Autoren wählen vielleicht dieses Attribut anstatt headers, je nachdem, welches
günstiger ist; beide Attribute erfüllen die gleiche
Funktion. Das Attribut headers wird im
Allgemeinen benötigt, wenn Kopfinformationen an
ungewöhnlichen Positionen in Bezug auf die Daten stehen,
für die sie gelten.
Das
Attribut abbr gibt einen abgekürzten
Kopfinhalt für Kopfzellen an, so dass Benutzerprogramme
Kopfinformationen schneller darstellen können.
Im folgenden Beispiel weisen wir Zellen Kopfinformationen durch
die Angabe des Attributs headers zu. Jede
Zelle in derselben Spalte bezieht sich auf dieselbe Kopfzelle
(über das id-Attribut).
<TABLE border="1"
summary="Diese Tabelle zeigt die Anzahl der
Tassen Kaffee, die von jedem Senator
konsumiert werden, die Art des Kaffees
(koffeinfrei oder normal) und, ob er mit
Zucker getrunken wird.">
<CAPTION>Von jedem Senator konsumierte Tassen Kaffee</CAPTION>
<TR>
<TH id="t1">Name</TH>
<TH id="t2">Tassen</TH>
<TH id="t3" abbr="Sorte">Kaffeesorte</TH>
<TH id="t4">Zucker?</TH>
<TR>
<TD headers="t1">T. Sexton</TD>
<TD headers="t2">10</TD>
<TD headers="t3">Espresso</TD>
<TD headers="t4">Nein</TD>
<TR>
<TD headers="t1">J. Dinnen</TD>
<TD headers="t2">5</TD>
<TD headers="t3">Koffeinfrei</TD>
<TD headers="t4">Ja</TD>
</TABLE>
Ein Sprachsynthesizer könnte diese Tabelle wie folgt
darstellen:
Beschriftung: Konsumierte Kaffeetassen pro Senator
summary= Diese Tabelle zeigt die Anzahl der
Tassen Kaffee, die von jedem Senator
konsumiert werden, die Art des Kaffees
(koffeinfrei oder normal) und, ob er mit
Zucker getrunken wird.
Name: T. Sexton, Tassen: 10, Sorte: Espresso, Zucker: Nein
Name: J. Dinnen, Tassen: 5, Sorte: Koffeinfrei, Zucker: Ja
Beachten Sie, dass der Kopf »Kaffeesorte« mit Hilfe des
Attributs abbr abgekürzt wird zu
»Sorte«.
Hier ist das gleiche Beispiel mit dem Attribut scope anstelle des Attributs headers. Beachten Sie den Wert »col«
für das scope-Attribut, das besagt »alle Zellen
in der aktuellen Spalte«:
<TABLE border="1"
summary="Diese Tabelle zeigt die Anzahl der
Tassen Kaffee, die von jedem Senator
konsumiert werden, die Art des Kaffees
(koffeinfrei oder normal) und, ob er mit
Zucker getrunken wird.">
<CAPTION>Von jedem Senator konsumierte Tassen Kaffee</CAPTION>
<TR>
<TH scope="col">Name</TH>
<TH scope="col">Tassen</TH>
<TH scope="col" abbr="Sorte">Kaffeesorte</TH>
<TH scope="col">Zucker?</TH>
<TR>
<TD>T. Sexton</TD>
<TD>10</TD>
<TD>Espresso</TD>
<TD>Nein</TD>
<TR>
<TD>J. Dinnen</TD>
<TD>5</TD>
<TD>Koffeinfrei</TD>
<TD>Ja</TD>
</TABLE>
Hier ist ein etwas komplexeres Beispiel zu Illustration anderer
Werte des scope-Attributs:
<TABLE border="1" cellpadding="5" cellspacing="2"
summary="Geschichtskurse der Gemeinde Bath, geordnet nach
Kursname, Tutor, Zusammenfassung, Kursnummer
und Gebühr">
<TR>
<TH colspan="5" scope="colgroup">Kurse der Gemeinde Bath – Herbst 1997</TH>
</TR>
<TR>
<TH scope="col" abbr="name">Kursname</TH>
<TH scope="col" abbr="tutor">Tutor des Kurses</TH>
<TH scope="col">Zusammenfassung</TH>
<TH scope="col">Kursnummer</TH>
<TH scope="col">Gebühr</TH>
</TR>
<TR>
<TD scope="row">Nach dem Bürgerkrieg</TD>
<TD>Dr. John Wroughton</TD>
<TD>
Der Kurs untersucht die turbulenten Jahre nach 1646
in England. <EM>6 wöchentliche Treffen
beginnen am Montag, dem 13. Oktober.</EM>
</TD>
<TD>H27</TD>
<TD>£32</TD>
</TR>
<TR>
<TD scope="row">Eine Einführung ins angelsächsische England</TD>
<TD>Mark Cottle</TD>
<TD>
Eintägiger Kurs zur Einführung in
die frühe mittelalterliche Epoche des
Wandels der Angelsachsen und ihrer
Gesellschaft. <EM>Samstag 18. Oktober.</EM>
</TD>
<TD>H28</TD>
<TD>£18</TD>
</TR>
<TR>
<TD scope="row">Der Ruhm gebührt den Griechen</TD>
<TD>Valerie Lorenz</TD>
<TD>
Die Geburtsstätte der Demokratie und Philosophie, Kernland
des Theaters, Heimat der Argumentation. Die Römer mögen
es vollendet haben, doch die Griechen waren die Ersten.
<EM>Samstag 25. Oktober 1997</EM>
</TD>
<TD>H30</TD>
<TD>£18</TD>
</TR>
</TABLE>
Ein graphisches Benutzerprogramm könnte dies so
darstellen:
Achten Sie auf die Verwendung des scope-Attributs mit dem Wert »row«.
Auch wenn die erste Zelle in jeder Zeile Daten enthält, und
keine Kopfinformationen, sorgt das das Attribut scope dafür, dass die Datenzelle sich
wie eine Zeilen-Kopfzelle verhält. Dadurch können
Sprachsynthesizer auf Anfrage den relevanten Kursnamen angeben oder
ihn direkt vor jedem Zellinhalt vortragen.
Benutzer, die eine Tabelle mit einem sprachbasierten
Benutzerprogramm lesen, möchten vielleicht zusätzlich zum
Zelleninhalt selbst eine Erklärung hören. Eine
Möglichkeit, dem Benutzer eine Erklärung anzubieten
besteht darin, zugehörige Kopfinformationen vor dem Inhalt der
Datenzelle zu sprechen (siehe Abschnitt »Kopfinformationen mit Datenzellen
verknüpfen«).
Benutzer möchten vielleicht auch Informationen über
mehr als eine Zelle erhalten. In diesem Fall könnten
Kopfinformationen auf Zellenebene (durch headers, scope und abbr) nicht den passenden Kontext bieten.
Betrachten Sie die folgende Tabelle, die Unkosten für
Mahlzeiten, Hotels und den Transport in zwei Städten (San Jose
und Seattle) über einige Tage einstuft:
Benutzer möchten vielleicht Informationen aus der Tabelle
in Form von Anfragen herausfiltern:
»Was habe ich für all meine Mahlzeiten
ausgegeben?«
»Was habe ich am 25. August für Mahlzeiten
ausgegeben?«
»Wie hoch waren die Gesamtkosten in San Jose?«
Jede Anfrage zieht eine Verarbeitung durch das Benutzerprogramm
nach sich, die keine oder mehr Zellen umfasst. Um zum Beispiel die
Kosten für Mahlzeiten am 25. August zu bestimmen, muss das
Benutzerprogramm wissen, welche Zellen sich auf »Mahlzeiten«
(alle von ihnen) und welche sich auf »Datumsangaben«
(insbesondere den 25. August) beziehen, und die Schnittmenge der
beiden Bereiche finden.
Um diese Art der Anfrage zu ermöglichen, gestattet das
Tabellenmodell von HTML 4 Autoren , Kopf- und Datenzellen in
Kategorien einzuordnen. Für die Reisekostentabelle zum
Beispiel, kann der Autor die Kopfzellen »San Jose« und
»Seattle« in die Kategorie »Ort«, die Köpfe
»Mahlzeiten«, »Hotels« und »Transport« in die
Kategorie »Ausgaben« und die vier Tage in die Kategorie
»Datum« einordnen. Die drei vorstehenden Fragen hätten
dann die folgende Bedeutung:
»Was habe ich für alle meine Mahlzeiten ausgegeben?«
bedeutet »Wie teuer ist alles zusammen in den Zellen der
Kategorie Ausgaben=Mahlzeiten?«
»Was habe ich am 25. August für Mahlzeiten
ausgegeben?« bedeutet »Wie teuer ist alles zusammen in den
Datenzellen der Kategorien Ausgaben=Mahlzeiten und
Datum=25-Aug-97?«
»Wie hoch waren die Gesamtkosten in San Jose?« bedeutet
»Wie teuer ist alles zusammen in den Datenzellen der Kategorien
Ausgaben=Mahlzeiten, Hotels, Transport und Ort=San
Jose?«
Autoren kategorisieren eine Kopf- oder Datenzelle durch Angabe
des axis-Attributs für die Zelle. In der
Reisekostentabelle zum Beispiel kann die Zelle mit der Information
»San Jose« wie folgt in die Kategorie »Ort« eingeordnet
werden:
<TH id="a6" axis="ort">San Jose</TH>
Jede Zelle, die Informationen bezüglich »San Jose«
enthält, sollte sich auf diese Kopfzelle entweder über
das headers- oder das scope-Attribut beziehen. Deshalb sollten
Ausgaben für Mahlzeiten am 25. August so ausgezeichnet werden,
das sie sich auf das id-Attribute (dessen
Wert hier »a6« ist) der »San Jose«-Kopfzelle
beziehen:
<TD headers="a6">37.74</TD>
Jedes headers-Attribut enthält eine Liste
von id-Referenzen. Autoren können eine
gegebene Zelle so auf unzählige Weise kategorisieren (oder
entlang unzähliger "Köpfe" (engl. headers), daher der
Name).
Im Folgenden zeichnen wir die Reisekostentabelle mit
Kategorieinformationen aus:
Beachten Sie, dass Benutzerprogramme durch die Auszeichnung
einer Tabelle auf diese Weise auch vermeiden können, Benutzer
mit ungewollten Informationen zu verwirren. Sollte zum Beispiel ein
Sprachsynthesizer alle Angaben in der Spalte »Mahlzeiten« der
Tabelle auf die Anfrage »Wie hoch waren all meine Ausgaben
für Mahlzeiten?« sprechen, wäre ein Benutzer nicht in
der Lage, Tagesausgaben von Zwischensummen oder Gesamtsummen zu
unterscheiden. Durch die sorgfältige Kategorisierung der
Datenzellen gestatten Autoren den Benutzerprogrammen, wichtige
semantische Unterschiede bei der Darstellung zu machen.
Natürlich gibt es kein Grenze, inwieweit Autoren
Informationen in einer Tabelle kategorisieren können. In der
Reisekostentabelle könnten wir zum Beispiel die
zusätzlichen Kategorien »Zwischensummen« und
»Gesamtsummen« hinzufügen.
Diese Spezifikation verlangt von Benutzerprogrammen weder, axis-Attribut angegebene Informationen zu
verarbeiten, noch gibt sie irgendwelche Empfehlungen darüber,
wie Benutzerprogramme dem Nutzer die axis -Informationen präsentieren
sollten, oder wie Nutzer diese Informationen beim Benutzerprogramm
erfragen könnten.
Jedoch möchten
Benutzerprogramme, insbesondere Sprachsynthesizer,
eventuell Informationen ausklammern, die in mehreren Zellen
vorkommen, die das Ergebnis einer Anfrage sind. Wenn der Benutzer
zum Beispiel fragt »Was habe ich für Mahlzeiten in San Jose
ausgegeben?«, würde das Benutzerprogramm zuerst die in
Frage kommenden Zellen bestimmen (25-Aug-1997: 37.74,
26-Aug-1997:27.28), und daraufhin diese Informationen darstellen.
Ein Benutzerprogramm, das diese Informationen spricht, könnte
sie so lesen:
Ort: San Jose. Datum: 25-Aug-1997. Ausgaben, Mahlzeiten: 37.74
Ort: San Jose. Datum: 26-Aug-1997. Ausgaben, Mahlzeiten: 27.28
oder kompakter:
San Jose, 25-Aug-1997, Mahlzeiten: 37.74
San Jose, 26-Aug-1997, Mahlzeiten: 27.28
Eine noch ökonomischere Darstellung würde die
gemeinsamen Informationen ausklammern und sie neu ordnen:
San Jose, Mahlzeiten, 25-Aug-1997: 37.74
26-Aug-1997: 27.28
Benutzerprogramme, die diese Art der Darstellung
unterstützen, sollten eine Möglichkeit bieten, die
Darstellung anzupassen (z.B. durch Stylesheets).
Werden keine Kopfinformationen durch das scope- oder das headers-Attribut angegeben, können
Benutzerprogramme nach dem folgenden Algorithmus Kopfinformationen
erzeugen. Das Ziel des Algorithmus ist, eine geordnete Liste mit
Kopfinformationen zu ermitteln. (In der folgenden Beschreibung des
Algorithmus wird die Tabellenrichtung von links nach
rechts angenommen.)
Suche zuerst links der Zellposition, um Kopfzellen für
Zeilen zu finden. Dann suche aufwärts, um Spaltenkopfzellen zu
finden. Die Suche in eine gegebene Richtung stoppt, wenn die Ecke
der Tabelle erreicht ist oder wenn eine Datenzelle nach einer
Kopfzelle gefunden wurde.
Zeilenköpfe werden in der Reihenfolge in die Liste
eingefügt, in der sie in der Tabelle erscheinen. In Tabellen
der Richtung links nach rechts werden die Köpfe von links nach
rechts eingefügt.
Spaltenköpfe werden nach Zeilenköpfen in der
Reihenfolge eingefügt, in der sie in der Tabelle erscheinen,
von oben nach unten.
Ist das headers-Attribut für eine Kopfzelle
angegeben, dann werden die Header, die von diesem Attribut
referenziert werden, in die Liste eingefügt und die Suche
stoppt für die aktuelle Richtung.
TD-Zellen mit dem Attribut axis werden ebenfalls als Kopfzellen
behandelt.
Dieses Beispiel zeigt gruppierte Zeilen und Spalten. Das
Beispiel ist übernommen aus »Developing International
Software« von Nadine Kano.
In ASCII-Darstellung würde die Tabelle
<TABLE border="2" frame="hsides" rules="groups"
summary="Code page support in different versions
of MS Windows.">
<CAPTION>CODE-PAGE SUPPORT IN MICROSOFT WINDOWS</CAPTION>
<COLGROUP align="center">
<COLGROUP align="left">
<COLGROUP align="center" span="2">
<COLGROUP align="center" span="3">
<THEAD valign="top">
<TR>
<TH>Code-Page<BR>ID
<TH>Name
<TH>ACP
<TH>OEMCP
<TH>Windows<BR>NT 3.1
<TH>Windows<BR>NT 3.51
<TH>Windows<BR>95
<TBODY>
<TR><TD>1200<TD>Unicode (BMP of ISO/IEC-10646)<TD><TD><TD>X<TD>X<TD>*
<TR><TD>1250<TD>Windows 3.1 Eastern European<TD>X<TD><TD>X<TD>X<TD>X
<TR><TD>1251<TD>Windows 3.1 Cyrillic<TD>X<TD><TD>X<TD>X<TD>X
<TR><TD>1252<TD>Windows 3.1 US (ANSI)<TD>X<TD><TD>X<TD>X<TD>X
<TR><TD>1253<TD>Windows 3.1 Greek<TD>X<TD><TD>X<TD>X<TD>X
<TR><TD>1254<TD>Windows 3.1 Turkish<TD>X<TD><TD>X<TD>X<TD>X
<TR><TD>1255<TD>Hebrew<TD>X<TD><TD><TD><TD>X
<TR><TD>1256<TD>Arabic<TD>X<TD><TD><TD><TD>X
<TR><TD>1257<TD>Baltic<TD>X<TD><TD><TD><TD>X
<TR><TD>1361<TD>Korean (Johab)<TD>X<TD><TD><TD>**<TD>X
<TBODY>
<TR><TD>437<TD>MS-DOS United States<TD><TD>X<TD>X<TD>X<TD>X
<TR><TD>708<TD>Arabic (ASMO 708)<TD><TD>X<TD><TD><TD>X
<TR><TD>709<TD>Arabic (ASMO 449+, BCON V4)<TD><TD>X<TD><TD><TD>X
<TR><TD>710<TD>Arabic (Transparent Arabic)<TD><TD>X<TD><TD><TD>X
<TR><TD>720<TD>Arabic (Transparent ASMO)<TD><TD>X<TD><TD><TD>X
</TABLE>
ungefähr so dargestellt:
CODE-PAGE SUPPORT IN MICROSOFT WINDOWS
===============================================================================
Code-Page | Name | ACP OEMCP | Windows Windows Windows
ID | | | NT 3.1 NT 3.51 95
-------------------------------------------------------------------------------
1200 | Unicode (BMP of ISO 10646) | | X X *
1250 | Windows 3.1 Eastern European | X | X X X
1251 | Windows 3.1 Cyrillic | X | X X X
1252 | Windows 3.1 US (ANSI) | X | X X X
1253 | Windows 3.1 Greek | X | X X X
1254 | Windows 3.1 Turkish | X | X X X
1255 | Hebrew | X | X
1256 | Arabic | X | X
1257 | Baltic | X | X
1361 | Korean (Johab) | X | ** X
-------------------------------------------------------------------------------
437 | MS-DOS United States | X | X X X
708 | Arabic (ASMO 708) | X | X
709 | Arabic (ASMO 449+, BCON V4) | X | X
710 | Arabic (Transparent Arabic) | X | X
720 | Arabic (Transparent ASMO) | X | X
===============================================================================
Ein graphisches Benutzerprogramm könnte sie so
darstellen:
Dieses Beispiel zeigt, wie COLGROUP verwendet
werden kann, um die Spalten zu gruppieren und die
Standard-Spaltenausrichtung zu setzen. Ähnlich wird TBODY verwendet, um Zeilen zu gruppieren.
Die Attribute frame und rules geben dem
Benutzerprogramm an, welche Rahmen und Linien gezeichnet werden
sollen.
Anmerkung der Übersetzer:
Unter den derzeit gängigen Browsern – immerhin sind
seit der Veröffentlichung dieser HTML-Spezifikation bereits
mehr als drei Jahre vergangen – haben wir nur einen einzigen
gefunden, der die Tabelle vollständig wie gewünscht
darstellt. Das align-Attribut in COLGROUP ignorieren fast alle; mit den
vorgegebenen Rändern und Linien haben nur wenige kein
Problem.
Anmerkung der Übersetzer:
Abschließend zum Thema »Tabellen« hier ein Beispiel,
wie man ein häufig verwendetes – heute vielfach noch mit
Hilfe von Tabellen erreichtes – Layout mittels Stylesheets
realisieren kann:
Stellen wir uns ein dreispaltiges Layout vor, in dem links die
Navigation zu anderen Seiten der Web-Site zu finden ist, in der
Mitte der eigentlich Inhalt steht und rechts sonstige Informationen
untergebracht werden. In der Regel wurden und werden derartige
Seiten durch den Einsatz einer dreispaltige Tabelle realisiert.
Unter Nutzung von Stylesheets (ohne Tabelle) könnte so eine
Seite etwa so aussehen:
So sollte es aussehen, denn bereits bei der Lösung dieser
vergleichsweise einfachen Aufgabe haben einige der getesteten
aktuellen Browser leichte Schwierigkeiten, sie stellen nicht
wirklich sauber dar oder verschieben das Layout bei
geringfügigen Änderungen der Benutzereinstellungen, zum
Beispiel der Schriftgröße – kein wirklich
zufriedenstellendes Ergebnis also, denn so simpel wie dieses sind
Layouts in der Praxis oft nicht. Weniger Probleme entstehen bei
festen Positionierungen und starren Vorgaben für
Schriftgrößen (px), nur ist der Preis dafür,
nämlich die Aufgabe jeglicher Anpassungsfähgkeit, zu
hoch.
Fazit: Stylesheets sind die anzustrebende Alternative für
Tabellenlayouts, aber erst dann eine wirkliche, wenn die
Browserlandschaft ihr gewachsen ist. Bis dahin werden Autoren und
Benutzer mit Einschränkungen und eventuell mit Kompromissen
leben.
Anmerkung der Übersetzer:
Das Tabellenmodell von HTML ist zeilenorientiert. Das heißt
auch, dass Tabellen Zeile für Zeile eingegeben werden. HTML-
oder XML-Editoren gestatten natürlich auch eine Eingabe in
eine graphisch dargestellte Tabelle. Manchmal kann diese
Zeilenorientierung unbequem sein, und man würde sich eine
Spaltenorientierung wünschen. In einem solchen Fall muss die
Tabelle »nur« transponiert werden (das heißt, Spiegelung
an der Hauptdiagonalen). So fern es sich um eine
regelmäßig aufgebaute Tabelle handelt (das heißt,
alle Zeilen haben die gleiche Länge, und es werden keine colspan- und rowspan-Attribute verwendet), lässt sich
eine Transponierung sehr einfach durchführen. Da einer der
Übersetzer kürzlich selbst vor diesem Problem stand,
finden Sie unter www.mintert.com/xslt/ ein
kleines XSLT-Programm, das die Transponierung für eine solche
XHTML-Tabelle durchführt.
