Sie sind auf Seite 1von 885

Titel.fm Seite i Mittwoch, 9.

April 2003 3:26 15

XHTML, CSS & Co.


<W3C.de> Die W3C-Spezifikationen
für das Web-Publishing
Titel.fm Seite ii Mittwoch, 9. April 2003 3:26 15

<edition
    W3C.de>
Die edition W3C.de bietet IT-Experten die maßgebliche Referenz zu den
technischen Grundlagen des WWW. Fachleute haben die englischen
W3C-Recommendations ins Deutsche übersetzt, begutachtet und kommentiert.
Parallel zur Buchreihe finden Sie die Übersetzungen auch online unter
www.edition-w3c.de.

XML & Co
Die W3C-Spezifikationen für Dokumenten-
und Datenarchitektur
Stefan Mintert (Hrsg.)

XML & Co. - das sind XML, XML Schema, XSLT,


XPath, XLink und weitere W3C-Spezifikatio-
nen, die hier kommentiert und in deutscher
Übersetzung vorliegen. Sie bilden die Grund-
lage für den Einsatz von XML zur Dokumen-
ten- und Datenmodellierung, wie auch für die
Verarbeitung von XML. Jeder, der mit oder für
XML Daten entwickelt, muss diese tech-
nischen Standards beherrschen.

edition W3C.de
760 Seiten
€ 59,95 [D] / € 61,70 [A]
ISBN 3-8273-1844-0

„Als gute, vollständige deutsche Übersetzung, kommentiert und mit Beispielen


angereichert ist es ein sehr gutes Handwerkszeug für den deutschen XML-Entwickler.
Gesamturteil, sehr empfehlenswert.“ (Java Spektrum, 1/2003)
Titel.fm Seite iii Mittwoch, 9. April 2003 3:26 15

<edition
Stefan Mintert (Hrsg.)
    W3C.de>

XHTML, CSS & Co.


<W3C.de> Die W3C-Spezifikationen
für das Web-Publishing

eBook
Die nicht autorisierte Weitergabe dieses eBooks
an Dritte ist eine Verletzung des Urheberrechts!

An imprint of Pearson Education


München • Boston • San Francisco • Harlow, England
Don Mills, Ontario • Sydney • Mexico City
Madrid • Amsterdam
Titel.fm Seite iv Mittwoch, 9. April 2003 3:26 15

Bibliografische Information Der Deutschen Bibliothek

Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;


detaillierte bibliografische Daten sind im Internet über <http://dnb.ddb.de> abrufbar.

Die Informationen in diesem Produkt werden ohne Rücksicht auf einen eventuellen Patentschutz veröffentlicht.
Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt.
Bei der Zusammenstellung von Texten und Abbildungen wurde mit größter Sorgfalt vorgegangen.
Trotzdem können Fehler nicht vollständig ausgeschlossen werden.
Verlag, Herausgeber und Autoren können für fehlerhafte Angaben und deren Folgen weder eine juristische
Verantwortung noch irgendeine Haftung übernehmen. Für Verbesserungsvorschläge und Hinweise
auf Fehler sind Verlag und Herausgeber dankbar.

Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in elektronischen Medien.
Die gewerbliche Nutzung der in diesem Produkt gezeigten Modelle und Arbeiten ist nicht zulässig.

Fast alle Hardware- und Softwarebezeichnungen, die in diesem Buch erwähnt werden, sind gleichzeitig auch
eingetragene Warenzeichen oder sollten als solche betrachtet werden.

Umwelthinweis:
Dieses Produkt wurde auf chlorfrei gebleichtem Papier gedruckt.
Die Einschrumpffolie – zum Schutz vor Verschmutzung – ist aus umweltverträglichem und recyclingfähigem
PE-Material.

10 09 08 07 06 05 04 03 02 01

ISBN 3-8273-1872-6

© 2003 by Addison-Wesley Verlag,


ein Imprint der Pearson Education Deutschland GmbH
Martin-Kollar-Straße 10–12, D-81829 München/Germany
Alle Rechte vorbehalten
Einbandgestaltung: Barbara Thoben, Köln
Lektorat: Sylvia Hasselbach, shasselbach@pearson.de
Korrektorat: Johannes Gerritsen, Emmerich-Elten
Satz: reemers publishing services gmbh, Krefeld, www.reemers.de
Druck: Bercker Graphischer Betrieb, Kevelaer
Printed in Germany
Page size: 168,00 x 240,00 mm

Inhaltsverzeichnis
Vorwort 17
Herstellung des Buches, typografische Konventionen und
weitere Formalien 19
Danksagung 20

Einleitung 21
Thematische Einf"hrung und #berblick "ber den Band 22
Die W3C-Spezifikationen in diesem Band 23
Weitere W3C-Spezifikationen und -Texte 25
Internet Society und Internet Engineering Task Force 25
HTTP und MIME 26
MIME-Typen f"r XHTML 27
Uniform Resource Identifier (URI) 28
International Organization for Standardization 31
Organization for the Advancement of Structured
Information Standards 32
Common Gateway Interface 32
Literatur 33

n
A Die HTML 4.01- Spezifikation
1 ber die HTML 4-Spezifikation
1.1
1.2
Wie die Spezifikation aufgebaut ist
Dokumentkonventionen
38
38
39
1.3 Danksagungen 40
1.4 Bemerkung zum Urheberrecht 41
2 Einf%hrung in HTML 4 41
2.1 Was ist das World Wide Web? 41
2.2 Was ist HTML? 44
2.3 HTML 4 45
2.4 Dokumente erstellen mit HTML 4 48
Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

3 ber SGML und HTML 49


3.1 Einf"hrung in SGML 49
3.2 In HTML verwendete SGML-Konstrukte 51
3.3 Wie die HTML-DTD zu lesen ist 54
4 Konformit+t: Anforderungen und Empfehlungen 61
4.1 Definitionen 61
4.2 SGML 63
4.3 Inhaltstyp (Content-Type) text/html 63
5 Repr+sentation von HTML-Dokumenten 64
5.1 Der Dokumentzeichensatz 64
5.2 Zeichenkodierungen 65
5.3 Zeichenreferenzen 70
5.4 Nicht darstellbare Zeichen 72
6 HTML-Grunddatentypen 72
6.1 Information zu Groß- bzw. Kleinschreibung 72
6.2 Grunddatentypen in SGML 73
6.3 Text-Zeichenfolgen 74
6.4 URIs 74
6.5 Farben 75
6.6 Maße 76
6.7 Inhaltstypen (content type) (MIME types) 77
6.8 Sprachcodes 77
6.9 Zeichenkodierungen 77
6.10 Einzelne Zeichen 77
6.11 Datum und Zeit 77
6.12 Linktypen 78
6.13 Medien-Deskriptoren 80
6.14 Skript-Daten 81
6.15 Stylesheet-Daten 82
6.16 Namen von Ziel-Frames (target names) 82
7 Die globale Struktur eines HTML-Dokuments 83
7.1 Einf"hrung in die Struktur eines HTML-Dokuments 83
7.2 HTML-Versionsinformation 84
7.3 Das HTML-Element 85
7.4 Der Dokument-Kopf 86
7.5 Der Dokumentrumpf 96
8 Sprachinformation und Leserichtung 104
8.1 Spezifizierung der Sprache des Inhalts: das lang-Attribut 104
8.2 Spezifizierung der Richtung von Text und Tabellen: das
dir-Attribut 108
9 Text 115
9.1 Leeraum (white space) 115
9.2 Strukturierter Text 116
9.3 Zeilen und AbsEtze 122

<6> Inhaltsverzeichnis
Page size: 168,00 x 240,00 mm

9.4 Kennzeichnen von DokumentEnderungen: Das INS- und das


DEL-Element 128
10 Listen 130
10.1 Einf"hrung in Listen 130
10.2 Ungeordnete Listen (UL), geordnete Listen (OL) und
ListeneintrEge (LI) 132
10.3 Definitionslisten: Die Elemente DL, DT und DD 134
10.4 Das DIR- und das MENU-Element 138
11 Tabellen 138
11.1 Einf"hrung in Tabellen 138
11.2 Elemente zur Tabellenerzeugung 141
11.3 Tabellenformatierung durch visuelle Benutzerprogramme 159
11.4 Tabellendarstellung durch nicht visuelle Benutzerprogramme165
11.5 Beispieltabelle 173
12 Links 178
12.1 Einf"hrung in Links und Anker 178
12.2 Das Element A 182
12.3 Dokumentbeziehungen: das LINK-Element 189
12.4 Pfadangaben: das BASE-Element 192
13 Objekte, Bilder und Applets 193
13.1 Einf"hrung in Objekte, Bilder und Applets 193
13.2 Eine Graphik einbinden: das Element IMG 195
13.3 Allgemeine Objekte einbetten: das Element OBJECT 197
13.4 Einbinden eines Applets: das Element APPLET wird zu
Gunsten des Elements OBJECT missbilligt
(mit all seinen Attributen). 205
13.5 Anmerkungen zu eingebetteten Dokumenten 207
13.6 Imagemaps 208
13.7 Visuelle Darstellung von Bildern, Objekten und Applets 214
13.8 Wie alternativer Text angegeben wird 216
14 Stylesheets 217
14.1 Einf"hrung in Stylesheets 217
14.2 HTML-Dokumente formatieren 219
14.3 Externe Stylesheets 225
14.4 Cascading Style Sheets 228
14.5 Formatierungsangaben vor Benutzerprogrammen verbergen 229
14.6 Mit HTTP-Headern auf Stylesheets verweisen 230
15 Ausrichtung, Schriftarten und horizontale Linien 231
15.1 Formatierung 231
15.2 Schriftarten 236
15.3 Linien: das Element HR 240
16 Frames 241
16.1 Einf"hrung in Frames 241
16.2 Frame-Layout 243

Inhaltsverzeichnis <7>
Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

16.3 Informationen f"r Ziel-Frames angeben 251


16.4 Alternativer Inhalt 254
16.5 Eingebettete Frames: das Element IFRAME 256
17 Formulare 257
17.1 Einf"hrung in Formulare 257
17.2 Steuerelemente 258
17.3 Das Element FORM 261
17.4 Das Element INPUT 263
17.5 Das Element BUTTON 268
17.6 Die Elemente SELECT, OPTGROUP und OPTION 270
17.7 Das Element TEXTAREA 275
17.8 Das Element ISINDEX 276
17.9 Beschriftungen 277
17.10 Formularen Struktur hinzuf"gen: die Elemente FIELDSET und
LEGEND 279
17.11 Einem Element den Fokus zuweisen 281
17.12 Deaktivierte und schreibgesch"tzte Steuerelemente 284
17.13 Formular"bertragung 285
18 Skripte 290
18.1 Einf"hrung in Skripte 290
18.2 Dokumente f"r Benutzerprogramme erstellen, die Skripte
unterst"tzen 291
18.3 Dokumente f"r Benutzerprogramme erstellen, die Skripte
nicht unterst"tzen 299
19 SGML-Referenzinformationen f%r HTML 301
19.1 Dokumentvalidierung 302
19.2 Beispiel f"r einen SGML-Katalog 303
20 SGML-Deklaration von HTML 4 303
20.1 SGML Declaration 304
21 Documenttyp-Definition 305
22 Transitional-
Documenttyp-Definition 305
23 Frameset-Dokumenttyp-Definition 305
24 Zeichen-Entity-Referenzen in HTML 4 306
24.1 Einf"hrung in Zeichen-Entity-Referenzen 306
24.2 Zeichen-Entity-Referenzen f"r Zeichen aus ISO 8859-1 309
24.3 Zeichen-Entity-Referenzen f"r Symbole, mathe- matische
Symbole und griechische Buchstaben 313
24.4 Zeichen-Entity-Referenzen f"r markup-relevante
und internationale Zeichen 318
A ;nderungen 321
B Anmerkungen zur Performance, Implementierung und
Gestaltung 321
B.1 Anmerkungen zu ung"ltigen Dokumenten 321
B.2 Besondere Zeichen in URI-Attributwerten 323

<8> Inhaltsverzeichnis
Page size: 168,00 x 240,00 mm

B.3 Anmerkungen zur SGML-Implementierung 324


B.4 Anmerkungen zum Thema: Suchmaschinen helfen,
die eigene Website zu indexieren 327
B.5 Anmerkungen zu Tabellen 330
B.6 Anmerkungen zu Formularen 336
B.7 Anmerkungen zu Skripten 337
B.8 Anmerkungen zu Frames 338
B.9 Anmerkungen zur ZugEnglichkeit 338
B.10 Anmerkungen zur Sicherheit 339

XHTML 1.0: Die Extensible


B HyperText Markup Language
1 Was ist XHTML? 366
1.1 Was ist HTML 4? 366
1.2 Was ist XML? 367
1.3 Wozu braucht man XHTML? 367
2 Definitionen 368
2.1 Terminologie 368
2.2 Allgemeine Begriffe 369
3 Normative Definition von XHTML 1.0 370
3.1 Konforme Dokumente 370
3.2 Konforme Benutzerprogramme 373
4 Unterschiede zu HTML 4 374
4.1 Dokumente m"ssen korrekt aufgebaut sein 374
4.2 Element- und Attributnamen m"ssen in Kleinbuchstaben
dargestellt werden 375
4.3 F"r nicht leere Elemente m"ssen End-Tags angegeben
werden 375
4.4 Attributwerte m"ssen immer in Anf"hrungszeichen stehen 375
4.5 Attributminimierung 375
4.6 Leere Elemente 376
4.7 Behandlung von Leerraum in Attributwerten 376
4.8 Script- und Style-Elemente 376
4.9 SGML-Ausschl"sse 377
4.10 Die Elemente mit 'id'- und 'name'-Attributen 377
4.11 Attribute mit vordefinierten Wertemengen 377
4.12 Entity-Referenzen als hexadezimaler Wert 377
5 Kompatibilit+tsaspekte 378
5.1 Internet-Medientyp 378
A DTDs 378
A.1 Dokumenttypdefinitionen 378
A.2 Entity-Mengen 379

Inhaltsverzeichnis <9>
Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

B Element-Ausschl%sse 379
C Richtlinien zur HTML-Kompatibilit+t 380
C.1 Verarbeitungsanweisungen und die XML-Deklaration 380
C.2 Leere Elemente 380
C.3 Elementminimierung und leerer Elementinhalt 380
C.4 Eingebettete Stylesheets und Skripte 380
C.5 Zeilenumbr"che innerhalb von Attributwerten 381
C.6 Isindex 381
C.7 Die Attribute lang and xml:lang 381
C.8 Fragmentbezeichner 381
C.9 Zeichencodierung 382
C.10 Boolesche Attribute 382
C.11 Document Object Model und XHTML 382
C.12 Die Verwendung von et-Zeichen in Attributwerten (und
anderswo) 383
C.13 Cascading Style Sheets (CSS) und XHTML 383
C.14 Referenzierung von Style-Elementen bei Verwendung
als XML 384
C.15 Leerraumzeichen in HTML vs. XML 384
C.16 Die benannte Zeichenreferenz &apos; 384
D Danksagungen 385
E Literaturverzeichnis 385

Modularisierung von XHTML


C 1 Einf%hrung
1.1 Was ist XHTML?
391
391
1.2 Was ist XHTML-Modularisierung? 392
1.3 Warum XHTML modularisieren? 392
2 Begriffe und Definitionen 394
3 Definition der Konformit+t 397
3.1 KonformitEt eines Dokumenttyps als XHTML
Host Language 397
3.2 KonformitEt eines Dokumenttyps als XHTML
Integration Set 398
3.3 KonformitEt eines Moduls zur XHTML-Familie 398
3.4 KonformitEt eines Dokuments zur XHTML-Familie 399
3.5 KonformitEt eines Benutzerprogramms zur XHTML-Familie 399
3.6 Namensregeln 401
3.7 Evolution von XHTML-Modulen 402
4 Definition abstrakter Module 402
4.1 Syntaktische Konventionen 403
4.2 Inhaltstypen 404

< 10 > Inhaltsverzeichnis


Page size: 168,00 x 240,00 mm

4.3 Attributtypen 404


4.4 Ein Beispiel f"r eine Definition eines abstrakten Moduls 409
5 Abstrakte XHTML-Module 410
5.1 Sammlungen von Attributen 410
5.2 Kernmodule (Core Modules) 411
5.3 Applet-Modul (Applet Module) 414
5.4 Texterweiterungsmodule (Text Extension Modules) 414
5.5 Formularmodul (Forms Modules) 415
5.6 Tabellenmodul (Table Modules) 418
5.7 Bildmodul (Image Module) 420
5.8 Modul f"r client-seitige Image Maps
(Client-side Image Map Module) 420
5.9 Modul f"r server-seitige Image Maps
(Server-side Image Map Module) 421
5.10 Objektmodul (Object Module) 421
5.11 Frames-Modul (Frames Module) 421
5.12 Target-Modul (Target Module) 422
5.13 Iframe-Modul (Iframe Module) 422
5.14 Modul f"r eingebaute Ereignisse (Intrinsic Events Module) 423
5.15 Metainformationsmodul (Metainformation Module) 424
5.16 Scripting-Modul (Scripting Module) 424
5.17 Stylesheet-Modul (Style Sheet Module) 424
5.18 Style-Attributmodul (Style Attribute Module) 425
5.19 Link-Modul (Link Module) 425
5.20 Base-Modul (Base Module) 425
5.21 Name-Identifizierungsmodul (Name Identification Module) 425
5.22 Altlastenmodul (Legacy Module) 426
A Erstellen von Schema-Modulen 428
B Entwicklung eines Schemas mit definierten und
erweiterten Modulen 428
C Implementierungen der XHTML-Schema-Module 428
D Erstellen von DTD-Modulen 429
D.1 Benennung von Parameter-Entities 429
D.2 Definieren des Namensraums f"r ein Modul 430
E Entwickeln von DTDs mit definierten und erweiterten
Modulen 437
E.1 Definition zusEtzlicher Attribute 438
E.2 Definition zusEtzlicher Elemente 438
E.3 Definition des Inhaltsmodells f"r eine Modulsammlung 439
E.4 Erstellen einer neuen DTD 440
E.5 Benutzen der neuen DTD 450
F Implementierungen von XHTML-Modulen mit DTDs 450
F.1 XHTML-Zeichen-Entities 451
F.2 Modulares Rahmenwerk von XHTML 459

Inhaltsverzeichnis < 11 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

F.3 Implementierungen der XHTML-Module 473


F.4 Unterst"tzende Module der XHTML-DTD-Implementierung 474
G Bibliographie 491
G.1 Normative Quellen 491
G.2 Informelle Quellen 493
H Entwurfsziele 494
H.1 Anforderungen 494
I Danksagungen 496

XHTML Basic
D 1 Einleitung
1.1 XHTML f"r KleinstinformationsgerEte
500
500
1.2 Hintergrund und Voraussetzungen 500
1.3 Gr"nde f"r Entwurfsentscheidungen 501
2 Konformit+t 503
2.1 KonformitEt der Dokumente 503
2.2 KonformitEt der Benutzerschnittstelle 503
3 Der XHTML-Basic-Dokumenttyp 503
4 Wie XHTML Basic verwendet wird 504
5 Danksagung 505
A Referenzen 505
A.1 Normative Referenzen 505
A.2 Informelle Referenzen 506
B XHTML-Basic- Dokumenttyp-Definition 506
B.1 "SGML Open Catalog Entry" f"r XHTML Basic 506
B.2 XHTML Basic-Treiber 507
B.3 XHTML-Basic-Anpassungen 511

XHTML 1.1 - Modulbasiertes


E XHTML
1 Einf%hrung 518
2 Definition der Konformit+t 518
2.1 DokumentkonformitEt 518
2.2 KonformitEt eines Benutzerprogramms 519
3 Der XHTML 1.1-Dokumenttyp 519
A ;nderungen gegen%ber XHTML 1.0 Strict 521
B Bibliographie 521
B.1 Normative Quellen 521
B.2 Informelle Quellen 522

< 12 > Inhaltsverzeichnis


Page size: 168,00 x 240,00 mm

C XHTML 1.1-Dokumenttyp-Definition 522


C.1 SGML Open Catalog-Eintrag f"r XHTML 1.1 522
C.2 XHTML 1.1-Treiber 523
C.3 Anpassung f"r XHTML 1.1 529
D Danksagungen 534

Cascading Style Sheets, Level 2


F 1 Informationen zur CSS2-Spezifikation
1.1 Wie Sie die Spezifikation lesen
538
538
1.2 Der Aufbau der Spezifikation 539
1.3 Konventionen 540
1.4 Danksagungen 544
1.5 Copyright-Hinweis 545
2 Einf%hrung in CSS2 546
2.1 Ein kurzer CSS2-#berblick f"r HTML 546
2.2 Ein kurzer CSS2-#berblick f"r XML 549
2.3 Das CSS2-Verarbeitungsmodell 551
2.4 CSS-Entwurfskonzepte 553
3 Konformit+t: Anforderungen und Empfehlungen 555
3.1 Definitionen 555
3.2 KonformitEt 558
3.3 Fehlerbedingungen 560
3.4 Der text/css-Inhaltstyp 560
4 CSS2-Syntax und grundlegende Datentypen 560
4.1 Syntax 560
4.2 Regeln f"r die Verarbeitung von Parser-Fehlern 568
4.3 Werte 569
4.4 CSS-Dokumentdarstellung 578
5 Selektoren 580
5.1 Mustervergleich 580
5.2 Selektorsyntax 582
5.3 Universeller Selektor 582
5.4 Typselektoren 583
5.5 Selektoren f"r Nachfahren 583
5.6 Kind-Selektoren 584
5.7 Selektoren f"r benachbarte Elemente 584
5.8 Attribut-Selektoren 585
5.9 ID-Selektoren 589
5.10 Pseudo-Elemente und Pseudo-Klassen 590
5.11 Pseudo-Klassen 591
5.12 Pseudo-Elemente 595

Inhaltsverzeichnis < 13 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

6 Eigenschaftswerte zuweisen, Kaskaden und Vererbung 601


6.1 Spezifizierte, berechnete und tatsEchliche Werte 601
6.2 Vererbung 602
6.3 Die @import-Regel 604
6.4 Die Kaskade 605
7 Medientypen 610
7.1 Einf"hrung in Medientypen 610
7.2 Angabe medienabhEngiger Stylesheets 610
7.3 Erkannte Medientypen 611
8 Das Box-Modell 613
8.1 Maße der Boxen 613
8.2 Beispiele f"r REnder, Polsterung und Rahmen 615
8.3 Randeigenschaften: 'margin-top', 'margin-right',
'margin-bottom', 'margin-left' und 'margin' 617
8.4 Polstereigenschaften: 'padding-top', 'padding-right',
'padding-bottom', 'padding-left' und 'padding' 619
8.5 Rahmeneigenschaften (border) 621
9 Visuelles Formatierungsmodell 628
9.1 Einf"hrung in das visuelle Formatierungsmodell 628
9.2 Kontrolle "ber das Erstellen von Boxen 629
9.3 Positionierungsschemata 635
9.4 Normaler Fluss 639
9.5 Floats 642
9.6 Absolute Positionierung 647
9.7 Beziehungen zwischen 'display', 'position' und 'float' 649
9.8 Vergleich von normalem Fluss, Floats und absoluter
Positionierung 649
9.9 Ebenen (Layer) 657
9.10 Textrichtung: die Eigenschaften 'direction' und
'unicode-bidi' 658
10 Details zum visuellen Formatierungsmodell 663
10.1 Definition des „umschließenden Blocks“ 663
10.2 Inhaltsbreite: die 'width'-Eigenschaft 665
10.3 Breiten und REnder berechnen 666
10.4 Minimale und maximale Breiten: 'min-width' und
'max-width' 668
10.5 InhaltshPhe : die 'height'-Eigenschaft 670
10.6 HPhen und REnder berechnen 671
10.7 Mindest- und MaximalhPhen: 'min-height' und
'max-height' 673
10.8 ZeilenhPhenberechnungen: die Eigenschaften
'line-height' und 'vertical-align' 674
11 Visuelle Effekte 677
11.1 #berlauf und Abschneiden 677
11.2 Sichtbarkeit: die 'visibility'-Eigenschaft 682

< 14 > Inhaltsverzeichnis


Page size: 168,00 x 240,00 mm

12 Erzeugter Inhalt, automatische Nummerierung


und Listen 684
12.1 Die Pseudoelemente :before und :after 684
12.2 Die 'content'-Eigenschaft 686
12.3 Zusammenspiel von :before und :after mit den Elementen
'compact' und 'run-in' 688
12.4 Anf"hrungszeichen 689
12.5 Automatische ZEhler und Nummerierung 693
12.6 Markierungen (Marker) und Listen 697
13 Seitenmedien 708
13.1 Einf"hrung in Seitenmedien 708
13.2 Seiten-Boxen: die @page -Regel 709
13.3 Seitenumbr"che 714
13.4 Kaskade im Seitenkontext 719
14 Farben und Hintergrund 719
14.1 Vordergrundfarbe : die 'color'-Eigenschaft 720
14.2 Der Hintergrund 720
14.3 Gammakorrektur 726
15 Schriften 727
15.1 Einf"hrung 727
15.2 Schriftspezifikation 729
15.3 Schriftauswahl 745
15.4 Schriftcharakteristika 761
15.5 Algorithmus zum Schriftvergleich 767
16 Text 772
16.1 Einr"ckung: die 'text-indent'-Eigenschaft 772
16.2 Ausrichtung: die 'text-align'-Eigenschaft 773
16.3 Ausschm"ckung 774
16.4 Buchstaben- und WortabstEnde: die 'letter-spacing'- und
'word-spacing'-Eigenschaften 777
16.5 Großschreibung: die 'text-transform'-Eigenschaft 779
16.6 Leerraum: die 'white-space'-Eigenschaft 780
17 Tabellen 781
17.1 Einf"hrung in Tabellen 781
17.2 Das CSS-Tabellenmodell 787
17.3 Spaltenselektoren 789
17.4 Tabellen im visuellen Formatierungsmodell 790
17.5 Visuelles Layout von Tabelleninhalt 793
17.6 Rahmen 802
17.7 Akustische Darstellung von Tabellen 808
18 Benutzeroberfl+che 812
18.1 Cursor: die 'cursor'-Eigenschaft 812
18.2 Benutzereinstellungen f"r Farben 813
18.3 Benutzereinstellungen f"r Schriften 815

Inhaltsverzeichnis < 15 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

18.4 Dynamische Einrahmungen: die 'outline'-Eigenschaft 815


18.5 VergrPßerung 817
19 Akustische Stylesheets 817
19.1 Einf"hrung in akustische Stylesheets (Aural Stylesheets) 817
19.2 Eigenschaften f"r die LautstErke : 'volume' 818
19.3 Spracheigenschaften: 'speak' 820
19.4 Pausen-Eigenschaften: 'pause-before', 'pause-after' und 'pause'
821
19.5 Cue-Eigenschaften: 'cue-before', 'cue-after' und 'cue' 822
19.6 Misch-Eigenschaften: 'play-during' 824
19.7 REumliche Eigenschaften: 'azimuth' und 'elevation' 825
19.8 Eigenschaften zur Sprachcharakteristik: 'speech-rate',
'voice-family', 'pitch', 'pitch-range', 'stress' und 'richness' 827
19.9 Spracheigenschaften: 'speak-punctuation' und 'speak-numeral'
831
A Ein Beispiel-Stylesheet f%r HTML 4.0 832
B ;nderungen gegen%ber CSS1 834
B.1 Neue Funktionen 835
B.2 Aktualisierte Beschreibungen 835
B.3 Semantische Qnderungen gegen"ber CSS1 835
C Hinweise zur Implementierung und Performance
von Schriften 836
C.1 Glossar f"r Schriftbegriffe 836
C.2 Schriften finden 840
C.3 Bedeutung der Panose-Zahlen 840
C.4 Ableitung von Unicode-Bereichen f"r TrueType 844
C.5 Automatische Deskriptor-Erstellung 847
D Die Grammatik von CSS2 848
D.1 Grammatik 849
D.2 Lexikalischer Scanner 851
D.3 Vergleich der Tokenbildung zwischen CSS1 und CSS2 852
E Literaturhinweise 853
E.1 Normative Literaturhinweise 853
E.2 Informelle Literaturhinweise 855
F Eigenschaftsindex 857
G Deskriptor-Index 870
Index 873

< 16 > Inhaltsverzeichnis


Page size: 168,00 x 240,00 mm

<edition
   W3C.de>

< Vorwort >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Endlich ist er da. Der zweite Band der edition W3C.de. Entstanden ist diese Buchreihe als Idee,
die ich 1999 whrend der OpenNet-Veranstaltung an Klaus Birkenbihl, den Leiter des deut-
schen B"ros des World Wide Web Consortium (W3C) herangetragen habe. Unser gemein-
sames Ziel ist es seitdem, die technischen Spezifikationen des W3C in deutscher Sprache
herauszugeben. Die als Empfehlung (Recommendation) ver0ffentlichten Texte haben lngst den
Charakter einer Norm. Sie sind lngst zur wesentlichen technischen Grundlage des World
Wide Web geworden – um so wichtiger, dass diese Texte in deutscher Sprache zur Verf"gung
stehen. Zweifellos ist das World Wide Web Consortium die maßgebliche Organisation f"r die
technische Weiterentwicklung des WWW.
Die edition W3C.de liefert Referenzinformation auf hohem Niveau. Im Zentrum stehen die maß-
geblichen, in der Regel englischsprachigen Originaltexte, ins Deutsche "bertragen und fachlich
kommentiert von Experten aus dem deutschsprachigen Raum. Und noch etwas gilt f"r dieses
Buch wie f"r das erste: Die 7bersetzungen wurden vom W3C gepr"ft. Daf"r geht schon an
dieser Stelle der Dank an Klaus Birkenbihl (Deutsch-8sterreisches W3C-B"ro) und an Ivan
Herrmann (W3C).
Es k0nnte Einwnde geben, dass doch Englisch gerade im IT-Bereich als Fachsprache etabliert
sei. Diese unbestrittene Tatsache ndert jedoch nichts daran, dass viele der W3C-Empfehlun-
gen und andere Spezifikationen schwer verstndlich, weil sehr formal geschrieben sind. Eine
7bersetzung ins Deutsche unter Beibehaltung der formalen Exaktheit bietet dem Leser einen
leichteren Zugang zu den einzigen verbindlichen Texten, die es in diesem Bereich gibt.
»Sind die B"cher der edition W3C.de also Leseb"cher f"r jedermann?« – Nein, sicher nicht. Die
edition W3C.de besteht nicht aus Einsteigerb"chern. Die Texte halten sich inhaltlich an das eng-
lische Original. Sie sind technisch exakt, przise und zum Teil formal. Der Leser der edition
W3C.de ist Profi; oder auf dem Weg dorthin. Der Leser ist Software- Entwickler, der W3C-kon-
forme Applikationen entwickelt. Er f"hrt Datenmodellierungen durch, die sich an die relevanten
Standards halten, um sich reibungslos in eine heteroge IT-Landschaft zu f"gen. Er formuliert
Dokumentstrukuren, die ihre Inhalte hersteller- und medienneutral beschreiben. Er generiert
Webseiten, die durch Befolgen der Recommendations eine maximale Reichweite erzielen.
7ber die 7bersetzung hinaus war es von Anfang an unser Ziel, dem Leser noch mehr zu bieten.
Mit der Absicht, die Verstndlichkeit der technischen Texte zu erh0hen, haben wir deshalb
Experten gesucht, die nicht nur "bersetzen, sondern auch fachlich kommentieren. Die Kom-
mentare der Fachleute sollen Ihnen helfen, auch die schwierigen Passagen der Spezifikationen
zu verstehen – und die einfachen Passagen bequemer. Dies geschieht in Form von anderen
Umschreibungen des Sachverhalts oder durch zustzliche Beispiele. Das Maß an Kommentie-
rungen variiert von Text zu Text, abhngig vom Schwierigkeitsgrad des Originals. Zusammen
mit den Experten, die die Kommentierung angefertigt haben, hoffe ich, dass wir das richtige
Maß gefunden haben.
F"r diesen Band der edition W3C.de haben die folgenden Personen Beitrge geliefert:

Christine K
hnel
Christine K"hnel ist schon bald nach ihrem Mathematikstudium der Informatik verfallen.
Nach mehrjhriger Programmiererfahrung hat sie Mitte der Neunzigerjahre das Netz f"r
sich entdeckt und besitzt heute ausgewiesenes Know-How "ber Web-Techniken, auch
"ber W3C-Themen hinaus.

< 18 > Vorwort


Page size: 168,00 x 240,00 mm

Neben freiberuflichen Ttigkeiten im Bereich Web-Design hat sie vor allem den Ruf als eine
der namhaftesten deutschen JavaScript- Expertinnen erworben. Die FAQ zur deutschspra-
chigen JavaScript- Newsgruppe wird von ihr herausgegeben.
Christine K"hnel schreibt Fachartikel f"r die iX. Als Co- Herausgeberin hat sie 2000 ihre
erste Monographie, den „JavaScript-Workshop“, bei Addison-Wesley ver0ffentlicht.
Stefan Mintert
Stefan Mintert begann parallel zu seinem Informatik-Studium in Dortmund bereits 1993 als
Web-Admin am Informatik- Fachbereich zu arbeiten. Seit 1994 ergnzt er seine WWW-
Erfahrung mit SGML-Know-how. Als stndiger freier Mitarbeiter der im Heise-Verlag
erscheinenden iX schreibt er regelmßig Fachartikel. Des Weiteren hat er bereits mehrere
Buchtitel ver0ffentlicht. 1998 erschien von Stefan Mintert als Co-Autor das erste deutsch-
sprachige Buch zum Thema XML. Die erste deutsche Fassung einer W3C-Recommendation
war seine 7bersetzung von XML.
Den Verlag Addison-Wesley hat er auch schon bei der 7bersetzung der W3C-B"cher von
Dave Ragget et. al. („Raggett on HTML 4“) und von HNkon Lie & Bert Bos („Cascading Style
Sheets“) fachlich beraten.
Er lebt heute in Hamburg und arbeitet seit 1998 als freier Berater, unter anderem in den
Bereichen Cross Media Publishing und Content Management. Dar"ber hinaus publiziert er
weiter und ist hufiger Referent auf Fachtagungen und Kongressen.
Judith Muhr
Judith Muhr arbeitet freiberuflich als 7bersetzerin.
Stefan Schumacher
Stefan Schumacher entdeckte die Seiten des World Wide Web Consortiums 1996 als Stu-
dent und erkannte die Spezifikationen als wertvolle Informationsquelle. Das Interesse an
der englischen Sprache und die Herausforderung, die Spezifikationen vollkommen zu ver-
stehen, weckten sein Interesse, wichtige Dokumente ins Deutsche zu "bersetzen. Er ist
selbststndiger Berater in den Bereichen Internet, Netzwerk und Kommunikation.

7ber die Website www.edition-w3c.de finden Sie die Kurzvita jedes Mitarbeiters, zum Teil
ergnzt um Links, auf die wir in der gedruckten Fassung verzichtet haben.

Herstellung des Buches, typografische Konventionen und


weitere Formalien
Da die Spezifikationen, die in diesem Band als kommentierte 7bersetzung enthalten sind, im
Original im (X)HTML-Format vorliegen, ist fr"h die Entscheidung gefallen, auf diesem Format
aufzusetzen. Aus organisatorischen Gr"nden konnten nicht alle Mitarbeiter direkt in HTML
arbeiten. Da andererseits nicht alle modernen Software-Produkte einen reibungslosen Export
in (X)HTML anbieten, mussten wir Alternativen suchen. So haben wir zwei Texte, deren 7ber-
setzungen in Word erfasst wurden, nach RTF exportiert und dann mit der Software upCast
nach XML konvertiert und von dort mittels XSLT in (X)HTML transformiert. F"r die freundli-
che Bereitstellung von upCast gilt unser Dank der Firma infinity loop.

Buchherstellung, typografische Konventionen, Formalien < 19 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Die W3C-Texte sind vor allem f"r die Darstellung im Web ausgezeichnet. Wir haben versucht,
diese Auszeichnungen so gut wie m0glich f"r den Druck zu verwenden. Folgende Textbau-
steine werden Ihnen in diesem Buch hufig begegnen:

Anmerkung der !bersetzer: Kommentare, die nicht im Originaltext enthalten


sind, sondern f"r die 7bersetzung hinzugef"gt wurden, sind entsprechend kenntlich
gemacht. Bitte beachten Sie, dass diese Abschnitte nicht durch das W3C verabschiedet
sind. Sie geh0ren nicht zum Originaltext.

Anmerkung: Nicht nur die bersetzer haben kommentiert. Auch das W3C hat in seinen Texten
Anmerkungen. Sie sehen so aus, wie dieser Absatz. n
Im gesamten Buch finden Sie zahlreiche Beispiele. Dazu geh0ren auch Listings mit Code-Bei-
spielen.

Code-Beispiele gibt es viele. Neben einer besonderen


Darstellung, zeichnen sie
sich auch dadurch aus,
dass Zeilenumbrche erhalten bleiben.

Neben diesen Elementen auf Blockebene finden sich verschiedenartige Auszeichnungen in den
Bl0cken. Zu den wichtigsten zhlen die Elemente und Attribute von (X)HTML. Des Weiteren
enthlt jeder Text dieser Sammlung einige eigene Auszeichnungen, die (hoffentlich) selbsterkl-
rend sind.

Danksagung
F"r die inhaltliche Pr"fung der 7bersetzungen danke ich Ivan Hermann (W3C) und Klaus Bir-
kenbihl (W3C.de). Stefan Hermann (infinity loop) hat durch die Bereitstellung seines Produkts
upCast zum Gelingen dieses Bandes beigetragen.
Ohne das Engagement von Stefan Schumacher und Christine K"hnel htte es keine 7berset-
zung von HTML 4 gegeben. Des Weiteren sind Christine K"hnel die meisten der Kommentare
in HTML 4 zu danken.
Last but not least: Mein besonderer Dank an Sylvia Hasselbach, unsere Lektorin von Addison-
Wesley. Dass sie das Projekt trotz allen Qrgers durchgezogen und das Buch gegen alle Wider-
stnde und Bedenken verteidigt hat, danke ich ihr pers0nlich sehr.
Abschließend bleibt mir der Wunsch zu ußern, dass sich unsere Arbeit lohnt und wir richtig
liegen mit der 7berzeugung, dass dieses Buch, so wie das erste der Reihe und die (hoffentlich)
nachfolgenden gebraucht werden; dass die edition W3C.de in deutscher Sprache das Referenz-
werk wird, das auf keinem Schreibtisch fehlen darf. 7bersetzer, Verlag, W3C und der Heraus-
geber glauben daran...
Stefan Mintert
Hamburg im April 2002

< 20 > Vorwort


Page size: 168,00 x 240,00 mm

<edition
   W3C.de>

< Einleitung >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Thematische Einf
hrung und !berblick
ber den Band
Der vorliegende Band widmet sich dem wichtigsten Thema des World Wide Web. Es geht um
die technischen Standards f"r die Ausgabe und Darstellung von Texten und Daten im WWW.
Die zentrale Sprache, die Lingua Franca des Web ist die Hypertext Markup Language (HTML).
Ohne HTML, in alle ihren Versionen und neuen Fassungen, gbe es kein WWW.
HTML geh0rt mittlerweile schon fast zur Allgemeinbildung. Doch das, was von Autoren HTML
genannt wird, ist oft alles andere als sauber geschrieben. Moderne Web-Browser sind gndig
bei Regelverst0ßen im Source-Code der Dokumente. Es geh0rte zum guten Ton, Web-Seiten
mit verschiedenen Browsern zu testen. Doch damit kann keine wirkliche Gewhr "bernommen
werden, dass Texte "berall und von jedermann zu lesen sind. Zu verschieden sind die Benut-
zerprogramme und Ausgabeformen im Internet – von graphischen Browsern, "ber Suchmaschi-
nen bis zu akustischer Ausgabe. Nach und nach setzt sich bei immer mehr Menschen die Ein-
sicht durch, die schon seit langem die 7berzeugung vieler Experten ist: Der beste Weg, um
m0glichst viele Menschen m0glichst gut im Web zu erreichen, besteht darin, akzeptierte Web-
Standards zu schaffen, zu verbreiten und selbst zu praktizieren. Aus diesem Grund ist die
Kenntnis der vorliegenden W3C- Spezifikationen f"r jeden unerlsslich, der als Autor, Designer
oder Anwendungsentwickler ttig ist.
HTML steht schon lngst nicht mehr allein da. Die Nachfolgerin und aktuelle Fassung trgt den
Namen Extensible Hypertext Markup Language (XHTML). Whrend die Erstere mit Hilfe von
SGML (Standard Generalized Markup Language) definiert wurde, ist die j"ngere Schwester eine
Anwendung von XML (Extensible Markup Language). Der Zusammenhang der Sprachen ist in
der folgenden Abbildung dargestellt.

formatiert
DSSSL

& transformiert

SGML HTML
Metasprachen

beeinflusst
definiert formatiert CSS

XML XHTML

formatiert
XSL
& transformiert XSLT
Auszeichnungssprachen
Formatierungs- und
Transformationssprachen

Der Zusammenhang zwischen XML, SGML, XHTML, HTML, CSS, DSSSL, XSL, XSLT (Quelle: [BeMi2000])

< 22 > Einleitung


Page size: 168,00 x 240,00 mm

Die W3C-Spezifikationen in diesem Band

Die W3C-Spezifikationen in diesem Band sind innerhalb des World Wide Web Consortiums in
der »Document Formats Domain« angesiedelt. Zu anderen Arbeitsbereichen des W3C zhlen
etwa die »Architecture Domain« und die Domain »Technology and Society«. In diesen Namen
zeigt sich schon, wo XHTML, CSS & Co angesiedelt sind. Es geht darum, Dokumente darzustel-
len und zu formatieren.
F"r die strukturierte Darstellung von Web-Seiten dienen HTML und XHTML. Die wichtigste
Spezifikation ist nach wie vor HTML 4.01. HTML 4.01 definiert die Menge der Elementtypen
(wie p, h1, a, table und so weiter), die f"r Web-Seiten verwendet werden k0nnen. Hierbei ist
wichtig, dass HTML 4.01 auch die Semantik der Elementtypen definiert. Erst dann ist klar, dass
h1 eine 7berschrift erster Ordnung und p ein Absatz ist. Das Web ist nun mehr als zehn Jahre
alt und immerhin schon Mitte der Neunzigerjahre begann es seinen Siegeszug um die Welt.
Und doch gab es niemals zuvor eine HTML-Spezifikation in deutscher Sprache. Das heißt, alles
was Sie bisher in deutscher Sprache "ber HTML gelesen haben, war Sekundrliteratur. Erst mit
diesem Band liegt eine 7bersetzung der Primrliteratur zum Web-Design in Deutsch vor –
zudem fachlich kommentiert.
XHTML 1.0 (zweite Auflage) ist die zweite Recommendation im Buch. Es handelt sich dabei um
die Neuformulierung von HTML 4 mit den Vokabeln von XML. XHTML 1.0 erklrt nicht die
Semantik der Elementtypen, sondern verweist auf HTML 4. Sie m"ssen deshalb auch heute
noch die HTML 4-Recommendation kennen. Trotzdem ist es sinnvoll neue Dokumente in
XHTML und nicht mehr in HTML herauszugeben, denn die Weiterentwicklung geht in diese
Richtung.
Whrend HTML 4 und XHTML 1.0 noch recht monolithisch sind, werden neuere Versionen
modular aufgebaut. Viele Gerte brauchen nicht den vollen Sprachumfang von HTML oder k0n-
nen ihn nicht unterst"tzen. Einige Gertehersteller wollen Teile von HTML unterst"tzen, aber
auch eigene Teile zuf"gen. Dies k0nnen zum Beispiel zuk"nftige Mobiltelefone, PDAs oder
e-Books sein. Der Schl"ssel dazu ist die Modularisierung von XHTML, die Sie als dritten Text in
diesem Buch finden.
Bei XHTML 1.1 handelt es sich um eine auf Modulen aufbauende Version. XHTML Basic ist eine
Untermenge von XHTML, die besonders f"r mobile Gerte entworfen wurde.
Die Formatierung von (X)HTML im weiteren Sinne, von der Bildschirmdarstellung bis zur
Sprachausgabe ist die Domne der Cascading Style Sheets, deren »Level 2« Sie zum Abschluss
des Bandes finden.
Die folgende Tabelle zeigt den Zeitplan aus der „HTML Working Group Roadmap“ vom
7. Februar 2003. Die Daten sind tatschliche (zur"ckliegende) oder voraussichtlichte (zuk"nfti-
ge) Daten, die angeben wann ein Dokument den jeweiligen Status erreicht hat. Die Abk"rzun-
gen stehen f"r Candidate Recommendation (CR), Proposed Recommendation (PR), Recom-
mendation (REC). Nur der letzte Status ist ein stabiler Zustand. Alle genannten W3C-Doku-
mente, die eine Recommendation sind, finden Sie in kommentierter Fassung in diesem Buch.

Thematische Einfhrung und berblick ber den Band < 23 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

1. 2. Letzter endet CR PR REC 2.


Entwurf Entwurf Aufruf Auflage
HTML 4.01 - - - - - 24 Aug 24 -
1999 Dec
1999
XHTML 1.0 5 Dec 24 Feb 5 May 1 Jun - 10 Dec 26 Jan 1 Aug
1998 1999 1999 1999 1999 2000 2002
Modulariza- 6 Apr 10 Sep 5 Jan 1 Feb 20 23 Feb 10 TBD
tion 1999 1999 2000 2000 Oct 2001 Apr
2000 2001
XHTML 1.1 10 Sep - 5 Jan 1 Feb - 6 Apr 31 TBD
1999 2000 2000 2001 May
2001
XHTML 21 Dec - 10 Feb 15 - 3 Nov 19 TBD
Basic 1999 2000 Mar 2000 Dec
2000 2000
Media Type 18 Dec 8 Feb 27 Sep 26 - - 6 Feb -
2000 2001 2001 Oct 2002
2001
XML Events 21 Dec 28 Aug 26 Oct 30 7 Feb Apr TBD -
1999 2000 2001 Nov 2003 2003
2001
Modulariza- 22 Mar 19 Dec 9 Dec 31 Jan Mar Sep TBD -
tion of 2001 2001 2002 2003 2003 2003
XHTML in
XML
Schema
XHTML + 30 Apr 9 Aug Mar TBD Sep Mar TBD -
MathML + 2002 2002 2003 2003 2004
SVG
XFrames 6 Aug - Jan Feb TBD TBD TBD -
2002 2003 2003
XHTML 2.0 5 Aug 11 Dec Jul 2003 TBD Oct Jul TBD -
2002 2002 2003 2004
Modulariza- TBD TBD TBD TBD TBD TBD TBD -
tion 2.0
XML Sche- 3 Sep TBD TBD TBD TBD TBD TBD -
mas for 2002
XHTML 1.0

< 24 > Einleitung


Page size: 168,00 x 240,00 mm

1. 2. Letzter endet CR PR REC 2.


Entwurf Entwurf Aufruf Auflage
XML Sche- Mar TBD TBD TBD TBD TBD TBD -
mas for 2003
XHTML 1.1
and Basic
HLink 13 Sep TBD TBD TBD TBD TBD TBD -
2002
XHTML + Jan Mar Jun TBD Oct Apr TBD -
SMIL 2003 2003 2003 2003 2004

Weitere W3C-Spezifikationen und -Texte

Neben den Spezifikationen, die in diesem Band enthalten sind, gibt es zahlreiche weitere, die
mehr oder weniger eng verwandt sind. Einige dieser Spezifikationen sind zum Zeitpunkt der
Drucklegung noch nicht fertig, whrend alle in diesem Band enthaltenen Texte verabschiedete
Recommendations sind, die eine Reihe von Pr"fungen hinter sich haben.
Wer sich f"r die technische Grundlage von XHTML interessiert, findet in der XML-Spezifika-
tion alle Informationen – auf www.edition-w3c.de sogar in deutscher Sprache. Im Rahmen der
Buchreihe ist bereits ein Band zu diesem Thema erschienen.
Im engeren Umfeld von XHTML sind einige Recommendations am Horizont zu erkennen: XFra-
mes wird die Neuformulierung der HTML-Frames sein, die allerdings nicht die gleichen Nach-
teile haben sollen. Qhnlich verhlt es sich mit XForms, einer XML- Sprache f"r Formulare. HLink
wird es gestatten, beliebigen Elementen Hyperlink-Fhigkeiten zu geben. Weitere in Arbeit
befindliche Spezifikationen beschftigen sich mit der Erstellung von Schemata anstelle von
DTDs f"r XHTML. Des weiteren gibt es einige Arbeiten, die XHTML-Profile f"r kombinierte
Anwendungen definieren. Dazu geh0rt zum Beispiel XHTML+MathML+SMIL.
Die nchste große Version von XHTML wird die Version 2.0 sein. Der gegenwrtige Zeitplan
unter www.w3.org/MarkUp/xhtml-roadmap/ nennt als Ver0ffentlichungszeitpunkt f"r die Pro-
posed Recommendation den Juli 2004. Einen Termin f"r die Recommendation gibt es noch
nicht, aber es darf angenommen werden, dass XHTML 2.0 nicht vor Ende 2004 verabschiedet
wird.

Internet Society und Internet Engineering Task Force

Auch wenn es vielen Menschen so vorkommt: Das Web ist nicht das Internet, vielmehr setzt
es auf der Infrastrukur des Internet auf. Die Internet Society (ISOC) k"mmert sich um die offene
Weiterentwicklung des Internet. Eine wichtige Rolle nimmt die mit ihr assoziierte Internet Engi-
neering Task Force (IETF) ein. Die wichtigsten Ver0ffentlichungen der IETF sind die Requests for
Comments (RFC), die zum Beispiel die Standards f"r alle Internet-Protokolle beschreiben. Die
offiziellen Websites sind: http://www.isoc.org/, http://www.ietf.org/, http://www.rfc-editor.org/

Thematische Einfhrung und berblick ber den Band < 25 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

F"r das Web sind wichtige RFCs unter anderen: HTTP/1.1 (RFC 2616) und HTTP Authentica-
tion (RFC 2617). Jenseits des Hypertext Transfer Protocol (HTTP) endet die Zustndigkeit der
IETF und es beginnt die Zustndigkeit des W3C. HTTP ist sozusagen die Schnittstelle zwischen
beiden Organisationen. Informationen "ber HTTP gibt es beim W3C unter http://www.w3.org/
Protocols/.

HTTP und MIME

Neben der Integration bestehender Protokolle war in der Geburtsstunde des Web auch ein
neues Protokoll geboren, das (besser als bestehende 7bertragungsverfahren) auf die Bed"rf-
nisse von Hypertextsystemen zugeschnitten sein sollte. Getauft hat Berners-Lee seine Entwick-
lung auf den Namen Hypertext Transfer Protocol (HTTP). In der Version 1.1 kennt HTTP die
Befehle GET, POST, HEAD, PUT, DELETE, TRACE und OPTIONS. Die wichtigsten davon
sind:

GET
zur Anforderung eines Dokumentes von einem Server
POST
zur 7bertragung von Daten, die etwa Formulareingaben des Benutzer darstellen
HEAD
zur Abfrage von HTTP-Header-Informationen, ohne ein Dokument vollstndig laden zu
m"ssen
PUT
als Gegenst"ck zu GET zum 7bertragen eines Dokumentes zu einem Server

Die fr"h geforderte Multimedialitt des World Wide Web macht es notwendig, dass verschie-
denartige Inhalte von Dokumenten (Text, Graphik, Video, Audio usw.) mit einer Kennzeich-
nung versehen werden, damit der Empfnger (der Client) weiß, wie er die erhaltenen Daten
verarbeiten muss und ob er es "berhaupt kann. Diese Kennzeichnung folgt im Web der MIME-
Konvention. Urspr"nglich als Multipurpose Internet Mail Extensions f"r den Mailverkehr ent-
wickelt, wird MIME nun auch als Multimedia Internet Message Extensions f"r weitere Dienste,
darunter das World Wide Web, eingesetzt. An einem Beispiel ist die Verfahrensweise leicht
ersichtlich. Das HTTP ist aufgrund seiner textuellen Natur auch f"r Menschen lesbar. Folgende
Zeilen zeigen eine Telnet-Verbindung zu einem Web-Server.

> telnet www.w3.org 80

Trying 18.23.0.22...
Connected to www.w3.org.
Escape character is '^]'.
HEAD /pub/WWW/Addressing/ HTTP/1.0

HTTP/1.0 200 Document follows


Server: CERN/3.0A
Date: Thu, 17 Apr 1997 11:16:47 GMT

< 26 > Einleitung


Page size: 168,00 x 240,00 mm

Content-Type: text/html
Content-Length: 12094
Last-Modified: Wed, 16 Apr 1997 21:44:29 GMT

Die hervorgehobenen Zeilen zeigen den Verbindungsaufbau (telnet), die HTTP-Anfrage


(HEAD), den Antwortcode des Servers (200 Document follows) sowie den MIME-Typ des
angefragten Dokumentes (text/html).
Falls im Web sensible Daten (etwa personenbezogene Daten, Kontodaten und so weiter) "ber-
tragen werden, dann ist nat"rlich eine hohe Sicherheit gegen unbefugtes Mith0ren gew"nscht.
Ein gngiger Ansatz besteht im Einsatz von TLS. TLS steht f"r Transport Layer Security. Im
Zusammenhang mit HTTP kann TLS in zwei Arten eingesetzt werden:

HTTP
ber TLS
In diesem Fall wird eine TLS-Verbindung hergestellt, "ber die dann HTTP „gesprochen“
wird. Eigenschaften dieser Vorgehensweise sind URIs, die mit https beginnen und Verbin-
dungen "ber den Port 443. Die Spezifikation ist in RFC 2818 zu finden.
TLS mit HTTP/1.1
In diesem Fall wird TLS "ber eine bestehende TCP-Verbindung abgewickelt. Dadurch lassen
sich gesicherte und ungesicherte HTTP-Nachrichten "ber denselben Port (80) schicken.
Details sind in RFC 2817 zu finden.

MIME-Typen f
r XHTML

Was unter einem MIME-Typ zu verstehen ist und wie er in HTTP benutzt wird, wurde soeben
schon erklrt. Bleibt die Frage, welcher MIME-Typ wof"r verwenden werden soll.Als es nur
HTML gab, war die Angelegenheit relativ einfach, mittlerweile ist es kompliziert. Neben HTML
(text/html) gibt es XML (text/xml). Was ist mit XHTML? Einerseits handelt es sich um HTML,
andererseits XML. Außerdem gibt es XHTML in mehreren Geschmacksrichtungen. Dar"ber
hinaus kann man noch MathML oder SVG in XHTML einbetten. Das Problem ist nicht ganz trivial.
F"r einige wichtige Flle enthlt die W3C-Note „XHTML Media Types“ (http://www.w3.org/TR/
xhtml-media-types) L0sungsvorschlge. Der Text unterscheidet zwischen voneinander abwei-
chenden XHTML-Versionen, XHTML mit eingebettetem MathML und HTML.
text/html ist im Allgemeinen nicht f"r XHTML geeignet, sondern nur f"r HTML. Er darf jedoch
verwendet werden, wenn ltere Browser XHTML darstellen sollen. In diesem Fall halten sich
die XHTML-Dokumente an die HTML-Kompatibilittsrichtlinien aus der XHTML 1-Spezifikati-
on. Dazu geh0rt, dass ein leeres Element wie <br/> (korrekte XHTML-Schreibweise) nun als
<br /> geschrieben wird. Das Leerzeichen vor dem Schrgstrich sorgt daf"r, dass alte Browser
das als br erkennen. Aber auch in diesem Fall sollte man text/html nur f"r XHTML 1 verwen-
den. Der Einsatz mit kombinierten Sprachen, wie XHTML+MathML ist nicht zulssig.
Außerdem ist unbedingt anzuraten, eine explizite Angabe "ber die Zeichenkodierung zu
machen. Fehlt eine solche Angabe, k0nnte man annehmen, das UTF-8 oder UTF-16 f"r XHTML
erlaubt sind, da es sich ja um Defaults f"r XML handelt. Bei Verwendung von text/html weist
die zugeh0rige Spezifikation („The 'text/html' Media Type“, RFC 2854) darauf hin, dass durch
RFC 2046 (MIME) als Default-Kodierung US-ASCII anzunehmen ist. Diesen Widerspruch kann

Thematische Einfhrung und berblick ber den Band < 27 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

man verlsslich durch Angabe der Zeichenkodierung in der XML-Deklaration (<?xml version=:
"1.0:" encoding=:"ISO-8859-1:"?>) und im meta-Element (<meta http-equiv="Content-Type" con-
tent="text/html; charset=ISO-8859-1" />) vermeiden.
Prinzipiell sollte man f"r XHTML-Dokumente den MIME-Typ application/xhtml+xml benutzen,
allerdings um den Preis, dass der Großteil der Browser heute damit nichts anfangen kann.
Selbstverstndlich kann auch application/xml f"r XHTML verwendet werden, schließlich sind
XHTML-Dokumente g"ltige XML-Instanzen. Mit diesem MIME-Typ verliert man jedoch die
Behandlung des Dokuments als XHTML-Dokument. Durch Einsatz von Stylesheets (etwa CSS)
lsst sich auf der gestalterischen Seite einiges ausgleichen, aber die Ber"cksichtigung der beson-
deren Semantik einiger Elemente (beispielsweise Links, Formulare und so weiter) ist verloren.
Fehlt bei der Verwendung von application/xml auf MIME-Ebene die Angabe der Zeichenkodie-
rung, muss das empfangende Programm anhand der durch XML 1.0 definierten Regeln die
Kodierung bestimmen. Im Gegensatz dazu gilt f"r text/xml dasselbe wie f"r text/html: Fehlt die
Kodierungsangabe auf MIME-Ebene, geben die „XML Media Types“ (RFC3023) US-ASCII vor.
Die Problematik wird in der W3C-Note in folgender Tabelle zusammengefasst. Ber"cksichtigt
man die aktuelle Browser-Situation, bedeutet das f"r den Einsatz von XHTML: beschrnken auf
XHTML 1, beachten der HTML-Kompatibilittsrichtlinien, deklarieren als text/html sowie voll-
stndige Angabe der Zeichenkodierung (XML-Deklaration und meta).

Medientyp HTML 4 XHTML 1.0 XHTML 1.0 XHTML XHTML+


(HTML- (anderes) Basic / 1.1 MathML
kompatibel)
text/html sollte darf sollte nicht sollte nicht sollte nicht
application/ darf nicht sollte sollte sollte sollte
xhtml+xml
application/xml darf nicht darf darf darf darf
text/xml darf nicht darf darf darf darf

Es ist momentan nicht leicht, einerseits standardkonform zu bleiben und andererseits mit den
aktuellen Browsern kompatibel. Da die Entwicklung der Browser schnell voranschreitet, ver-
weisen wir an dieser Stelle auf eine Online-Quelle: Unter http://www.w3.org/People/mimasa/
test/xhtml/media-types/ finden Sie einen Test, der feststellt, welcher Browser welchen MIME-
Typ akzeptiert. Selbstverstndlich sind die Ergebnisse f"r bereits getestete Browser dort ver-
0ffentlicht.

Uniform Resource Identifier (URI)

Jedes HTML-Dokument, oder allgemeiner jedes Objekt, das im Netz erreichbar ist, soll "ber
eine eindeutigen Bezeichner adressierbar sein. Die Objekte nennt man auch Ressource. Der
Bezeichner heißt Uniform Resource Identifier (URI). Dessen Syntax wird in RFC 2396 fest-
gelegt.
Beispiele sieht man bei der tglichen Arbeit mit dem World Wide Web stndig, dennoch sei
eines genannt: http://www.edition-w3c.de/presse.html. Bei der Ressource, die damit adressiert
wird, handelt es sich um ein HTML-Dokument. Nebenbei sei bemerkt, dass dort Pressebe-

< 28 > Einleitung


Page size: 168,00 x 240,00 mm

richte "ber unsere Buchreihe zu finden sind. Ein URI besteht aus mehreren Teilen. Der erste
Teil (hier: http) wird „Schema“ (engl.: Scheme) genannt. Im obigen Beispiel gibt das Schema an,
wie das Dokument zu erreichen ist, nmlich per HTTP. Es handelt sich bei diesem URI deshalb
um einen Spezialfall, den Uniform Resource Locator (URL). Auch wenn dieser Begriff mittler-
weile als veraltet gilt, RFC 2396 beschreibt ihn so: „Der Ausdruck Uniform Resource Locator
(URL) bezeichnet die Vertreter der URIs, die Ressourcen durch Nennung ihres primren
Zugriffsmechanismus' (z. B. ihren Aufenthaltsort im Netzwerk) beschreiben, anstatt sie durch
ihren Namen oder andere Eigenschaften zu identifizieren. Der Ausdruck Uniform Resource
Name (URN) bezeichnet die Vertreter der URIs, von denen verlangt wird, dass sie global ein-
deutig und bestndig bleiben, selbst wenn die Ressource nicht mehr existiert oder nicht mehr
erreichbar ist.“
Beim Schreiben von HTML-Texten d"rften URIs mit dem http-Schema am hufigsten Anwen-
dung finden. Dennoch sind andere Schemata wichtig. Eine offizielle Liste der URI-Schemata ist
bei der Internet Assignet Names Authority (IANA) zu finden: http://www.iana.org/assignments/
uri-schemes. Mit Stand vom 11. Mrz 2003 sind folgende Namen bei der IANA reserviert:

Name des Beschreibung Referenz


Schemas
ftp File Transfer Protocol [RFC1738]
http Hypertext Transfer Protocol [RFC2616]
gopher The Gopher Protocol [RFC1738]
mailto Electronic mail address [RFC2368]
news USENET news [RFC1738]
nntp USENET news using NNTP access [RFC1738]
telnet Reference to interactive sessions [RFC1738]
wais Wide Area Information Servers [RFC1738]
file Host-specific file names [RFC1738]
prospero Prospero Directory Service [RFC1738]
z39.50s Z39.50 Session [RFC2056]
z39.50r Z39.50 Retrieval [RFC2056]
cid content identifier [RFC2392]
mid message identifier [RFC2392]
vemmi versatile multimedia interface [RFC2122]
service service location [RFC2609]
imap internet message access protocol [RFC2192]
nfs network file system protocol [RFC2224]
acap application configuration access protocol [RFC2244]
rtsp real time streaming protocol [RFC2326]
tip Transaction Internet Protocol [RFC2371]
pop Post Office Protocol v3 [RFC2384]

Thematische Einfhrung und berblick ber den Band < 29 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Name des Beschreibung Referenz


Schemas
data data [RFC2397]
dav dav [RFC2518]
opaquelocktoken opaquelocktoken [RFC2518]
sip session initiation protocol [RFC2543]
tel telephone [RFC2806]
fax fax [RFC2806]
modem modem [RFC2806]
ldap Lightweight Directory Access Protocol [RFC2255]
https Hypertext Transfer Protocol Secure [RFC2818]
soap.beep soap.beep [RFC3288]
soap.beeps soap.beeps [RFC3288]
xmlrpc.beep xmlrpc.beep [RFC-harold-beep-
xmlrpc-03.txt]
xmlrpc.beeps xmlrpc.beeps [RFC-harold-beep-
xmlrpc-03.txt]
urn Uniform Resource Names (siehe http://www. [RFC2141]
iana.org/assignments/urn-namespaces)
go go [RFC3368]
h323 H.323 [RFC-levin-iptel-
h323-url-scheme-
05.txt]

Die bekannten Namen wie http, ftp oder mailto bed"rfen keiner weiteren Beispiele. Interes-
sant, insbesondere f"r den Aufbau von Firmen-Websites d"rften die Namen tel und fax sein.
Das folgende Beispiel illustriert eine m0gliche Verwendung auf dem Website von Addison-
Wesley:

<p>Sie erreichen uns telefonisch unter


<a href="tel:+4989460030">089 / 4 60 03-0</a>.
Wenn Sie uns ein Fax schicken mEchten, senden Sie
es bitte an <a href="fax:+498946003100">089 / 4 60 03-100</a>.</p>

Auf den ersten Blick mag es wenig Sinn machen, Telefon- und Faxnummern als URI anzugeben.
Doch lngst ist es "blich Faxe per Computer zu verschicken und auch Software zur IP-Telefo-
nie ist keine Science-Fiction. Je nach Ausstattung seines Computers kann ein Benutzer obige
Links anklicken und es startet seine Fax- respektive Telefon-Software. Letztere beginnt m0gli-
cherweise gleich den Whlvorgang.

< 30 > Einleitung


Page size: 168,00 x 240,00 mm

International Organization for Standardization

Das W3C versteht sich selbst nicht als Normierungsorganisation. Derer gibt es aus deutsch-
sprachiger Sicht vier: eine internationale und je eine nationale in Deutschland, 8sterreich und
der Schweiz.
Die Internationale Organisation f>r Normierung (ISO), mit Sitz in Genf, ist nat"rlich ebenfalls im
Web vertreten: http://www.iso.ch/. Deutsches Mitglied der ISO ist das Deutsche Institut f>r Nor-
mung e.V. (DIN, http://www.din.de/). Die 0sterreichische Vertretung ist das @sterreichische Nor-
mungsinstitut (ON, http://www.on-norm.at/) und die Schweiz wird durch die Schweizerische Nor-
men-Vereinigung (SNV, http://www.snv.ch/) vertreten. Im technischen Bereich muss neben der
ISO unbedingt die 40 Jahre fr"her gegr"ndete International Electrotechnical Commission (IEC,
http://www.iec.ch/) erwhnt werden. Aufgrund der Zusammenarbeit tragen viele Normen das
Prfix ISO/IEC.

SGML (ISO 8879)


Informationen "ber SGML, dem Vorfahren von XML, sind auf den XML Cover Pages sowie
in [Goldfarb97] zu finden. Von Interesse ist auch die International SGML/XML Users' Group:
http://www.isgmlug.org/
HyTime (ISO/IEC 10744)
Den Einstieg in die Hypermedia/Time-based Structuring Language findet man am besten auf
der HyTime Users' Group Home Page (http://www.hytime.org/). HyTime hat viele Grundlagen
f"r die Linking-Spezifikationen f"r XML geschaffen.
Topic Maps (ISO/IEC 13250)
Die 2000 verabschiedete Norm Topic Maps dient zur thematischen Gruppierung von Infor-
mationsobjekten (dies k0nnten zum Beispiel Webseiten sein) und zum Beschreiben der
zwischen ihnen bestehenden Relationen. Es besteht ein gewisser Zusammenhang zu den
W3C-Sepzifikationen f"r RDF. Eine Variante sind die XML Topic Maps. Siehe http://www.to-
picmaps.org/
ISO/IEC 10646-1
Zu dieser Norm geh0ren Universal Multiple-Octet Coded Character Set (UCS), Transformation
Format for 16 planes of group 00 (UTF-16) sowie UCS Transformation Format 8 (UTF-8). Es han-
delt sich dabei um die f"r XML zugrunde gelegte Zeichenkodierung. F"r den praktischen
Einsatz ist die »offizielle Implementierung« namens Unicode wichtig (Zitat von der Unico-
de-Site). Informationen sind unter http://www.unicode.org/ zu finden. Die im Februar 2000
ver0ffentlichte Version 3.0 von Unicode ist mit der Second Edition von ISO/IEC 10646-1
abgeglichen. Ein lesenswerter Text zu Unicode und XML ist als kombinierte W3C Note/
Unicode Technical Report auf den Sites beider Konsortien zu finden: Unicode in XML and
other Markup Languages (http://www.unicode.org/unicode/reports/tr20/ oder http://www.
w3.org/TR/unicode-xml/)
HyperText Markup Language (HTML, ISO/IEC 15445:2000)
Diese Variante von HTML 4 wird "blicherweise als ISO-HTML bezeichnet. Eine Beschrei-
bung der beiden Herausgeber, David M. Abrahamson und Roger Price, ist unter http://
purl.org/NET/ISO+IEC.15445/Users-Guide.html zu finden.

Thematische Einfhrung und berblick ber den Band < 31 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Organization for the Advancement of Structured Information


Standards

OASIS ist eine Organisation, die sich der Verbreitung von offenen Standards wie XML ver-
schrieben hat. Im Gegensatz zum W3C gibt sie selbst keine technischen Spezifikationen heraus.
Außerdem ist die Mitgliedschaft nicht auf Firmen beschrnkt, sondern steht auch Einzelper-
sonen offen. Die OASIS-Homepage ist unter http://www.oasis-open.org/. OASIS betreibt auch
das Portal XML.org unter der gleichnamigen Adresse http://xml.org/.
OASIS ist gemeinsam mit den Vereinten Nationen verantwortlich f"r das Projekt Electronic Busi-
ness XML (http://www.ebxml.org/).
Ein f"r den praktischen Einsatz von XML sehr wichtiger Aspekt wird vom W3C nicht adres-
siert: Das Auffinden von externen Entities. Im Gegensatz zu SGML muss bei XML f"r externe
Entities immer ein System-Identifier angegeben werden. In XML-Dokumenten ist dies ein URI.
Damit ist das Problem der Entity-Referenzierung aus W3C-Sicht erledigt. In der Praxis ist die-
ser formale Standpunkt oft nicht zufriedenstellend. Doch schon zu SGML-Zeiten gab es eine
L0sung: Ein Katalog, der global eindeutige Entity-Namen (damals:Formal Public Identifier (FPI);
heute mehr und mehr: URI) auf lokale Namen abbildet. Eine Initiative f"r XML Catalogs gibt es
([XMLcat]); praktisch werden nach wie vor die alten, etablierten SGML Open Catalogs eingesetzt
([SOcat]) und auch von vielen XML-Programmen unterst"tzt.

Common Gateway Interface

HTML-Formulare sind vergleichsweise pl0tzlich im Web aufgetaucht. Sie wurden in der zwei-
ten Jahreshlfte 1993 im XMosaic-Browser implementiert. Zu dieser Zeit gab es nur zwei ver-
breitete Web-Server, den vom NCSA (Vorlufer des Apache-Servers) und den vom CERN. Es
stellte sich die Frage, wie Daten, die vom Benutzer in Formulare eingetragen wurden, zum Ser-
ver "bertragen und von diesem an ein verarbeitendes Programm "bertragen werden. Die
7bertragung zum Server erfolgt durch Anhngen an einen URI (Get-Methode) oder als Inhalt
der HTTP-Nachricht (Post-Methode). Die Entwickler am National Center f"r Supercomputing
Applications (NCSA) haben einen Vorschlag gemacht, wie die Daten auf dem Server-Rechner
an ein beliebiges Programm "bergeben werden k0nnen: das Common Gateway Interface. Das
Ziel der Entwickler war eine L0sung, die es gestattet, ein so genanntes CGI-Programm mit
beliebigen Server-Programmen benutzen zu k0nnen; es sollte keine L0sung nur f"r den NCSA-
Server sein. Daher kommt der Name Common Gateway Interface.
Da CGI im Unix-Umfeld entwickelt wurde, war es naheliegend, dass Daten per Standardein-
gabe (STDIN) und durch Umgebungsvariablen "bergeben werden. Die Dokumentation von
CGI ist nach fast zehn Jahren noch immer unter der selben Adresse zu finden: The Common
Gateway Interface, http://hoohoo.ncsa.uiuc.edu/cgi/overview.html.
Wer ein Bourne-Shell-Skript f"r die Auswertung von per HTTP "bertragenen Daten schreiben
m0chte, wird nach wie vor sehr direkt mit dem CGI in Ber"hrung kommen. F"r die meisten
komfortableren Programmiersprachen, wie etwa Perl oder PHP, ist eine „manuelle“ Auswer-
tung der CGI-Parameter nicht mehr n0tig. F"r Perl beispielsweise gibt es ein Modul, dass die
CGI-Parameterwerte in ein Perl-Objekt umwandelt und in einer f"r die Programmiersprache
nat"rlichen Weise zur Verf"gung stellt.

< 32 > Einleitung


Page size: 168,00 x 240,00 mm

Literatur
BeMi2000
Henning Behme und Stefan Mintert. XML in der Praxis, Addison-Wesley, M"nchen 2000
Clark97
James Clark. Comparison of SGML and XML,1997. http://www.w3.org/TR/NOTE-sgml-
xml-971215
Goldfarb97
Charles F. Goldfarb. The SGML History Niche, 1997. http://www.sgmlsource.com/history/
index.htm
Raggett98
Dave Raggett, Jenny Lam, Ian Alexander, Michael Kmiec. HTML 4, Addison-Wesley, Bonn
1998
SOcat
Paul Grosso (Subcommitee chair). Entity Management - OASIS Technical Resolution
9401:1997 (Amendment 2 to TR 9401), OASIS, 10. September 1997. http://www.oasis-
open.org/specs/tr9401.html
W3C7pt
Das World Wide Web Consortium (W3C) in sieben Punkten, 7bersetzung von Henning
Fischer, 6.4.2002. http://www.w3.org/Consortium/Offices/Germany/sieben.html
W3CTR
W3C Technical Reports and Publications. http://www.w3.org/TR/. Deutsche 7bersetzun-
gen siehe http://www.edition-w3c.de/
XML10pt
W3C Communication Team. XML in 10 Punkten, 7bersetzung von Henning Fischer, 2002.
http://www.w3.org/Consortium/Offices/Germany/Misc/XML-in-10-points.html.de
XMLcat
Norman Walsh (editor). XML Catalogs, OASIS, 6. August 2001. http://www.oasis-open.org/
committees/entity/spec.html
XMLspec21
Guide to the W3C XML Specification ("XMLspec") DTD, Version 2.1. http://www.
w3.org/XML/1998/06/xmlspec-report-v21.htm

Literatur < 33 >


Page size: 168,00 x 240,00 mm
Page size: 168,00 x 240,00 mm

<edition
   W3C.de>
A
< Die HTML 4.01-
Spezifikation >
Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

HTML 4.01-Spezifikation
Deutsche bersetzung
Die HTML 4.01- Spezifikation

Diese Version:
http://www.edition-w3c.de/TR/1999/REC-html401-19991224
Aktuelle Version:
http://www.edition-w3c.de/TR/html4
bersetzer:
Christine Khnel ( bersetzung, fachliche Kommentierung)
<kuehnel@screenexa.net>
Stefan Schumacher ( bersetzung, fachliche Kommentierung)
<sts@schumacher-netz.de>
Stefan Mintert (Fachlektorat und fachliche Kommentierung)

Bei diesem Dokument handelt es sich um eine bersetzung eines W3C-Textes. Dieser
Text ist urheberrechtlich geschtzt; 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 endgltige
Dokument unter der oben angegebenen Adresse ver=ffentlicht. Die jetzige Ver=ffent-
lichung w@hrend der laufenden Arbeit dient zur Information von Interessierten und zur
Prfung durch die Fach=ffentlichkeit. Sollten Sie Fehler finden oder Verbesserungsvor-
schl@ge haben, schicken Sie diese bitte per Mail an die bersetzer.

W3C-Recommendation 24. Dezember 1999


Diese Version:
http://www.w3.org/TR/1999/REC-html401-19991224
(Textdatei [794Kb] http://www.w3.org/TR/1999/REC-html401-19991224/html40.txt,
gzipptes Tar-Archiv der HTML-Dateien [371Kb] http://www.w3.org/TR/1999/REC-
html401-19991224/html40.tgz,
Zip-Archiv der HTML-Dateien [405Kb] http://www.w3.org/TR/1999/REC-
html401-19991224/html40.zip,
gzippte Postscript-Datei [746Kb, 389 Seiten] http://www.w3.org/TR/1999/REC-
html401-19991224/html40.ps.gz,
gzippte PDF-Datei [963Kb] http://www.w3.org/TR/1999/REC-
html401-19991224/html40.pdf.gz)
Aktuelle Version von HTML 4.01:
http://www.w3.org/TR/html401

< 36 > Die HTML 4.01- Spezifikation


Page size: 168,00 x 240,00 mm

Aktuelle Version von HTML 4:


http://www.w3.org/TR/html4
Aktuelle Version von HTML:
http://www.w3.org/TR/html

Die HTML 4.01- Spezifikation


Vorherige Version von HTML 4.01:
http://www.w3.org/TR/1999/PR-html40-19990824
Vorherige HTML 4-Recommendation:
http://www.w3.org/TR/1998/REC-html40-19980424
Editoren:
Dave Raggett <dsr@w3.org>
Arnaud Le Hors, W3C
Ian Jacobs, W3C

Copyright L1997-1999 W3CM (MIT, INRIA, Keio), All Rights Reserved. W3C liability,
trademark, document use and software licensing rules apply.

Zusammenfassung
Diese Spezifikation definiert die HyperText Markup Language (HTML), die Sprache fr Ver-
=ffentlichungen im World Wide Web. Diese Spezifikation definiert HTML 4.01, eine ber-
arbeitung von HTML 4. Zus@tzlich zu den Text-, Multimedia und Hyperlink-Funktionen der fr-
heren HTML-Versionen (HTML 3.2 [HTML32] und HTML 2.0 [RFC1866]), untersttzt HTML
4 mehr Multimedia-Erweiterungen, Skript-Sprachen, Stylesheets, bessere Druckfunktionen,
sowie zug@nglichere Dokumente fr behinderte Benutzer. HTML 4 macht auch große Schritte
im Hinblick auf die Internationalisierung von Dokumenten, mit dem Ziel, das Netz wirklich
weltweit zu machen (World Wide Web).
HTML 4 ist eine zum internationalen Standard ISO 8879 konforme SGML-Anwendung (Stan-
dard Generalized Markup Language [ISO8879]).

Status dieses Dokuments


Dieser Abschnitt beschreibt den Status dieses Dokuments zum Zeitpunkt seiner Ver=ffent-
lichung. Andere Dokumente k=nnen dieses ersetzen. Der letzte Stand der Dokumentreihe
wird vom W3C gepflegt.
Dieses Dokument spezifiziert HTML 4.01, das Teil der HTML 4-Spezifikationen ist. Die erste
Version von HTML 4 war HTML 4.0 [HTML40], ver=ffentlicht am 18. Dezember 1997 und
berarbeitet am 24. April 1998. Diese Spezifikation ist die erste HTML 4.01-Recommendation.
Sie enth@lt nicht redaktionelle Onderungen seit der HTML-Version 4.0 vom 24. April. Es gab
zum Beispiel einige Onderungen an den DTDs. Dieses Dokument erkl@rt vorherige Versionen
von HTML 4.0 fr veraltet, obgleich das W3C diese Spezifikationen und ihre DTDs weiterhin
auf der Web-Site des W3C verfgbar machen wird.
Dieses Dokument wurde von Mitgliedern des W3C und anderen Interessierten geprft und
vom Direktor des W3C als W3C-Recommendation gebilligt. Es ist ein stabiles Dokument und
kann als Referenzmaterial verwendet werden oder von anderen Dokumenten als normative

Die HTML 4.01- Spezifikation < 37 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Referenz zitiert werden. Die Rolle des W3C bei der Erstellung dieser Recommendation ist es,
die Spezifikation bekannt zu machen und ihren breiten Einsatz zu f=rdern. Dies erh=ht die
Funktionalit@t und Interoperabilit@t des Webs.
Das W3C empfiehlt, dass Benutzerprogramme und Autoren (und im besonderen Programme
Die HTML 4.01- Spezifikation

zur Erstellung von Web-Seiten) Dokumente bevorzugt in HTML 4.01 erzeugen und nicht in
HTML 4.0. Das W3C empfiehlt, dass Autoren HTML 4-Dokumente erstellen, statt HTML
3.2-Dokumente. Aus Grnden der Rckw@rtskompatibilit@t empfiehlt das W3C zus@tzlich, dass
Programme, die HTML 4 interpretieren, auch weiterhin HTML 3.2 und HTML 2.0 unterstt-
zen.
Informationen ber die n@chste Generation von HTML, die „Extensible HyperText Markup
Language“[XHTML], finden Sie bei der W3C HTML Activity (http://www.w3.org/MarkUp/) und
in der Liste der W3C Technical Reports (http://www.w3.org/TR/).
Dieses Dokument wurde als Teil der W3C HTML Activity (http://www.w3.org/MarkUp/)
erstellt. Die Ziele der HTML Working Group (http://www.w3.org/MarkUp/Group/, nur
fr Mitglieder: http://cgi.w3.org/MemberAccess/) werden in der HTML Working Group
Charter (http://www.w3.org/MarkUp/Group/HTMLcharter, nur fr Mitglieder: http://cgi.w3.org/
MemberAccess/) besprochen.
Eine Liste der aktuellen W3C-Recommendations und anderer technischer Dokumente ist
unter http://www.w3.org/TR zu finden.
Sffentliche Diskussionen zu HTML-Gesichtspunkten werden in der Mailingliste www-
html@w3.org gefhrt (Archiv: www-html@w3.org).

Verf-gbare Sprachen

Die englische Version dieser Spezifikation ist die einzige normative Version. bersetzungen
dieses Dokuments finden Sie unter http://www.w3.org/MarkUp/html4-updates/translations.

Errata

Die Liste der bekannten Fehler in dieser Spezifikation ist verfgbar unter
http://www.w3.org/MarkUp/html4-updates/errata.

Bitte senden Sie Berichte ber Fehler in diesem Dokument an www-html-editor@w3.org.

1 ber die HTML 4-Spezifikation


1.1 Wie die Spezifikation aufgebaut ist
Diese Spezifikation ist in die folgenden Abschnitte unterteilt:

Abschnitte 2 und 3: Einf-hrung in HTML 4


Die Einfhrung beschreibt, wie HTML in das Schema des World Wide Webs einzuordnen
ist, erz@hlt kurz die Geschichte der HTML-Entwicklung, stellt heraus, was mit HTML
gemacht werden kann, und gibt einige Tips zur Arbeit mit HTML.

< 38 > ber die HTML 4-Spezifikation


Page size: 168,00 x 240,00 mm

Das kurze SGML-Tutorial kl@rt den Leser im Grundsatz ber die Beziehung von HTML zu
SGML auf und gibt einen berblick, wie die Dokumenttyp-Definition (DTD) von HTML zu
lesen ist.
Abschnitt 4 bis 24: HTML 4-Referenzhandbuch

Die HTML 4.01- Spezifikation


Der berwiegende Teil des Referenzhandbuchs besteht aus der HTML-Sprachreferenz, die
alle Elemente und Attribute der Sprache definiert.
Dieses Dokument folgt in seinem Aufbau weniger der HTML-Grammatik als vielmehr The-
menschwerpunkten. Die Themen gliedern sich in drei Kategorien: Struktur, Darstellung
und Interaktivit@t. Auch wenn es nicht einfach ist, HTML-Konstrukte perfekt in diese drei
Kategorien einzuordnen, spiegelt dieses Modell die Erfahrungen der HTML Working Group
wider, die besagen, dass die Trennung der Dokumentstruktur von der Darstellung effekti-
vere und pflegeleichtere Dokumente erzeugt.
Die Sprachreferenz besteht aus den folgenden Informationen:
·· Welche Zeichen drfen in einem HTML-Dokument erscheinen.
Grundlegende Datentypen eines HTML-Dokuments.
· Elemente zur Bestimmung der Struktur von HTML-Dokumenten, einschließlich Text,
Listen, Tabellen, Links und eingeschlossene Objekte sowie Bilder und Applets.
· Elemente zur Bestimmung der Darstellung eines HTML-Dokuments, einschließlich
Stylesheets, Schriftarten, Farben, Trennlinien und andere optische Darstellungsformen
und Frames fr die Darstellung in mehreren Fenstern.
· Elemente, die Interaktivit@t mit einem HTML-Dokument erlauben, einschließlich For-
mulare fr Benutzereingaben und Skripte fr aktive Dokumente.
·· Die formale SGML-Definition von HTML:
Die SGML-Deklaration von HTML.
·· Drei DTDs: strict, transitional und frameset.
Die Liste der Zeichenreferenzen.
Anh.nge
Der erste Anhang enth@lt Informationen ber die Onderungen gegenber HTML 3.2, um
Autoren und Entwicklern beim bergang zu HTML 4 zu helfen, sowie Onderungen gegen-
ber der Spezifikation vom 18. Dezember 1997. Der zweite Anhang enth@lt Bemerkungen
zur Leistungsf@higkeit und zur Implementierung und ist prim@r darauf ausgerichtet, Entwick-
ler bei der Erstellung von Benutzerprogrammen fr HTML 4 zu untersttzen.
Referenzen
Eine Liste normativer und informeller Referenzen.
Indizes
Drei Indizes verschaffen dem Leser einen raschen Zugriff auf die Definitionen der Schlssel-
konzepte, Elemente und Attribute.

1.2 Dokumentkonventionen
Dieses Dokument wurde fr zwei Lesergruppen geschrieben: Autoren und Entwickler. Wir
hoffen, dass die Spezifikation Autoren mit den n=tigen Werkzeugen ausstatten wird, um effi-
ziente, attraktive und zug@ngliche Dokumente zu schreiben, ohne sie mit den Details der
HTML-Implementation zu berfordern. Entwickler sollten jedoch alles finden, was sie ben=ti-
gen, um konforme Benutzerprogramme zu erstellen.
Die Spezifikation kann von verschiedenen Seiten angegangen werden:

Dokumentkonventionen < 39 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

· Vom Anfang bis zum Ende lesen. Die Spezifikation beginnt mit einer allgemeinen Dar-
stellung von HTML und wird zum Ende mehr und mehr technisch und geht in die Details.
· Schneller Zugang zu Informationen. Um an Informationen ber die Syntax und
Semantik so schnell wie m=glich zu kommen, enth@lt die Online-Version der Spezifikation
Die HTML 4.01- Spezifikation

die folgenden Eigenschaften.


1. Jede Bezugnahme auf ein Element oder Attribut ist ber einen Link mit dessen Defini-
tion in der Spezifikation verbunden. Jedes Element oder Attribut ist nur an einer Stelle
definiert.
2. Jede Seite enth@lt Links auf die Indizes. So ist man niemals mehr als zwei Links von der
Definition eines Elements oder Attributs entfernt.
3. Jeder Abschnitt des Sprachreferenzhandbuchs erweitert das ursprngliche Inhaltsver-
zeichnis um weitere Details zum jeweiligen Abschnitt.

1.2.1 Elemente und Attribute

Elementnamen werden in Großbuchstaben geschrieben (z. B. BODY). Attributnamen werden


in Kleinbuchstaben geschrieben (z. B. lang, onsubmit). Rufen Sie sich ins Ged@chtnis, dass fr
HTML gilt: Element- und Attributnamen unterscheiden nicht zwischen Groß- und Kleinschrei-
bung (case-insensitive); die Konvention soll lediglich die Lesbarkeit f=rdern.
Element- und Attributnamen wurden in diesem Dokument ausgezeichnet und werden von eini-
gen Benutzerprogrammen eventuell besonders dargestellt.
Jede Attributdefinition gibt den Typ des Attributwerts an. Erlaubt der Typ eine geringe Anzahl
m=glicher Werte, listet die Definition die verschiedenen Werte auf, getrennt durch einen senk-
rechten Strich (|).
Nach den Angaben zum Typ, zeigt jede Attributdefinition innerhalb von eckigen Klammern
(„[ ]“) an, ob der Wert zwischen Groß- und Kleinschreibung unterscheidet oder nicht (case-
sensitivity). Details finden Sie in Abschnitt 6.1, „Information zu Groß- bzw. Kleinschreibung“.

1.2.2 Bemerkungen und Beispiele

Um sich vom umgebenden Text abzuheben, sind informelle Bemerkungen hervorgehoben, und
werden von einigen Benutzerprogrammen eventuell besonders dargestellt.
Alle Beispiele, die missbilligten Sprachgebrauch verdeutlichen sollen, sind als „MISSBILLIGTES
BEISPIEL“ gekennzeichnet. Missbilligte Beispiele beinhalten auch empfohlene alternative L=sun-
gen. Alle Beispiele, die nicht erlaubten Sprachgebrauch verdeutlichen, sind klar als „UNER-
LAUBTES BEISPIEL“ gekennzeichnet.
Beispiele und Bemerkungen wurden ausgezeichnet und werden eventuell von einigen Benutzer-
programmen besonders dargestellt.

1.3 Danksagungen
Dank an alle, die mitgeholfen haben, den Working Draft zu erstellen, der zur HTML 4-Spezifika-
tion fhrte, und an all diejenigen, die Vorschl@ge und Korrekturen eingebracht haben.
Vielen Dank an die Web Accessibility Initiative Task Force (WAI HC Group) fr ihre Arbeit
zur Verbesserung der Zug@nglichkeit in HTML und an T.V. Raman (Adobe) fr seine frhe
Arbeit bei der Entwicklung von zug@nglichen Formularen.

< 40 > ber die HTML 4-Spezifikation


Page size: 168,00 x 240,00 mm

Die Autoren dieser Spezifikation, die Mitglieder der W3C HTML Working Group, verdienen
große Anerkennung fr ihre gewissenhafte Bearbeitung dieses Dokuments, ihre konstruktiven
Kommentare und ihre harte Arbeit: John D. Burger (MITRE), Steve Byrne (JavaSoft), Martin J.
Drst (University of Zurich), Daniel Glazman (ElectricitW de France), Scott Isaacs (Microsoft),

Die HTML 4.01- Spezifikation


Murray Maloney (GRIF), Steven Pemberton (CWI), Robert Pernett (Lotus), Jared Sorensen
(Novell), Powell Smith (IBM), Robert Stevahn (HP), Ed Tecot (Microsoft), Jeffrey Veen (HotWi-
red), Mike Wexler (Adobe), Misha Wolf (Reuters) und Lauren Wood (SoftQuad).
Danke Dir, Dan Connolly (W3C) fr die genaue und zeitintensive Arbeit als Teilzeit-Editor und
fr die aufmerksame Leitung als Vorsitzender der HTML Working Group. Danke Dir, Sally
Khudairi (W3C) fr Deine unentbehrliche Arbeit bei der Erstellung der Presseinformationen.
Dank an David M. Abrahamson und Roger Price fr das sorgf@ltige Lesen der Spezifikation und
konstruktive Kommentare.
Dank an Jan K@rrman, dem Autor von html2ps (http://www.tdb.uu.se/~jan/html2ps.html), fr
die große Hilfe bei der Erstellung der Postscript-Version der Spezifikation.
Von besonderer Hilfe vom W3C in Sophia-Antipolis waren Janet Bertot, Bert Bos, Stephane
Boyera, Daniel Dardailler, Yves Lafon, HZkon Lie, Chris Lilley und Colas Nahaboo (Bull).
Schließlich gebrt Dank Tim Berners-Lee, ohne den nichts von alledem m=glich gewesen w@re.

1.3.1 Danksagungen f-r die aktuelle berarbeitung

Vielen Dank an Shane McCarron fr die Fehlerverfolgung zu dieser Version der Spezifikation.

1.4 Bemerkung zum Urheberrecht


Informationen zum Urheberrecht finden Sie in der W3C Intellectual Property Notice
(http://www.w3.org/Consortium/Legal/ipr-notice#Copyright), der W3C Document Notice
(http://www.w3.org/Consortium/Legal/copyright-documents-19990405.html) und der W3C IPR
Software Notice (http://www.w3.org/Consortium/Legal/copyright-software-19980720.html).

2 Einf-hrung in HTML 4
2.1 Was ist das World Wide Web?
Das World Wide Web (Web) ist ein Netzwerk von Informationsquellen. Um diese Ressourcen
dem gr=ßtm=glichen Publikum problemlos verfgbar zu machen, sttzt sich das Web auf drei
Mechanismen:
1. Ein einheitliches Namensschema zum Lokalisieren von Ressourcen im Web (z. B. URIs)
2. Protokolle fr den Zugriff auf benannte Ressourcen ber das Web (z. B. HTTP)
3. Hypertext zur einfachen Navigation zwischen den Ressourcen (z. B. HTML)
Die Zusammenh@nge zwischen den drei Mechanismen sind in der gesamten Spezifikation erkennbar.

Bemerkung zum Urheberrecht < 41 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

2.1.1 Einf-hrung in URIs

Jede im Netz verfgbare Ressource – HTML-Dokument, Grafik, Videoclip, Programm und so


weiter – hat eine Adresse, die in Form eines Universal Resource Identifier oder „URI“ kodiert
Die HTML 4.01- Spezifikation

werden kann.
URIs bestehen blicherweise aus drei Teilen:
1. Dem Namensschema des fr den Zugriff auf die Ressource verwendeten Mechanismus
2. Dem Namen des Rechners, auf dem sich die Ressource befindet
3. Dem Namen der Ressource selbst, angegeben als Pfad
Nehmen wir den URI, der die „Technical Reports“ des W3C kennzeichnet:

http://www.w3.org/TR

Dieser URI kann folgendermaßen gelesen werden: Es gibt ein via HTTP-Protokoll verfgbares
Dokument (s. [RFC2616]), das sich auf dem Rechner www.w3.org befindet und ber den Pfad
„/TR“ erreichbar ist. Andere Schemata, die Ihnen in HTML-Dokumenten begegnen k=nnen,
enthalten „mailto“ fr Email und „ftp“ fr FTP.

Anmerkung der bersetzer: In gewissem Sinne ist dies kein so gutes Beispiel.
Zwar liefert der Web-Browser bei Eingabe von http://www.w3.org/TR die gewnschte
Seite; wer aber genau hinsieht, stellt fest, dass die Adresse nach dem Laden anders lau-
tet: http://www.w3.org/TR/. Der Schr@gstrich am Ende rhrt daher, dass der Server bei
Zugriff auf /TR eine Umlenkung ausl=st. Das heißt, der Browser wird angwiesen, es
doch noch einmal an anderer Stelle zu probieren, in diesem Fall /TR/.
Auf Protokollebene sieht das so aus: Zuerst der Zugriff auf /TR:

HEAD /TR HTTP/1.0

HTTP/1.1 301 Moved Permanently


Date: Fri, 29 Nov 2002 18:11:17 GMT
Server: Apache/1.3.26 (Unix) PHP/3.0.18
Location: http://www.w3.org/TR/
Connection: close
Content-Type: text/html; charset=iso-8859-1

Zu erkennen ist die Antwort „301 Moved Permanently“ und die neue Adresse „Loca-
tion: http://www.w3.org/TR/“. Nun zum Vergleich der Zugriff auf /TR/:

HEAD /TR/ HTTP/1.0

HTTP/1.1 200 OK
Date: Fri, 29 Nov 2002 18:11:37 GMT
Server: Apache/1.3.26 (Unix) PHP/3.0.18
P3P: policyref="http://www.w3.org/2001/05/P3P/p3p.xml"
Cache-Control: max-age=600
Expires: Fri, 29 Nov 2002 18:21:37 GMT
Last-Modified: Sat, 16 Nov 2002 15:56:59 GMT
ETag: "3dd66acb"
Accept-Ranges: bytes
Content-Length: 102136

< 42 > Einf#hrung in HTML 4


Page size: 168,00 x 240,00 mm

Connection: close
Content-Type: text/html; charset=iso-8859-1

Hier die Antwort „200 OK“. Im ersten Fall werden also zwei HTTP-Anfragen ben=tigt.

Die HTML 4.01- Spezifikation


In einer Situation wie dieser sollte der Schr@gstrich nicht leichtfertig weggelassen wer-
den. Andernfalls entsteht unn=tiger Netzverkehr.

Hier ist ein weiteres Beispiel fr einen URI. Dieser weist auf die Mailbox eines Benutzers:

...dies ist Text...


Anregungen und Meinungen senden Sie bitte an
<A href="mailto:joe@someplace.com">Joe Cool</A>.

Anmerkung der bersetzer: An dieser Stelle sei darauf aufmerksam gemacht,


dass ein Link, der auf ein anderes Protokoll als „http“ verweist, bei seiner Aktivierung in
aller Regel auch ein anderes Benutzerprogramm als den Web-Browser erfordert; in die-
sem Fall w@re das ein Mail-Client. Man sollte also nicht davon ausgehen, dass die Akti-
vierung des Links bei jedem Benutzer zum gewnschten Ergebnis fhren muss.

Anmerkung: Den meisten Lesern wird der Begriff „URL“ gel,ufig sein, nicht aber der Begriff „URI“.
URLs bilden eine Teilmenge des umfassenderen URI-Namensschemas. n

2.1.2 Fragmentbezeichner (fragment identifiers)

Einige URIs weisen auf eine Stelle innerhalb einer Ressource. Diese Art von URIs endet mit
„#“, gefolgt von Bezeichnern fr einen Anker (genannt Fragmentbezeichner). Zum Beispiel
zeigt dieser URI auf einen Anker namens section_2:

http://somesite.com/html/top.html#section_2

2.1.3 Relative URIs

Ein relativer URI enth@lt keinerlei Namensschemainformationen. Sein Pfad weist im Allgemei-
nen auf eine Ressource auf demselben Rechner wie das aktuelle Dokument. Relative URIs k=n-
nen relative Pfadkomponenten (z. B. meint „..“ die n@chsth=here Ebene in der durch den Pfad
festgelegten Hierarchie) und auch Fragmentbezeichner enthalten.
Relative URIs werden unter Verwendung eines Basis-URIs zu vollst@ndigen URIs aufgel=st. Als
Beispiel fr die Aufl=sung relativer URIs nehmen wir an, wir h@tten den Basis-URI
„http://www.acme.com/support/intro.html“. Der relative URI in folgender Auszeichnung eines
Hypertext-Links

<A href="suppliers.html">Suppliers</A>

Was ist das World Wide Web? < 43 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

wrde erweitert zum vollst@ndigen URI „http://www.acme.com/support/suppliers.html“, w@h-


rend der relative URI in der folgenden Auszeichnung fr ein Bild

<IMG src="../icons/logo.gif" alt="logo">


Die HTML 4.01- Spezifikation

aufgel=st wrde zum vollst@ndigen URI „http://www.acme.com/icons/logo.gif“.


In HTML werden URIs verwendet, um
· auf ein anderes Dokument oder eine andere Ressource zu verweisen, (s. A- und LINK-
Element).
·· auf ein externes Stylesheet oder Skript zu verweisen (s. LINK- und SCRIPT-Element).
ein Bild, Objekt oder Applet in eine Seite einzufgen, (s. IMG-, OBJECT-, APPLET- und INPUT-
Element).
·· eine Imagemap zu kreieren (s. the MAP- und AREA-Element).
ein Formular abzuschicken (s. FORM-Element).
·· ein Frame-Dokument zu erzeugen (s. FRAME- und IFRAME-Element).
eine externe Quelle zu zitieren (s. Q-, BLOCKQUOTE-, INS- und DEL-Element).
· auf Meta-Daten zu verweisen, die das Dokument beschreiben (s. HEAD-Element).
Mehr zu URIs lesen Sie bitte im Abschnitt 6.4, „URIs“.

2.2 Was ist HTML?


Um Informationen zur globalen Verbreitung zu publizieren, braucht man eine universell ver-
st@ndliche Sprache, eine Art Muttersprache der Publikation, die m=glichst alle Computer ver-
stehen k=nnen. Die vom World Wide Web benutze Publikationssprache ist HTML (HyperText
Markup Language).
HTML gibt Autoren die Mittel an die Hand, um
·· Dokumente mit berschriften, Text, Tabellen, Listen, Fotos usw. online zu ver=ffentlichen.
Online-Informationen via Hypertext-Links auf Knopfdruck abzurufen.
· Formulare fr Transaktionen mit entfernten Diensten fr den Einsatz bei der Informa-
tionssuche, bei Reservierungen, bei Warenbestellungen usw. zu gestalten.
· Spreadsheets, Videoclips, Soundclips und andere Applikationen direkt in ihre Dokumente
einzufgen.

2.2.1 Ein kurzer Abriss der Geschichte von HTML

HTML wurde ursprnglich von Tim Berners-Lee w@hrend seiner CERN-Zeit entwickelt und
durch den von NCSA geschaffenen Mosaic-Browser popul@r gemacht. Mit dem explosiven
Wachstum des Web erblhte es w@hrend der Neunzigerjahre. In dieser Zeit wurde HTML auf
mehrere Arten erweitert. Das Web ist darauf angewiesen, dass Autoren von Webseiten und
Produkthersteller dieselben Konventionen fr HTML einhalten. Das hat zur gemeinsamen
Arbeit an Spezifikationen fr HTML angeregt.
HTML 2.0 (November 1995, s. [RFC1866]) wurde unter der Leitung der Internet Engineering
Task Force (IETF) entwickelt, um die Ende 1994 g@ngige Praxis zu formalisieren. HTML+ (1993)
und HTML 3.0 (1995, s. [HTML30]) schlugen reichhaltigere Versionen von HTML vor. Obwohl
in den Diskussionen der Standards nie ein Konsens erreicht wurde, fhrten diese Entwrfe zur
bernahme einer Auswahl von neuen Features. Die Bemhungen der HTML Working Group

< 44 > Einf#hrung in HTML 4


Page size: 168,00 x 240,00 mm

des World Wide Web Consortiums to codify common practice in 1996 endeten mit HTML
3.2 (January 1997, s. [HTML32]). Onderungen gegenber HTML 3.2 sind in Anhang A zusam-
mengestellt.
Die Mehrheit ist sich darin einig, dass HTML-Dokumente ber verschiedene Browser und

Die HTML 4.01- Spezifikation


Plattformen hinweg funktionieren sollten. Wird diese Interoperabilit@t erreicht, reduzieren sich
die Kosten der Content-Provider, denn sie mssen nur eine Version eines Dokuments erarbei-
ten. Wird diese Anstrengung nicht unternommen, besteht eine wesentlich gr=ßere Gefahr,
dass das Web auf eine propriet@re Welt inkompatibler Formate zugeht und sich letzten Endes
das kommerzielle Potenzial des Web fr alle Beteiligten verringert.
Jede Version von HTML hat versucht, den wachsenden Konsens unter den Industrievertretern
widerzuspiegeln, so dass die Investitionen der Inhaltsanbieter nicht verschwendet und ihre
Dokumente nicht in kurzer Zeit unlesbar werden.
HTML wurde mit der Vision entwickelt, dass alle Arten von Ger@ten in der Lage sein sollten,
Informationen aus dem Web zu nutzen: PCs mit grafischen Displays unterschiedlichster Auf-
l=sung und Farbtiefe, Funktelefone, Handhelds, Ger@te mit Sprachein- und -ausgabe, Ger@te mit
großer und kleiner Bandbreite usw.

2.3 HTML 4
HTML 4 erweitert HTML um Mechanismen fr Stylesheets, Scripting, Frames, eingebundene
Objekte, verbesserte Untersttzung fr von rechts nach links zu lesende Texte sowie Texte
mit unterschiedlichen Leserichtungen, reichhaltigere Tabellen und fr Menschen mit Behin-
derungen bessere Zug@nglichkeit bietende Erweiterungen bei Formularen.
HTML 4.01 ist eine berarbeitung von HTML 4.0, in der Fehler korrigiert und einige Onderun-
gen seit der vorhergehenden berarbeitung vorgenommen wurden.

2.3.1 Internationalisierung

Diese HTML-Version wurde mit Hilfe von Experten auf dem Gebiet der Internationalisierung
gestaltet, so dass Dokumente in jeder Sprache geschrieben und problemlos um die Welt trans-
portiert werden k=nnen. Erreicht wurde das durch die Einbeziehung von [RFC2070], der sich
mit der Internationalisierung von HTML befasst.
Ein bedeutender Schritt war die Aufnahme des Standards ISO/IEC:10646 (siehe [ISO10646])
als Dokument-Zeichensatz fr HTML. Dies ist der weltweit umfassendste Standard zu Fragen
der Darstellung internationaler Zeichen, Leserichtung, Zeichensetzung und anderer Themen
bezglich der Sprachen der Welt.
HTML bietet jetzt weitreichendere Untersttzung fr verschiedene menschliche Sprachen
innerhalb eines Dokuments. Dies erm=glicht die effektivere Indizierung von Dokumenten
durch Suchmaschinen, qualitativ bessere Typographie, eine bessere Text-nach-Sprache-Kon-
vertierung, bessere Silbentrennung usw.

Anmerkung der bersetzer: Mit Fragen der Internationalisierung besch@ftigt sich


eine eigene Activity, die „W3C Internationalization Activity“, die es sich zur Aufgabe
gemacht hat, die Nutzbarkeit von Formaten und Protokollen des W3C weltweit in allen
Sprachen sicherzustellen.

HTML 4 < 45 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

N@heres dazu finden Sie auf der zugeh=rigen Web-Site unter http://www.w3.org/Inter-
national/.
Die HTML 4.01- Spezifikation

2.3.2 Zug.nglichkeit

Da die Web-Community w@chst und ihre Mitglieder sich in ihren F@higkeiten und ihrem K=n-
nen voneinander unterscheiden, ist es entscheidend, dass die zugrunde liegenden Technologien
an deren spezifische Bedrfnisse angepasst sind. HTML wurde darauf ausgelegt, Webseiten fr
Menschen mit physischen Einschr@nkungen besser zug@nglich zu machen. Folgende HTML
4-Entwicklungen sind durch die wachsende Bedeutung der Zug@nglichkeit angeregt worden:
· Bessere Trennung zwischen Dokumentstruktur und Pr@sentation, demzufolge F=rderung
der Nutzung von Stylesheets anstelle von HTML-Pr@sentationselementen und -Attributen.
· Bessere Formulare, darin enthalten die Erg@nzung um Zugriffstasten, die F@higkeit, Formu-
lar-Kontrollelemente semantisch zu gruppieren, die F@higkeit, SELECT-Optionen semantisch
zu gruppieren, und wirkliche Labels.
· Die F@higkeit, im Markup eingebundener Objekte (mit dem OBJECT-Element) eine Text-Be-
schreibung anzugeben.
· Ein neuer Mechanismus fr clientseitige Imagemaps (MAP-Element), der Autoren gestattet,
Bild- und Textlinks zu integrieren.
· Die Forderung, dass mit dem IMG-Element eingebundene Bilder und durch das AREA-Element
eingebundene Imagemaps von alternativem Text begleitet werden.
·· Untersttzung fr title- und das lang-Attribut bei allen Elementen.
Untersttzung fr das ABBR- und das ACRONYM-Element.
·· Ein breiteres Spektrum von Zielmedien (TTY, Braille usw.) zur Nutzung mit Stylesheets.
Bessere Tabellen, die berschriften, Spaltengruppen und Mechanismen zur F=rderung
nichtvisueller Darstellung beinhalten.
· Langbeschreibungen (long descriptions) von Tabellen, Bildern, Frames usw.
Autoren, die die Aspekte der Zug@nglichkeit nicht aus den Augen verlieren w@hrend sie Seiten
gestalten, werden nicht nur den Segen der Accessibility-Gemeinschaft empfangen, sie werden
auch in anderer Form Nutzen daraus ziehen: wohlgestaltete HTML-Dokumente, die Struktur
und Pr@sentation trennen, werden sich leichter an neue Technologien anpassen.

Anmerkung: Fr mehr Informationen ber die Gestaltung zug,nglicher HTML-Dokumente lesen Sie
bitte [WAI]. n

2.3.3 Tabellen

Das neue Tabellen-Modell in HTML basiert auf [RFC1942]. Autoren haben jetzt gr=ßere Kont-
rolle ber Struktur und Layout (z. B. Spaltengruppen). Dass Designer in der Lage sind, Spalten-
breiten zu empfehlen, erlaubt es Benutzerprogrammen, Tabellendaten inkrementell (so, wie sie
eintreffen) anzuzeigen, ohne auf die vollst@ndige Tabelle warten zu mssen bevor sie sie dar-
stellen.

< 46 > Einf#hrung in HTML 4


Page size: 168,00 x 240,00 mm

Anmerkung: Einige Autorenwerkzeuge sttzen sich fr Formatierungen beim Schreiben sehr stark
auf Tabellen; das kann leicht zu Problemen bzgl. der Zug,nglichkeit fhren. n

2.3.4 Zusammengesetzte Dokumente (compound documents)

Die HTML 4.01- Spezifikation


HTML bietet jetzt einen Standard-Mechanismus zum Einbinden beliebiger Medienobjekte und
Anwendungen in HTML-Dokumente. Das OBJECT-Element untersttzt (zusammen mit seinen
spezifischeren Vorfahren IMG und APPLET) einen Mechanismus zum Einbinden von Bild-, Video-,
Sound-, mathematischen, besonders spezialisierten Anwendungen und anderen Objekten in ein
Dokument. Es gestattet Autoren auch, fr Benutzerprogramme, die eine bestimmte Darstel-
lung nicht untersttzen, eine Hierarchie alternativer Darstellungen vorzugeben.

2.3.5 Stylesheets

Stylesheets vereinfachen das HTML-Markup und entlasten HTML erheblich von der Verant-
wortung fr die Pr@sentation. Sie geben sowohl Autoren als auch Nutzern Kontrolle ber die
Pr@sentation von Dokumenten – ber Schriftarten, Ausrichtungen, Farben usw.
Style-Informationen k=nnen fr einzelne Elemente oder Gruppen von Elementen angegeben
werden. Style-Informationen k=nnen innerhalb eines HTML-Dokuments oder in externen
Stylesheets angegeben werden.
Der Mechanismus der Zuordnung eines Stylesheets zu einem Dokument ist unabh@ngig von
der Stylesheet-Sprache.
Vor dem Erscheinen der Stylesheets hatten Autoren eingeschr@nkte Kontrolle ber die Dar-
stellung. HTML 3.2 beinhaltete eine Anzahl von Attributen und Elementen, die Kontrolle ber
Ausrichtung, Schriftgr=ße und Textfarbe anboten. Die Autoren nutzten darber hinaus Tabel-
len und Graphiken als Layout-Hilfsmittel. Es wird eine verh@ltnism@ßig lange Zeit dauern, bis
die Benutzer ihre Browser ersetzt haben, d. h., diese Features werden noch fr einge Zeit Ver-
wendung finden. Wie dem auch sei, da Stylesheets m@chtigere Pr@sentations-Mechanismen bie-
ten, wird das World Wide Web Consortium letzten Endes viele der HTML-Pr@sentationsele-
mente und -attribute nach und nach zurckziehen. In der gesamten Spezifikation sind die
gef@hrdeten Elemente und Attribute als „missbilligt“ (siehe Abschnitt 4) gekennzeichnet. Sie
werden begleitet von Beispielen, die zeigen, wie derselbe Effekt mit anderen Elementen oder
Stylesheets zu erreichen ist.

2.3.6 Scripting

Mit Hilfe von Skripten k=nnen Autoren dynamische Webseiten gestalten (z. B. „Intelligente For-
mulare“ („Smart Forms“), die reagieren, wenn Benutzer sie ausfllen) und HTML als Werkzeug
verwenden, um Netz-Applikationen zu bauen.

Anmerkung der bersetzer: „Intelligent“ sind Formulare dann, wenn sie bereits
beim Ausfllen auf Eingaben des Benutzers reagieren, z. B. Werte auf Zul@ssigkeit hin
prfen, Formularfelder in Abh@ngikeit von in anderen Feldern eingetragenen Werten
vorbelegen usw. Da das bereits auf dem Client passiert, werden Formulare deutlich
benutzerfreundlicher. Als Autor sollte man aber stets daran denken, dass zwingend not-
wendige Prfungen eingegebener Werte nicht ausschließlich durch clientseitige Skripte

HTML 4 < 47 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

erfolgen sollten. Ein Formular soll auch dann benutzbar sein, wenn Scripting nicht zur
Verfgung steht, sei es, weil der Browser Scripting generell oder fr die gew@hlte
Skriptsprache nicht untersttzt, sei es, weil der Benutzer Scripting deaktiviert hat.
Die HTML 4.01- Spezifikation

Die zum Einbinden von Skripten angebotenen Mechanismen sind unabh@ngig von der Skript-
sprache.

2.3.7 Drucken

Manchmal werden Autoren wnschen, es Benutzern leicht zu machen, mehr als nur das aktu-
elle Dokument zu drucken. Wenn Dokumente Teil einer gr=ßeren Arbeit sind, kann der
Zusammenhang zwischen ihnen durch das HTML-LINK-Element oder mit Hilfe des „Resource
Description Framework (RDF)“ (s. [RDF10]) vom W3C beschrieben werden.

2.4 Dokumente erstellen mit HTML 4


Wir empfehlen, dass Autoren und Entwickler die folgenden allgemeinen Regeln beachten, wenn
sie mit HTML 4 arbeiten.

2.4.1 Trennen von Struktur und Pr.sentation

HTML hat seine Wurzeln in SGML, das stets eine Sprache zur Spezifikation strukturierter Aus-
zeichnungen war. So wie sich HTML entwickelt, werden mehr und mehr seiner Pr@sentations-
elemente und -attribute durch andere Mechanismen ersetzt werden, insbesondere durch Style-
sheets. Die Entwicklung hat gezeigt, dass die Trennung der Struktur eines Dokuments von sei-
nen Pr@sentationsaspekten die Kosten fr die Bedienung eines breiten Spektrums von Plattfor-
men, Medien usw. reduziert und die berarbeitung von Dokumenten erleichtert.

2.4.2 Allgemeine Zug.nglichkeit zum Web beachten

Um das Web zug@nglicher fr jedermann zu machen, insbesondere fr jene Personen mit
Behinderungen, sollten Autoren darber nachdenken, wie ihre Dokumente auf verschiedenen
Plattformen dargestellt werden k=nnten wie z. B. durch sprachbasierte Browser, Braille-Leser
usw. Wir fordern nicht etwa dazu auf, dass Autoren ihre Kreativit@t einschr@nken, sondern
lediglich, dass sie alternative Darstellungen in ihrem Design bedenken. HTML bietet eine Anzahl
von Mechanismen dafr (z. B. das alt-Attribut, das accesskey-Attribut usw.)
Darber hinaus sollten Autoren bedenken, dass ihre Dokumente ein weit entferntes Publikum
mit anderen Computer-Konfigurationen erreichen k=nnten. Damit Dokumente korrekt inter-
pretiert werden, sollten Autoren in ihre Dokumente Informationen ber die natrliche Spra-
che und die Leserichtung des Textes aufnehmen, darber, wie das Dokument kodiert ist, und
ber andere Aspekte, die im Zusammenhang mit der Internationalisierung stehen.

< 48 > Einf#hrung in HTML 4


Page size: 168,00 x 240,00 mm

2.4.3 Benutzerprogrammen bei inkrementeller Darstellung helfen

Durch sorgf@ltige Gestaltung ihrer Tabellen und Einsatz der neuen Tabellen-Features von
HTML 4 k=nnen Autoren Benutzerprogrammen helfen, Dokumente schneller darzustellen.

Die HTML 4.01- Spezifikation


Autoren k=nnen lernen, wie man Tabellen fr inkrementelle Darstellung gestaltet (siehe TABLE-
Element). Entwickler sollten die „Anmerkungen zu Tabellen“ im Anhang B konsultieren, um an
Informationen zum inkrementellen Algorithmus zu kommen.

3 ber SGML und HTML


Dieser Abschnitt des Dokuments fhrt in SGML ein und er=rtert dessen Verh@ltnis zu HTML.
Eine vollst@ndige Diskussion von SGML sei dem Standard (siehe [ISO8879]) berlassen.

Anmerkung der bersetzer: HTML basiert auf SGML. Aus diesem Grund ist die
Diskussion des Verh@ltnisses in diesem Kapitel wichtig. Mittlerweile ist HTML aber von
XHTML abgel=st worden. XHTML basiert auf XML, nicht mehr auf SGML. Und obwohl
HTML inhaltlich auch heute noch ein sehr wichtiger Standard ist, sind die nachfolgenden
Ausfhrungen ber SGML fr XHTML nicht mehr uneingeschr@nkt zutreffend. Aus die-
sem Grund finden Sie im Folgenden eine Reihe von Kommentaren, die die Gltigkeit
der Aussagen aus Sicht von XHTML korrigieren.
Ein einfhrender Artikel zum Thema SGML ist im Web unter http://www.mintert.com/
xml/ zu finden. An gleicher Stelle gibt es auch Einfhrungen in XML. Eine deutsche
bersetzung des XML-Standards (http://www.edition-w3c.de/TR/REC-xml) ist ebenso
wie eine deutsche bersetzung von XHTML (http://www.edition-w3c.de/TR/xhtml1)
als Teil des deutschen W3C- bersetzungsprojekts entstanden.

3.1 Einf-hrung in SGML


SGML ist ein System zur Definition von Auszeichnungssprachen. Autoren zeichnen ihre Doku-
mente durch entsprechende den Inhalt begleitende Informationen bzgl. Struktur, Pr@sentation
und Semantik aus. HTML ist ein Beispiel einer Auszeichnungssprache. Hier folgt ein Beispiel
eines HTML-Dokuments:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"


"http://www.w3.org/TR/html4/strict.dtd">
<HTML>
<HEAD>
<TITLE>Mein erstes HTML-Dokument</TITLE>
</HEAD>
<BODY>
<P>Hallo Welt!
</BODY>
</HTML>

ber SGML und HTML < 49 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Ein HTML-Dokument unterteilt sich in einen Kopf (Head) (hier zwischen <HEAD> und
</HEAD>) und einen Rumpf (Body) (hier zwischen <BODY> und </BODY>). Der Titel eines
Dokuments erscheint (zusammen mit anderen Informationen ber das Dokument) im Kopf;
der Inhalt des Dokuments steht im Rumpf. Der Rumpf in diesem Beispiel enth@lt lediglich einen
Die HTML 4.01- Spezifikation

Absatz, ausgezeichnet mit <P>.

Anmerkung der bersetzer: In den Beispielen in dieser Spezifikation werden die


Elementnamen von HTML-Elementen groß geschrieben. In HTML spielt die Klein/Groß-
schreibung keine Rolle. In XHTML sind jedoch nur noch kleine Elementnamen zul@ssig.
Aus diesem Grund sollten Sie beim Schreiben von HTML-Dokumenten immer nur die
Kleinschreibung fr Element- und Attributnamen verwenden; also <head> statt <HEAD>
usw.
Eine weitere Onderung besteht darin, dass in XHTML keine Tags weggelassen werden
drfen. Die obige Zeile <P>Hallo Welt! muss in XHTML <p>Hallo Welt!</p> lauten.

Jede in SGML definierte Auszeichnugssprache wird SGML-Anwendung genannt. Eine SGML-An-


wendung ist ganz allgemein gekennzeichnet durch:
1. Eine SGML-Deklaration. Die SGML-Deklaration spezifiziert, welche Zeichen und Begrenzer
in der Anwendung auftreten k=nnen.
2. Eine Dokumenttyp-Definition (DTD). Die DTD definiert die Syntax von Auszeichnungs-
konstrukten. Die DTD kann zus@tzliche Definitionen wie z. B. Zeichen-Entity-Referenzen
enthalten.
3. Eine Spezifikation, die die zur Auszeichnung geh=rende Semantik beschreibt. Diese Spezifi-
kation erlegt zudem Syntaxrestriktionen auf, die innerhalb der DTD nicht ausgedrckt wer-
den k=nnen.
4. Dokument-Instanzen, die Daten (Inhalt) und Auszeichnung beinhalten. Jede Instanz enth@lt
eine Referenz auf die zu ihrer Interpretation zu verwendende DTD.
Diese Spezifikation beinhaltet eine SGML-Deklaration (Abschnitt 20), drei Dokument-Typ-De-
finitionen (fr die Beschreibung dieser drei Definitionen siehe Abschnitt 7.2, „HTML-Versions-
Information“) und eine Liste von Zeichenreferenzen.

Anmerkung der bersetzer: Fr XHTML spielt das Konzept der SGML-Deklara-
tion keine Rolle mehr. Das liegt darin begrndet, dass fr alle XML-Anwendungen eine
einzige, feste SGML-Deklaration vereinbart wurde. In der Praxis kann man also einfach
davon ausgehen, dass Tags durch spitze Klammern begrenzt werden und dass es eine
Reihe von Sonderzeichen (wie &) gibt, die sp@ter erkl@rt werden.
Der Begriff der Dokumentinstanz rhrt daher, dass jedes Dokument ein Beispiel oder
ein Vertreter des Dokumenttyps ist, der durch die DTD definiert wird. Wer sich mit
objektorientierter Programmierung auskennt, wird den Begriff der Instanz kennen; der
Dokumenttyp entspricht dann der Klasse.

< 50 > ber SGML und HTML


Page size: 168,00 x 240,00 mm

3.2 In HTML verwendete SGML-Konstrukte


Die folgenden Abschnitte stellen die in HTML verwendeteten SGML-Konstrukte vor.
Im Anhang sind einige SGML-Features aufgelistet, die sich keiner breiten Untersttzung durch

Die HTML 4.01- Spezifikation


HTML-Programme erfreuen und deshalb vermieden werden sollten.

3.2.1 Elemente

Eine SGML-Dokumenttyp-Definition deklariert Elementtypen, die Strukturen oder gewnsch-


tes Verhalten repr@sentieren. HTML beinhaltet Elementtypen, die Abs@tze, Hypertext-Links,
Listen, Tabellen, Bilder usw. repr@sentieren.
Jede Elementtyp-Deklaration beschreibt im Allgemeinen drei Teile: einen Start-Tag, den Inhalt
und einen End-Tag.

Anmerkung der bersetzer: Pr@zise: Die Elementtyp-Deklaration beschreibt


den Namen des Elementtyps sowie sein Inhaltsmodell. Der Name bestimmt wie Start-
und End-Tag aussehen.

Der Name des Elements erscheint im Start-Tag (geschrieben <Elementname>) und im End-Tag
(geschrieben </Elementname>); beachten Sie den Schr@gstrich vor dem Elementnamen im End-
Tag. Zum Beispiel begrenzen Start- und End-Tag des Elementtyps UL die Aufz@hlungspunkte in
einer Liste:

<UL>
<LI><P>...Punkt.1...
<LI><P>...Punkt.2...
</UL>

Einige HTML-Elementtypen erlauben Autoren, die End-Tags wegzulassen (z. B. die Element-
typen P und LI). Einige wenige Elemementtypen gestatten auch das Weglassen der Start-Tags,
z. B. HEAD und BODY. Die HTML-DTD gibt fr jeden Elementtyp vor, ob Start- und End-Tag erfor-
derlich sind oder nicht.

Anmerkung der bersetzer: Wie oben schon gesagt, mssen Elemente in


XHTML sowohl Start- als auch End-Tag besitzen. Kein Tag darf weggelassen werden.

Einige HTML-Elementtypen haben keinen Inhalt. Zum Beispiel hat das Zeilenwechsel-Element
BR keinen Inhalt; seine einzige Funktion besteht darin, eine Textzeile zu begrenzen. Solche lee-
ren Elemente haben nie End-Tags. Die Dokumenttyp-Definition und der Text der Spezifikation
geben vor, ob ein Elementtyp leer ist (keinen Inhalt hat) oder, wenn er Inhalt haben kann, was
als zul@ssiger Inhalt betrachtet wird.

In HTML verwendete SGML-Konstrukte < 51 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Anmerkung der bersetzer: Die Forderung, dass leere Elemente niemals einen
End-Tag besitzen drfen, ist weder durch SGML noch (fr XHTML) durch XML begrn-
det. Es ist eine Festlegung dieser Spezifikation.
Die HTML 4.01- Spezifikation

Die nachfolgende Aussage bzgl. der Klein/Großschreibung gilt nicht mehr fr XHTML.
Auch die anschließenden Beispiele sind nur fr HTML, nicht jedoch fr XHTML richtig
und sollten unter diesem Blickwinkel ignoriert werden.

Bei Elementnamen wird nie zwischen Groß- und Kleinschreibung unterschieden.


Bitte konsultieren Sie den SGML-Standard zu Informationen ber die fr Elemente geltenden
Regeln (z. B. mssen sie korrekt verschachtelt sein, ein End-Tag schließt zurck bis zum korres-
pondierenden Start-Tag alle dazwischenliegenden ungeschlossenen Start-Tags mit weggelasse-
nen End-Tags (siehe Abschnitt 7.5.1) usw.).
Zum Beispiel kann der folgende Absatz:

<P>Dies ist der erste Absatz.</P>


...ein Block-Element...

auch ohne seinen End-Tag:

<P>Dies ist der erste Absatz.


...ein Block-Element...

geschrieben werden, da der <P>-Start-Tag vom folgenen Block-Element geschlossen wird.


Gleiches gilt, wenn ein Absatz in einem Block-Element eingeschlossen ist wie in:

<DIV>
<P>Dies ist der Absatz.
</DIV>

Der End-Tag des umschließenden Block-Elements (hier </DIV>) impliziert den End-Tag des
offenen <P>-Start-Tags.
Elemente sind keine Tags. Manche Leute sprechen von Elementen als Tags (z. B. „der P-Tag“).
Denken Sie daran, dass ein Element eine Sache ist und der Tag (sei es Start- oder End-Tag) eine ande-
re. Zum Beispiel ist das HEAD-Element immer vorhanden, sogar, wenn sowohl Start- als auch End-Tag
in der Auszeichnung fehlen. n

Anmerkung der bersetzer: Die obige Bemerkung ist sehr wichtig. Tats@chlich
werden die Begriffe Tag, Element, Elementtyp immer wieder durcheinander gebracht.
HTML-Dokumente bestehen aus ineinander verschachtelten Elementen (<p>Hallo
Welt!</p>), die wiederum aus Start-Tags (<p>), End-Tags (</p>) und Inhalt (Hallo Welt!)
bestehen.
Der HTML-Dokumenttyp (festgelegt durch die DTD) deklariert die Elementtypen (hier: p).

Alle in dieser Spezifikation deklarierten Elementtypen sind im Index der Elemente aufgelistet.

< 52 > ber SGML und HTML


Page size: 168,00 x 240,00 mm

Anmerkung der bersetzer: Dieser Verweis auf den Index ist ein klassisches Bei-
spiel fr die falsch benutzte Terminologie: Natrlich ist es kein Index der Elemente.
Wie sollte das auch m=glich sein? Die Anzahl der Elemente ist potenziell unbegrenzt

Die HTML 4.01- Spezifikation


(n@mlich die Summe aller HTML-Elemente, die alle HTML-Dateien berall auf der Welt
enthalten). Der Verweis zeigt auf den Index der Elementtypen.

3.2.2 Attribute

Elemente k=nnen zugeh=rige Eigenschaften haben, genannt Attribute, diese k=nnen Werte
besitzen (standardm@ßig oder von Autoren oder Skripten gesetzt). Attribut-Wert-Paare
erscheinen vor „>“ des Start-Tags eines Elements. Im Start-Tag eines Elements kann eine belie-
bige Anzahl von durch Zwischenraum getrennten (zul@ssigen) Attribut-Wert-Paaren stehen.
Sie k=nnen beliebig angeordnet sein.
In diesem Beispiel ist das id-Attribut fr ein H1-Element gesetzt:

<H1 id="section1">
This is an identified heading thanks to the id attribute
</H1>

Standardm@ßig verlangt SGML, dass alle Attributwerte entweder von doppelten Anfhrungszei-
chen (ASCII dezimal 34) oder einfachen Anfhrungszeichen (ASCII dezimal 39) begrenzt wer-
den. Einfache Anfhrungszeichen k=nnen im Attributwert enthalten sein, wenn der Wert durch
doppelte Anfhrungszeichen begrenzt ist und umgekehrt. Autoren k=nnen auch Numerische
Zeichenreferenzen verwenden, die die doppelten (&#34;) und einfachen (&#39;) Anfhrungs-
zeichen repr@sentieren. Fr doppelte Anfhrungszeichen drfen Autoren auch die Zeichen-En-
tity-Referenz „&quot;“ benutzen.
In bestimmten F@llen k=nnen Autoren den Wert eines Attributs ohne jegliche Anfhrungszei-
chen angeben; der Attributwert darf nur Buchstaben (a-z und A-Z), Ziffern (0-9), Bindestriche
(ASCII dezimal 45), Punkte (ASCII dezimal 46), Unterstriche (ASCII dezimal 95) und Doppel-
punkte (ASCII dezimal 58) enthalten. Wir empfehlen, Anfhrungszeichen auch dann zu verwen-
den, wenn es m=glich ist, sie wegzulassen.

Anmerkung der bersetzer: Wir empfehlen die Anfhrungszeichen niemals weg-


zulassen. In XHTML ist das Weglassen nicht mehr zul@ssig. Fr die Groß/Kleinschrei-
bung gilt das Gleiche wie fr Elemente.

Bei Attributnamen wird nie zwischen Groß- und Kleinschreibung unterschieden. Die Definition
eines jeden Attributs gibt an, ob bei seinem Wert zwischen Groß- und Kleinschreibung unter-
schieden wird.
Alle durch diese Spezifikation definierten Attribute sind im Index der Attribute aufgelistet.

In HTML verwendete SGML-Konstrukte < 53 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Anmerkung der bersetzer: Es handelt sich um den Index der Attributtypen.


Die HTML 4.01- Spezifikation

3.2.3 Zeichenreferenzen

Zeichenreferenzen sind numerische oder symbolische Namen fr Zeichen, die in einem HTML-
Dokument enthalten sein k=nnen. Sie sind ntzlich fr selten verwendete Zeichen oder solche,
die in Authoring Tools nur schwer oder gar nicht eingegeben werden k=nnen. Sie werden Zei-
chenreferenzen berall in diesem Dokument sehen; sie beginnen mit einem „&“-Zeichen und
enden mit einem Semikolon (;). Bekannte Beispiele sind:
·· „&lt;“ steht fr das <-Zeichen.
„&gt;“ steht fr das >-Zeichen.
·· „&quot;“ steht fr das doppelte "-Zeichen.
„&#229;“ (dezimal) steht fr den Buchstaben „a“ mit einem kleinen Kreis darber.
·· „&#1048;“ (dezimal) steht fr den kyrillischen Großbuchstaben „I“.
„&#x6C34;“ (hexadezimal) steht fr das chinesische Zeichen fr Wasser.
Wir er=rtern HTML-Zeichenreferenzen sp@ter in Abschnitt 5.1, „Dokument-Zeichensatz“ im
Detail. Die Spezifikation enth@lt auch eine Liste der Zeichenreferenzen (siehe Abschnitt 24),
die in HTML 4-Dokumenten auftauchen k=nnen.

3.2.4 Kommentare

HTML-Kommentare haben folgende Syntax:

<!- - dies ist ein Kommentar - ->


<!- - und das hier ist einer,
der mehr als eine Zeile belegt - ->

Leerraum (white space) ist nicht gestattet zwischen dem =ffnenden Begrenzer der Auszeich-
nungsdeklaration (markup declaration open delimiter) („<!“) und dem =ffnenden Begrenzer
des Kommentars (comment open delimiter) („- -“); er ist jedoch zul@ssig zwischen dem schlie-
ßenden Begrenzer des Kommentars (comment close delimiter) („- -“) und dem schließenden
Begrenzer der Auszeichnungsdeklaration („>“). Ein h@ufiger Fehler ist es, in einen Kommentar
eine Kette von Bindestrichen („- --“) einzuschließen. Autoren sollten vermeiden, zwei oder
mehr aufeinanderfolgende Bindestriche innerhalb von Kommentaren zu schreiben.
Information, die in Kommentaren erscheint, hat keine spezielle Bedeutung (z. B. werden Zei-
chenreferenzen nicht als solche interpretiert).
Beachten Sie, dass Kommentare Auszeichnungen sind.

3.3 Wie die HTML-DTD zu lesen ist


Jede Element- und Attributdeklaration in dieser Spezifikation wird begleitet von ihrem Auszug
aus der document type definition. Wir haben uns entschlossen, die DTD-Auszge in die Spezifi-
kation aufzunehmen, anstatt eine zwar besser zug@ngliche, aber dafr l@ngere und weniger pr@-

< 54 > ber SGML und HTML


Page size: 168,00 x 240,00 mm

zise Beschreibung der Eigenschaften eines Elements zu versuchen. Das folgende Tutorial sollte
es mit SGML nicht vertrauten Lesern gestatten, die DTD zu lesen und die technischen Details
der HTML-Spezifikation zu verstehen.

Die HTML 4.01- Spezifikation


3.3.1 DTD-Kommentare

In DTDs k=nnen sich Kommentare ber mehrere Zeilen erstrecken. In der DTD sind Kom-
mentare durch ein Paar von „- -“-Marken begrenzt, z. B.

<!ELEMENT PARAM - O EMPTY - - named property value - ->

Hier erkl@rt der Kommentar „named property value“ die Verwendung des PARAM-Elementtyps.
Kommentare in der DTD haben lediglich informellen Charakter.

Anmerkung der bersetzer: Diese Art des Kommentierens von DTDs ist mit
XML nicht mehr m=glich. Folglich wird man eine Zeile wie die obige in der XHTML-
DTD nicht mehr finden. Eine Alternative ist etwa:

<!ELEMENT param EMPTY> <!- - named property value - ->

3.3.2 Parameter-Entity-Definitionen

Die HTML-DTD beginnt mit einer Serie von Parameter-Entity-Definitionen. Eine Parameter-
Entity-Definition definiert eine Art Makro, das irgendwo in der DTD angesprochen und refe-
renziert werden kann. Diese Makros erscheinen nicht in HTML-Dokumenten, lediglich in der
DTD. Andere Makrotypen, genannt Zeichenreferenzen, k=nnen im Text eines HTML-Doku-
ments oder in Attributwerten erscheinen.
Wird das Parameter-Entity in der DTD ber den Namen angesprochen, so wird es in eine Zei-
chenkette (string) aufgel=st.
Eine Parameter-Entity-Definition beginnt mit dem Schlsselwort <!ENTITY % gefolgt vom Entity-
Namen, dann der in Anfhrungszeichen eingeschlossenen Zeichenkette, zu der das Entity auf-
gel=st wird, und letzlich der schließenden Klammer >. Die Benutzung eines Parameter-Entity in
einer DTD beginnt mit „%“, gefolgt vom Parameter-Entity-Namen und optional dem abschlie-
ßenden „;“.
Das folgende Beispiel definiert die Zeichenkette, in die das „%fontstyle;“-Entity aufgel=st wird.

<!ENTITY % fontstyle "TT | I | B | BIG | SMALL">

Die Zeichenkette, in die das Parameter-Entity aufgel=st wird, kann andere Parameter-Entity-
Namen enthalten. Diese Namen werden rekursiv aufgel=st. Im folgenden Beispiel ist das „%inli-
ne;“-Parameter-Entity so definiert, dass es die „%fontstyle;“-, „%phrase;“-, „%special;“- und
„%formctrl;“- Parameter enth@lt.

<!ENTITY % inline "#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;">

Wie die HTML-DTD zu lesen ist < 55 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Zwei DTD-Entities werden Ihnen h@ufig in der HTML-DTD begegnen: „%block;“ und „%inli-
ne;.“ Sie werden verwendet, wenn das Inhaltsmodell Block-Level- bzw. Inline-Elemente umfasst
(definiert in Abschnitt 7, „Die globale Struktur eines HTML-Dokuments“).
Die HTML 4.01- Spezifikation

3.3.3 Elementdeklarationen

Der Hauptteil der HTML-DTD besteht aus den Deklarationen von Elementtypen und deren
Attribute. Das <!ELEMENT-Schlsselwort beginnt eine Deklaration und das >-Zeichen
beschließt sie. Dazwischen sind spezifiziert:
1. Der Name des Elements
2. Ob die Tags des Elements optional sind. Erscheinen zwei Bindestriche hinter dem Element-
namen, so heißt das, Start- und End-Tag sind vorgeschrieben. Ein Bindestrich, gefolgt vom
Buchstaben „O“ bedeutet, der End-Tag kann weggelassen werden. Zwei „O“s zeigen an,
dass sowohl Start- als auch End-Tag weggelassen werden k=nnen (o = omit).
3. Der Inhalt des Elements, so vorhanden. Der erlaubte Inhalt eines Elements wird dessen
Inhaltsmodell genannt. Elementtypen, die dafr angelegt sind, keinen Inhalt zu haben, wer-
den Leere Elemente genannt. Das Inhaltsmodell fr so ein Element ist durch die Verwen-
dung des Schlsselwortes „EMPTY“ deklariert.

Anmerkung der bersetzer: Der zweite Punkt, der sich mit dem Weglassen von
Start- und/oder End-Tags besch@ftigt, ist fr XML und damit XHTML nicht mehr rele-
vant.

In diesem Beispiel:

<!ELEMENT UL - - (LI)+>

·· Der deklarierte Elementtyp ist UL.


Die beiden Bindestriche bedeuten, dass sowohl der Start-Tag <UL> als auch der End-Tag
</UL> fr dieses Element erforderlich sind.
· Das Inhaltsmodell fr diesen Elementtyp ist deklariert, „mindestens ein LI-Element“ zu sein.
Weiter unten erkl@ren wir, wie Inhaltsmodelle zu spezifizieren sind.
Dieses Beispiel zeigt die Deklarierung eines leeren Elementtyps:

<!ELEMENT IMG - O EMPTY>

·· Der Elementtyp, der deklariert wird, ist IMG.


Der Bindestrich und das folgende „O“ geben an, dass der End-Tag weggelassen werden
kann, aber zusammen mit dem Inhaltsmodell „EMPTY“ ist es verst@rkend fr die Regel, dass
der End-Tag weggelassen werden muss.
· Das „EMPTY“-Schlsselwort besagt, dass die Instanz dieses Typs keinen Inhalt haben darf.

< 56 > ber SGML und HTML


Page size: 168,00 x 240,00 mm

Inhaltsmodell-Definitionen
Das Inhaltsmodell beschreibt, was in einer Instanz eines Elementtyps enthalten sein kann.
Inhaltsmodell-Definitionen k=nnen beinhalten:
· Die Namen von erlaubten oder verbotenen Elementtypen (z. B. enth@lt das UL-Element

Die HTML 4.01- Spezifikation


Instanzen des LI-Elementtyps, und der P-Elementtyp darf keine anderen P-Elemente enthal-
ten)
·· DTD-Entities (z. B. enth@lt das LABEL-Element Instanzen des „%inline;“-Parameter-Entities)
Dokument-Text (angezeigt durch das SGML-Konstrukt „#PCDATA“). Text kann Zeichen-
referenzen enthalten. Rufen Sie sich in Erinnerung, dass diese mit & beginnen und mit Semi-
kolon enden (z. B. enth@lt „Herg&eacute;'s adventures of Tintin“ die Zeichen-Entity-Refe-
renz fr das „e acute“-Zeichen).
Das Inhaltsmodell eines Elements ist spezifiziert durch die folgende Syntax. Bitte beachten Sie,
dass das Listing unten eine Vereinfachung der vollst@ndigen SGML-Syntax-Regeln ist und z. B.
Pr@zedenzen nicht ausdrckt.

( ... )
begrenzt eine Gruppe.
A
A muss genau einmal vorkommen.
A+
A muss einmal oder mehrmals vorkommen.
A?
A darf nicht oder muss einmal vorkommen.
A*
A kann nicht oder mehrmals vorkommen.
+(A)
A kann vorkommen.
-(A)
A darf nicht vorkommen.
A|B
Entweder A oder B muss vorkommen, aber nicht beide.
A,B
A und B mssen in dieser Reihenfolge vorkommen.
A&B
A und B mssen in beliebiger Reiehenfolge vorkommen.

Anmerkung der bersetzer: Die Exklusionen und Inklusionen (+(A) und -(A))
sowie der Ausdruck A & B sind in XML nicht mehr m=glich und finden sich folglich nicht
mehr in den XHTML-DTDs.

Hier einige Beispiel aus der HTML-DTD:

<!ELEMENT UL - - (LI)+>

Das UL-Element muss ein oder mehrere LI-Elemente enthalten.

Wie die HTML-DTD zu lesen ist < 57 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

<!ELEMENT DL - - (DT|DD)+>

Das DL-Element muss ein oder mehrere DT- oder DD-Elemente in beliebiger Reihenfolge enthalten.
Die HTML 4.01- Spezifikation

<!ELEMENT OPTION - O (#PCDATA)>

Das OPTION-Element kann nur Text und Entities wie &amp; enthalten – dies wird durch den
SGML-Daten-Typ #PCDATA angezeigt.
Ein paar HTML-Elementtypen verwenden ein weiteres SGML-Feature, um Elemente von ihrem
Inhaltsmodell auszuschließen. Ausgeschlossenen Elementen wird ein Bindestrich vorangestellt.
Expliziter Ausschluss berschreibt erlaubte Elemente.
In diesem Beispiel sagt -(A), dass das Element A nicht in einem anderen A-Element vorkommen
kann (d. h., Anker k=nnen nicht verschachtelt werden).

<!ELEMENT A - - (%inline;)* -(A)>

Beachten Sie, dass der A-Elementtyp Teil des DTD-Parameter-Entities „%inline;“ ist, jedoch
durch -(A) explizit ausgeschlossen wird.

Anmerkung der bersetzer: Da es diese Ausschlussm=glichkeit (-(A)) in XML


und damit in XHTML nicht mehr gibt, msste, um die gleiche Definition des Inhalts-
modells zu erzielen, eine explizite Definition ohne das Element A erfolgen. Hierzu
msste also das Parameter-Entity %inline; umdefiniert werden, oder es k=nnte hier
nicht zum Einsatz kommen.

Enstprechend verbietet die folgende Elementtyp-Deklaration fr FORM verschachtelte Formulare:

<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM)>

3.3.4 Attributdeklarationen

Mit dem <!ATTLIST-Schlsselwort beginnt die Deklaration von Attributen, die ein Element
erhalten kann. Ihm folgen der Name des in Frage kommenden Elements, eine Liste von Attri-
butdefinitionen und ein abschließendes >. Jede Attributdefinition ist ein Triplet, das Folgendes
definiert:
·· Den Namen des Attributs.
Den Typ des Attributwertes oder einen expliziten Satz m=glicher Werte. Explizit durch die
DTD definierte Werte unterscheiden nicht zwischen Groß- und Kleinschreibung. Bitte
konsultieren Sie den Abschnitt 6, „HTML-Grunddatentypen“ fr weitere Informationen zu
Typen von Attributwerten.
· Ob der Standardwert des Attributs implizit ist (Schlsselwert „#IMPLIED“), in welchem Fall
das Benutzerprogramm den Standardwert liefern muss (in einigen F@llen durch Ableitung
von Eltern-Elementen), stets erforderlich ist (keyword „#REQUIRED“) oder auf den ange-
gebenen Wert fixiert (keyword „#FIXED“) ist. Einige Attributdefinitionen spezifizieren
explizit einen Standardwert fr die Attribute.

< 58 > ber SGML und HTML


Page size: 168,00 x 240,00 mm

Anmerkung der bersetzer: Der Wert #IMPLIED bedeutet so viel wie „optional“.

Die HTML 4.01- Spezifikation


In diesem Beispiel ist das name-Attribute fr das MAP-Element definiert. Das Attribut ist fr die-
ses Element optional.

<!ATTLIST MAP
name CDATA #IMPLIED
>

Der Typ der erlaubten Werte ist als CDATA, einem SGML-Datentyp, angegeben. CDATA ist
Text, der Zeichenreferenzen (siehe Abschnitt 5.3) enthalten kann.
Fr weitere Informationen zu „CDATA“, „NAME“, „ID“ und andere Datentypen lesen Sie bitte
im Abschnitt 6, „HTML-Grunddatentypen“ nach.
Das folgende Beispiel zeigt mehrere Attributdefinitionen:

rowspan NUMBER 1 - - number of rows spanned by cell - -


http-equiv NAME #IMPLIED - - HTTP response header name - -
id ID #IMPLIED - - document-wide unique id - -
valign (top|middle|bottom|baseline) #IMPLIED

Das rowspan-Attribut verlangt Werte vom Typ NUMBER. Der Standardwert ist explizit als „1“
gegeben. Das optionale http-equiv-Attribut verlangt Werte vom Typ NAME. Das optionale id-
Attribut verlangt Werte vom Typ ID. Das optionale valign-Attribut ist gezwungen, Werte aus
der Menge {top, middle, bottom, baseline} anzunehmen.

DTD-Entities in Attributdefinitionen
Attributdefinitionen k=nnen auch Parameter-Entity-Referenzen enthalten.
In diesem Beispiel sehen wir, dass die Attributdefinitionsliste fr das LINK-Element mit dem
„%attrs;“-Parameter-Entity beginnt.

<!ELEMENT LINK - O EMPTY - - a media-independent link - ->


<!ATTLIST LINK
%attrs; -- %coreattrs, %i18n, %events - -
charset %Charset; #IMPLIED -- char encoding of linked resource - -
href %URI; #IMPLIED -- URI for linked resource - -
hreflang %LanguageCode; #IMPLIED -- language code - -
type %ContentType; #IMPLIED -- advisory content type - -
rel %LinkTypes; #IMPLIED -- forward link types - -
rev %LinkTypes; #IMPLIED -- reverse link types - -
media %MediaDesc; #IMPLIED -- for rendering on these media - -
>

Start-Tag: erforderlich, End-Tag: verboten


Das „%attrs;“-Parameter-Entity ist folgendermaßen definiert:

<!ENTITY % attrs "%coreattrs; %i18n; %events;">

Wie die HTML-DTD zu lesen ist < 59 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Das „%coreattrs;“-Parameter-Entity in der „%attrs;“-Definition wird wie folgt aufgel=st:

<!ENTITY % coreattrs
"id ID #IMPLIED -- document-wide unique id - -
class CDATA #IMPLIED -- space-separated list of classes - -
Die HTML 4.01- Spezifikation

style %StyleSheet; #IMPLIED -- associated style info - -


title %Text; #IMPLIED -- advisory title - -"
>

Das „%attrs;“-Parameter-Entity wurde aus Bequemlichkeit definiert, weil diese Attribute fr
die meisten HTML-Elementtypen definiert sind.
Ohnlich definiert die DTD den „%URI;“-Parameter-Entity als aufzul=sen in die Zeichenkette
„CDATA“.

<!ENTITY % URI "CDATA"


- - a Uniform Resource Identifier,
see [URI]
- ->

Wie dieses Beispiel zeigt, versorgt das Paramater-Entity „%URI;“ Leser der DTD mit mehr
Information als fr ein Attribut zu dem Datentyp erwartet werden. Ohnlich wurden Entities fr
„%Color;“, „%Charset;“, „%Length;“, „%Pixels;“ usw. definiert

Boolesche Attribute
Einige Attribute spielen die Rolle boolescher Variablen (z. B. das selected-Attribut fr das OPTI-
ON-Element). Ihr Auftauchen im Start-Tag eines Elements impliziert, dass der Wert des Attri-
buts „wahr“ (true) ist; ihr Fehlen impliziert den Wert „falsch“ (false).
Boolesche Attribute k=nnen nur einen zul@ssigen Wert annehmen: den Namen des Attributs
selbst (z. B. selected="selected").
Dieses Beispiel definiert das selected-Attribut als boolesches Attribut.

selected (selected) #IMPLIED - - option is pre-selected - -

Das Attribut wird bei Auftauchen im Start-Tag des Elements auf „wahr“ gesetzt:

<OPTION selected="selected">
...Inhalt...
</OPTION>

In HTML k=nnen boolesche Attribute in minimierter Form auftreten – der Wert des Attributs
erscheint allein im Start-Tag des Elelements. So kann selected gesetzt werden, indem man
schreibt:

<OPTION selected>

anstatt:

<OPTION selected="selected">

< 60 > ber SGML und HTML


Page size: 168,00 x 240,00 mm

Autoren sollte bewusst sein, dass viele Benutzerprogramme nur die minimierte Form erken-
nen, nicht aber die vollst@ndige Form.

Anmerkung der bersetzer: Die minimierte Form ist in XHTML nicht mehr

Die HTML 4.01- Spezifikation


zul@ssig.

4 Konformit.t: Anforderungen und


Empfehlungen
Mit diesem Abschnitt beginnen wir die HTML-Spezifikation anfangend mit der bereinkunft
zwischen Autoren, Dokumenten, Benutzern und Benutzerprogrammen.
Die Schlsselw=rter „MUSS“ („MUST“), „DARF NICHT“ („MUST NOT“), „ERFORDERLICH“
(„REQUIRED“), „SOLL“ („SHALL“), „SOLL NICHT“ („SHALL NOT“), „SOLLTE“
(„SHOULD“), „SOLLTE NICHT“ („SHOULD NOT“), „EMPFOHLEN“ („RECOMMENDED“),
„KANN“ („MAY“) und „OPTIONAL“ in diesem Dokument sind, wie in [RFC2119] beschrie-
ben, zu verstehen. Der besseren Lesbarkeit wegen erscheinen die W=rter in dieser Spezifika-
tion jedoch nicht in Großbuchstaben.
Gelegentlich geben die Autoren dieser Spezifikation praktische Empfehlungen fr Autoren und
Benutzerprogramme. Diese Empfehlungen sind nicht normativ; die Konformit@t mit der Spezifi-
kation ist nicht abh@ngig von ihrer Umsetzung. Diese Empfehlungen enthalten Formulierungen
wie „Wir empfehlen ...“, „Diese Spezifikation empfiehlt ...“ oder verwenden einen @hnlichen
Wortlaut.

4.1 Definitionen
HTML-Dokument
Ein HTML-Dokument ist ein SGML-Dokument, das den Beschr@nkungen dieser Spezifika-
tion gerecht wird.
Autor
Ein Autor ist eine Person oder ein Programm, die/das HTML-Dokumente schreibt oder
generiert. Bei einem Autorenwerkzeug handelt es sich um einen speziellen Autor, n@mlich
um ein Programm, das HTML generiert.
Wir empfehlen Autoren, lieber zur Strict-DTD konforme Dokumente zu schreiben als zu
anderen durch diese Spezifikation definierten DTDs. Details ber die in HTML 4 definierten
DTDs finden Sie im Abschnitt 7.2, „HTML-Versionsinformation“.
Benutzer
Ein Benutzer ist eine Person, die mit einem Benutzerprogramm interagiert, um ein dar-
gestelltes HTML-Dokument zu sehen, zu h=ren oder auf andere Art zu nutzen.

Konformit,t: Anforderungen und Empfehlungen < 61 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

HTML-Benutzerprogramm
Ein HTML-Benutzerprogramm ist jede Vorrichtung, die HTML-Dokumente interpretiert.
Zu den Benutzerprogrammen geh=ren visuelle Browser (Text- und graphische Browser),
nicht-visuelle Browser (Audio, Braille), Suchmaschinen, Proxies und so weiter.
Die HTML 4.01- Spezifikation

Ein zu HTML 4 konformes Benutzerprogramm ist eines, das die in dieser Spezifikation
dargelegten zwingenden Bedingungen („muss“) einschließlich der folgenden Punkte beach-
tet:
· Ein Benutzerprogramm sollte vermeiden, literalen Attributwerten irgendwelche L@ngen-
beschr@nkungen aufzuerlegen (siehe Passage zu „Capacities“ in Abschnitt 20, „SGML-De-
klaration“). Einfhrende Informationen zu SGML-Attributen sind im Abschnitt 3.3.4, „At-
tributdeklarationen“ zu finden.
· Ein Benutzerprogramm muss sicherstellen, dass die Darstellung nicht davon beeinflusst
wird, ob Start- und End-Tags vorhanden oder nicht vorhanden sind, wenn die HTML-
DTD diese als optional angibt. Einfhrende Informationen ber SGML-Elemente finden
Sie im Abschnitt 3.3.3, „Elementdeklarationen“.
· Aus Grnden der Abw@rtskompatibilit@t empfehlen wir, dass Tools, die HTML 4 inter-
pretieren, auch weiterhin HTML 3.2 (siehe [HTML32]) und HTML 2.0 (siehe
[RFC1866]) untersttzen.
Fehlerbedingungen
Empfehlungen fr Reaktionen auf Fehler finden Sie in den „Anmerkungen zu ungltigen
Dokumenten“ im Anhang B.
Missbilligt
Ein missbilligtes Element oder Attribut ist eines, das durch neuere Konstrukte berholt
wurde. Missbilligte Elemente werden im Referenzhandbuch an den entsprechenden Stellen
definiert, sind aber deutlich als missbilligt gekennzeichnet. Missbilligte Elemente k=nnen in
zuknftigen Versionen von HTML obsolet sein.
Aus Grnden der Abw@rtskompatibilit@t sollten Benutzerprogramme auch weiterhin miss-
billigte Elemente untersttzen.
Die Definitionen von Elementen und Attributen bringen klar zum Ausdruck, welche von
ihnen missbilligt werden.
Diese Spezifikation enth@lt Beispiele, die zeigen, wie die Verwendung missbilligter Elemente
vermieden werden kann. In den meisten F@llen setzt das Stylesheet-Untersttzung der
Benutzerprogramme voraus. Um Stil- und Gestaltungseffekte zu erzielen, sollten Autoren
im Allgemeinen eher Stylesheets verwenden als HTML-Pr@sentationsattribute. HTML-
Pr@sentationsattribute werden missbiligt seit Stylesheet-Alternativen existieren (s. z. B.
[CSS1]).
Obsolet
Ein obsoletes Element oder Attribut ist eines, fr dessen Untersttzung durch ein Benut-
zerprogramm es keine Garantie gibt. Obsolete Elemente werden in dieser Spezifikation
nicht mehr definiert, sind jedoch aus historischen Grnden in den „Onderungen“ im Anhang
A des Referenzhandbuches aufgelistet.

< 62 > Konformit,t: Anforderungen und Empfehlungen


Page size: 168,00 x 240,00 mm

4.2 SGML
HTML 4 ist eine zur internationalen Norm ISO 8879 – Standard Generalized Markup Language
SGML (definiert in [ISO8879]) konforme SGML-Anwendung .

Die HTML 4.01- Spezifikation


Beispiele im Text sind konform zur Strict-Dokumenttyp-Definiton, es sei denn, das fragliche Bei-
spiel bezieht sich auf Elemente oder Attribute, die nur in der Transitional-Dokumenttyp-Definiton
oder der Frameset-Dokumenttyp-Definiton definiert sind. Um der Krze willen beginnen die meis-
ten Beispiele nicht mit der am Anfang eines HTML-Dokuments vorgeschriebenen Dokument-
typ-Deklaration.
DTD-Fagmente in Elementdefinitionen stammen mit Ausnahme der Elemente, die sich auf
Frames beziehen, aus der Strict-Dokumenttyp-Definiton.
Zu Details, wann die Strict-, Transitional- oder Frameset-DTD zu verwenden ist, lesen Sie bitte
die HTML-Versionsinformation.
In der HTML 4-DTD erscheinende Kommentare haben keine normative Bedeutung, sondern
lediglich informellen Charakter.
Benutzerprogramme drfen SGML-Verarbeitungsanweisungen (z. B. <?full volume>) oder
Kommentare nicht darstellen. Fr weitere Informationen ber dieses und andere SGML-Featu-
res, die in HTML zul@ssig sein k=nnen, aber von Benutzerprogrammen weitgehend nicht unter-
sttzt werden, lesen Sie bitte den Abschnitt „SGML-Eigenschaften mit begrenzter Unterstt-
zung“ im Anhang B.

4.3 Inhaltstyp (Content-Type) text/html


HTML-Dokumente werden als Byte-Sequenzen ber das Internet versandt; begleitet werden
diese von Kodierungsinformationen (beschrieben im Abschnitt 5.2, „Zeichenkodierungen“).
Die Struktur der Sendung, bezeichnet als Nachrichteneinheit, ist definiert durch [RFC2045]
und [RFC2616]. Eine Nachrichteneinheit mit einem Inhaltstyp „text/html“ (s. Abschnitt 6.7)
repr@sentiert ein HTML-Dokument.
Der Inhaltstyp fr HTML-Dokumente ist folgendermaßen definiert:

Inhaltstyp-Name:
text
Inhalts-Sub-Typ-Name:
html
Erforderliche Parameter:
keine
Optionale Parameter:
charset
Dekodierungs-Einschrnkungen:
jede Dekodierung ist erlaubt
Sicherheits-Einschrnkungen:
siehe „Anmerkungen zur Sicherheit“ im Anhang B

Der optionale Parameter „charset“ verweist auf die Zeichenkodierung, die verwendet wird,
um das HTML-Dokument als Bytesequenz darzustellen. Gltige Werte fr diesen Parameter
sind im Abschnitt 5.2, „Zeichenkodierungen“ definiert. Obwohl dieser Parameter optional ist,
empfehlen wir, ihn stets zu setzen.

SGML < 63 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

5 Repr.sentation von
HTML-Dokumenten
Die HTML 4.01- Spezifikation

In diesem Kapitel er=rtern wir, wie HTML-Dokumente auf einem Computer und ber das
Internet repr@sentiert werden.

Anmerkung der bersetzer: Unter der „Repr@sentation“ ist hier Folgendes zu


verstehen: Ein HTML-Dokument wird in irgendeiner Form auf dem Rechner
gespeichert und in irgendeiner Form ber das Internet bertragen. In diesem Kapi-
tel geht es nun um diese Form: Wie „sieht“ ein HTML-Dokument fr den Rechner
aus, das heißt, wie ist es auf dem Rechner repr@sentiert? Diese Frage kann auf ganz
unterschiedlichen Ebenen beantworten werden. Selbstverst@ndlich gibt es eine
bin@re Repr@sentation des Dokuments, ebenso eine byte-orientierte Darstellung.
Hier geht es nun um die Repr@sentation auf Zeichen-Ebene. Das heißt, welche Zei-
chen gibt es und wie werden diese durch Bytes dargestellt; etwa Ein-Byte-Kodie-
rung, wie ASCII (fr amerikanische Texte ausreichend) oder ISO-Latin-1 (fr die
meisten Westeurop@ischen Schriften) oder Mehr-Byte-Kodierungen, wie Unicode
(fr internationale Schriften).

Der Abschnitt ber den Dokumentzeichensatz wendet sich der Frage zu, welche abstrakten
Zeichen Teil eines HTML-Dokuments sein k=nnen. Zeichen umfassen den lateinischen Buchsta-
ben „A“, den kyrillischen Buchstaben „I“, das chinesische Zeichen fr „Wasser“ usw.
Der Abschnitt ber Zeichenkodierungen wendet sich der Frage zu, wie diese Zeichen in einer
Datei oder zur bertragung ber das Internet dargestellt werden k=nnen. Da manche Zeichen-
kodierungen nicht alle Zeichen direkt darstellen k=nnen, die ein Autor in einem Dokument
verwenden m=chte, bietet HTML andere Mechanismen, auf jedes Zeichen zu verweisen, Zei-
chenreferenzen genannt.
Weil es innerhalb der menschlichen Sprachen eine Vielzahl von Zeichen und eine große Vielfalt
der Darstellungsarten dieser Zeichen gibt, muss darauf geachtet werden, dass Dokumente von
Benutzerprogrammen rund um den Erdball verstanden werden k=nnen.

5.1 Der Dokumentzeichensatz


Um die Interoperabilit@t zu untersttzen, fordert SGML, dass jede Anwendung (einschl. HTML)
ihren Dokumentzeichensatz spezifiziert. Ein Dokumentzeichensatz besteht aus Folgendem:
· Einem Vorrat: Ein Satz abstrakter Zeichen wie der lateinische Buchstabe „A“, der kyrillische
Buchstabe „I“, das chinesische Zeichen fr „Wasser“ usw.
· Code-Positionen: Ein Satz von Integer-Referenzen zu Zeichen im Vorrat.
Jedes SGML-Dokument (einschl. jeden HTML-Dokuments) ist eine Folge von Zeichen aus dem
Vorrat. Computersysteme identifizieren jedes Zeichen anhand seiner Code-Position; zum Bei-
spiel verweisen im ASCII-Zeichensatz die Code-Positionen 65, 66 und 67 in dieser Reihenfolge
auf die Zeichen „A“, „B“ and „C“.

< 64 > Repr,sentation von HTML-Dokumenten


Page size: 168,00 x 240,00 mm

Der ASCII-Zeichensatz reicht fr ein globales Informationssystem wie das Web nicht aus, des-
wegen nutzt HTML das so genannte Universal Character Set (UCS), einen viel umfangreicheren
Zeichensatz, definiert in [ISO10646]. Dieser Standard definiert einen Vorrat von Tausenden
von den V=lkern der ganzen Welt verwendeten Zeichen.

Die HTML 4.01- Spezifikation


Der in [ISO10646] definierte Zeichensatz ist Zeichen fr Zeichen @quivalent zu Unicode ([UNI-
CODE]). Beide Standards werden von Zeit zu Zeit mit neuen Zeichen aktualisiert; die Neufas-
sungen auf den entsprechenden Websites sollten beachtet werden. In der gegenw@rtigen Spezi-
fikation wird [ISO10646] verwendet, um auf den Dokumentzeichensatz zu verweisen, w@hrend
[UNICODE] fr Verweise auf den Unicode-Bidirektional-Textalgorithmus (siehe Abschnitt 8.2)
reserviert ist.
Der Dokumentzeichensatz reicht jedoch nicht aus, um Benutzerprogrammen eine korrekte
Interpretation von HTML-Dokumenten, wie sie blicherweise ausgetauscht werden, als Byte-
sequenz in einer Datei oder w@hrend einer Netzwerk- bertragung, zu gestatten. Benutzerpro-
gramme mssen die spezifische Zeichenkodierung, die verwendet wurde, um den Dokument-
Zeichenstrom in einen Bytestrom zu transformieren, ebenfalls kennen.

5.2 Zeichenkodierungen
Das, was diese Spezifikation Zeichenkodierung (character encoding) nennt, ist in anderen Spe-
zifikationen unter verschiedenen Namen bekannt (was zur Verwirrung fhren kann). Das Kon-
zept ist jedoch im ganzen Internet weitgehend gleich. Auch Protokoll-Header, Attribute und
Parameter, die sich auf Zeichkodierungen beziehen, benutzen denselben „Zeichensatz“ (char-
set) und dieselben Werte aus dem [IANA]-Register (komplette Liste siehe [CHARSETS]).
Der „charset“-Parameter identifiziert eine Zeichenkodierung; dies ist eine Methode zur Kon-
vertierung einer Folge von Bytes in eine Folge von Zeichen. Diese Konvertierung passt natr-
lich zum System der Web-Aktivit@ten: Server senden HTML-Dokumente als Folge von Bytes zu
Benutzerprogrammen; Benutzerpromme interpretieren sie als eine Folge von Zeichen. Die
Konvertierngsmethode kann sich zwischen einer einfachen Eins-zu-Eins-Beziehung und komple-
xen Umsetzungssystemen und -algorithmen bewegen.
Eine einfache Ein-Byte-pro-Zeichen-Kodierungstechnik gengt nicht fr Textfolgen aus einem
Zeichenvorrat so groß wie [ISO10646]. Zus@tzlich zu Kodierungen des vollst@ndigen Zeichen-
satzes (wie UCS-4) gibt es mehrere verschiedene Kodierungen von Teilen von [ISO10646].

5.2.1 Eine Kodierung w.hlen

Autoren-Tools (z. B. Texteditoren) k=nnen HTML-Dokumente in der Zeichenkodierung ihrer


Wahl kodieren; die Wahl h@ngt weitgehend von den Konventionen der verwendeten System-
software ab. Diese Tools k=nnen jede geeignete Kodierung, die die meisten im Dokument ent-
haltenen Zeichen abdeckt, verwenden, vorausgesetzt, die Kodierung ist korrekt etikettiert.
Vereinzelte Zeichen, die nicht unter diese Kodierung fallen, k=nnen immer noch durch Zei-
chenreferenzen dargestellt werden. Diese beziehen sich immer auf den Dokumentzeichensatz,
nicht auf die Zeichenkodierung.

Zeichenkodierungen < 65 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Server und Proxies k=nnen eine Zeichenkodierung „on the fly“ @ndern (genannt Transkodie-
rung), um den Anforderungen von Benutzerprogrammen gerecht zu werden (siehe Abschnitt
14.2 in [RFC2616], „the 'Accept-Charset' HTTP request header“). Server und Proxies mssen
ein Dokument nicht mit einer Zeichenkodierung bedienen, die den vollst@ndigen Dokumentzei-
Die HTML 4.01- Spezifikation

chensatz umfasst.
Im Web h@ufig verwendete Zeichenkodierungen sind ISO-8859-1 (auch als „Latin-1“ bezeich-
net; verwendbar fr die meisten westeurop@ischen Sprachen), ISO-8859-5 (die die kyrillische
Schrift untersttzt), SHIFT_JIS (eine japanische Kodierung), EUC-JP (eine andere japanische
Kodierung) and UTF-8 (eine Kodierung von ISO 10646, die eine unterschiedliche Bytezahl fr
verschiedene Zeichen nutzt). Die Namen fr Zeichenkodierungen unterscheiden nicht zwi-
schen Groß- und Kleinschreibung, so dass zum Beispiel „SHIFT_JIS“, „Shift_JIS“ und „shift_jis“
@quivalent sind.
Diese Spezifikation schreibt nicht vor, welche Zeichenkodierungen ein Benutzerprogramm
untersttzen muss.
Konforme Benutzerprogramme (siehe Abschnitt 4.1) mssen alle Zeichen in allen Zeichenko-
dierungen, die sie erkennen, korrekt auf ISO 10646 abbilden (oder sie mssen sich verhalten,
als ob sie so arbeiten wrden).

Anmerkung der bersetzer: Die meistverbreitete Kodierung von deutschspra-


chigen Texten drfte ISO-8859-1 sein. Auch diese HTML-Spezifikation enth@lt im (eng-
lischen) Original folgendes meta-Element:

<meta http-equiv="Content-Type"
content="text/html;
charset=ISO-8859-1">

Da es in dieser Thematik immer wieder Missverst@ndnisse gibt, insbesondere bei


HTML-Einsteigern, sei auf einen wichtigen Punkt nachdrcklich hingewiesen: Es gengt
nicht, einfach die Kodierung ISO-8859-1 (oder irgendeine andere) anzugeben. Selbstver-
st@ndlich muss das Dokument dann auch genau so kodiert sein. Auch in dieser Hinsicht
bietet es sich an, Web-Seiten vom W3C-Validator prfen zu lassen: http://validator.
w3.org/.
Zur Veranschaulichung hier noch ein Beispiel. Das folgende Bild zeigt einen Teil des Edi-
tors, mit dem diese bersetzung geschrieben wurde. Der untere Bereich zeigt die
hexadezimale Kodierung des Textes, der hier in ISO-8859-1 kodiert ist.

< 66 > Repr,sentation von HTML-Dokumenten


Page size: 168,00 x 240,00 mm

Die HTML 4.01- Spezifikation


Und nun zum Vergleich dasselbe Dokument in einer 2-Byte-Unicode-Kodierung. Beach-
ten Sie, dass in der Textansicht im Editor kein Unterschied zu erkennen ist, dass jedoch
pro Zeichen zwei Bytes verwendet werden.

Zeichenkodierungen < 67 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

ISO-8859-1 enth@lt brigens nicht das Euro-Zeichen. Statt dessen kann ISO-8859-15
verwendet werden, allerdings kann man davon ausgehen, dass diese Kodierung von
einer kleineren Anzahl Programme untersttzt wird. Das Euro-Entity &euro; drfte die
Die HTML 4.01- Spezifikation

sicherste (aber vielleicht nicht bequemste) Wahl sein (siehe auch Abschnitt 5.3, „Zei-
chenreferenzen“).
Im Hinblick auf das XML-basierte XHTML sei darauf hingewiesen, dass XML 1.0 ver-
langt, dass jedes verarbeitende System mindestens die Kodierungen UTF-8 und UTF-16
beherrscht. Die Internet Engineering Task Force (IETF) verlangt in ihrem RFC 2277
„IETF Policy on Character Sets and Languages“, dass Protokolle in der Lage sein ms-
sen, die UTF-8-Kodierung zu verwenden. Nachzulesen unter http://www.ietf.org/rfc/
rfc2277.txt.
Wer sich mit diesem Thema eingehender besch@ftigen m=chte, findet beim W3C ein
Arbeitspapier mit dem Titel „Character Model for the World Wide Web 1.0“. Das
Dokument gibt es noch nicht in deutscher bersetzung. In Englisch ist es unter
http://www.w3.org/TR/charmod/ zu finden. Sobald es eine bersetzung gibt, wird sie
voraussichtlich unter http://www.edition-w3c.de/TR/charmod/ erh@ltlich sein.

Anmerkungen zu spezifischen Kodierungen


Wenn HTML-Text in UTF-16 (charset = UTF-16) bertragen wird, sollten die Textdaten in
bereinstimmung mit [ISO10646], Abschnitt 6.3 und [UNICODE], Absatz C3, Seite 3-1 in
Netzwerk-Bytefolge („big-endian“, h=herwertiges Byte zuerst) bertragen werden.
Um die Chancen einer ordnungsgem@ßen Interpretation zu maximieren, wird zudem empfoh-
len, dass Dokumente, die als UTF-16 bertragen werden, immer mit dem Zeichen „ZERO-
WIDTH NON-BREAKING SPACE“ beginnen (hexadezimal FEFF, auch „Byte Order Mark“
(BOM) genannt), welches bei Byte-Umkehrung zu hexadezimal FFFE wird, einem garantiert
unbestimmten Zeichen. So k=nnte ein Benutzerprogramm, wenn es ein FFFE (hexadezimal) als
erstes Bytes des Textes erh@lt, wissen, dass die brigen Bytes bis zum Ende des Textes umge-
kehrt werden mssen.
Das UTF-1-Transformationsformat aus [ISO10646] (bei IANA registriert als ISO-
10646-UTF-1) sollte nicht benutzt werden. Informationen ber ISO 8859-8 und den Bidirek-
tionalalgorithmus finden Sie in der Anmerkung „Bidirektionalit@t und Zeichenkodierung“ in
Abschnitt 8.2.4 .

5.2.2 Spezifizieren der Zeichenkodierung

Wie stellt ein Server fest, welche Zeichenkodierung fr ein Dokument, das er anbietet, gilt?
Manche Server prfen die ersten paar Bytes eines Dokuments oder vergleichen mit einer
Datenbank bekannter Kodierungen und Dateien. Viele moderne Server geben Webmastern
mehr Einflussm=glickeiten auf die Zeichensatzkonfiguration als alte Server. Webmaster sollten
diese Mechanismen nutzen, um einen „charset“-Parameter zu senden, wann immer das m=glich
ist. Sie sollten jedoch Vorsicht walten lassen, um ein Dokument nicht mit einem falschen Wert
im „charset“-Parameter zu identifizieren.

< 68 > Repr,sentation von HTML-Dokumenten


Page size: 168,00 x 240,00 mm

Woher weiß ein Benutzerprogramm, welche Zeichenkodierung verwendet wurde? Der Server
sollte diese Information anbieten. Der direkteste Weg fr einen Server, das Benutzerpro-
gramm ber die Zeichenkodierung des Dokuments zu informieren, ist die Verwendung des
„charset“-Parameters im „Content-Type“-Header-Feld des HTTP-Protokolls ([RFC2616],

Die HTML 4.01- Spezifikation


Abschnitte 3.4 und 14.17). Zum Beispiel zeigt der folgende HTTP-Header an, dass die Zeichen-
kodierung EUC-JP ist:

Content-Type: text/html; charset=EUC-JP

Bitte lesen Sie die Definition von text/html in Abschnitt 4, „Konformit@t“.

Das HTTP-Protokoll ([RFC2616], Abschnitt 3.7.1) fhrt ISO-8859-1 als Standardkodierung an,
sollte der „charset“-Parameter im „Content-Type“-Header-Feld fehlen. In der Praxis hat sich
diese Empfehlung als nutzlos erwiesen, weil manche Server es nicht gestatten, einen „char-
set“-Parameter zu senden und andere nicht entsprechend konfiguriert sein k=nnen, den Para-
meter zu senden. Deswegen drfen Benutzerprogramme keinen Standardwert fr den „char-
set“-Parameter annehmen.
Um Server- oder Konfigurationseinschr@nkungen zu begegnen, k=nnen HTML-Dokumente
explizite Angaben ber die Zeichenkodierung des Dokuments enthalten; das META-Element kann
benutzt werden, Benutzerprogrammen diese Information zur Verfgung zu stellen.
Zum Beispiel sollte ein Dokument die folgende META-Deklaration enthalten, um zu spezifizieren,
dass die Zeichenkodierung des aktuellen Dokuments „EUC-JP“ ist:

<META http-equiv="Content-Type" content="text/html; charset=EUC-JP">

Die META-Deklaration darf nur verwendet werden, wenn die Zeichenkodierung derart auf-
gebaut ist, dass ASCII-wertige Bytes fr ASCII-Zeichen stehen (mindestens bis das META-Ele-
ment gelesen wurde). META-Deklarationen sollten so frh wie m=glich im HEAD-Element erschei-
nen.
Fr F@lle, in denen weder das HTTP-Protokoll noch das META-Element Informationen ber die
Zeichenkodierung eines Dokuments bereitstellt, bietet HTML bei verschiedenen Elementen
auch das charset-Attribut. Durch Kombination dieser Mechanismen kann ein Autor die Chan-
cen betr@chtlich erh=hen, dass das Benutzerprogramm die Zeichenkodierung erkennt, wenn
der Benutzer eine Ressource l@dt.
Zusammenfassend sei bemerkt: Konforme Benutzerprogramme mssen die folgende Reihen-
folge bei der Ermittlung der Zeichenkodierung eines Dokuments beachten (von der h=chsten
zur niedrigsten Priorit@t):
1. Einen HTTP-„charset“-Parameter in einem „Content-Type“-Feld.
2. Eine META-Deklaration mit „http-equiv“, gesetzt auf „Content-Type“ und einem gesetzten
Wert fr „charset“.
3. Das in einem eine externe Ressource kennzeichnenden Element gesetzte charset-Attribut.
Zus@tzlich zu dieser Liste kann das Benutzerprogramm Heuristik und Benutzereinstellungen
verwenden. Zum Beispiel benutzen viele Benutzerprogramme die Heuristik, um die verschiede-
nen Kodierungen fr japanischen Text voneinander zu unterscheiden. Benutzerprogramme
haben auch blicherweise eine vom Benutzer einstellbare lokale Standardkodierung, die sie
anwenden, wenn andere Indikatoren fehlen.

Zeichenkodierungen < 69 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Benutzerprogramme k=nnen einen Mechanismus bieten, der es Benutzern gestattet, inkorrekte


„Zeichensatz“-Information zu berschreiben. Wenn ein Benutzerprogramm solch einen
Mechanismus anbietet, sollte es das jedoch nur fr die Browserfunktionalit@t tun und nicht fr
Editierfunktionen, um das Erstellen von Webseiten zu vermeiden, die mit einem inkorrekten
Die HTML 4.01- Spezifikation

„charset“-Parameter gekennzeichneten sind.

Anmerkung: Sollte es fr spezifische Anwendungen erforderlich werden, auf Zeichen außerhalb von
[ISO10646] zu verweisen, sollten die Zeichen einer privaten Zone zugewiesen werden, um Konflikte
mit gegenw,rtigen oder knftigen Versionen des Standards zu vermeiden. Davon wird jedoch aus Grn-
den der Portierbarkeit dringend abgeraten. n

5.3 Zeichenreferenzen
Eine gegebene Zeichenkodierung kann eventuell nicht in der Lage sein, alle Zeichen des Doku-
mentzeichensatzes darzustellen. Fr solche Kodierungen, oder wenn Hard- bzw. Software-
konfigurationen Benutzern bei einigen Dokumentzeichen nicht gestatten, sie direkt einzugeben,
k=nnen Autoren SGML-Zeichenreferenzen nutzen. Zeichenreferenzen sind von der Zeichen-
kodierung unabh@ngige Mechanismen zur Eingabe beliebiger Zeichen aus dem Dokumentzei-
chensatz.
Zeichenreferenzen k=nnen in HTML in zwei Formen erscheinen:
·· Numerische Zeichenreferenzen (entweder dezimal oder hexadezimal)
Zeichen-Entity-Referenzen.
Zeichenreferenzen innerhalb von Kommentaren haben keine spezielle Bedeutung; sie sind
lediglich Kommentardaten.

Anmerkung: HTML bietet andere Wege der Darstellung von Zeichen, insbesondere eingebettete
Graphiken (siehe Abschnitt 13). n
Anmerkung: In SGML ist es in einigen F,llen m glich, das abschließende „;“ nach einer Zeichenrefe-
renz zu entfernen (z. B. an einem Zeilenumbruch oder unmittelbar vor einem Tag). Unter anderen
Umst,nden darf es nicht entfernt werden (z. B. in der Mitte eines Wortes). Um Probleme mit Benutzer-
programmen zu vermeiden, die verlangen, dass dieses Zeichen vorhanden ist, raten wir dringend dazu,
das „;“ in allen F,llen zu verwenden. n

5.3.1 Numerische Zeichenreferenzen

Numerische Zeichenreferenzen geben die Code-Position eines Zeichens im Dokumentzei-


chensatz an. Numerische Zeichenreferenzen k=nnen zwei Formen annehmen:
· Die Syntax „&#D;“, wobei D eine Dezimalzahl ist, weist auf die dezimale Zeichennummer D
in ISO 10646.
· Die Syntax „&#xH;“, wobei „&#xH;“ eine Hexadezimalzahl ist, weist auf die hexadezimale
Zeichennummer H in ISO 10646. Hexadezimale Zahlen in numerischen Zeichenreferenzen
unterscheiden nicht zwischen Groß- und Kleinschreibung.

< 70 > Repr,sentation von HTML-Dokumenten


Page size: 168,00 x 240,00 mm

Hier sind einige Beispiele numerischer Zeichenreferenzen:


· &#229; (dezimal) repr@sentiert den Buchstaben „a“ mit einem kleinen Kreis darber (z. B.
im Norwegischen benutzt).
·· &#xE5; (hexadezimal) repr@sentiert dasselbe Zeichen.

Die HTML 4.01- Spezifikation


&#Xe5; (hexadezimal) repr@sentiert ebenso dasselbe Zeichen.
·· &#1048; (dezimal) repr@sentiert den kyrillischen Großbuchstaben „I“.
&#x6C34; (hexadezimal) repr@sentiert das chinesische Zeichen fr „Wasser“.
Anmerkung: Obwohl die hexadezimale Repr,sentation nicht in [ISO8879] definiert ist, ist anzuneh-
men, dass sie wie in [WEBSGML] beschrieben, in der Hberarbeitung enthalten sein wird. Diese Konven-
tion ist besonders ntzlich, weil Zeichenstandards im Allgemeinen hexadezimale Repr,sentationen ver-
wenden. n

5.3.2 Zeichen-Entity-Referenzen

Um Autoren eine intuitivere M=glichkeit zu geben, auf Zeichen im Dokumentzeichensatz zu


verweisen, bietet HTML eine Kollektion von Zeichen-Entity-Referenzen. Zeichen-Entity-Refe-
renzen verwenden symbolische Namen, so dass sich Autoren keine Code-Positionen merken
mssen. Zum Beispiel verweist die Zeichen-Entity-Referenz &aring; auf das kleine „a“ mit einem
Kreis darber; „&aring;“ ist leichter zu merken als &#229;.
HTML 4 definiert nicht fr alle Zeichen im Dokumentzeichensatz eine Zeichen-Entity-Referenz.
Zum Beispiel gibt es keine Zeichen-Entity-Referenz fr den kyrillischen Großbuchstaben „I“.
Die in HTML 4 definierten finden Sie in der vollst@ndigen Liste der Zeichen-Entity-Referenzen
(siehe Abschintt 24).
Zeichen-Entity-Referenzen unterscheiden zwischen Groß- und Kleinschreibung. So weist
&Aring; auf ein anderes Zeichen (großes A mit Kreis) als &aring; (kleines a mit Kreis).
Vier Zeichen-Entity-Referenzen verdienen besondere Beachtung, da sie oft verwendet werden,
um spezielle Zeichen zu vermeiden:
·· „&lt;“ repr@sentiert das <-Zeichen.
„&gt;“ repr@sentiert das >-Zeichen.
·· „&amp;“ repr@sentiert das &-Zeichen.
„&quot;“ repr@sentiert das "-Zeichen.
Autoren, die das „<“-Zeichen im Text einsetzen wollen, sollten „&lt;“ (ASCII dezimal 60) ver-
wenden, um m=gliche Verwechslungen mit dem Beginn eines Tags (=ffnender Begrenzer des
Start-Tags, start tag open delimiter) zu vermeiden. Analog sollten Autoren im Text „&gt;“
(ASCII dezimal 62) anstelle von „>“ benutzen. Sie gehen damit Problemen aus dem Wege, die
in @lteren Benutzerprogrammen auftreten k=nnen. Dies kann dann passieren, wenn „>“ innner-
halb von in Anfhrungszeichen stehenden Attributwerte auftaucht und ein Benutzerprogramm
darin f@lschlicherweise das Ende eines Tags (schließender Tag-Begrenzer) erkennt.
Autoren sollten „&amp;“ (ASCII dezimal 38) anstelle von „&“ verwenden, um Verwechslungen
mit dem Beginn einer Zeichen-Entity-Referenz (=ffnender Begrenzer einer Entity-Referenz) zu
vermeiden. Autoren sollten auch in Attributwerten „&amp;“ benutzen, da Zeichenreferenzen
in CDATA-Attributwerten erlaubt sind.
Einige Autoren verwenden die Zeichen-Entity-Referenze „&quot;“, um doppelte Anfhrungs-
zeichen (") zu kodieren, weil dieses Zeichen zur Begrenzung von Attributwerten verwendet
werden kann.

Zeichenreferenzen < 71 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

5.4 Nicht darstellbare Zeichen


Ein Benutzerprogramm kann eventuell nicht in der Lage sein, alle Zeichen eines Dokuments
sinnvoll darzustellen, zum Beispiel, weil ihm ein passender Zeichensatz (Font) fehlt, ein Zeichen
Die HTML 4.01- Spezifikation

einen Wert hat, der in der internen Zeichenkodierung des Benutzerprogramms nicht aus-
gedrckt werden kann, usw.
Weil es viele verschiedene Dinge gibt, die in solch einem Fall getan werden k=nnen, schreibt
dieses Dokument kein bestimmtes Verhalten vor. Abh@ngig von der Implementierung k=nnen
nicht darstellbare Zeichen auch vom darunterliegenden Anzeigesystem und nicht von der
Anwendung selbst behandelt werden. Bei Fehlen eines besseren Verhaltens, zum Beispiel ange-
passt an die Erfordernisse einer speziellen Schrift (script) oder einer Sprache, empfehlen wir
fr Benutzerprogramme das folgende Verhalten:
1. Einen deutlich erkennbaren, aber unaufdringlichen Mechanismus w@hlen, um den Benutzer
ber fehlende Ressourcen zu informieren.
2. Die hexadezimale Form verwenden (nicht die dezimale), wenn fehlende Zeichen durch ihre
numerische Repr@sentation dargestellt werden, weil das die in Zeichensatz-Standards ver-
wendete Form ist.

6 HTML-Grunddatentypen
Dieser Abschnitt der Spezifikation beschreibt die Grunddatentypen, die als Inhalt eines Ele-
ments oder Wert eines Attributs vorkommen k=nnen.
Einhrende Informationen darber, wie die HTML-DTD zu lesen ist, finden Sie in Abschnitt 3,
„ ber SGML und HTML“.

6.1 Information zu Groß- bzw. Kleinschreibung


Jede Definition eines Attributs enth@lt die Information darber, ob innerhalb seines Wertes
zwischen Groß- und Kleinschreibung unterschieden wird. Die Information zu Groß- bzw.
Kleinschreibung ist mit Hilfe folgender Schlssel dargestellt:

CS
Im Wert wird zwischen Groß- und Kleinschreibung unterschieden (case-sensitive), d. h.,
Benutzerprogramme interpretieren „a“ und „A“ verschieden.
CI
Im Wert wird nicht zwischen Groß- und Kleinschreibung unterschieden (case-sensitive),
d. h., Benutzerprogramme interpretieren „a“ und „A“ gleich.
CN
Der Wert kann nicht von Groß- in Kleinschreibung oder umgekehrt ge@ndert werden, z. B.,
weil es sich um eine Zahl oder ein Zeichen aus dem Dokument-Zeichensatz handelt.

< 72 > HTML-Grunddatentypen


Page size: 168,00 x 240,00 mm

CA
Die Element- oder Attributdefinition selbst gibt die Information zu Groß- bzw. Kleinschrei-
bung.
CT

Die HTML 4.01- Spezifikation


Lesen Sie die Information zu Groß- bzw. Kleinschreibung (case-sensitivity) in der Typ-Defi-
nition nach.

Ist ein Attribut eine Liste, gelten, wenn nicht anders angegeben, die Schlssel fr alle Werte
der Liste.

6.2 Grunddatentypen in SGML


Die Dokumenttyp-Definition spezifiziert die Syntax der Inhalte von HTML-Elementen und der
Werte von Attributen unter Verwendung von SGML-Tokens (z. B. PCDATA, CDATA, NAME,
ID usw.). Die vollst@ndige Definition ist in [ISO8879] zu finden. Nachfolgend eine Zusammen-
fassung der Schlssel-Informationen:
· CDATA ist eine Folge von Zeichen des Dokument-Zeichensatzes und kann Zeichen-Enti-
ties enthalten. Benutzerprogramme sollten Attributwerte folgendermaßen interpretieren:
·· Zeichen-Entities durch Zeichen ersetzen
Zeilenumbrche ignorieren
· Jeden Zeilenwechsel oder Tabulatorsprung durch ein einzelnes Leerzeichen ersetzen
Benutzerprogramme k=nnen fhrenden und nachfolgenden Leerraum (white space) in
CDATA-Attributwerten ignorieren (z. B. kann „ myval “ als „myval“ interpretiert werden).
Autoren sollten Attributwerte nicht mit fhrendem oder nachfolgendem Leerraum dekla-
rieren.
Fr einige HTML 4-Attribute mit CDATA-Attributwerten erlegt die Spezifikation der Kol-
lektion fr das Attribut gltiger Werte zus@tzliche Einschr@nkungen auf, die nicht durch die
DTD ausgedrckt werden k=nnen.
Auch das STYLE- und SCRIPT-Element nutzen CDATA fr ihr Datenmodell; fr diese Ele-
mente mssen Benutzerprogramme CDATA anders behandeln. Auszeichnungen und Enti-
ties mssen als purer Text angesehen und an die Anwendung gegeben werden, wie sie sind.
Das erste Auftreten der Zeichenfolge „</“ (=ffnender Begrenzer des End-Tags, end tag
open delimiter) wird als Ende des Elementinhalts angesehen. In gltigen Dokumenten w@re
das der End-Tag des Elements.
· ID- und NAME-tokens mssen mit einem Buchstaben ([A-Za-z]) beginnen, diesem kann
eine beliebige Anzahl von Buchstaben, Ziffern ([0-9]), Bindestrichen („-“), Unterstrichen
(„_“), Doppelpunkten („:“) und Punkten („.“) folgen.
· IDREF und IDREFS sind Verweise auf durch andere Attribute definierte ID-tokens.
IDREF ist ein Einzel-Token und IDREFS ist eine durch Leerzeichen getrennte Liste von
Tokens.
· NUMBER-tokens mssen mindestens eine Ziffer ([0-9]) enthalten.

Grunddatentypen in SGML < 73 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

6.3 Text-Zeichenfolgen
Mehrere Attribute (in der DTD: %Text;) nehmen Text auf, der so angelegt ist, dass er fr Men-
schen lesbar ist („human readable“). Fr einfhrende Informationen ber Attribute lesen Sie
Die HTML 4.01- Spezifikation

bitte Abschnitt 3.3.2, „Attribute“.

Anmerkung der bersetzer: Eines dieser Attribute, das %Text; erwartet, ist das
title-Attribut. Wie drei der zum Zeitpunkt des Erscheinens dieses Buches g@ngigen
Browser den Link

<A href="www.edition-w3c.de/"
title="
Wert des
&quot;title-Attributes&quot;"
>mein Link</A>
<!- - (Zwischen "Wert" und "des"
befinden sich zwei TabulatorsprUnge) - ->

zeigen, ist in der Abbildung zu sehen.

6.4 URIs
Diese Spezifiaktion verwendet den Terminus URI, wie er in [URI] definiert ist (s.a. [RFC1630]).
Beachten Sie, dass URIs URLs (wie in [RFC1738] und [RFC1808] definiert) beinhalten.
Relative URIs werden unter Verwendung eines Basis-URIs in vollst@ndige URIs aufgel=st.
[RFC1808], Abschnitt 3 definiert den normativen Algorithmus fr diesen Prozess. Mehr Infor-
mationen ber Basis-URIs finden Sie im Abschnitt 12.4, „Pfadangaben: Das Base-Element“ im
Kapitel ber Links.

URIs werden in der DTD durch den Parameter-Entity %URI; verk=rpert.

< 74 > HTML-Grunddatentypen


Page size: 168,00 x 240,00 mm

Generell unterscheiden URIs zwischen Groß- und Kleinschreibung. Es kann URIs oder Teile
von URIs geben, in denen Groß- oder Kleinschreibung keine Rolle spielt (z. B. Namen von
Maschinen), aber dies herauszufinden, wird nicht immer leicht sein. Benutzer sollten immer
annehmen, dass URIs zwischen Groß- und Kleinschreibung unterscheiden (um auf der sicheren

Die HTML 4.01- Spezifikation


Seite zu sein).
Informationen ber Nicht-ASCII-Zeichen in URI-Attributwerten finden Sie im Anhang B.

6.5 Farben
Der Typ „color“ (%Color;) fr Attributwerte verweist auf Farbdefinitionen, wie sie in [SRGB]
spezifiziert sind. Ein Farbwert (color value) kann entweder eine Hexadezimalzahl (mit voran-
gestelltem Nummernzeichen) oder einer der folgenden 16 Farbnamen (color names) sein. Die
Farbnamen unterscheiden nicht zwischen Groß- und Kleinschreibung.

Black = „#000000“ Green = „#008000“

Silver = „#C0C0C0“ Lime = „#00FF00“

Gray = „#808080“ Olive = „#808000“

White = „#FFFFFF“ Yellow = „#FFFF00“

Maroon = „#800000“ Navy = „#000080“

Red = „#FF0000“ Blue = „#0000FF“

Purple = „#800080“ Teal = „#008080“

Fuchsia = „#FF00FF“ Aqua = „#00FFFF“

Farben < 75 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Dementsprechend beziehen sich sowohl „#800080“ als auch „Purple“ auf die Farbe „Purpur“.

6.5.1 Bemerkungen zur Verwendung von Farben


Die HTML 4.01- Spezifikation

Obwohl Farben Dokumenten merklich Informationswert hinzufgen und sie lesbarer machen
k=nnen, bedenken Sie bitte die folgenden Richtlinien, wenn Sie Farben in Ihre Dokumente mit
einbeziehen:
· Die Verwendung von Elementen und Attributen zur Spezifizierung von Farben ist missbilligt.
Sie sind statt dessen aufgefordert, Stylesheets zu verwenden.
· Verwenden Sie keine Farbkombinationen, die fr Menschen, die unter Farbenblindheit der
verschiedensten Form leiden, Probleme verursachen k=nnen.
· Wenn Sie ein Hintergundbild verwenden oder die Hintergrundfarbe festlegen, dann legen
Sie unbedingt die verschiedenen Textfarben ebenfalls fest.
· Mit Hilfe von BODY- und FONT-Element bzw. bgcolor in Tabellen spezifizierte Farben sehen auf
unterschiedlichen Plattformen unterschiedlich aus (z. B. Workstations, Macs, Windows und
LCD-Panele vs. CRTs), deswegen sollten Sie sich nicht auf einen speziellen Effekt verlassen.
Die Untersttzung des [SRGB]-Farbmodells zusammen mit ICC-Farbprofilen drften dieses
Problem in Zukunft mildern.
· Wenn m=glich machen Sie sich bliche Konventionen zu eigen, Benutzer nicht unn=tig zu
verwirren.

6.6 Maße
HTML spezifiziert drei Arten von Maßwerten fr Attribute:
1. Pixels: Der Wert (in der DTD: %Pixels;) ist eine ganze Zahl, die die Anzahl der Pixel des
Canvas (Bildschirm, Papier) angibt. Der Wert „50“ bedeutet folglich 50 Pixel. Fr normative
Informationen ber die Definition von Pixel lesen Sie bitte in [CSS1] nach.
2. Length: Der Wert (in der DTD: %Length;) kann entweder %Pixel; oder ein prozentualer
Anteil des verfgbaren horizontalen Platzes sein. Folglich bedeutet der Wert „50%“ die
H@lfte des verfgbaren Platzes.
3. MultiLength: Der Wert (in der DTD: %MultiLength;) kann %Length; sein oder ein relati-
ves Maß. Ein relatives Maß hat die Form „i*“, wobei „i“ eine ganze Zahl ist. Wenn Benutzer-
programme Elementen, die sich darum bewerben, Platz zuweisen, weisen sie zuerst Pixel-
und Prozentwerte zu, dann verteilen sie den verbleibenden verfgbaren Platz unter den
relativen Maßen. Jedes relative Maß erh@lt einen Anteil des verfgbaren Platzes, der propor-
tional ist zu der dem „*“ vorausgehenden ganzen Zahl. Der Wert „*“ ist @quivalent zu „1*“.
Folglich werden, wenn 60 Pixel an Platz verfgbar sind, nachdem das Benutzerprogramm
Pixel- und Prozentwerte zugewiesen hat und die sich bewerbenden relativen Maße 1*, 2*,
und 3* sind, der 1* 10 Pixel, der 2* 20 Pixel und der 3* 30 Pixel zugewiesen.
Fr Maßwerte ist die Unterscheidung zwischen Groß- und Kleinschreibung nicht relevant.

< 76 > HTML-Grunddatentypen


Page size: 168,00 x 240,00 mm

6.7 Inhaltstypen (content type) (MIME types)


Anmerkung: Ein „Medientyp“ (media type) (definiert in [RFC2045] und [RFC2046]) spezifiziert
die Art der verlinkten Ressource. In Hbereinstimmung mit dem allgemeinen Sprachgebrauch bevorzugt

Die HTML 4.01- Spezifikation


diese Spezifikation den Terminus „Inhaltstyp“ (content type) gegenber „Medientyp“ (media type).
Außerdem kann sich „Medientyp“ in dieser Spezifikation auf das Medium beziehen, auf dem das
Benutzerprogramm das Dokument darstellt. n
Dieser Typ wird in der DTD durch %ContentType; dargestellt.
Inhaltstypen unterscheiden nicht zwischen Groß- und Kleinschreibung.
Beispiele fr Inhaltstypen sind „text/html“, „image/png“, „image/gif“, „video/mpeg“, „text/css“
und „audio/basic“. Die aktuelle Liste der registrierten MIME-Typen finden Sie unter [MIME-
TYPES].

6.8 Sprachcodes
Der Wert von Attributen vom Typ Sprachcode (language code) (in der DTD: %LanguageCode)
weist auf einen Sprachcode, wie er durch [RFC1766] Abschnitt 2 spezifiziert wird, hin. Informa-
tionen zur Spezifizierung von Sprachcodes in HTML finden Sie im Abschnitt 8.1.1, „Sprach-
codes“. Leerr@ume sind im Sprachcode nicht erlaubt.
Sprachcodes unterscheiden nicht zwischen Groß- und Kleinschreibung.

6.9 Zeichenkodierungen
Die „charset“-Attribute (in der DTD: %Charset) verweisen auf eine Zeichenkodierung wie in
Abschnitt 5.2, „Zeichenkodierungen“ beschrieben. Die Werte mssen Zeichenfolgen aus der
IANA-Registrierung sein (z. B. „euc-jp“) (s. [CHARSETS] fr eine komplette Liste).
Namen von Zeichenkodierungen unterscheiden nicht zwischen Groß- und Kleinschreibung.
Um die Zeichenkodierung einer externen Ressource zu bestimmen, mssen Benutzerpro-
gramme die im Abschnitt 5.2.2, „Spezifizieren von Zeichenkodierungen“ angefhrten Schritte in
der vorgegebenen Reihenfolge ausfhren.

6.10 Einzelne Zeichen


Bestimmte Attribute verlangen nach einem einzelnen Zeichen aus dem Dokumentzeichensatz
(siehe Abschnitt 5.1). Diese Attribute sind vom Typ %Character in der DTD.
Einzelne Zeichen k=nnen mit Hilfe von Zeichenreferenzen (z. B. „&amp;“) spezifiziert werden
(siehe Abschnitt 5.3).

6.11 Datum und Zeit


[ISO8601] gestattet viele Optionen und Variationen in der Darstellung von Datum und Zeit.
Die augenblickliche Spezifikation verwendet fr ihre Definition gltiger Datum/Zeit-Zeichenfol-
gen (date/time strings) (in der DTD: %Datetime) eines der im Profil [DATETIME] beschriebe-
nen Formate.

Inhaltstypen (content type) (MIME types) < 77 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Das Format ist:

YYYY-MM-DDThh:mm:ssTZD
Die HTML 4.01- Spezifikation

mit:

YYYY = vierstellige Angabe des Jahres


MM = zweistellige Monatsangabe (01=Januar usw.)
DD = zweistellige Angabe des Tags des Monats (01 bis 31)
hh = zweistellige Stundenangabe (00 bis 23) (am/pm sind nicht erlaubt)
mm = zweistellige Minutenangabe (00 bis 59)
ss = zweistellige Sekundenangabe (00 bis 59)
TZD = Zeitzonen-Kennzeichnung

Die Zeitzonen-Kennzeichnung:
Z
weist auf UTC (Coordinated Universal Time) hin. Das „Z“ muss groß geschrieben werden.
+hh:mm
weist darauf hin, dass es sich um eine lokale Zeit handelt, die hh Stunden und mm Minuten
gegenber UTC voraus ist.
-hh:mm
weist darauf hin, dass es sich um eine lokale Zeit handelt, die hh Stunden und mm Minuten
gegenber UTC zurck ist.

Exakt die hier gezeigten Komponenten mit exakt dieser Interpunktion mssen vorhanden sein.
Beachten Sie, dass das \;T\( in der Zeichenfolge genau so vorkommen muss (es muss groß
geschrieben werden), um den Beginn des Zeit-Elements wie in [ISO8601] spezifiziert anzuzei-
gen.
Wenn eine generierende Anwendung die Zeit nicht auf die Sekunde genau weiß, kann sie den
Wert „00“ fr Sekunden benutzen (falls erforderlich analog fr Minuten und Stunden).

Anmerkung: [DATETIME] geht nicht auf die Frage der Schaltsekunden ein. n

6.12 Linktypen
Autoren k=nnen die nachfolgenden bekannten Linktypen verwenden – hier aufgelistet mit ihrer
blichen Interpretation. In der DTD weist %LinkTypes auf eine durch Leerzeichen getrennte
Liste von Linktypen. Leerraum-Zeichen (white space) sind innerhalb von Linktypen nicht
erlaubt.
Diese Linktypen unterscheiden nicht zwischen Groß- und Kleinschreibung. Zum Beispiel hat
„Alternate“ dieselbe Bedeutung wie „alternate“.
Benutzerprogramme, Suchmaschinen usw. k=nnen diese Linktypen auf verschiedenste Art
interpretieren. Zum Beispiel k=nnen Benutzerprogramme den Zugriff auf verlinkte Dokumente
ber eine Navigationsleiste anbieten.

< 78 > HTML-Grunddatentypen


Page size: 168,00 x 240,00 mm

Alternate
kennzeichnet Ersatzversionen des Dokuments, in dem der Link vorkommt. Wird es zusam-
men mit dem hreflang-Attribute verwendet, bedeutet dies, dass eine bersetzte Version
des Dokuments vorliegt. Wird es zusammen mit dem media-Attribut verwendet, bedeutet

Die HTML 4.01- Spezifikation


dies, dass es sich um eine Version fr ein anderes Medium handelt.
Stylesheet
verweist auf externes Stylesheet. Details lesen Sie in Abschnitt 14.3, „Externe Stylesheets“.
Fr durch den Benutzer w@hlbare Stylesheets wird es gemeinsam mit mit dem Linktyp „Al-
ternate“ eingesetzt.
Start
verweist auf das erste Dokument einer Kollektion von Dokumenten. Dieser Linktyp sagt
Suchmaschinen, welches Dokument vom Autor als Startpunkt der Kollektion angesehen wird.
Next
verweist auf das n@chste Dokument einer linearen Folge von Dokumenten. Benutzerpro-
gramme k=nnen sich entschließen, das „n@chste“ Dokument vorzuladen, um die wahr-
genommene Ladezeit zu reduzieren.
Prev
verweist auf das vorhergehende Dokument einer geordneten Folge von Dokumenten.
Einige Benutzerprogramme untersttzen auch das Synonym „Previous“.
Contents
verweist auf ein Dokument, das als Inhaltsverzeichnis dient. Einige Benutzerprogramme
untersttzen auch das Synonym ToC (von „Table of Contents“).
Index
verweist auf ein Dokument, das einen Index fr das aktuelle Dokument anbietet.
Glossary
verweist auf ein Dokument, das ein Glossar zu Ausdrcken anbietet, die das aktuelle Doku-
ment betreffen.
Copyright
verweist auf eine Copyright-Angabe des aktuellen Dokuments.
Chapter
verweist auf ein Dokument, das als Kapitel (chapter) in einer Kollektion von Dokumenten
dient.
Section
verweist auf ein Dokument, das als Abschnitt in einer Kollektion von Dokumenten dient.
Subsection
verweist auf ein Dokument, das als Unterabschnitt in einer Kollektion von Dokumenten
dient.
Appendix
verweist auf ein Dokument, das als Anhang in einer Kollektion von Dokumenten dient.
Help
verweist auf ein Dokument, das Hilfe anbietet (weitergehende Informationen, Links zu
anderen Nachrichtenquellen usw.)
Bookmark
verweist auf ein Lesezeichen (bookmark). Ein Lesezeichen ist ein Link zu einem Schlssel-
eintrittspunkt innerhalb eines ausgedehnten Dokuments. Das title-Attribut kann zum Bei-
spiel dazu benutzt werden, das Lesezeichen zu beschriften. Beachten Sie, dass in jedem
Dokument mehrere Lesezeichen definiert werden k=nnen.

Linktypen < 79 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Autoren k=nnten den Wunsch haben, zus@tzliche Linktypen, die nicht in dieser Spezifikation
beschrieben sind, zu definieren. Wenn dem so ist, sollten sie ein Profile benutzen (siehe
Abschnitt 7), um die fr die Definition des Linktyps verwendeten Konventionen anzufhren.
Siehe profile-Attribut des HEAD-Elements fr mehr Details.
Die HTML 4.01- Spezifikation

Anmerkung der bersetzer: Die Verwendung eines Linktyps sieht in der Praxis
zum Beispiel so aus:

<link rel="stylesheet"
type="text/css"
href="textseite.css" />

Hier wird eine CSS-Datei durch das link-Element im Kopf der HTML-Datei mit der
HTML-Datei verknpft. Die anderen genannten Linktypen werden von den meisten
Browsern nicht untersttzt. Auch die genannten Profile spielen praktisch keine Rolle.

Weitergehende Er=rterungen zu Linktypen finden Sie im Abschnitt 12, „Links“.

6.13 Medien-Deskriptoren
Nachfolgend sind die anerkannten Medien-Deskriptoren (in der DTD: %MediaDesc) aufgelistet.

screen
ist bestimmt fr nicht seitenorientierte Computer-Bildschirme.
tty
ist bestimmt fr Medien, die ein @quidistantes Zeichenraster verwenden, wie Teleprinter,
Terminals oder tragbare Ger@te mit eingeschr@nkten Dartsellungsf@higkeiten.
tv
ist bestimmt fr TV-@hnliche Ger@te (geringe Aufl=sung, Farben, begrenzte Scroll-M=glich-
keit).
projection
ist bestimmt fr Projektoren.
handheld
ist bestimmt fr Handheld-Ger@te (kleiner Bildschirm, monochrom, Rastergrafiken, geringe
Bandbreite).
print
ist bestimmt fr seitenweises undurchsichtiges Material und fr Dokumente, die am Bild-
schirm im Druckvorschau-Modus angesehen werden.
braille
ist bestimmt fr Braille-Leseger@te.
aural
ist bestimmt fr Sprach-Synthesizer.
all
ist geeignet fr alle Ger@te.

< 80 > HTML-Grunddatentypen


Page size: 168,00 x 240,00 mm

Knftige HTML-Versionen k=nnen neue Werte einfhren und parametrisierte Werte gestat-
ten. Um die Einfhrung dieser Erweiterungen zu erleichtern, mssen konforme Benutzerpro-
gramme in der Lage sein, den media-Attributwert folgendermaßen zu parsen:

Die HTML 4.01- Spezifikation


1. Der Wert ist eine durch Kommata getrennte Liste von Eintr@gen. Zum Beispiel wird

media="screen, 3d-glasses, print and resolution > 90dpi"

abgebildet auf:

"screen"
"3d-glasses"
"print and resolution > 90dpi"

2. Jeder Eintrag wird genau vor dem ersten Zeichen beschnitten, das weder ein US-ASCII-Zei-
chen [a-zA-Z] (ISO 10646 hex 41-5a, 61-7a), eine Ziffer [0-9] (hex 30-39) noch ein Binde-
strich (hex 2d) ist. Im Beispiel ergibt dies:

"screen"
"3d-glasses"
"print"

3. Anschließend wird (unter Beachtung von Groß- und Kleinschreibung) ein Vergleich mit
dem Satz der oben definierten Medientypen durchgefhrt. Benutzerprogramme k=nnen
nicht passende Eintr@ge ignorieren. Im Beispiel bleiben screen und print brig.

Anmerkung: Stylesheets k nnen medienunabh,ngige Variationen beinhalten (z. B. das CSS-


@media-Konstrukt). In solchen F,llen kann es passend sein, „media=all“ zu verwenden. n

6.14 Skript-Daten
Skript-Daten (in der DTD: %Script;) k=nnen den Inhalt des SCRIPT-Elements oder den Wert
innerer (intrinsic) Ereignisattribute (siehe Abschnitt 18) bilden. Benutzerprogramme drfen
Skript-Daten nicht als HTML-Auszeichnung auswerten, sondern mssen sie statt dessen an die
Script-Engine weiterreichen.
Ob zwischen Groß- und Kleinschreibung unterschieden wird, h@ngt von Skript-Sprache ab.

Anmerkung der bersetzer: JavaScript unterscheidet zum Beispiel zwischen


Groß- und Kleinschreibung, w@hrend VBScript das nicht tut. Das kleine Beispiel illus-
triert den Unterschied:

<SCRIPT type="text/javascript">
Nachricht = "World!";
nachricht = "Hello ";
alert(nachricht + Nachricht);
</SCRIPT>
<SCRIPT type="text/vbscript">
Nachricht = "World!"
nachricht = "Hello "

Skript-Daten < 81 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

msgBox nachricht & Nachricht


</SCRIPT>

Das erste Skript (JavaScript) meldet sich mit „Hello World!“, weil „Nachricht“ und
Die HTML 4.01- Spezifikation

„nachricht“ zwei unterschiedliche Variablen bezeichen. Die Meldung des zweiten Skripts
(VBScript) hingegen lautet „Hello Hello“, da nicht zwischen „Nachricht“ und „nach-
richt“ unterschieden wird.

Bite beachten Sie, dass Skript-Daten als Elementinhalt keine Zeichenreferenzen (siehe
Abschnitt 5.3) enthalten k=nnen, Skript-Daten in Form von Attributwerten diese jedoch bein-
halten drfen. Der Anhang liefert weitere Informationen ber die Spezifizierung von Nicht-
HTML-Daten (siehe B.3.2).

Anmerkung der bersetzer: Im folgenden Beispiel wird der Benutzer bei Klick
auf den Link mit „Grß Gott“ begrßt werden, w@hrend die alert-Anweisung im SCRIPT-
Element „Gr&uuml;ß Gott“ unver@ndert, also mit unaufgel=stem Entity, wiedergibt

<SCRIPT type="text/javascript">
alert('Gr&uuml;ß Gott');
</SCRIPT>
<A href="http://edition-w3c.de"
onclick="alert('Gr&uuml;ß Gott')"
>http://edition-w3c.de</A>

Zurzeit g@ngige Browser verhalten sich hier durchaus korrekt.

6.15 Stylesheet-Daten
Stylesheet-Daten (in der DTD: %StyleSheet;) k=nnen den Inhalt des STYLE-Elements oder den
Wert des style-Attributs bilden. Benutzerprogramme drfen Skript-Daten nicht als HTML-
Auszeichnung auswerten.
Ob zwischen Groß- und Kleinschreibung unterschieden wird h@ngt von der Stylesheet-Sprache
ab.
Bite beachten Sie, dass Stylesheet-Daten als Elementinhalt keine Zeichenreferenzen (siehe
Abschnitt 5.3) enthalten k=nnen, Stylesheet-Daten in Form von Attributwerten diese jedoch
beinhalten drfen. Der Anhang liefert weitere Informationen ber die Spezifizierung von Nicht-
HTML-Daten (siehe B.3.2).

6.16 Namen von Ziel-Frames (target names)


Mit Ausnahme der weiter unten aufgelisteten reservierten Namen mssen Ziel-Frame-Namen
(in der DTD: %FrameTarget;) mit einem alphabetischen Zeichen (a-zA-Z) beginnen. Benutzer-
programme sollten alle anderen Ziel-Namen ignorieren.
Die folgenden Ziel-Namen sind reserviert und haben besondere Bedeutungen.

< 82 > HTML-Grunddatentypen


Page size: 168,00 x 240,00 mm

_blank
Das Benutzerprogramm sollte das angegebene Dokument in ein neues unbenanntes Fenster
laden.
_self

Die HTML 4.01- Spezifikation


Das Benutzerprogramm sollte das Dokument in denselben Frame laden wie das Element,
das auf dieses Ziel verweist.
_parent
Das Benutzerprogramm sollte das Dokument in das umgebende Eltern-FRAMESET (parent)
des aktuellen Frames laden. Dieser Wert ist identisch mit _self, wenn es zum aktuellen
Frame kein Eltern-Frameset gibt.
_top
Das Benutzerprogramm sollte das Dokument in das volle Original-Fenster laden (auf diese
Art alle anderen Frames aufhebend). Dieser Wert ist identisch mit _self, wenn es zum
aktuellen Frame kein Eltern-Frameset gibt.

7 Die globale Struktur eines


HTML-Dokuments
7.1 Einf-hrung in die Struktur eines HTML-Dokuments
Ein HTML 4-Dokument setzt sich aus drei Teilen zusammen:
1. Einer Zeile, die HTML-Versionsinformationen enth@lt
2. Einem deklarativen Kopfabschnitt (begrenzt durch das HEAD-Element)
3. Einem Rumpf, der den eigentlichen Inhalt des Dokuments enth@lt. Der Rumpf kann durch
das BODY-Element oder das FRAMESET-Element eingebunden sein.
Leerr@ume (white spaces; Leerzeichen, Zeilenwechsel, Tabulatursprnge und Kommentare)
k=nnen vor und nach jedem Abschnitt auftauchen. Abschnitt 2 und 3 sollten durch das HTML-Ele-
ment begrenzt sein.
Hier ist ein Beispiel fr ein einfaches HTML-Dokument:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"


"http://www.w3.org/TR/html4/strict.dtd">
<HTML>
<HEAD>
<TITLE>My first HTML document</TITLE>
</HEAD>
<BODY>
<P>Hello world!
</BODY>
</HTML>

Die globale Struktur eines HTML-Dokuments < 83 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

7.2 HTML-Versionsinformation
Ein gltiges HTML-Dokument gibt die im Dokument benutzte HTML-Version an. Die Doku-
menttyp-Deklaration benennt die fr das Dokument verwendete Dokumenttyp-Definition
Die HTML 4.01- Spezifikation

(DTD) (s. [ISO8879]).


HTML 4.01 spezifiziert drei DTDs, deshalb mssen Autoren eine der folgenden Dokumenttyp-
Deklarationen in ihre Dokumente aufnehmen. Die DTDs unterscheiden sich in den Elementen,
die sie untersttzen.
· Die HTML 4.01 Strict DTD beinhaltet alle Elemente und Attribute, die nicht missbilligt
wurden und nicht in Frameset-Dokumenten auftreten. Fr Dokumente, die diese DTD
benutzen, verwenden Sie die Dokumenttyp-Deklaration:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"


"http://www.w3.org/TR/html4/strict.dtd">

· Die HTML 4.01 Transitional DTD beinhaltet alles aus der Strict-DTD und zus@tzlich miss-
billigte Elemente und Attribute (von denen die meisten die visuelle Darstellung betreffen).
Fr Dokumente, die diese DTD benutzen, verwenden Sie die Dokumenttyp-Deklaration:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"


"http://www.w3.org/TR/html4/loose.dtd">

· Die HTML 4.01 Frameset DTD beinhaltet alles aus der Transitional DTD und zus@tzlich
Frames. Fr Dokumente, die diese DTD benutzen, verwenden Sie die Dokumenttyp-Dekla-
ration:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"


"http://www.w3.org/TR/html4/frameset.dtd">

Der URI in jeder Dokumenttyp-Deklaration gestattet es Benutzerprogrammen, die DTD und


irgendwelche ben=tigten Entity-S@tze (siehe Abschnitt 24) herunterzuladen. Die folgenden (re-
lativen) URIs verweisen auf DTDs und Entity-S@tze fr HTML 4:
·· „strict.dtd“ – Standard-Strict-DTD
„loose.dtd“ – loose DTD
·· „frameset.dtd“ – DTD fr Frameset-Dokumente
„HTMLlat1.ent“ – Latin-1-Entities
·· „HTMLsymbol.ent“ – Symbol-Entities
„HTMLspecial.ent“ – Special-Entities
Die Zuordnung von Public Identifiers zu Dateien kann durch die Verwendung einer Katalogda-
tei, deren Format sich nach den Empfehlungen des Oasis Open Consortiums dafr richtet
(siehe [OASISOPEN]), durchgefhrt werden. Eine Beispiel-Katalogdatei fr HTML 4.01 ist am
Anfang des Abschnittes ber SGML-Referenzinformationen fr HTML enthalten (s. Abschnitt
19.2). Die letzten beiden Buchstaben der Deklaration geben die Sprache der DTD an. Fr
HTML ist dies immer Englisch („EN“).

< 84 > Die globale Struktur eines HTML-Dokuments


Page size: 168,00 x 240,00 mm

Anmerkung: Mit der Version vom 24. Dezember von HTML 4.01 verpflichtet sich die HTML-
Arbeitsgruppe zu folgendem Verfahren:
· Alle Mnderungen hin zu knftigen HTML 4-DTDs lassen Dokumente, die zu den DTDs der gegen-
w,rtigen Spezifikation konform sind, nicht ungltig werden. Die HTML-Arbeitsgruppe beh,lt sich

Die HTML 4.01- Spezifikation


das Recht vor, bekannte Fehler zu korrigieren.
· Zu den DTDs der gegenw,rtigen Spezifikation konforme Software kann Features knftiger HTML
4-DTDs, die sie nicht erkennt, ignorieren.
Das bedeutet, dass Autoren in der Dokumenttyp-Deklaration ruhig einen System-Bezeichner benutzen
k nnen, der auf die letzte Version einer HTML 4-DTD verweist. Autoren k nnen sich auch entschlie-
ßen, einen Systembezeichner zu verwenden, der auf eine bestimmte (veraltete) Version einer HTML
4-DTD verweist, wenn Gltigkeit gegenber dieser besonderen DTD erforderlich ist. W3C wird alle
Anstrengungen unternehmen, um archivierte Dokumente an ihren Originaladressen in ihrer Original-
form unbeschr,nkt verfgbar zu machen. n

7.3 Das HTML-Element


<!ENTITY % html.content "HEAD, BODY">

<!ELEMENT HTML O O (%html.content;) - - document root element - ->


<!ATTLIST HTML
%i18n; - - lang, dir - -
>

Start-Tag: optional, End-Tag: optional

Attributdefinitionen

version = cdata [CN]


Missbilligt. Der Wert dieses Attributs spezifiziert, welche HTML-DTD-Version fr das
aktuelle Dokument maßgebend ist. Dieses Attribut wurde missbilligt, weil es redundant zur
Versions-Information ist, die vom Dokument-Typ angeboten wird.

An anderer Stelle definierte Attribute


· lang (Sprachcode), dir (Leserichtung)

Der gesamte Rest eines HTML-Dokuments nach der Dokumenttyp-Deklaration wird vom
HTML-Element aufgenommen. Somit hat ein typisches HTML-Dokument diese Struktur:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"


"http://www.w3.org/TR/html4/strict.dtd">
<HTML>
...Kopf, Rumpf usw. stehen hier...
</HTML>

Das HTML-Element < 85 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

7.4 Der Dokument-Kopf


7.4.1 Das HEAD-Element
Die HTML 4.01- Spezifikation

<!- - %head.misc; defined earlier on as "SCRIPT|STYLE|META|LINK|OBJECT" - ->


<!ENTITY % head.content "TITLE & BASE?">

<!ELEMENT HEAD O O (%head.content;) +(%head.misc;) - - document head - ->


<!ATTLIST HEAD
%i18n; - - lang, dir - -
profile %URI; #IMPLIED - - named dictionary of meta info - -
>

Start-Tag: optional, End-Tag: optional

Attributdefinitionen

profile = uri [CT]


Dieses Attribut spezifiziert den Fundort eines oder – durch Leerzeichen getrennt – mehre-
rer Metadaten-Profile. Im Hinblick auf knftige Erweiterungen sollten Benutzerprogramme
den Wert als Liste ansehen, auch wenn diese Spezifikation nur den ersten URI als signifikant
betrachtet. Profile werden weiter unten in Abschnitt 7.4.4, „Meta-Daten“ diskutiert.

An anderer Stelle definierte Attribute


· lang (Sprachcode), dir (Leserichtung)

Das HEAD-Element enth@lt Informationen ber das aktuelle Dokument, wie seinen Titel, Schls-
selw=rter, die sinnvoll fr Suchmaschinen sein k=nnen, und andere Daten, die nicht als Doku-
mentinhalt betrachtet werden. Benutzerprogramme stellen Elemente, die im HEAD stehen, im
Allgemeinen nicht als Inhalt dar. Sie k=nnen jedoch Informationen aus dem HEAD ber andere
Mechanismen fr den Benutzer verfgbar machen.

Anmerkung der bersetzer: Das ist zum Beispiel das Head-Element der eng-
lischen Originalfassung der Seite zu Abschnitt 7 dieser Spezifikation:

<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>The global structure of an HTML document</title>
<link rel="previous" href="../types.html">
<link rel="next" href="dirlang.html">
<link rel="contents" href="../cover.html#toc">
<link rel="stylesheet" type="text/css" href="
http://www.w3.org/StyleSheets/TR/W3C-REC">
<link rel="STYLESHEET" href="../style/default.css" type="text/css">
</head>

Eine M=glichkeit, wie ein Benutzerprogramm (hier der Mozilla-Browser) dem Benutzer
die enthaltenen Informationen zug@nglich machen kann, zeigen die folgenden Abbildungen:

< 86 > Die globale Struktur eines HTML-Dokuments


Page size: 168,00 x 240,00 mm

Die HTML 4.01- Spezifikation


7.4.2 Das TITLE-Element

<!- - The TITLE element is not considered part of the flow of text.
It should be displayed, for example as the page header or
window title. Exactly one title is required per document.
- ->
<!ELEMENT TITLE - - (#PCDATA) -(%head.misc;) - - document title - ->
<!ATTLIST TITLE %i18n>

Start-Tag: erforderlich, End-Tag: erforderlich

Der Dokument-Kopf < 87 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

An anderer Stelle definierte Attribute


· lang (Sprachcode), dir (Leserichtung)

Jedes HTML-Dokument muss ein TITLE-Element im HEAD-Abschnitt haben.


Autoren sollten das TITLE-Element benutzen, um den Inhalt eines Dokuments zu beschreiben.
Die HTML 4.01- Spezifikation

Da Benutzer oft Dokumente aus dem Zusammenhang gerissen aufrufen, sollten Autoren
selbsterkl@rende Titel anbieten. So sollten Autoren anstelle eines Titels wie „Einfhrung“, der
nicht viel Information ber den Kontext bietet, einen Titel wie „Einfhrung in die Bienenhaltung
im Mittelalter“ w@hlen.

Anmerkung der bersetzer: Das TITLE-Element wird von Autoren oft vernach-
l@ssigt. Nicht selten trifft man Dokumente mit dem Title „Untitled“ an, das ist der Titel,
den eine Reihe von HTML-Editoren standardm@ßig einsetzen. Dem Benutzer wird
damit der Umgang mit den Dokumenten erschwert. Sie sind auch im Katalog der Lese-
zeichen, Favoriten oder wie immer er im konkreten Benutzerprogramm heißen mag,
„Untitled“. Hat ein Benutzer mehrere Fenster ge=ffnet, so wird ihm die Auswahl eines
konkreten ge=ffneten Dokuments nicht leicht gemacht, wenn es „Untitled“ ist. Wie das
bei vier offenen Fenstern, von denen nur eines ein Dokument mit aussagef@higem Titel
enth@lt, aussehen kann, zeigt das folgende Bild (hier Internet Explorer 5 unter Mac OS):

Aus Grnden der Zug@nglichkeit mssen Benutzerprogramme den Inhalt des TITLE-Elements
fr Benutzer immer verfgbar machen (TITLE-Elemente, die in einem Frame erscheinen, einge-
schlossen). Der Mechanismus dafr h@ngt vom Benutzerprogramm ab (z. B. als berschrift,
gesprochen).
Titel drfen Zeichen-Entities enthalten (fr Zeichen mit Akzentzeichen, Sonderzeichen usw.),
k=nnen aber keine andere Auszeichnung enthalten (Kommentare eingeschlossen). Hier ist ein
Beispiel fr einen Dokument-Titel:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"


"http://www.w3.org/TR/html4/strict.dtd">
<HTML>
<HEAD>
<TITLE>Eine Studie der Entwicklung der Population</TITLE>

< 88 > Die globale Struktur eines HTML-Dokuments


Page size: 168,00 x 240,00 mm

... andere Kopfelemente ...


</HEAD>
<BODY>
... Dokumentrumpf ...
</BODY>

Die HTML 4.01- Spezifikation


</HTML>

7.4.3 Das title-Attribut

Attributdefinition

title = text [CS]


Dieses Attribut bietet kommentierende Information ber das Element, fr das es gesetzt
ist.

Anders als das TITLE-Element, das Informationen ber ein ganzes Dokument bietet und nur ein-
mal vorkommen darf, kann das title-Attribut eine beliebige Anzahl von Elementen mit Kom-
mentaren versehen. Bitte sehen Sie in der Definition eines Elements nach, um zu berprfen,
ob es dieses Attribut untersttzt.
Werte des title-Attributs k=nnen von Benutzerprogrammen auf verschiedenste Art dar-
gestellt werden. Zum Beispiel zeigen visuelle Browser „title“ oft als „Tooltip“ (eine kurze
Nachricht, die erscheint, wenn das Zeigeger@t ber einem Objekt inneh@lt). Audio-Benutzer-
programme k=nnen die „title“-Information in entsprechendem Kontext sprechen. Zum Beispiel
erm=glicht das Setzen dieses Attributs fr einen Link Benutzerprogrammen (visuellen und nicht
visuellen), Benutzern etwas ber die Beschaffenheit der verlinkten Ressource zu sagen:

... Text ...


Hier ist ein Bild von
<A href="http://someplace.com/neatstuff.gif" title="ich beim Tauchen">
mir beim Tauchen letzten Sommer
</A>
... Text ...

Das title-Attribut hat keine zus@tzliche Funktion, wenn es mit dem LINK-Element benutzt wird,
um ein externes Stylesheet zu benennen. Details finden Sie in Abschnitt 12.3.2, „Links und
externe Stylesheets“.

Anmerkung der bersetzer: Das title-Attribut ist nicht zu verwechseln mit


dem alt-Attribut oder mit diesem gleich zu setzen. Da das title-Attribut von @lteren
g@ngigen Browsern nicht untersttzt wurde, der Wert des alt-Attributs von ihnen nicht
nur – wie es seinem eigentlichen Anliegen enstpricht – als Alternative gezeigt wurde,
sondern zum Beispiel auch bei Mausberhrung, benutzten Autoren das alt-Attribut
h@ufig „zweckentfremdet“. Wir raten dringend, an dieser Stelle zwischen beiden zu
unterscheiden. So k=nnten zum Beispiel title und alt fr ein Bild verwendet werden:

<img src="klassentreffen.jpg"
alt="Foto vom Klassentreffen"
title="Klassentreffen am 15.06.2002,
festgehalten von Peter Meier">

Der Dokument-Kopf < 89 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Kann das Bild nicht angezeigt werden, k=nnte eine sinnvolle visuelle Pr@sentation so wie
im folgenden Bild aussehen; der Text aus dem Wert des alt-Attributs ersetzt das Bild.
Anderenfalls wrde das Bild gezeigt und dazu der Text aus dem title-Attribut.
Die HTML 4.01- Spezifikation

Anmerkung: Um die Qualit,t der Sprachsynthese fr F,lle, die durch Standardtechniken mangelhaft
behandelt werden, zu verbessern, k nnen knftige HTML-Versionen ein Attribut fr Kodierung phoneti-
scher und prosodischer Informationen beinhalten. n

7.4.4 Meta-Daten

Anmerkung: Das Resource Description Framework des W3C (siehe [RDF10]) wurde im Februar
1999 W3C-Recommendation. RDF erlaubt Autoren, maschinenlesbare Meta-Daten ber HTML-Doku-
mente und andere ber ein Netzwerk erreichbare Ressourcen zu spezifizieren. n
HTML l@sst Autoren Meta-Daten – Informationen ber ein Dokument im Gegensatz zum Inhalt
des Dokuments – auf unterschiedliche Art spezifizieren.
Um zum Beispiel den Autor eines Dokuments anzugeben, kann man das META-Element wie folgt
benutzen:

<META name="Author" content="Dave Raggett">

Das META-Element spezifiziert eine Eigenschaft (hier „Author“) und ordnet ihr einen Wert zu
(hier „Dave Raggett“).
Diese Spezifikation definiert keine Sammlung gltiger Eigenschaften fr Meta-Daten. Die Bedeu-
tung einer Eigenschaft und der Satz gltiger Werte fr diese Eigenschaft sollten in einem Refe-
renz-Lexikon, Profil genannt, definiert werden. Beispielsweise wrde ein Profil, das entworfen
wurde, um Suchmaschinen bei der Indizierung von Dokumenten zu helfen, Eigenschaften wie
„author“, „copyright“, „keywords“ usw. definieren.

Anmerkung der bersetzer: Informationen ber die Arbeitsweise verschiedener


Suchmaschinen gibt es zum Beispiel auf www.searchengineworld.com.

< 90 > Die globale Struktur eines HTML-Dokuments


Page size: 168,00 x 240,00 mm

Spezifizierung von Meta-Daten


Im Allgemeinen erfolgt die Spezifizierung von Meta-Daten in zwei Schritten:
1. Deklarieren einer Eigenschaft und eines Wertes fr diese Eigenschaft. Das kann auf zwei
Arten geschehen:

Die HTML 4.01- Spezifikation


1. Im Innern eines Dokuments mit Hilfe des META-Elements.
2. Außerhalb eines Dokuments durch Verlinken von Meta-Daten mit Hilfe des LINK-Ele-
ments (siehe Abschnitt 6.12, „Link-Typen“).
2. Verweisen auf ein Profil, in dem die Eigenschaft und deren gltige Werte definiert sind. Um
ein Profil anzugeben, verwenden Sie das profile-Attribut des HEAD-Elements.
Beachten Sie, dass, wenn ein Profil fr das HEAD-Element definiert wird, dasselbe Profil fr alle
META- und LINK-Elemente im Dokument-Kopf gilt.
Es ist nicht erforderlich, dass Benutzerprogramme Mechanismen zur Untersttzung von Meta-
Daten haben. Fr den Fall, dass sie sich entschließen, Meta-Daten zu untersttzen, definiert
diese Spezifikation nicht, wie Meta-Daten interpretiert werden sollten.

Das META-Element
<!ELEMENT META - O EMPTY - - generic metainformation - ->
<!ATTLIST META
%i18n; -- lang, dir, for use with content - -
http-equiv NAME #IMPLIED -- HTTP response header name - -
name NAME #IMPLIED -- metainformation name - -
content CDATA #REQUIRED -- associated information - -
scheme CDATA #IMPLIED -- select form of content - -
>

Start-Tag: erforderlich, End-Tag: verboten

Attributdefinitionen
Die erlaubten Werte und ihre Interpretation fr die folgenden Attribute sind abh@ngig vom
Profile:

name = name [CS]


Dieses Attribut weist den Namen einer Eigenschaft aus. Diese Spezifikation listet gltige
Werte fr dieses Attribut nicht auf.
content = cdata [CS]
Dieses Attribut spezifiziert den Wert einer Eigenschaft. Diese Spezifikation listet gltige
Werte fr dieses Attribut nicht auf.
scheme = cdata [CS]
Dieses Attribut benennt ein Schema, das zur Interpretation des Wertes der Eigenschaft
herangezogen wird (Details finden Sie in den Ausfhrungen ber Profile).
http-equiv = name [CI]
Dieses Attribut kann anstelle des name-Attributs benutzt werden. HTTP-Server verwenden
dieses Attribut, um Informationen fr Header-Zeilen der HTTP-Antwort zusammenzutra-
gen.

Der Dokument-Kopf < 91 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

An anderer Stelle definierte Attribute


· lang (Sprachcode), dir (Leserichtung)

Das META-Element kann verwendet werden, um Eigenschaften eines Dokuments auszuweisen


(z. B. Autor, Verfallsdatum, eine Liste von Schlsselw=rtern usw.) und diesen Eigenschaften
Die HTML 4.01- Spezifikation

Werte zuzuweisen. Diese Spezifikation definiert keinen normativen Satz von Eigenschaften.
Jedes META-Element spezifiziert ein Eigenschaft/Wert-Paar. Das name-Attribute identifiziert die
Eigenschaft und das content-Attribut spezifiziert den Wert der Eigenschaft.
Zum Beispiel setzt die folgende Deklaration einen Wert fr die Author-Eigenschaft:

<META name="Author" content="Dave Raggett">

Das lang-Attribut kann zusammen mit META verwendet werden, um die Sprache fr den Wert
des content-Attributs zu spezifizieren. Das gestattet Sprachsynthesizern sprachabh@ngige Aus-
spracheregeln anzuwenden.
In diesem Beispiel ist der Name des Autors als franz=sisch deklariert:

<META name="Author" lang="fr" content="Arnaud Le Hors">

Anmerkung: Das META-Element ist ein allgemeiner Mechanismus zur Spezifizierung von Meta-Da-
ten. Jedoch handhaben einige HTML-Elemente und -Attribute bereits bestimmte Teile von Meta-Daten
und k nnen von Autoren anstelle von META benutzt werden, um diese Teile zu spezifizieren: das TITLE-
Element, das ADDRESS-Element, die Elemente INS und DEL, das title-Attribut und das cite-Attribut. n
Anmerkung: Wenn eine durch ein META-Element spezifizierte Eigenschaft einen Wert annimmt, der
ein URI ist, ziehen es manche Autoren vor, die Meta-Daten ber das LINK-Element zu spezifizieren. So
kann die folgende Deklaration von Meta-Daten:

<META name="DC.identifier"
content="http://www.ietf.org/rfc/rfc1866.txt">

auch so geschrieben werden:

<LINK rel="DC.identifier"
type="text/plain"
href="http://www.ietf.org/rfc/rfc1866.txt"> n

META und HTTP-Header


Das http-equiv-Attribut kann anstelle des name-Attributs verwendet werden; es hat eine beson-
dere Bedeutung, wenn Dokumente per Hypertext-Transfer-Protocol (HTTP) abgerufen wer-
den. HTTP-Server k=nnen den durch http-equiv-Attribut spezifizierten Namen der Eigenschaft
verwenden, um einen [RFC822]-Style-Header in der HTTP-Response zu erzeugen. Bitte lesen
Sie die Details zu gltigen HTTP-Headern in der Spezifikation ([RFC2616]) nach.

Die folgende Beispiel-META-Deklaration

<META http-equiv="Expires" content="Tue, 20 Aug 1996 14:25:27 GMT">

< 92 > Die globale Struktur eines HTML-Dokuments


Page size: 168,00 x 240,00 mm

wird diesen HTTP-Header ergeben:

Expires: Tue, 20 Aug 1996 14:25:27 GMT

Die HTML 4.01- Spezifikation


Caches k=nnen dies verwenden, um festzulegen, wann sie eine neue Kopie des zugeh=rigen
Dokuments heranholen.
Anmerkung: Manche Benutzerprogramme untersttzen die Verwendung von META, um die aktuelle
Seite nach einer festgelegten Anzahl von Sekunden zu erneuern – mit der Option, sie durch einen
anderen URI zu ersetzen. Autoren sollten diese Technik nicht benutzen, um Benutzer zu anderen Sei-
ten weiterzuleiten, weil das die Seite fr einige Benutzer unzug,nglich macht. Statt dessen sollte auto-
matische Weiterleitung durch den Einsatz serverseitiger Redirects realisiert werden. n

Anmerkung der bersetzer: Ohne die vorhergehende Anmerkung bergehen zu


wollen, sei folgender Hinweis gestattet: Eine serverseitige Umlenkung ist nicht fr alle
Autoren realisierbar. Wer seinen Server durch einen Web-Hosting-Anbieter betreiben
l@sst, hat unter Umst@nden keine M=glichkeit, auf die Server-Konfiguration zuzugreifen.
Beispielsweise l@sst sich der Apache durch Dateien mit dem Namen .htaccess in jedem
Verzeichnis konfigurieren. Ohne eine solche Option bleibt nur die Verwendung eines
Meta-Elements. Richtig eingesetzt l@sst sich auch etwaiger Schaden vermeiden. Folgen-
des Beispiel zeigt eine Umlenkung per Meta-Element:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">


<html>
<head>
<title>de.comp.lang.javascript</title>
<meta http-equiv="refresh" content="0; url=http://www.dcljs.de/">
</head>
<body bgcolor="white">
<p>Die neue Heimat der JavaScript-FAQ befindet sich
unter <a href="http://www.dcljs.de/">www.dcljs.de</a>.</p>
</body>
</html>

Das Meta-Element tritt hier an die Stelle des HTTP-Headers refresh. Nach null (0)
Sekunden soll die neue Seite http://www.dcljs.de/ geladen werden. Falls ein Programm
mit der Anweisung nichts anfangen kann, erkl@rt der Dokumentrumpf, dass sich die
gesuchte Seite unter einer neuen Adresse befindet. Auf diese Art kann jeder mit der
Information etwas anfangen.

META und Suchmaschinen


META wird h@ufig verwendet, um Schlsselw=rter anzugeben, die eine Suchmaschine zur Verbes-
serung der Qualit@t von Suchergebnissen nutzen kann. Wenn verschiedene META-Elemente
sprachabh@ngige Informationen ber ein Dokument anbieten, k=nnen Suchmaschinen anhand
des lang-Attributs filtern, um Suchergebnisse gem@ß den Sprachpriorit@ten des Benutzers anzu-
zeigen.

Der Dokument-Kopf < 93 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Zum Beispiel:

<!- - For speakers of US English - ->


<META name="keywords" lang="en-us"
content="vacation, Greece, sunshine">
Die HTML 4.01- Spezifikation

<!- - For speakers of British English - ->


<META name="keywords" lang="en"
content="holiday, Greece, sunshine">
<!- - For speakers of French - ->
<META name="keywords" lang="fr"
content="vacances, Gr&egrave;ce, soleil">

Die Effektivit@t von Suchmaschinen kann auch dadurch erh=ht werden, dass das LINK-Element
verwendet wird, um Links zu spezifizieren hin zu bersetzungen des Dokuments in andere
Sprachen, zu Versionen des Dokuments in anderen Formaten (z. B. PDF) und, wenn das Doku-
ment Teil einer Sammlung ist, zu einem geeigneten Startpunkt zum Bl@ttern in der Sammlung.
Mehr Hilfe bietet der Abschnitt „Suchmaschinen helfen, die eigene Website zu indexieren“ im
Anhang B.

META und PICS


Die Platform for Internet Content Selection (PICS, spezifiziert in [PICS]) ist eine Infrastruktur,
um Kennzeichnungen (labels, Meta-Daten) mit Internet-Inhalt zu verbinden. Ursprnglich ent-
worfen, um Eltern und Lehrern bei der Kontrolle zu helfen, was Kindern im Internet zug@nglich
gemacht wird, erleichtert sie auch andere Nutzungen von Kennzeichnungen, einschließlich
Code-Signierung, Privatsph@re, Schutz von geistigem Eigentum (code signing, privacy, and intel-
lectual property rights management).
Dieses Beispiel zeigt, wie man eine META-Deklaration dazu verwenden kann, eine PICS
1.1-Kennzeichnung einzubeziehen:

<HEAD>
<META http-equiv="PICS-Label" content='
(PICS-1.1 "http://www.gcf.org/v2.5"
labels on "1994.11.05T08:15-0500"
until "1995.12.31T23:59-0000"
for "http://w3.org/PICS/Overview.html"
ratings (suds 0.5 density 0 color/hue 1))
'>
<TITLE>... document title ...</TITLE>
</HEAD>

META und Standardinformationen


Das META-Element kann verwendet werden, um in folgenden F@llen die Standardinformation fr
ein Dokument zu spezifizieren:
·· Die Standard-Skript-Sprache (siehe Abschnitt 18.2.2)
Die Standard-Stylesheet-Sprache (siehe Abschnitt 14.2.1)
· Die Dokument-Zeichenkodierung (siehe Abschnitt 5)
Das folgende Beispiel gibt die Zeichenkodierung fr ein Dokument mit ISO-8859-5 an

<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-5">

< 94 > Die globale Struktur eines HTML-Dokuments


Page size: 168,00 x 240,00 mm

Meta-Daten-Profil
Das profile-Attribut des HEAD gibt den Fundort eines Meta-Daten-Profils an. Der Wert des
profile-Attributs ist ein URI. Benutzerprogramme k=nnen diesen URI auf zwei Arten benut-
zen:

Die HTML 4.01- Spezifikation


· Als globaler eindeutiger Name: Benutzerprogramme k=nnen den Namen erkennen (ohne
das Profil wirklich abzurufen) und basierend auf bekannten Konventionen fr dieses Profil
einige Aktivit@ten ausfhren. Zum Beispiel k=nnten Suchmaschinen eine Schnittstelle fr die
Suche in Katalogen von HTML-Dokumenten anbieten, wenn alle diese Dokumente dasselbe
Profil verwenden, um Katalogeintr@ge darzustellen.
· Als Link: Benutzerprogramme k=nnen das hinter dem URI stehende Profil laden und auf
der Grundlage der aktuellen Definitionen im Profil Aktivit@ten ausfhren (z. B. die Verwen-
dung des Profils im aktuellen HTML-Dokument erlauben). Formate fr Profile werden
durch diese Spezifikation nicht definiert.
Dieses Beispiel verweist auf ein hypothetisches Profil, das ntzliche Eigenschaften zur Doku-
ment-Indizierung definiert. Die Werte der durch dieses Profil definierten Eigenschaften – das
sind „author“, „copyright“, „keywords“ und „date“ – werden nachtr@glich durch META-Deklara-
tionen gesetzt.

<HEAD profile="http://www.acme.com/profiles/core">
<TITLE>How to complete Memorandum cover sheets</TITLE>
<META name="author" content="John Doe">
<META name="copyright" content="&copy; 1997 Acme Corp.">
<META name="keywords" content="corporate,guidelines,cataloging">
<META name="date" content="1994-11-06T08:49:37+00:00">
</HEAD>

Anmerkung: W,hrend diese Spezifikation geschrieben wird, ist es g,ngige Praxis, die in in
[RFC2616], Abschnitt 3.3. beschriebenen Datums-Formate zu verwenden. Weil diese Formate relativ
schwer zu verarbeiten sind, empfehlen wir Autoren, das [ISO8601]-Datums-Format zu benutzen.
Mehr Informationen finden Sie in Abschnitt 9.4 zum INS- und DEL-Element. n
Das scheme-Attribut erlaubt Autoren, Benutzerprogrammen mehr Kontext fr die korrekte
Interpretation von Meta-Daten anzubieten. Gelegentlich kann so eine Zusatzinformation kri-
tisch sein, n@mlich dann, wenn Meta-Daten in unterschiedlichen Formaten spezifiziert sein k=n-
nen. Zum Beispiel k=nnte ein Autor ein Datum im (nicht eindeutigen) Format „10-9-97“ spezifi-
zieren. Ist damit der 9. Oktober 1997 oder der 10. September 1997 gemeint? Der Wert
„Month-Day-Year“ des scheme-Attributs wrde die Mehrdeutigkeit des Datums-Wertes ver-
meiden.
Bei anderen Gelegenheiten kann das scheme-Attribut dem Benutzerprogramm hilfreiche, aber
unkritische Informationen bieten.
Zum Beispiel kann die folgende scheme-Deklaration Benutzerprogrammen helfen, festzustellen,
dass es sich bei dem Wert der „identifier“-Eigenschaft um einen ISBN-Code handelt:

<META scheme="ISBN" name="identifier" content="0-8230-2355-9">

Die Werte eines scheme-Attributs sind abh@ngig von der name-Eigenschaft und dem zugeh=rigen
Profile.

Der Dokument-Kopf < 95 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Anmerkung: Ein Beispiel fr ein Profil ist das Dublin Core (siehe [DCORE]). Dieses Profil definiert
einen Satz empfohlener Eigenschaften, bibliografische Beschreibungen in elektronischer Form und ist
dafr vorgesehen. die Interoperabilit,t zwischen unterschiedlichen Beschreibungsmodellen zu f r-
dern. n
Die HTML 4.01- Spezifikation

7.5 Der Dokumentrumpf


7.5.1 Das BODY-Element

<!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) - - document body - ->


<!ATTLIST BODY
%attrs; - - %coreattrs, %i18n, %events - -
onload %Script; #IMPLIED - - the document has been loaded - -
onunload %Script; #IMPLIED - - the document has been removed - -
>

Start-Tag: optional, End-Tag: optional

Attributdefinitionen

background = uri [CT]


Missbilligt. Der Wert dieses Attributs ist ein URI, der auf eine Graphik-Ressource (image)
zeigt. Die Graphik wird im Allgemeinen als Hintergrund gekachelt (in visuellen Browsern).
text = color [CI]
Missbilligt. Dieses Attribut legt die Vordergrundfarbe des Textes (fr visuelle Browser)
fest.
link = color [CI]
Missbilligt. Dieses Attribut legt die Textfarbe noch nicht besuchter Hyperlinks (fr visu-
elle Browser) fest.
vlink = color [CI]
Missbilligt. Dieses Attribut legt die Textfarbe besuchter Hyperlinks (fr visuelle Browser)
fest.
alink = color [CI]
Missbilligt. Dieses Attribut legt die Textfarbe von Hyperlinks fr den Moment fest, in dem
sie ausgew@hlt sind (fr visuelle Browser).

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Titel des Elemente)


style (inzeilige Formatierungsinformation)

·· bgcolor (Hintergrundfarbe)
onload, onunload (eingebettete Ereignisse)

· onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,


onkeydown, onkeyup (eingebettete Ereignisse)

< 96 > Die globale Struktur eines HTML-Dokuments


Page size: 168,00 x 240,00 mm

Der Rumpf eines Dokuments enth@lt den Inhalt des Dokuments. Ein Benutzerprogramm kann
den Inhalt auf unterschiedlichste Art pr@sentieren. Fr visuelle Browser zum Beispiel kann man
sich den Rumpf als Leinwand vorstellen, auf der der Inhalt erscheint: Text, Bilder, Farben, gra-
phische Darstellungen usw. Fr akustische Benutzerprogramme kann derselbe Inhalt gespro-

Die HTML 4.01- Spezifikation


chen werden. Inzwischen sind Stylesheets die bevorzugte Art, die Erscheinung eines Doku-
ments zu bestimmen, deswegen wurden die auf die Pr@sentation gerichtete Attribute fr BODY-
missbilligt.

MISSBILLIGTES BEISPIEL:
Das folgende HTML-Fragment zeigt die Verwendung der missbilligten Attribute. Es setzt die
Hintergrundfarbe der Zeichenfl@che auf Weiß, die Vordergrundfarbe des Textes auf Schwarz
und die Farbe der Hyperlinks zun@chst auf Rot, fr den Moment der Aktivierung auf Fuchsia
und auf Maroon, wenn erst einmal besucht.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<HTML>
<HEAD>
<TITLE>Eine Studie der Entwicklung der Population</TITLE>
</HEAD>
<BODY bgcolor="white" text="black"
link="red" alink="fuchsia" vlink="maroon">
... Dokumentrumpf ...
</BODY>
</HTML> n

Mit Hilfe von Stylesheets k=nnte derselbe Effekt folgendermaßen erreicht werden:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<HTML>
<HEAD>
<TITLE>Eine Studie der Entwicklung der Population</TITLE>
<STYLE type="text/css">
BODY { background: white; color: black}
A:link { color: red }
A:visited { color: maroon }
A:active { color: fuchsia }
</STYLE>
</HEAD>
<BODY>
... Dokumentrumpf ...
</BODY>
</HTML>

Die Verwendung externer (linked) Stylesheets gibt Ihnen die Flexibilit@t, die Darstellung ohne
berarbeitung des Ursprungs-HTML-Dokuments zu @ndern:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<HTML>
<HEAD>
<TITLE>Eine Studie der Entwicklung der Population</TITLE>
<LINK rel="stylesheet" type="text/css" href="smartstyle.css">

Der Dokumentrumpf < 97 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

</HEAD>
<BODY>
... Dokumentrumpf ...
</BODY>
</HTML>
Die HTML 4.01- Spezifikation

Framesets und HTML-R-mpfe: Dokumente, die Framesets enthalten, ersetzen das BODY-Ele-
ment durch das FRAMESET-Element. Mehr Informationen finden Sie im Abschnitt ber Frames. n

7.5.2 Element-Identifikatoren: das id- und das class-Attribut

Attributdefinitionen
id = name [CS]
Dieses Attribut ordnet dem Element einen Namen zu. Innerhalb des Dokuments muss die-
ser Name eindeutig sein.
class = cdata-list [CS]
Dieses Attribut ordnet einem Element einen Klassennamen oder einen Satz von Klassen-
namen zu. Dem- oder denselben Klassennamen kann eine beliebige Anzahl von Elementen
zugeordnet werden. Multiple Klassennamen mssen durch Leerzeichen voneinander
getrennt werden.

Das id-Attribut ordnet einem Element einen eindeutigen Identifikator zu (der durch einen
SGML-Parser verifiziert werden kann). Zum Beispiel unterscheiden sich die folgenden Abs@tze
durch ihre id-Werte:

<P id="myparagraph">Das ist ein eindeutig benannter Absatz.</P>


<P id="yourparagraph">Das ist ebenfalls ein eindeutig benannter Absatz.</P>

Das id-Attribute spielt in HTML verschiedene Rollen:


·· Als Stylesheet-Selektor
Als Ziel-Anker fr Hypertext-Links
·· Als M=glichkeit, eine einzelnes Element von einem Skript aus anzusprechen
Als Name eines deklarierten OBJECT-Elements
· Fr universelle Verarbeitung durch Benutzerprogramme (z. B. bei der Identifizierung von
Feldern bei der Extraktion von Daten aus HTML-Seiten fr Datenbanken, bei der berset-
zung von HTML-Dokumenten in andere Formate und so weiter)

Anmerkung der bersetzer: Das id-Attribut wird sehr h@ufig verwendet, um


Elemente per Skript anzusprechen. Gibt man dem Bild vom Klassentreffen von oben
eine id, kann man zum Beispiel mit Hilfe von JavaScript den Wert seines title-Attributs
anzeigen lassen.

<img src="klassentreffen.jpg"
id="foto"
alt="Foto vom Klassentreffen"
title="Klassentreffen am 15.06.2002,
festgehalten von Peter Meier">
<form>

< 98 > Die globale Struktur eines HTML-Dokuments


Page size: 168,00 x 240,00 mm

<input type="button" value="Bildtitel zeigen"


onclick="alert(document.getElementById('foto').title)">
</form>

Die HTML 4.01- Spezifikation


Das class-Attribut auf der anderen Seite ordnet einem Element einen oder mehrere Klassen-
Namen zu; das Element soll damit zu diesen Klassen geh=ren. Ein Klassen-Name kann von meh-
reren Elementen benutzt werden. In HTML spielt das class-Attribut verschiedene Rollen:
· Als Stylesheet-Selektor (wenn ein Autor einem Satz von Elementen Style-Informationen
zuordnen m=chte)
· Fr allgemeine Verwendung durch Benutzerprogramme
Im folgenden Beispiel wird das SPAN-Element zusammen mit dem id- und dem class-Attribut
zur Auszeichnung von Meldungen im Dokument benutzt. Die Nachrichten erscheinen sowohl
in englischer als auch in deutscher Version.

<!- - English messages - ->


<P><SPAN id="msg1" class="info" lang="en">Variable declared twice</SPAN>
<P><SPAN id="msg2" class="warning" lang="en">Undeclared variable</SPAN>
<P><SPAN id="msg3" class="error" lang="en">Bad syntax for variable name</SPAN>

<!- - Deutsche Meldungen - ->


<P><SPAN id="msg1" class="info" lang="de">Variable zweimal deklariert</SPAN>
<P><SPAN id="msg2" class="warning" lang="de">Nicht deklarierte Variable</SPAN>
<P><SPAN id="msg3" class="error" lang="de">Falsche Syntax fU Variablennamen</SPAN>

Die folgenden CSS-Style-Vorgaben wrden visuellen Benutzerprogrammen sagen, dass sie


informelle Meldungen grn, Warnungen gelb und Fehlermeldungen rot anzeigen sollen:

SPAN.info { color: green }


SPAN.warning { color: yellow }
SPAN.error { color: red }

Beachten Sie, dass das deutsche „msg1“ und das englische „msg1“ nicht im selben Dokument
erscheinen k=nnen, da sie denselben id-Wert haben. Vom id-Attribut k=nnen Autoren außer-
dem Gebrauch machen, um die Pr@sentation individueller Meldungen zu verfeinern, sie zu Ziel-
ankern zu machen usw.
Fast jedem HTML-Element k=nnen Identifikator und Klasseninformation zugeordnet werden.
Stellen Sie sich zum Beispiel vor, dass wir ein Dokument ber eine Programmiersprache erstel-
len. In das Dokument ist eine Anzahl formatierter (preformatted) Beispiele aufzunehmen. Zur
Formatierung der Beispiele verwenden wir das PRE-Element. Darber hinaus weisen wir allen
Instanzen des PRE-Elements, die zur Klasse „example“ geh=ren, eine Hintergrundfarbe (green) zu.

<HEAD>
<TITLE>... Dokumenttitel ...</TITLE>
<STYLE type="text/css">
PRE.example { background : green }
</STYLE>
</HEAD>

Der Dokumentrumpf < 99 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

<BODY>
<PRE class="example" id="example-1">
... Code ...
</PRE>
</BODY>
Die HTML 4.01- Spezifikation

Durch Setzen des id-Attributs fr dieses Beispiel k=nnen wir (1) einen Hyperlink darauf erzeu-
gen und (2) Formatierungsinformationen der Klasse durch Formatierungsinformationen fr die
Instanz berschreiben.

Anmerkung: Das id-Attribut benutzt denselben Namensraum wie das name-Attribut, wenn es fr
Ankernamen verwendet wird. Im Abschnitt 12.2.3, „Anker mit id-Attribut“ finden Sie mehr Informa-
tionen. n

7.5.3 Elemente auf Blockebene und inzeilige Elemente


(Block-Level/Inline)

Bestimmte HTML-Elemente, die im BODY erscheinen k=nnen, werden „Blockelemente“ (block-


level) genannt, w@hrend andere „inzeilig“ sind (Inline; auch bekannt als „text-level“). Die Unter-
scheidung basiert auf mehreren Gedanken.

Inhalts-Modell (content model)


Im Allgemeinen k=nnen Block-Elemente inzeilige (inline) Elemente und andere Block-Ele-
mente und inzeilige Elemente nur Daten und andere inzeilige Elemente enthalten. In dieser
strukturellen Unterscheidung ist die Idee enthalten, dass Block-Elemente „gr=ßere“ Struk-
turen schaffen als inzeilige Elemente.
Formatierung
Standardm@ßig werden Block-Elemente anders formatiert als inzeilige. Im Allgemeinen
beginnen Block-Elemente in einer neuen Zeile, Inzeilige Elemente tun das nicht. Informa-
tionen ber Leerr@ume, Zeilenumbrche und Block-Formatierungen finden Sie in Abschnitt
9, „Text“.
Schreibrichtung
Aus technischen Grnden, einer davon ist der [UNICODE]-Bidirektional-Textalgorithmus,
unterscheiden sich Block- und inzeilige Elemente darin, wie sie Information ber die Lese-
richtung vererben. Details dazu finden Sie in Abschnitt 8.2.2, „Vererbung von Informationen
zur Leserichtungen“.

Stylesheets stellen Werkzeuge zur Verfgung, die Wiedergabe beliebiger Elemente zu spezifi-
zieren, unter anderem auch, ob ein Element als Block oder inzeilig dargestellt wird. In manchen
F@llen, wie etwa die inzeilige Darstellung von Listenelementen, kann das angemessen sein, all-
gemein wird Autoren jedoch davon abgeraten, die konventionelle Interpretation von HTML-
Elementen auf diese Art zu berschreiben.
Die Onderung traditioneller Pr@sentationsgepflogenheiten fr Block- und Inline-Elemente hat
auch starke Auswirkungen auf den Bidirektional-Textalgorithmus. Mehr Informationen finden
Sie in Abschnitt 8.2.6, „Die Wirkung von Stylesheets auf die Bidirektionalit@t“.

< 100 > Die globale Struktur eines HTML-Dokuments


Page size: 168,00 x 240,00 mm

7.5.4 Gruppierung von Elementen: das DIV- und das SPAN-Element

<!ELEMENT DIV - - (%flow;)* - - generic language/style container - ->


<!ATTLIST DIV
%attrs; - - %coreattrs, %i18n, %events - -

Die HTML 4.01- Spezifikation


>
<!ELEMENT SPAN - - (%inline;)* - - generic language/style container - ->
<!ATTLIST SPAN
%attrs; - - %coreattrs, %i18n, %events - -
>

Start-Tag: erforderlich, End-Tag: erforderlich

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachincode), dir (Leserichtung)

·· title (Elementtitel)
style (Inzeilige Formatierungsinformation)

·· align (Ausrichtung)
onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,
onkeydown, onkeyup (eingebettete Ereignisse)

Das DIV- und das SPAN-Element bieten zusammen mit dem id- und dem class-Attribute einen all-
gemeinen Mechanismus, Dokumenten Struktur hinzuzufgen. Diese Elemente definieren Inhalt als
inzeilige (SPAN) oder Block-Elemente (DIV), erlegen dem Inhalt aber keine anderen Darstellungs-
vorgaben auf. So k=nnen Autoren diese Elemente zusammen mit Stylesheets, dem lang-Attribut
usw. dafr verwenden, HTML auf ihre eigenen Bedrfnisse und ihren Geschmack zuzuschneiden.
Nehmen wir zum Beispiel an, dass wir basierend auf einer Datenbank mit Client-Informationen
ein HTML-Dokument generieren wollten. Da HTML keine Elemente zur Identifikation solcher
Objekte wie „Client“, „Telefonnummer“, „Mailadresse“ usw. enth@lt, benutzen wir DIV und
SPAN, um die gewnschten Strukturierungs- und Pr@sentationsergebnisse zu erzielen. Um die
Information zu strukturieren, k=nnten wir das TABLE-Element wie folgt verwenden:

<!- - Example of data from the client database: - ->


<!- - Name: Stephane Boyera, Tel: (212) 555-1212, Email: sb@foo.org - ->

<DIV id="client-boyera" class="client">


<P><SPAN class="client-title">Client information:</SPAN>
<TABLE class="client-data">
<TR><TH>Last name:<TD>Boyera</TR>
<TR><TH>First name:<TD>Stephane</TR>
<TR><TH>Tel:<TD>(212) 555-1212</TR>
<TR><TH>Email:<TD>sb@foo.org</TR>
</TABLE>
</DIV>

<DIV id="client-lafon" class="client">


<P><SPAN class="client-title">Client information:</SPAN>
<TABLE class="client-data">
<TR><TH>Last name:<TD>Lafon</TR>
<TR><TH>First name:<TD>Yves</TR>
<TR><TH>Tel:<TD>(617) 555-1212</TR>

Der Dokumentrumpf < 101 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

<TR><TH>Email:<TD>yves@coucou.com</TR>
</TABLE>
</DIV>

Fr das Finetuning der Pr@sentation der Datenbankeintr@ge k=nnen wir sp@ter einfach Style-
Die HTML 4.01- Spezifikation

sheet-Deklarationen hinzufgen.
Ein weiteres Anwendungsbeispiel finden Sie weiter oben im Abschnitt ber die Attribute class und id.
Visuelle Benutzerprogramme fgen im Allgemeinen vor und nach dem DIV-Element einen Zei-
lenumbruch ein, zum Beispiel ist fr

<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>ccccc<P>ccccc</DIV>

eine typische Darstellungsform:

aaaaaaaaa
bbbbbbbbb
ccccc

ccccc

7.5.5 berschriften: Die Elemente H1, H2, H3, H4, H5, H6

<!ENTITY % heading "H1|H2|H3|H4|H5|H6">


<!- -
There are six levels of headings from H1 (the most important)
to H6 (the least important).
- ->

<!ELEMENT (%heading;) - - (%inline;)* - - heading - ->


<!ATTLIST (%heading;)
%attrs; - - %coreattrs, %i18n, %events - -
>

Start-Tag: erforderlich, End-Tag: erforderlich

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Elementtitel)
style (Inzeilige Formatierungsinformation)

·· align (Ausrichtung)
onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,
onkeydown, onkeyup (eingebettete Ereignisse)

Ein berschrift-Element beschreibt kurz das Thema des Abschnittes, den es er=ffnet. ber-
schriftsinformationen k=nnen von Benutzerprogrammen zum Beispiel dafr verwendet wer-
den, fr ein Dokument automatisch ein Inhaltsverzeichnis zu erstellen.
In HTML gibt es sechs berschriftebenen, von denen H1 die oberste und H6 die unterste ist.
Visuelle Benutzerprogramme stellen wichtigere berschriften meist in gr=ßerer Schrift dar als
weniger wichtige.

< 102 > Die globale Struktur eines HTML-Dokuments


Page size: 168,00 x 240,00 mm

Das folgende Beispiel zeigt, wie man das DIV-Element einsetzt, um die berschrift mit dem
darauffolgenden Abschnitt des Dokuments zu verbinden. Dieses Vorgehen erm=glicht es Ihnen,
fr den Abschnitt mit Hilfe von Stylesheets einen Stil (style) zu definieren (dem Hintergrund
eine Farbe zu geben, die Schriftart festzulegen usw.).

Die HTML 4.01- Spezifikation


<DIV class="section" id="forest-elephants" >
<H1>Forest elephants</H1>
<P>In this section, we discuss the lesser known forest elephants.
...this section continues...
<DIV class="subsection" id="forest-habitat" >
<H2>Habitat</H2>
<P>Forest elephants do not live in trees but among them.
...this subsection continues...
</DIV>
</DIV>

Diese Struktur kann wie folgt mit Formatierungsinformationen ausgestattet werden:

<HEAD>
<TITLE>... document title ...</TITLE>
<STYLE type="text/css">
DIV.section { text-align: justify; font-size: 12pt}
DIV.subsection { text-indent: 2em }
H1 { font-style: italic; color: green }
H2 { color: green }
</STYLE>
</HEAD>

Numerierte Abschnitte und Referenzen


HTML selbst bewirkt nicht, dass Abschnittsnummern aus Hberschriften generiert werden. Diese M g-
lichkeit kann jedoch von Benutzerprogrammen angeboten werden. Bald werden Stylesheet-Sprachen
wie CSS es Autoren erlauben, die Generierung von Abschnittsnummern zu steuern (ntzlich fr Vor-
w,rts-Referenzen in gedruckten Dokumenten wie z. B. „siehe Abschnitt 7.2“).

Manche werten das Hberspringen von Hberschriftsebenen als schlechten Stil. Sie akzeptieren H1 H2 H1,
aber nicht H1 H3 H1, weil die Hberschriftsebene H2 bersprungen wird. n

7.5.6 Das ADDRESS-Element

<!ELEMENT ADDRESS - - (%inline;)* - - information on author - ->


<!ATTLIST ADDRESS
%attrs; - - %coreattrs, %i18n, %events - -
>

Start-Tag: erforderlich, End-Tag: erforderlich

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

· title (Elementtitel)

Der Dokumentrumpf < 103 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

·· style (Inzeilige Formatierungsinformation)


onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,
onkeydown, onkeyup (eingebettete Ereignisse)

Autoren k=nnen das ADDRESS-Element benutzen, um Kontaktinformationen fr ein Dokument


Die HTML 4.01- Spezifikation

oder fr einen bedeutenden Teil eines Dokuments, wie zum Beispiel ein Formular, bereitzustel-
len. Dieses Element erscheint oft am Anfang oder Ende eines Dokuments.
Zum Beispiel k=nnte eine Seite der Website des W3C, die Bezug hat zu HTML, die folgende
Kontaktinformation enthalten:

<ADDRESS>
<A href="../People/Raggett/">Dave Raggett</A>,
<A href="../People/Arnaud/">Arnaud Le Hors</A>,
contact persons for the <A href="Activity">W3C HTML Activity</A><BR>
$Date: 1999/12/24 23:07:14 $
</ADDRESS>

8 Sprachinformation und Leserichtung


Dieser Abschnitt des Dokuments er=rtert zwei wichtige Themen, die die Internationalisierung
von HTML betreffen: Die Spezifizierung der Sprache (lang-Attribut) und der Leserichtung (dir-
Attribut) von Text in einem Dokument.

8.1 Spezifizierung der Sprache des Inhalts: das


lang-Attribut
Attributdefinitionen

lang = Sprachcode [CI]


Dieses Attribut spezifiziert die Basis-Sprache der Attributwerte und des Textinhaltes eines
Elements. Der Standardwert dieses Attributs ist unknown.

Durch lang-Attribut spezifizierte die Sprachinformation kann von Benutzerprogrammen auf


vielf@ltige Art genutzt werden, um die Darstellung zu steuern. Einige Situationen, in denen vom
Autor bereitgestellte Sprachinformation hilfreich sein k=nnen, seien im Folgenden genannt:
·· Die Untersttzung von Suchmaschinen
Die Untersttzung von Sprachsynthesizern
· Die Untersttzung eines Benutzerprogramms bei der Auswahl von Glyphen fr qualitatv
hochwertige Typographie
· Die Untersttzung eines Benutzerprogramms bei der Auswahl eines Satzes von Anfh-
rungszeichen
· Die Untersttzung eines Benutzerprogramms bei Entscheidungen in Bezug auf Silbentren-
nung, Ligatur und Abst@nde
· Die Untersttzung von Rechtschreib- und Grammatikprfern

< 104 > Sprachinformation und Leserichtung


Page size: 168,00 x 240,00 mm

Das lang-Attribut spezifiziert die Sprache des Elementinhalts und der Attributwerte; ob es fr
ein gegebenes Attribut relevant ist, h@ngt von Syntax und Semantik des Attributs und der
daraus resultierenden Operation ab.
Anliegen des lang-Attributs ist es, Benutzerprogrammen zu gestatten, Inhalt auf der Basis bli-

Die HTML 4.01- Spezifikation


cher kultureller Gewohnheiten einer gegebenen Sprache sinnvoller darzustellen. Das bedeutet
nicht, dass Benutzerprogramme Zeichen, die fr eine bestimmte Sprache atypisch sind, in weni-
ger sinnvoller Art darstellen sollen; Benutzerprogramme mssen den besten Weg suchen, um
alle Zeichen darzustellen, ungeachtet des in lang spezifizierten Wertes.
Wenn zum Beispiel griechische Buchstaben innerhalb von englischem Text stehen:

<P><Q lang="en">Her super-powers were the result of


&gamma;-radiation,</Q> he explained.</P>

sollten Benutzerprogramme (1) versuchen, den englischen Inhalt in angemessener Art und
Weise darzustellen (z. B. in seiner Behandlung der Anfhrungszeichen) und mssen (2) ver-
suchen, g – obgleich kein englischer Buchstabe – darzustellen.

Anmerkung der bersetzer: Die Sprachinformation in obigem Beispiel k=nnte


auch dafr genutzt werden, englische Anfhrungszeichen um den Inhalt des Q-Elements
(quote) zu setzen. Dies ist auch mit CSS m=glich. Verwandte Informationen finden Sie
in der CSS2-Spezifikation im Abschnitt 5.11.4.

Hiermit in Zusammenhang stehende Informationen finden Sie im Abschnitt 5.4, „Nicht darstell-
bare Zeichen“.

8.1.1 Sprachcodes

Der Wert des lang-Attributs ist ein Sprachcode, der eine natrliche gesprochene, geschriebene
oder auf andere Art zur Verst@ndigung von Menschen verwendete Sprache kennzeichnet.
Computer-Sprachen sind explizit von Sprachcodes ausgeschlossen.
[RFC1766] definiert und erkl@rt die Sprachcodes, die in HTML-Dokumenten verwendet wer-
den mssen.
Kurz gefasst, bestehen Sprachcodes aus einem prim@ren Code und einer – m=glicherweise lee-
ren – Serie von Unter-Codes:

language-code = primary-code ( "-" subcode )*

Hier sinde einige Beipiele fr Sprachcodes:


·· „en“: Englisch
„en-US“: US-Englisch
·· „en-cockney“: Cockney-English
„i-navajo“: Die Navajo-Sprache, gesprochen von einigen Ureinwohnern Amerikas
· „x-klingon“: Das vorangestellte „x“ weist auf eine experimentelle Sprache hin.

Spezifizierung der Sprache des Inhalts < 105 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Anmerkung der bersetzer: Dass es sich bei Klingonisch um eine experimentelle


Sprache handelt, sollten Sie niemals gegenber einem Klingonen behaupten. Die gleiche
Behauptung wird bei einer gewissen Gruppe der Cineasten zu einer ebenso ablehnen-
Die HTML 4.01- Spezifikation

den Reaktion fhren, drfte aber weniger gef@hrlich sein als gegenber einem Klingo-
nen. Wer es ausprobieren m=chte, sollte also mit einem Cineasten anfangen. ;-)
Da Sie in Mitteleuropa vermutlich h@ufiger mit Deutschen und Schweizern als mit Klin-
gonen zusammentreffen, sehen Sie nachfolgend noch ein Beispiel fr einen deutschen
Satz. Er stammt (hinsichtlich der Auszeichnungen leicht abgewandelt) aus der deutschen
XML-Spezifikation:

<p lang="de-DE">In welcher Straße hast du geparkt?</p>


<p lang="de-CH">In welcher Strasse hast du parkiert?</p>

Beachten Sie bitte, dass die Sprachauszeichnung nicht fr Dialekte verwendet wird.

Aus zwei Zeichen bestehende Sprachcodes sind fr [ISO639] Sprachkrzel reserviert. Zwei-
Zeichen-Codes beinhalten fr (Franz=sisch), de (Deutsch), it (Italienisch), nl (Niederl@ndisch), el
(Griechisch), es (Spanisch), pt (Portugiesisch), ar (Arabisch), he (Hebr@isch), ru (Russisch), zh
(Chinesisch), ja (Japanisch), hi (Hindi), ur (Urdu), und sa (Sanskrit).
Jeder Zwei-Zeichen-Subcode wird als [ISO3166] L@ndercode (country code) aufgefasst.

8.1.2 Vererbung von Sprachcodes

Ein Element bekommt Sprachcode-Informationen in folgender Rangfolge (vom h=chsten zum


niedrigsten):
·· von einem fr das Element selbst gesetzten lang-Attribut
vom n@chsten Eltern-Element, in dem das lang-Attribut gesetzt ist (d. h., das lang-Attribut
wird vererbt)
· vom HTTP-„Content-Language“-Header (der in einem Server konfiguriert sein kann). Zum
Beispiel:

Content-Language: en-cockney

· von Standardwerten von Benutzerprogrammen und Benutzereinstellungen


In diesem Beispiel ist die prim@re Sprache des Dokuments Franz=sisch („fr“). Ein Absatz ist als
Spanisch („es“) deklariert; danach kehrt die prim@re Sprache zu Franz=sisch zurck. Der
darauffolgende Absatz enth@lt eine eingebundene japanische Wendung („ja“), danach kehrt die
prim@re Sprache zu Franz=sisch zurck.

< 106 > Sprachinformation und Leserichtung


Page size: 168,00 x 240,00 mm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"


"http://www.w3.org/TR/html4/strict.dtd">
<HTML lang="fr">
<HEAD>
<TITLE>Un document multilingue</TITLE>

Die HTML 4.01- Spezifikation


</HEAD>
<BODY>
...interpretiert als Franz0sisch...
<P lang="es">...interpretiert als Spanisch...
<P>...wieder interpretiert als Franz0sisch...
<P>...franz0sischer Text unterbrochen von <EM lang="ja">etwas
Japanisch</EM> hier beginnt wieder Franz0sisch...
</BODY>
</HTML>

Anmerkung: Tabellenzellen k nnen lang-Werte nicht von Eltern-Elementen erben, sondern erhalten
sie von der ersten Zelle eines Bereiches. Einzelheiten finden Sie im Abschnitt 11.3.2 unter „Vererbung
von Ausrichtungsangaben“. n

8.1.3 Interpretation von Sprachcodes

Im HTML-Kontext sollten Benutzerprogramme einen Sprachcode eher als Hierarchie von


Merkmalen interpretieren denn als einzelnes Merkmal. Wenn ein Benutzerprogramm seine
Darstellungsweise gem@ß einer Sprachinformation einstellt (sagen wir, durch Vergleich von
Stylesheet-Sprachcodes und lang-Werten), sollte es immer exakte bereinstimmung favorisie-
ren, aber auch passende Prim@r-Codes als ausreichend ansehen. Ein Benutzerprogramm sollte
also, wenn der Wert des lang-Attributs fr das HTML-Eelement als „en-US“ gesetzt ist, Style-In-
formationen, die zu „en-US“ passen, den zum allgemeineren „en“ passenden vorziehen.

Anmerkung: Sprachcode-Hierarchien garantieren nicht, dass alle Sprachen mit einem allgemeinen
Pr,fix von denen ["von den Menschen"] verstanden werden, die eine oder mehrere dieser Sprachen
beherrschen. Sie erlauben einem Benutzer, die allgemeinere Form anzufordern, falls dieser Fall [Nicht-
Verstehen der Sprache] fr den Benutzer vorliegt. n

Anmerkung der bersetzer: Cockney ist eine Sprache, die in einigen Teilen von
London gesprochen wurde beziehungsweise wird. Ein Benutzer, der „en-US“ beherrscht,
muss „en-cockney“ nicht unbedingt verstehen. (Man stelle sich den Klischee-Texaner vor,
der London besucht.) Der Benutzer sollte dann aber „en“ anfordern k=nnen.
Die g@ngigen Web-Browser erlauben, eine sortierte Vorgabe der bevorzugten Sprachen
anzugeben. Zum Beispiel Mozilla:

Spezifizierung der Sprache des Inhalts < 107 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>
Die HTML 4.01- Spezifikation

8.2 Spezifizierung der Richtung von Text und Tabellen:


das dir-Attribut
Attributdefinitionen

dir = LTR | RTL [CI]


Dieses Attribut spezifiziert die Basisrichtung von richtungsneutralem Text (d. h., von Text,
der keine eigene Richtung, wie in [UNICODE] definiert, hat) im Inhalt eines Elements und
Atributwerten. Es spezifiziert auch die Richtung von Tabellen. M=gliche Werte:
·· LTR: Text oder Tabelle, von links nach rechts zu lesen
RTL: Text oder Tabelle, von rechts nach links zu lesen

Zus@tzlich zur Spezifizierung der Sprache eines Dokuments mit Hilfe des lang-Attributs kann es
notwendig sein, dass Autoren die Basisrichtung (von links nach rechts oder von rechts nach
links) fr Teile des Textes eines Dokuments oder eine Tabellenstruktur usw. spezifizieren. Dies
wird mit Hilfe des dir-Attributs erledigt.
Die [UNICODE]-Spezifikation ordnet Zeichen Richtung zu und definiert einen (komplexen)
Algorithmus zur Bestimmung der geeigneten Richtung von Text. Wenn ein Dokument kein
darstellbares von rechts nach links zu lesendes Zeichen (right-to-left character) enth@lt, ist es
nicht erforderlich, dass ein konformes Benutzerprogramm den [UNICODE]-Bidirektional-Al-
gorithmus anwendet. Wenn ein Dokument von rechts nach links zu lesende Zeichen enth@lt
und das Benutzerprogramm diese Zeichen anzeigt, muss das Benutzerprogramm den Bidirek-
tional-Algorithmus verwenden.

< 108 > Sprachinformation und Leserichtung


Page size: 168,00 x 240,00 mm

Obgleich Unicode spezielle Zeichen spezifiziert, die sich mit der Leserichtung befassen, bietet
HTML h=herwertige Auszeichnungskonstrukte an, die dasselbe tun: das dir-Attribut (nicht zu
verwechseln mit dem DIR-Element) und das BDO-Element. Um ein hebr@isches Zitat auszudr-
cken, ist es somit intuitiver, zu schreiben:

Die HTML 4.01- Spezifikation


<Q lang="he" dir="rtl">...ein hebr3isches Zitat...</Q>

als dasselbe mit Unicode-Verweisen:

&#x202B;&#x05F4;...ein hebr3isches Zitat...&#x05F4;&#x202C;

Benutzerprogramme drfen das lang-Attribut nicht verwenden, um die Leserichtung zu


bestimmen.
Das dir-Attribut ist vererbt und kann berschrieben werden. Details finden Sie weiter unten
im Abschnitt ber die Vererbung von Informationen zur Leserichtung.

8.2.1 Einf-hrung in den Bidirektionial-Algorithmus

Das folgende Beispiel illustriert das erwartete Verhalten des Bidirektional-Algorithmus. Es


umfasst Englisch, eine von links nach rechts zu lesende Schrift, und Hebr@isch, eine von rechts
nach links zu lesende Schrift.
Betrachten Sie den folgenden Beispieltext:

english1 HEBREW2 english3 HEBREW4 english5 HEBREW6

Die Zeichen in diesem Beispiel (und in allen verwandten Beispielen) sind im Computer so
gespeichert, wie sie hier gezeigt werden: Das erste Zeichen in der Datei ist „e“, das zweite „n“
und das letzte „6“.
Wir setzen voraus, die vorherrschende Sprache des Dokuments, das diesen Absatz enth@lt, ist
Englisch. Das bedeutet, die Basisrichtung verl@uft von links nach rechts. Die korrekte Pr@senta-
tion dieser Zeile w@re:

english1 2WERBEH english3 4WERBEH english5 6WERBEH


<------ <------ <------
H H H
------------------------------------------------->
E

Die gestrichelten Linien kennzeichnen die Struktur dieses Satzes: Englisch herrscht vor, etwas
hebr@ischer Text ist eingebettet. Um die korrekte Pr@sentation zu erzielen, ist keine zus@tzliche
Auszeichnung erforderlich, weil die hebr@ischen Passagen von Benutzerprogrammen durch
Anwendung des Bidirektional-Algorithmus korrekt umgekehrt werden.
Wenn andererseits hebr@isch die vorherrschende Sprache des Dokuments ist, ist die Basisrich-
tung von rechts nach links. Die korrekte Pr@sentation hierfr:

Das dir-Attribut < 109 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

6WERBEH english5 4WERBEH english3 2WERBEH english1


-------> -------> ------->
E E E
<-------------------------------------------------
H
Die HTML 4.01- Spezifikation

In diesem Fall wurde der ganze Satz von rechts nach links darestellt und die eingebetteten eng-
lischen Passagen vom Bidirektional-Algorithmus richtig umgekehrt.

8.2.2 Vererbung von Informationen zur Leserichtung

Der Unicode-Bidirektional-Algorithmus erfordert eine Basistextrichtung fr Textbl=cke. Um


die Basisrichtung eines Block-Level-Elements zu spezifizieren, setzen Sie das dir-Attribut des
Elements. Der Standardwert des dir-Attributs ist „ltr“ (von links nach rechts zu lesender
Text).
Wenn das dir-Attribut fr ein Block-Level-Element gesetzt ist, ist es fr dieses Element bis zu
dessen Ende und fr alle eingeschlossenen Block-Level-Elemente wirksam. Das Setzen des dir-
Attributs fr ein eingeschlossenes Element berschreibt den ererbten Wert.
Um die Basistextrichtung fr ein ganzes Dokument zu setzen, setzen Sie das dir-Attribut im
HTML-Element.
Beispiel:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"


"http://www.w3.org/TR/html4/strict.dtd">
<HTML dir="RTL">
<HEAD>
<TITLE>...ein von rechts nach links zu lesender Titel...</TITLE>
</HEAD>
...von rechts nach links zu lesender Text...
<P dir="ltr">...von links nach rechts zu lesender Text...</P>
<P>...wieder von rechts nach links zu lesender Text...</P>
</HTML>

Andererseits erben Inline-Elemente das dir-Attribut nicht. Das heißt, ein Inline-Element ohne
dir-Attribut er=ffnet hinsichtlich des Bidirektional-Algorithmus keine zus@tzliche Einbettungs-
ebene. (Ein Element wird hier in Abh@ngigkeit von seiner Standardpr@sentation als Block-Level-
oder Inline-Element betrachtet. Beachten Sie, dass das INS- und das and DEL-Element in Abh@n-
gigkeit vom Kontext Block-Level- oder Inline-Elemente sein k=nnen.)

8.2.3 Setzen der Richtung von eingebettetem Text

Der [UNICODE]-Bidirektional-Algorithmus kehrt eingebettete Zeichenfolgen gem@ß ihrer


eigenen Richtung automatisch um (wie im vorangegangenen Beispiel gezeigt). Im Allgemeinen
kann jedoch nur eine Einbettungsebene bercksichtigt werden. Um zus@tzliche Ebenen einge-
betteter Richtungswechsel zu erzeugen, mssen Sie in einem Inline-Element vom dir-Attribut
Gebrauch machen.
Betrachten Sie dasselbe Beispiel wie zuvor:

english1 HEBREW2 english3 HEBREW4 english5 HEBREW6

< 110 > Sprachinformation und Leserichtung


Page size: 168,00 x 240,00 mm

Wir setzen voraus, die vorherrschende Sprache des Dokuments, das diesen Absatz enth@lt, ist
englisch. Außerdem enth@lt der obige englische Satz einen hebr@ischen Abschnitt, der sich von
HEBREW2 bis HEBREW4 erstreckt, und der hebr@ische Abschnitt enth@lt ein englisches Zitat
(english3). Die gewnschte Darstellung des Textes ist diese:

Die HTML 4.01- Spezifikation


english1 4WERBEH english3 2WERBEH english5 6WERBEH
------->
E
<-----------------------
H
------------------------------------------------->
E

Um zwei eingebettete Richtungswechsel zu erreichen, mssen wir zus@tzliche Informationen


verwenden. Das tun wir, indem wir die zweite Einbettung explizit begrenzen. In diesem Beispiel
verwenden wir das SPAN-Element und das dir-Attribut, um den Text auszuzeichnen:

english1 <SPAN dir="RTL">HEBREW2 english3 HEBREW4</SPAN> english5 HEBREW6

Autoren k=nnen auch spezielle Unicode-Zeichen benutzen, um mehrfach eingebettete Rich-


tungswechsel zu erreichen. Um Links-nach-rechts-Einbettung zu erzielen, schließen Sie den ein-
gebetteten Text in die Zeichen LEFT-TO-RIGHT EMBEDDING („LRE“, hexadecimal 202A)
und POP DIRECTIONAL FORMATTING („PDF“, hexadecimal 202C) ein. Um Rechts-nach-
links-Einbettung zu erzielen, schließen Sie den eingebetteten Text in die Zeichen RIGHT-TO-
LEFT EMBEDDING („RTE“, hexadecimal 202B) und PDF ein.

Verwendung der HTML-Richtungs-Auszeichnung mit Unicode-Zeichen: Autoren und


Entwickler von Autoren-Software sollten sich bewußt sein, dass Konflikte auftreten k nnen, wenn das
dir-Attribut in Inline-Elementen (einschl. BDO) gleichzeitig mit den entsprechenden [UNICODE]-Forma-
tierungszeichen eingesetzt wird. Vorzugsweise sollte entweder das eine oder das andere exklusiv
benutzt werden. Die Auszeichnungsmethode bietet eine bessere Gew,hr fr die strukturelle Integrit,t
des Dokuments und mindert manche Probleme, wenn bidirektionaler Text mit einem einfachen Text-
Editor bearbeitet wird; manche Software k nnte jedoch geschickter im Umgang mit [UNICODE]-Zei-
chen sein. Wenn beide Methoden benutzt werden, sollte große Sorgfalt gebt werden, um eine saubere
Verschachtelung von Auszeichnung und Richtungseinbettung und -berschreibung zu sichern. Anderen-
falls sind die Darstellungergebnisse undefiniert. n

Anmerkung der bersetzer: Der oben erw@hnte Konflikt besteht in dem Wider-
spruch, der auftreten kann, wenn auf Zeichenebene die Richtung links-nach-rechts (zum
Beispiel mit dem genannten Zeichen an Position 202A) angegeben wird, gleichzeitig das
dir-Attribut den Wert „RTL“ besitzt.

Das dir-Attribut < 111 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

8.2.4 berschreiben des Bidirektional-Algorithmus: das


BDO-Element

<!ELEMENT BDO - - (%inline;)* -- I18N BiDi over-ride -->


Die HTML 4.01- Spezifikation

<!ATTLIST BDO
%coreattrs; - - id, class, style, title - -
lang %LanguageCode; #IMPLIED - - language code - -
dir (ltr|rtl) #REQUIRED - - directionality - -
>

Start-Tag: erforderlich, End-Tag: erforderlich

Attributdefinitionen

dir = LTR | RTL [CI]


Dieses zwingende Attribut spezifiziert die Basisrichtung fr den Text-Inhalt des Elements.
Diese Richtung berschreibt die eigene Richtung von Zeichen wie in [UNICODE] definiert.
M=gliche Werte:
·· LTR: Text oder Tabelle, von links nach rechts zu lesen
RTL: Text oder Tabelle, von rechts nach links zu lesen

An anderer Stelle definierte Attribute


· lang (Sprachcode)

Der Bidirektional-Algorithmus und das dir-Attribut gengen im Allgemeinen, um eingebettete


Richtungswechsel zu handhaben. Es k=nnten jedoch einige Situationen entstehen, in denen der
Bidirektional-Algorithmus eine inkorrekte Darstellung bewirkt. Das BDO-Element gestattet
Autoren, den Bidirektional-Algorithmus fr ausgew@hlte Textpassagen auszuschalten.
Betrachten wir ein Dokument, das denselben Text enth@lt wie eben:

english1 HEBREW2 english3 HEBREW4 english5 HEBREW6

nehmen jedoch an, dass dieser Text bereits in visueller Reihenfolge vorliegt. Ein Grund dafr
kann sein, dass der MIME-Standard ([RFC2045], [RFC1556]) visuelle Reihenfolge begnstigt,
z. B., dass von rechts nach links zu lesende Zeichenfolgen von rechts nach links in den Byte-
strom aufgenommen werden. In EMail k=nnte der obige Text – Zeilenwechsel einbezogen – so
formatiert werden:

english1 2WERBEH english3


4WERBEH english5 6WERBEH

Das kollidiert mit dem [UNICODE]-Bidirektional-Algorithmus, weil dieser Algorithmus


2WERBEH, 4WERBEH, und 6WERBEH ein zweites Mal umkehren und so die hebr@ischen W=rter von
links nach rechts darstellen wrde anstatt von rechts nach links.
Die L=sung in diesem Fall ist, den Bidirektional-Algorithmus dadurch zu berschreiben, dass
man den EMail-Auszug in ein PRE-Element setzt (zur Erhaltung der Zeilenumbrche) und jede
Zeile in ein BDO-Element, dessen dir-Attribute auf LTR gesetzt ist:

< 112 > Sprachinformation und Leserichtung


Page size: 168,00 x 240,00 mm

<PRE>
<BDO dir="LTR">english1 2WERBEH english3</BDO>
<BDO dir="LTR">4WERBEH english5 6WERBEH</BDO>
</PRE>

Die HTML 4.01- Spezifikation


Das sagt dem Bidirektional-Algorithmus „Lass mich von links nach rechts!“ und wrde die
gewnschte Darstellung erzeugen:

english1 2WERBEH english3


4WERBEH english5 6WERBEH

Das BDO-Element sollte in Szenarien verwendet werden, in denen absolute Kontrolle ber die
Reihenfolge gefordert ist (z. B. mehrsprachige part numbers). Das dir-Attribut ist zwingend fr
dieses Element.
Autoren k=nne auch spezielle Unicode-Zeichen verwenden, um den Bidirektional-Algorithmus
zu berschreiben – LEFT-TO-RIGHT OVERRIDE (202D) oder RIGHT-TO-LEFT OVERRIDE
(hexadecimal 202E). In beiden F@llen beendet das Zeichen POP DIRECTIONAL FORMAT-
TING (hexadecimal 202C) das berschreiben.

Anmerkung: Erinnern Sie sich, dass Konflikte auftreten k nnen, wenn das dir-Attribut in Inline-Ele-
menten (einschl. BDO) gleichzeitig mit den entsprechenden [UNICODE]-Formatierungszeichen einge-
setzt wird. n
Bidirektionalit.t und Zeichenkodierung: Gem,ß [RFC1555] und [RFC1556] gibt es spezielle
Konventionen fr die Verwendung von „Zeichensatz“-Parameterwerten, um bidirektionale Behandlung
in MIME-Mail zu kennzeichen, insbesondere zur Unterscheidung zwischen visueller, impliziter und
expliziter Richtung. Der Parameterwert „ISO-8859-8“ (fr Hebr,isch) heißt visuelle Kodierung,
„ISO-8859-8-i“ heißt implizite Bidirektionalit,t und „ISO-8859-8-e“ heißt explizite Richtung.
Weil HTML den Unicode-Bidirektional-Algorithmus verwendet, mssen unter Verwendung von ISO
8859-8 kodierte konforme Dokumente als „ISO-8859-8-i“ ausgewiesen sein. Explizite Kontrolle der
Richtung ist auch mit HTML m glich, kann aber nicht mit ISO 8859-8 ausgedrckt werden, deswegen
sollte „ISO-8859-8-e“ nicht verwendet werden.
Der Wert „ISO-8859-8“ impliziert, dass das Dokument visuell formatiert ist, einige Auszeichnungen
dabei missbrauchend (wie TABLE mit Rechtsbndigkeit und ohne Zeilenumbruch), um eine verst,ndliche
Darstellung durch ,ltere Benutzerprogramme, die Bidirektionalit,t nicht behandeln, zu gew,hrleisten.
Solche Dokumente entsprechen nicht der gegenw,rtigen Spezifikation. Wenn erforderlich, k nnen sie
zur aktuellen Spezifikation konform gemacht werden (und gleichzeitig werden sie von ,lteren Benut-
zerprogrammen korrekt dargestellt werden), indem, wo n tig, BDO-Auszeichnungen hinzugefgt wer-
den.Im Gegensatz zu dem, was in [RFC1555] und [RFC1556] gesagt wird, kommt bei ISO-8859-6
(Arabisch) keine „Visual“-Reihenfolge zum Einsatz. n

Anmerkung der bersetzer: Die letzte Bemerkung bezglich arabischer Kodie-


rung wird verst@ndlich, wenn man in den beiden genannten RFCs nachliest: „Visual“
wird dort (RFC 1556) definiert als Anzeigemodus, bei dem die prim@re Anzeigerichtung
(links nach rechts) fr die Zeichenreihenfolge und die Darstellung verwendet wird. Der
Modus ist unabh@ngig davon, welche Inhaltsrichtung den Daten zugrundeliegt. Das
bedeutet, dass das Benutzerprogramm die Zeichen in der Reihenfolge anzeigen kann, in
der die Bytes bei ihm eintreffen. Bei Sprachen, die von rechts nach links schreiben, wer-

Das dir-Attribut < 113 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

den die Texte also „von hinten nach vorne“ (links nach rechts) angezeigt. Das Autoren-
werkzeug muss sich darum kmmern, die von rechts nach links eingegebenen Zeichen
in anderer Reihenfolge abzuspeichern.
Die HTML 4.01- Spezifikation

8.2.5 Zeichenreferenzen f-r die Richtung und f-r die Steuerung von
Verbindungen (joining control)

Da manchmal Mehrdeutigkeiten bezglich der Richtung bestimmter Zeichen enstehen (z. B.


Zeichensetzung), enth@lt die [UNICODE]-Spezifikation Zeichen, die eine korrekte Entschei-
dung erm=glichen. Unicode enth@lt auch einige Zeichen, um, wenn erforderlich, das Verhalten
in Bezug auf die Verbindung von Zeichen zu steuern (z. B. in einigen F@llen arabischer Buchsta-
ben). HTML 4 beinhaltet Zeichenreferenzen fr diese Zeichen.
Der folgende DTD-Auszug zeigt einige der Richtungs-Entities (directional entities):

<!ENTITY zwnj CDATA "&#8204;"- -=zero width non-joiner- ->


<!ENTITY zwj CDATA "&#8205;"- -=zero width joiner- ->
<!ENTITY lrm CDATA "&#8206;"- -=left-to-right mark- ->
<!ENTITY rlm CDATA "&#8207;"- -=right-to-left mark- ->

Das zwnj-Entity wird verwendet, um das Verbinden in Umgebungen zu verhindern, in denen es


durchgefhrt werden wrde, jedoch nicht durchgefhrt werden soll. Das zwj-Entity bewirkt
das Gegenteil; es erzwingt das Verbinden, wenn es nicht durchgefhrt werden wrde, jedoch
durchgefhrt werden soll. Zum Beispiel wird der arabische Buchstabe „HEH“ als Abkrzung
des islamischen Kalendersystems „Hijri“ benutzt. Da die alleinstehende Form von „HEH“ aus-
sieht wie die Ziffer fnf in arabischer Schrift (basierend auf indischen Ziffern), wird, um Fehl-
deutungen von „HEH“ als letzte Ziffer fnf einer Jahreszahl vorzubeugen, die ursprngliche
Form von „HEH“ benutzt. Wie dem auch sei, es gibt keinen folgenden Kontext (z. B. einen
vebindenden Buchstaben) mit dem das „HEH“ verbunden werden kann. Das zwj-Zeichen liefert
diesen Kontext.
Ohnlich gibt es in persischen Texten F@lle, in denen ein Buchstabe, der normalerweise in einer
kursiven Verbindung mit einem nachfolgenden stehen wrde, dies nicht tun sollte. Das Zeichen
zwnj wird verwendet, um das Verbinden in diesen F@llen zu verhindern.
Die anderen Zeichen lrm und rlm werden benutzt, um fr richtungsneutrale Zeichen eine Rich-
tung zu erzwingen. Wenn zum Beispiel ein doppeltes Anfhrungszeichen zwischen einem ara-
bischen (von rechts nach links) und einem lateinischen (von links nach rechts) Buchstaben steht,
ist die Richung des Anfhrungszeichens nicht klar (Bezieht es sich auf den arabischen oder auf
den lateinischen Text?). Die Zeichen lrm und rlm haben eine Richtungseigenschaft, jedoch keine
Breiten- und Wort- bzw. Zeilenumbrucheigenschaft. Detaillierte Informationen finden Sie
unter [UNICODE].

Gespiegelte Zeichenglyphen: Im Allgemeinen spiegelt der Bidirektional-Algorithmus Zeichengly-


phen nicht, sondern l,sst sie unangetastet. Ausnahmen bilden Zeichen wie runde Klammern (siehe
[UNICODE], Tabelle 4-7). Wird eine Spiegelung gewnscht, beispielsweise fr ,gyptische Hierogly-
phen, das griechische Bustrophedon oder spezielle Designeffekte, sollte dies ber Stil-Vorgaben (styles)
geregelt werden. n

< 114 > Sprachinformation und Leserichtung


Page size: 168,00 x 240,00 mm

8.2.6 Die Wirkung von Stylesheets auf die Bidirektionalit.t

Im Allgemeinen ist die Verwendung von Stylesheets zur Onderung der visuellen Wiedergabe
eines Elements von Block-Level zu Inline oder umgekehrt unkompliziert. Da der Bidirektional-

Die HTML 4.01- Spezifikation


Algorithmus jedoch auf die Unterscheidung zwischen Inline- und Block-Level baut, sollte die
Umwandlung mit besonderer Sorgfalt geschehen.
Wenn ein Inline-Element, das kein dir-Attribut besitzt, durch ein Stylesheet in den Stil (style)
eines Block-Level-Elements transformiert wird, erbt es das dir-Attribut von seinem n@chstlie-
genden Eltern-Block-Element, um die Basisrichtung des Blocks festzulegen.
Wenn ein Block-Eelement ohne dir-Attribut durch ein Stylesheet in den Stil eines Inline-Ele-
ments transformiert wird, sollte die resultierende Darstellung in Bezug auf die bidirektionale
Formatierung @quivalent zu der Formatierung sein, die durch explizites Hinzufgen eines dir-
Attributs (Zuweisung des ererbten Wertes) zum transformierten Element erzielt wird.

9 Text
Die folgenden Abschnitte behandeln Fragen rund um die Strukturierung von Text. Elemente,
die Text darstellen (Ausrichtungselemente, Font-Elemente, Stylesheets und so weiter) werden
an anderen Stellen der Spezifikation behandelt (siehe Abschnitte 14 und 15). Informationen zu
Zeichen finden Sie im Abschnitt 5.1, „Der Dokumentzeichensatz“.

9.1 Leeraum (white space)


Der Dokumentzeichensatz enth@lt ein großes Spektrum von Leerraumzeichen (white space
characters). Viele davon sind typographische Elemente und werden in einigen Anwendungen
benutzt, um spezielle Abstand-Wirkungen zu erzielen. In HTML sind nur die folgenden Zeichen
als Leerraumzeichen definiert:
·· ASCII Leerzeichen (&#x0020;)
ASCII Tabulatorschritt (&#x0009;)
·· ASCII Blattwechsel (&#x000C;)
Zero-width space (&#x200B;)
Zeilenwechsel (siehe Abschnitt 9.3.2) sind ebenfalls Leerraumzeichen. Beachten Sie, dass in
[ISO10646] auch &#x2028; und &#x2029; definiert sind, um Zeilen bzw. Abs@tze eindeutig zu
trennen, diese l=sen in HTML keinen Zeilenwechsel aus, die Spezifikation nimmt sie auch nicht
in eine allgemeinere Kategorie von Leerraumzeichen auf.
Diese Spezifikation gibt kein Verhalten bezglich Darstellung oder Sonstigem fr andere
Abstandszeichen (space characters) als die explizit benannten Leerraumzeichen vor. Aus die-
sem Grund sollten Autoren zur Erzielung visueller Formatierungen, die Leerr@ume beinhalten,
geeignete Elemente und Stile den Leerzeichen vorziehen.
Folgen von Leerr@umen trennen fr alle HTML-Elemente außer PRE-„Worte“ (wir verwenden
den Begriff „Wort“ („word“) hier fr „Folgen von Nicht-Leerraumzeichen“). Bei der Formatie-
rung von Text sollten Benutzerprogramme diese Worte erkennen und so anordnen, wie es fr
die spezielle geschriebene Sprache (Schrift) und das Zielmedium blich ist.

Text < 115 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Dieses Layout kann beinhalten, dass Worte durch Abst@nde getrennt werden (genannt Wort-
zwischenraum) (inter-word space); die Konventionen fr Wortzwischenr@ume variieren
jedoch von Schrift zu Schrift. Zum Beispiel wird in lateinischen Schriften Wortzwischenraum
blicherweise als ASCII-Leeraum (&#x0020;) dargestellt, w@hrend es in Thai ein Wordtrenner
Die HTML 4.01- Spezifikation

mit Null-Breite (&#x200B;) ist. In japanischer und chinesischer Schrift wird Wortzwischenraum
berhaupt nicht besonders dargestellt.
Beachten Sie, dass eine Folge von Leerr@umen zwische Worten im Quelldokument v=llig unter-
schiedliche Darstellungen des Wortzwischenraumes ergeben kann (außer beim PRE-Element).
Insbesondere sollten Benutzerprogramme eingelesene Leerraumfolgen bei der Erzeugung des
Wortzwischenraumes fr die Ausgabe reduzieren (collapse). Das kann und soll sogar bei feh-
lender Sprachinformation (aus dem lang-Attribute, dem HTTP-„Content-Language“-Header-
Feld (siehe [RFC2616], Abschnitt 14.12), Einstellungen im Benutzerprogramm und so weiter)
erfolgen.
Das PRE-Element wird fr vorformatierten Text (preformatted text) verwendet, in dem Leer-
@ume signifikant sind (siehe Abschnitt 9.3.4).
Um Probleme mit SGML-Regeln fr Zeilenumbruch (SGML line break rules) und Inkonsisten-
zen zwischen bestehenden Implementationen zu vermeiden, sollten Autoren sich nicht darauf
verlassen, dass Benutzerprogramme Leeraum unmittelbar nach einem Start-Tag oder direkt
vor einem End-Tag anzeigen (siehe auch Abschnitt „Zeilenumbrche“ in Anhang B). So sollten
Autoren und insbesondere Autorenwerkzeuge schreiben:

<P>Wir bieten kostenlosen <A>technischen Support</A> fUr Abonnenten.</P>

Und nicht etwa:

<P>Wir bieten kostenlosen<A> technischen Support </A>fUr Abonnenten.</P>

9.2 Strukturierter Text


9.2.1 Inzeilige Elemente (phrase elements): EM, STRONG, DFN,
CODE, SAMP, KBD, VAR, CITE, ABBR und ACRONYM

<!ENTITY % phrase "EM | STRONG | DFN | CODE |


SAMP | KBD | VAR | CITE | ABBR | ACRONYM" >
<!ELEMENT (%fontstyle;|%phrase;) - - (%inline;)*>
<!ATTLIST (%fontstyle;|%phrase;)
%attrs; - - %coreattrs, %i18n, %events - -
>

Start-Tag: erforderlich, End-Tag: erforderlich

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Elementtitel)
style (inzeilige Formatierungsinformation)

· onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,


onkeydown, onkeyup (eingebettete Ereignisse)

< 116 > Text


Page size: 168,00 x 240,00 mm

Inzeilige Elemente geben Textfragmenten Strukturinformationen. Die gebr@uchlichen Bedeu-


tungen der inzeiligen Elemente sind:

EM:

Die HTML 4.01- Spezifikation


Kennzeichnet Betonungen.
STRONG:
Kennzeichnet st@rkere Betonungen.
CITE:
Enth@lt ein Zitat aus anderen Quellen beziehungsweise eine Referenz auf andere Quellen.
DFN:
Kennzeichnet die definierende Instanz des eingeschlossenen Terms.
CODE:
Kennzeichnet einen Auszug aus Computer-Code.
SAMP:
Kennzeichnet ein Ausgabebeispiel von Programmen, Skripten und so weiter
KBD:
Kennzeichnet vom Benutzer eingegebenen Text.
VAR:
Kennzeichnet eine Instanz einer Variablen oder eines Programm-Arguments.
ABBR:
Kennzeichnet eine Abkrzung (zum Beispiel WWW, HTTP, URI und so weiter).
ACRONYM:
Kennzeichnet ein Akronym (zum Beispiel WAC, Radar und so weiter).

EM und STRONG werden benutzt, um Betonungen zu kennzeichnen. Die anderen Wortgruppen-


Elemente haben insbesondere in technischen Dokumenten Bedeutung. Diese Beispiele ver-
anschaulichen einige der Wortgruppen-Elemente:

As <CITE>Harry S. Truman</CITE> said,


<Q lang="en-us">The buck stops here.</Q>

Weitere Informationen finden Sie in <CITE>[ISO-0000]</CITE>.

Geben Sie bitte folgende Bearbeitungsnummer


an: <STRONG>1-234-55</STRONG>

Die Darstellung der Wortgruppen-Elemente ist abh@ngig vom Benutzerprogramm. Im All-


gemeinen stellen visuelle Benutzerprogramme EM-Text kursiv und STRONG-Text fett dar. Benut-
zerprogramme mit Sprachsynthesizer k=nnen die Syntheseparameter wie etwa Lautst@rke,
Tonh=he und Tempo entsprechend @ndern.
Das ABBR- und das ACRONYM-Element gestatten es Autoren, Abkrzungen und Akronyme deutlich
zu kennzeichnen. Westliche Sprachen machen intensiven Gebrauch von Akronymen wie
„GmbH“, „NATO“ und „F.B.I.“ ebenso wie von Abkrzungen wie „M.“, „Inc.“, „et al.“, „etc.“.
Sowohl chinesisch als auch japanisch verwenden analoge Abkrzungsmechanismen, in denen
ein langer Name sp@ter durch einen Teil der Han-Zeichen des vollst@ndigen Namens repr@sen-
tiert wird. Die Auszeichnung dieser Konstrukte liefert ntzliche Informationen fr Benutzer-
programme und Tools wie Rechtschreibkontrollen, Sprachsynthesizer, bersetzungssysteme
und Indexierer von Suchmaschinen.

Strukturierter Text < 117 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Der Inhalt des ABBR- bzw. ACRONYM-Elements spezifiziert den Abkrzungsausdruck selbst, so, wie
er normal im Fließtext erscheinen wrde. Das title-Attribut dieser Elemente kann verwendet
werden, um die Langform des Ausdrucks anzubieten.
Beispiele fr die Verwendung von ABBR sind:
Die HTML 4.01- Spezifikation

<P>
<ABBR title="World Wide Web">WWW</ABBR>
<ABBR lang="fr"
title="Soci&eacute;t&eacute; Nationale des Chemins de Fer">
SNCF
</ABBR>
<ABBR lang="es" title="Do&ntilde;a">Do&ntilde;a</ABBR>
<ABBR title="Abbreviation">abbr.</ABBR>

Anmerkung der bersetzer: Das title-Attribut von ACRONYM-Elementen wird von


Web-Browsern zum Beispiel dazu benutzt, die Langform des Akronyms als Tooltip
anzuzeigen, sobald der Mauszeiger ber dem Akronym steht. Außerdem werden solche
Akronyme gelegentlich auch punktiert unterstrichen. Nachfolgend ein Beispiel von der
W3C-Site und die Darstellung im Mozilla. Der punktierte Unterstrich ist hier kaum
erkennbar, weil das Akronym gleichzeitig ein unterstrichener Link ist.

<acronym title="Document Object Model">DOM</acronym>

Beachten Sie, dass Abkrzungen und Akronyme oft ihre eigene gesprochene Form haben. Zum
Beispiel werden „IRS“ und „BBC“ im allgemeinen Buchstabe fr Buchstabe gesprochen und
„NATO“ und „UNESCO“ phonetisch. Wieder andere abgekrzte Formen (zum Beispiel „URI“
and „SQL“) werden von einigen buchstabiert und von anderen als Worte gesprochen. Wenn
notwendig, sollten Autoren Stylesheets verwenden, um die Aussprache der abgekrzten Form
anzugeben.

< 118 > Text


Page size: 168,00 x 240,00 mm

9.2.2 Zitate: Das BLOCKQUOTE- und das Q-Element

<!ELEMENT BLOCKQUOTE - - (%block;|SCRIPT)+ - - long quotation - ->


<!ATTLIST BLOCKQUOTE
%attrs; - - %coreattrs, %i18n, %events - -

Die HTML 4.01- Spezifikation


cite %URI; #IMPLIED - - URI for source document or msg - -
>
<!ELEMENT Q - - (%inline;)* - - short inline quotation - ->
<!ATTLIST Q
%attrs; - - %coreattrs, %i18n, %events - -
cite %URI; #IMPLIED - - URI for source document or msg - -
>

Start-Tag: erforderlich, End-Tag: erforderlich

Attributdefinitionen

cite = uri [CT]


Der Wert dieses Attributs ist ein URI, der ein Quelldokument oder eine Nachricht kenn-
zeichnet. Der Sinn dieses Atrributs besteht darin, Informationen ber die Quelle, aus der
das Zitat entnommen wurde, zu geben.

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Elementtitel)
style (inzeilige Formatierungsinformation)

· onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,


onkeydown, onkeyup (eingebettete Ereignisse)

Diese beiden Elemente kennzeichnen zitierten Text.BLOCKQUOTE ist vorgesehen fr lange Zitate
(Block-Level-Inhalt) und Q fr kurze Zitate, der keine Absatzwechsel erfordert (inzeiliger
Inhalt).
Dieses Beispiel zeichnet einen Auszug aus „Die zwei Trme“ von J.R.R. Tolkien als BLOCKQUOTE aus.

<BLOCKQUOTE cite="http://www.mycom.com/tolkien/twotowers.html">
<P>Einer hinter dem anderen liefen sie wie Jagdhunde auf einer
frischen F]hrte, und ihre Augen leuchteten vor Ungeduld. Fast genau
nach Westen hatten die marschierenden Orks ihre h]ßliche, breite Spur
getrampelt; das duftige Gras von Rohan war zertreten und schwarz
geworden, als sie vorUbergingen.</P>
</BLOCKQUOTE>

Darstellung von Zitaten


Visuelle Benutzerprogramme stellen BLOCKQUOTE im Allgemeinen als eingerckten Block dar.
Visuelle Benutzerprogramme mssen sicherstellen, dass der Inhalt des Q-Elements mit begren-
zenden Anfhrungszeichen dargestellt wird. Autoren sollten am Anfang und am Ende des
Inhalts eines Q-Elements keine Anfhrungszeichen schreiben.

Strukturierter Text < 119 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Anmerkung der bersetzer: Leider sind nicht alle zur Zeit g@ngigen Browser
dazu in der Lage. In folgendem Beispielcode ignorieren einige „Q“ vollst@ndig.
Die HTML 4.01- Spezifikation

<H3>&Uuml;ber das Leben</H3>


<DL>
<DT>Erich Fromm</DT>
<DD>
<Q>Leben bedeutet st&auml;ndige Ver&auml;nderung,
immerw&auml;hrende Geburt. Tod bedeutet Aufh&ouml;ren des Wachstums,
Verkn&ouml;cherung, Wiederholung.</Q>
</DD>
<DT>Antoine de Saint-Exup&eacute;ry</DT>
<DD>
<Q LAN="fr">Leben hei&szlig;t langsam Geborenwerden.
Es w&auml;re allzu bequem, fixfertige Seelen auszuleihen.</Q>
</DD>
</DL>

So k=nnte der Codeschnipsel widergegeben werden:

Diese Darstellung ist inkorrekt:

< 120 > Text


Page size: 168,00 x 240,00 mm

Benutzerprogramme sollten Anfhrungszeichen in der sprachspezifischen Art darstellen (siehe


lang-Attribut). Viele Sprachen w@hlen unterschiedliche Zitierstile fr @ußere und innere (einge-
schlossene) Zitate, die von Benutzerprogrammen respektiert werden sollten.

Die HTML 4.01- Spezifikation


Anmerkung der bersetzer: Vergleichen Sie zu diesem Thema auch den
Abschnitt 12.4 in der CSS2-Spezifikation.

Das folgende Beispiel zeigt eingeschlossene Zitate mit dem Q-Element.

John said, <Q lang="en-us">I saw Lucy at lunch, she told me


<Q lang="en-us">Mary wants you
to get some ice cream on your way home.</Q> I think I will get
some at Ben and Jerry's, on Gloucester Road.</Q>

Da die Sprache beider Zitate „American English“ ist, sollten Benutzerprgramme sie entspre-
chend rendern, zum Beispiel durch einfache Anfhrungszeichen fr das innere Zitat und dop-
pelte Anfhrungszeichen fr das @ußere Zitat:

John said, "I saw Lucy at lunch, she told me 'Mary wants you
to get some ice cream on your way home.' I think I will get some
at Ben and Jerry's, on Gloucester Road."

Anmerkung der bersetzer: Diese „Hrde“ bew@ltigen leider noch weniger der
derzeit gebr@uchlichen Browser. Auch diejenigen, die Anfhrungszeichen fr Zitate set-
zen, bercksichtigen das lang-Attribut dabei meistens nicht.
So sollte es aussehen:

Anmerkung: Wir empfehlen, dass Stylesheet-Implementationen einen Mechanismus fr das Einset-
zen von Anfhrungszeichen vor und nach einem durch BLOCKQUOTE begrenzten Zitat anbieten, der der
aktuellen Sprache und dem Grad der Verschachtelung entspricht.

Strukturierter Text < 121 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Weil jedoch einge Autoren BLOCKQUOTE lediglich als Mechanismus zum Einrcken von Text benutzt
haben, sollten Benutzerprogramme, um die Absicht der Autoren zu wahren, im Standard-Style keine
Anfhrungszeichen einsetzen.
Die Verwendung von BLOCKQUOTE fr das Einrcken von Text ist zu Gunsten von Stylesheets missbilligt. n
Die HTML 4.01- Spezifikation

9.2.3 Hoch- und Tiefstellen, das SUB- und das SUP-Element

<!ELEMENT (SUB|SUP) - - (%inline;)* - - subscript, superscript - ->


<!ATTLIST (SUB|SUP)
%attrs; - - %coreattrs, %i18n, %events - -
>

Start-Tag: erforderlich, End-Tag: erforderlich

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Elementtitel)
style (inzeilige Formatierungsinformation)

· onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,


onkeydown, onkeyup (eingebettete Ereignisse)

Viele Schriften (zum Beispiel franz=sisch) erfordern Hoch- oder Tiefstellungen fr eine saubere
Darstellung. Um Text in solchen F@llen auszuzeichnen, sollten das SUB- und das SUP-Element
benutzt werden.

H<SUB>2</SUB>O
E = mc<SUP>2</SUP>
<SPAN lang="fr">M<SUP>lle</SUP> Dupont</SPAN>

Anmerkung der bersetzer: So k=nnte eine korrekte Darstellung in einem visu-


ellen Benutzerprogramm aussehen:

9.3 Zeilen und Abs.tze


Traditionell teilen Autoren ihre Gedankeng@nge in Abschnitte und Abs@tze auf. Die Gliederung
von Informationen in Abs@tze wird nicht von ihrer Art der Darstellung beeinflusst: Abs@tze im
Blocksatz enthalten dieselben Gedanken wie links ausgerichtete.
Die HTML-Auszeichnung, um einen Absatz zu definieren, ist unkompliziert: das P-Element defi-
niert einen Absatz.
Die visuelle Pr@sentation von Abs@tzen ist nicht so einfach. Eine Anzahl von Punkten, sowohl
stilistische als auch technische, muss beachtet werden:

< 122 > Text


Page size: 168,00 x 240,00 mm

·· Behandlung von Leerraum


Zeilenumbruch und word wrapping
·· Ausrichtung
Silbentrennung
··

Die HTML 4.01- Spezifikation


Konventionen der Schriftsprache und Leserichtung
Formatierung von Abs@tzen unter Beachtung des umgebenden Inhalts
Wir wenden uns diesen Fragen im Folgenden zu. Absatzausrichtung und gleitende Objekte
(floating objects) werden sp@ter in diesem Dokument behandelt.

9.3.1 Abs.tze: das P-Element

<!ELEMENT P - O (%inline;)* - - paragraph - ->


<!ATTLIST P
%attrs; - - %coreattrs, %i18n, %events - -
>

Start-Tag: erforderlich, End-Tag: optional

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Elementtitel)
style (inzeilige Formatierungsinformation)

·· align (Ausrichtung)
onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,
onkeydown, onkeyup (eingebettete Ereignisse)

Das P-Element repr@sentiert einen Absatz. Es kann keine Block-Level-Elemente enthalten (ein-
schließlich P selbst).
Wir raten Autoren von der Verwendung leerer P-Elemente ab. Benutzerprogramme sollten
leere P-Elemente ignorieren.

9.3.2 Zeilenumbr-che kontrollieren

Ein Zeilenumbruch ist definiert als Wagenrcklauf (carriage return, &#x000D;), ein Zeilenvor-
schub (line feed, &#x000A;) oder ein Wagenrcklauf/Zeilenvorschub-Paar. Alle Zeilenumbr-
che sind Leerraum.
Mehr Informationen ber die Spezifikation von Zeilenumbrchen in SGML finden Sie in Anhang
B unter „Zeilenumbrche“.

Erzwingen eines Zeilenumbruchs: das BR-Element


<!ELEMENT BR - O EMPTY - - forced line break - ->
<!ATTLIST BR
%coreattrs; - - id, class, style, title - -
>

Start-Tag: erforderlich, End-Tag: verboten

Zeilen und Abs,tze < 123 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
title (Elementtitel)

·· style (inzeilige Formatierungsinformation)


Die HTML 4.01- Spezifikation

clear (Ausrichtung und gleitende Objekte )

Das BR-Element bricht (beendet) zwingend die aktuelle Textzeile um.


Fr visuelle Benutzerprogramme kann das clear-Attribut verwendet werden, um zu bestim-
men, ob dem BR-Element folgender Inhalt um am linken oder rechten Rand ausgerichtete Bilder
und andere Objekte fließt oder ob es unterhalb solcher Objekte beginnt. Weitere Details zu
Ausrichtung und gleitenden Objekten sind in Abschnitt 15, „Formatierung“ zu finden. Autoren
wird geraten, Stylesheets zu verwenden, um den Textfluss um gleitende Objekte zu steuern.
Mit Rcksicht auf bidirektionale Formatierung sollte sich das BR-Element verhalten wie das Zei-
chen[ISO10646] LINE SEPARATOR im Bidirektionalalgorithmus.

Zeilenumbruch verhindern
Manchmal wollen Autoren verhindern, dass ein Zeilenumbruch zwischen zwei Worten
erscheint. Das &nbsp;-Entity (&#160; oder &#xA0;) fungiert als Zwischenraum, an dem Benut-
zerprogramme keinen Zeilenumbruch veranlassen.

9.3.3 Silbentrennung

In HTML gibt es zwei Typen von Trennzeichen: den normalen Trennstrich und das weiche
Trennzeichen (soft hyphen). Der normale Trennstrich sollte von den Benutzerprogrammen
wie jedes andere Zeichen behandelt werden. Das weiche Trennzeichen zeigt dem Benutzer-
programm wo, ein Zeilenumbruch auftreten kann.
Diejenigen Browser, die weiche Trennzeichen interpretieren, mssen folgende Semantik
beachten: Wenn eine Zeile an einem weichen Trennzeichen umgebrochen wird, muss ein
Trennstrich am Ende der ersten Zeile stehen. Wenn eine Zeile an einem weichen Trennzei-
chen nicht umgebrochen wird, darf das Benutzerprogramm keinen Trennstrich ausgeben. Bei
Operationen wie Suchen und Sortieren sollte das weiche Trennzeichen immer ignoriert wer-
den.
In HTML wird der normale Trennstrich durch das „-“-Zeichen (&#45; or &#x2D;) repr@sen-
tiert. Das weiche Trennzeichen wird repr@sentiert durch die Zeichen-Entity-Referenz &shy;
(soft hyphen, &#173; oder &#xAD;)

< 124 > Text


Page size: 168,00 x 240,00 mm

Anmerkung der bersetzer: Hier ein Beispiel zur Illustration:

<P>Ein Beispiel fUr Silben&shy;trennung</P>

Die HTML 4.01- Spezifikation


Die korrekte Widergabe sollte so erfolgen:

9.3.4 Vorformatierter Text: Das PRE-Element

<!ENTITY % pre.exclusion "IMG|OBJECT|BIG|SMALL|SUB|SUP">

<!ELEMENT PRE - - (%inline;)* -(%pre.exclusion;) - - preformatted text - ->


<!ATTLIST PRE
%attrs; - - %coreattrs, %i18n, %events - -
>

Start-Tag: erforderlich, End-Tag: erforderlich

Attributdefinitionen

width = number [CN]


Missbilligt. Dieses Attribut bietet visuellen Benutzerprogrammen einen Hinweis ber die
gewnschte Breite des formatierten Blocks. Das Benutzerprogramm kann diese Informa-
tion nutzen, um eine passende Schriftgr=ße zu w@hlen oder um den Inhalt entsprechend
einzurcken. Die gewnschte Breite wird ausgedrckt in Anzahl von Zeichen. Dieses Attri-
but wird gegenw@rtig nicht umfassend untersttzt.

Zeilen und Abs,tze < 125 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Elementtitel)
Die HTML 4.01- Spezifikation

style (inzeilige Formatierungsinformation)

· onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,


onkeydown, onkeyup (eingebettete Ereignisse)

Das PRE-Element sagt visuellen Benutzerprogrammen, dass der enthaltene Text „vorformatiert“. ist.
Bei der Behandlung vorformatierten Textes k=nnen Benutzerprogramme Folgendes tun:
·· Leerraum intakt lassen
Text in einer Nichtproportionalschrift rendern
· Automatischen Umbruch verhindern
Bei der Behandlung vorformatierten Textes drfen Benutzerprogramme die Durchfhrung des
Bidirektionalalgorithmus jedoch nicht verhindern. Nicht-visuelle Benutzerprogramme mssen
zus@tzlichen Leerraum im Inhalt eines PRE-Elements nicht bercksichtigen.
Mehr Informationen ber die Spezifikation von Zeilenumbrchen in SGML finden Sie im Anhang
B unter „Zeilenumbrche“.
Der obenstehende DTD-Auszug zeigt an, welche Elemente nicht innerhalb einer PRE-Deklara-
tion stehen k=nnen. Dies ist dasselbe wie in HTML 3.2 und dafr bestimmt, konstante Zeilen-
abst@nde und Spaltenausrichtung fr in Festbreitenschrift gerenderten Text zu erhalten. Auto-
ren wird abgeraten, dieses Verhalten durch Stylesheets zu ver@ndern.
Das folgende Beispiel zeigt eine vorformatierte Strophe aus dem Gedicht „To a Skylark“ von
Shelley:

<PRE>
Higher still and higher
From the earth thou springest
Like a cloud of fire;
The blue deep thou wingest,
And singing still dost soar, and soaring ever singest.
</PRE>

So wird er im Allgemeinen dargestellt:

Higher still and higher


From the earth thou springest
Like a cloud of fire;
The blue deep thou wingest,
And singing still dost soar, and soaring ever singest.

Das Zeichen „Horizontaler Tabulator“


Der horizontale Tabulator (dezimal 9 in [ISO10646] und [ISO88591] ) wird durch visuelle Benutzer-
programme wie folgt interpretiert: Es ist die kleinste, positive Anzahl von Leerzeichen, die notwendig
sind, um Zeichen an Tabulatoren auszurichten, die je acht Zeichen voneinander entfernt sind. Wir
empfehlen nachdringlich, auf die Verwendung von horizontalen Tabulatoren in vorformatiertem Text
zu verzichten. Es ist g,ngige Praxis, die Tabulatorweite zu ver,ndern, was dann zu schlecht ausgerich-
teten Dokumenten fhren kann. n

< 126 > Text


Page size: 168,00 x 240,00 mm

9.3.5 Visuelle Darstellung von Abs.tzen

Anmerkung: Der folgende Abschnitt ist eine informelle Beschreibung des Verhaltens einiger gegen-
w,rtiger visueller Benutzerprogramme bei der Formatierung von Abs,tzen. Stylesheets erlauben bes-

Die HTML 4.01- Spezifikation


sere Kontrolle der Absatzformatierung. n
Wie Abs@tze visuell gerendert werden, ist abh@ngig vom Benutzerprogramm. Abs@tze werden
blicherweise linksbndig mit Flatterrand rechts gerendert. Andere Standards sind zu von
rechts nach links lesbaren Schriften passend.
HTML-Benutzerprogramme haben Abs@tze traditionell mit Abstand davor und danach dar-
gestellt, zum Beispiel:

At the same time, there began to take form a system of numbering,


the calendar, hieroglyphic writing, and a technically advanced
art, all of which later influenced other peoples.

Within the framework of this gradual evolution or cultural


progress the Preclassic horizon has been divided into Lower,
Middle and Upper periods, to which can be added a transitional
or Protoclassic period with several features that would later
distinguish the emerging civilizations of Mesoamerica.

Dies steht im Gegensatz zum in Romanen verwendeten Stil, der die erste Zeile eines Absatzes
einrckt und zwischen der letzten Zeile des aktuellen Absatzes und der ersten Zeile des folgen-
den den normalen Zeilenabst@nd verwendet, zum Beispiel:

At the same time, there began to take form a system of


numbering, the calendar, hieroglyphic writing, and a technically
advanced art, all of which later influenced other peoples.
Within the framework of this gradual evolution or cultural
progress the Preclassic horizon has been divided into Lower,
Middle and Upper periods, to which can be added a transitional
or Protoclassic period with several features that would later
distinguish the emerging civilizations of Mesoamerica.

Dem ursprnglichen Satzstil des NCSA Mosaic-Browsers von 1993 folgend richten Benutzer-
programme im Allgemeinen nicht beide R@nder aus, zum Teil weil das ohne anspruchsvolle Sil-
bentrennungsroutinen schwer effektiv zu realisieren ist. Das Auftauchen von Stylesheets und
von gegl@tteten Schriften mit Sub-Pixel-Positionierung wird HTML-Autoren vermutlich mehr
M=glichkeiten an die Hand geben, als sie zuvor besaßen.
Stylesheets bieten weitgehende Kontrolle ber Gr=ße und Stil einer Schrift, ber R@nder,
Abst@nde vor und nach einem Absatz, Einrckung der ersten Zeile, Ausrichtung und viele
andere Details. Das Standard-Stylesheet des Benutzerprogramms formatiert P-Elemente auf
vertraute Art, wie oben beschrieben. Man k=nnte das im Prinzip so berschreiben, dass
Abs@tze ohne die Zwischenr@ume, die blicherweise aufeinanderfolgende Abs@tze trennen,
dargestellt werden. Weil das Leser verwirren kann, raten wir gemeinhin von dieser Praxis ab.
Es ist eine g@ngige Konvention, dass visuelle HTML-Benutzerprogramme Textzeilen umbre-
chen, um sie innerhalb der verfgbaren R@nder einzupassen. Der Algorithmus fr den Umbruch
h@ngt von der zu formatierenden Schrift (script) ab.

Zeilen und Abs,tze < 127 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

In westlichen Schriften zum Beispiel sollte Text nur an Lerr@umen (white space) umgebrochen
werden. Frhere Benutzerprogramme haben Zeilen inkorrekt genau hinter dem Start-Tag oder
genau vor dem End-Tag eines Elements umgebrochen, was zu h@ngender Interpunktion fhrte.
Betrachten Sie zum Beispiel diesen Satz:
Die HTML 4.01- Spezifikation

Eine Statue des <A href="cih78">Cihuateteus</A>, dem Patron ...

Wird die Zeile genau vor dem End-Tag des A-Elements umgebrochen, fhrt das dazu, dass das
Komma an den Anfang der n@chsten Zeile rutscht:

Eine Statue des Cihuateteus


, dem Patron ...

Das ist ein Fehler, da im Markup an dieser Stelle kein Leerraum steht.

9.4 Kennzeichnen von Dokument.nderungen:


Das INS- und das DEL-Element
<!- - INS/DEL are handled by inclusion on BODY - ->
<!ELEMENT (INS|DEL) - - (%flow;)* - - inserted text, deleted text - ->
<!ATTLIST (INS|DEL)
%attrs; - - %coreattrs, %i18n, %events - -
cite %URI; #IMPLIED - - info on reason for change - -
datetime %Datetime; #IMPLIED - - date and time of change - -
>

Start-Tag: erforderlich, End-Tag: erforderlich

Attributdefinitionen

cite = uri [CT]


Der Wert dieses Attributs ist ein URI, der ein Quelldokument oder eine Nachricht kenn-
zeichnet. Der Sinn dieses Attributs besteht darin, Informationen ber die Quelle, aus der
das Zitat entnommen wurde, zu geben.
datetime = datetime [CS]
Der Wert dieses Attributs gibt Datum und Zeit des Zeitpunkts der Onderung an.

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)
·· title (Elementtitel)
style (inzeilige Formatierungsinformation)
· onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouse-
out, onkeypress, onkeydown, onkeyup (eingebettete Ereignisse)
INS und DEL werden verwendet, um Abschnitte eines Dokuments auszuzeichnen, die gegen-
ber einer anderen Versionen des Dokuments eingefgt oder gel=scht wurden (zum Beispiel
bei Gesetzentwrfen, bei denen der Gesetzgeber die Onderungen erkennen muss).

< 128 > Text


Page size: 168,00 x 240,00 mm

Diese beiden Elemente sind außergew=hnlich fr HTML, k=nnen entweder als Block-Level-
oder inzeilige Elemente dienen (jedoch nicht beides). Sie k=nnen ein oder mehr Worte inner-
halb eines Absatzes enthalten oder ein oder mehr Block-Level-Elemente wie Abs@tze, Listen
und Tabellen.

Die HTML 4.01- Spezifikation


Dieses Beispiel k=nnte aus einem Gesetzentwurf stammen, der die Gesetzgebung darber, wie
viele Stellvertreter ein Brgermeister einsetzen kann, von drei auf fnf @ndert.

<P>
Ein BUrgermeister kann <DEL>3</DEL><INS>5</INS>
Stellvertreter bestimmen.
</P>

Das INS- und das DEL-Element drfen keinen Block-Level-Inhalt haben, wenn diese Elemente als
als inzeilige Elemente fungieren.

UNG LTIGES BEISPIEL:


Das Folgende ist kein gltiges HTML:

<P>
<INS><DIV>...Block-Inhalt...</DIV></INS>
</P> n

Benutzerprogramme sollten eingefgten und gel=schten Text so darstellen, dass die Onderung
deutlich wird. Zum Beispiel kann eingefgter Text in spezieller Schrift erscheinen, gel=schter
Text kann gar nicht gezeigt oder durchgestrichen oder mit speziellen Markierungen versehen
werden und so weiter.

Anmerkung der bersetzer: Eine m=gliche Pr@sentation des Beispiels von oben
ist folgende:

Die beiden folgenden Beispiele passen auf „November 5, 1994, 8:15:30 am, US Eastern Stan-
dard Time.“

1994-11-05T13:15:30Z
1994-11-05T08:15:30-05:00

Bei Benutzung von INS ergibt:

<INS datetime="1994-11-05T08:15:30-05:00"
cite="http://www.foo.org/mydoc/comments.html">
Furthermore, the latest figures from the marketing department
suggest that such practice is on the rise.
</INS>

Das INS- und das DEL-Element < 129 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Das Dokument „http://www.foo.org/mydoc/comments.html“ wrde Kommentare dazu enthal-


ten, warum die Information in das Dokument eingefgt wurde.
Autoren k=nnen eingefgten oder gel=schten Text auch mittels title-Attribut fr das INS- und
DEL-Element kommentieren. Benutzerprogramme k=nnen dem Benutzer diese Information pr@-
Die HTML 4.01- Spezifikation

sentieren (zum Beispiel als Popup-Note). Ein Beispiel:

<INS datetime="1994-11-05T08:15:30-05:00"
title="Changed as a result of Steve B's comments in meeting.">
Furthermore, the latest figures from the marketing department
suggest that such practice is on the rise.
</INS>

10 Listen
10.1 Einf-hrung in Listen
HTML bietet Autoren verschiedene Mechanismen, Auflistungen von Informationen zu spezifi-
zieren. Alle Listen mssen ein oder mehr Listenelemente haben. Listen k=nnen Folgendes ent-
halten:
·· Ungeordnete Informationen
Geordnete Informationen
· Definitionen
Zum Beispiel ist die vorstehende Liste eine mit dem UL-Element erstellte ungeordnete Liste:

<UL>
<LI>Ungeordnete Informationen
<LI>Geordnete Informationen
<LI>Definitionen
</UL>

Eine geordnete Liste, erstellt mit Hilfe des OL-Elements, sollte Informationen enthalten, deren
Ordnung wie in einem Rezept hervorgehoben werden soll:
1. Die trockenen Zutaten vermischen.
2. Die flssigen Zutaten dazugeben.
3. 10 Minuten rhren.
4. Eine Stunde bei 300 Grad backen.
Definitionslisten, die mit Hilfe des Elements DL erstellt werden, bestehen im Allgemeinen aus
einer Reihe von Ausdrucks/Definitions-Paaren (Definitionslisten k=nnen auch anders verwen-
det werden). So k=nnte man bei der Werbung fr ein Produkt eine Definitionsliste benutzen:

Niedrigere Kosten
Die neue Version dieses Produktes kostet deutlich weniger als die vorherige!
Einfachere Verwendung
Wir haben das Produkt so ver@ndert, dass es jetzt noch einfacher einzusetzen ist!

< 130 > Listen


Page size: 168,00 x 240,00 mm

Kindersicher
Sie k=nnen Ihre Kinder mit diesem Produkt allein im Zimmer lassen, sie werden sich nicht
verletzen (ohne Garantie).

Die HTML 4.01- Spezifikation


In HTML definiert:

<DL>
<DT><STRONG>Niedrigere Kosten</STRONG>
<DD>Die neue Version dieses Produktes kostet deutlich weniger als die vorherige!
<DT><STRONG>Einfachere Verwendung</STRONG>
<DD>Wir haben das Produkt so ver]ndert, dass es jetzt noch einfacher einzusetzen
ist!
<DT><STRONG>Kindersicher</STRONG>
<DD>Sie k^nnen Ihre Kinder mit diesem Produkt allein im Zimmer lassen,
sie werden sich nicht verletzen (ohne Garantie).
</DL>

Anmerkung der bersetzer: Falls alle DT-Elemente gleich dargestellt werden sol-
len (was im Allgemeinen sinnvoll ist), sollte man sich im obigen Beispiel die STRONG-Aus-
zeichnung sparen und die Formatierung besser durch eine CSS-Anweisung vornehmen:

dt { font-weight: bold; }

Eine m=gliche Darstellung zeigt das folgende Bild:

Listen k=nnen auch verschachtelt werden und verschiedene Listentypen k=nnen gemeinsam
verwendet werden. Das folgende Beispiel besteht aus einer Definitionsliste, die eine ungeord-
nete Liste (die Zutaten) und eine geordnete Liste (die Zubereitung) enth@lt:

Einf#hrung in Listen < 131 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Zutaten:
·· 100g Mehl
10g Zucker
··1 Tasse Wasser
Die HTML 4.01- Spezifikation

2 Eier
·Salz, Pfeffer
Zubereitung:
1. Die trockene Zutaten grndlich vermischen.
2. Die flssigen Zutaten dazugeben.
3. 10 Minuten rhren.
4. Eine Stunde bei 300 Grad backen.
Tipp:
Das Rezept kann durch Zugabe von Rosinen verfeinert werden.

Die genaue Darstellung der drei Listenarten h@ngt vom Benutzerprogramm ab. Wir raten
Autoren davon ab, Listen lediglich zum Einrcken von Text zu benutzen. Das ist eine stilistische
Angelegenheit, die besser mit Hilfe von Stylesheets erledigt wird.

10.2 Ungeordnete Listen (UL), geordnete Listen (OL) und


Listeneintr.ge (LI)
<!ELEMENT UL - - (LI)+ - - unordered list - ->
<!ATTLIST UL
%attrs; - - %coreattrs, %i18n, %events - -
>
<!ELEMENT OL - - (LI)+ - - ordered list - ->
<!ATTLIST OL
%attrs; - - %coreattrs, %i18n, %events - -
>

Start-Tag: erforderlich, End-Tag: erforderlich

<!ELEMENT LI - O (%flow;)* - - list item - ->


<!ATTLIST LI
%attrs; - - %coreattrs, %i18n, %events - -
>

Start-Tag: erforderlich, End-Tag: optional

Attributdefinitionen

type = style-information [CI]


Missbilligt. Dieses Attribut gibt den Stil eines Listeneintrags (item) vor. Derzeit verfgbare
Werte sind fr visuelle Benutzerprogramme bestimmt. M=gliche Werte werden weiter
unten (zusammen mit Information zur Groß-/Kleinschreibung) beschrieben.

< 132 > Listen


Page size: 168,00 x 240,00 mm

start = number [CN]


Missbilligt. Nur fr OL. Dieses Attribut gibt den Startwert des ersten Eintrags einer geord-
neten Liste an. Der Standardstartwert ist „1“. Beachten Sie, dass, auch wenn der Wert die-
ses Attribut eine ganz Zahl (Integer) ist, das zugeh=rige Kennzeichen nichtnumerisch sein

Die HTML 4.01- Spezifikation


kann. start=3 ergibt „C“, wenn der Stil der Listeneintr@ge große lateinische Buchstaben
(A, B, C ...) vorgibt. Gibt der Stil kleingeschriebene r=mische Ziffern vor, bedeutet start=3
„iii“ usw.
value = number [CN]
Missbilligt. Nur fr LI. Dieses Attribut bestimmt die Nummer des aktuellen Listeneintra-
ges. Auch wenn der Wert dieses Attributs eine ganz Zahl ist, kann die dazugeh=rigen Dar-
stellung nichtnumerisch sein (siehe start-Attribut).
compact [CI]
Missbilligt. Wenn gesetzt, gibt dieses boolesche Attribut visuellen Benutzerprogrammen
einen Hinweis, die Liste kompakter darzustellen. Die Interpretation dieser Eigenschaft ist
abh@ngig vom Benutzerprogramm.

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Elementtitel)
style (inzeilige Formatierungsinformation)

· onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,


onkeydown, onkeyup (eingebettete Ereignisse)

Geordnete und ungeordnete Listen werden identisch dargestellt und unterscheiden sich nur
darin, dass visuelle Benutzerprogramme geordnete Listeintr@ge nummerieren. Benutzerpro-
gramme k=nnen diese Zahlen auf unterschiedliche Art darstellen. Ungeordnete Listenelemente
sind nicht nummeriert.
Beide Listenarten werden aus einer Folgen von Listeneintr@gen gebildet, definiert durch das
LI-Element (dessen abschließender Tag weggelassen werden kann).
Dieses Beispiel veranschaulicht die Grundstruktur einer Liste.

<UL>
<LI> ... erster Listeneintrag...
<LI> ... zweiter Listeneintrag...
...
</UL>

Listen k=nnen auch verschachtelt sein:

MISSBILLIGTES BEISPIEL:

<UL>
<LI> ... Ebene eins, Nummer eins...
<OL>
<LI> ... Ebene zwei, Nummer eins...
<LI> ... Ebene zwei, Nummer zwei...
<OL start="10">
<LI> ... Ebene drei, Nummer eins...
</OL>

Ungeordnete, geordnete Listen und Listeneintr,ge < 133 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

<LI> ... Ebene zwei, Nummer drei...


</OL>
<LI> ... Ebene eins, Nummer zwei...
</UL> n
Die HTML 4.01- Spezifikation

Details -ber die Reihenfolge der Zahlen: In geordneten Listen ist es nicht m glich, Listennum-
merierungen aus einer vorherigen Liste automatisch fortzusetzen oder die Nummerierung einiger Lis-
teneintr,ge zu verbergen. Autoren k nnen aber die Nummer eines Listeneintrags ber das value-Attri-
but neu setzen. Die Nummerierung fr die nachfolgenden Listeneintr,ge wird vom neuen Wert aus
fortgesetzt. Zum Beispiel:

<ol>
<li value="30"> Dieser Eintrag wird zu Nummer 30.
<li value="40"> Dieser Eintrag wird zu Nummer 40.
<li> Dieser Eintrag wird zu Nummer 41.
</ol> n

Anmerkung der bersetzer: So oder @hnlich kann diese Liste vom Browser
gezeigt werden:

10.3 Definitionslisten: Die Elemente DL, DT und DD


<!- - definition lists - DT for term, DD for its definition - ->

<!ELEMENT DL - - (DT|DD)+ - - definition list - ->


<!ATTLIST DL
%attrs; - - %coreattrs, %i18n, %events - -
>

Start-Tag: erforderlich, End-Tag: eforderlich

<!ELEMENT DT - O (%inline;)* - - definition term - ->


<!ELEMENT DD - O (%flow;)* - - definition description - ->
<!ATTLIST (DT|DD)
%attrs; - - %coreattrs, %i18n, %events - -
>

Start-Tag: erforderlich, End-Tag: optional

< 134 > Listen


Page size: 168,00 x 240,00 mm

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Elementtitel)

Die HTML 4.01- Spezifikation


style (inzeilige Formatierungsinformation)

· onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,


onkeydown, onkeyup (eingebettete Ereignisse)

Definitionslisten unterscheiden sich von anderen Listenarten nur insoweit, dass Listeneintr@ge
aus zwei Teilen bestehen: einer Bezeichnung und einer Beschreibung. Die Bezeichnung wird
durch das DT-Element zugewiesen und ist auf Elemente auf Zeilenebene beschr@nkt. Die
Beschreibung wird mit dem Element DD angegeben, das Blockelemente enth@lt.

Ein Beispiel:

<DL>
<DT>Dweeb
<DD>young excitable person who may mature
into a <EM>Nerd</EM> or <EM>Geek</EM>

<DT>Hacker
<DD>a clever programmer

<DT>Nerd
<DD>technically bright but socially inept person

</DL>

Hier ein Beispiel mit mehrfachen Bezeichnungen und Beschreibungen:

<DL>
<DT>Center
<DT>Centre
<DD> A point equidistant from all points
on the surface of a sphere.
<DD> In some field sports, the player who
holds the middle position on the field, court,
or forward line.
</DL>

Eine andere Anwendungsm=glichkeit fr DL ist beispielsweise die Auszeichnung von Dialogen,
in der jedes DT einen Sprecher bezeichnet und jedes DD ihre oder seine Worte enth@lt.

Anmerkung der bersetzer: Wie die Beispiele zeigen, ist die obige Aussage, dass
in DD Blockelemente stehen nicht korrekt. DD kann entweder Block- oder inzeilige Ele-
mente, auch Text, aufnehmen.
Die Beispiele zeigen eine saubere Verwendung der Definitionslisten. Die anschließend
gemachte Bemerkung zeigt aber auch, dass ein DT (Definition Term) nicht immer einen
Ausdruck (Term) enth@lt, der im nachfolgenden DD (Definition) definiert wird. Trotz der
semantisch anmutenden Elementtypnamen handelt es sich in der Praxis doch oft um
eine Liste, die (auch) gestalterischen Zwecken dient.

Definitionslisten: Die Elemente DL, DT und DD < 135 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

10.3.1 Visuelle Darstellung von Listen

Anmerkung: Nachfolgend eine informelle Beschreibung zum Verhalten einiger aktueller visueller
Benutzerprogramme bei der Listenformatierung. Stylesheets erlauben eine bessere Kontrolle der For-
Die HTML 4.01- Spezifikation

matierung von Listen (beispielsweise bei Nummerierungen, sprachabh,ngigen Konventionen, Ein-


rckungen usw.). n
Visuelle Benutzeragenten rcken im Allgemeinen verschachtelte Listen unter Bercksichtung
der jeweiligen Verschachtelungsebene ein.
Sowohl fr OL als auch fr UL gibt das type-Attribut Darstellungsoptionen fr visuelle Benutzer-
agenten vor.
Fr das UL-Element sind disc, square und circle m=gliche Werte des type-Attributs. Der Stan-
dardwert ist abh@ngig von der Verschachtelungsebene der aktuellen Liste. Bei diesen Werten
wird nicht zwischen Groß- oder Kleinschreibung unterschieden.
Wie die Werte dargestellt werden, h@ngt vom Benutzerprogramm ab. Benutzerprogramme
sollten versuchen, „disc“ als kleine ausgefllte Scheibe, „circle“ als Umriss eines kleinen Kreises
und „square“ als Umriss eines kleinen Rechtecks darzustellen.
Ein graphisches Benutzerprogramm k=nnte dies so wiedergeben:

fr den Wert „disc“

fr den Wert „circle“

fr den Wert „square“

M=gliche Werte des type-Attributs fr das OL-Element sind in der folgenden Tabelle zusammen-
gestellt (zwischen Groß- und Kleinschreibung wird unterschieden):

Typ Art der Nummerierung


1 Arabische Ziffern 1, 2, 3, ...
a Kleinbuchstaben a, b, c, ...
A Großbuchstaben A, B, C, ...
i Kleine r=mische Zahlen i, ii, iii, ...
I Große r=mische Zahlen I, II, III, ...

Beachten Sie, dass das Attribut type missbilligt ist und der Stil von Listen durch Stylesheets
behandelt werden sollte.

Anmerkung der bersetzer: Entsprechende Informationen sind in der CSS2-Spe-


zifikation im Abschnitt 12.6 zu finden. Die CSS2-Eigenschaft list-style-type gestattet
mehr Gestaltungsspielraum als HTML. Hinzu kommen list-style-image, um Listen-
punkten eine Grafik voranzustellen, und list-style-position. Neben den guten Grn-

< 136 > Listen


Page size: 168,00 x 240,00 mm

den, die prinzipiell dafr sprechen, Formatierung per Stylesheet zu steuern, erh@lt man
in diesem Fall mit CSS auch viel mehr M=glichkeiten als mit HTML.

Die HTML 4.01- Spezifikation


Zum Beispiel k=nnte man unter Verwendung von CSS angeben, dass Listeneintr@ge in einer
geordneten Liste mit kleinen r=mischen Ziffern dargestellt werden sollen. Im folgenden Auszug
wird jedes OL-Element, das zur Klasse „withroman“ geh=rt, r=mische Zahlen vor den Listenein-
tr@gen haben.

<STYLE type="text/css">
OL.withroman { list-style-type: lower-roman }
</STYLE>
<BODY>
<OL class="withroman">
<LI> Schritt eins ...
<LI> Schritt zwei ...
</OL>
</BODY>

Die Wiedergabe einer Definitionsliste ist ebenfalls abh@ngig vom Benutzerprogramm. Das Bei-
spiel

<DL>
<DT>Dweeb
<DD>young excitable person who may mature
into a <EM>Nerd</EM> or <EM>Geek</EM>

<DT>Hacker
<DD>a clever programmer

<DT>Nerd
<DD>technically bright but socially inept person
</DL>

k=nnte wie folgt dargestellt werden:

Dweeb
young excitable person who may mature into a Nerd or Geek
Hacker
a clever programmer
Nerd
technically bright but socially inept person

Definitionslisten: Die Elemente DL, DT und DD < 137 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

10.4 Das DIR- und das MENU-Element


DIR und MENU sind missbilligt.
Die formale Definition finden Sie in der Transitional DTD.
Die HTML 4.01- Spezifikation

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Elementtitel)
style (inzeilige Formatierungsinformation)

· onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,


onkeydown, onkeyup (eingebettete Ereignisse)

Das DIR-Element wurde fr das Erstellen von mehrspaltigen Verzeichnislisten entworfen. Das
MENU-Element wurde fr einspaltige Menlisten entworfen. Beide Elemente haben dieselbe
Struktur wie UL, unterscheiden sich jedoch in der Darstellung. In der Praxis wird ein Benutzer-
programm eine DIR- oder MENU-Liste genau wie eine UL-Liste wiedergeben.
Wir empfehlen dringend, anstelle dieser Elemente UL zu verwenden.

11 Tabellen
11.1 Einf-hrung in Tabellen
Das Tabellenmodell von HTML gestattet Autoren die Anordnung von Daten – Text, vorforma-
tierter Text, Bilder, Links, Formulare, Formularfelder, andere Tabellen und so weiter – in Zel-
len, 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 angege-
ben 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=n-
nen von Benutzerprogrammen auf eine Weise dargestellt werden, die diese Struktur unter-
sttzt. 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 untersttzen. Wer-
den lange Tabellen gedruckt, k=nnen die Kopf- und Fußinformationen auf jeder Seite, die Tabel-
lendaten 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 Spal-
teneigenschaften 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 visu-

< 138 > Tabellen


Page size: 168,00 x 240,00 mm

elle Benutzerprogramme Kopfinformationen ber die Zelle einfacher an den Benutzer weiter-
geben k=nnen. Diese Mechanismen untersttzen nicht nur Benutzer mit Sehbehinderungen
immens, sie erm=glichen es multimodalen kabellosen Browsern mit begrenzten Anzeigem=g-
lichkeiten (z. B. web-f@hige Pager und Telefone) Tabellen zu verarbeiten.

Die HTML 4.01- Spezifikation


Tabellen sollten nicht ausschließlich als Mittel zum Layout von Dokumentinhalt verwendet wer-
den, weil dies Probleme mit sich bringen kann, wenn der Inhalt auf nicht visuellen Medien aus-
gegeben 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 mssen wir – so richtig sie in ihrem
Anliegen sind – unter praktischen Gesichtspunkten etwas relativieren.
Richtig und wichtig ist: Tabellen sind ein Struktur-, kein Layoutmittel. Mangels Alternati-
ven wurden und werden sie h@ufig fr Layoutzwecke „missbraucht“ und fhren zu den
erw@hnten Problemen bei nicht visueller Darstellung. Leider scheitert die vorgeschla-
gene Alternative, Stylesheets zu verwenden, im Moment oft noch in der Praxis, mindes-
tens dann, wenn etwas komplexere Layouts realisiert werden sollen. Die Ursache liegt
in den visuellen Benutzerprogrammen, von denen selbst aktuelle Versionen mit Style-
sheets nicht so umgehen, wie es erforderlich w@re, sei es nun durch Bugs oder unvoll-
st@ndige Untersttzung von Stylesheets.
Um es noch einmal deutlich zu sagen: Wir untersttzen hier nicht die Verwendung von
Tabellen fr 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 dafr 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 Breiten-
vorgaben 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, fhren 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 Breiten-
vorgaben oder durch Positionierung mit Hilfe von Stylesheets, macht im Ergebnis nicht
wirklich einen Unterschied. Vermeiden oder wenigstens minimieren l@sst sich des Prob-
lems nur durch bewusstes Herangehen seitens der Autoren.
Das eben Gesagte @ndert natrlich nichts daran, dass Stylesheets das Mittel der Wahl
sein sollten, wenn es um Layoutfragen geht. Ein Beispiel, wie man ein h@ufig verwende-
tes – heute vielfach noch mit Hilfe von Tabellen erreichtes – Layout mittels Stylesheets
realisieren kann, finden Sie am Ende dieses Kapitels.

Einf#hrung in Tabellen < 139 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Anmerkung der bersetzer: Es gibt noch einen anderen Blickwinkel darauf, ob


Tabellen der Strukturierung oder dem Layout dienen: Selbstverst@ndlich k=nnen Tabel-
len nur tabellarische Daten strukturieren. Beispiele fr solche Daten sind in diesem Kapi-
Die HTML 4.01- Spezifikation

tel 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 fr 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 endgltig die
Frage erledigt: „Struktur oder Layout?“
Dank der Modularisierung von XHTML l@sst sich so etwas einfach mit XHTML kom-
binieren: Ein „liga“-Modul fr die Sportdaten k=nnte den XHTML-Modulen hinzugefgt
werden.

Anmerkung: Diese Spezifikation enth,lt detailliertere Informationen ber Tabellen in den Abschnit-
ten ber Begrndung des Tabellenentwurfs und Implementierungsaspekte (siehe Anhang B). n
Hier folgt eine einfache Tabelle, die einige Eigenschaften des HTML-Tabellenmodells illustriert.
Die folgende Tabellendefinition:

<TABLE border="1"
summary="Diese Tabelle zeigt einige Statistiken Uber
Fruchtfliegen: durchschnittliche H^he und
Gewicht und Anteil derjenigen mit roten Augen
(fUr 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:

Eine Testtabelle mit zusammengefassten Zellen


/----------------------------------------------\
| | Durchschnitt | Rote |
| |----------------------| Augen |
| | Gr^ße | Gewicht | |
|----------------------------------------------|
| M]nnchen | 1.9 | 0.003 | 40% |
|----------------------------------------------|
| Weibchen | 1.7 | 0.002 | 43% |
\----------------------------------------------/

< 140 > Tabellen


Page size: 168,00 x 240,00 mm

oder wie diese durch ein graphisches Benutzerprogramm:

Die HTML 4.01- Spezifikation


Anmerkung der bersetzer: Benutzer der Betriebssysteme Linux und Unix
werden unter tty-Ger@t eher eine Ger@tedatei fr serielle Ger@te vermuten, in die-
sem Fall ist aber der Ausdruck eines klassischen Fernschreibers (Teletype Termi-
nal) gemeint.

11.2 Elemente zur Tabellenerzeugung


11.2.1 Das TABLE-Element

<!ELEMENT TABLE - -
(CAPTION?, (COL*|COLGROUP*), THEAD?, TFOOT?, TBODY+)>
<!ATTLIST TABLE -- table element - -
%attrs; -- %coreattrs, %i18n, %events - -
summary %Text; #IMPLIED - - purpose/structure for speech output- -
width %Length; #IMPLIED - - table width - -
border %Pixels; #IMPLIED - - controls frame width around table - -
frame %TFrame; #IMPLIED - - which parts of frame to render - -
rules %TRules; #IMPLIED - - rulings between rows and cols - -
cellspacing %Length; #IMPLIED - - spacing between cells - -
cellpadding %Length; #IMPLIED - - spacing within cells - -
>

Start-Tag: erforderlich, End-Tag: erforderlich

Attributdefinitionen

summary = text [CS]


Dieses Attribut bietet eine Zusammenfassung der Intention und der Struktur der Tabelle
fr Benutzerprogramme, die den Inhalt fr nicht visuelle Medien wie Sprach- oder Braille-
Browser ausgeben.
align = left|center|right [CI]
Missbilligt. Dieses Attribut gibt die Position der Tabelle in Bezug auf das Dokument an.
Erlaubte Werte:
·· left: Die Tabelle wird am linken Rand des Dokuments ausgerichtet.
center: Die Tabelle wird in der Mitte des Dokuments ausgerichtet.

· right: Die Tabelle wird am rechten Rand des Dokuments ausgerichtet.

Elemente zur Tabellenerzeugung < 141 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

width = length [CN]


Dieses Attribut gibt die gewnschte Breite der gesamten Tabelle an und ist fr visuelle
Benutzerprogramme vorgesehen. Ist der Wert eine Prozentangabe, dann ist der Wert rela-
tiv zur verfgbaren horizontalen Ausdehnung des Benutzerprogramms. Ist keine Breite
Die HTML 4.01- Spezifikation

angegeben, wird die Tabellenbreite durch das Benutzerprogramm festgelegt.

Anmerkung der bersetzer: Genauer gesagt gibt das Attribut align die Posi-
tion 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.

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Elementtitel)
style (inzeilige Formatierungsinformation)

· onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,


onkeydown, onkeyup (eingebettete Ereignisse)

·· bgcolor (Hintergrundfarbe)
frame, rules, border (Rahmen und Linien)

· cellspacing, cellpadding (Zellr@nder)

Das Element TABLE enth@lt alle anderen Elemente, die Beschriftung, Zeilen, Inhalt und Format
angeben.
Die folgende informelle Liste zeigt, welche Operationen Benutzerprogramme ausfhren k=n-
nen, wenn sie eine Tabelle darstellen:
· Dem Benutzer die Tabellenzusammenfassung (summary) zur Verfgung stellen. Autoren soll-
ten 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 mssen wissen, wo Kopf und Fuß darzustellen
sind. Ist das Ausgabemedium zum Beispiel seitenorientiert, mssen Benutzerprogramme
den Kopf an den Beginn und den Fuß an das Ende jeder Seite stellen. Ohnlich 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 Anzahl der Spalten in der Tabelle berechnen. Beachten Sie, dass die Anzahl der Zeilen
in einer Tabelle gleich der Anzahl der TR-Elemente innerhalb des Elements TABLE ist.
·· Die Spalten entsprechend jeder Spaltengruppenangabe anordnen.
Die Zellen Zeile fr 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.

< 142 > Tabellen


Page size: 168,00 x 240,00 mm

Das HTML-Tabellenmodell wurde so entworfen, dass Benutzerprogramme mit Untersttzung


des Autors Tabellen inkrementell darstellen k=nnen (d. h., wenn Tabellenzeilen eintreffen),
anstatt auf alle Daten warten zu mssen, um mit der Darstellung zu beginnen.
Damit ein Benutzerprogramm eine Tabelle in einem Zug darstellen kann, mssen Autoren ihm

Die HTML 4.01- Spezifikation


Folgendes mitteilen:
· Die Anzahl der Spalten in der Tabelle. Im Abschnitt „Berechnen der Spaltenanzahl in einer
Tabelle“ finden Sie Details, wie diese Information angegeben werden kann.
· 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 „Be-
rechnen der Spaltenbreite“), mssen Autoren auch die Breite der Tabelle selbst angeben.

Tabellenrichtung
Die Richtung einer Tabelle ist entweder die geerbte Richtung (Standard ist von links nach
rechts) oder die vom Attribut dir angegebene Richtung fr das Element TABLE.
Fr eine Tabelle von links nach rechts ist die Spalte Null auf der linken Seite und die Zeile Null
befindet sich oben. Fr 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 fr „links-nach-rechts“-Tabellen an
der rechten Seite und und fr „rechts-nach-links“-Tabellen auf der linken Seite hinzugefgt.
Beachten Sie, dass TABLE das einzige Element ist, fr welches das Attribut dir die visuelle Rei-
henfolge der Spalten umkehrt; eine einzelne Tabellenzeile (TR) oder eine Spaltengruppe (COL-
GROUP) kann nicht unabh@ngig umgekehrt werden.
Ist das Attribut dir fr das Element TABLE angegeben, wirkt sich das Attribut ebenfalls auf den
Text innerhalb der Tabellenzellen aus (weil das dir-Attribut von Block-Level-Elementen ver-
erbt 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, „Spezifizie-
rung der Richtung von Text und Tabellen“ fr weiterfhrende Informationen zum Thema Text-
flussrichtung.

Elemente zur Tabellenerzeugung < 143 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

11.2.2 Tabellen-berschriften: Das CAPTION-Element

<!ELEMENT CAPTION - - (%inline;)* - - table caption - ->

<!ATTLIST CAPTION
Die HTML 4.01- Spezifikation

%attrs; - - %coreattrs, %i18n, %events - -


>

Start-Tag: erforderlich, End-Tag: erforderlich

Attributdefinitionen

align = top|bottom|left|right [CI]


Missbilligt. Fr visuelle Benutzerprogramme gibt dieses Attribut die Position der ber-
schrift in Bezug auf die Tabelle an. M=gliche Werte:
··top: Die berschrift befindet sich ber der Tabelle. Dies ist die Voreinstellung.
bottom: Die berschrift befindet sich unter der Tabelle.

··
left: Die berschrift befindet sich zur Linken der Tabelle.
right: Die berschrift befindet sich zur Rechten der Tabelle.

Anmerkung der bersetzer: Die Werte left und right werden von einigen g@n-
gigen Browsern ignoriert.

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Elementtitel)
style (inzeilige Formatierungsinformation)

· onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,


onkeydown, onkeyup (eingebettete Ereignisse)

Wenn das Element CAPTION angegeben ist, sollte sein Text die Natur der Tabelle beschreiben.
Das Element CAPTION ist nur direkt hinter dem Start-Tag TABLE gestattet. Ein TABLE-Element kann
nur ein CAPTION-Element enthalten.
Visuelle Benutzerprogramme erlauben sehenden Benutzern sowohl durch die Kopfzeilen als
auch durch die berschrift, die Struktur der Tabelle schnell zu erfassen. Folglich werden ber-
schriften 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 fr Tabellen ohne berschriften. Beispiele weiter unten zeigen die
Verwendung des Attributs summary.

< 144 > Tabellen


Page size: 168,00 x 240,00 mm

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 errei-
chen, zum Beispiel ber horizontales oder vertikales Scrollen. Wir empfehlen, dass die ber-
schrift auf die gleiche Breite gesetzt wird wie die Tabelle (siehe auch den Abschnitt „Empfoh-

Die HTML 4.01- Spezifikation


lene Layout-Algorithmen“ im Anhang B).

11.2.3 Zeilengruppen: Die Elemente THEAD, TFOOT und TBODY

<!ELEMENT THEAD - O (TR)+ - - table header - ->


<!ELEMENT TFOOT - O (TR)+ - - table footer - ->

Start-Tag: erforderlich, End-Tag: optional

<!ELEMENT TBODY O O (TR)+ - - table body - ->

Start-Tag: erforderlich, End-Tag: optional

<!ATTLIST (THEAD|TBODY|TFOOT) -- table section - -


%attrs; -- %coreattrs, %i18n, %events - -
%cellhalign; -- horizontal alignment in cells - -
%cellvalign; -- vertical alignment in cells - -
>

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Elementtitel)
style (inzeilige Formatierungsinformation)

· onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,


onkeydown, onkeyup (eingebettete Ereignisse)

· align, char, charoff, valign (Zellausrichtung)

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 Tabellenrmpfen unabh@ngig vom Tabel-
lenkopf und -fuß zu untersttzen. 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 Tabellen-
rumpf sollte Zeilen mit Tabellendaten enthalten.

Anmerkung der bersetzer: Die CSS2-Spezifikation nennt die folgenden Anga-


ben als Voreinstellungen fr die Elemente THEAD, TBODY und TFOOT.

THEAD { display: table-header-group }


TBODY { display: table-row-group }
TFOOT { display: table-footer-group }

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

Elemente zur Tabellenerzeugung < 145 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

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-An-
gabe vorhanden ist. Interessanterweise wiederholen diese Programme den Kopf und
Die HTML 4.01- Spezifikation

Fuß beim Ausdruck nicht, wenn die CSS-Anweisungen fehlen; obwohl die Einstellungen
fr HTML automatisch gelten sollten. Es empfiehlt sich also, die gezeigten CSS-Anwei-
sungen 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 -rmpfen.

<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 Tabellen-
rumpf und keinen Tabellenkopf oder -fuß. Das End-Tag TBODY kann immer problemlos weg-
gelassen werden.
· Die Start-Tags fr THEAD und TFOOT sind erforderlich, wenn Tabellenkopf bzw. -fuß vorhan-
den sind, jedoch k=nnen die End-Tags immer problemlos weggelassen werden.
Konforme Parser von Benutzerprogrammen mssen diese Regeln aus Grnden der Abw@rts-
kompatibilit@t immer befolgen.
Die Tabelle des vorherigen Beispiels k=nnte durch Weglassen bestimmter End-Tags verkrzt
werden:

<TABLE>
<THEAD>
<TR> ...Kopfinformation...
<TFOOT>
<TR> ...Fußinformation...

< 146 > Tabellen


Page size: 168,00 x 240,00 mm

<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...

Die HTML 4.01- Spezifikation


<TR> ...zweite Zeile mit Daten von Block zwei...
<TR> ...dritte Zeile mit Daten von Block zwei...
</TABLE>

Die Bereiche THEAD, TFOOT und TBODY mssen die gleiche Spaltenanzahl enthalten.

11.2.4 Spaltengruppen: Die Elemente COLGROUP und COL

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 fr 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 fr mehreren Spalten gemeinsam zu verwen-
den, 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.

Das Element COLGROUP


<!ELEMENT COLGROUP - O (COL)* - - table column group - ->
<!ATTLIST COLGROUP
%attrs; -- %coreattrs, %i18n, %events - -
span NUMBER 1 -- default number of columns in group - -
width %MultiLength; #IMPLIED -- default width for enclosed COLs - -
%cellhalign; -- horizontal alignment in cells - -
%cellvalign; -- vertical alignment in cells - -
>

Start-Tag: erforderlich, End-Tag: optional

Attributdefinitionen

span = number [CN]


Dieses Attribut muss eine Ganzzahl gr=ßer als 0 sein und gibt die Anzahl der Spalten einer
Spaltengruppe an. Werte bedeuten das Folgende:
·· Ohne ein span-Attribut definiert jedes COLGROUP eine Spaltengruppe mit einer Spalte.
Ist das Attribut span auf N > 0 gesetzt, definiert das aktuelle COLGROUP-Element eine Spal-
tengruppe mit N Spalten.
Benutzerprogramme mssen dieses Attribut ignorieren, wenn das COLGROUP-Element ein
oder mehrere COL-Elemente enth@lt.

Elemente zur Tabellenerzeugung < 147 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

width = multi-length [CN]


Dieses Attribut gibt eine Standardbreite fr 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 HTML 4.01- Spezifikation

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 wer-
den kann. Autoren sollten sich dessen bewusst sein, dass die Angabe von „0*“ Benutzerpro-
gramme 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.

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Elementtitel)
style (inzeilige Formatierungsinformation)

· onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,


onkeydown, onkeyup (eingebettete Ereignisse)

· align, char, charoff, valign (Zellausrichtung)

Das Element COLGROUP erzeugt eine explizite Spaltengruppe. Fr die Angabe der Anzahl der
Spalten in der Spaltengruppe gibt es zwei, sich gegenseitig ausschließende M=glichkeiten:
1. Das span-Attribut des Elements (Standardwert 1) gibt die Anzahl der Spalten in der Gruppe
an.
2. 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 zusam-
menfassen k=nnen. Enth@lt eine Tabelle vierzig Spalten, jede mit einer Breite von 20 Pixeln, ist
es einfacher, Folgendes zu schreiben:

<COLGROUP span="40" width="20">


</COLGROUP>

als:

<COLGROUP>
<COL width="20">
<COL width="20">
... im Ganzen vierzig COL-Elemente ...
</COLGROUP>

Ist es notwendig, eine einzelne Spalte innerhalb einer Gruppe auszugrenzen (z. B. fr Format-
informationen, um eine Breite anzugeben usw.), mssen 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:

<COLGROUP width="20">
<COL span="39">
<COL id="formatier-mich-anders">
</COLGROUP>

< 148 > Tabellen


Page size: 168,00 x 240,00 mm

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

Die HTML 4.01- Spezifikation


10 Spalten und die zweite 5 Spalten. Die Standardbreite fr jede Spalte in der ersten Spalten-
gruppe ist 50 Pixel. Die Breite jeder Spalte in der zweiten Spaltengruppe wird die minimal
ben=tigte fr diese Spalte sein.

<TABLE>
<COLGROUP span="10" width="50">
<COLGROUP span="5" width="0*">
<THEAD>
<TR><TD> ...
</TABLE>

Das COL-Element
<!ELEMENT COL - O EMPTY -- table column - ->
<!ATTLIST COL -- column groups and properties - -
%attrs; -- %coreattrs, %i18n, %events - -
span NUMBER 1 -- COL attributes affect N columns - -
width %MultiLength; #IMPLIED -- column width specification - -
%cellhalign; -- horizontal alignment in cells - -
%cellvalign; -- vertical alignment in cells - -
>

Start-Tag: erforderlich, End-Tag: verboten

Attributdefinitionen

span = number [CN]


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 fr dieses Attribut ist 1
(d. h., das Element COL bezieht sich auf eine einzige Spalte). Ist fr das span-Attribut N > 1,
teilt das aktuelle COL-Element seine Attribute mit den n@chsten N-1 Spalten.
width = multi-length [CN]
Dieses Attribut gibt eine Standardbreite fr jede Spalte an, ber die sich das aktuelle COL-
Element erstreckt. Es hat die gleiche Bedeutung wie das Attribut width fr das Element
COLGROUP und berschreibt es.

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Elementtitel)
style (inzeilige Formatierungsinformation)

· onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,


onkeydown, onkeyup (eingebettete Ereignisse)

· align, char, charoff, valign (Zellausrichtung)

Elemente zur Tabellenerzeugung < 149 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Das Element COL gestattet Autoren, Attributangaben fr Tabellenspalten (in Gruppen) zusam-
menzufassen. COL gruppiert Spalten nicht strukturell, denn das ist Aufgabe des Elements
COLGROUP. COL-Elemente sind leer und dienen nur als Untersttzung fr Attribute. Sie k=nnen
innerhalb oder außerhalb einer expliziten Spaltengruppe (d. h., dem COLGROUP-Element) erschei-
Die HTML 4.01- Spezifikation

nen.
Das Attribut width des Elements COL bezieht sich auf die Breite jeder Spalte innerhalb der
Spannweite des Elements.

Berechnen der Spaltenanzahl einer Tabelle


Es gibt zwei M=glichkeiten, die Anzahl der Spalten in einer Tabelle zu bestimmen (in der Rei-
henfolge ihrer Priorit@t):
1. Enth@lt das Element TABLE COLGROUP- oder COL-Elemente, sollten Benutzerprogramme die
Anzahl der Spalten durch folgende Addition errechnen:
·· Verwende fr jedes COL-Element den Wert seines span-Attributs (Standardwert 1).
Ignoriere fr jedes COLGROUP-Element, das mindestens ein COL-Element enth@lt, das span-
Attribut eben dieses COLGROUP-Elements. Vollziehe fr jedes COL-Element die Berechnung
aus Schritt 1.
· Nimm fr jedes leere COLGROUP-Element den Wert seines span-Attributs (Standardwert 1).
2. 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. Fr jede Zeile, die weniger als diese Anzahl Spalten hat, sollte das Ende mit lee-
ren Zellen aufgefllt 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 Berech-
nungen nicht die gleiche Spaltenanzahl ergeben.
Hat das Benutzerprogramm die Anzahl der Spalten in einer Tabelle berechnet, kann es die Spal-
ten in Spaltengruppen einteilen.
Zum Beispiel sollten fr jede der folgenden Tabellen die beiden Spaltenberechnungsmethoden
drei Spalten ermitteln. Die ersten drei Tabellen k=nnen inkrementell aufgebaut werden.

<TABLE>
<COLGROUP span="3"></COLGROUP>
<TR><TD> ...
...Zeilen...
</TABLE>

<TABLE>
<COLGROUP>
<COL>
<COL span="2">
</COLGROUP>
<TR><TD> ...
...Zeilen...
</TABLE>

<TABLE>
<COLGROUP>
<COL>

< 150 > Tabellen


Page size: 168,00 x 240,00 mm

</COLGROUP>
<COLGROUP span="2">
<TR><TD> ...
...Zeilen...
</TABLE>

Die HTML 4.01- Spezifikation


<TABLE>
<TR>
<TD><TD><TD>
</TR>
</TABLE>

Berechnen der Spaltenbreite


Autoren haben drei M=glichkeiten die Spaltenbreite anzugeben:

Fest
Eine feste Breitenangabe wird in Pixeln angegeben (z. B. width=„30“). Eine feste Breiten-
angabe erm=glicht einen inkrementellen Aufbau.
Prozentual
Eine prozentuale Angabe (z. B. width=„20%“) basiert auf dem Prozentsatz des horizontalen
Raums, der fr die Tabelle zur Verfgung 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 Ele-
ments TABLE ein fester Wert zugewiesen, k=nnen Benutzerprogramme die Tabelle sogar
mit proportionalen Spalten inkrementell aufbauen.
Hat die Tabelle jedoch keine feste Breite, mssen 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 keine Informationen zur Breite einer Spalte an, ist ein Benutzerprogramm even-
tuell 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 fr den Inhalt einer bestimmten Tabellenzelle, mssen
Benutzerprogramme die Tabelle eventuell neu aufbauen.

Anmerkung der bersetzer: Die M=glichkeit, dass eine Tabelle inkrementell auf-
gebaut 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 wrde dies zu dem
Ergebnis fhren, dass vorhandene Fenster- oder Frame-Breiten nicht ausreichen; die
Nutzer mssten dann scrollen. Wenn diese Gefahr besteht und es sich nicht gerade um
sehr lange Tabellen handelt, ist es daher im Interesse einer benutzerfreundlichen Dar-
stellung sicher legitim, auch einmal auf inkrementellen Aufbau zu verzichten. Besonders

Elemente zur Tabellenerzeugung < 151 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

wichtig ist dann jedoch, dass der Platzbedarf fr eventuell enthaltene Objekte und Gra-
phiken, deren Ladezeiten naturgem@ß gr=ßer sind, angegeben wird (zum Beispiel ber
width- und height-Attribute).
Die HTML 4.01- Spezifikation

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 fr Spalten enth@lt und keinen Wert
fr das width-Attribut des TABLE-Elements.
Wenn das (visuelle) Benutzerprogramm die Tabellendaten empfangen hat, wird der verfgbare
horizontale Raum vom Benutzerprogramm wie folgt zugewiesen: Zuerst wird das Benutzerpro-
gramm den Spalten eins und zwei je 30 Pixel zuweisen, dann wird der minimal n=tige Raum fr
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 fnf (1*)
bekommt einen Teil und Spalte sechs (3*) erh@lt drei.

<TABLE>
<COLGROUP>
<COL width="30">
<COLGROUP>
<COL width="30">
<COL width="0*">
<COL width="2*">
<COLGROUP align="center">
<COL width="1*">
<COL width="3*" align="char" char=":">
<THEAD>
<TR><TD> ...
...Zeilen...
</TABLE>

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 berschrei-
ben. In der Tat tut das letzte COL genau das, indem es angibt, dass jede Zelle in der Spalte, fr
die es gilt, am Zeichen „:“ ausgerichtet wird.
In der folgenden Tabelle gestattet die Spaltenbreitenangabe dem Benutzerprogramm, die
Tabelle inkrementell zu formatieren:

<TABLE width="200">
<COLGROUP span="10" width="15">
<COLGROUP width="*">
<COL id="penultimate-column">

< 152 > Tabellen


Page size: 168,00 x 240,00 mm

<COL id="last-column">
<THEAD>
<TR><TD> ...
...Zeilen...
</TABLE>

Die HTML 4.01- Spezifikation


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-Ele-
mente nur auftauchen, damit ein id-Wert fr 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.

11.2.5 Tabellenzeilen: Das TR-Element

<!ELEMENT TR - O (TH|TD)+ -- table row - ->


<!ATTLIST TR -- table row - -
%attrs; -- %coreattrs, %i18n, %events - -
%cellhalign; -- horizontal alignment in cells - -
%cellvalign; -- vertical alignment in cells - -
>

Start-Tag: erforderlich, End-Tag: optional

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Elementtitel)
style (inzeilige Formatierungsinformation)

· onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,


onkeydown, onkeyup (eingebettete Ereignisse)

·· bgcolor (Hintergrundfarbe)
align, char, charoff, valign (Zellausrichtung)

Das Element TR fungiert als Beh@lter fr eine Zeile von Tabellenzellen. Der End-Tag kann weg-
gelassen 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>

Elemente zur Tabellenerzeugung < 153 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

11.2.6 Tabellenzellen: Die Elemente TH und TD

<!ELEMENT (TH|TD) - O (%flow;)* - - table header cell, table data cell- ->

<!- - Scope is simpler than headers attribute for common tables - ->
Die HTML 4.01- Spezifikation

<!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 - -
axis CDATA #IMPLIED - - comma-separated list of related headers- -
headers IDREFS #IMPLIED - - list of id's for header cells - -
scope %Scope; #IMPLIED - - scope covered by header cells - -
rowspan NUMBER 1 - - number of rows spanned by cell - -
colspan NUMBER 1 - - number of cols spanned by cell - -
%cellhalign; - - horizontal alignment in cells - -
%cellvalign; - - vertical alignment in cells - -
>

Start-Tag: erforderlich, End-Tag: optional

Attributdefinitionen

headers = idrefs [CS]


Dieses Attribut gibt die Liste der Kopfzellen an, die Kopf-Informationen fr die aktuelle
Datenzelle beinhalten. Der Wert dieses Attributs ist eine durch Leerzeichen getrennte
Liste von Zellnamen; diese Zellen mssen durch Angabe ihres id-Attributs benannt werden.
Autoren verwenden das headers-Attribut im Allgemeinen, um nicht visuellen Benutzerpro-
grammen bei der Darstellung von Kopfinformationen fr 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.
scope = scope-name [CI]
Dieses Attribut gibt die Gruppe der Datenzellen an, fr die die aktuelle Kopfzelle Kopf-
informationen bereit h@lt. Dieses Attribut kann anstelle des Attributs headers verwendet
werden, insbesondere fr einfache Tabellen. Ist dieses Attribut angegeben, muss es einen
der folgenden Werte haben:
· row: Die aktuelle Zelle enth@lt Kopfinformationen fr den Rest der Zeile, die sie ent-
h@lt (siehe auch den Abschnitt ber Tabellenrichtung).
· col: Die aktuelle Zelle enth@lt Kopfinformationen fr den Rest der Spalte, die sie ent-
h@lt.
· rowgroup: Die Kopfzelle enth@lt Kopfinformationen fr den Rest der Zeilengruppe,
die sie enth@lt.
· colgroup: Die Kopfzelle enth@lt Kopfinformationen fr den Rest der Spaltengruppe,
die sie enth@lt.
abbr = text [CS]
Dieses Attribut sollte verwendet werden, um eine abgekrzte Form des Zellinhalts zur
Verfgung zu stellen und k=nnte von Benutzerprogrammen dargestellt werden, wenn es
anstelle des Zellinhalts sinnvoll ist. Abgekrzte Namen sollten kurz sein, weil Benutzerpro-

< 154 > Tabellen


Page size: 168,00 x 240,00 mm

gramme sie wiederholt darstellen k=nnten. Zum Beispiel k=nnten Sprachsythesizer den
abgekrzten Kopf wiedergeben, der zu einer bestimmten Zelle geh=rt, bevor dieser Zell-
inhalt selbst wiedergegeben wird.
axis = cdata [CI]

Die HTML 4.01- Spezifikation


Dieses Attribut kann dazu verwendet werden, eine Zelle in konzeptionelle Kategorien ein-
zuordnen, 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“ fr weiterfhrende Informa-
tionen. Der Wert dieses Attributs ist eine durch Kommata getrennte Liste von Kategorie-
namen.
rowspan = number [CN]
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.
colspan = number [CN]
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.
nowrap [CI]
Missbilligt. Ist dieses Boolesche Attribut angegeben, deutet es visuellen Benutzerprogram-
men, dass sie den automatischen Zeilenumbruch fr diese Zelle ausschalten sollen. Style-
sheets 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.
width = length [CN]
Missbilligt. Dieses Attribut versorgt Benutzerprogramme mit einer empfohlenen Zellbreite.
height = length [CN]
Missbilligt. Dieses Attribut versorgt Benutzerprogramme mit einer empfohlenen Zell-
h=he.

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Elementtitel)
style (inzeilige Formatierungsinformation)

· onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,


onkeydown, onkeyup (eingebettete Ereignisse)

·· bgcolor (Hintergrundfarbe)
align, char, charoff, valign (Zellausrichtung)

Elemente zur Tabellenerzeugung < 155 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

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 Benutzer-
programme Text in Kopfzellen in fettgedruckter Schrift darstellen. Sprachsynthesizer k=nnten
Die HTML 4.01- Spezifikation

die Kopfinformationen in einem anderen Tonfall sprechen.


Das Element TH definiert eine Zelle, die Kopfinformationen enth@lt. Benutzerprogrammen ste-
hen zwei Arten der Kopfinformationen zur Verfgung: der Inhalt des Elements TH und der Wert
des Attributs abbr. Benutzerprogramme mssen entweder den Inhalt der Zelle oder den Wert
des Attributs abbr darstellen. Fr visuelle Medien kann das Letztere angebracht sein, wenn
ungengend Platz zur Darstellung des gesamten Zelleninhalts zur Verfgung steht. Fr nicht
visuelle Medien kann abbr als Abkrzung fr Tabellenk=pfe verwenden, wenn diese zusammen
mit dem Inhalt der Zellen, fr die sie gltig sind, wiedergegeben werden.
Die Attribute headers und scope gestatten es Autoren ebenfalls, nicht visuellen Benutzerpro-
grammen bei der Verarbeitung der Kopfinformationen zu helfen. Bitte lesen Sie die Informa-
tionen und Beispiele im Abschnitt „Kopfinformationen mit Datenzellen verknpfen“ fr 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 Spalten-
beschreibung 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 dar-
stellen:

Name Tassen Kaffeesorte Zucker?


T. Sexton 10 Espresso Nein
J. Dinnen 5 Koffeinfrei Ja

< 156 > Tabellen


Page size: 168,00 x 240,00 mm

Zellen, die sich -ber mehrere Zeilen oder Spalten erstrecken


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 Ele-
mente TH und TD angegeben.

Die HTML 4.01- Spezifikation


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.

<TABLE border="1">
<CAPTION>Von jedem Senator konsumierte Tassen Kaffee</CAPTION>
<TR><TH>Name<TH>Tassen<TH>Kaffeesorte<TH>Zucker?
<TR><TD>T. Sexton<TD>10<TD>Espresso<TD>Nein
<TR><TD>J. Dinnen<TD>5<TD>Koffeinfrei<TD>Ja
<TR><TD>A. Soria<TD colspan="3"><em>Nicht verfUgbar</em>
</TABLE>

Diese Tabelle k=nnte von einem visuellen Benutzerprogramm auf tty-Ger@t wie folgt ausgege-
ben werden:

Von jedem Senator konsumierte Tassen Kaffee


--------------------------------------
| Name |Tassen|Kaffeesorte|Zucker?|
--------------------------------------
|T. Sexton|10 |Espresso |Nein |
--------------------------------------
|J. Dinnen|5 |Koffeinfrei|Ja |
--------------------------------------
|A. Soria |Nicht verfUgbar |
--------------------------------------

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:

<TABLE border="1">
<TR><TD>1 <TD rowspan="2">2 <TD>3
<TR><TD>4 <TD>6
<TR><TD>7 <TD>8 <TD>9
</TABLE>

Weil sich Zelle „2“ ber die erste und zweite Zeile erstreckt, wird die Definition der zweiten
Zeile dies bercksichtigen. 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:

-------------
| 1 | 2 | 3 |
----| |----
| 4 | | 6 |
----|---|----
| 7 | 8 | 9 |
-------------

Elemente zur Tabellenerzeugung < 157 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Ein graphisches Benutzerprogramm hingegen k=nnte dies so darstellen:


Die HTML 4.01- Spezifikation

Beachten Sie: Wenn das TD, welches Zelle „6“ definiert, weggelassen worden w@re, w@re eine
zus@tzliche leere Zelle durch das Benutzerprogramm hinzugefgt worden, um die Zeile zu ver-
vollst@ndigen.
Ohnlich erstreckt sich Zelle „4“ in der folgenden Tabellendefinition:

<TABLE border="1">
<TR><TD>1 <TD>2 <TD>3
<TR><TD colspan="2">4 <TD>6
<TR><TD>7 <TD>8 <TD>9
</TABLE>

ber zwei Spalten, so dass das zweite TD in der Zeile in diesem Fall die dritte Zelle („6“) defi-
niert:

-------------
| 1 | 2 | 3 |
--------|----
| 4 | 6 |
--------|----
| 7 | 8 | 9 |
-------------

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 gltige 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“:

< 158 > Tabellen


Page size: 168,00 x 240,00 mm

<TABLE border="1">
<TR><TD>1 <TD>2 <TD>3
<TR><TD>4 <TD rowspan="2">5 <TD>6
<TR><TD colspan="2">7 <TD>9
</TABLE>

Die HTML 4.01- Spezifikation


11.3 Tabellenformatierung durch visuelle
Benutzerprogramme
Anmerkung: Der folgende Abschnitt beschreibt die Tabellenattribute in HTML, die die visuelle For-
matierung betreffen. Als diese Spezifikation 1997 das erste Mal ver ffentlicht wurde, stellte [CSS1]
nicht alle Mechanismen zur Verfgung, um alle Aspekte der visuellen Tabellenformatierung zu kontrol-
lieren. Seit dieser Zeit hat [CSS2] Eigenschaften hinzugefgt, die eine visuelle Formatierung von Tabel-
len gestatten. n
HTML 4 beinhaltet Kontrollmechanismen fr:
··Rahmendarstellung
horizontale and vertikale Ausrichtung von Zellinhalt
·Zellr@nder

11.3.1 Rahmen und Linien

Die folgenden Attribute betreffen den @ußeren Rahmen und die inneren Linien.

Attributdefinitionen

frame = void|above|below|hsides|lhs|rhs|vsides|box|border [CI]


Dieses Attribut gibt an, welche Seiten des Rahmens, der die Tabelle umgibt, sichtbar sind.
M=gliche Werte:
··
void: Keine Seite. Dies ist der Standardwert.
above: Nur die obere Seite.

··
below: Nur die untere Seite.
hsides: Nur die obere und untere Seite.

··
vsides: Nur die rechte und die linke Seite.
lhs: Nur die linke Seite.

··
rhs: Nur die rechte Seite.
box: Alle vier Seiten.

·
border: Alle vier Seiten.

rules = none|groups|rows|cols|all [CI]


Dieses Attribut gibt an, welche Linien zwischen den Zellen innerhalb einer Tabelle ange-
zeigt 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).

Formatierung durch visuelle Benutzerprogramme < 159 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

·· rows: Linien erscheinen nur zwischen Zeilen.


cols: Linien erscheinen nur zwischen Spalten.

· all: Linien erscheinen zwischen allen Zeilen und Spalten.

border = pixels [CN]


Die HTML 4.01- Spezifikation

Dieses Attribut gibt die Breite (nur in Pixeln) des Rahmens um eine Tabelle an (siehe
Anmerkung unten fr weitere Informationen ber dieses Attribut).

Um die Zellen einer Tabelle auseinander zu halten, k=nnen wir das Attribut border des Ele-
ments 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 fnf Pixel breiten Rand auf der linken
und auf der rechten Seite der Tabelle darstellen und Linien zwischen jeder Spalte.

<TABLE border="5" frame="vsides" rules="cols">


<TR> <TD>1 <TD>2 <TD>3
<TR> <TD>4 <TD>5 <TD>6
<TR> <TD>7 <TD>8 <TD>9
</TABLE>

< 160 > Tabellen


Page size: 168,00 x 240,00 mm

Anmerkung der bersetzer: So k=nnte die Darstellung in einem visuellen Benut-


zerprogramm aussehen:

Die HTML 4.01- Spezifikation


Die folgenden Einstellungen sollten von Benutzerprogrammen aus Grnden der Rckw@rts-
kompatibilit@t berwacht werden:
· Die Angabe border=„0“ impliziert frame=„void“ und, wenn nicht anders angegeben,
rules=„none“.

· Andere Werte fr 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 (un-
gleich Null) fr das Attribut border.
Zum Beispiel sind die folgenden Definitionen @quivalent:

<TABLE border="2">
<TABLE border="2" frame="border" rules="all">

ebenso die folgenden:

<TABLE border>
<TABLE frame="border" rules="all">

Anmerkung: Das Attribut border definiert auch das Erscheinungsbild der Rahmen fr die Elemente
OBJECT und IMG, verwendet jedoch andere Werte fr diese Elemente. n

11.3.2 Horizontale und vertikale Ausrichtung

Die folgenden Attribute k=nnen fr verschiedene Tabellenelemente verwendet werden (siehe
deren Definition):

<!- - horizontal alignment attributes for cell contents - ->


<!ENTITY % cellhalign
"align (left|center|right|justify|char) #IMPLIED
char %Character; #IMPLIED - - alignment char, e.g. char=':' - -
charoff %Length; #IMPLIED - - offset for alignment char - -"
>
<!- - vertical alignment attributes for cell contents - ->

Formatierung durch visuelle Benutzerprogramme < 161 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

<!ENTITY % cellvalign
"valign (top|middle|bottom|baseline) #IMPLIED"
>

Attributdefinitionen
Die HTML 4.01- Spezifikation

align = left|center|right|justify|char [CI]


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 fr Tabel-
lendaten.
·· center: Daten zentrieren/Text zentrieren. Das ist der Standardwert fr 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. Untersttzt ein Benutzerpro-
gramm diese Zeichenausrichtung nicht, ist das Verhalten bei Angabe dieses Werts nicht
definiert.
valign = top|middle|bottom|baseline [CI]
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 Stan-
dardwert.
·· 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.
char = character [CN]
Dieses Attribut gibt ein einzelnes Zeichen in einem Textfragment an, dass als Achse fr die
Ausrichtung fungiert. Der Standardwert fr dieses Attribut ist das Dezimaltrennzeichen der
aktuellen Sprache, die durch das Attribut lang eingestellt ist (z. B. der Punkt („.“) im Eng-
lischen und das Komma („,“) im Franz=sischen). Benutzerprogramme mssen dieses Attri-
but nicht untersttzen.
charoff = length [CN]
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 mssen dieses Attribut nicht
untersttzen.

< 162 > Tabellen


Page size: 168,00 x 240,00 mm

Anmerkung der bersetzer: Derzeit verbreitete Browser untersttzen das


Attribut charoff nicht.

Die HTML 4.01- Spezifikation


Die Tabelle in diesem Beispiel richtet einige W@hrungswerte an einem Dezimalpunkt aus. Wir
setzen das Ausrichtungszeichen explizit auf „.“.

<TABLE border="1">
<COLGROUP>
<COL><COL align="char" char=".">
<THEAD>
<TR><TH>GemUse <TH>Preis pro Kilo
<TBODY>
<TR><TD>Kopfsalat <TD>$1
<TR><TD>Silberne Karotten <TD>$10.50
<TR><TD>Goldene RUben <TD>$100.30
</TABLE>

Die formatierte Tabelle k=nnte dem Folgenden gleichen:

-----------------------------------
| GemUse |Preis pro Kilo|
|----------------- -|--------------|
|Kopfsalat | $1 |
|----------------- -|--------------|
|Silberne Karotten | $10.50|
|----------------- -|--------------|
|Goldene RUben | $100.30|
-----------------------------------

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 defi-
niert. Autoren sollten deshalb achtsam mit char umgehen.

Anmerkung: Visuelle Benutzerprogramme zentrieren TH-Elemente im Allgemeinen vertikal und hori-


zontal in einer Zelle und stellen sie in fettgedruckten Buchstaben dar. n

Vererbung von Ausrichtungsangaben


Die Ausrichtung von Zellinhalt kann Zelle fr Zelle angegeben oder von einschließenden Ele-
menten wie Zeilen, Spalten oder der Tabelle selbst vererbt werden.
Die Rangfolge (vom h=chsten zum niedrigsten Rang) fr die Attribute align, char und charoff
ist die folgende:
1. Ein fr ein Element innerhalb der Zelldaten gesetztes Ausrichtungsattribut (z. B. P).
2. Ein fr eine Zelle gesetztes Ausrichtungsattribut (TH und TD).
3. Ein fr 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.

Formatierung durch visuelle Benutzerprogramme < 163 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

4. Ein fr eine Zeile oder ein Zeilengruppen-Element gesetztes Ausrichtungsattribut (TR,
THEAD, TFOOT und TBODY). Ist eine Zelle Teil eines mehrzeiligen Bereiches, wird die Ausrich-
tungseigenschaft von der Zelldefinition am Anfang des Bereiches vererbt.
5. Ein fr die Tabelle gesetztes Ausrichtungsattribut (TABLE).
Die HTML 4.01- Spezifikation

6. Der Standardausrichtungswert.
Die Rangfolge (vom h=chsten zum niedrigsten Rang) fr die Attribute valign (wie auch fr die
anderen vererbten Attribute lang, dir und style) ist die folgende:
1. Ein fr ein Element innerhalb der Zelldaten gesetztes Attribut (z. B. P).
2. Ein fr eine Zelle gesetztes Attribut (TH und TD).
3. Ein fr 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.
4. Ein fr 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.
5. Ein fr die Tabelle gesetztes Attribut (TABLE).
6. Der Standardattributwert.
Außerdem bestimmen bei der Darstellung von Zellen Spalten bevorzugt vor Zeilen die hori-
zontale Ausrichtung, w@hrend bei vertikaler Ausrichtung Zeilen Vorrang vor Spalten haben.
Die Standardausrichtung fr Zellen ist abh@ngig vom Benutzerprogramm. Jedoch sollten Benut-
zerprogramme 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 untersttzen, 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 Ver-
erbungsregeln fr Attribute. n

11.3.3 Zellenr.nder

Attributdefinitionen
cellspacing = length [CN]
Dieses Attribut gibt an, wie viel Leerraum das Benutzerprogramm stehen lassen soll zwi-
schen 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
fr die rechte Seite und die Unterkante. Das Attribut gibt ebenfalls an, wieviel Freiraum
zwischen Zellen bleiben soll.
cellpadding = length [CN]
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 Verfgung stehenden vertikalen Raums, der linke und der
rechte Rand sollten gleichermaßen vom Inhalt abgesetzt werden, basierend auf einem pro-
zentualen Anteil des zur Verfgung stehenden horizontalen Raums.

< 164 > Tabellen


Page size: 168,00 x 240,00 mm

Diese beiden Attribute kontrollieren die Abst@nde zwischen und innerhalb von Zellen. Die fol-
gende Darstellung illustriert die Beziehung zwischen ihnen:

Die HTML 4.01- Spezifikation


Im folgenden Beispiel gibt das Attribut cellspacing an, dass Zellen voneinander und vom Tabel-
lenrahmen 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 verfgbaren
horizontalen Raums (zusammen 20%) zum Zellinhalt halten sollen. Ohnlich werden der linke
Rand der Zelle und der rechte Rand der Zelle jeweils einen Abstand von 10% des verfgbaren
horizontalen Raums (zusammen 20%) einhalten.

<TABLE cellspacing="20" cellpadding="20%">


<TR> <TD>Data1 <TD>Data2 <TD>Data3
</TABLE>

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 Attri-
buten Vorrang vor dem Attribut width gew@hren, wenn Konflikte auftreten, jedoch sie sind
nicht dazu verpflichtet.

11.4 Tabellendarstellung durch nicht visuelle


Benutzerprogramme
11.4.1 Kopfinformationen mit Datenzellen verkn-pfen

Nicht visuelle Benutzerprogramme wie Sprachsynthesizer und Braille-basierte Ger@te k=nnten


die folgenden Attribute der Elemente TD und TH verwenden, um Tabellenzellen intuitiver dar-
zustellen:
· Fr eine gegebene Datenzelle listet das Attribut headers auf, welche Zellen relevante Kopf-
informationen bieten. Zu diesem Zweck muss jede Kopfzelle ber ein id-Attribut 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 fr solche Zellen zusammen mit
dem id- oder scope-Attribut verwenden, je nachdem, welches sinnvoll ist.

Darstellung durch nicht visuelle Benutzerprogramme < 165 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

· Fr eine gegebene Kopfzelle teilt das Attribut scope dem Benutzerprogramm mit, fr wel-
che Datenzellen dieser Kopf Informationen bereith@lt. Autoren w@hlen vielleicht dieses
Attribut anstatt headers, je nachdem, welches gnstiger ist; beide Attribute erfllen die glei-
che Funktion. Das Attribut headers wird im Allgemeinen ben=tigt, wenn Kopfinformationen
Die HTML 4.01- Spezifikation

an ungew=hnlichen Positionen in Bezug auf die Daten stehen, fr die sie gelten.
· Das Attribut abbr gibt einen abgekrzten Kopfinhalt fr Kopfzellen an, so dass Benutzerpro-
gramme 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-Attri-
but).

<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 abgekrzt wird zu „Sor-
te“.
Hier ist das gleiche Beispiel mit dem Attribut scope anstelle des Attributs headers. Beachten Sie
den Wert „col“ fr das scope-Attribut, das besagt „alle Zellen in der aktuellen Spalte“:

< 166 > Tabellen


Page size: 168,00 x 240,00 mm

<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

Die HTML 4.01- Spezifikation


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 GebUhr">
<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">GebUhr</TH>
</TR>
<TR>
<TD scope="row">Nach dem BUrgerkrieg</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>&pound;32</TD>
</TR>
<TR>
<TD scope="row">Eine EinfUhrung ins angels]chsische England</TD>
<TD>Mark Cottle</TD>
<TD>
Eint]giger Kurs zur EinfUhrung in

Darstellung durch nicht visuelle Benutzerprogramme < 167 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

die frUhe mittelalterliche Epoche des


Wandels der Angelsachsen und ihrer
Gesellschaft. <EM>Samstag 18. Oktober.</EM>
</TD>
<TD>H28</TD>
Die HTML 4.01- Spezifikation

<TD>&pound;18</TD>
</TR>
<TR>
<TD scope="row">Der Ruhm gebUhrt 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>&pound;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
dafr, dass die Datenzelle sich wie eine Zeilen-Kopfzelle verh@lt. Dadurch k=nnen Sprachsyn-
thesizer auf Anfrage den relevanten Kursnamen angeben oder ihn direkt vor jedem Zellinhalt
vortragen.

11.4.2 Zellen kategorisieren

Benutzer, die eine Tabelle mit einem sprachbasierten Benutzerprogramm lesen, m=chten viel-
leicht 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 verknpfen“).

< 168 > Tabellen


Page size: 168,00 x 240,00 mm

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 pas-
senden Kontext bieten. Betrachten Sie die folgende Tabelle, die Unkosten fr Mahlzeiten,
Hotels und den Transport in zwei St@dten (San Jose und Seattle) ber einige Tage einstuft:

Die HTML 4.01- Spezifikation


Benutzer m=chten vielleicht Informationen aus der Tabelle in Form von Anfragen herausfiltern:
·· „Was habe ich fr all meine Mahlzeiten ausgegeben?“
„Was habe ich am 25. August fr 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 fr 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 Schnitt-
menge 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. Fr 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 Bedeu-
tung:
· „Was habe ich fr alle meine Mahlzeiten ausgegeben?“ bedeutet „Wie teuer ist alles zusam-
men in den Zellen der Kategorie Ausgaben=Mahlzeiten?“
· „Was habe ich am 25. August fr Mahlzeiten ausgegeben?“ bedeutet „Wie teuer ist alles zusam-
men 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 fr 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>

Darstellung durch nicht visuelle Benutzerprogramme < 169 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Jede Zelle, die Informationen bezglich „San Jose“ enth@lt, sollte sich auf diese Kopfzelle entwe-
der ber das headers- oder das scope-Attribut beziehen. Deshalb sollten Ausgaben fr Mahlzei-
ten am 25. August so ausgezeichnet werden, das sie sich auf das id-Attribute (dessen Wert hier
„a6“ ist) der „San Jose“-Kopfzelle beziehen:
Die HTML 4.01- Spezifikation

<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:

<TABLE border="1"
summary="Diese Tabelle berechnet Reisekosten,
die w]hrend der Reise nach
San Jose und Seattle angefallen sind.">
<CAPTION>
Reisekostenreport
</CAPTION>
<TR>
<TH></TH>
<TH id="a2" axis="ausgaben">Mahlzeiten</TH>
<TH id="a3" axis="ausgaben">Hotels</TH>
<TH id="a4" axis="ausgaben">Transport</TH>
<TD>Zwischensumme</TD>
</TR>
<TR>
<TH id="a6" axis="ort">San Jose</TH>
<TH></TH>
<TH></TH>
<TH></TH>
<TD></TD>
</TR>
<TR>
<TD id="a7" axis="datum">25-Aug-97</TD>
<TD headers="a6 a7 a2">37.74</TD>
<TD headers="a6 a7 a3">112.00</TD>
<TD headers="a6 a7 a4">45.00</TD>
<TD></TD>
</TR>
<TR>
<TD id="a8" axis="datum">26-Aug-97</TD>
<TD headers="a6 a8 a2">27.28</TD>
<TD headers="a6 a8 a3">112.00</TD>
<TD headers="a6 a8 a4">45.00</TD>
<TD></TD>
</TR>
<TR>
<TD>Zwischensumme</TD>
<TD>65.02</TD>
<TD>224.00</TD>
<TD>90.00</TD>
<TD>379.02</TD>
</TR>

< 170 > Tabellen


Page size: 168,00 x 240,00 mm

<TR>
<TH id="a10" axis="ort">Seattle</TH>
<TH></TH>
<TH></TH>
<TH></TH>

Die HTML 4.01- Spezifikation


<TD></TD>
</TR>
<TR>
<TD id="a11" axis="datum">27-Aug-97</TD>
<TD headers="a10 a11 a2">96.25</TD>
<TD headers="a10 a11 a3">109.00</TD>
<TD headers="a10 a11 a4">36.00</TD>
<TD></TD>
</TR>
<TR>
<TD id="a12" axis="datum">28-Aug-97</TD>
<TD headers="a10 a12 a2">35.00</TD>
<TD headers="a10 a12 a3">109.00</TD>
<TD headers="a10 a12 a4">36.00</TD>
<TD></TD>
</TR>
<TR>
<TD>Zwischensumme</TD>
<TD>131.25</TD>
<TD>218.00</TD>
<TD>72.00</TD>
<TD>421.25</TD>
</TR>
<TR>
<TH>Gesamtsumme</TH>
<TD>196.27</TD>
<TD>442.00</TD>
<TD>162.00</TD>
<TD>800.27</TD>
</TR>
</TABLE>

Beachten Sie, dass Benutzerprogramme durch die Auszeichnung einer Tabelle auf diese Weise
auch vermeiden k=nnen, Benutzer mit ungewollten Informationen zu verwirren. Sollte zum Bei-
spiel ein Sprachsynthesizer alle Angaben in der Spalte „Mahlzeiten“ der Tabelle auf die Anfrage
„Wie hoch waren all meine Ausgaben fr 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.
Natrlich 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 „Zwi-
schensummen“ und „Gesamtsummen“ hinzufgen.
Diese Spezifikation verlangt von Benutzerprogrammen weder, axis-Attribut angegebene Infor-
mationen zu verarbeiten, noch gibt sie irgendwelche Empfehlungen darber, wie Benutzerpro-
gramme dem Nutzer die axis -Informationen pr@sentieren sollten, oder wie Nutzer diese
Informationen beim Benutzerprogramm erfragen k=nnten.

Darstellung durch nicht visuelle Benutzerprogramme < 171 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Jedoch m=chten Benutzerprogramme, insbesondere Sprachsynthesizer, eventuell Informa-


tionen ausklammern, die in mehreren Zellen vorkommen, die das Ergebnis einer Anfrage sind.
Wenn der Benutzer zum Beispiel fragt „Was habe ich fr Mahlzeiten in San Jose ausgegeben?“,
wrde das Benutzerprogramm zuerst die in Frage kommenden Zellen bestimmen
Die HTML 4.01- Spezifikation

(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 wrde 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 untersttzen, sollten eine M=glichkeit bie-
ten, die Darstellung anzupassen (z. B. durch Stylesheets).

11.4.3 Algorithmen zur Auffindung von Kopfinformationen

Werden keine Kopfinformationen durch das scope- oder das headers-Attribut angegeben, k=n-
nen Benutzerprogramme nach dem folgenden Algorithmus Kopfinformationen erzeugen. Das
Ziel des Algorithmus ist, eine geordnete Liste mit Kopfinformationen zu ermitteln. (In der fol-
genden Beschreibung des Algorithmus wird die Tabellenrichtung von links nach rechts ange-
nommen.)
· Suche zuerst links der Zellposition, um Kopfzellen fr Zeilen zu finden. Dann suche auf-
w@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 eingefgt, in der sie in der Tabelle
erscheinen. In Tabellen der Richtung links nach rechts werden die K=pfe von links nach
rechts eingefgt.
· Spaltenk=pfe werden nach Zeilenk=pfen in der Reihenfolge eingefgt, in der sie in der
Tabelle erscheinen, von oben nach unten.
· Ist das headers-Attribut fr eine Kopfzelle angegeben, dann werden die Header, die von die-
sem Attribut referenziert werden, in die Liste eingefgt und die Suche stoppt fr die aktu-
elle Richtung.
· TD-Zellen mit dem Attribut axis werden ebenfalls als Kopfzellen behandelt.

< 172 > Tabellen


Page size: 168,00 x 240,00 mm

11.5 Beispieltabelle
Dieses Beispiel zeigt gruppierte Zeilen und Spalten. Das Beispiel ist bernommen aus „Develo-
ping International Software“ von Nadine Kano.

Die HTML 4.01- Spezifikation


In ASCII-Darstellung wrde 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

Beispieltabelle < 173 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

1255 | Hebrew | X | X
1256 | Arabic | X | X
1257 | Baltic | X | X
1361 | Korean (Johab) | X | ** X
----------------------------------------------------------------------------- --
Die HTML 4.01- Spezifikation

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. Ohnlich wird TBODY verwendet, um Zeilen zu grup-
pieren. Die Attribute frame und rules geben dem Benutzerprogramm an, welche Rahmen und
Linien gezeichnet werden sollen.

< 174 > Tabellen


Page size: 168,00 x 240,00 mm

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

Die HTML 4.01- Spezifikation


gewnscht darstellt. Das align-Attribut in COLGROUP ignorieren fast alle; mit den vorgege-
benen R@ndern und Linien haben nur wenige kein Problem.

Anmerkung der bersetzer: Abschließend zum Thema „Tabellen“ hier ein Bei-
spiel, 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 Sei-
ten der Web-Site zu finden ist, in der Mitte der eigentliche Inhalt steht und rechts sons-
tige Informationen untergebracht werden. In der Regel wurden und werden derartige
Seiten durch den Einsatz einer dreispaltige Tabelle realisiert. Unter Nutzung von Style-
sheets (ohne Tabelle) k=nnte so eine Seite etwa so aussehen:

<html>
<head>
<title>Dornr^schen</title>
<style type="text/css">
body {
background-color: #999999;
font-family: Verdana,Geneva,Arial,Helvetica,sans-serif;
font-size: 80%;
color: #ffffff;
}
#kopf {
width: 100%;
text-align: center;
}
#navigation {
background: #000000;
color: #ffffff;
width: 20%;
float: left;
}
#haupttext {
background: #ffffff;
color: #000000;
float: left;
width: 60%;
}
#hinweise {
background: #cccccc;
color: #ffffff;
float: left;
width: 20%;
}
H1 {
font-size: 180%;

Beispieltabelle < 175 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

font-weight: bold;
margin: 0.5em 0em 1.5em 0em;
}
H2 {
Die HTML 4.01- Spezifikation

font-size: 140%;
font-weight: bold;
padding: 1.5em 1em 0.5em 1em;
}
#navigation P {
color: #ffffff;
padding: 0.1em 1em 0.1em 1em;
}
#haupttext P {
color: #000000;
padding: 0.1em 1em 0.1em 1em;
}
#hinweise P {
color: #ffffff;
padding: 0.1em 1em 0.1em 1em;
}
#navigation P A:link {
color: #cccccc;
}
#navigation P A:visited {
color: #999999;
}
#hinweise P A:link {
color: #000000;
}
#hinweise P A:visited {
color: #333333;
}
</style>
</head>
<body>
<div id="kopf">
<h1>Die M]rchen der GebrUder Grimm</h1>
</div>
<div id="navigation">
<p><a href="allerleirauh.html">Allerleirauh</a></p>
<p><a href="bruderlustig.html">Bruder Lustig</a></p>
<p><a href="bruederchenunschwesterchen.html">BrUderchen und
Schwesterchen</a></p>
<p><a href="dastapfereschneiderlein.html">Das tapfere Schneiderlein</a></p>
<p><a href="derfroschkoenig.html">Der Froschk^nig</a></p>
Die Links zu den Ubrigen M]rchen...
</div>
<div id="haupttext">
<h2>Dornr^schen</h2>
<p>Vorzeiten war ein K^nig und eine K^nigin...</p>
Der Rest des M]rchens...
</div>
<div id="hinweise">
<p><a href="http://andereMaerchen.de/">andere M]rchen</a></p>
<p><a href="maerchenbuecher.html">M]rchenbUcher</a></p>

< 176 > Tabellen


Page size: 168,00 x 240,00 mm

<p><a href="maerchenlinks.html">M]rchenlinks</a></p>
<p><a href="impressum.html">Impressum</a></p>
<p><a href="kontakt.html">Kontakt</a></p>
</div>

Die HTML 4.01- Spezifikation


</body>
</html>

Und so sollte das Ergebnis aussehen:

So sollte es aussehen, denn bereits bei der L=sung dieser vergleichsweise einfachen Auf-
gabe haben einige der getesteten aktuellen Browser leichte Schwierigkeiten, sie stellen
nicht wirklich sauber dar oder verschieben das Layout bei geringfgigen Onderungen
der Benutzereinstellungen, zum Beispiel der Schriftgr=ße – kein wirklich zufriedenstel-
lendes Ergebnis also, denn so simpel wie dieses sind Layouts in der Praxis oft nicht.
Weniger Probleme entstehen bei festen Positionierungen und starren Vorgaben fr
Schriftgr=ßen (px), nur ist der Preis dafr, n@mlich die Aufgabe jeglicher Anpassungs-
f@hgkeit, zu hoch.
Fazit: Stylesheets sind die anzustrebende Alternative fr Tabellenlayouts, aber erst dann
eine wirkliche, wenn die Browserlandschaft ihr gewachsen ist. Bis dahin werden Auto-
ren und Benutzer mit Einschr@nkungen und eventuell mit Kompromissen leben.

Beispieltabelle < 177 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Anmerkung der bersetzer: Das Tabellenmodell von HTML ist zeilenorientiert.


Das heißt auch, dass Tabellen Zeile fr Zeile eingegeben werden. HTML- oder XML-
Editoren gestatten natrlich auch eine Eingabe in eine graphisch dargestellte Tabelle.
Die HTML 4.01- Spezifikation

Manchmal kann diese Zeilenorientierung unbequem sein, und man wrde sich eine Spal-
tenorientierung wnschen. In einem solchen Fall muss die Tabelle „nur“ transponiert
werden (das heißt, Spiegelung an der Hauptdiagonalen). So fern es sich um eine regel-
m@ß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 Transponie-
rung sehr einfach durchfhren. Da einer der bersetzer krzlich selbst vor diesem
Problem stand, finden Sie unter www.mintert.com/xslt/ ein kleines XSLT-Programm,
das die Transponierung fr eine solche XHTML-Tabelle durchfhrt.

12 Links
12.1 Einf-hrung in Links und Anker
HTML bietet viele der herk=mmlichen Publikationsm=glichkeiten fr Rich-Text und struktu-
rierte Dokumente. Was den Unterschied zu den meisten anderen Auszeichnungssprachen aus-
macht, sind die Merkmale: Hypertext und interaktive Dokumente. Dieser Abschnitt stellt den
Link (auch Hyperlink oder Web-Link), das grundlegende Hypertext-Konstrukt, vor. Ein Link ist
eine Verbindung von einer Web-Ressource zur anderen. Wenngleich ein einfaches Konzept,
war der Link eine der wichtigsten Kr@fte, die den Erfolg des Webs vorangetrieben haben.
Ein Link hat zwei Enden – genannt Anker – und eine Richtung. Der Link beginnt beim
„Quell“-Anker und zeigt auf den „Ziel“-Anker, der eine beliebige Web-Ressource sein kann
(zum Beispiel ein Bild, ein Videoclip, ein Klangschnipsel, ein Programm, ein HTML-Dokument,
ein Element innerhalb eines HTML-Dokuments und so weiter).

12.1.1 Besuchen einer verlinkten Ressource

Standardm@ßig wird ber einen Link eine andere Web-Ressource gefunden. Dieses Verhalten
wird gew=hnlich ohne weiteres durch Auswahl eines Links (zum Beispiel durch Anklicken,
durch eine Tastatureingabe usw.) erreicht.
Der folgende HTML-Auszug enth@lt zwei Links, einen, dessen Zielanker ein HTML Dokument
namens „chapter2.html“ ist, und einen anderen, dessen Zielanker ein GIF-Bild in der Datei
„forest.gif“ ist:

<BODY>
...Text...
<P>Sie k^nnen eine Menge mehr in <A href="chapter2.html">Kapitel zwei</A> finden.
Schauen Sie bitte auch diese <A href="../images/forest.gif">Karte des
Zauberwaldes</A> an.
</BODY>

< 178 > Links


Page size: 168,00 x 240,00 mm

Bei der Aktivierung dieser Links (durch Anklicken mit der Maus, Tastatureingabe, Sprach-
befehle usw.) k=nnen Benutzer diese Ressourcen aufsuchen. Beachten Sie, dass das href-Attri-
but in jedem Quellanker die Adresse des Zielankers durch einen URI spezifiziert.
Der Zielanker eines Links kann ein Element innerhalb eines HTML-Dokuments sein. Der Ziel-

Die HTML 4.01- Spezifikation


anker muss einen Ankernamen besitzen, und jede URI-Adressierung dieses Ankers muss den
Namen als Fragmentbezeichner enthalten (siehe Abschnitt 2.1.2).
Zielanker in HTML-Dokumenten k=nnen entweder duch das Element A (benannt durch das name-
Attribut) oder durch ein anderes Element (benannt durch das id-Attribut) angegeben werden.
So k=nnte zum Beispiel ein Autor ein Inhaltsverzeichnis erstellen, dessen Eintr@ge auf ber-
schriften-Elemente H2, H3 und so weiter im gleichen Dokument verweisen. Unter Verwendung
des A-Elements zur Erstellung von Zielankern wrden wir schreiben:

<H1>Inhaltsverzeichnis</H1>
<P><A href="#section1">EinfUhrung</A><BR>
<A href="#section2">Etwas zum Hintergrund</A><BR>
<A href="#section2.1">Eine pers^nliche Anmerkung</A><BR>
...Der Rest des Inhaltsverzeichnisses...
...Der Dokumentrumpf...
<H2><A name="section1">EinfUhrung</A></H2>
...Abschnitt 1...
<H2><A name="section2">Etwas zum Hintergrund</A></H2>
...Abschnitt 2...
<H3><A name="section2.1">Eine pers^nliche Anmerkung</A></H3>
...Abschnitt 2.1...

Wir k=nnen denselben Effekt erreichen, wenn wir die berschriften-Elemente selbst zu
Ankern machen:

<H1>Inhaltsverzeichniss</H1>
<P><A href="#section1">EinfUhrung</A><BR>
<A href="#section2">Etwas zum Hintergrund</A><BR>
<A href="#section2.1">Eine pers^nliche Anmerkung</A><BR>
...Der Rest des Inhaltsverzeichnisses...
...Der Dokumentrumpf...
<H2 id="section1">EinfUhrung</H2>
...Abschnitt 1...
<H2 id="section2">Etwas zum Hintergrund</H2>
...Abschnitt 2...
<H3 id="section2.1">Eine pers^nliche Anmerkung</H3>
...Abschnitt 2.1...

12.1.2 Andere Link-Beziehungen

Die bei weitem h@ufigste Nutzungsart von Links ist die, wie in dem vorigen Beispiel dargestellt,
andere Web-Ressourcen aufzurufen. Autoren k=nnen jedoch auch Links in ihre Dokumente
aufnehmen, die andere Beziehungen zwischen den Ressourcen ausdrcken als einfach nur „akti-
viere diesen Link, um die betreffende Ressource aufzusuchen“. In Quellankern von Links, die
andere Arten von Beziehungen ausdrcken, sind ein oder mehr Linktypen spezifiziert.
Die Rolle eines durch A oder LINK definierten Links wird durch die rel und rev-Attribute
bestimmt.

Einf#hrung in Links und Anker < 179 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Beispielsweise k=nnen Links, die mit mit Hilfe des LINK-Elements definiert sind, die Position
eines Dokuments innerhalb einer Serie von Dokumenten beschreiben. Im folgenden Auszug
verweisen Links innerhalb des mit „Kapitel 5“ betitelten Dokuments auf das vorhergehende
und das nachfolgende Kapitel:
Die HTML 4.01- Spezifikation

<HEAD>
...andere Kopfinformation...
<TITLE>Kapitel 5</TITLE>
<LINK rel="prev" href="chapter4.html">
<LINK rel="next" href="chapter6.html">
</HEAD>

Der Linktyp des ersten Links ist „prev“ und der des zweiten ist „next“ (zwei von mehreren
erkannten Linktypen). Durch LINK spezifizierte Links werden nicht mit dem Dokumentinhalt
dargestellt. Benutzerprogramme k=nnen sie jedoch auf andere Weise wiedergeben (zum Bei-
spiel als Navigationswerkzeuge).

Anmerkung der bersetzer: Der Mozilla-Browser zum Beispiel nutzt diese Links,
so sie in einem Dokument vorhanden sind, um dem Benutzer ein bequemes Navigations-
instrument anzubieten. Schauen wir als Beispiel die Originalfassung dieses Kapitels der
HTML-Spezifikation unter http://www.w3.org/TR/1999/REC-html401-19991224/struct/
links.html an. Sie enth@lt folgende Links:

<link rel="previous" href="tables.html">


<link rel="next" href="objects.html">
<link rel="contents" href="../cover.html#toc">

Wird die Seite im Browser geladen, so zeigt er eine Navigationsleiste, ber die man in
Fall unserer Beispielseite zur vorhergehenden Seite (das ist Kapitel 11, „Tables“,
tables.html), zur n@chsten Seite (das ist Kapitel 13, „Objects, Images, and Applets“,
objects.html) und zum Inhaltsverzeichnis (cover.html) gelangen kann.

< 180 > Links


Page size: 168,00 x 240,00 mm

Die HTML 4.01- Spezifikation


Auch wenn sie nicht fr die Navigation benutzt werden, k=nnen diese Links auf interessante
Weise interpretiert werden. Beispielsweise kann ein Benutzerprogramm, das eine Serie von
HTML-Dokumenten als ein einziges Dokument ausdruckt, die Informationen dieser Links als
Grundlage fr den Aufbau eines durchgehenden zusammenh@ngenden Dokuments nutzen.
Mehr Informationen sind weiter unten unter „Links und Suchmaschinen“ zu finden.

12.1.3 Links und Anker definieren

Obgleich verschiedene HTML-Elemente und -Attribute Links zu anderen Ressourcen erzeugen


(zum Beispiel das Element IMG, das Element FORM usw.), befasst sich dieses Kapitel mit Links und
Ankern, die durch die Elemente LINK und A erzeugt werden. Das Element LINK darf nur im Kopf
eines Dokuments auftauchen. Das Element A darf nur im Rumpf stehen.
Ist das href-Attribut des A-Elements gesetzt, so definiert das Element einen Quellanker fr
einen Link, der vom Benutzer aktiviert werden kann, um eine Web-Ressource abzurufen. Der
Quellanker ist die Position der A-Instanz und der Zielanker ist die Web-Ressource.
Die aufgerufene Ressource kann vom Benutzerprogramm auf unterschiedliche Art behandelt
werden: durch Sffnen eines neuen HTML-Dokuments im gleichen Fenster des Benutzerpro-
gramms, durch Sffnen eines neuen HTML-Dokuments in einem anderen Fenster, durch Star-
ten eines anderen Programms, das die Ressource bearbeitet und so weiter. Da das A-Element
Inhalt besitzt (Text, Bilder usw.), k=nnen Benutzerprogramme diesen Inhalt auf eine Art wie-
dergeben, die auf das Vorhandensein eines Links hinweist (zum Beispiel durch Unterstreichen
des Inhalts).
Wenn das name- oder das id-Attribut des Elements A gesetzt ist, definiert das Element einen
Anker, der Ziel anderer Links sein kann.
Autoren k=nnen name- und href-Attribut gleichzeitig in derselben A-Instanz setzen.
Das Element LINK definiert eine Beziehung zwischen dem aktuellen Dokument und einer ande-
ren Ressource. Obwohl LINK keinen Inhalt hat, kann die definierte Beziehung von manchen
Benutzeragenten wiedergegeben werden.

Einf#hrung in Links und Anker < 181 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

12.1.4 Linktitel

Das title-Attribut kann sowohl fr A als auch fr LINK gesetzt werden, um Informationen ber
ber den Link hinzuzufgen. Diese Information k=nnen vom Benutzerprogramm gesprochen
Die HTML 4.01- Spezifikation

werden, als Tooltip wiedergegeben werden, eine Onderung der Cursordarstellung bewirken
und vieles mehr.
Damit k=nnen wir ein vorangehendes Beispiel erweitern, indem wir fr jeden Link einen Titel
anbieten:

<BODY>
...Text...
<P>Sie k^nnen eine Menge mehr in <A href="chapter2.html"
title="Gehe zu Kapitel zwei">Kapitel zwei</A> finden.
<A href="./chapter2.html"
title="Hole Kapitel zwei.">chapter two</A>.
Schauen Sie bitte auch diese <A href="../images/forest.gif"
title="GIF-Bild des Zauberwaldes">Karte
des Zauberwaldes</A> an.
</BODY>

12.1.5 Internationalisierung und Links

Da Links auf Dokumente mit anderer Zeichenkodierung (siehe Abschnitt 5.1) weisen k=nnen,
untersttzen A- und LINK-Element das charset-Attribut. Dieses Attribut erlaubt es Autoren, das
Benutzerprogramm ber die Datenkodierung am anderen Ende des Links zu informieren.
Das hreflang-Attribut versorgt das Benutzerprogramm mit Informationen ber die Sprache
der Ressource am Ende eines Links, so, wie das lang-Attribut Information ber die Sprache des
Inhalts eines Elements oder den Wert eines Attributs zur Verfgung stellt.
Ausgerstet mit diesem zus@tzlichen Wissen sollten es Benutzerprogramme vermeiden k=n-
nen, dem Benutzer „Mll“ zu pr@sentieren. Statt dessen k=nnen sie entweder Ressourcen aus-
findig machen, die fr die korrekte Pr@sentation des Dokuments notwendig sind, oder sie soll-
ten, so sie die Ressourcen nicht finden k=nnen, den Benutzer wenigstens warnen, dass das
Dokument unlesbar sein wird, und den Grund erkl@ren.

12.2 Das Element A


<!ELEMENT A - - (%inline;)* -(A) - - anchor - ->
<!ATTLIST A
%attrs; -- %coreattrs, %i18n, %events - -
charset %Charset; #IMPLIED -- char encoding of linked resource - -
type %ContentType; #IMPLIED -- advisory content type - -
name CDATA #IMPLIED -- named link end - -
href %URI; #IMPLIED -- URI for linked resource - -
hreflang %LanguageCode; #IMPLIED -- language code - -
rel %LinkTypes; #IMPLIED -- forward link types - -
rev %LinkTypes; #IMPLIED -- reverse link types - -
accesskey %Character; #IMPLIED -- accessibility key character - -
shape %Shape; rect -- for use with client-side image maps - -
coords %Coords; #IMPLIED -- for use with client-side image maps - -
tabindex NUMBER #IMPLIED -- position in tabbing order - -

< 182 > Links


Page size: 168,00 x 240,00 mm

onfocus %Script; #IMPLIED - - the element got the focus - -


onblur %Script; #IMPLIED - - the element lost the focus - -
>

Start-Tag: erforderlich, End-Tag: erforderlich

Die HTML 4.01- Spezifikation


Attributdefinitionen

name = cdata [CS]


Dieses Attribut bennent den aktuellen Anker, so dass er Ziel eines anderen Links sein kann.
Der Wert dieses Attributs muss ein eindeutiger Ankername sein. Der Geltungsbereich die-
ses Namens ist das aktuelle Dokument. Beachten Sie bitte, dass dieses Attribut den gleichen
Namensraum hat wie das id-Attribut.
href = uri [CT]
Dieses Attribut gibt die Position einer Web-Ressource an und definiert so einen Link zwischen
dem aktuellen Element (dem Quellanker) und dem durch dieses Attribut definierten Zielanker.
hreflang = langcode [CI]
Dieses Attribut gibt die Basissprache der durch href bestimmten Ressource an. Es kann nur
benutzt werden, wenn href angegeben ist.
type = content-type [CI]
Dieses Attribut gibt einen Hinweis auf den Inhaltstyp des an der Zieladresse des Links vor-
handenen Inhalts. Es erlaubt Benutzerprogrammen, sich fr den Einsatz eines Fallback-Me-
chanismus zu entscheiden, statt den Inhalt zu holen, wenn sie darber benachrichtigt wer-
den, dass sie Inhalt mit einem Inhaltsyp erhalten, den sie nicht untersttzen.
Autoren, die dieses Attribut benutzen, bernehmen die Verantwortung, das Risiko der
Inkonsistenz mit dem an der Zieladresse des Links verfgbaren Inhalt zu behandeln.
Die aktuelle Liste der registrierten Inhaltsypen finden Sie unter [MIMETYPES].
rel = link-types [CI]
Dieses Attribut beschreibt die Beziehung vom aktuellen Dokument zu dem durch das href-
Attribut angegebenen Anker. Der Wert dieses Attributs ist eine durch Leerzeichen
getrennte Liste von Linktypen.
rev = link-types [CI]
Dieses Attribut wird benutzt, um einen Rckw@rtslink vom durch das href-Attribut angege-
benen Anker zum aktuellen Dokument zu beschreiben. Der Wert dieses Attributs ist eine
durch Leerzeichen getrennte Liste von Linktypen.
charset = charset [CI]
Dieses Attribut gibt die Zeichenkodierung der durch den Link bezeichneten Ressource an.
Details finden Sie in Abschnitt 5.2, „Zeichenkodierungen“.

An anderer Stelle definierte Attribute


·· id, class (dokumentenweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Elementtitel)
style (inzeilige Formatierungsinformationen)

·· shape und coords (Imagemaps)


onfocus, onblur, onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmou-
seout, onkeypress, onkeydown, onkeyup (eingebettete Ereignisse )

Das Element A < 183 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

·· target (Ziel-Frame-Angabe)
tabindex (Tabulatornavigation)

· accesskey (Zugriffstaste)

Jedes A-Element definiert einen Anker


Die HTML 4.01- Spezifikation

1. Der Inhalt des A-Elements bestimmt die Position des Ankers.


2. Das name-Attribut benennt den Anker, so dass er Ziel von null oder mehr Links sein kann
(siehe auch Anker mit id).
3. Das href-Attribut macht diesen Anker zum Quellanker von genau einem Link.
Autoren k=nnen auch ein A-Element erstellen, das keine Anker definiert, d. h., weder href, name
noch id sind angegegeben. Werte fr diese Attribute k=nnen zu einem sp@teren Zeitpunkt per
Skript gesetzt werden.

Anmerkung der bersetzer: Mit dieser M=glichkeit sollten Autoren @ußerst


bewusst und vorsichtig umgehen und stets bedenken, dass Scripting nicht zwingend zur
Verfgung steht.

Im folgenden Beispiel definiert das A-Element einen Link. Quellanker ist der Text „W3C Web-
Site“ und Zielanker ist „http://www.w3.org/“:

Mehr Informationen Uber das W3C bekommen Sie auf der


<A href="http://www.w3.org/">Web-Site des W3C </A>.

Dieser Link weist auf die Homepage des World Wide Web Consortium. Wenn ein Benutzer
den Verweis in einem Benutzerprogramm aktiviert, wird das Benutzerprogramm die Ressour-
ce, die in diesem Fall ein HTML-Dokument ist, abrufen.
Benutzerprogramme stellen Links gew=hnlich so dar, dass sie fr den Benutzer augenf@llig sind
(unterstrichen, invertiert usw.). Die exakte Wiedergabe h@ngt vom Benutzerprogramm ab. Die
Wiedergabe kann abh@ngig davon, ob der Benutzer den Link bereits besucht hat oder nicht,
variieren. Eine m=gliche visuelle Wiedergabe des vorigen Links k=nnte so aussehen:

Mehr Informationen Uber das W3C bekommen Sie auf der Web-Site des W3C.
~~~~~~~~~~~~~~~~

Anmerkung der bersetzer: Autoren k=nnen durch Setzen der entsprechenden


Attributwerte im BODY-Start-Tag oder mit Hilfe von Stylesheets vom Standardverhalten
abweichende eigene Vorgaben machen. Sie sollten dabei aber stets darauf achten, dass
die Benutzerfreundlichkeit erhalten bleibt. Nicht mehr oder nur schwer als Links
erkennbare Links etwa sind wenig benutzerfreundlich.

< 184 > Links


Page size: 168,00 x 240,00 mm

Um einem Benutzerprogramm die Zeichenkodierung der Zielseite explitzit mitzuteilen, setzen


Sie das charset-Attribut:

Mehr Informationen Uber das W3C bekommen Sie auf der

Die HTML 4.01- Spezifikation


<A href="http://www.w3.org/" charset="ISO-8859-1">Web-Site des W3C</A>.

Angenommen, wir definieren einen Anker namens „anker-one“ in der Datei „one.html“.

...Text vor dem Anker...


<A name="anchor-one">Hier befindest sich anker-one.</A>
...Text nach dem Anker...

Es wird ein Anker um den Text „Hier befindest sich anker-one.“ erstellt. blicherweise wird
der Inhalt von A nicht auf spezielle Art dargestellt, wenn A lediglich einen Anker definiert.
Nachdem wir den Anker definiert haben, k=nnen wir vom gleichen oder einem anderen Doku-
ment aus auf ihn verweisen. URIs, die Anker kennzeichnen, enthalten ein „#“-Zeichen gefolgt
vom Namen des Ankers (dem Fragmentbezeichner). Hier folgen einige Beispiele fr solche
URIs:
·· Ein absoluter URI: http://www.mycompany.com/one.html#anchor-one
Ein relativer URI: ./one.html#anchor-one oder one.html#anchor-one
· Wenn der Verweis im gleichen Dokument definiert ist: #anchor-one
Ein Link, der in der in demselben Verzeichnis wie „one.html“ befindlichen Datei „two.html“
definiert ist, wrde folgendermaßen auf den Anker verweisen:

...Text vor dem Link...


Mehr Informationen finden Sie unter <A href="./one.html#anchor-one"> anchor one</A>.
...Text nach dem Link...

Das A-Element im folgenden Beispiel spezifiziert gleichzeitig einen Verweis (mittels href) und
erstellt einen benannten Anker (mittels name):

Ich bin gerade aus dem Urlaub zurUck! Hier ist ein
<A name="anchor-two"
href="http://www.somecompany.com/People/Ian/vacation/family.png">
Foto meiner familie am See.</A>.

Dieses Beispiel enth@lt einen Link auf eine andere Art Web-Ressource (einem PNG-Bild). Die
Aktivierung des Links sollte bewirken, dass die Bildquelle aus dem Web abgerufen wird (und,
falls das System konfiguriert wurde, dies zu tun, dargestellt wird).

Anmerkung: Benutzerprogramme sollten in der Lage sein, von leeren A-Elementen erstellte Anker
zu finden; manche versagen jedoch dabei. Zum Beispiel k nnen einige Benutzerprogramme den Anker
„empty-anchor“ im folgenden HTML-Auszug nicht finden:

<A name="empty-anchor"></A>
<EM>...etwas HTML...</EM>
<A href="#empty-anchor">Link auf empty-anchor</A> n

Das Element A < 185 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Anmerkung der bersetzer: Von der Verwendung leerer A-Elemente raten auch
die bersetzer dieser Spezifikation ab, da zum Zeitpunkt der bersetzung g@ngige
Browser dieses unerwnschte Verhalten noch immer zeigen.
Die HTML 4.01- Spezifikation

12.2.1 Die Syntax von Ankernamen

Ein Ankername ist entweder der Wert des name- oder des id-Attributs, wenn diese im Kontext
von Ankern verwendet werden. Ankernamen mssen die folgenden Regeln beachten:
· Eindeutigkeit: Ankernamen mssen innerhalb eines Dokuments eindeutig sein. Anker-
namen, die sich nur in Groß- und Kleinschreibung unterscheiden, k=nnen nicht im selben
Dokument vorkommen.
· Zeichenfolgenabgleich: Vergleiche zwischen Fragmentbezeichner und Ankernamen
mssen auf genaue bereinstimmung hin (Groß- und Kleinschreibung) durchgefhrt wer-
den.
Damit ist das folgende Beispiel hinsichtlich des Zeichenfolgenabgleiches korrekt und muss von
Benutzerprogramm als zutreffend angesehen werden:

<P><A href="#xxx">...</A>
...mehr Dokument...
<P><A name="xxx">...</A>

UNG LTIGES BEISPIEL:


Das folgende Beispiel ist bezglich der Eindeutigkeit ungltig, da beiden Namen sich nur in
Groß- und Kleinschreibung unterscheiden:

<P><A name="xxx">...</A>
<P><A name="XXX">...</A>

Obwohl der folgende Auszug gltiges HTML darstellt, ist das Verhalten von Benutzerprogram-
men nicht definiert; einige Benutzerprogramme k=nnten dies (f@lschlicherweise) als zutreffend
betrachten und andere nicht.

<P><A href="#xxx">...</A>
...Mehr Dokument...
<P><A name="XXX">...</A>

Ankernamen sollten auf ASCII-Zeichen beschr@nkt sein. Im Anhang B finden Sie weitere Infor-
mationen unter „Nicht-ASCII-Zeichen in URI-Attributwerten“.

12.2.2 Verschachtelte Links sind unzul.ssig

Durch das A-Element definierte Anker und Verweise drfen nicht verschachtelt werden; ein
A-Element darf kein anderes A-Elemente enthalten.
Da die DTD das Element LINK als leer definiert, k=nnen LINK-Elemente auch nicht verschachtelt
werden.

< 186 > Links


Page size: 168,00 x 240,00 mm

12.2.3 Anker mit dem id-Attribut

Das id-Attribut kann verwendet werden, um einen Anker am Start-Tag eines beliebigen Ele-
ments (einschließlich des A-Elements) zu erstellen.

Die HTML 4.01- Spezifikation


Dieses Beispiel veranschaulicht die Verwendung des id-Attributs, um einen Anker innerhalb
eines H2-Elements positionieren. Auf den Anker wird durch das A-Element verwiesen.

Sie k^nnen mehr darUber in


<A href="#section2">Abschnitt zwei</A> lesen.
...weiter unten im Dokument
<H2 id="section2">Abschnitt zwei</H2>
...weiter unten im Dokument
<P>Bitte lesen Sie Details weiter oben in
<A href="#section2">Section Two</A>
nach.

Das folgende Beispiel benennt einen Zielanker im dem id-Attribut:

Ich bin gerade aus dem Urlaub zurUck! Hier ist ein
<A id="anchor-two">Foto meiner Famile am See.</A>.

Das id und das name-Attribut benutzen denselben Namensraum. Das bedeutet, sie k=nnen
nicht beide einen Anker mit demselben Namen im selben Dokument definieren. Es ist zul@ssig,
beide Attribute zu benutzen, um einen eindeutigen Bezeichner fr die folgenden Elemente
anzugeben: A, APPLET, FORM, FRAME, IFRAME, IMG, und MAP. Wenn beide Attribute bei einem Element
benutzt werden, mssen ihre Werte identisch sein.

Anmerkung der bersetzer: Der Sinnn dieser Einschr@nkung wird augenf@llig,


wenn man folgendes Beispiel ansieht:

<p>Absatz 1:
<br><a href="#ziel">Der Link zum Ziel</a></p>
<p id="ziel">Absatz 2:
<br>... Text ...</p>
<p><a name="ziel">Absatz 3</a>:
<br>...noch mehr Text ...</p>

Wo befindet sich der Zielanker des Links, in Absatz 2 oder in Absatz 3? Er ist nicht ein-
deutig bestimmbar; damit ist der obige Code ungltig.
Anders hier:

<p>Absatz 1:
<br><a href="#ziel">Der Link zum Ziel</a></p>
<p>Absatz 2:
<br>... Text ...</p>
<p><a name="ziel" id="ziel">Absatz 3</a>:
<br>...noch mehr Text ...</p>

Das Element A < 187 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

UNG LTIGES BEISPIEL:


Der folgende Auszug ist ungltiges HTML, da diese Attribute denselben Namen zweimal im sel-
ben Dokument deklarieren:
Die HTML 4.01- Spezifikation

<A href="#a1">...</A>
...
<H1 id="a1">
...Seiten und Seiten...
<A name="a1"></A>

Das folgende Beispiel veranschaulicht, dass id und name identisch sein mssen, wenn beide im
Start-Tag des Elements stehen:

<P><A name="a1" id="a1" href="#a1">...</A>

Seiner Spezifizierung in der HTML-DTD folgend kann das name-Attribut Zeichenreferenzen ent-
halten. Damit sind sowohl D&#xfc;rst als auch D&uuml;rst gltige Werte fr ein name-Attribut.
Im Unterschied dazu darf das id-Attribut keine Zeichenreferenzen enthalten.

id oder name benutzen? Autoren sollten die folgenden Punkte beachten, wenn sie sich zwischen
id und name fr einen Ankernamen entscheiden:

· Das id-Attribut kann als mehr, denn nur als ein Ankername fungieren (zum Beispiel als Style-
sheet-Selektor, als Bezeichner fr die Verarbeitung usw.).
·· Einige ,ltere Benutzerprogramme untersttzen mit Hilfe des id-Attributs erstellte Anker nicht.
Das name-Attribut erlaubt ein gr ßeres Spektrum an Ankernamen (mit Entities). n

12.2.4 Unerreichbare und nicht identifizierbare Ressourcen

Eine Referenz auf eine nicht verfgbare oder eine nicht identifizierbare Ressource ist ein Fehler.
Wenngleich Benutzerprogramme solch einen Fehler auf unterschiedliche Weise behandeln
k=nnen, empfehlen wir folgendes Verhalten:
· Wenn ein Benutzerprogramm eine verlinkte Ressource nicht lokalisieren kann, sollte es
den Benutzer darauf aufmerksam machen.
· Wenn ein Benutzerprogramm den Typ einer verlinkten Ressource nicht identifizieren kann,
sollte es dennoch versuchen, sie zu bearbeiten. Es sollte den Benutzer warnen und kann
ihm gestatten, einzugreifen und den Dokumenttyp zu identifizieren.

Anmerkung der bersetzer: Hier sind Beispiele von zur Zeit verwendeten
Browsern fr
· eine Browsermeldung nach dem Versuch, einen nicht erreichbaren Server bzw. eine
nicht identifizierbare Domain zu lokalisieren:

< 188 > Links


Page size: 168,00 x 240,00 mm

Die HTML 4.01- Spezifikation


· die Frage an den Benutzer, was mit einer Datei, fr deren Typ keine Behandlung
festgelegt ist (hier eine Word-Datei vom Typ application/msword), geschehen soll:

Anmerkung: Die Auswahlm=glichkeit „Sffnen“ fhrt bei der Word-Datei auf dem
hier verwendeten Linux-System lediglich zur n@chsten Frage, womit ge=ffnet werden
soll.

12.3 Dokumentbeziehungen: das LINK-Element


<!ELEMENT LINK - O EMPTY - - a media-independent link - ->
<!ATTLIST LINK
%attrs; -- %coreattrs, %i18n, %events - -
charset %Charset; #IMPLIED -- char encoding of linked resource - -
href %URI; #IMPLIED -- URI for linked resource - -
hreflang %LanguageCode; #IMPLIED -- language code - -
type %ContentType; #IMPLIED -- advisory content type - -
rel %LinkTypes; #IMPLIED -- forward link types - -
rev %LinkTypes; #IMPLIED -- reverse link types - -
media %MediaDesc; #IMPLIED -- for rendering on these media - -
>

Start-Tag: erforderlich, End-Tag: verboten

An anderer Stelle definierte Attribute


·· id, class (dokumentenweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Elementtitel)
style (inzeilige Formatierungsinformation )

· onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,


onkeydown, onkeyup (eingebettete Ereignisse )

· href, hreflang, type, rel, rev (Links und Anker)

Dokumentbeziehungen: das LINK-Element < 189 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

·· target (Ziel-Frame-Angabe)
media (Kopf-Style-Information)

· charset(Zeichenkodierung)

Dieses Element definiert einen Verweis. Anders als A kann es nur im HEAD-Abschnitt des Doku-
Die HTML 4.01- Spezifikation

ments stehen, kann jedoch mehrfach vorkommen. Obgleich LINK keinen Inhalt besitzt, vermit-
telt es Informationen ber die Beziehungen zweier Ressourcen, die von Benutzerprogrammen
auf vielf@ltige Weise wiedergegeben werden k=nnen (zum Beispiel als Toolbar, durch ein aus
Links bestehendes Drop-Down-Men).
Dieses Beispiel veranschaulicht das Auftreten mehrerer LINK-Definitionen im HEAD-Abschnitt
des Dokuments. Das aktuelle Dokument ist „Chapter2.html“. Das rel-Attribut gibt die Bezie-
hung des verlinkten Dokuments zum aktuellen Dokument an. Die Werte „Index“, „Next“, und
„Prev“ werden in Abschnitt 6.12, „Linktypen“ erkl@rt.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"


"http://www.w3.org/TR/html4/strict.dtd">
<HTML>
<HEAD>
<TITLE>Chapter 2</TITLE>
<LINK rel="Index" href="../index.html">
<LINK rel="Next" href="Chapter3.html">
<LINK rel="Prev" href="Chapter1.html">
</HEAD>
...Der Rest des Dokuments...

12.3.1 Vorw.rts- und R-ckw.rts-Links

Die rel- und rev-Attribute spielen entgegengesetzte Rollen – das rel-Attribut spezifiziert einen
Vorw@rts-Link und das rev-Attribut einen Rckw@rts-Link.
Betrachten Sie die beiden Dokumente A und B.

Dokument A: <LINK href="docB" rel="foo">

hat exakt die gleiche Bedeutung wie:

Dokument B: <LINK href="docA" rev="foo">

Beide Attribute k=nnen gleichzeitig angegeben werden.

12.3.2 Links und externe Stylesheets

Wenn das LINK-Element ein externes Stylesheet mit dem Dokument verbindet, spezifiziert das
type-Attribut die Stylesheet Sprache an und das media-Attribut das vorgesehene Ausgabemedi-
um. Benutzerprogramme k=nnen Zeit sparen, indem sie nur diejenigen Stylesheets aus dem
Netz laden, die fr das aktuelle Ger@t passend sind.
Medientypen werden in Abschnitt 14, „Stylesheets“ genauer behandelt.

< 190 > Links


Page size: 168,00 x 240,00 mm

12.3.3 Links und Suchmaschinen

Autoren k=nnen das LINK-Element verwenden, um vielf@ltige Informationen fr Suchmaschinen


bereitzustellen, darin enthalten:
·

Die HTML 4.01- Spezifikation


Verweise zu alternativen in anderen menschlichen Sprachen geschriebenen Versionen des
Dokuments
· Verweise zu alternativen fr andere Medien gestaltete Versionen, beispielsweise eine spe-
ziell fr den Druck eingerichtete Fassung
· Verweise zur Startseite einer Sammlung von Dokumenten
Das Beispiel unten veranschaulicht, wie Sprachangaben, Medientypen und Verweisarten kom-
biniert werden k=nnen, um die Behandlung des Dokuments durch Suchmaschinen zu verbes-
sern.
In dem folgenden Beispiel benutzen wir das hreflang-Attribut, um Suchmaschinen mitzuteilen,
wo die niederl@ndische, portugiesische und arabische Version eines Dokuments zu finden sind.
Beachten Sie die Verwendung des charset-Attributs fr das arabische Handbuch. Beachten Sie
auch die Verwendung des lang-Attributs, das darauf hinweist, dass der Wert des title-Attri-
buts im LINK-Element, welches das franz=siche Handbuch kennzeichnet, in Franz=sisch angege-
ben ist.

<HEAD>
<TITLE>Das Handbuch auf englisch</TITLE>
<LINK title="Das Handbuch auf niederl]ndisch"
type="text/html"
rel="alternate"
hreflang="nl"
href="http://someplace.com/manual/dutch.html">
<LINK title="Das Handbuch auf portugiesisch"
type="text/html"
rel="alternate"
hreflang="pt"
href="http://someplace.com/manual/portuguese.html">
<LINK title="Das Handbuch auf arabisch"
type="text/html"
rel="alternate"
charset="ISO-8859-6"
hreflang="ar"
href="http://someplace.com/manual/arabic.html">
<LINK lang="fr" title="La documentation en Fran&ccedil;ais"
type="text/html"
rel="alternate"
hreflang="fr"
href="http://someplace.com/manual/french.html">
</HEAD>

In dem folgenden Beispiel sagen wir Suchmaschinen, wo die druckbare Version des Handbuchs
zu finden ist.

<HEAD>
<TITLE>Handbuch</TITLE>
<LINK media="print" title="Das Handbuch in Postscript"
type="application/postscript"

Dokumentbeziehungen: das LINK-Element < 191 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

rel="alternate"
href="http://someplace.com/manual/postscript.ps">
</HEAD>

In dem folgenden Beispiel sagen wir Suchmaschinen, wo die Titelseite einer Sammlung von
Die HTML 4.01- Spezifikation

Dokumenten zu finden ist.

<HEAD>
<TITLE>Handbuch -- Seite 5</TITLE>
<LINK rel="Start" title="Die erste Seite des Handbuchs"
type="text/html"
href="http://someplace.com/manual/start.html">
</HEAD>

Weitere Informationen sind in den Anmerkungen in Anhang B unter „Suchmaschinen helfen,


die eigene Web-Site zu indexieren“ zu finden.

12.4 Pfadangaben: das BASE-Element


<!ELEMENT BASE - O EMPTY - - Basis-URI des Dokuments- ->
<!ATTLIST BASE
href %URI; #REQUIRED - - URI die als Basis-URI dient - -
>

Start-Tag: erforderlich, End-Tag: verboten

Attributdefinitionen

href = uri [CT]


Dieses Attribut gibt einen absoluten URI an, der als Basis-URI fr die Aufl=sung relativer
URIs dient.

An anderer Stelle definierte Attribute


· target (Zielframe-Angabe)

In HMTL sind Links und Referenzen zu externen Bildern, Anwendungen, formularverarbeiten-


den Programmen, Stylesheets und so weiter stets durch einen URI spezifiziert. Relative URIs
werden gem@ß einem Basis-URI aufgel=st, der aus den verschiedensten Quellen kommen kann.
Das Element BASE erlaubt es Autoren, den Basis-URI eines Dokuments explizit anzugeben.
Wenn vorhanden, muss das Element BASE im HEAD-Abschnitt eines HTML-Dokuments stehen,
vor jedem Element, das auf eine externe Quelle verweist. Die Pfadangabe, spezifiziert durch
das BASE-Element, betrifft nur URIs in dem Dokument, in dem das Element steht.
Zum Beispiel wrden die folgende BASE- und A-Deklaration:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"


"http://www.w3.org/TR/html4/strict.dtd">
<HTML>
<HEAD>
<TITLE>Unsere Produkte</TITLE>
<BASE href="http://www.aviary.com/products/intro.html">

< 192 > Links


Page size: 168,00 x 240,00 mm

</HEAD>
<BODY>
<P>Haben Sie unsere <A href="../cages/birds.gif">Vogelk]fige</A> gesehen?
</BODY>
</HTML>

Die HTML 4.01- Spezifikation


den relativen URI „../cages/birds.gif“ aufl=sen in:

http://www.aviary.com/cages/birds.gif

12.4.1 Relative URIs auflUsen

Benutzerprogramme mssen den Basis-URI fr die Aufl=sung relativer URIs gem@ß [RFC1808],
Abschnitt 3 ermitteln. Nachfolgend ist beschrieben, wie [RFC1808] speziell in HTML angewen-
det wird.
Benutzeragenten mssen den Basis-URI gem@ß folgender Rangfolge (von h=chster Priorit@t zu
niedrigster) ermitteln:
1. Der Basis-URI ist durch das BASE-Element gesetzt.
2. Der Basis-URI wird durch Meta-Daten angegeben, die w@hrend einer Protokoll-Interaktion
gefunden wurden, wie zum Beispiel einem HTTP-Header (siehe auch [RFC2616]).
3. Standardm@ßig ist der Basis-URI der des aktuellen Dokuments. Nicht alle HTML-Doku-
mente haben einen Basis-URI (zum Beispiel kann ein gltiges HTML-Dokument in einer
E-Mail vorkommen und nicht durch einen URI bezeichnet werden). Solche HTML-Doku-
mente werden als fehlerhaft angesehen, wenn sie relative URIs enthalten und sich auf einen
Standard-Basis-URI beziehen.
Zus@tzlich definieren OBJECT- und APPLET-Elemente Attribute, die Vorrang vor dem durch das
BASE-Element gesetzten Wert haben. Weitere Informationen ber speziell fr diese geltende
URI-Punkte finden Sie in den Definition der Elemente.

Anmerkung. Bei Versionen von HTTP, die einen Link-Header definieren, sollten Benutzerpro-
gramme diese Header genau wie LINK-Elemente im Dokument behandeln. HTTP 1.1, wie in
[RFC2616] definiert, enth,lt kein Link-Header-Feld (bezieht sich auf Abschnitt 19.6.3). n

13 Objekte, Bilder und Applets

13.1 Einf-hrung in Objekte, Bilder und Applets


Die Multimedia-Eigenschaften von HTML gestatten Autoren die Einbindung von Bildern, App-
lets (Programme, die automatisch heruntergeladen und auf dem Rechner des Benutzers aus-
gefhrt werden), Videoclips und anderen HTML-Dokumenten in ihre Seiten.
Um zum Beispiel eine PNG-Graphik in ein Dokument einzubetten, k=nnen Autoren schreiben:

Objekte, Bilder und Applets < 193 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

<BODY>
<P>Hier ist eine Großaufnahme des Grand Canyon:
<OBJECT data="canyon.png" type="image/png">
Dies ist eine <EM>Großaufnahme</EM> des Grand Canyon.
</OBJECT>
Die HTML 4.01- Spezifikation

</BODY>

Frhere Versionen von HTML gestatteten Autoren die Einbindung von Bildern (ber IMG) und
Applets (ber APPLET). Diese Elemente haben mehrere Einschr@nkungen:
· Sie l=sen das eher allgemeine Problem nicht, wie neue und zuknftige Medientypen ein-
zubinden sind.
· Das Element APPLET arbeitet nur mit Java-basierten Applets zusammen. Dieses Element
wird zu Gunsten des OBJECT-Elements missbilligt.
· Sie bringen Zug@nglichkeitsprobleme mit sich.
Um diese Probleme anzugehen, fhrt HTML 4 das Element OBJECT ein, das eine universelle
L=sung fr die allgemeine Objekteinbindung anbietet. Das OBJECT-Element erlaubt HTML-Auto-
ren, alle fr die Darstellung im Benutzerprogramm erforderlichen Informationen des Objekts
anzugeben: Quelltext, Anfangswerte und Laufzeitdaten. In dieser Spezifikation wird der Begriff
„Objekt“ in dem Sinn verwendet, dass er alle Dinge beschreibt, die jemand in einem HTML-Do-
kument unterbringen m=chte; andere allgemein verwendete Begriffe fr diese Dinge sind: App-
lets, Plug-Ins, Medien-Handler usw.
Das neue Element OBJECT bernimmt so einige Aufgaben, die von bestehenden Elementen aus-
gefhrt werden. Stellen Sie sich die folgenden Funktionalit@ten vor:

Art der Einbindung Spezielles Element Allgemeines Element


Bild IMG OBJECT
Applet APPLET(Missbilligt.) OBJECT
Ein weiteres HTML-Dokument IFRAME OBJECT

Die Tabelle zeigt, dass jede Art der Einbindung eine spezielle und eine allgemeine L=sung hat.
Das allgemeine Element OBJECT wird als L=sung fr die Implementierung zuknftiger Medien-
typen fungieren.
Zur Einbindung von Bildern k=nnen Autoren das Element OBJECT oder das Element IMG verwen-
den.
Zur Einbindung von Applets sollten Autoren das Element OBJECT verwenden, weil das APPLET-
Element missbilligt wird.
Zur Einbindung eines HTML-Dokuments in ein anderes, k=nnen Autoren entweder das neue
Element IFRAME oder das Element OBJECT verwenden. In beiden F@llen bleibt das eingebettete
Dokument unabh@ngig vom Hauptdokument. Visuelle Benutzerprogramme k=nnen das einge-
schlossene Dokument in einem separaten Fenster innerhalb des Hauptdokuments darstellen.
Bitte lesen Sie zum Vergleich zwischen OBJECT und IFRAME in Bezug auf die Dokumenteinbindung
die „Anmerkungen zu eingebetteten Dokumenten“ weiter unten.
Bilder und andere eingebundene Objekte k=nnen mit ihnen verbundene Hyperlinks haben,
beide durch den Standard-Link-Mechanismus, aber auch ber Imagemaps. Eine Imagemap gibt

< 194 > Objekte, Bilder und Applets


Page size: 168,00 x 240,00 mm

aktive geometrische Bereiche eines eingebetteten Objekts an und verbindet jeden Bereiche mit
einem Link. Bei ihrer Aktivierung k=nnen diese Links den Empfang eines Dokuments veranlas-
sen, ein Programm auf dem Server starten usw.
In den folgenden Abschnitten behandeln wir die verschiedenen Mechanismen, die Autoren fr

Die HTML 4.01- Spezifikation


die Multimedia-Einbindung und zum Erstellen von Imagemaps dafr zur Verfgung haben.

13.2 Eine Graphik einbinden: das Element IMG


<!- - To avoid problems with text-only UAs as well as
to make image content understandable and navigable
to users of non-visual UAs, you need to provide
a description with ALT, and avoid server-side image maps - ->
<!ELEMENT IMG - O EMPTY - - Embedded image - ->

<!ATTLIST IMG
%attrs; - - %coreattrs, %i18n, %events - -
src %URI; #REQUIRED - - URI of image to embed - -
alt %Text; #REQUIRED - - short description - -
longdesc %URI; #IMPLIED - - link to long description
(complements alt) - -
name CDATA #IMPLIED - - name of image for scripting - -
height %Length; #IMPLIED - - override height - -
width %Length; #IMPLIED - - override width - -
usemap %URI; #IMPLIED - - use client-side image map - -
ismap (ismap) #IMPLIED - - use server-side image map - -
>

Start-Tag: erforderlich, End-Tag: verboten

Attributdefinitionen

src = uri [CT]


Dieses Attribut gibt den Ort der Bildquelle an. Beispiele weithin erkannter Bildformate sind
GIF, JPEG und PNG.
longdesc = uri [CT]
Dieses Attribut gibt einen Link zu einer langen Beschreibung des Bilds an. Diese Beschrei-
bung sollte die kurze Beschreibung des Attributs alt erg@nzen. Besitzt das Bild eine ver-
knpfte Imagemap, dann sollte dieses Attribut Informationen ber den Inhalt der Imagemap
anbieten. Dies ist besonders wichtig fr Server-seitige Imagemaps. Weil ein IMG-Element im
Inhalt eines A-Elements stehen kann, muss sich der Mechanismus des des Benutzerpro-
gramms in der Benutzerschnittstelle fr den Zugriff auf die longdesc-Quelle des ersteren
von dem Mechanismus fr den Zugriff auf die href-Quelle des letzteren unterscheiden.
name = cdata [CI]
Dieses Attribut benennt das Element, so dass es von Stylesheets oder Skripten referenziert
werden kann. Anmerkung: Dieses Attribut wurde zur Rckw@rtskompatibilit@t auf-
genommen. Anwendungen sollten das id-Attribut verwenden, um das Element zu identifi-
zieren.

Eine Graphik einbinden: das Element IMG < 195 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
alt (alternativer Text)

·· lang (Sprachcode), dir (Leserichtung)


Die HTML 4.01- Spezifikation

title (Elementtitel)

·· style (inzeilige Formatierungsinformation)


onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,
onkeydown, onkeyup (eingebettete Ereignisse)

··ismap, usemap (client-seitige Imagemaps)


align, width, height, border, hspace, vspace (visuelle Darstellung von Objekten, Bildern und
Applets)
Das IMG-Element bettet ein Bild an der Stelle in das aktuelle Dokument ein, an der die Element-
definition zu finden ist. Das IMG-Element hat keinen Inhalt; es wird im Allgemeinen im Textfluss
(inline) durch das Bild ersetzt, das vom src-Attribut angegeben wird. Eine Ausnahme besteht
fr links oder rechts ausgerichtete Bilder, die aus dem Textfluss herausfließen.
In einem frheren Beispiel haben wir einen Verweis zu einem Familienfoto definiert. Hier fgen
wir das Foto direkt in das aktuelle Dokument ein:

<BODY>
<P>Ich komme gerade aus dem Urlaub nach Hause! Hier ist ein Foto meiner Familie am
See:
<IMG src="http://www.somecompany.com/People/Ian/vacation/family.png"
alt="Ein Foto meiner Familie am See.">
</BODY>

Diese Einbindung k=nnte auch mit dem OBJECT-Element wie folgt geschehen:

<BODY>
<P>Ich komme gerade aus dem Urlaub nach Hause! Hier ist ein Foto meiner Familie am
See:
<OBJECT data="http://www.somecompany.com/People/Ian/vacation/family.png"
type="image/png">
Ein Foto meiner Familie am See.
</OBJECT>
</BODY>

Das Attribut alt gibt alternativen Text an, der dargestellt wird, wenn das Bild nicht angezeigt
werden kann (mehr Informationen finden sie in Abschnitt „Wie alternativer Text angegeben
wird“ weiter unten). Benutzerprogramme mssen alternativen Text darstellen, wenn sie keine
Bilder untersttzen, bestimmte Bildtypen nicht untersttzen oder wenn sie so konfiguriert sind,
dass sie Bilder nicht anzeigen.
Das folgende Beispiel zeigt, wie das longdesc-Attribut verwendet werden kann, um auf eine aus-
fhrlichere Beschreibung zu verweisen:

<BODY>
<P>
<IMG src="sitemap.gif"
alt="HP Labs Site Map"
longdesc="sitemap.html">
</BODY>

< 196 > Objekte, Bilder und Applets


Page size: 168,00 x 240,00 mm

Anmerkung der bersetzer: Eine M=glichkeit, auf solch eine Beschreibung zu


verweisen, zeigt das folgende Bild (hier das Eigenschaftsfenster eines Bildes in Mozilla).

Die HTML 4.01- Spezifikation


Das alt-Attribut liefert eine kurze Beschreibung des Bildes. Diese sollte ausreichend sein, um
Benutzern die Entscheidung zu erm=glichen, ob sie dem von longdesc-Attribut angegebenen
Link auf die l@ngere Beschreibung folgen m=chten, in diesem Fall sitemap.html.
Bitte lesen Sie in Abschnitt „Visuelle Darstellung von Objekten, Bildern und Applets“ die Infor-
mationen ber Bildgr=ße, Ausrichtung und Rahmen.

13.3 Allgemeine Objekte einbetten: das Element OBJECT


<!ELEMENT OBJECT - - (PARAM | %flow;)*
- - generic embedded object - ->
<!ATTLIST OBJECT
%attrs; -- %coreattrs, %i18n, %events - -
declare (declare) #IMPLIED -- declare but don't instantiate flag - -
classid %URI; #IMPLIED -- identifies an implementation - -
codebase %URI; #IMPLIED -- base URI for classid, data, archive- -
data %URI; #IMPLIED -- reference to object's data - -
type %ContentType; #IMPLIED -- content type for data - -
codetype %ContentType; #IMPLIED -- content type for code - -
archive CDATA #IMPLIED -- space-separated list of URIs - -
standby %Text; #IMPLIED -- message to show while loading - -
height %Length; #IMPLIED -- override height - -
width %Length; #IMPLIED -- override width - -
usemap %URI; #IMPLIED -- use client-side image map - -
name CDATA #IMPLIED -- submit as part of form - -
tabindex NUMBER #IMPLIED -- position in tabbing order - -
>

Start-Tag: erforderlich, End-Tag: erforderlich

Allgemeine Objekte einbetten: das Element OBJECT < 197 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Attributdefinitionen

classid = uri [CT]


Dieses Attribut kann verwendet werden, um den Ort einer Objektimplementierung ber
Die HTML 4.01- Spezifikation

einen URI anzugeben. Es kann abh@ngig vom Typ des beteiligten Objekts zusammen mit
oder als Alternative zum data-Attribut verwendet werden.
codebase = uri [CT]
Dieses Attribut gibt den Basispfad zur Aufl=sung relativer URIs an, die durch die Attribute
classid, data und archive angegeben sind. Ist das Attribut nicht angegeben, ist der Basis-URI
des aktuellen Dokuments der voreingestellte Wert.
codetype = content-type [CI]
Dieses Attribut gibt den Inhaltstyp der erwarteten Daten an, wenn ein Objekt herunter-
geladen wird, das durch das Attribut classid angegeben ist. Dieses Attribut ist optional,
jedoch empfohlen, wenn classid angegeben ist, weil es dem Benutzerprogramm gestattet,
das Laden von Informationen fr nicht untersttzte Inhaltstypen zu vermeiden. Ist es nicht
angegeben, ist seine Voreinstellung der Wert des type-Attributs.
data = uri [CT]
Dieses Attribut kann dazu verwendet werden, den Ort der Objektdaten anzugeben, zum
Beispiel Bilddaten fr Objekte, die Bilder definieren oder allgemeiner, eine serialisierte
Form eines Objekts, die verwendet werden kann, um es wiederherzustellen. Ist es als rela-
tiver URI gegeben, sollte es relativ zum codebase-Attribut aufgel=st werden.
type = content-type [CI]
Dieses Attribut gibt den Inhaltstyp der Daten an, die vom data-Attribut angegeben werden.
Dieses Attribut ist optional, jedoch empfohlen, wenn data angegeben ist, weil es dem
Benutzerprogramm gestattet, das Laden von Informationen fr nicht untersttzte Inhalts-
typen zu vermeiden. Unterscheidet sich der Wert dieses Attributs vom HTTP-Inhaltstyp,
der vom Server zurckgegeben wird, wenn das Objekt empfangen wird, ist der HTTP-
Inhaltstyp vorrangig.
archive = uri-list [CT]
Dieses Attribut kann dazu verwendet werden, eine durch Kommata getrennte Liste mit
URIs der Archive anzugeben, welche die relevanten Quellen fr das Objekt enthalten.
Darin eingeschlossen k=nnen die Quellen sein, die durch die Attribute classid und data
bezeichnet sind. Archive vorab herunterzuladen, fhrt im Allgemeinen zu einer verringerten
Ladezeit fr Objekte. Archive, die als relativer URI angegeben sind, sollten relativ zum
Attribut codebase aufgel=st werden.
declare [CI]
Sofern angegeben, wird die aktuelle OBJECT-Definition durch dieses Boolesche Attribut zu
einer Deklaration. Die Instanz des Objekts muss von einer folgenden OBJECT-Definition, die
sich auf diese Deklaration bezieht, erzeugt werden.
standby = text [CS]
Dieses Attribut stellt eine Nachricht zur Verfgung, die ein Benutzerprogramm darstellen
kann, w@hrend die Implementierung und die Daten des Objekts geladen werden.

An anderer Stelle defnierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

· title (Elementtitel)

< 198 > Objekte, Bilder und Applets


Page size: 168,00 x 240,00 mm

·· style (inzeilige Formatierungsinformation)


onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,
onkeydown, onkeyup (eingebettete Ereignisse)

·· tabindex (Tabulatornavigation)

Die HTML 4.01- Spezifikation


usemap (client-seitige Imagemaps)

·· name (Formularbertragung)
align, width, height, border, hspace, vspace (visuelle Darstellung von Objekten, Bildern und
Applets)
Die meisten Benutzerprogramme haben einen eingebauten Mechanismus zur Darstellung von
allgemeinen Datentypen, dazu geh=ren Text, GIF-Bilder, Farben, Schriftarten und eine Handvoll
graphischer Elemente. Um Datentypen darzustellen, die sie nicht nativ untersttzen, verwen-
den Benutzerprogramme im Allgemeinen externe Anwendungen. Das Element OBJECT gestattet
dem Autor die Kontrolle darber, ob Daten extern dargestellt werden sollen oder durch ein
vom Autor angegebenes Programm, das Daten innerhalb eines Benutzerprogramms anzeigt.
Im allgemeinsten Fall hat ein Autor drei Infromationstypen anzugeben:
· Die Implementierung des eingebundenen Objekts. Ist das eingebundene Objekt zum Bei-
spiel ein Uhr-Applet, muss der Autor den Ort des ausfhrbaren Codes des Applets ange-
ben.
· Die Daten, die dargestellt werden sollen. Ist das eingebundene Objekt zum Beispiel ein Pro-
gramm, das Schriftdaten darstellt, muss der Autor den Ort dieser Daten angeben.
· Zus@tzliche Werte, die vom Objekt zur Laufzeit ben=tigt werden. Zum Beispiel k=nnten
einige Applets Anfangswerte fr Parameter fordern.
Das Element OBJECT gestattet zwar Autoren die Angabe aller drei Datentypen, jedoch mssen
Autoren nicht unbedingt alle drei Angaben zugleich machen. Zum Beispiel ben=tigen einige
Objekte vielleicht keine Daten (z. B. ein in sich geschlossenes Applet, das eine kurze Animation
zeigt). Andere ben=tigen eventuell keine Laufzeitinitialisierung. Wieder andere ben=tigen m=g-
licherweise keine zus@tzlichen Implementierungsinformationen, z. B. kann das das Benutzerpro-
gramm selbst schon wissen, wie dieser Datentyp darzustellen ist (z. B. GIF-Bilder).
Autoren geben eine Objektimplementierung und den Ort der darzustellenden Daten ber das
OBJECT-Element an. Um Laufzeitwerte anzugeben, verwenden Autoren jedoch das Element
PARAM, das im Abschnitt „Objektinitialisierung“ er=rtert wird.
Das OBJECT-Element kann auch im Inhalt des Elements HEAD stehen. Weil Benutzerprogramme
im Allgemeinen Elemente im HEAD nicht darstellen, sollten Autoren sicherstellen, dass kein
OBJECT-Element im HEAD Inhalt angibt, der dargestellt werden kann. Bitte lesen Sie unter „Daten
teilen mit anderen Frames“ im Abschnitt 16.2.1 nach, dort findet sich ein Beispiel fr die Einbin-
dung des OBJECT-Elements in das HEAD-Element.
Bitte lesen Sie den Abschnitt 17.2, „Steuerelemente“, dort finden Sie Informationen ber
OBJECT-Elemente in Formularen.
Dieses Dokument spezifiziert nicht das das Verhalten von OBJECT-Elementen, die sowohl das
Attribut classid zur Identifizierung einer Implementierung als auch das Attribut data zur
Angabe von Daten fr diese Implementierung verwenden. Um fr Portabilit@t zu sorgen, sollten
Autoren das Element PARAM verwenden, um Implementierungen mitzuteilen, woher sie zus@tzli-
che Daten beziehen k=nnen.

Allgemeine Objekte einbetten: das Element OBJECT < 199 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

13.3.1 Regeln zur Darstellung von Objekten

Benutzerprogramme mssen ein OBJECT-Element entsprechend der folgenden Rangfolge inter-


pretieren:
Die HTML 4.01- Spezifikation

1. Das Benutzerprogramm muss zuerst versuchen, das Objekt darzustellen. Es sollte nicht
den Inhalt des Elements darstellen, aber es muss ihn untersuchen, falls das Element irgend-
welche direkte Kinder hat, die PARAM-Elemente (siehe Objektinitialisierung) oder MAP-Ele-
mente sind (siehe Client-seitige Imagemaps).
2. Ist ein Benutzerprogramm aus irgendeinem Grund nicht in der Lage, das Objekt darzustel-
len (so konfiguriert, zu wenig Quellen, falsche Architektur usw.), dann muss es versuchen,
dessen Inhalt darzustellen.
Autoren sollten keinen Inhalt in OBJECT-Elemente einschließen, die im HEAD-Element stehen.
Im folgenden Beispiel fgen wir das Applet einer analogen Uhr in ein Dokument ber das
OBJECT-Element ein. Das in der Sprache Python geschriebene Applet ben=tigt keine weiteren
Daten oder Laufzeitwerte. Das Attribut classid gibt den Ort des Applets an:

<P><OBJECT classid="http://www.miamachina.it/analoguhr.py">
</OBJECT>

Beachten Sie, dass die Uhr dargestellt wird, sobald das Benutzerprogramm diese OBJECT-Dekla-
ration interpretiert. Es ist m=glich, die Darstellung eines Objekts zu verz=gern, indem man das
Objekt zuerst deklariert (weiter unten beschrieben).
Autoren sollten diese Deklaration durch Angabe eines alternativen Textes im Inhalt des
OBJECT-Elements vervollst@ndigen, falls das Benutzerprogramm die Uhr nicht anzeigen kann.

<P><OBJECT classid="http://www.miamachina.it/analoguhr.py">
Eine animierte Uhr.
</OBJECT>

Eine signifikante Konsequenz des Aufbaus des OBJECT-Elements ist, dass er einen Mechanismus
bietet, alternative Objektdarstellungen anzugeben; jede eingebettete OBJECT-Deklaration kann
alternative Inhaltstypen deklarieren. Kann ein Benutzerprogramm das @ußere OBJECT nicht dar-
stellen, versucht es, den Inhalt darzustellen, der wiederum ein OBJECT-Element sein kann, usw.
Im folgenden Beispiel betten wir meherere OBJECT-Deklarationen ein, um zu zeigen, wie die
alternative Darstellung funktioniert. Ein Benutzerprogramm wird versuchen, das erste OBJECT-
Element darzustellen, das es kann, und zwar in der folgenden Reihenfolge: (1) Ein in der Spra-
che Python geschriebenes Erde-Applet, (2) eine MPEG-Animation der Erde, (3) ein GIF-Bild
der Erde, (4) alternativen Text.

<P> <!- - Zuerst versuche das Python-Applet - ->


<OBJECT title="Die Erde vom All aus betrachtet"
classid="http://www.observer.mars/DieErde.py">
<!- - Sonst, versuche das MPEG-Video - ->
<OBJECT data="TheEarth.mpeg" type="application/mpeg">
<!- - Sonst, versuche das GIF-Bild - ->
<OBJECT data="TheEarth.gif" type="image/gif">
<!- - Sonst stelle den Text dar - ->
Die <STRONG>Erde</STRONG> aus dem All betrachtet.

< 200 > Objekte, Bilder und Applets


Page size: 168,00 x 240,00 mm

</OBJECT>
</OBJECT>
</OBJECT>

Die @ußere Deklaration gibt ein Applet an, das keine Daten oder Anfangswerte erfordert. Die

Die HTML 4.01- Spezifikation


zweite Deklaration gibt eine MPEG-Animation an, und weil sie keinen Ort fr eine Implemen-
tierung definiert, die MPEG verarbeitet, liegt die Vorgehensweise in Bezug auf die Animation
beim Benutzerprogramm. Wir geben auch das type-Attribut an, so dass ein Benutzerprogramm
sich nicht bemhen wird, die Datei „TheEarth.mpeg“ aus dem Netz zu laden, wenn ihm bekannt
ist, dass es MPEG nicht darstellen kann. Die dritte Deklaration gibt den Ort einer GIF-Datei an
und liefert einen alternativen Text, falls alle anderen Mechanismen versagen.
Interne gegen externe Daten. Darzustellende Daten k nnen auf zwei Arten zur Verfgung
gestellt werden: intern und aus externen Quellen. W,hrend die erstgenannte Methode im Allgemeinen
zu einer schnelleren Darstellung fhrt, ist sie nicht praktisch, wenn gr ßere Datenmengen dargestellt
werden.
Hier folgt ein Beispiel, das zeigt, wie ein OBJECT intern mit Daten gefttert werden kann:

<P>
<OBJECT id="uhr1"
classid="clsid:663C8FEF-1EF9-11CF-A3DB-080036F12502"
data="data:application/x-oleobject;base64, ...base64-Daten...">
Eine Uhr.
</OBJECT> n

Bitte lesen sie den Abschnitt „Visuelle Darstellung von Objekten, Bildern und Applets“. Hier
finden Sie Informationen zu Objektgr=ße, -ausrichtung und Rahmen.

13.3.2 Objektinitialisierung: das Element PARAM

<!ELEMENT PARAM - O EMPTY - - named property value - ->

<!ATTLIST PARAM
id ID #IMPLIED -- document-wide unique id - -
name CDATA #REQUIRED -- property name - -
value CDATA #IMPLIED -- property value - -
valuetype (DATA|REF|OBJECT) DATA -- How to interpret value - -
type %ContentType; #IMPLIED -- content type for value
when valuetype=ref - -
>

Start-Tag: erforderlich, End-Tag: verboten

Attributdefinitionen

name = cdata
Dieses Attribut definiert den Namen eines Laufzeitparameters, von dem angenommen wird,
dass das eingebettete Objekt ihn kennt. Ob der Eigenschaftsname Unterschiede zwischen
Groß- und Kleinschreibung macht, ist abh@ngig von der jeweiligen Objekt-Implementierung.

Allgemeine Objekte einbetten: das Element OBJECT < 201 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

value = cdata
Dieses Attribut gibt den Wert eines Laufzeitparameters an, der von name spezifiziert wird.
Eigenschaftswerte haben keine Bedeutung fr HTML; ihre Bedeutung wird durch das
betreffende Objekt festgelegt.
Die HTML 4.01- Spezifikation

valuetype = data|ref|object [CI]


Dieses Attribut gibt den Typ des value-Attributs an. Folgende Werte sind m=glich:
· data: Dies ist die Voreinstellung fr das Attribut. Das heißt, der durch value angege-
bene Wert wird als Zeichenkette betrachtet und an die Implementierung des Objekts
weitergegeben.
· ref: Der von value angegebene Wert ist ein URI, der eine Quelle angibt, in der Laufzeit-
werte gespeichert sind. Dies erlaubt Hilfsprogrammen die Identifizierung von URIs, die
als Parameter angegeben werden. Der URI muss zu dem Objekt weitergeleitet werden,
wie er ist (as is), z. B. nicht aufgel=st.
· object: Der von value angegebene Wert ist ein Bezeichner, der sich auf eine OBJECT-
Deklaration im gleichen Dokument bezieht. Der Bezeichner muss der Wert des id-
Attributs sein, das fr der deklarierte OBJECT-Element gesetzt ist.
type = content-type [CI]
Dieses Attribut gibt den Inhaltstyp der Quelle, die durch das value-Attribut bestimmt ist,
nur in dem Fall an, wenn fr valuetype der Wert ref angegeben ist. Dieses Attribut gibt so
den Typ der Werte fr das Benutzerprogramm an, die unter dem URI gefunden werden,
der von value angegeben ist.

An anderer Stelle definierte Attribute


· id, class (dokumentweite Identifikatoren)

PARAM-Elemente geben eine Wertemenge an, die von einem Objekt zur Laufzeit ben=tigt wer-
den kann. Eine beliebige Anzahl von PARAM-Elementen kann im Inhalt der Elemente OBJECT oder
APPLET in jeder erdenklichen Reihenfolge erscheinen, jedoch mssen sie zu Beginn des Inhalts
der einschließenden Elemente OBJECT oder APPLET stehen.
Es wird angenommen, dass die Syntax der Namen und Werte von der Implementierung des
Objekts verstanden wird. Dieses Dokument gibt weder an, wie Benutzerprogramme die
Name/Wert-Paare empfangen sollen, noch wie sie doppelt erscheinende Parameternamen
interpretieren sollen.
Kehren wir zum Uhr-Beispiel zurck, um die Verwendung des PARAM-Elements zu verdeutlichen:
Nehmen Sie an, dass ein Applet in der Lage ist, zwei Laufzeitparameter zu verarbeiten, die des-
sen Anfangsh=he und -breite definieren. Wir k=nnen die Anfangsabmessung mit zwei PARAM-
Elementen auf 40x40 Pixel festlegen.

<P><OBJECT classid="http://www.miamachina.it/analoguhr.py">
<PARAM name="height" value="40" valuetype="data">
<PARAM name="width" value="40" valuetype="data">
Dieses Benutzerprogramm kann keine Python-Anwendungen darstellen.
</OBJECT>

Im folgenden Beispiel werden Laufzeitdaten fr den Objektparameter Init_values als externe
Quelle (eine GIF-Datei) angegeben. Der Wert des Attributs valuetype wird folglich auf „ref“
gesetzt, und value ist ein URI, der die Quelle angibt.

< 202 > Objekte, Bilder und Applets


Page size: 168,00 x 240,00 mm

<P><OBJECT classid="http://www.gifstuff.com/gifappli"
standby="Elvis wird geladen ...">
<PARAM name="Init_values"
value="./images/elvis.gif">
valuetype="ref">

Die HTML 4.01- Spezifikation


</OBJECT>

Beachten Sie, dass wir das standby-Attribut so angegeben haben, dass ein Benutzerprogramm
eine Nachricht einblenden kann, solange der Darstellungsmechanismus geladen wird.
Wird ein OBJECT-Element dargestellt, mssen Benutzerprogramme den Inhalt nur nach PARAM-
Elementen durchsuchen, die direkte Kinder sind und das OBJECT damit „fttern“.
Daraus abgeleitet gilt fr das folgende Beispiel, dass „param1“ fr „obj1“ (und nicht fr „obj2“)
gilt, wenn „obj1“ dargestellt wird. Wird „obj1“ nicht dargestellt, jedoch „obj2“, dann wird „pa-
ram1“ ignoriert und „param2“ gilt fr „obj2“. Wird keines der beiden OBJECT-Elemente dar-
gestellt, gilt auch keines der beiden PARAM-Elemente.

<P>
<OBJECT id="obj1">
<PARAM name="param1">
<OBJECT id="obj2">
<PARAM name="param2">
</OBJECT>
</OBJECT>

13.3.3 Globale Namensschemata f-r Objekte

Der Ort der Implementierung eines Objekts ist durch einen URI gegeben. Wie wir in Abschnitt
2.1.1, „Einfhrung zu URIs“ er=rtert haben, gibt das erste Segment eines absoluten URIs das
Namensschema an, das verwendet wird, um die Daten zu bertragen, die vom URI bestimmt
sind. Fr HTML-Dokumente ist das Schema h@ufig „http“. Einige Applets k=nnen andere
Namensschemata einsetzen. Wenn zum Beispiel ein Java-Applet angegeben wird, k=nnen Auto-
ren URIs verwenden, die mit „java“ beginnen oder fr ActiveX-Applets k=nnen Autoren das
„clsid“ verwenden.
Im folgenden Beispiel fgen wir ein Java-Applet in ein HTML-Dokument ein.

<P><OBJECT classid="java:program.start">
</OBJECT>

Durch Angabe des codetype-Attributs kann ein Benutzerprogramm, abh@ngig von seiner F@hig-
keit Java zu verarbeiten, entscheiden, ob es die Java-Anwendung empfangen will.

<OBJECT codetype="application/java-archive"
classid="java:program.start">
</OBJECT>

Einige Darstellungsschemata erfordern zus@tzliche Informationen, um ihre Implementierung zu


identifizieren. Ihnen muss mitgeteilt werden, wo sie diese Informationen finden. Autoren k=n-
nen Pfadinformationen zu der Implementierung des Objekts ber das Attribut codebase ange-
ben.

Allgemeine Objekte einbetten: das Element OBJECT < 203 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

<OBJECT codetype="application/java-archive"
classid="java:program.start">
codebase="http://foooo.bar.com/java/myimplementation/"
</OBJECT>
Die HTML 4.01- Spezifikation

Das folgende Beispiel gibt ber einen URI, der mit dem Namensschema „clsid“ beginnt, ein
ActiveX-Objekt an (mit dem classid-Attribut). Das Attribut data lokalisiert die Daten, die dar-
gestellt werden sollen (eine andere Uhr).

<P><OBJECT classid="clsid:663C8FEF-1EF9-11CF-A3DB-080036F12502"
data="http://www.acme.com/ole/clock.stm">
Diese Anwendung wird nicht unterstUtzt.
</OBJECT>

13.3.4 Objektdeklarationen und -instanzen

Die vorausgehenden Beispiele haben nur isolierte Objektdefinitionen gezeigt. Wenn ein Doku-
ment mehr als eine Instanz des gleichen Objekts enthalten soll, dann kann man die Deklaration
eines Objekts von seinen Instanzen trennen. Dies zu tun, bringt mehrere Vorteile:
· Daten k=nnen vom Benutzerprogramm einmal ber das Netzwerk empfangen werden
(w@hrend der Deklaration) und fr jede Instanz wieder verwendet werden.
· Es ist m=glich, von einem Objekt an einem anderen Ort als der Objektdeklaration eine
Instanz zu erzeugen, zum Beispiel von einem Verweis aus.
· Es ist m=glich, Objekte als Laufzeitdaten fr andere Objekte anzugeben.
Um ein Objekt zu deklarieren, ohne dass es ausgefhrt wird, wenn das Benutzerprogramm es
ausliest, setzt man das Boolesche Attribut declare im OBJECT-Element. Zur gleichen Zeit mssen
Autoren diese Deklaration dadurch kennzeichnen, dass sie den Wert des id-Attributs im
OBJECT-Element auf einen eindeutigen Wert setzen. Sp@ter werden sich Instanzen des Objekts
auf diesen Bezeichner beziehen.
Ein deklariertes OBJECT muss im Dokument vor der ersten Instanz dieses Objektes (OBJECT) ste-
hen.
Fr ein mit dem declare-Attribut definiertes Objekt wird jedesmal eine Instanz erzeugt, wenn
ein Element, das sich auf das Objekt bezieht, fordert, dass es dargestellt wird (z. B. ein Verweis
bezieht sich auf dieses Objekt und wird aktiviert oder ein Objekt bezieht sich auf dieses Objekt
und wird aktiviert usw.).
Im folgenden Beispiel deklarieren wir ein OBJECT und erzeugen eine Instanz des Objekts, indem
wir uns ber einen Verweis darauf beziehen. So kann das Objekt zum Beispiel durch Anklicken
eines abgesetzten Texts aktiviert werden.

<P><OBJECT declare
id="erd.deklaration"
data="DieErde.mpeg"
type="application/mpeg">
Die <STRONG>Erde</STRONG> aus dem All betrachtet.
</OBJECT>
...sp3ter im Dokument...
<P>Eine tolle <A href="#erd.deklaration"> Animation der Erde!</A>

< 204 > Objekte, Bilder und Applets


Page size: 168,00 x 240,00 mm

Anmerkung der bersetzer: Die Errata erg@nzen hierzu: Eine weitere M=glich-
keit, von einem in dieser Weise deklarierten Objekt eine Instanz zu erzeugen, ist Fol-
gendes:

Die HTML 4.01- Spezifikation


<object data="#erd.deklaration"></object>

Das folgende Beispiel zeigt, wie Laufzeitwerte angegeben werden, die wiederum andere
Objekte sind. In diesem Beispiel schicken wir einen Text (in der Tat ein Gedicht) an einen
hypothetischen Mechanismus zur Ansicht von Gedichten. Das Objekt erkennt einen Laufzeit-
parameter namens „font“ (sagen wir, um das Gedicht in einer bestimmten Schriftart darzustel-
len). Der Wert fr diesen Parameter ist seinerseits ein Objekt, welches das Schriftart-Objekt
einfgt (aber nicht darstellt). Die Beziehung zwischen dem Schriftart-Objekt und dem Gedicht-
betrachter-Objekt wird (1) durch Angabe der id„tribune“ in der Deklaration des Schriftart-
Objekts und (2) durch den Bezug darauf ber das PARAM-Element des Gedichtbetrachter-
Objekts (mit valuetype und value) hergestellt.

<P><OBJECT declare
id="tribune"
type="application/x-webfont"
data="tribune.gif">
</OBJECT>
...betrachte das Gedicht in KublaKhan.txt hier...
<P><OBJECT classid="http://foo.bar.com/poem_viewer"
data="KublaKhan.txt">
<PARAM name="font" valuetype="object" value="#tribune">
<P>Ihnen fehlt ein wirklich cooler Gedichtbetrachter ...
</OBJECT>

Benutzerprogramme, die das Attribut declare nicht verstehen, mssen den Inhalt der OBJECT-
Deklaration darstellen.

13.4 Einbinden eines Applets: das Element APPLET wird


zu Gunsten des Elements OBJECT missbilligt (mit all
seinen Attributen).
In der Transitional DTD finden Sie die formale Definition.

Attributdefinitionen

codebase = uri [CT]


Dieses Attribut gibt den Base-URI eines Applets an. Ist dieses Attribut nicht spezifiziert, ist
die Voreinstellung gleich dem Base-URI des aktuellen Dokuments. Werte fr dieses Attri-
but k=nnen sich nur auf Unterverzeichnisse des Verzeichnisses beziehen, das dieses aktuelle
Dokument enth@lt.

Einbinden eines Applets: das Element APPLET < 205 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Anmerkung: Obwohl die Beschr,nkung auf Unterverzeichnisse eine Abweichung von der allgemei-
nen Praxis und der HTML 3.2-Spezifikation darstellt, hat die HTML Working Group entschieden, die
Beschr,nkung in dieser Version der Spezifikation aus Sicherheitsgrnden zu belassen. n
code = cdata [CS]
Die HTML 4.01- Spezifikation

Dieses Attribut gibt entweder den Namen der Klassendatei an, die alle Applet-Unterklas-
sen des Applets enth@lt, oder den Pfad, um diese Klasse zu empfangen, eingeschlossen die
Klassendatei selbst. Es wird in unter Bercksichtigung von „codebase“ des Applets auf-
gel=st. Entweder muss code oder object vorhanden sein.
name = cdata [CS]
Dieses Attribut gibt einen Namen fr die Instanz des Applets an. Damit wird m=glich, dass
sich Applets im gleichen Dokument gegenseitig finden (und miteinander kommunizieren).
archive = uri-list [CT]
Dieses Attribut gibt eine durch Kommata getrennte Liste mit URIs fr Archive, die Klassen
und andere Ressourcen enthalten, die „vorgeladen“ werden. Die Klassen werden mit Hilfe
einer Instanz eines Applet-Klassenladers (AppletClassLoader) mit der gegebenen codebase
geladen. Relative URIs fr Archive werden in Bezug auf das codebase-Attribut des Applets
aufgel=st. Quellen vorab zu laden, kann die Performance eines Applets signifikant erh=hen.
object = cdata [CS]
Dieses Attribut gibt eine Ressource an, die in serialisierter Form den Zustand eines Applets ent-
h@lt. Es wird relativ zur Codebase des Applets interpretiert. Die serialisierten Daten enthalten
den Namen der Klasse des Applets, aber nicht deren Implementierung. Der Klassenname dient
dazu, die Implementierung aus einer Class-Datei oder einem Archiv zu bekommen.
Wenn das Applet „deserialisiert“ wird, wird die start()-Methode, aber nicht die init()-Me-
thode aufgerufen. Attributwerte, die zum Zeitpunkt gltig waren, als das Objekt serialisiert wur-
de, werden nicht wieder hergestellt. Jegliche Attribute, die an diese APPLET-Instanz bergeben
werden, werden fr das Applet zur Verfgung stehen. Autoren sollten dieses Feature mit gro-
ßer Vorsicht einsetzen. Ein Applet sollte vor der Serialisierung angehalten werden.
Entweder code oder object mssen vorhanden sein. Falls sowohl code als auch object ange-
geben sind, ist es ein Fehler, wenn sie verschiedene Klassennamen nennen.
width = length [CI]
Dieses Attribut gibt die Anfangsbreite des Anzeigebereichs eines Applets an (nicht davon
betroffen sind die Fenster und Dialogfelder, die das Applet erzeugt).
height = length [CI]
Dieses Attribut gibt die Anfangsh=he des Anzeigebereichs eines Applets an (nicht davon
betroffen sind die Fenster und Dialogfelder, die das Applet erzeugt).
An anderer Stelle definierte Attribute
·· id, class (dokumentweite Identifikatoren)
title (Elementtitel)

·· style (inzeilige Formatierungsinformation)


alt (alternativer Text)

· align, hspace, vspace (visuelle Darstellung von Objekten, Bildern und Applets)

Dieses von allen Java-f@higen Browsern untersttzte Element, gestattet es Autoren, ein Java-App-
let in ein HTML-Dokument einzubetten. Es wird zu Gunsten des Elements OBJECTmissbilligt.
Der Inhalt des APPLET-Elements dient als alternative Information fr Benutzerprogramme, die
dieses Element nicht untersttzen oder so konfiguriert sind, dass sie Applets nicht zu unterstt-
zen. Andernfalls mssen Benutzerprogramme den Inhalt ignorieren.

< 206 > Objekte, Bilder und Applets


Page size: 168,00 x 240,00 mm

MISSBILLIGTES BEISPIEL:
Im folgenden Beispiel fgt das APPLET-Element ein Java-Applet in das Dokument ein. Weil kein
codebase-Attribut angegeben ist, wird angenommen, dass sich dieses Applet im gleichen Ver-
zeichnis wie das aktuelle Dokument befindet.

Die HTML 4.01- Spezifikation


<APPLET code="Bubbles.class" width="500" height="500">
Ein Java-Applet, das animierte Seifenblasen malt.
</APPLET>

Dieses Beispiel kann wie folgt mit einem OBJECT-Element erzeugt werden:

<P><OBJECT codetype="application/java"
classid="java:Bubbles.class"
width="500" height="500">
Ein Java-Applet, das animierte Seifenblasen malt.
</OBJECT>

Anfangswerte k=nnen an dem Applet ber das PARAM-Element bereitgestellt werden.

MISSBILLIGTES BEISPIEL:
Das folgende Beispiel eines Java-Applets:

<APPLET code="AudioItem" width="15" height="15">


<PARAM name="snd" value="Hello.au|Welcome.au">
Ein Java-Applet, das eine Willkommensmusik spielt.
</APPLET>

kann mit Hilfe eines OBJECT-Elements wie folgt erzeugt werden:

<OBJECT codetype="application/java"
classid="AudioItem"
width="15" height="15">
<PARAM name="snd" value="Hello.au|Welcome.au">
Ein Java-Applet, das eine Willkommensmusik spielt.
</OBJECT>

13.5 Anmerkungen zu eingebetteten Dokumenten


Anstatt nur auf ein Dokument zu verweisen, m=chte ein Autor dieses vielleicht manchmal
direkt in das prim@re Dokument einbetten. Autoren k=nnen entweder das Element IFRAME oder
das Element OBJECT fr diesen Zweck verwenden, jedoch unterscheiden sich die Elemente in
einigen Bereichen. Die beiden Elemente haben nicht nur unterschiedliche Inhaltsmodelle, das
IFRAME-Element kann auch ein Ziel-Frame sein (im Abschnitt 16.3, „Informationen fr Ziel-
Frames angeben“ finden Sie Details) und kann vom Benutzerprogramm als Fokus fr den
Druck, das Anschauen von HTML-Quellen usw. ausgew@hlt werden. Benutzerprogramme k=n-
nen ausgew@hlte Frame-Elemente auf eine Weise darstellen, die sie von den nicht ausgew@hlten
Frames unterscheidet (z. B. durch einen Rahmens um den ausgew@hlten Frame herum).

Anmerkungen zu eingebetteten Dokumenten < 207 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Ein eingebettetes Dokument ist vollkommen unabh@ngig vom Dokument, in das es eingebettet
ist. Zum Beispiel werden relative URIs im eingebetteten Dokument zu dem Base-URI des ein-
gebetteten Dokuments aufgel=st, nicht zu dem des Hauptdokuments. Ein eingebettetes Doku-
ment wird nur innerhalb eines anderen Dokuments dargestellt (z. B. in einem Unterfenster);
Die HTML 4.01- Spezifikation

ansonsten bleibt es unabh@ngig.


Zum Beispiel bettet die folgende Zeile den Inhalt von embed_me.html an der Stelle ein, an der die
OBJECT-Definition erscheint.

...Text vorher...
<OBJECT data="embed_me.html">
Warnung: embed_me.html konnte nicht eingebettet werden.
</OBJECT>
...Text danach...

Rufen Sie sich in Erinnerung, dass der Inhalt von OBJECT nur dann dargestellt werden muss,
wenn die vom data-Attribut angegebene Datei nicht geladen werden kann.
In dem Fall, in dem eine Datei sich selbst enth@lt, ist das Verhalten eines Benutzerprogramms
nicht defniert.

13.6 Imagemaps
Imagemaps gestatten es Autoren, Bereiche eines Bildes oder Objekts anzugeben und weisen
jedem Bereich eine eigene Funktion zu (z. B. ein Dokument empfangen, ein Programm starten
usw.). Wird der Bereich durch den Benutzer aktiviert, wird die Funktion ausgefhrt.
Eine Imagemap wird erzeugt, indem einem Objekt sensitive geometrische Bereiche zugewiesen
werden.
Es gibt zwei Arten von Imagemaps:
· Client-seitig. Aktiviert der Benutzer mit der Maus einen Bereich der Client-seitigen Image-
map, werden die Koordinaten der Pixel vom Benutzerprogramm ausgewertet. Das Benut-
zerprogramm w@hlt den Link, der fr den aktivierten Bereich angegeben ist, und folgt ihm.
· Server-seitig. Aktiviert der Benutzer mit einer Maus einen Bereich der Server-seitigen Image-
map, werden die Koordinaten des angeklickten Pixels zu dem Server-seitigen Programm
gesendet, welches durch das href-Attribut des A-Elements angegeben ist. Das Server-seitige
Programm wertet die Koordinaten aus und fhrt irgendwelche Funktionen aus.
Client-seitige Imagemaps werden den Server-seitigen Imagemaps aus mindestens zwei Grnden vor-
gezogen: Sie sind zug@nglicher fr Menschen, die mit nicht visuellen Benutzerprogrammen surfen, und
sie geben eine direkte Rckmeldung, ob sich ein Zeiger ber einem aktiven Bereich befindet.

13.6.1 Client-seitige Imagemaps: die Elemente MAP und AREA

<!ELEMENT MAP - - ((%block;) | AREA)+ - - client-side image map - ->


<!ATTLIST MAP
%attrs; - - %coreattrs, %i18n, %events - -
name CDATA #REQUIRED - - for reference by usemap - -
>

Start-Tag: erforderlich, End-Tag: verboten

< 208 > Objekte, Bilder und Applets


Page size: 168,00 x 240,00 mm

<!ELEMENT AREA - O EMPTY - - client-side image map area - ->

<!ATTLIST AREA
%attrs; -- %coreattrs, %i18n, %events - -
shape %Shape; rect -- controls interpretation of coords - -

Die HTML 4.01- Spezifikation


coords %Coords; #IMPLIED -- comma-separated list of lengths - -
href %URI; #IMPLIED -- URI for linked resource - -
nohref (nohref) #IMPLIED -- this region has no action - -
alt %Text; #REQUIRED -- short description - -
tabindex NUMBER #IMPLIED -- position in tabbing order - -
accesskey %Character; #IMPLIED -- accessibility key character - -
onfocus %Script; #IMPLIED -- the element got the focus - -
onblur %Script; #IMPLIED -- the element lost the focus - -
>

Start-Tag: erforderlich, End-Tag: verboten

Attributdefinitionen fr MAP

name = cdata [CI]


Dieses Attribut weist der Imagemap, die durch das Element MAP definiert ist, einen Namen zu.

Attributdefinitionen fr AREA

shape = default|rect|circle|poly [CI]


Dieses Attribut gibt die Form des Bereichs an. M=gliche Werte:
·· default: Gibt den gesamten Bereich an.
rect: Definiert einen rechteckigen Bereich.

··circle: Definiert eine kreisf=rmigen Bereich.


poly: Definiert einen vieleckigen Bereich.

coords = coordinates [CN]


Dieses Attribut gibt die Position und die Form auf dem Bildschirm an. Anzahl und Reihen-
folge der Werte sind abh@ngig von der definierten Form. M=gliche Kombinationen sind:
·· rect: left-x, top-y, right-x, bottom-y.
circle: center-x, center-y, radius. Anmerkung: Ist der Radiuswert eine Prozentanga-
be, sollten Benutzerprogramme den endgltigen Radiuswert anhand der Breite und
H=he des entsprechenden Objekts berechnen. Der Radius sollte der kleinere der bei-
den Werte sein.
· poly: x1, y1, x2, y2, ..., xN, yN. Das erste und das letzte x-y-Koordinatenpaar sollten gleich
sein und das Vieleck schließen. Sind diese Koordinatenwerte nicht gleich, sollten Benutzer-
programme ein zus@tzliches Koordinatenpaar erzeugen, um das Vieleck zu schließen.
Koordinaten sind relativ zu der oberen linken Ecke des Objekts. Alle Werte sind Maße
(length, siehe Abschnitt 6.6). Alle Werte werden durch Kommata getrennt.
nohref [CI]
Wenn gesetzt, gibt dieses Boolesche Attribut an, dass diesem Bereich kein Verweis zuge-
ordnet ist.

Imagemaps < 209 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Attribute, um eine Imagemap mit einem Element zu verbinden

usemap = uri [CT]


Dieses Attribut verbindet eine Imagemap mit einem Element. Die Imagemap wird durch ein
Die HTML 4.01- Spezifikation

MAP-Element definiert. Der Wert von usemap muss dem Wert des name-Attributs des zu ver-
bindenden MAP-Elements entsprechen.

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Elementtitel)
style (inzeilige Formatierungsinformation)

·· name (Objekte mit Formularen bertragen)


alt (alternativer Text)

·· href (Ankerreferenz) target (Ziel-Frame-Angabe)


tabindex (Tabulatornavigation)

··accesskey (Zugriffstaste)
shape (Imagemaps)

·onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,


onkeydown, onkeyup, onfocus, onblur (eingebettete Ereignisse)

Anmerkung der bersetzer: Die Errata merken zu AREA an: „In der Spezifikation
ist unklar, ob x,y-Koordinaten die Basis 0 oder 1 verwenden. Ist die linke obere Ecke
(0,0) oder (1,1)?“ Eine Korrektur steht bisher (Stand 01/2003) nicht zur Verfgung.
Die Fassung von XHTML, an der zur Zeit gearbeitet wird (XHTML 2.0, Working Draft,
18. Dezember 2002), definiert die Koordinaten eindeutig. Dort heißt es in der „Samm-
lung der Imagemap-Attribute“: „Bildschirmkoordinaten werden als Pixelwerte aus-
gedrckt, die relativ zum Bild sind; ihr Ursprung ist (0,0) in der linken oberen Ecke.“

Das Element MAP gibt eine Client-seitige Imagemap an (oder einen anderen Navigationsmecha-
nismus), die mit anderen Elementen (IMG, OBJECT oder INPUT) verbunden werden kann. Eine
Imagemap wird mit einem Element ber das usemap-Attribut des Elements verknpft. Das Ele-
ment MAP kann als allgemeiner Navigationsmechanismus ohne ein verknpftes Bild verwendet
werden.
Die Gegenwart eines usemap-Attributs in einem OBJECT bedingt, dass dieses eingebettete Objekt
ein Bild ist. Wenn das Element OBJECT darber hinaus eine verknpfte Client-seitige Imagemap
hat, k=nnen Benutzerprogramme eine Interaktion des Benutzers mit dem OBJECT-Element nur
in Bezug auf die Client-seitige Imagemap implementieren. Dies gestattet Benutzerprogrammen
(wie einem Audio-Browser oder einem Robot) mit dem OBJECT-Element zu interagieren, ohne
es ausfhren zu mssen; das Benutzerprogramm kann sogar entscheiden, das referenzierte
Objekt nicht zu laden (oder auszufhren). Hat ein OBJECT-Element eine verknpfte Imagemap,
sollten Autoren nicht erwarten, dass dieses Objekt von jedem Benutzerprogramm empfangen
oder ausgefhrt wird.

< 210 > Objekte, Bilder und Applets


Page size: 168,00 x 240,00 mm

Das Inhaltsmodell des MAP-Elements gestattet Autoren die Kombination des Folgenden:
1. Eines oder mehrere AREA-Elemente. Diese Elemente haben keinen Inhalt, aber sie geben die
geometrischen Bereiche der Imagemap an und den Link, der mit jedem Bereich verbunden
ist. Beachten Sie, dass Benutzerprogramme AREA-Elemente im Allgemeinen nicht darstellen.

Die HTML 4.01- Spezifikation


Hierfr mssen Autoren einen alternativen Text fr jedes AREA-Element ber das alt-Attri-
but angeben (weitere Informationen in „Wie alternativer Text angegeben wird“ unten).
2. Blockinhalt. Dieser Inhalt sollte A-Elemente einschließen, die geometrische Bereiche der
Imagemap angeben und den Link, der mit jedem Bereich verbunden ist. Beachten Sie, dass
ein Benutzerprogramm den Blockinhalt eines MAP-Elements darstellen sollte. Autoren soll-
ten diese Methode verwenden, um zug@nglichere Dokumente zu erschaffen.
Wenn ein MAP-Element gemischten Inhalt enth@lt (sowohl AREA-Elemente als auch Blockinhalt),
mssen Benutzerprogramme das AREA-Element ignorieren.
Autoren sollten die Geometrie einer Imagemap vollst@ndig mit AREA-Elementen, vollst@ndig mit
A-Elementen oder, wenn der Inhalt gemischt ist, vollst@ndig mit beiden Elementen angeben.
Autoren m=chten vielleicht den Inhalt mischen, damit auf der einen Seite @ltere Benutzerpro-
gramme die Map-Geometrie bearbeiten k=nnen, die durch AREA-Elemente angegeben wird, und
neue Benutzerprogramme auf der anderen Seite Vorteil aus vielf@ltigerem Blockinhalt ziehen
k=nnen.
berschneiden sich zwei oder mehr definierte Bereiche, hat das den Bereich beschreibende
Element, das zuerst im Dokument steht, den Vorrang (z. B. reagiert es auf Benutzereingabe).
Benutzerprogramme und Autoren sollten alternativen Text zu graphischen Imagemaps bieten,
und zwar fr den Fall, dass die Graphiken nicht verfgbar sind oder der Benutzer nicht auf sie
zugreifen kann. Zum Beispiel k=nnen Benutzerprogramme den Text des alt-Attributs verwen-
den, um Textverweise anstelle einer graphischen Imagemap zu erzeugen. Solche Verweise k=n-
nen auf verschiedene Weise aktiviert werden (Tastatur, Sprachaktivierung usw.).

Anmerkung: MAP ist nicht rckw,rtskompatibel zu Benutzerprogrammen, die fr HTML 2.0
geschrieben wurden. n

Beispiele Client-seitiger Imagemaps


Im folgenden Beispiel erzeugen wir eine Client-seitige Imagemap fr das Element OBJECT. Wir
wollen den Inhalt der Imagemap nicht darstellen, wenn das OBJECT dargestellt wird, deshalb
„verstecken“ wir das Element MAP im Inhalt des Elements OBJECT. Folglich wird der Inhalt des
Elements MAP nur dann dargestellt, wenn das OBJECT nicht dargestellt werden kann.

<HTML>
<HEAD>
<TITLE>Die coole Seite!</TITLE>
</HEAD>
<BODY>
<P><OBJECT data="navbar1.gif" type="image/gif" usemap="#map1">
<MAP name="map1">
<P>Navigiere durch die Web-Seiten:
<A href="guide.html" shape="rect" coords="0,0,118,28">Hilfe</a> |
<A href="shortcut.html" shape="rect" coords="118,0,184,28">Gehe zu</A> |
<A href="search.html" shape="circle" coords="184,200,60">Suchen</A> |
<A href="top10.html" shape="poly"
coords="276,0,276,28,100,200,50,50,276,0">Top 10</A>

Imagemaps < 211 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

</MAP>
</OBJECT>
</BODY>
</HTML>
Die HTML 4.01- Spezifikation

Vielleicht m=chten wir den Inhalt der Imagemap sogar dann darstellen, wenn ein Benutzerpro-
gramm das OBJECT wiedergeben kann. Zum Beispiel wollen wir vielleicht eine Imagemap mit
einem OBJECT-Element verknpfen und eine Textnavigation am Fuß der Seite anbringen. Um das
zu realisieren, definieren wir das MAP-Element außerhalb des OBJECT-Elements:

<HTML>
<HEAD>
<TITLE>Die coole Seite!</TITLE>
</HEAD>
<BODY>
<P><OBJECT data="navbar1.gif" type="image/gif" usemap="#map1">
</OBJECT>

...der Rest der Seite hier...

<MAP name="map1">
<P>Navigiere durch die Seite:
<A href="guide.html" shape="rect" coords="0,0,118,28">Hilfe</a> |
<A href="shortcut.html" shape="rect" coords="118,0,184,28">Gehe zu</A> |
<A href="search.html" shape="circle" coords="184,200,60">Suchen</A> |
<A href="top10.html" shape="poly"
coords="276,0,276,28,100,200,50,50,276,0">Top 10</A>
</MAP>
</BODY>
</HTML>

Im folgenden Beispiel erzeugen wir eine @hnliche Imagemap, diesmal mit dem AREA-Element.
Beachten Sie die Verwendung des alternativen Texts mit Hilfe des Attributs alt:

<P><OBJECT data="navbar1.gif" type="image/gif" usemap="#map1">


<P>Dies ist eine Navigationsleiste.
</OBJECT>

<MAP name="map1">
<AREA href="guide.html"
alt="Hilfe"
shape="rect"
coords="0,0,118,28">
<AREA href="search.html"
alt="Suchen"
shape="rect"
coords="184,0,276,28">
<AREA href="shortcut.html"
alt="Gehe zu"
shape="circle"
coords="184,200,60">
<AREA href="top10.html"
alt="Top 10"

< 212 > Objekte, Bilder und Applets


Page size: 168,00 x 240,00 mm

shape="poly"
coords="276,0,276,28,100,200,50,50,276,0">
</MAP>

Hier ist eine @hnliche Version, die das IMG-Element statt des OBJECT-Elements verwendet (mit

Die HTML 4.01- Spezifikation


der gleichen MAP-Deklaration):

<P><IMG src="navbar1.gif" usemap="#map1" alt="Navigationsleiste">

Das folgende Beispiel zeigt, wie Imagemaps gemeinsam verwendet werden k=nnen.
Verschachtelte OBJECT-Elemente sind ntzlich, um Ausweichm=glichkeiten parat zu halten, falls
ein Benutzerprogramm ein bestimmtes Format nicht untersttzt. Zum Beispiel:

<P>
<OBJECT data="navbar.png" type="image/png">
<OBJECT data="navbar.gif" type="image/gif">
Text, der das Bild beschreibt...
</OBJECT>
</OBJECT>

Untersttzt das Benutzerprogramm das PNG-Format nicht, versucht es, das GIF-Bild darzustel-
len. Wenn es GIF nicht untersttzt (z. B. ein sprachbasiertes Benutzerprogramm), dann stellt es
die Textbeschreibung dar, die als Inhalt des inneren OBJECT-Elements angegeben ist. Sind
OBJECT-Elemente auf diese Weise verschachtelt, k=nnen Autoren die Imagemaps fr diese Ele-
mente gemeinsam nutzen.

<P>
<OBJECT data="navbar.png" type="image/png" usemap="#map1">
<OBJECT data="navbar.gif" type="image/gif" usemap="#map1">
<MAP name="map1">
<P>Navigate the site:
<A href="guide.html" shape="rect" coords="0,0,118,28">Hilfe</a> |
<A href="shortcut.html" shape="rect" coords="118,0,184,28">Gehe zu</A> |
<A href="search.html" shape="circle" coords="184,200,60">Suchen</A> |
<A href="top10.html" shape="poly"
coords="276,0,276,28,100,200,50,50,276,0">Top 10</A>
</MAP>
</OBJECT>
</OBJECT>

Das folgende Beispiel zeigt, wie Anker angegeben werden k=nnen, um inaktive Bereiche inner-
halb einer Imagemap zu erzeugen. Der erste Anker gibt einen kleinen kreisf=rmigen Bereich
ohne verbundenen Verweis an. Der zweite Anker gibt einen gr=ßeren kreisf=rmigen Bereich
mit den gleichen Mittelpunktkoordinaten an. Zusammen formen die beiden einen Ring, dessen
Mitte inaktiv, und dessen Rand aktiv ist. Die Reihenfolge der Ankerdefinitionen ist wichtig, weil
der kleinere Kreis den gr=ßeren Kreis berschreiben muss.

<MAP name="map1">
<P>
<A shape="circle" coords="100,200,50">Ich bin inaktiv.</A>

Imagemaps < 213 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

<A href="outer-ring-link.html" shape="circle" coords="100,200,250">Ich bin


aktiv.</A>
</MAP>

Ohnlich dazu deklariert das Attribut nohref des AREA-Elements, dass ein geometrischer Bereich
Die HTML 4.01- Spezifikation

keinen verbundenen Link enth@lt.

13.6.2 Server-seitige Imagemaps

Server-seitige Imagemaps k=nnen in den F@llen interessant sein, in denen die Imagemap fr eine
client-seitige Imagemap zu kompliziert ist.
Eine server-seitige Imagemap kann nur fr die Elemente IMG und INPUT definiert werden. Im Fall
von IMG muss sich IMG innerhalb eines A-Elements befinden und das Boolesche Attribut ismap
([CI]) muss gesetzt sein. Im Fall von INPUT muss INPUT vom Typ „image“ sein.
Aktiviert der Benutzer den Link durch Anklicken der Graphik, werden die Bildschirmkoordina-
ten direkt zum Server geschickt, auf dem das Dokument vorliegt. Bildschirmkoordinaten wer-
den als Bildschirmpixelwerte relativ zur Graphik ausgedrckt. Normative Informationen ber
die Definition eines Pixels und wie seine Position bestimmt wird, finden Sie in [CSS1].
Im folgenden Beispiel definiert der aktive Bereich einen Server-seitigen Link. Durch einen Klick
auf irgendeine Stelle im Bild werden die Koordinaten des Klicks zum Server geschickt.

<P><A href="http://www.acme.com/cgi-bin/competition">
<IMG src="game.gif" ismap alt="Ziel"></A>

Der angeklickte Punkt wird wie folgt zum Server weitergeleitet. Das Benutzerprogramm
erzeugt einen neuen URI aus dem URI, der vom href-Attribut des A-Elements angegeben ist.
Dies geschieht durch Anh@ngen eines „?“, gefolgt von den x- und y-Koordinaten, getrennt
durch ein Komma. Dem Link wird dann mit dem neuen URI nachgegangen. Klickt der Benutzer
im gegebenen Beispiel auf die Stelle mit den Koordinaten x=10 und y=27, dann ist der abgelei-
tete URI „http://www.acme.com/cgi-bin/competition?10,27“.
Benutzerprogramme, die dem Benutzer nicht die M=glichkeit bieten, bestimmte Koordinaten
auszuw@hlen (z. B. nicht graphische Benutzerprogramme, die auf Tastatureingaben angewiesen
sind, sprachbasierte Benutzerprogramme usw.), sollten die Koordinaten „0,0“ an den Server
senden, wenn der Link aktiviert wird.

13.7 Visuelle Darstellung von Bildern, Objekten und


Applets
Alle Attribute zu IMG und OBJECT, welche die visuelle Ausrichtung und Darstellung betreffen,
wurden zu Gunsten von Stylesheets fr missbilligt erkl@rt.

13.7.1 Breite und HUhe

Attributdefinitionen

width = length [CN]


Bild- und Objektbreite berschreiben.

< 214 > Objekte, Bilder und Applets


Page size: 168,00 x 240,00 mm

height = length [CN]


Bild- und Objekth=he berschreiben.

Werden die Attribute width und height angegeben, weisen sie das Benutzerprogramm an, die

Die HTML 4.01- Spezifikation


originalen Bild- oder Objektgr=ßen zu Gunsten dieser Werte zu berschreiben.
Ist das Objekt ein Bild, wird es skaliert. Benutzerprogramme sollten ihr Bestes geben, um ein
Objekt oder Bild in der Breite und H=he so anzupassen, wie es vom Autor angegeben ist.
Beachten Sie, dass sich prozentual angegebene L@ngen auf den horizontal oder vertikal verfg-
baren Raum beziehen, der aktuell zur Verfgung steht, und nicht auf die originale Gr=ße des
Bilds, Objekts oder Applets.
Die Attribute height und width geben Benutzerprogrammen Informationen ber die Gr=ße
eines Bilds oder Objekts, so dass sie Platz reservieren und das Dokument weiter aufbauen k=n-
nen, w@hrend sie auf die Bilddaten warten.

13.7.2 Leerraum um Bilder und Objekte herum

Attributdefinitionen

hspace = pixels [CN]


Missbilligt. Dieses Attribut gibt die Gr=ße des Leerraums an, der an der rechten und lin-
ken Seite des Elements IMG, APPLET oder OBJECT erscheinen soll. Ein Standardwert ist nicht
vorgegeben, jedoch ist es im Allgemeinen eine geringes Maß ungleich Null.
vspace = pixels [CN]
Missbilligt. Dieses Attribut gibt die Gr=ße des Leerraums an, der ber und unter dem Ele-
ment IMG, APPLET oder OBJECT erscheinen soll. Ein Standardwert ist nicht vorgegeben, jedoch
ist es im Allgemeinen eine geringes Maß ungleich Null.

13.7.3 Rahmen

Ein Bild oder Objekt kann von einem Rahmens umgeben sein (z. B. wenn ein Rahmen vom
Benutzer vorgegeben wurde, oder wenn das Bild Inhalt eines A-Elements ist).

Attributdefinitionen

border = pixels [CN]


Missbilligt. Dieses Attribut gibt die Breite des Rahmens von IMG oder OBJECT in Pixeln an.
Die Voreinstellung fr dieses Attribut h@ngt vom Benutzerprogramm ab.

13.7.4 Ausrichtung

Attributdefinitionen

align = bottom|middle|top|left|right
Missbilligt. Dieses Attribut gibt die Position eines IMG, OBJECT oder APPLET in Bezug zu sei-
nem Kontext an.

Visuelle Darstellung von Bildern, Objekten, Applets < 215 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Die folgenden Werte fr align betreffen die Position des Objekts in Bezug auf den umgeben-
den Text:
· bottom: bedeutet, dass der untere Rand des Objekts vertikal zur Grundlinie der aktuellen
Textzeile ausgerichtet werden soll. Dies ist die Voreinstellung.
·
Die HTML 4.01- Spezifikation

middle: bedeutet, dass die Mitte des Objekts vertikal zur Grundlinie der aktuellen Textzeile
ausgerichtet werden soll.
· top: bedeutet, dass der obere Rand des Objekts vertikal zu der Oberkante der aktuellen
Textzeile ausgerichtet werden soll.
Zwei weitere Werte, left und right, lassen das Bild zum aktuellen linken oder rechten Rand
fließen. Sie werden im Abschnitt 15.1.3, „Umflossene Objekte“ besprochen.

Unterschiedliche Auslegung von align: Benutzerprogramme interpretieren das align-Attribut


unterschiedlich. Einige bercksichtigen nur, was in der Textzeile vor dem Element erscheint, einige
bercksichtigen den Text auf beiden Seiten des Elements. n

Anmerkung der bersetzer: Anstelle der missbilligten Atribute, die sich alle auf
die visuelle Darstellung beziehen, ist der Einsatz von Stylesheets zu empfehlen.
Die Attribute width und height, die auf den ersten Blick ebenfalls der visuellen Darstel-
lung dienen, sollten auch weiterhin benutzt werden. Wenn diese Werte bekannt sind
bevor die Bilddatei selbst geladen ist, gestatten sie auch neueren visuellen Browsern
einen „ruhigeren“ Aufbau der Darstellung.

13.8 Wie alternativer Text angegeben wird


Attributdefinitionen

alt = text [CS]


Dieses Attribut gibt alternativen Text fr Benutzerprogramme an, die Bilder, Formulare
oder Applets nicht darstellen k=nnen. Die Sprache des alternativen Texts wird durch das
Attribut lang festgelegt.

Viele Elemente, die prim@r nicht darauf ausgelegt sind, Text darzustellen (IMG, AREA, APPLET und
INPUT), bieten Autoren die M=glichkeit, einen alternativen Text anzugeben, der als Inhalt dient,
wenn das Element nicht wie vorgesehen dargestellt werden kann. Die Angabe von alternativem
Text untersttzt Benutzer ohne graphische Anzeigeterminals, Benutzer, deren Browser keine
Formulare untersttzen, Benutzer mit Sehschw@chen, die Sprachsynthesizer verwenden, dieje-
nigen, die ihren graphischen Browser so konfiguriert haben, dass Bilder nicht angezeigt werden
usw.
Das alt-Attribut muss fr die Elemente IMG und AREA angegeben werden. Es ist optional fr die
Elemente INPUT und APPLET.
Auch wenn alternativer Text sehr hilfreich sein kann, so muss er doch mit Vorsicht verwendet
werden. Autoren sollten die folgenden Richtlinien beachten:

< 216 > Visuelle Darstellung von Bildern, Objekten, Applets


Page size: 168,00 x 240,00 mm

· Geben sie keinen belanglosen alternativen Text an, wenn sie Bilder verwenden, um eine
Seite zu formatieren. Zum Beispiel w@re alt="rote Kugel" unangebracht fr ein Bild, das eine
rote Kugel zur Dekoration einer berschrift oder eines Absatzes darstellt. In solchen F@llen
sollte der alternative Text eine leere Zeichenkette sein (""). Autoren werden nachdrcklich

Die HTML 4.01- Spezifikation


dazu angehalten, Bilder nicht zur Formatierung von Seiten zu verwenden; stattdessen soll-
ten Stylesheets verwendet werden.
· Geben Sie keinen sinnlosen Text an (z. B. „Dummy-Text“). Dies wird Benutzer nicht nur
frustrieren, es wird auch Benutzerprogramme verlangsamen, die den Text als Sprache oder
in Blindenschrift ausgeben.
Entwickler sollten den Abschnitt „Anmerkungen zur Zug@nglichkeit“ im Anhang B lesen, um
Informationen zu erhalten, wie in F@llen, in denen alternativer Text fehlt, zu verfahren ist.

14 Stylesheets
14.1 Einf-hrung in Stylesheets
Stylesheets bedeuten einen wichtigen Durchbruch fr Web-Designer. Stylesheets erweitern
die M=glichkeiten der Designer, das Erscheinungsbild ihrer Seiten zu verbessern. In der wissen-
schaftlichen Umgebung, in der das Web entwickelt wurde, hat man mehr Wert auf den Inhalt
als auf die Darstellung des Dokuments gelegt. Nachdem Menschen aus immer mehr Schichten
und Berufen das Web entdeckten, fhrten die Grenzen von HTML zu einer fortschreitenden
Frustration, und Autoren wurden gezwungen, diese stilistischen Einschr@nkungen von HTML
zu umgehen. Auch wenn die Absichten gut waren – die Darstellung von Web-Seiten zu verbes-
sern – hatten die verwendeten Techniken unsch=ne Nebenwirkungen. Diese Techniken funk-
tionieren fr einige Leuten manchmal, nicht fr alle Leuten fr immer. Diese Techniken sind es:
·· Propriet@re HTML-Erweiterungen
Text in Graphiken umwandeln
·· Graphiken fr die Gestaltung von Leerraum verwenden
Das Layout der Seiten mit Tabellen gestalten
· Eine Anwendung schreiben, statt HTML zu verwenden
Diese Techniken erh=hen die Komplexit@t von Web-Seiten erheblich, bieten begrenzte Flexibi-
lit@t, leiden an Interoperabilit@tsproblemen und erzeugen unangenehme Nachteile fr Men-
schen mit Behinderungen.
Stylesheets l=sen diese Probleme im gleichen Moment, in dem sie die begrenzten Darstellungs-
mechanismen in HTML berwinden. Stylesheets machen es einfach, den Leerraum zwischen
Textzeilen anzugeben, die Einrckung von Zeilen zu steuern, Farben fr Text und Hintergrund
festzulegen, Schriftgr=ße und -art und eine Flle weiterer Details zu steuern.
Zum Beispiel bestimmt das folgende kurze CSS-Stylesheet (gespeichert in der Datei special.css)
die grne Textfarbe des Absatzes und umrandet diesen mit einer geschlossenen roten Linie:

Stylesheets < 217 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

P.special {
color : green;
border: solid red;
}
Die HTML 4.01- Spezifikation

Autoren k=nnen dieses Stylesheet mit Hilfe des LINK-Elements in ihr HTML-Quelldokument
einbinden:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"


"http://www.w3.org/TR/html4/strict.dtd">
<HTML>
<HEAD>
<LINK href="special.css" rel="stylesheet" type="text/css">
</HEAD>
<BODY>
<P class="special">Dieser Absatz sollte speziellen grUnen Text enthalten.</P>
</BODY>
</HTML>

HTML 4 untersttzt die folgenden Stylesheet-Eigenschaften:

Flexible Platzierung der Stilinformationen


Die Verwaltung von Stylesheets in separaten Dateien erleichtert ihre Wiederverwendung.
Manchmal ist es sinnvoll, Darstellungsanweisungen innerhalb des Dokuments anzugeben, in
dem sie angewendet werden. Entweder geschlossen am Anfang eines Dokuments, oder als
Attributwert in den Elementen innerhalb des Dokumentrumpfes. Um es einfacher zu
machen, die Formatierung fr einen gesamten Website zu verwalten, beschreibt diese Spe-
zifikation wie HTTP-Header verwendet werden k=nnen, um einem Dokument Stylesheets
zuzuweisen.
Unabh.ngigkeit von bestimmten Stylesheet-Sprachen
Diese Spezifikation bindet HTML nicht an irgendeine bestimmte Stylesheet-Sprache. Sie
erlaubt die Verwendung unterschiedlicher Sprachen, zum Beispiel einfache Sprachen fr die
Mehrheit der Benutzer und komplexere fr eine Minderheit mit hoch spezialisierten Anfor-
derungen. Die unten stehenden Beispiele verwenden durchgehend die Sprache CSS (Casca-
ding Style Sheets) [CSS1], andere Stylesheet-Sprachen w@ren jedoch auch m=glich.
Kaskadierend
Dies ist die F@higkeit einiger Stylesheet-Sprachen wie CSS, die Formatierungsinformationen
verschiedener Quellen miteinander zu vermischen. Es k=nnen zum Beispiel firmenweite
Formatierungsrichtlinien sein, das gemeinsame Layout einer Dokumentreihe und ein Stil,
der speziell fr ein Dokument gilt. Werden diese getrennt gespeichert, k=nnen Stylesheets
wiederverwendet werden, die Erstellung vereinfachen und Zwischenspeicherungen im Netz
(caching) besser nutzen. Die Kaskade definiert eine geordnete Reihenfolge der Stylesheets.
Vorschriften in sp@teren Stylesheets haben Vorrang gegenber den zuvor gelesenen. Nicht
alle Stylesheet-Sprachen sind kaskadierend.
Medienabh.ngigkeit
HTML erlaubt Autoren, Dokumente unabh@ngig von bestimmten Medien zu erstellen. Dies
gestattet Benutzern den Zugang zu Web-Seiten mit vielen verschiedenen Ger@ten und
Medien, zum Beispiel mit graphischen Displays fr Computer, die mit Windows, Macintosh

< 218 > Stylesheets


Page size: 168,00 x 240,00 mm

OS und X11 laufen, mit Zusatzger@ten fr Fernseher, mit besonders ausgestatteten Telefo-
nen und PDA-basierten tragbaren Ger@ten, sowie mit sprachbasierten Browsern und Blin-
denschrift anzeigenden Tastger@ten.
Stylesheets richten sich im Gegensatz dazu an bestimmte Medien oder Mediengruppen. Ein

Die HTML 4.01- Spezifikation


Stylesheet, das fr die Ausgabe am Bildschirm gedacht ist, kann auch zum Drucken geeignet
sein, ist jedoch fr sprachbasierte Browser wenig hilfreich. Diese Spezifikation erlaubt
Ihnen, die groben Medienkategorien zu definieren, fr die ein Stylesheet geeignet ist. Dies
hilft Benutzerprogrammen dabei, den Empfang ungeeigneter Stylesheets zu vermeiden.
Stylesheet-Sprachen k=nnen M=glichkeiten zur Beschreibung von Medienabh@ngigkeiten
innerhalb desselben Stylesheets enthalten.

Anmerkung der bersetzer: Ein Beispiel fr ein CSS-Stylesheet, das Formatie-
rungen fr mehrere Ausgabemedien enth@lt, finden Sie in Abschnitt 7.2.1 der CSS2-Spe-
zifikation. In Anhang A von CSS2 finden Sie ein Stylesheet fr HTML 4-Dokumente.
Auch dieses Stylesheet besitzt Formatierungsregeln fr unterschiedliche Medien.

Alternative Stile
Autoren m=chten dem Leser eventuell verschiedene M=glichkeiten anbieten, ein Doku-
ment zu betrachten. Zum Beispiel mit einem Stylesheet, um kompakte Dokumente mit
kleinen Schriftarten darzustellen, oder mit einem Stylesheet, das gr=ßere Schriftarten zur
besseren Lesbarkeit bietet. Diese Spezifikation gestattet es Autoren, ein bevorzugtes Style-
sheet wie auch Alternativen fr bestimmmte Benutzer oder Medien anzugeben. Die Benut-
zerprogramme sollten Benutzern die M=glichkeit geben, zwischen alternativen Stylesheets
zu w@hlen oder diese ganz auszuschalten.
Leistungsbedenken
Einige Personen haben Bedenken ber die Leistungsf@higkeit von Stylesheets ausgespro-
chen. Zum Beispiel k=nnte der Empfang eines externen Stylesheets die vollst@ndige Darstel-
lung fr den Benutzer verlangsamen. Eine @hnliche Situation tritt ein, wenn der Dokument-
kopf eine lange Aufz@hlung mit Stilregeln enth@lt.
Der aktuelle Vorschlag tr@gt diesem Umstand insofern Rechnung, dass es Autoren gestattet
wird, die Darstellungsanweisungen innerhalb der HTML-Elemente anzugeben. Die Darstel-
lungsanweisung ist folglich immer dann verfgbar, wenn ein Benutzerprogramm die betref-
fenden Elemente darstellen m=chte.
In vielen F@llen werden Autoren den Vorteil eines gemeinsamen Stylesheets fr mehrere
Dokumente nutzen. In diesem Fall wird die Verwendung von Formatierungsregeln innerhalb
des Dokuments zu einer geringeren Leistung fhren, als wenn auf ein Stylesheet verwiesen
wrde, da fr die meisten Dokumente bereits ein Stylesheet im lokalen Cache vorhanden
sein wird. Die =ffentliche Verfgbarkeit von guten Stylesheets wird diesen Effekt verst@rken.

14.2 HTML-Dokumente formatieren


Anmerkung: Das Beispiel des Stylesheets fr HTML 4, das in [CSS2] enthalten ist, stellt allgemein
anerkannte Standardformatierungsinformationen fr jedes Element dar. Sowohl Autoren als auch Ent-
wickler k nnten dies als eine ntzliche Quelle ansehen. n
HTML-Dokumente k=nnen Stylesheet-Regeln direkt enthalten oder Stylesheets importieren.

HTML-Dokumente formatieren < 219 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Jede Stylesheet-Sprache kann mit HTML verwendet werden. Eine einfache Stylesheet-Sprache
kann den Anforderungen der meisten Benutzer gengen, andere Sprachen k=nnen jedoch fr
hochspezialisierte Anforderungen eher geeignet sein. Diese Spezifikation verwendet fr Bei-
spiele die Formatierungssprache „Cascading Style Sheets“ ([CSS1]), kurz CSS.
Die HTML 4.01- Spezifikation

Die Syntax von Formatierungsangaben (siehe auch Abschnitt 6.15, „Stylesheet-Daten“) ist
abh@ngig von der verwendeten Stylesheet-Sprache.

14.2.1 Festlegen der Standard-Stylesheet-Sprache

Autoren mssen die Stylesheet-Sprache angeben, die fr die Formatierungsinformationen eines
HTML-Dokuments gelten soll.

Anmerkung der bersetzer: Die praktische Relevanz dieses Abschnitts ist ziem-
lich gering: Fr den Fall, dass Formatierungsinformationen im Element STYLE im Kopf
der HTML-Datei stehen, muss zwingend das Attribut type die Stylesheet-Sprache ange-
ben. Fr den Fall, dass die Formatierungsanweisungen in einer externen CSS-Datei ste-
hen, die von der HTML-Datei per LINK eingebunden wird, muss der Web-Server in der
HTTP-Antwort in der Zeile Content-type den Wert text/css angeben. Eine Typangabe
in der CSS-Datei ist nicht m=glich.
Der Sinn dieses Abschnitts beschr@nkt sich im brigen dann auf die inzeiligen Formatie-
rungsanweisungen, die im n@chsten Abschnitt erkl@rt werden. Allerdings ist gerade
diese inzeilige Platzierung von Formatierungsanweisungen diejenige, von der man m=g-
lichst Abstand nehmen soll.

Autoren sollten das Element META verwenden, um die voreingestellte Stylesheet-Sprache fr ein
Dokument zu bestimmen. Um die Voreinstellung zum Beispiel auf CSS zu setzen, sollten Auto-
ren die folgende Deklaration in den HEAD ihrer Dokumente einfgen:

<META http-equiv="Content-Style-Type" content="text/css">

Die voreingestellte Stylesheet-Sprache kann auch ber HTTP-Header festgelegt werden. Die
oben beschriebene META-Deklaration ist @quivalent zu dem HTTP-Header:

Content-Style-Type: text/css

Benutzerprogramme sollten die Voreinstellung fr die Stylesheet-Sprache fr ein Dokument
anhand der folgenden Schritte bestimmen (von h=chster zu niedrigster Priorit@t):
1. Geben META-Deklarationen den „Content-Style-Type“ an, bestimmt die letzte Deklaration
in der Dokumentzeichenfolge die Voreinstellung fr die Stylesheet-Sprache.
2. Anderenfalls, wenn irgendwelche HTTP-Header den „Content-Style-Type“ angeben,
bestimmt die letzte Angabe in der Dokumentzeichenfolge die Voreinstellung fr die Style-
sheet-Sprache.
3. Ansonsten ist die Voreinstellung fr die Stylesheet-Sprache „text/css“.

< 220 > Stylesheets


Page size: 168,00 x 240,00 mm

Dokumente, welche Elemente enthalten, die das Attribut style verwenden, die aber keine vor-
eingestellte Stylesheet-Sprache definieren, sind inkorrekt. Webseiten erzeugende Programme
sollten Voreinstellungen fr Stylesheet-Informationen generieren (blicherweise eine META-De-
klaration), so dass Benutzerprogramme sich nicht auf die Voreinstellung „text/css“ berufen

Die HTML 4.01- Spezifikation


mssen.

14.2.2 Inzeilige Formatierungsinformation

Attributdefinitionen

style = style [CN]


Dieses Attribut gibt Formatierungsinformationen fr das aktuelle Element an.

Die Syntax des Wertes des Attributs style wird von der voreingestellten Stylesheet-Sprache
festgelegt. Um zum Beispiel inzeilige Formatierangaben nach [CSS2] anzugeben, verwenden Sie
die Blocksyntax fr Deklarationen wie in Abschnitt 4.1.8 beschrieben (ohne die begrenzenden
geschweiften Klammern).

Anmerkung der bersetzer: Gemeint ist hier Abschnitt 4.1.8 der Spezifikation
fr „Cascading Style Sheets, Level 2“, der erkl@rt, dass Deklarationen fr denselben
Selektor in durch Semikolons (;) voneinander getrennten Gruppen angeordnet werden
k=nnen.

Dieses CSS-Beispiel legt die Farbe und die Schriftgr=ße fr den Text in einem bestimmten
Absatz fest.

<P style="font-size: 12pt; color: fuchsia">Sind Stylesheets nicht wunderbar?</P>

In CSS haben die Eigenschaftsdeklarationen die Form „name: wert“ und werden durch ein
Semikolon getrennt.
Zur Angabe von Formatierungsinformationen fr mehr als ein Element, sollten Autoren das
Element STYLE verwenden. Um eine optimale Flexibilit@t zu erreichen, sollten Autoren die For-
matierungen in externen Stylesheets definieren.

14.2.3 Formatierungsinformationen im Kopf: das Element STYLE

<!ELEMENT STYLE - - %StyleSheet - - style info - ->


<!ATTLIST STYLE
%i18n; -- lang, dir, for use with title - -
type %ContentType; #REQUIRED -- content type of style language - -
media %MediaDesc; #IMPLIED -- designed for use with these media - -
title %Text; #IMPLIED -- advisory title - -
>

Start-Tag: erforderlich, End-Tag: erforderlich

HTML-Dokumente formatieren < 221 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Attributdefinitionen

type = content-type [CI]


Dieses Attribut gibt die Stylesheet-Sprache des Elementinhalts an und berschreibt die vor-
Die HTML 4.01- Spezifikation

eingestellte Stylesheet-Sprache. Die Stylesheet-Sprache wird als Inhaltstyp angegeben (zum


Beispiel „text/css“). Autoren mssen einen Wert fr dieses Attribut angeben; es gibt keinen
Standardwert fr dieses Attribut.
media = media-descriptors [CI]
Dieses Attribut gibt das anvisierte Zielmedium fr die Formatierungsinformationen an. Es
kann eine einzelne Medienbeschreibung sein oder eine durch Kommata getrennte Liste.
Der Standardwert fr dieses Attribut ist „screen“ fr die Bildschirmausgabe.

Anmerkung der bersetzer: Bislang spielt keine andere Stylesheet-Sprache


außer CSS eine Rolle fr die Einbettung in HTML beziehungsweise XHTML, und es ist
auch keine Alternative absehbar. (In XML-Dateien werden blicherweise keine Forma-
tierungsinformationen integriert; statt dessen werden meist externe Stylesheets refe-
renziert.) Fr das HTML-Element STYLE gilt damit in der Praxis immer, dass das Attribut
type den Wert „text/css“ besitzt.
Die Funktion des media-Attributs kann auch eine @media-Regel in CSS bernehmen.
Details finden Sie in der CSS2-Spezifikation im Abschnitt 7.2.1.

An anderer Stelle definierte Attribute


·· lang (Sprachcode), dir (Leserichtung)
title (Elementtitel)

Das Element STYLE gestattet Autoren, Stylesheet-Regeln in den Kopf des Dokuments zu stellen.
HTML erlaubt eine beliebige Anzahl von STYLE-Elementen im HEAD-Bereich eines Dokuments.
Benutzerprogramme, die keine Stylesheets untersttzen beziehungsweise die von einem STYLE-
Element verwendete spezifische Stylesheet-Sprache nicht untersttzen, mssen den Inhalt des
STYLE-Elements verbergen. Es ist ein Fehler, den Inhalt als Teil des Dokumenttextes darzustel-
len. Einige Stylesheet-Sprachen untersttzen die Syntax, den Inhalt vor nicht konformen Benut-
zerprogrammen zu verbergen.
Die Syntax der Formatierungsangaben ist abh@ngig von der Stylesheet-Sprache.
Einige Stylesheet-Implementierungen m=gen vielf@ltigere Regeln im STYLE-Element erlauben als
im style-Attribut. Zum Beispiel k=nnen mit CSS die Regeln in einem STYLE-Element bestimmt
werden fr:
· Alle Instanzen eines bestimmten HTML-Elements (zum Beispiel alle P-Elemente, alle H1-Ele-
mente usw.)
· Alle Instanzen eines HTML-Elements, das zu einer bestimmten Klasse geh=ren (d. h., dessen
class-Attribut auf einen Wert gesetzt ist)

· Einzelne Instanzen eines HTML-Elements (d. h., dessen id-Attribut auf einen Wert gesetzt
ist)
Vorgaben zur Verarbeitungsreihenfolge der Formatierungsregeln und zur Vererbung sind
abh@ngig von der Stylesheet-Sprache.

< 222 > Stylesheets


Page size: 168,00 x 240,00 mm

Die folgende CSS STYLE-Deklaration erzeugt einen Rahmen um jedes H1-Element im Dokument
und zentriert es auf der Seite:

<HEAD>

Die HTML 4.01- Spezifikation


<STYLE type="text/css">
H1 {border-width: 1; border: solid; text-align: center}
</STYLE>
</HEAD>

Um anzugeben, dass die Formatierungsinformation nur fr H1-Elemente einer bestimmten


Klasse gelten soll, ver@ndern wir sie wie folgt:

<HEAD>
<STYLE type="text/css">
H1.myclass {border-width: 1; border: solid; text-align: center}
</STYLE>
</HEAD>
<BODY>
<H1 class="myclass">Dieses H1 wird durch unsere Formatvorlage ver]ndert.</H1>
<H1>Dieses ist nicht von unserer Formatvorlage betroffen.</H1>
</BODY>

Zuletzt, um den Geltungsbereich der Formatierungsinformationen auf eine einzige Instanz von
H1 zu begrenzen, wird das id-Attribut gesetzt:

<HEAD>
<STYLE type="text/css">
#myid {border-width: 1; border: solid; text-align: center}
</STYLE>
</HEAD>
<BODY>
<H1 class="myclass">Dieses H1 ist nicht betroffen</H1>
<H1 id="myid">Diese H1 ist vom Stil betroffen</H1>
<H1>Dieses H1 ist nicht betroffen</H1>
</BODY>

Auch wenn Formatierungsinformationen fr fast jedes HTML-Element angegeben werden k=n-
nen, sind zwei Elemente, DIV und SPAN, dadurch besonders wertvoll, dass sie keiner darstel-
lungsrelevanten Semantik unterliegen (außer Block-Level versus inzeilig). Werden sie mit Style-
sheets kombiniert, erlauben diese Elemente dem Benutzer, HTML unbegrenzt zu erweitern,
speziell wenn sie mit den Attributen class und id verwendet werden.
Im folgenden Beispiel verwenden wir das Element SPAN, um das Schriftformat der ersten Worte
eines Absatzes auf klein geschriebene Großbuchstaben (small caps) zu setzen:

<HEAD>
<STYLE type="text/css">
SPAN.sc-ex { font-variant: small-caps }
</STYLE>
</HEAD>
<BODY>
<P><SPAN class="sc-ex">Die ersten</SPAN> Worte
dieses Absatzes sind klein geschriebene Großbuchstaben.
</BODY>

HTML-Dokumente formatieren < 223 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Im folgenden Beispiel verwenden wir DIV und das class-Attribut, um die Textausrichtung fr
diejenigen Abs@tze festzulegen, die den zusammenfassenden Abschnitt eines wissenschaftlichen
Beitrags ausmachen. Diese Formatierungsinformation kann fr andere zusammenfassende
Abschnitte wiederverwendet werden, indem das class-Attribut an anderer Stelle im Doku-
Die HTML 4.01- Spezifikation

ment gesetzt wird.

<HEAD>
<STYLE type="text/css">
DIV.zusammenfassung { text-align: justify }
</STYLE>
</HEAD>
<BODY>
<DIV class="zusammenfassung">
<P>Die Produktgruppe Chieftain ist unser Marktgewinner fUr
das kommende Jahr. Dieser Bericht legt dar, wie Chieftain gegen
wettbewerbende Produkte plaziert wird.

<P>Chieftain ersetzt den Commander-Bereich, der bis


auf Weiteres auf der Preisliste bestehen bleibt.
</DIV>
</BODY>

14.2.4 Medientypen

HTML gestattet es Autoren, Dokumente zu entwerfen, die sich die Charakteristika der Medien
zunutze machen, auf denen sie dargestellt werden sollen (zum Beispiel graphische Displays,
Fernsehbildschirme, portable Ger@te, sprachbasierte Browser, Blindenschrift darstellende Tast-
ger@te usw.). Durch die Angabe des Attributs media gestatten Autoren den Benutzerprogram-
men, Stylesheets selektiv zu laden und anzuwenden. Bitte beachten Sie die Liste der anerkann-
ten Medien-Deskriptoren (siehe Abschnitt 6.13).
Die folgenden Beispiel-Deklarationen gelten fr H1-Elemente. Bei einer Projektion auf einem
Gesch@ftstreffen werden alle Instanzen blau dargestellt werden. Beim Druck werden sie alle
zentriert werden.

<HEAD>
<STYLE type="text/css" media="projection">
H1 { color: blue}
</STYLE>

<STYLE type="text/css" media="print">


H1 { text-align: center }
</STYLE>

Anmerkung der bersetzer: Der Medientyp „projection“ wird zum Beispiel vom
Opera-Browser verstanden. Damit ist eine PowerPoint-@hnliche Pr@sentation auf Basis
von HTML-Dateien m=glich. Sie eignen sich gleichzeitig fr den „normalen“ Einsatz im
Web (letzteres wird dann natrlich ber CSS-Anweisungen fr „screen“ formatiert).

< 224 > Stylesheets


Page size: 168,00 x 240,00 mm

Dieses Beispiel fgt Ankern Soundeffekte hinzu, wenn eine Sprachausgabe verwendet wird:

<STYLE type="text/css" media="aural">


A { cue-before: uri(bell.aiff); cue-after: uri(dong.wav)}
</STYLE>

Die HTML 4.01- Spezifikation


</HEAD>

Anmerkung der bersetzer: Details ber akustische Stylesheets enth@lt das


Kapitel 19 der CSS2-Spezifikation.

Mediensteuerung ist besonders interessant, wenn sie in Bezug auf externe Stylesheets verwen-
det wird. Benutzerprogramme k=nnen dadurch Zeit sparen, dass sie nur die relevanten Style-
sheets fr das aktuelle Ger@t aus dem Netz laden. Zum Beispiel k=nnen sprachbasierte
Browser den Download von Stylesheets vermeiden, die fr die optische Darstellung entworfen
worden sind. Beachten Sie den Abschnitt 14.4.1, „Medienabh@ngige Kaskaden“, fr weiterge-
hende Informationen.

14.3 Externe Stylesheets


Autoren k=nnen Stylesheets von HTML-Dokumenten trennen. Dies bietet mehrere Vorteile:
· Autoren und Verwalter von Web-Auftritten k=nnen Stylesheets ber viele Dokumente
(und Web-Auftritte) hinweg teilen.
· Autoren k=nnen das Stylesheet auswechseln, ohne dass Onderungen am Dokument not-
wendig werden.
· Benutzerprogramme k=nnen Stylesheets selektiv laden (abh@ngig von der Medienbeschrei-
bung).

14.3.1 Bevorzugte und alternative Stylesheets

HTML erlaubt Autoren, eine beliebige Anzahl externer Stylesheets mit einem Dokument zu
verknpfen. Die Stylesheet-Sprache definiert, wie sich mehrere externe Stylesheets gegenseitig
beeinflussen (zum Beispiel die CSS-Kaskadenregeln).
Autoren k=nnen eine beliebige Anzahl sich gegenseitig ausschließender Stylesheets angeben,
genannt alternative Stylesheets. Benutzer k=nnen das bevorzugte Stylesheet unter diesen
abh@ngig von ihren Benutzervorgaben w@hlen. Zum Beispiel kann ein Autor ein Stylesheet fr
kleine Displays angeben und ein anderes fr Benutzer mit verminderter Sehf@higkeit (zum Bei-
spiel große Schriftarten). Benutzerprogramme sollten Benutzern die Auswahl der alternativen
Stylesheets erm=glichen.
Der Autor kann angeben, dass eines der alternativen Stylesheets das bevorzugte ist. Benutzer-
programme sollten das bevorzugte Stylesheet des Autors anwenden, wenn der Benutzer keine
andere Alternative ausgew@hlt hat.
Autoren k=nnen mehrere alternative Stylesheets (eingeschlossen das bevorzugte Stylesheet
des Autors) unter einem einzigen Formatnamen zusammenfassen. Wenn der Benutzer eine
benannte Formatvorlage w@hlt, muss das Benutzerprogramm alle Stylesheets mit diesem

Externe Stylesheets < 225 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Namen anwenden. Benutzerprogramme drfen keine alternativen Stylesheets mit einem ande-
ren Formatnamen anwenden. Der Abschnitt „Aufruf externer Stylesheets“ erkl@rt, wie eine
Gruppe von Stylesheets benannt wird.
Autoren k=nnen auch best@ndige Stylesheets (persistent style sheets) angeben, die Benutzer-
Die HTML 4.01- Spezifikation

programme zus@tzlich zu jedem alternativen Stylesheet anwenden mssen.


Benutzerprogramme mssen Medien-Deskriptoren respektieren, wenn ein Stylesheet ange-
wendet wird.
Benutzerprogramme sollten Benutzern ebenfalls gestatten, die Stylesheets des Autors vollst@n-
dig zu ignorieren. In diesem Fall darf das Benutzerprogramm kein best@ndiges oder alternatives
Stylesheet verarbeiten.

14.3.2 Angabe externer Stylesheets

Autoren rufen externe Stylesheets mit den folgenden Attributen des Elements LINK auf:
· Setzen des Attributwertes von href auf den Ort der Stylesheet-Datei. Der Wert des Attri-
buts href ist ein URI.
· Setzen des Attributwertes von type, um die Sprache der referenzierten Stylesheet-Datei
anzugeben. Das Benutzerprogramm kann so den Download eines Stylesheets einer nicht
untersttzten Stylesheet-Sprache vermeiden.
·· Die Angabe, ob das Stylesheet st@ndig, bevorzugt oder alternativ ist:
Um einem Stylesheet den Status „st@ndig“ zuzuweisen, wird das Attribut rel auf „style-
sheet“ gesetzt und das Attribut title nicht angegeben.
· Um einem Stylesheet den Status „bevorzugt“ zuzuweisen, wird das Attribut rel auf
„stylesheet“ gesetzt und das Stylesheet mit dem Attribut title benannt.
· Um ein Stylesheet alternativ zu machen, wird das Attribut rel auf „alternate stylesheet“
gesetzt und das Stylesheet mit dem Attribut title benannt.
Benutzerprogramme sollten Benutzern ein Mittel zur Verfgung stellen, sich die Liste der alter-
nativen Formate anzusehen und aus ihr zu w@hlen. Der Wert des Attributs title wird als
Name jeder Auswahlm=glichkeit empfohlen.
In diesem Beispiel geben wir zuerst ein best@ndiges Stylesheet an, das in der Datei mystyle.css
abgelegt ist:

<LINK href="mystyle.css" rel="stylesheet" type="text/css">

Die Angabe des Attributs title verwandelt dieses Stylesheet in das vom Autor bevorzugte
Stylesheet:

<LINK href="mystyle.css" title="compact" rel="stylesheet" type="text/css">

Der Zusatz des Schlsselworts „alternate“ zum Attribut rel verwandelt es in ein alternatives
Stylesheet:

<LINK href="mystyle.css" title="Medium" rel="alternate stylesheet" type="text/css">

< 226 > Stylesheets


Page size: 168,00 x 240,00 mm

Anmerkung der bersetzer: Betrachten Sie den folgenden Ausschnitt aus einer
(X)HTML-Datei:

Die HTML 4.01- Spezifikation


<link href="standard.css"
rel="stylesheet"
type="text/css" />

<link href="gross.css"
title="Große Schrift"
rel="stylesheet"
type="text/css" />

<link href="kontrast.css"
title="kontrastreiches Layout"
rel="alternate stylesheet"
type="text/css" />

Wird diese Datei im Mozilla betrachtet, erlaubt der Browser ber ein Men die Aus-
wahl der gewnschten Formatierung (siehe Abbildung). Das unbenannte Stylesheet (das
best@ndige Stylesheet) wird in der englischen Version als „Basic Page Style“ bezeichnet.
Dessen Formatierungsregeln werden in jedem Fall angewendet. Außerdem ist das
bevorzugte Stylesheet ausgew@hlt (in diesem Fall „Große Schrift“) und die darin fest-
gelegte Formatierung gilt zus@tzlich.

Weitere Informationen ber externe Stylesheets finden Sie in Abschnitt 12.3.2, „Links und
externe Stylesheets“.
Autoren k=nnen auch das Element META verwenden, um das bevorzugte Stylesheet eines Doku-
ments zu bestimmen. Um zum Beispiel das Stylesheet „compact“ als bevorzugt zu bestimmen
(siehe vorausgegangenes Beispiel), k=nnen Autoren die folgende Zeile im HEAD einfgen:

<META http-equiv="Default-Style" content="compact">

Externe Stylesheets < 227 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Das bevorzugte Stylesheet kann ebenso mit Hilfe eines HTTP-Headers bestimmt werden. Die
META-Deklaration oben ist @quivalent zu dem HTTP-Header:

Default-Style: "compact"
Die HTML 4.01- Spezifikation

Geben zwei oder mehr META-Deklarationen oder HTTP-Header das bevorzugte Stylesheet an,
hat die letzte Angabe Vorrang. Aus diesem Grund wird erwartet, dass HTTP-Header vor dem
HEAD des Dokuments angegeben werden.
Geben zwei oder mehr LINK-Elemente das bevorzugte Stylesheet an, hat das erste den Vor-
rang.
Bevorzugte Stylesheets, die mit META oder mit HTTP-Headern bestimmt werden, haben Vor-
rang vor denen, die ber das Element LINK bestimmt werden.

14.4 Cascading Style Sheets


Kaskadierende Stylesheet-Sprachen wie CSS gestatten die Vermischung von Formatierungs-
informationen aus mehreren Quellen. Jedoch untersttzen nicht alle Stylesheet-Sprachen diese
Kaskade. Um eine Kaskade zu definieren, geben Autoren eine Reihe von LINK- und/oder STYLE-
Elementen an. Die Formatierungsinformationen werden in der Reihenfolge kaskadiert, in der
die Elemente im HEAD erscheinen.

Anmerkung: Diese Spezifikation gibt nicht an, wie Stylesheets von unterschiedlichen Formatierungs-
sprachen kaskadieren. Autoren sollten Stylesheet-Sprachen nicht vermischen. n
Im folgenden Beispiel geben wir zwei alternative Stylesheets mit Namen „compact“ an. W@hlt
der Benutzer das Format „compact“, muss das Benutzerprogramm die beiden externen Style-
sheets sowie das best@ndige Stylesheet „common.css“ anwenden. W@hlt der Benutzer das For-
mat „big print“, werden nur das alternative Stylesheet „bigprint.css“ und das best@ndige „com-
mon.css“ verarbeitet.

<LINK rel="alternate stylesheet" title="compact" href="small-base.css"


type="text/css">
<LINK rel="alternate stylesheet" title="compact" href="small-extras.css"
type="text/css">
<LINK rel="alternate stylesheet" title="big print" href="bigprint.css"
type="text/css">
<LINK rel="stylesheet" href="common.css" type="text/css">

Hier das Beispiel einer Kaskade. Es wird sowohl das LINK- als auch das STYLE-Element einbezo-
gen.

<LINK rel="stylesheet" href="corporate.css" type="text/css">


<LINK rel="stylesheet" href="techreport.css" type="text/css">
<STYLE type="text/css">
p.special { color: rgb(230, 100, 180) }
</STYLE>

< 228 > Stylesheets


Page size: 168,00 x 240,00 mm

14.4.1 Medienabh.ngige Kaskaden

Eine Kaskade kann Stylesheets einschließen, die fr verschiedene Medien geeignet sind. Sowohl
LINK als auch STYLE k=nnen das Attribut media verwenden. Das Benutzerprogramm ist dann

Die HTML 4.01- Spezifikation


dafr verantwortlich, die Stylesheets herauszufiltern, die fr das aktuelle Medium nicht passend
sind.
Im folgenden Beispiel definieren wir eine Kaskade, bei der das Stylesheet „corporate“ in ver-
schiedenen Versionen bereitgestellt wird: eine fr die Druckausgabe, eine fr die Bildschirm-
ausgabe und eine fr sprachbasierte Browser (ntzlich, sagen wir mal, um E-Mails im Auto zu
„lesen“). Das Stylesheet „techreport“ gilt fr alle Medien. Die Farbregel des STYLE-Elements
wird fr die Druck- und Bildschirmausgabe verwendet, jedoch nicht fr die Sprachausgabe.

<LINK rel="stylesheet" media="aural" href="corporate-aural.css" type="text/css">


<LINK rel="stylesheet" media="screen" href="corporate-screen.css" type="text/css">
<LINK rel="stylesheet" media="print" href="corporate-print.css" type="text/css">
<LINK rel="stylesheet" href="techreport.css" type="text/css">
<STYLE media="screen, print" type="text/css">
p.special { color: rgb(230, 100, 180) }
</STYLE>

14.4.2 Vererbung und Kaskadierung

M=chte das Benutzerprogramm ein Dokument darstellen, muss es Werte fr die Formateigen-
schaften finden, zum Beispiel fr die Schriftfamilie, Schriftart, -gr=ße, Zeilenh=he, Textfarbe
und so weiter. Der genaue Mechanismus ist abh@ngig von der Stylesheet-Sprache. Die folgende
Beschreibung ist jedoch allgemein anwendbar:
Der Mechanismus der Kaskade wird angewendet, wenn mehrere Formatierungsregeln direkt
fr ein Element gelten. Der Mechanismus gestattet es dem Benutzerprogramm, die Regeln nach
Spezifit@t zu sortieren, um festzustellen, welche Regel angewendet werden soll. Wird keine
Regel gefunden, h@ngt der weitere Ablauf davon ab, ob die Formateigenschaft vererbt werden
kann oder nicht. Nicht alle Eigenschaften k=nnen vererbt werden. Fr diese Eigenschaften bie-
tet die Stylesheet-Sprache voreingestellte Werte an, die angewendet werden, wenn keine
expliziten Regeln fr ein bestimmtes Element angegeben sind.
Kann die Eigenschaft vererbt werden, untersucht das Benutzerprogramm das n@chste umschlie-
ßende Element, um zu sehen, ob eine Regel dafr existiert. Dieser Vorgang wird fortgefhrt bis
eine geeignete Regel gefunden wird. Dieser Mechanismus erlaubt die kompakte Angabe von
Stylesheets. Zum Beispiel k=nnen Autoren die Schriftart fr alle Elemente innerhalb des BODY
durch eine einzige Regel festlegen, die fr das Element BODY gilt.

14.5 Formatierungsangaben vor Benutzerprogrammen


verbergen
Einige Stylesheet-Sprachen untersttzen eine Syntax, die Autoren erlaubt, den Inhalt eines
STYLE-Elements vor nicht konformen Benutzerprogrammen zu verbergen.
Dieses Beispiel zeigt fr CSS, wie der Inhalt eines STYLE-Elements auskommentiert wird, um zu
gew@hrleisten, dass @ltere, nicht konforme Benutzerprogramme diesen Inhalt nicht als Text
darstellen.

Formatierungen von Benutzerprogrammen verbergen < 229 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

<STYLE type="text/css">
<!- -
H1 { color: red }
P { color: blue}
- ->
Die HTML 4.01- Spezifikation

</STYLE>

14.6 Mit HTTP-Headern auf Stylesheets verweisen


Dieser Abschnitt gilt nur fr Benutzerprogramme, die konform zu HTTP-Versionen sind, die
ein Link Header-Feld definieren. Beachten Sie, dass HTTP 1.1 wie definiert in [RFC2616] kein
Link Header-Feld einschließt (siehe Abschnitt 19.6.3).
Administratoren von Web-Servern m=gen es als angenehm empfinden, einen Server so zu kon-
figurieren, dass ein Stylesheet auf eine Gruppe von mehreren Seiten angewandt wird. Der
HTTP Link Header hat den gleichen Effekt wie ein LINK-Element mit den gleichen Attributen
und Werten. Mehrere Link Header haben die Wirkung wie mehrere LINK-Elemente, die in der
gleichen Reihenfolge erscheinen. Zum Beispiel entspricht

Link: <http://www.acme.com/corporate.css>; REL=stylesheet

der Angabe

<LINK rel="stylesheet" href="http://www.acme.com/corporate.css">

Es ist m=glich, mehrere alternative Formate mit Hilfe mehrerer Link Header anzugeben, und
dann das rel-Attribut zur Bestimmung des voreingestellten Formats heranzuziehen.

Im folgenden Beispiel wird „compact“ als Voreinstellung verwendet, weil das Schlsselwort
„alternate“ fr das rel-Attribut nicht gesetzt ist.

Link: <compact.css>; rel="stylesheet"; title="compact"


Link: <bigprint.css>; rel="alternate stylesheet"; title="big print"

Dies sollte ebenfalls funktionieren, wenn HTML-Dokumente per E-Mail verschickt werden.
Einige E-Mail-Programme k=nnen die Reihenfolge von [RFC822]-Headern ver@ndern. Um sich
dagegen zu schtzen, dass die Kaskadierungsreihenfolge fr Stylesheets berhrt wird, die ber
Link Header angegeben werden, k=nnen Autoren die Header-Verkettung verwenden, um meh-
rere Instanzen eines Header-Feldes zusammenzulegen. Die Anfhrungszeichen sind nur not-
wendig, wenn der Attributwert Leerraum enth@lt. Verwenden Sie SGML-Entities, um Zeichen
zu referenzieren, die ansonsten in einem HTTP- oder E-Mail-Header nicht gestattet w@ren,
oder die m=glicherweise auf dem Weg durch Gateways ver@ndert werden k=nnten.

Anmerkung der bersetzer: Das Versenden von E-Mail im HTML-Format ist


sehr umstritten. Viele Menschen @rgern sich ber kleine Schriften, schlechten Kontrast
und @hnliches in Mails. Viele ernstzunehmende Sicherheitslcken in Mail-Programmen
werden erst durch HTML-Mails und darin eingebettete Programme zu einem Problem.
An dieser Stelle wollen wir kein Urteil fr oder gegen HTML-Mails f@llen; nur eine Bitte:
schicken Sie uns keine HTML-Mails! ;-)

< 230 > Stylesheets


Page size: 168,00 x 240,00 mm

Die Elemente LINK und META, die durch HTTP-Header angegeben werden, sind so definiert, dass
sie vor irgendeinem expliziten LINK- und META-Element im Dokumentkopf angegeben werden
mssen.

Die HTML 4.01- Spezifikation


15 Ausrichtung, Schriftarten und
horizontale Linien
Dieser Abschnitt der Spezifikation er=rtert einige HTML-Elemente und -Attribute, die fr die
optische Formatierung von Elementen verwendet werden k=nnen. Viele von ihnen sind missbil-
ligt.

15.1 Formatierung
15.1.1 Hintergrundfarbe

Attributdefinitionen

bgcolor = color [CI]


Missbilligt. Dieses Attribut weist dem Dokumentrumpf oder Tabellenzellen eine Hinter-
grundfarbe zu.

Dieses Attribut weist der Zeichenfl@che des Dokumentrumpfes (das BODY-Element) oder Tabel-
len (die Elemente TABLE, TR, TH und TD) die Hintergrundfarbe zu. Fr das Element BODY k=nnen
zus@tzliche Attribute zur Angabe der Textfarbe verwendet werden.
Dieses Attribut wird zu Gunsten der Stylesheets, die Angaben zur Farbe des Hintergrunds
machen, missbilligt.

15.1.2 Ausrichtung

Es ist m=glich, Blockelemente (Tabellen, Bilder, Objekte, Abs@tze usw.) mit Hilfe des Attributs
align auf der Zeichenfl@che auszurichten. Auch wenn dieses Attribut vielen HTML-Elementen
zugewiesen werden kann, unterscheiden sich die m=glichen Werte von Element zu Element.
Hier er=rtern wir nur die Bedeutung des align-Attributs in Bezug auf Text.

Attributdefinitionen

align = left|center|right|justify [CI]


Missbilligt. Dieses Attribut gibt die horizontale Ausrichtung des Elements in Bezug auf den
umgebenden Kontext an. M=gliche Werte:
·· left: Textzeilen werden links ausgerichtet.
center: Textzeilen werden zentriert.

·· right: Textzeilen werden rechts ausgerichtet.


justify: Textzeilen werden an beiden Seiten ausgerichtet.

Ausrichtung, Schriftarten und horizontale Linien < 231 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Die Voreinstellung h@ngt von der Textflussrichtung ab. Fr Text, der von links nach rechts ver-
l@uft, ist die Voreinstellung align=left, w@hrend fr von rechts nach links verlaufenden Text die
Voreinstellung align=right ist.
Die HTML 4.01- Spezifikation

MISSBILLIGTES BEISPIEL:
Dieses Beispiel zentriert die berschrift auf der Zeichenfl@che.

<H1 align="center"> Wie Holz geschnitzt wird </H1> n

Mit CSS, zum Beispiel, kann der gleiche Effekt wie folgt erzielt werden:

<HEAD>
<TITLE>Wie Holz geschnitzt wird</TITLE>
<STYLE type="text/css">
H1 { text-align: center}
</STYLE>
<BODY>
<H1> Wie Holz geschnitzt wird </H1>

Beachten Sie, dass dies alle H1-Deklarationen ausrichten wrde. Sie k=nnen den Geltungs-
bereich der Formatinformation durch Angabe des Attributs class im Element reduzieren:

<HEAD>
<TITLE>Wie Holz geschnitzt wird</TITLE>
<STYLE type="text/css">
H1.wood {text-align: center}
</STYLE>
<BODY>
<H1 class="wood"> Wie Holz geschnitzt wird </H1>

Anmerkung der bersetzer: class ist natrlich nur eine M=glichkeit, den Gel-
tungsbereich einzuschr@nken; id w@re zum Beispiel eine andere. Stylesheets bieten noch
weitaus mehr M=glichkeiten. Mehr dazu finden in Kapitel 5 der ebenfalls in diesem Buch in
deutscher bersetzung zu findenden Spezifikation der „Cascading Style Sheets, level 2“.

MISSBILLIGTES BEISPIEL:
Um einen Absatz mit dem HTML-Attribut align rechts auf der Zeichenfl@che auszurichten, zie-
hen Sie dies in Betracht:

<P align="right">...viel Text in einem Absatz... n

Dasselbe wrde mit CSS so aussehen:

<HEAD>
<TITLE>Wie Holz geschnitzt wird</TITLE>
<STYLE type="text/css">
P.mypar {text-align: right}
</STYLE>
<BODY>

< 232 > Ausrichtung, Schriftarten und horizontale Linien


Page size: 168,00 x 240,00 mm

<P class="mypar">...viel Text in einem Absatz...

MISSBILLIGTES BEISPIEL:
Um mehrere Abs@tze rechts auszurichten, fassen Sie diese mit dem DIV-Element zusammen:

Die HTML 4.01- Spezifikation


<DIV align="right">
<P>...Text im ersten Absatz...
<P>...Text im zweiten Absatz...
<P>...Text im dritten Absatz...
</DIV> n

In CSS wird die Eigenschaft zur Textausrichtung vom Elternelement vererbt, weshalb Sie Fol-
gendes verwenden k=nnen:

<HEAD>
<TITLE>Wie Holz geschnitzt wird</TITLE>
<STYLE type="text/css">
DIV.mypars {text-align: right}
</STYLE>
<BODY>
<DIV class="mypars">
<P>...Text im ersten Absatz...
<P>...Text im zweiten Absatz...
<P>...Text im dritten Absatz...
</DIV>

Um das gesamte Dokument mit CSS zu zentrieren:

<HEAD>
<TITLE>Wie Holz geschnitzt wird</TITLE>
<STYLE type="text/css">
BODY {text-align: center}
</STYLE>
<BODY>
...Der BODY ist zentriert...
</BODY>

Das Element CENTER ist @quivalent zur Angabe des Elements DIV mit dem auf „center“ gesetzten
Attribut align. Das Element CENTER ist missbilligt.

15.1.3 Umflossene Objekte

Bilder und Objekte k=nnen direkt im Textfluss erscheinen oder zu einem Rand der Seite flie-
ßen und damit zeitweise die R@nder des Texts ver@ndern, der auf beiden Seiten das Objekt
umfließen kann.

Ein Objekt fließen lassen


Das Attribut align fr Objekte, Bilder, Tabellen, Frames usw. veranlasst das Objekt zum linken
oder rechten Rand hin zu fließen. Umflossene Objekte beginnen im Allgemeinen mit einer
neuen Zeile. Dieses Attribut verwendet die folgenden Werte:

Formatierung < 233 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

· left: Richtet das Objekt am aktuellen linken Rand aus. Nachfolgender Text fließt entlang
der rechten Seite des Objekts.
· right: Richtet das Objekt am aktuellen rechten Rand aus. Nachfolgender Text fließt entlang
der linken Seite des Objekts.
Die HTML 4.01- Spezifikation

Anmerkung der bersetzer: Mit „Frames“ ist hier das Element IFRAME gemeint.
Nur dafr kann das align-Attribut gesetzt werden, denn nur dafr kann eine Ausrich-
tung Sinn machen.

MISSBILLIGTES BEISPIEL:
Das folgende Beispiel zeigt, wie ein IMG-Element am aktuellen linken Rand der Zeichenfl@che
ausgerichtet wird.

<IMG align="left" src="http://foo.com/animage.gif" alt="my boat"> n

Einige Ausrichtungsattribute gestatten auch den Wert center, der kein Fließen verursacht, aber
das Objekt innerhalb der aktuellen R@nder ausrichtet. Fr P und DIV jedenfalls bewirkt der
Wert center, dass der Inhalt des Elements zentriert wird.

Text um ein Objekt fließen lassen


Ein weiteres Attribut, definiert fr das Element BR, kontrolliert den Textfluss um das umflos-
sene Objekt herum.

Attributdefinitionen

clear = none|left|right|all [CI]


Missbilligt. Gibt an, an welcher Stelle in einem visuellen Browser die n@chste Zeile nach
einem von diesem Element verursachten Zeilenumbruch erscheinen soll. Dieses Attribut
bercksichtigt umflossene Objekte (Bilder, Tabellen usw.). M=gliche Werte:
·· none: Die n@chste Zeile beginnt normal. Das ist die Voreinstellung.
left: Die n@chste Zeile wird an der naheliegendsten Zeile unter irgendeinem umflosse-
nen Objekt am linken Rand beginnen.
· right: Die n@chste Zeile wird an der naheliegendsten Zeile unter irgendeinem umflos-
senen Objekt am rechten Rand beginnen.
· all: Die n@chste Zeile wird an der naheliegendsten Zeile unter irgendeinem umflosse-
nen Objekt an beiden R@ndern beginnen.

< 234 > Ausrichtung, Schriftarten und horizontale Linien


Page size: 168,00 x 240,00 mm

Stellen Sie sich das folgende visuelle Szenario vor, in dem der Text an der rechten Seite eines
Bildes fließt, bis eine Zeile durch ein BR umgebrochen wird:

********* -------

Die HTML 4.01- Spezifikation


| | -------
| image | --<BR>
| |
*********

Wird dem Attribut clear der Wert none zugewiesen, wird die auf BR folgende Zeile direkt unter
dem Attribut auf seiner rechten Seite beginnen:

********* -------
| | -------
| image | --<BR>
| | ------
*********

MISSBILLIGTES BEISPIEL:
Wird dem Attribut clear der Wert left oder all zugewiesen, wird die n@chste Zeile wie folgt
erscheinen:

********* -------
| | -------
| image | --<BR clear="left">
| |
*********
-----------------

Mit Stylesheets k=nnen Sie festlegen, dass alle Zeilenumbrche fr Objekte (Bilder, Tabellen
usw.), die gegen den linken Rand fließen, auf diese Weise verfahren. Mit CSS k=nnen Sie das auf
folgende Weise erreichen:

<STYLE type="text/css">
BR { clear: left }
</STYLE>

Um dieses Verhalten fr eine bestimmte Instanz des Elements BR anzugeben, k=nnenn Sie die
Stilinformation und das Attribut id kombinieren:

<HEAD>
...
<STYLE type="text/css">
BR#mybr { clear: left }
</STYLE>
</HEAD>
<BODY>
<P>...

Formatierung < 235 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

********* -------
| | -------
| table | --<BR id="mybr">
| |
*********
Die HTML 4.01- Spezifikation

-----------------
...
</BODY>

15.2 Schriftarten
Die folgenden HTML-Elemente geben Informationen zur Schriftart an. Auch wenn sie nicht alle
missbilligt sind, wird von ihrer Verwendung abgeraten; stattdessen sollten Stylesheets verwen-
det werden.

15.2.1 Elemente zur Angabe des Schriftstils: die Elemente TT, I, B,


BIG, SMALL, STRIKE, S und U

<!ENTITY % fontstyle
"TT | I | B | BIG | SMALL">
<!ELEMENT (%fontstyle;|%phrase;) - - (%inline;)*>
<!ATTLIST (%fontstyle;|%phrase;)
%attrs; - - %coreattrs, %i18n, %events - -
>

Start-Tag: erforderlich, End-Tag: erforderlich

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Elementtitel)
style (inzeilige Formatierungsinformation)

· onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,


onkeydown onkeyup (eingebettete Ereignisse)

Die Darstellung von Schriftstil-Elementen ist abh@ngig vom Benutzerprogramm. Das Folgende
ist nur eine informelle Beschreibung.

TT: Darstellung als Teletype oder Monospace.


I: Darstellung als kursiver Text.
B: Darstellung als fettgedruckter Text.
BIG: Darstellung in großer Schriftart.
SMALL: Darstellung in kleiner Schriftart.
STRIKE und S: Missbilligt. Darstellung als durchgestrichener Text.
U: Missbilligt. Darstellung als unterstrichener Text.

< 236 > Ausrichtung, Schriftarten und horizontale Linien


Page size: 168,00 x 240,00 mm

Der folgende Satz zeigt einige Textarten:

<P><b>fett</b>,
<i>kursiv</i>, <b><i>fett kursiv</i></b>, <tt>Teletype</tt> und
<big>großer</big> und <small>kleiner</small> Text.

Die HTML 4.01- Spezifikation


Diese Worte k=nnten wie folgt dargestellt werden:

Anmerkung der bersetzer: Die Verwendung der Elemente I, B und TT erbrigt


sich in den weitaus meisten Einsatzf@llen nicht erst, seit Stylesheets zur Verfgung ste-
hen. Das eigentliche Anliegen, das Autoren zum Beispiel dann verfolgen, wenn sie B ein-
setzen, ist bei n@herer Betrachtung nicht, eine Textpassage „fett“ darzustellen, sondern
sie deutlich zu betonen. Fettschrift ist lediglich das Mittel, mit dem die Betonung
erreicht werden soll. Dafr bietet HTML jedoch das fr den genannten Zweck deutlich
besser geeignete Element STRONG an. STRONG gibt im Gegensatz zu B eine Information
ber die Bedeutung der so ausgezeichneten Passage (starke Betonung), nicht nur ber
ihre visuelle Darstellung. Bedeutungsinformation kann auch von nicht visuellen Benut-
zerprogrammen dazu genutzt werden, eine passende Pr@sentation zu finden, w@hrend
„fett“ auf die visuelle Darstellung beschr@nkt bleibt.
Ganz analog verh@lt es sich mit I und TT, fr die in der Mehrzahl der im Web zu sehen-
den Anwendungsf@lle, deren Autoren besser EM und KBD verwendet h@tten. Leider
untersttzen eine Reihe von HTML-Editoren die Verbreitung dieser „Unsitte“, indem
sie B per Mausklick anbieten, STRONG aber in den Tiefen ihrer Mens verstecken.
Die g@ngigen visuellen Browser w@hlen bereits ohne Nutzung von Stylesheets zur visu-
ellen Kennzeichnung von STRONG, EM und KBD genau die Schriftstile, die mit B, I und TT
erreicht werden.
Ein kleines Beispiel soll das verdeutlichen:

<p><kbd>- - * * - - * * - -</kbd></p>
<dl>
</dt>Gedanken zum <strong>Nachdenken</strong>:</dt>
<dd>
<p>Leicht finden wir Freunde, die uns helfen;
schwer verdienen wir uns jene, die unsere Hilfe
brauchen.</p>
<p><em>Antoine de Saint-Exup&eacute;ry</em></p>
</dd>
</dl>
<p><tt>- - * * - - * * - -</tt></p>
<dl>
</dt>Gedanken zum <b>Nachdenken</b>:</dt>
<dd>
<p>Leicht finden wir Freunde, die uns helfen;
schwer verdienen wir uns jene, die unsere Hilfe

Schriftarten < 237 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

brauchen.</p>
<p><i>Antoine de Saint-Exup&eacute;ry</i></p>
</dd>
</dl>
Die HTML 4.01- Spezifikation

Hier die Darstellung im Mozilla-Browser:

Stylesheets k=nnen sehr viel mehr Schrifteffekte erzeugen. Das folgende Beispiel gibt einen
blauen, kursiven Text in einem Absatz mit Hilfe von CSS an:

<HEAD>
<STYLE type="text/css">
P#mypar {font-style: italic; color: blue}
</STYLE>
</HEAD>
<P id="mypar">...viel blauer kursiver Text...

Schriftformat-Elemente mssen richtig verschachtelt sein. Die Darstellung von verschachtelten


Schriftformat-Elementen ist abh@ngig vom Benutzerprogramm.

15.2.2 Schriftart ver.ndernde Elemente: FONT und BASEFONT

FONT und BASEFONT werden missbilligt.


Die formale Definition finden Sie in der Transitional DTD.

Attributdefinitionen

size = cdata [CN]


Missbilligt. Dieses Attribut weist der Schriftart die Gr=ße zu. M=gliche Werte:
· Eine ganze Zahl zwischen 1 und 7. Diese weist der Schriftart eine feste Gr=ße zu, deren
Darstellung vom Benutzerprogramm abh@ngt. Nicht alle Benutzerprogramme k=nnen
eventuell alle sieben Gr=ßen darstellen.

< 238 > Ausrichtung, Schriftarten und horizontale Linien


Page size: 168,00 x 240,00 mm

· Ein relativer Zuwachs der Schriftgr=ße. Der Wert +1 bedeutet eine Nummer gr=ßer,
der Wert -3 bedeutet drei Nummern kleiner. Alle Gr=ßen beziehen sich auf die Skala
von 1 bis 7.
color = color [CI]

Die HTML 4.01- Spezifikation


Missbilligt. Dieses Attribut weist dem Text die Farbe zu.
face = cdata [CI]
Missbilligt. Dieses Attribut definiert eine durch Kommata getrennte Liste mit Schriftart-
namen, die das Benutzerprogramm in Reihenfolge der Vorgabe suchen soll.

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

·· title (Elementtitel)
style (inzeilige Formatierungsinformation)

Das Element FONT @ndert die Schriftgr=ße und die Farbe fr den Text in seinem Inhalt.
Das Element BASEFONT weist die Grundschriftgr=ße zu (unter Verwendung des Attributs size).
Onderungen der Schriftgr=ße, die mit FONT erreicht werden, sind relativ zu der Grundschrift-
gr=ße, die von BASEFONT zugewiesen wurde. Wird BASEFONT nicht verwendet, ist die voreinge-
stellte Grundschriftgr=ße 3.

MISSBILLIGTES BEISPIEL:
Das folgende Beispiel wird die Unterschiede zwischen den sieben Schriftgr=ßen zeigen, die mit
FONT verfgbar sind:

<P><font size=1>size=1</font>
<font size=2>size=2</font>
<font size=3>size=3</font>
<font size=4>size=4</font>
<font size=5>size=5</font>
<font size=6>size=6</font>
<font size=7>size=7</font>

Dies k=nnte so dargestellt werden:

Schriftarten < 239 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Das folgende Beispiel zeigt, welche Auswirkungen es hat, wenn die Grundschriftgr=ße 3 mit
relativen Schriftgr=ßen ver@ndert wird:
Die HTML 4.01- Spezifikation

Die Grundschriftgr=ße gilt nicht fr berschriften, außer wenn sie mit Hilfe des FONT-Elements
mit einer relativen Schriftgr=ßen@nderung manipuliert werden.

15.3 Linien: das Element HR


<!ELEMENT HR - O EMPTY - - horizontal rule - ->
<!ATTLIST HR
%attrs; - - %coreattrs, %i18n, %events - -
>

Start-Tag: erforderlich, End-Tag: nicht gestattet

Attributdefinitionen

align = left|center|right [CI]


Missbilligt. Dieses Attribut gibt die horizontale Ausrichtung der Linie in Bezug auf den
umgebenden Kontext an. M=gliche Werte:
··left: Die Linie wird links ausgerichtet.
center: Die Linie wird zentriert.

·right: Die Linie wird rechts ausgerichtet.

Die Voreinstellung ist align=center.


noshade [CI]
Missbilligt. Wenn angegeben, fordert dieser Boolesche Wert, dass ein Benutzerprogramm
die Linie in einer durchgehenden Farbe anzeigt, statt in der traditionellen zweifarbigen
Form.
size = pixels [CI]
Missbilligt. Dieses Attribut gibt die H=he der Linie an. Die Voreinstellung fr diesen Wert
h@ngt vom Benutzerprogramm ab.
width = length [CI]
Missbilligt. Dieses Attribut gibt die Breite der Linie an. Die Voreinstellung ist 100%, zum
Beispiel erstreckt sich die Linie ber die ganze Zeichenfl@che.

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)

< 240 > Ausrichtung, Schriftarten und horizontale Linien


Page size: 168,00 x 240,00 mm

·· title (Elementtitel)
style (inzeilige Formatierungsinformation)

· onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,


onkeydown, onkeyup (eingebettete Ereignisse)

Die HTML 4.01- Spezifikation


Das Element HR erzeugt eine horizontale Linie zur Darstellung in visuellen Benutzerprogram-
men.
Die H=he des (vertikalen) Leerraums zwischen der Linie und dem umliegenden Inhalt sind
abh@ngig vom Benutzerprogramm.

MISSBILLIGTES BEISPIEL:
Dieses Beispiel zentriert die Linie und begrenzt sie auf die H@lfte der zur Verfgung stehenden
Breite zwischen den R@ndern. Die obere Linie hat die voreingestellte H=he, w@hrend den bei-
den unteren die H=he 5 zugewiesen ist. Die unterste Linie sollte in einer durchgehenden Farbe
ohne Schatteneffekt dargestellt werden:

<HR width="50%" align="center">


<HR size="5" width="50%" align="center">
<HR noshade size="5" width="50%" align="center">

Diese Linien k=nnten wie folgt dargestellt werden:

16 Frames
16.1 Einf-hrung in Frames
HTML-Frames gestatten Autoren die Darstellung von Dokumenten in mehreren Ansichten, die
aus unterschiedlichen Fenstern oder Unterfenstern bestehen k=nnen. Mehrere Ansichten bie-
ten dem Designer die M=glichkeit, bestimmte Informationen im Sichtfeld zu belassen, w@hrend
andere Ansichten gescrollt oder ersetzt werden k=nnen. Zum Beispiel kann in einem Fenster
ein Frame ein dauerhaft eingeblendetes Banner zeigen, ein zweiter kann ein Navigationsmen
enthalten und ein dritter das Hauptdokument, durch welches gescrollt werden kann, oder das
durch die Navigation im zweiten Frame ersetzt werden kann.

Frames < 241 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Hier ist ein einfaches Frame-Dokument:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"


"http://www.w3.org/TR/html4/frameset.dtd">
<HTML>
Die HTML 4.01- Spezifikation

<HEAD>
<TITLE>Ein einfaches Frameset-Dokument</TITLE>
</HEAD>
<FRAMESET cols="20%, 80%">
<FRAMESET rows="100, 200">
<FRAME src="inhalt_von_frame1.html">
<FRAME src="inhalt_von_frame2.gif">
</FRAMESET>
<FRAME src="inhalt_von_frame3.html">
<NOFRAMES>
<P>Dieses Frameset enth]lt:
<UL>
<LI><A href="inhalt_von_frame1.html">Pr]gnanter Inhalt</A>
<LI><IMG src="inhalt_von_frame2.gif" alt="Ein pr]gnantes Foto">
<LI><A href="inhalt_von_frame3.html">Anderer pr]gnanter Inhalt</A>
</UL>
</NOFRAMES>
</FRAMESET>
</HTML>

Kann das Benutzerprogramm keine Frames anzeigen oder ist es entsprechend konfiguriert,
dass es keine Frames anzeigen soll, wird es den Inhalt des Elements NOFRAMES darstellen.
Es k=nnte ein Frame-Layout wie dieses erzeugen:

< 242 > Frames


Page size: 168,00 x 240,00 mm

16.2 Frame-Layout
Ein HTML-Dokument, das ein Frame-Layout beschreibt (Frameset-Dokument genannt), hat ein
anderes Aussehen als ein HTML-Dokument ohne Frames. Ein normales Dokument hat einen

Die HTML 4.01- Spezifikation


Abschnitt HEAD und einen BODY. Ein Frameset-Dokument hat einen HEAD-Abschnitt und ein
FRAMESET statt des BODY.
Der FRAMESET-Abschnitt eines Dokuments gibt das Layout der Ansichten im Hauptfenster des
Benutzerprogramms an. Zus@tzlich kann der FRAMESET-Abschnitt ein NOFRAMES-Element enthal-
ten, das alternativen Inhalt fr Benutzerprogramme anbietet, die Frames nicht untersttzen
oder so konfiguriert sind, dass sie keine Frames darstellen.
Elemente, die normalerweise im BODY-Element erscheinen wrden, drfen nicht vor dem ersten
FRAMESET-Element stehen, sonst wird das FRAMESET ignoriert.

16.2.1 Das Element FRAMESET

<![ %HTML.Frameset; [
<!ELEMENT FRAMESET - - ((FRAMESET|FRAME)+ & NOFRAMES?) - - window subdivision- ->
<!ATTLIST FRAMESET
%coreattrs; - - id, class, style, title - -
rows %MultiLengths; #IMPLIED - - list of lengths,
default: 100% (1 row) - -
cols %MultiLengths; #IMPLIED - - list of lengths,
default: 100% (1 col) - -
onload %Script; #IMPLIED - - all the frames have been loaded - -
onunload %Script; #IMPLIED - - all the frames have been removed - -
>
]]>

Attributdefinitionen

rows = multi-length-list [CN]


Dieses Attribut gibt das Layout der horizontalen Frames an. Es ist eine durch Kommata
getrennte Liste von Pixelangaben, prozentualen und relativen L@ngen (lengths). Der Stan-
dardwert ist 100%, gleichbedeutend mit einer Zeile.
cols = multi-length-list [CN]
Dieses Attribut gibt das Layout der vertikalen Frames an. Es ist eine durch Kommata
getrennte Liste mit Pixelangaben, prozentualen und relativen L@ngen. Der Standardwert ist
100%, gleichbedeutend mit einer Spalte.

An anderer Stelle definierte Attribute


·· id, class (dokumentweite Identifikatoren)
title (Elementtitel)

·· style (inzeilige Formatierungsinformation)


onload, onunload (eingebettete Ereignisse)

Das Element FRAMESET legt das Layout des Hauptfensters mit rechteckigen Unterfenstern fest.

Frame-Layout < 243 >


Page size: 168,00 x 240,00 mm

<edition
    W3C.de>

Zeilen und Spalten


Die Angabe des Attributs rows definiert die Anzahl der horizontalen Unterfenster in einem
Frameset. Die Angabe des Attributs cols definiert die Anzahl der vertikalen Unterfenster. Zur
Erzeugung eines Gitters k=nnen beide Attribute gleichzeitig angegeben werden.
Die HTML 4.01- Spezifikation

Ist das Attribut rows nicht angegeben, erstreckt sich jede Spalte ber die volle L@nge der Seite.
Ist das Attribut cols nicht angegeben, erstreckt sich jede Zeile ber die gesamte Seitenbreite.
Ist keines der Attribute angegeben, nimmt der Frame genau die Fl@che der Seite ein.
Frames werden von links nach rechts fr Spalten und von oben nach unten fr Zeilen erzeugt.
Sind beide Attribute angegeben, werden die Ansichten von links nach rechts in der ersten Rei-
he, von links nach rechts in der zweiten Reihe und so weiter erzeugt.
Das erste Beispiel teilt den Bildschirm vertikal in zwei H@lften (d. h., es wird eine obere und
eine untere H@lfte erzeugt).

<FRAMESET rows="50%, 50%">


...der Rest der Definition...
</FRAMESET>

Anmerkung der bersetzer:

Das n@chste Beispiel erzeugt drei Spalten: die zweite hat eine festgelegte Breite von 250 Pixel