Addison Wesley - XML, XHTML, CSS & Co
Hochgeladen von
dsosicAddison Wesley - XML, XHTML, CSS & Co
Hochgeladen von
dsosic[Link] Seite i Mittwoch, 9.
April 2003 3:26 15
XHTML, CSS & Co.
<[Link]> Die W3C-Spezifikationen
für das Web-Publishing
[Link] Seite ii Mittwoch, 9. April 2003 3:26 15
<edition
[Link]>
Die edition [Link] 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
[Link].
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 [Link]
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)
[Link] Seite iii Mittwoch, 9. April 2003 3:26 15
<edition
Stefan Mintert (Hrsg.)
[Link]>
XHTML, CSS & Co.
<[Link]> 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
[Link] 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 <[Link] 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@[Link]
Korrektorat: Johannes Gerritsen, Emmerich-Elten
Satz: reemers publishing services gmbh, Krefeld, [Link]
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
[Link]>
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
[Link]>
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
[Link]>
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 ' 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
[Link]>
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
[Link]>
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
[Link]>
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
[Link]>
< Vorwort >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Endlich ist er da. Der zweite Band der edition [Link]. 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 [Link] 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 [Link] also Leseb"cher f"r jedermann?« – Nein, sicher nicht. Die
edition [Link] 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
[Link] 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 [Link] 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 [Link] 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
[Link]>
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 Zeilenumbr che 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 ([Link]). 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 [Link] 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
[Link]>
< Einleitung >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
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
[Link]>
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 [Link] 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 [Link]/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: [Link] [Link] [Link]
Thematische Einfhrung und berblick ber den Band < 25 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
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 [Link]
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 [Link] 80
Trying [Link]...
Connected to [Link].
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 [Link] 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“ ([Link]
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
[Link]>
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 [Link]
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: [Link] 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: [Link]
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
[Link]>
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]
[Link] [Link] [RFC3288]
[Link] [Link] [RFC3288]
[Link] [Link] [RFC-harold-beep-
[Link]]
[Link] [Link] [RFC-harold-beep-
[Link]]
urn Uniform Resource Names (siehe [Link] [RFC2141]
[Link]/assignments/urn-namespaces)
go go [RFC3368]
h323 H.323 [RFC-levin-iptel-
h323-url-scheme-
[Link]]
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="[Link] / 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: [Link] Deutsches Mitglied der ISO ist das Deutsche Institut f>r Nor-
mung e.V. (DIN, [Link] Die 0sterreichische Vertretung ist das @sterreichische Nor-
mungsinstitut (ON, [Link] und die Schweiz wird durch die Schweizerische Nor-
men-Vereinigung (SNV, [Link] vertreten. Im technischen Bereich muss neben der
ISO unbedingt die 40 Jahre fr"her gegr"ndete International Electrotechnical Commission (IEC,
[Link] 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:
[Link]
HyTime (ISO/IEC 10744)
Den Einstieg in die Hypermedia/Time-based Structuring Language findet man am besten auf
der HyTime Users' Group Home Page ([Link] 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 [Link]
[Link]/
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 [Link] 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 ([Link] oder [Link]
[Link]/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://
[Link]/NET/ISO+IEC.15445/[Link] zu finden.
Thematische Einfhrung und berblick ber den Band < 31 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
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 [Link] OASIS betreibt auch
das Portal [Link] unter der gleichnamigen Adresse [Link]
OASIS ist gemeinsam mit den Vereinten Nationen verantwortlich f"r das Projekt Electronic Busi-
ness XML ([Link]
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, [Link]
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. [Link]
xml-971215
Goldfarb97
Charles F. Goldfarb. The SGML History Niche, 1997. [Link]
[Link]
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. [Link]
[Link]/specs/[Link]
W3C7pt
Das World Wide Web Consortium (W3C) in sieben Punkten, 7bersetzung von Henning
Fischer, 6.4.2002. [Link]
W3CTR
W3C Technical Reports and Publications. [Link] Deutsche 7bersetzun-
gen siehe [Link]
XML10pt
W3C Communication Team. XML in 10 Punkten, 7bersetzung von Henning Fischer, 2002.
[Link]
XMLcat
Norman Walsh (editor). XML Catalogs, OASIS, 6. August 2001. [Link]
committees/entity/[Link]
XMLspec21
Guide to the W3C XML Specification ("XMLspec") DTD, Version 2.1. [Link]
[Link]/XML/1998/06/[Link]
Literatur < 33 >
Page size: 168,00 x 240,00 mm
Page size: 168,00 x 240,00 mm
<edition
[Link]>
A
< Die HTML 4.01-
Spezifikation >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
HTML 4.01-Spezifikation
Deutsche bersetzung
Die HTML 4.01- Spezifikation
Diese Version:
[Link]
Aktuelle Version:
[Link]
bersetzer:
Christine K hnel ( bersetzung, fachliche Kommentierung)
<kuehnel@[Link]>
Stefan Schumacher ( bersetzung, fachliche Kommentierung)
<sts@[Link]>
Stefan Mintert (Fachlektorat und fachliche Kommentierung)
Bei diesem Dokument handelt es sich um eine bersetzung eines W3C-Textes. Dieser
Text ist urheberrechtlich gesch tzt; bitte beachten Sie die nachfolgenden Hinweise des
Originaldokuments. Die Rechte an der bersetzung liegen bei den bersetzern und
dem Verlag Addison-Wesley. Die bersetzung hat keine durch das W3C legitimierte,
normative Wirkung. Das einzige maßgebliche Dokument ist das englische Original.
Bitte senden Sie Fehler und Korrekturen zur deutschen Fassung an die bersetzer.
Kommentare der bersetzer, die als solche gekennzeichnet sind, unterliegen dem
Urheberrecht der bersetzer. Sie sind nicht Bestandteil des Ursprungsdokuments.
Diese Ver=ffentlichung ist eine Vorver ffentlichung. Kein Teil dieses Textes darf kopiert
werden. Alle Rechte vorbehalten. Nach Abschluss der Arbeit wird das endg ltige
Dokument unter der oben angegebenen Adresse ver=ffentlicht. Die jetzige Ver=ffent-
lichung w@hrend der laufenden Arbeit dient zur Information von Interessierten und zur
Pr fung 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:
[Link]
(Textdatei [794Kb] [Link]
gzipptes Tar-Archiv der HTML-Dateien [371Kb] [Link]
html401-19991224/[Link],
Zip-Archiv der HTML-Dateien [405Kb] [Link]
html401-19991224/[Link],
gzippte Postscript-Datei [746Kb, 389 Seiten] [Link]
html401-19991224/[Link],
gzippte PDF-Datei [963Kb] [Link]
html401-19991224/[Link])
Aktuelle Version von HTML 4.01:
[Link]
< 36 > Die HTML 4.01- Spezifikation
Page size: 168,00 x 240,00 mm
Aktuelle Version von HTML 4:
[Link]
Aktuelle Version von HTML:
[Link]
Die HTML 4.01- Spezifikation
Vorherige Version von HTML 4.01:
[Link]
Vorherige HTML 4-Recommendation:
[Link]
Editoren:
Dave Raggett <dsr@[Link]>
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 f r 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]), unterst tzt HTML
4 mehr Multimedia-Erweiterungen, Skript-Sprachen, Stylesheets, bessere Druckfunktionen,
sowie zug@nglichere Dokumente f r 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 f r veraltet, obgleich das W3C diese Spezifikationen und ihre DTDs weiterhin
auf der Web-Site des W3C verf gbar machen wird.
Dieses Dokument wurde von Mitgliedern des W3C und anderen Interessierten gepr ft 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
[Link]>
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 Gr nden der R ckw@rtskompatibilit@t empfiehlt das W3C zus@tzlich, dass
Programme, die HTML 4 interpretieren, auch weiterhin HTML 3.2 und HTML 2.0 unterst t-
zen.
Informationen ber die n@chste Generation von HTML, die „Extensible HyperText Markup
Language“[XHTML], finden Sie bei der W3C HTML Activity ([Link] und
in der Liste der W3C Technical Reports ([Link]
Dieses Dokument wurde als Teil der W3C HTML Activity ([Link]
erstellt. Die Ziele der HTML Working Group ([Link] nur
fr Mitglieder: [Link] werden in der HTML Working Group
Charter ([Link] nur fr Mitglieder: [Link]
MemberAccess/) besprochen.
Eine Liste der aktuellen W3C-Recommendations und anderer technischer Dokumente ist
unter [Link] zu finden.
Sffentliche Diskussionen zu HTML-Gesichtspunkten werden in der Mailingliste www-
html@[Link] gef hrt (Archiv: www-html@[Link]).
Verf-gbare Sprachen
Die englische Version dieser Spezifikation ist die einzige normative Version. bersetzungen
dieses Dokuments finden Sie unter [Link]
Errata
Die Liste der bekannten Fehler in dieser Spezifikation ist verf gbar unter
[Link]
Bitte senden Sie Berichte ber Fehler in diesem Dokument an www-html-editor@[Link].
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 Einf hrung 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 d rfen 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 f r die Darstellung in mehreren Fenstern.
· Elemente, die Interaktivit@t mit einem HTML-Dokument erlauben, einschließlich For-
mulare f r Benutzereingaben und Skripte f r aktive Dokumente.
·· Die formale SGML-Definition von HTML:
Die SGML-Deklaration von HTML.
·· Drei DTDs: strict, transitional und frameset.
Die Liste der Zeichenreferenzen.
[Link]
Der erste Anhang enth@lt Informationen ber die Onderungen gegen ber 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 f r HTML 4 zu unterst tzen.
Referenzen
Eine Liste normativer und informeller Referenzen.
Indizes
Drei Indizes verschaffen dem Leser einen raschen Zugriff auf die Definitionen der Schl ssel-
konzepte, Elemente und Attribute.
1.2 Dokumentkonventionen
Dieses Dokument wurde f r 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
[Link]>
· 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 urspr ngliche 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 f r
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 f hrte, und an all diejenigen, die Vorschl@ge und Korrekturen eingebracht haben.
Vielen Dank an die Web Accessibility Initiative Task Force (WAI HC Group) f r ihre Arbeit
zur Verbesserung der Zug@nglichkeit in HTML und an T.V. Raman (Adobe) f r seine fr he
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 f r ihre gewissenhafte Bearbeitung dieses Dokuments, ihre konstruktiven
Kommentare und ihre harte Arbeit: John D. Burger (MITRE), Steve Byrne (JavaSoft), Martin J.
D rst (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) f r die genaue und zeitintensive Arbeit als Teilzeit-Editor und
f r die aufmerksame Leitung als Vorsitzender der HTML Working Group. Danke Dir, Sally
Khudairi (W3C) f r Deine unentbehrliche Arbeit bei der Erstellung der Presseinformationen.
Dank an David M. Abrahamson und Roger Price f r das sorgf@ltige Lesen der Spezifikation und
konstruktive Kommentare.
Dank an Jan K@rrman, dem Autor von html2ps ([Link] f r
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 geb rt 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 f r die Fehlerverfolgung zu dieser Version der Spezifikation.
1.4 Bemerkung zum Urheberrecht
Informationen zum Urheberrecht finden Sie in der W3C Intellectual Property Notice
([Link] der W3C Document Notice
([Link] und der W3C IPR
Software Notice ([Link]
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 verf gbar zu machen, st tzt sich das Web auf drei
Mechanismen:
1. Ein einheitliches Namensschema zum Lokalisieren von Ressourcen im Web (z. B. URIs)
2. Protokolle f r 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
[Link]>
2.1.1 Einf-hrung in URIs
Jede im Netz verf gbare 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 f r 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:
[Link]
Dieser URI kann folgendermaßen gelesen werden: Es gibt ein via HTTP-Protokoll verf gbares
Dokument (s. [RFC2616]), das sich auf dem Rechner [Link] befindet und ber den Pfad
„/TR“ erreichbar ist. Andere Schemata, die Ihnen in HTML-Dokumenten begegnen k=nnen,
enthalten „mailto“ f r Email und „ftp“ f r FTP.
Anmerkung der bersetzer: In gewissem Sinne ist dies kein so gutes Beispiel.
Zwar liefert der Web-Browser bei Eingabe von [Link] die gew nschte
Seite; wer aber genau hinsieht, stellt fest, dass die Adresse nach dem Laden anders lau-
tet: [Link] Der Schr@gstrich am Ende r hrt 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: [Link]
Connection: close
Content-Type: text/html; charset=iso-8859-1
Zu erkennen ist die Antwort „301 Moved Permanently“ und die neue Adresse „Loca-
tion: [Link] 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="[Link]
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 f r einen URI. Dieser weist auf die Mailbox eines Benutzers:
...dies ist Text...
Anregungen und Meinungen senden Sie bitte an
<A href="[Link] 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 gew nschten Ergebnis f hren 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 f r einen Anker (genannt Fragmentbezeichner). Zum Beispiel
zeigt dieser URI auf einen Anker namens section_2:
[Link]
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 f r die Aufl=sung relativer URIs nehmen wir an, wir h@tten den Basis-URI
„[Link] Der relative URI in folgender Auszeichnung eines
Hypertext-Links
<A href="[Link]">Suppliers</A>
Was ist das World Wide Web? < 43 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
w rde erweitert zum vollst@ndigen URI „[Link] w@h-
rend der relative URI in der folgenden Auszeichnung f r ein Bild
<IMG src="../icons/[Link]" alt="logo">
Die HTML 4.01- Spezifikation
aufgel=st w rde zum vollst@ndigen URI „[Link]
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 einzuf gen, (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 f r Transaktionen mit entfernten Diensten f r den Einsatz bei der Informa-
tionssuche, bei Reservierungen, bei Warenbestellungen usw. zu gestalten.
· Spreadsheets, Videoclips, Soundclips und andere Applikationen direkt in ihre Dokumente
einzuf gen.
2.2.1 Ein kurzer Abriss der Geschichte von HTML
HTML wurde urspr nglich 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 erbl hte 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 f r HTML einhalten. Das hat zur gemeinsamen
Arbeit an Spezifikationen f r 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, f hrten diese Entw rfe zur
bernahme einer Auswahl von neuen Features. Die Bem hungen 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 gegen ber 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 m ssen 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 f r 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 f r Stylesheets, Scripting, Frames, eingebundene
Objekte, verbesserte Unterst tzung f r von rechts nach links zu lesende Texte sowie Texte
mit unterschiedlichen Leserichtungen, reichhaltigere Tabellen und f r 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 f r HTML. Dies ist der weltweit umfassendste Standard zu Fragen
der Darstellung internationaler Zeichen, Leserichtung, Zeichensetzung und anderer Themen
bez glich der Sprachen der Welt.
HTML bietet jetzt weitreichendere Unterst tzung f r 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
[Link]>
N@heres dazu finden Sie auf der zugeh=rigen Web-Site unter [Link]
national/.
Die HTML 4.01- Spezifikation
2.3.2 [Link]
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 Bed rfnisse angepasst sind. HTML wurde darauf ausgelegt, Webseiten f r
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 f r 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.
·· Unterst tzung f r title- und das lang-Attribut bei allen Elementen.
Unterst tzung f r 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 m ssen 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 unterst tzt (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, f r Benutzerprogramme, die eine bestimmte Darstel-
lung nicht unterst tzen, eine Hierarchie alternativer Darstellungen vorzugeben.
2.3.5 Stylesheets
Stylesheets vereinfachen das HTML-Markup und entlasten HTML erheblich von der Verant-
wortung f r 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 f r 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 dar ber 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 f r 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 zur ckziehen. 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 ausf llen) und HTML als Werkzeug
verwenden, um Netz-Applikationen zu bauen.
Anmerkung der bersetzer: „Intelligent“ sind Formulare dann, wenn sie bereits
beim Ausf llen auf Eingaben des Benutzers reagieren, z. B. Werte auf Zul@ssigkeit hin
pr fen, 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 Pr fungen eingegebener Werte nicht ausschließlich durch clientseitige Skripte
HTML 4 < 47 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
erfolgen sollten. Ein Formular soll auch dann benutzbar sein, wenn Scripting nicht zur
Verf gung steht, sei es, weil der Browser Scripting generell oder f r die gew@hlte
Skriptsprache nicht unterst tzt, 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 w nschen, 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 [Link]
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 f r die Bedienung eines breiten Spektrums von Plattfor-
men, Medien usw. reduziert und die berarbeitung von Dokumenten erleichtert.
2.4.2 Allgemeine [Link] zum Web beachten
Um das Web zug@nglicher f r jedermann zu machen, insbesondere f r jene Personen mit
Behinderungen, sollten Autoren dar ber 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 daf r (z. B. das alt-Attribut, das accesskey-Attribut usw.)
Dar ber 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 nat rliche Spra-
che und die Leserichtung des Textes aufnehmen, dar ber, 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 f r 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 f hrt 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
Ausf hrungen ber SGML f r XHTML nicht mehr uneingeschr@nkt zutreffend. Aus die-
sem Grund finden Sie im Folgenden eine Reihe von Kommentaren, die die G ltigkeit
der Aussagen aus Sicht von XHTML korrigieren.
Ein einf hrender Artikel zum Thema SGML ist im Web unter [Link]
xml/ zu finden. An gleicher Stelle gibt es auch Einf hrungen in XML. Eine deutsche
bersetzung des XML-Standards ([Link] ist ebenso
wie eine deutsche bersetzung von XHTML ([Link]
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"
"[Link]
<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
[Link]>
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 f r Element- und Attributnamen verwenden; also <head> statt <HEAD>
usw.
Eine weitere Onderung besteht darin, dass in XHTML keine Tags weggelassen werden
d rfen. 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 ausgedr ckt 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 (f r die Beschreibung dieser drei Definitionen siehe Abschnitt 7.2, „HTML-Versions-
Information“) und eine Liste von Zeichenreferenzen.
Anmerkung der bersetzer: F r XHTML spielt das Konzept der SGML-Deklara-
tion keine Rolle mehr. Das liegt darin begr ndet, dass f r 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 r hrt 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 Unterst tzung 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 gew nsch-
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 f r 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
[Link]>
Anmerkung der bersetzer: Die Forderung, dass leere Elemente niemals einen
End-Tag besitzen d rfen, ist weder durch SGML noch (f r XHTML) durch XML begr n-
det. Es ist eine Festlegung dieser Spezifikation.
Die HTML 4.01- Spezifikation
Die nachfolgende Aussage bzgl. der Klein/Großschreibung gilt nicht mehr f r XHTML.
Auch die anschließenden Beispiele sind nur f r HTML, nicht jedoch f r 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 f r Elemente geltenden
Regeln (z. B. m ssen sie korrekt verschachtelt sein, ein End-Tag schließt zur ck 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 f r die falsch benutzte Terminologie: Nat rlich 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 f r 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 Anf hrungszei-
chen (ASCII dezimal 34) oder einfachen Anf hrungszeichen (ASCII dezimal 39) begrenzt wer-
den. Einfache Anf hrungszeichen k=nnen im Attributwert enthalten sein, wenn der Wert durch
doppelte Anf hrungszeichen begrenzt ist und umgekehrt. Autoren k=nnen auch Numerische
Zeichenreferenzen verwenden, die die doppelten (") und einfachen (') Anf hrungs-
zeichen repr@sentieren. F r doppelte Anf hrungszeichen d rfen Autoren auch die Zeichen-En-
tity-Referenz „"“ benutzen.
In bestimmten F@llen k=nnen Autoren den Wert eines Attributs ohne jegliche Anf hrungszei-
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, Anf hrungszeichen auch dann zu verwen-
den, wenn es m=glich ist, sie wegzulassen.
Anmerkung der bersetzer: Wir empfehlen die Anf hrungszeichen niemals weg-
zulassen. In XHTML ist das Weglassen nicht mehr zul@ssig. F r die Groß/Kleinschrei-
bung gilt das Gleiche wie f r 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
[Link]>
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 f r Zeichen, die in einem HTML-
Dokument enthalten sein k=nnen. Sie sind n tzlich f r 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:
·· „<“ steht f r das <-Zeichen.
„>“ steht f r das >-Zeichen.
·· „"“ steht f r das doppelte "-Zeichen.
„å“ (dezimal) steht f r den Buchstaben „a“ mit einem kleinen Kreis dar ber.
·· „И“ (dezimal) steht f r den kyrillischen Großbuchstaben „I“.
„水“ (hexadezimal) steht f r das chinesische Zeichen f r 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-Ausz ge in die Spezifi-
kation aufzunehmen, anstatt eine zwar besser zug@ngliche, aber daf r 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 Schl sselwort <!ENTITY % gefolgt vom Entity-
Namen, dann der in Anf hrungszeichen 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
[Link]>
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-Schl sselwort 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 daf r angelegt sind, keinen Inhalt zu haben, wer-
den Leere Elemente genannt. Das Inhaltsmodell f r so ein Element ist durch die Verwen-
dung des Schl sselwortes „EMPTY“ deklariert.
Anmerkung der bersetzer: Der zweite Punkt, der sich mit dem Weglassen von
Start- und/oder End-Tags besch@ftigt, ist f r 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> f r dieses Element erforderlich sind.
· Das Inhaltsmodell f r 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 f r die Regel, dass
der End-Tag weggelassen werden muss.
· Das „EMPTY“-Schl sselwort 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é's adventures of Tintin“ die Zeichen-Entity-Refe-
renz f r 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 ausdr ckt.
( ... )
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 m ssen in dieser Reihenfolge vorkommen.
A&B
A und B m ssen 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
[Link]>
<!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 & 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, m sste, um die gleiche Definition des Inhalts-
modells zu erzielen, eine explizite Definition ohne das Element A erfolgen. Hierzu
m sste also das Parameter-Entity %inline; umdefiniert werden, oder es k=nnte hier
nicht zum Einsatz kommen.
Enstprechend verbietet die folgende Elementtyp-Deklaration f r FORM verschachtelte Formulare:
<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM)>
3.3.4 Attributdeklarationen
Mit dem <!ATTLIST-Schl sselwort 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“ f r weitere Informationen zu
Typen von Attributwerten.
· Ob der Standardwert des Attributs implizit ist (Schl sselwert „#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 f r 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 f r das MAP-Element definiert. Das Attribut ist f r 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.
F r 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 f r 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
[Link]>
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 f r
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 f r ein Attribut zu dem Datentyp erwartet werden. Ohnlich wurden Entities f r
„%Color;“, „%Charset;“, „%Length;“, „%Pixels;“ usw. definiert
Boolesche Attribute
Einige Attribute spielen die Rolle boolescher Variablen (z. B. das selected-Attribut f r 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 Schl sselw=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 f r 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
[Link]>
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“). Einf hrende 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. Einf hrende Informationen ber SGML-Elemente finden
Sie im Abschnitt 3.3.3, „Elementdeklarationen“.
· Aus Gr nden 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]) unterst tzen.
Fehlerbedingungen
Empfehlungen f r Reaktionen auf Fehler finden Sie in den „Anmerkungen zu ung ltigen
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
zuk nftigen Versionen von HTML obsolet sein.
Aus Gr nden der Abw@rtskompatibilit@t sollten Benutzerprogramme auch weiterhin miss-
billigte Elemente unterst tzen.
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-Unterst tzung 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, f r dessen Unterst tzung durch ein Benut-
zerprogramm es keine Garantie gibt. Obsolete Elemente werden in dieser Spezifikation
nicht mehr definiert, sind jedoch aus historischen Gr nden 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 K rze 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 d rfen SGML-Verarbeitungsanweisungen (z. B. <?full volume>) oder
Kommentare nicht darstellen. F r weitere Informationen ber dieses und andere SGML-Featu-
res, die in HTML zul@ssig sein k=nnen, aber von Benutzerprogrammen weitgehend nicht unter-
st tzt werden, lesen Sie bitte den Abschnitt „SGML-Eigenschaften mit begrenzter Unterst t-
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 f r HTML-Dokumente ist folgendermaßen definiert:
Inhaltstyp-Name:
text
Inhalts-Sub-Typ-Name:
html
Erforderliche Parameter:
keine
Optionale Parameter:
charset
Dekodierungs-Einschr nkungen:
jede Dekodierung ist erlaubt
Sicherheits-Einschr nkungen:
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. G ltige Werte f r 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
[Link]>
5 [Link] 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 f r 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 (f r amerikanische Texte ausreichend) oder ISO-Latin-1 (f r die
meisten Westeurop@ischen Schriften) oder Mehr-Byte-Kodierungen, wie Unicode
(f r 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 f r „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 unterst tzen, 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 f r „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 f r 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 f r 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] f r 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 m ssen 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 f hren 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 nat r-
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 gen gt nicht f r 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 [Link]
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
[Link]>
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 m ssen
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 f r die meisten westeurop@ischen Sprachen), ISO-8859-5 (die die kyrillische
Schrift unterst tzt), SHIFT_JIS (eine japanische Kodierung), EUC-JP (eine andere japanische
Kodierung) and UTF-8 (eine Kodierung von ISO 10646, die eine unterschiedliche Bytezahl f r
verschiedene Zeichen nutzt). Die Namen f r 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
unterst tzen muss.
Konforme Benutzerprogramme (siehe Abschnitt 4.1) m ssen alle Zeichen in allen Zeichenko-
dierungen, die sie erkennen, korrekt auf ISO 10646 abbilden (oder sie m ssen sich verhalten,
als ob sie so arbeiten w rden).
Anmerkung der bersetzer: Die meistverbreitete Kodierung von deutschspra-
chigen Texten d rfte 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 nachdr cklich hingewiesen: Es gen gt
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 pr fen zu lassen: [Link]
[Link]/.
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
[Link]>
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 unterst tzt wird. Das Euro-Entity € d rfte 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 [Link]
[Link].
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
[Link] zu finden. Sobald es eine bersetzung gibt, wird sie
voraussichtlich unter [Link] 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 m ssen.
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 f r ein Dokument, das er anbietet, gilt?
Manche Server pr fen 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 f r 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) f hrt 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 d rfen Benutzerprogramme keinen Standardwert f r 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 Verf gung 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 f r ASCII-Zeichen stehen (mindestens bis das META-Ele-
ment gelesen wurde). META-Deklarationen sollten so fr h wie m=glich im HEAD-Element erschei-
nen.
F r 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 m ssen 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 f r „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 f r 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
[Link]>
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 f r die Browserfunktionalit@t tun und nicht f r
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. F r 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:
· å (dezimal) repr@sentiert den Buchstaben „a“ mit einem kleinen Kreis dar ber (z. B.
im Norwegischen benutzt).
·· å (hexadezimal) repr@sentiert dasselbe Zeichen.
Die HTML 4.01- Spezifikation
å (hexadezimal) repr@sentiert ebenso dasselbe Zeichen.
·· И (dezimal) repr@sentiert den kyrillischen Großbuchstaben „I“.
水 (hexadezimal) repr@sentiert das chinesische Zeichen f r „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
m ssen. Zum Beispiel verweist die Zeichen-Entity-Referenz å auf das kleine „a“ mit einem
Kreis dar ber; „å“ ist leichter zu merken als å.
HTML 4 definiert nicht f r alle Zeichen im Dokumentzeichensatz eine Zeichen-Entity-Referenz.
Zum Beispiel gibt es keine Zeichen-Entity-Referenz f r 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
Å auf ein anderes Zeichen (großes A mit Kreis) als å (kleines a mit Kreis).
Vier Zeichen-Entity-Referenzen verdienen besondere Beachtung, da sie oft verwendet werden,
um spezielle Zeichen zu vermeiden:
·· „<“ repr@sentiert das <-Zeichen.
„>“ repr@sentiert das >-Zeichen.
·· „&“ repr@sentiert das &-Zeichen.
„"“ repr@sentiert das "-Zeichen.
Autoren, die das „<“-Zeichen im Text einsetzen wollen, sollten „<“ (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 „>“
(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 Anf hrungszeichen stehenden Attributwerte auftaucht und ein Benutzerprogramm
darin f@lschlicherweise das Ende eines Tags (schließender Tag-Begrenzer) erkennt.
Autoren sollten „&“ (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 „&“ benutzen, da Zeichenreferenzen
in CDATA-Attributwerten erlaubt sind.
Einige Autoren verwenden die Zeichen-Entity-Referenze „"“, um doppelte Anf hrungs-
zeichen (") zu kodieren, weil dieses Zeichen zur Begrenzung von Attributwerten verwendet
werden kann.
Zeichenreferenzen < 71 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
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-
gedr ckt 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
f r 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.
Ein hrende Informationen dar ber, 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 dar ber, ob innerhalb seines Wertes
zwischen Groß- und Kleinschreibung unterschieden wird. Die Information zu Groß- bzw.
Kleinschreibung ist mit Hilfe folgender Schl ssel 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 Schl ssel f r 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 Schl ssel-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
Zeilenumbr che ignorieren
· Jeden Zeilenwechsel oder Tabulatorsprung durch ein einzelnes Leerzeichen ersetzen
Benutzerprogramme k=nnen f hrenden und nachfolgenden Leerraum (white space) in
CDATA-Attributwerten ignorieren (z. B. kann „ myval “ als „myval“ interpretiert werden).
Autoren sollten Attributwerte nicht mit f hrendem oder nachfolgendem Leerraum dekla-
rieren.
F r einige HTML 4-Attribute mit CDATA-Attributwerten erlegt die Spezifikation der Kol-
lektion f r das Attribut g ltiger Werte zus@tzliche Einschr@nkungen auf, die nicht durch die
DTD ausgedr ckt werden k=nnen.
Auch das STYLE- und SCRIPT-Element nutzen CDATA f r ihr Datenmodell; f r diese Ele-
mente m ssen Benutzerprogramme CDATA anders behandeln. Auszeichnungen und Enti-
ties m ssen 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 g ltigen Dokumenten w@re
das der End-Tag des Elements.
· ID- und NAME-tokens m ssen 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 m ssen mindestens eine Ziffer ([0-9]) enthalten.
Grunddatentypen in SGML < 73 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
6.3 Text-Zeichenfolgen
Mehrere Attribute (in der DTD: %Text;) nehmen Text auf, der so angelegt ist, dass er f r Men-
schen lesbar ist („human readable“). F r einf hrende 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="[Link]/"
title="
Wert des
"title-Attributes""
>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 f r 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;) f r 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
[Link]>
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 hinzuf gen 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 f r 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 Unterst tzung des [SRGB]-Farbmodells zusammen mit ICC-Farbprofilen d rften 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 f r 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. F r 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 verf gbaren horizontalen Platzes sein. Folglich bedeutet der Wert „50%“ die
H@lfte des verf gbaren 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 verf gbaren Platz unter den
relativen Maßen. Jedes relative Maß erh@lt einen Anteil des verf gbaren Platzes, der propor-
tional ist zu der dem „*“ vorausgehenden ganzen Zahl. Der Wert „*“ ist @quivalent zu „1*“.
Folglich werden, wenn 60 Pixel an Platz verf gbar 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.
F r 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 f r 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 m ssen Zeichenfolgen aus der
IANA-Registrierung sein (z. B. „euc-jp“) (s. [CHARSETS] f r eine komplette Liste).
Namen von Zeichenkodierungen unterscheiden nicht zwischen Groß- und Kleinschreibung.
Um die Zeichenkodierung einer externen Ressource zu bestimmen, m ssen Benutzerpro-
gramme die im Abschnitt 5.2.2, „Spezifizieren von Zeichenkodierungen“ angef hrten Schritte in
der vorgegebenen Reihenfolge ausf hren.
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. „&“) 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 f r ihre Definition g ltiger 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
[Link]>
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
gegen ber UTC voraus ist.
-hh:mm
weist darauf hin, dass es sich um eine lokale Zeit handelt, die hh Stunden und mm Minuten
gegen ber UTC zur ck ist.
Exakt die hier gezeigten Komponenten mit exakt dieser Interpunktion m ssen 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“ f r Sekunden benutzen (falls erforderlich analog f r 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 f r ein anderes Medium handelt.
Stylesheet
verweist auf externes Stylesheet. Details lesen Sie in Abschnitt 14.3, „Externe Stylesheets“.
F r 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 unterst tzen auch das Synonym „Previous“.
Contents
verweist auf ein Dokument, das als Inhaltsverzeichnis dient. Einige Benutzerprogramme
unterst tzen auch das Synonym ToC (von „Table of Contents“).
Index
verweist auf ein Dokument, das einen Index f r das aktuelle Dokument anbietet.
Glossary
verweist auf ein Dokument, das ein Glossar zu Ausdr cken 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 Schl ssel-
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
[Link]>
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 f r die Definition des Linktyps verwendeten Konventionen anzuf hren.
Siehe profile-Attribut des HEAD-Elements f r 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="[Link]" />
Hier wird eine CSS-Datei durch das link-Element im Kopf der HTML-Datei mit der
HTML-Datei verkn pft. Die anderen genannten Linktypen werden von den meisten
Browsern nicht unterst tzt. 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 f r nicht seitenorientierte Computer-Bildschirme.
tty
ist bestimmt f r Medien, die ein @quidistantes Zeichenraster verwenden, wie Teleprinter,
Terminals oder tragbare Ger@te mit eingeschr@nkten Dartsellungsf@higkeiten.
tv
ist bestimmt f r TV-@hnliche Ger@te (geringe Aufl=sung, Farben, begrenzte Scroll-M=glich-
keit).
projection
ist bestimmt f r Projektoren.
handheld
ist bestimmt f r Handheld-Ger@te (kleiner Bildschirm, monochrom, Rastergrafiken, geringe
Bandbreite).
print
ist bestimmt f r seitenweises undurchsichtiges Material und f r Dokumente, die am Bild-
schirm im Druckvorschau-Modus angesehen werden.
braille
ist bestimmt f r Braille-Leseger@te.
aural
ist bestimmt f r Sprach-Synthesizer.
all
ist geeignet f r alle Ger@te.
< 80 > HTML-Grunddatentypen
Page size: 168,00 x 240,00 mm
K nftige HTML-Versionen k=nnen neue Werte einf hren und parametrisierte Werte gestat-
ten. Um die Einf hrung dieser Erweiterungen zu erleichtern, m ssen 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 durchgef hrt. 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 d rfen
Skript-Daten nicht als HTML-Auszeichnung auswerten, sondern m ssen 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
[Link]>
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 d rfen. 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üß Gott“ unver@ndert, also mit unaufgel=stem Entity, wiedergibt
<SCRIPT type="text/javascript">
alert('Grüß Gott');
</SCRIPT>
<A href="[Link]
onclick="alert('Grüß Gott')"
>[Link]
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 d rfen 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 d rfen. 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 m ssen 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, Tabulaturspr nge 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 f r ein einfaches HTML-Dokument:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"[Link]
<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
[Link]>
7.2 HTML-Versionsinformation
Ein g ltiges HTML-Dokument gibt die im Dokument benutzte HTML-Version an. Die Doku-
menttyp-Deklaration benennt die f r das Dokument verwendete Dokumenttyp-Definition
Die HTML 4.01- Spezifikation
(DTD) (s. [ISO8879]).
HTML 4.01 spezifiziert drei DTDs, deshalb m ssen Autoren eine der folgenden Dokumenttyp-
Deklarationen in ihre Dokumente aufnehmen. Die DTDs unterscheiden sich in den Elementen,
die sie unterst tzen.
· Die HTML 4.01 Strict DTD beinhaltet alle Elemente und Attribute, die nicht missbilligt
wurden und nicht in Frameset-Dokumenten auftreten. F r Dokumente, die diese DTD
benutzen, verwenden Sie die Dokumenttyp-Deklaration:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"[Link]
· 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).
F r Dokumente, die diese DTD benutzen, verwenden Sie die Dokumenttyp-Deklaration:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"[Link]
· Die HTML 4.01 Frameset DTD beinhaltet alles aus der Transitional DTD und zus@tzlich
Frames. F r Dokumente, die diese DTD benutzen, verwenden Sie die Dokumenttyp-Dekla-
ration:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"[Link]
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 f r HTML 4:
·· „[Link]“ – Standard-Strict-DTD
„[Link]“ – loose DTD
·· „[Link]“ – DTD f r Frameset-Dokumente
„[Link]“ – Latin-1-Entities
·· „[Link]“ – Symbol-Entities
„[Link]“ – 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 daf r richtet
(siehe [OASISOPEN]), durchgef hrt werden. Eine Beispiel-Katalogdatei f r HTML 4.01 ist am
Anfang des Abschnittes ber SGML-Referenzinformationen f r HTML enthalten (s. Abschnitt
19.2). Die letzten beiden Buchstaben der Deklaration geben die Sprache der DTD an. F r
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 % [Link] "HEAD, BODY">
<!ELEMENT HTML O O (%[Link];) - - 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 f r 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"
"[Link]
<HTML>
...Kopf, Rumpf usw. stehen hier...
</HTML>
Das HTML-Element < 85 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
7.4 Der Dokument-Kopf
7.4.1 Das HEAD-Element
Die HTML 4.01- Spezifikation
<!- - %[Link]; defined earlier on as "SCRIPT|STYLE|META|LINK|OBJECT" - ->
<!ENTITY % [Link] "TITLE & BASE?">
<!ELEMENT HEAD O O (%[Link];) +(%[Link];) - - 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 k nftige 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, Schl s-
selw=rter, die sinnvoll f r 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 f r den Benutzer verf gbar 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="../[Link]">
<link rel="next" href="[Link]">
<link rel="contents" href="../[Link]#toc">
<link rel="stylesheet" type="text/css" href="
[Link]
<link rel="STYLESHEET" href="../style/[Link]" 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) -(%[Link];) - - document title - ->
<!ATTLIST TITLE %i18n>
Start-Tag: erforderlich, End-Tag: erforderlich
Der Dokument-Kopf < 87 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
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 „Einf hrung“, der
nicht viel Information ber den Kontext bietet, einen Titel wie „Einf hrung 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 Gr nden der Zug@nglichkeit m ssen Benutzerprogramme den Inhalt des TITLE-Elements
f r Benutzer immer verf gbar machen (TITLE-Elemente, die in einem Frame erscheinen, einge-
schlossen). Der Mechanismus daf r h@ngt vom Benutzerprogramm ab (z. B. als berschrift,
gesprochen).
Titel d rfen Zeichen-Entities enthalten (f r Zeichen mit Akzentzeichen, Sonderzeichen usw.),
k=nnen aber keine andere Auszeichnung enthalten (Kommentare eingeschlossen). Hier ist ein
Beispiel f r einen Dokument-Titel:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"[Link]
<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, f r 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 berpr fen,
ob es dieses Attribut unterst tzt.
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 f r 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="[Link] 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 unterst tzt 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 Mausber hrung, 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 f r ein Bild verwendet werden:
<img src="[Link]"
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
[Link]>
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 w rde 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 g ltiger Eigenschaften f r Meta-Daten. Die Bedeu-
tung einer Eigenschaft und der Satz g ltiger Werte f r diese Eigenschaft sollten in einem Refe-
renz-Lexikon, Profil genannt, definiert werden. Beispielsweise w rde 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 [Link].
< 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 f r 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 g ltige Werte definiert sind. Um
ein Profil anzugeben, verwenden Sie das profile-Attribut des HEAD-Elements.
Beachten Sie, dass, wenn ein Profil f r das HEAD-Element definiert wird, dasselbe Profil f r alle
META- und LINK-Elemente im Dokument-Kopf gilt.
Es ist nicht erforderlich, dass Benutzerprogramme Mechanismen zur Unterst tzung von Meta-
Daten haben. F r den Fall, dass sie sich entschließen, Meta-Daten zu unterst tzen, 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 f r die folgenden Attribute sind abh@ngig vom
Profile:
name = name [CS]
Dieses Attribut weist den Namen einer Eigenschaft aus. Diese Spezifikation listet g ltige
Werte f r dieses Attribut nicht auf.
content = cdata [CS]
Dieses Attribut spezifiziert den Wert einer Eigenschaft. Diese Spezifikation listet g ltige
Werte f r 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 Ausf hrungen ber Profile).
http-equiv = name [CI]
Dieses Attribut kann anstelle des name-Attributs benutzt werden. HTTP-Server verwenden
dieses Attribut, um Informationen f r Header-Zeilen der HTTP-Antwort zusammenzutra-
gen.
Der Dokument-Kopf < 91 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
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 Schl sselw=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 f r die Author-Eigenschaft:
<META name="Author" content="Dave Raggett">
Das lang-Attribut kann zusammen mit META verwendet werden, um die Sprache f r 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="[Link]"
content="[Link]
auch so geschrieben werden:
<LINK rel="[Link]"
type="text/plain"
href="[Link] 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 g ltigen 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 f r 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>[Link]</title>
<meta http-equiv="refresh" content="0; url=[Link]
</head>
<body bgcolor="white">
<p>Die neue Heimat der JavaScript-FAQ befindet sich
unter <a href="[Link]
</body>
</html>
Das Meta-Element tritt hier an die Stelle des HTTP-Headers refresh. Nach null (0)
Sekunden soll die neue Seite [Link] 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 Schl sselw=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
[Link]>
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è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. Urspr nglich 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 "[Link]
labels on "1994.11.05T08:15-0500"
until "1995.12.31T23:59-0000"
for "[Link]
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 f r
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 f r 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 f r dieses Profil
einige Aktivit@ten ausf hren. Zum Beispiel k=nnten Suchmaschinen eine Schnittstelle f r 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 ausf hren (z. B. die Verwen-
dung des Profils im aktuellen HTML-Dokument erlauben). Formate f r Profile werden
durch diese Spezifikation nicht definiert.
Dieses Beispiel verweist auf ein hypothetisches Profil, das n tzliche 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="[Link]
<TITLE>How to complete Memorandum cover sheets</TITLE>
<META name="author" content="John Doe">
<META name="copyright" content="© 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 f r 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 w rde 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
[Link]>
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 (f r visuelle Browser)
fest.
link = color [CI]
Missbilligt. Dieses Attribut legt die Textfarbe noch nicht besuchter Hyperlinks (f r visu-
elle Browser) fest.
vlink = color [CI]
Missbilligt. Dieses Attribut legt die Textfarbe besuchter Hyperlinks (f r visuelle Browser)
fest.
alink = color [CI]
Missbilligt. Dieses Attribut legt die Textfarbe von Hyperlinks f r den Moment fest, in dem
sie ausgew@hlt sind (f r 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. F r visuelle Browser zum Beispiel kann man
sich den Rumpf als Leinwand vorstellen, auf der der Inhalt erscheint: Text, Bilder, Farben, gra-
phische Darstellungen usw. F r 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 f r 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, f r den Moment der Aktivierung auf Fuchsia
und auf Maroon, wenn erst einmal besucht.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"[Link]
<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"
"[Link]
<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"
"[Link]
<HTML>
<HEAD>
<TITLE>Eine Studie der Entwicklung der Population</TITLE>
<LINK rel="stylesheet" type="text/css" href="[Link]">
Der Dokumentrumpf < 97 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
</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 m ssen 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 f r Hypertext-Links
·· Als M=glichkeit, eine einzelnes Element von einem Skript aus anzusprechen
Als Name eines deklarierten OBJECT-Elements
· F r universelle Verarbeitung durch Benutzerprogramme (z. B. bei der Identifizierung von
Feldern bei der Extraktion von Daten aus HTML-Seiten f r 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="[Link]"
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([Link]('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)
· F r 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 w rden visuellen Benutzerprogrammen sagen, dass sie
informelle Meldungen gr n, Warnungen gelb und Fehlermeldungen rot anzeigen sollen:
[Link] { color: green }
[Link] { color: yellow }
[Link] { 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. Dar ber 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">
[Link] { background : green }
</STYLE>
</HEAD>
Der Dokumentrumpf < 99 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<BODY>
<PRE class="example" id="example-1">
... Code ...
</PRE>
</BODY>
Die HTML 4.01- Spezifikation
Durch Setzen des id-Attributs f r dieses Beispiel k=nnen wir (1) einen Hyperlink darauf erzeu-
gen und (2) Formatierungsinformationen der Klasse durch Formatierungsinformationen f r 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, Zeilenumbr che und Block-Formatierungen finden Sie in Abschnitt
9, „Text“.
Schreibrichtung
Aus technischen Gr nden, 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 Verf gung, 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 f r 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 hinzuzuf gen. 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. daf r verwenden, HTML auf ihre eigenen Bed rfnisse 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 gew nschten 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@[Link] - ->
<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@[Link]</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
[Link]>
<TR><TH>Email:<TD>yves@[Link]</TR>
</TABLE>
</DIV>
F r das Finetuning der Pr@sentation der Datenbankeintr@ge k=nnen wir sp@ter einfach Style-
Die HTML 4.01- Spezifikation
sheet-Deklarationen hinzuf gen.
Ein weiteres Anwendungsbeispiel finden Sie weiter oben im Abschnitt ber die Attribute class und id.
Visuelle Benutzerprogramme f gen im Allgemeinen vor und nach dem DIV-Element einen Zei-
lenumbruch ein, zum Beispiel ist f r
<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 daf r verwendet wer-
den, f r 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,
f r 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">
[Link] { text-align: justify; font-size: 12pt}
[Link] { 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
[Link]>
·· style (Inzeilige Formatierungsinformation)
onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,
onkeydown, onkeyup (eingebettete Ereignisse)
Autoren k=nnen das ADDRESS-Element benutzen, um Kontaktinformationen f r ein Dokument
Die HTML 4.01- Spezifikation
oder f r 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 Unterst tzung von Suchmaschinen
Die Unterst tzung von Sprachsynthesizern
· Die Unterst tzung eines Benutzerprogramms bei der Auswahl von Glyphen f r qualitatv
hochwertige Typographie
· Die Unterst tzung eines Benutzerprogramms bei der Auswahl eines Satzes von Anf h-
rungszeichen
· Die Unterst tzung eines Benutzerprogramms bei Entscheidungen in Bezug auf Silbentren-
nung, Ligatur und Abst@nde
· Die Unterst tzung von Rechtschreib- und Grammatikpr fern
< 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 f r
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 f r eine bestimmte Sprache atypisch sind, in weni-
ger sinnvoller Art darstellen sollen; Benutzerprogramme m ssen 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
γ-radiation,</Q> he explained.</P>
sollten Benutzerprogramme (1) versuchen, den englischen Inhalt in angemessener Art und
Weise darzustellen (z. B. in seiner Behandlung der Anf hrungszeichen) und m ssen (2) ver-
suchen, g – obgleich kein englischer Buchstabe – darzustellen.
Anmerkung der bersetzer: Die Sprachinformation in obigem Beispiel k=nnte
auch daf r genutzt werden, englische Anf hrungszeichen 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 nat rliche 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 m ssen.
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 f r 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
[Link]>
Anmerkung der bersetzer: Dass es sich bei Klingonisch um eine experimentelle
Sprache handelt, sollten Sie niemals gegen ber einem Klingonen behaupten. Die gleiche
Behauptung wird bei einer gewissen Gruppe der Cineasten zu einer ebenso ablehnen-
Die HTML 4.01- Spezifikation
den Reaktion f hren, d rfte aber weniger gef@hrlich sein als gegen ber 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 f r 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 f r Dialekte verwendet wird.
Aus zwei Zeichen bestehende Sprachcodes sind f r [ISO639] Sprachk rzel 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 f r 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 zur ck. Der
darauffolgende Absatz enth@lt eine eingebundene japanische Wendung („ja“), danach kehrt die
prim@re Sprache zu Franz=sisch zur ck.
< 106 > Sprachinformation und Leserichtung
Page size: 168,00 x 240,00 mm
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"[Link]
<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 f r 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
[Link]>
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) f r 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:
‫״...ein hebr3isches Zitat...״‬
Benutzerprogramme d rfen 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 hierf r:
Das dir-Attribut < 109 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
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 f r 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 f r ein Block-Level-Element gesetzt ist, ist es f r dieses Element bis zu
dessen Ende und f r alle eingeschlossenen Block-Level-Elemente wirksam. Das Setzen des dir-
Attributs f r ein eingeschlossenes Element berschreibt den ererbten Wert.
Um die Basistextrichtung f r ein ganzes Dokument zu setzen, setzen Sie das dir-Attribut im
HTML-Element.
Beispiel:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"[Link]
<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 ber cksichtigt werden. Um zus@tzliche Ebenen einge-
betteter Richtungswechsel zu erzeugen, m ssen 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 gew nschte 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, m ssen 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
[Link]>
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 f r 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 gen gen 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 f r 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 daf r
kann sein, dass der MIME-Standard ([RFC2045], [RFC1556]) visuelle Reihenfolge beg nstigt,
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 w rde 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 Zeilenumbr che) 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 w rde die
gew nschte 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 f r
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-
[Link] 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 bez glich 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) f r 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
[Link]>
den die Texte also „von hinten nach vorne“ (links nach rechts) angezeigt. Das Autoren-
werkzeug muss sich darum k mmern, 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 bez glich 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 f r diese Zeichen.
Der folgende DTD-Auszug zeigt einige der Richtungs-Entities (directional entities):
<!ENTITY zwnj CDATA "‌"- -=zero width non-joiner- ->
<!ENTITY zwj CDATA "‍"- -=zero width joiner- ->
<!ENTITY lrm CDATA "‎"- -=left-to-right mark- ->
<!ENTITY rlm CDATA "‏"- -=right-to-left mark- ->
Das zwnj-Entity wird verwendet, um das Verbinden in Umgebungen zu verhindern, in denen es
durchgef hrt werden w rde, jedoch nicht durchgef hrt werden soll. Das zwj-Entity bewirkt
das Gegenteil; es erzwingt das Verbinden, wenn es nicht durchgef hrt werden w rde, jedoch
durchgef hrt werden soll. Zum Beispiel wird der arabische Buchstabe „HEH“ als Abk rzung
des islamischen Kalendersystems „Hijri“ benutzt. Da die alleinstehende Form von „HEH“ aus-
sieht wie die Ziffer f nf in arabischer Schrift (basierend auf indischen Ziffern), wird, um Fehl-
deutungen von „HEH“ als letzte Ziffer f nf einer Jahreszahl vorzubeugen, die urspr ngliche
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 w rde, 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 f r richtungsneutrale Zeichen eine Rich-
tung zu erzwingen. Wenn zum Beispiel ein doppeltes Anf hrungszeichen zwischen einem ara-
bischen (von rechts nach links) und einem lateinischen (von links nach rechts) Buchstaben steht,
ist die Richung des Anf hrungszeichens 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 Hinzuf gen 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 ( )
ASCII Tabulatorschritt (	)
·· ASCII Blattwechsel ()
Zero-width space (​)
Zeilenwechsel (siehe Abschnitt 9.3.2) sind ebenfalls Leerraumzeichen. Beachten Sie, dass in
[ISO10646] auch 
 und 
 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 bez glich Darstellung oder Sonstigem f r 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 f r alle HTML-Elemente außer PRE-„Worte“ (wir verwenden
den Begriff „Wort“ („word“) hier f r „Folgen von Nicht-Leerraumzeichen“). Bei der Formatie-
rung von Text sollten Benutzerprogramme diese Worte erkennen und so anordnen, wie es f r
die spezielle geschriebene Sprache (Schrift) und das Zielmedium blich ist.
Text < 115 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Dieses Layout kann beinhalten, dass Worte durch Abst@nde getrennt werden (genannt Wort-
zwischenraum) (inter-word space); die Konventionen f r Wortzwischenr@ume variieren
jedoch von Schrift zu Schrift. Zum Beispiel wird in lateinischen Schriften Wortzwischenraum
blicherweise als ASCII-Leeraum ( ) dargestellt, w@hrend es in Thai ein Wordtrenner
Die HTML 4.01- Spezifikation
mit Null-Breite (​) 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 f r 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 f r vorformatierten Text (preformatted text) verwendet, in dem Leer-
@ume signifikant sind (siehe Abschnitt 9.3.4).
Um Probleme mit SGML-Regeln f r 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 „Zeilenumbr che“ 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 Abk rzung (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, Abk rzungen und Akronyme deutlich
zu kennzeichnen. Westliche Sprachen machen intensiven Gebrauch von Akronymen wie
„GmbH“, „NATO“ und „F.B.I.“ ebenso wie von Abk rzungen wie „M.“, „Inc.“, „et al.“, „etc.“.
Sowohl chinesisch als auch japanisch verwenden analoge Abk rzungsmechanismen, 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 n tzliche Informationen f r Benutzer-
programme und Tools wie Rechtschreibkontrollen, Sprachsynthesizer, bersetzungssysteme
und Indexierer von Suchmaschinen.
Strukturierter Text < 117 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Der Inhalt des ABBR- bzw. ACRONYM-Elements spezifiziert den Abk rzungsausdruck selbst, so, wie
er normal im Fließtext erscheinen w rde. Das title-Attribut dieser Elemente kann verwendet
werden, um die Langform des Ausdrucks anzubieten.
Beispiele f r die Verwendung von ABBR sind:
Die HTML 4.01- Spezifikation
<P>
<ABBR title="World Wide Web">WWW</ABBR>
<ABBR lang="fr"
title="Société Nationale des Chemins de Fer">
SNCF
</ABBR>
<ABBR lang="es" title="Doña">Doñ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 Abk rzungen und Akronyme oft ihre eigene gesprochene Form haben. Zum
Beispiel werden „IRS“ und „BBC“ im allgemeinen Buchstabe f r Buchstabe gesprochen und
„NATO“ und „UNESCO“ phonetisch. Wieder andere abgek rzte 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 abgek rzten 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 [Link] ist vorgesehen f r lange Zitate
(Block-Level-Inhalt) und Q f r kurze Zitate, der keine Absatzwechsel erfordert (inzeiliger
Inhalt).
Dieses Beispiel zeichnet einen Auszug aus „Die zwei T rme“ von J.R.R. Tolkien als BLOCKQUOTE aus.
<BLOCKQUOTE cite="[Link]
<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 einger ckten Block dar.
Visuelle Benutzerprogramme m ssen sicherstellen, dass der Inhalt des Q-Elements mit begren-
zenden Anf hrungszeichen dargestellt wird. Autoren sollten am Anfang und am Ende des
Inhalts eines Q-Elements keine Anf hrungszeichen schreiben.
Strukturierter Text < 119 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
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>Über das Leben</H3>
<DL>
<DT>Erich Fromm</DT>
<DD>
<Q>Leben bedeutet ständige Veränderung,
immerwährende Geburt. Tod bedeutet Aufhören des Wachstums,
Verknöcherung, Wiederholung.</Q>
</DD>
<DT>Antoine de Saint-Exupéry</DT>
<DD>
<Q LAN="fr">Leben heißt langsam Geborenwerden.
Es wä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 Anf hrungszeichen in der sprachspezifischen Art darstellen (siehe
lang-Attribut). Viele Sprachen w@hlen unterschiedliche Zitierstile f r @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 Anf hrungszeichen f r das innere Zitat und dop-
pelte Anf hrungszeichen f r 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 „H rde“ bew@ltigen leider noch weniger der
derzeit gebr@uchlichen Browser. Auch diejenigen, die Anf hrungszeichen f r Zitate set-
zen, ber cksichtigen 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
[Link]>
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 f r 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 [Link]
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 [Link]: 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 Wagenr cklauf (carriage return, 
), ein Zeilenvor-
schub (line feed, 
) oder ein Wagenr cklauf/Zeilenvorschub-Paar. Alle Zeilenumbr -
che sind Leerraum.
Mehr Informationen ber die Spezifikation von Zeilenumbr chen in SGML finden Sie in Anhang
B unter „Zeilenumbr che“.
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
[Link]>
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.
F r 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 R cksicht 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 -Entity (  oder  ) 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, m ssen 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 (- or -) repr@sen-
tiert. Das weiche Trennzeichen wird repr@sentiert durch die Zeichen-Entity-Referenz ­
(soft hyphen, ­ oder ­)
< 124 > Text
Page size: 168,00 x 240,00 mm
Anmerkung der bersetzer: Hier ein Beispiel zur Illustration:
<P>Ein Beispiel fUr Silben­trennung</P>
Die HTML 4.01- Spezifikation
Die korrekte Widergabe sollte so erfolgen:
9.3.4 Vorformatierter Text: Das PRE-Element
<!ENTITY % [Link] "IMG|OBJECT|BIG|SMALL|SUB|SUP">
<!ELEMENT PRE - - (%inline;)* -(%[Link];) - - 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
gew nschte Breite des formatierten Blocks. Das Benutzerprogramm kann diese Informa-
tion nutzen, um eine passende Schriftgr=ße zu w@hlen oder um den Inhalt entsprechend
einzur cken. Die gew nschte Breite wird ausgedr ckt in Anzahl von Zeichen. Dieses Attri-
but wird gegenw@rtig nicht umfassend unterst tzt.
Zeilen und Abs,tze < 125 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
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 d rfen Benutzerprogramme die Durchf hrung des
Bidirektionalalgorithmus jedoch nicht verhindern. Nicht-visuelle Benutzerprogramme m ssen
zus@tzlichen Leerraum im Inhalt eines PRE-Elements nicht ber cksichtigen.
Mehr Informationen ber die Spezifikation von Zeilenumbr chen in SGML finden Sie im Anhang
B unter „Zeilenumbr che“.
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 daf r bestimmt, konstante Zeilen-
abst@nde und Spaltenausrichtung f r 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 [Link]
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 linksb ndig 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
einr ckt 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 urspr nglichen 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, Einr ckung 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 verf gbaren R@nder einzupassen. Der Algorithmus f r 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
[Link]>
In westlichen Schriften zum Beispiel sollte Text nur an Lerr@umen (white space) umgebrochen
werden. Fr here Benutzerprogramme haben Zeilen inkorrekt genau hinter dem Start-Tag oder
genau vor dem End-Tag eines Elements umgebrochen, was zu h@ngender Interpunktion f hrte.
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, f hrt 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 [Link]:
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 eingef gt oder gel=scht wurden (zum Beispiel
bei Gesetzentw rfen, 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 f r 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 dar ber, wie
viele Stellvertreter ein B rgermeister einsetzen kann, von drei auf f nf @ndert.
<P>
Ein BUrgermeister kann <DEL>3</DEL><INS>5</INS>
Stellvertreter bestimmen.
</P>
Das INS- und das DEL-Element d rfen keinen Block-Level-Inhalt haben, wenn diese Elemente als
als inzeilige Elemente fungieren.
UNG LTIGES BEISPIEL:
Das Folgende ist kein g ltiges HTML:
<P>
<INS><DIV>...Block-Inhalt...</DIV></INS>
</P> n
Benutzerprogramme sollten eingef gten und gel=schten Text so darstellen, dass die Onderung
deutlich wird. Zum Beispiel kann eingef gter 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="[Link]
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
[Link]>
Das Dokument „[Link] w rde Kommentare dazu enthal-
ten, warum die Information in das Dokument eingef gt wurde.
Autoren k=nnen eingef gten oder gel=schten Text auch mittels title-Attribut f r 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 m ssen 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 fl ssigen Zutaten dazugeben.
3. 10 Minuten r hren.
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 f r 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
[Link]>
Zutaten:
·· 100g Mehl
10g Zucker
··1 Tasse Wasser
Die HTML 4.01- Spezifikation
2 Eier
·Salz, Pfeffer
Zubereitung:
1. Die trockene Zutaten gr ndlich vermischen.
2. Die fl ssigen Zutaten dazugeben.
3. 10 Minuten r hren.
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 Einr cken 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
[Link] (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 verf gbare
Werte sind f r 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 f r 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 f r 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
[Link]>
<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 f r 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
[Link]>
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 r cken im Allgemeinen verschachtelte Listen unter Ber cksichtung
der jeweiligen Verschachtelungsebene ein.
Sowohl f r OL als auch f r UL gibt das type-Attribut Darstellungsoptionen f r visuelle Benutzer-
agenten vor.
F r 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 ausgef llte 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 f r 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 Gr n-
< 136 > Listen
Page size: 168,00 x 240,00 mm
den, die prinzipiell daf r 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">
[Link] { 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
[Link]>
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 f r das Erstellen von mehrspaltigen Verzeichnislisten entworfen. Das
MENU-Element wurde f r einspaltige Men listen 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-
st tzt. Benutzerprogramme k=nnen die Bereiche Kopf, Rumpf und Fuß ausnutzen, um das von
den Kopf- und Fußbereichen unabh@ngige Scrollen von Rumpf-Bereichen zu unterst tzen. 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 unterst tzen 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 m ssen wir – so richtig sie in ihrem
Anliegen sind – unter praktischen Gesichtspunkten etwas relativieren.
Richtig und wichtig ist: Tabellen sind ein Struktur-, kein Layoutmittel. Mangels Alternati-
ven wurden und werden sie h@ufig f r Layoutzwecke „missbraucht“ und f hren zu den
erw@hnten Problemen bei nicht visueller Darstellung. Leider scheitert die 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 Unterst tzung von Stylesheets.
Um es noch einmal deutlich zu sagen: Wir unterst tzen hier nicht die Verwendung von
Tabellen f r Layoutzwecke, weisen nur auf die praktischen Schwierigkeiten hin, die
Alternativen zurzeit noch mit sich bringen.
Die erg@nzende Aussage, dass Tabellen zum horizontalen Scrollen zwingen k=nnen, ist
ebenfalls richtig, jedoch nicht so absolut, wie sie sich vielleicht liest. Nicht die Erstellung
auf gr=ßeren Bildschirmen ist die Ursache, sondern mangelndes Bewusstsein daf r bei
so manchem Autor, der ihnen ein zu starres Layout aufzwingt – brigens auch da, wo
Tabellen nicht „missbraucht“, sondern ihrer Intention entsprechend zur strukturierten
Pr@sentation von Informationen eingesetzt werden. Mehr dazu lesen Sie in unseren
Anmerkungen weiter unten in diesem Kapitel, in den Abschnitten, die sich mit 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, f hren aber ansonsten zu durchaus @hnlichen Problemen bei allzu
starren Vorgaben. Ob feste Positionen durch Dummy-Graphiken – dem meistgehassten
beliebten Hilfsmittel der Tabellenlayouts – erreicht werden, durch unflexible 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 nat rlich 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
[Link]>
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 f r 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 f r eine Tabelle mit den Elementnamen liga, verein, punkte, tore und so weiter.
Es ist unmittelbar klar, dass es um irgendwelche Sportdaten geht. Die Formatierung als
Tabelle erfolgt dort mit CSS. Bei dieser Vorgehensweise hat sich dann endg ltig die
Frage erledigt: „Struktur oder Layout?“
Dank der Modularisierung von XHTML l@sst sich so etwas einfach mit XHTML kom-
binieren: Ein „liga“-Modul f r die Sportdaten k=nnte den XHTML-Modulen hinzugef gt
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 f r 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
f r Benutzerprogramme, die den Inhalt f r 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
[Link]>
width = length [CN]
Dieses Attribut gibt die gew nschte Breite der gesamten Tabelle an und ist f r visuelle
Benutzerprogramme vorgesehen. Ist der Wert eine Prozentangabe, dann ist der Wert rela-
tiv zur verf gbaren 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 ausf hren k=n-
nen, wenn sie eine Tabelle darstellen:
· Dem Benutzer die Tabellenzusammenfassung (summary) zur Verf gung 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 m ssen wissen, wo Kopf und Fuß darzustellen
sind. Ist das Ausgabemedium zum Beispiel seitenorientiert, m ssen Benutzerprogramme
den Kopf an den Beginn und den Fuß an das Ende jeder Seite stellen. 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 f r Zeile und angeordnet in entsprechenden Spalten zwischen dem Kopf
und dem Fuß darstellen. Visuelle Benutzerprogramme sollten die Tabelle so formatieren
wie HTML-Attribute und Stylesheet-Angaben es vorgeben.
< 142 > Tabellen
Page size: 168,00 x 240,00 mm
Das HTML-Tabellenmodell wurde so entworfen, dass Benutzerprogramme mit Unterst tzung
des Autors Tabellen inkrementell darstellen k=nnen (d. h., wenn Tabellenzeilen eintreffen),
anstatt auf alle Daten warten zu m ssen, um mit der Darstellung zu beginnen.
Damit ein Benutzerprogramm eine Tabelle in einem Zug darstellen kann, m ssen Autoren ihm
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“), m ssen 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 f r das Element TABLE.
F r eine Tabelle von links nach rechts ist die Spalte Null auf der linken Seite und die Zeile Null
befindet sich oben. F r eine Tabelle von rechts nach links ist die Spalte Null auf der rechten
Seite und die Zeile Null befindet sich oben.
Teilt ein Benutzerprogramm einer Zeile zus@tzliche Zellen zu (siehe Abschnitt „Berechnen der
Spaltenanzahl einer Tabelle“), werden zus@tzliche Zellen f r „links-nach-rechts“-Tabellen an
der rechten Seite und und f r „rechts-nach-links“-Tabellen auf der linken Seite hinzugef gt.
Beachten Sie, dass TABLE das einzige Element ist, f r welches das Attribut dir die visuelle Rei-
henfolge der Spalten umkehrt; eine einzelne Tabellenzeile (TR) oder eine Spaltengruppe (COL-
GROUP) kann nicht unabh@ngig umgekehrt werden.
Ist das Attribut dir f r das Element TABLE angegeben, wirkt sich das Attribut ebenfalls auf den
Text innerhalb der Tabellenzellen aus (weil das dir-Attribut von Block-Level-Elementen 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“ f r weiterf hrende Informationen zum Thema Text-
flussrichtung.
Elemente zur Tabellenerzeugung < 143 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
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. F r 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 f r 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 Tabellenr mpfen unabh@ngig vom Tabel-
lenkopf und -fuß zu unterst tzen. Werden lange Tabellen gedruckt, k=nnen Informationen des
Tabellenkopfes und -fußes auf jeder Seite mit Tabellendaten wiederholt werden.
Tabellenkopf und -fuß sollten Informationen ber die Tabellenspalten enthalten. Der Tabellen-
rumpf sollte Zeilen mit Tabellendaten enthalten.
Anmerkung der bersetzer: Die CSS2-Spezifikation nennt die folgenden Anga-
ben als Voreinstellungen f r 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
[Link]>
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
f r 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 -r mpfen.
<TABLE>
<THEAD>
<TR> ...Kopfinformation...
</THEAD>
<TFOOT>
<TR> ...Fußinformation...
</TFOOT>
<TBODY>
<TR> ...erste Zeile mit Daten von Block eins...
<TR> ...zweite Zeile mit Daten von Block eins...
</TBODY>
<TBODY>
<TR> ...erste Zeile mit Daten von Block zwei...
<TR> ...zweite Zeile mit Daten von Block zwei...
<TR> ...dritte Zeile mit Daten von Block zwei...
</TBODY>
</TABLE>
TFOOT muss vor TBODY innerhalb einer TABLE-Definition stehen, so dass Benutzerprogramme den
Fuß darstellen k=nnen, bevor alle (der eventuell zahlreichen) Datenzeilen empfangen werden.
Das Folgende fasst zusammen, welche Tags erforderlich sind und welche weggelassen werden
k=nnen:
· Der Start-Tag TBODY ist immer erforderlich, außer die Tabelle enth@lt nur einen Tabellen-
rumpf und keinen Tabellenkopf oder -fuß. Das End-Tag TBODY kann immer problemlos weg-
gelassen werden.
· Die Start-Tags f r 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 m ssen diese Regeln aus Gr nden der Abw@rts-
kompatibilit@t immer befolgen.
Die Tabelle des vorherigen Beispiels k=nnte durch Weglassen bestimmter End-Tags verk rzt
werden:
<TABLE>
<THEAD>
<TR> ...Kopfinformation...
<TFOOT>
<TR> ...Fußinformation...
< 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 m ssen 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 f r das TABLE-Element) hervorheben. Ein Beispiel der visuellen Darstellung von
Spaltengruppen enth@lt die Beispieltabelle in Abschnitt 11.5.
Eine Tabelle kann entweder eine einzige implizite Spaltengruppe (kein COLGROUP-Element
begrenzt die Spalten) oder eine beliebige Anzahl expliziter Spaltengruppen (jede begrenzt durch
die Instanz eines COLGROUP-Elements) enthalten.
Das Element COL gestattet Autoren, ein Attribut f r mehreren Spalten gemeinsam zu 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 m ssen 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
[Link]>
width = multi-length [CN]
Dieses Attribut gibt eine Standardbreite f r jede Spalte in der aktuellen Spaltengruppe an.
Zus@tzlich zum Standard (Pixel, Prozent und relative Werte) gestattet dieses Attribut die
besondere Form „0*“ (Null Stern), was bedeutet, dass die Breite jeder Spalte in der Gruppe
Die 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. F r 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. f r Format-
informationen, um eine Breite anzugeben usw.), m ssen Autoren diese Spalte mit einem COL-
Element identifizieren. Um in einem solchen Fall der letzten Spalte der vorhergehenden Tabelle
ein bestimmtes Format zuzuweisen, grenzen wir sie wie folgt aus:
<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 f r jede Spalte in der ersten Spalten-
gruppe ist 50 Pixel. Die Breite jeder Spalte in der zweiten Spaltengruppe wird die minimal
ben=tigte f r 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 f r dieses Attribut ist 1
(d. h., das Element COL bezieht sich auf eine einzige Spalte). Ist f r das span-Attribut N > 1,
teilt das aktuelle COL-Element seine Attribute mit den n@chsten N-1 Spalten.
width = multi-length [CN]
Dieses Attribut gibt eine Standardbreite f r jede Spalte an, ber die sich das aktuelle COL-
Element erstreckt. Es hat die gleiche Bedeutung wie das Attribut width f r das Element
COLGROUP und berschreibt es.
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
[Link]>
Das Element COL gestattet Autoren, Attributangaben f r 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 Unterst tzung f r 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 f r jedes COL-Element den Wert seines span-Attributs (Standardwert 1).
Ignoriere f r jedes COLGROUP-Element, das mindestens ein COL-Element enth@lt, das span-
Attribut eben dieses COLGROUP-Elements. Vollziehe f r jedes COL-Element die Berechnung
aus Schritt 1.
· Nimm f r jedes leere COLGROUP-Element den Wert seines span-Attributs (Standardwert 1).
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. F r jede Zeile, die weniger als diese Anzahl Spalten hat, sollte das Ende mit lee-
ren Zellen aufgef llt werden. Das „Ende“ einer Zeile ist abh@ngig von der Tabellenrichtung.
Es ist ein Fehler, wenn Tabellen COLGROUP oder COL-Elemente enthalten und die beiden 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 f r 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 f r die Tabelle zur Verf gung steht (zwischen dem aktuellen linken und rechten
Rand, gleitende Objekte eingeschlossen). Beachten Sie, dass dieser Raum nicht von der
Tabelle selbst abh@ngig ist, und prozentuale Angaben deshalb einen inkrementellen Aufbau
gestatten.
Proportional
Proportionale Angaben (z. B. width=„3*“) beziehen sich auf den horizontalen Raum, der
von der Tabelle gefordert wird. Wird der Tabellenbreite ber das Attribut width des 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, m ssen Benutzerprogramme alle Tabellendaten
empfangen, bevor sie den horizontalen Raum ermitteln k=nnen, der von der Tabelle ben=-
tigt wird. Nur dann kann dieser Raum den proportionalen Spalten zugeordnet werden.
Gibt ein Autor 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 f r den Inhalt einer bestimmten Tabellenzelle, m ssen
Benutzerprogramme die Tabelle eventuell neu aufbauen.
Anmerkung der bersetzer: Die M=glichkeit, dass eine Tabelle inkrementell 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 w rde dies zu dem
Ergebnis f hren, dass vorhandene Fenster- oder Frame-Breiten nicht ausreichen; die
Nutzer m ssten dann scrollen. Wenn diese Gefahr besteht und es sich nicht gerade um
sehr lange Tabellen handelt, ist es daher im Interesse einer benutzerfreundlichen 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
[Link]>
wichtig ist dann jedoch, dass der Platzbedarf f r 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 f r Spalten enth@lt und keinen Wert
f r das width-Attribut des TABLE-Elements.
Wenn das (visuelle) Benutzerprogramm die Tabellendaten empfangen hat, wird der verf gbare
horizontale Raum vom Benutzerprogramm wie folgt zugewiesen: Zuerst wird das Benutzerpro-
gramm den Spalten eins und zwei je 30 Pixel zuweisen, dann wird der minimal n=tige Raum f r
die dritte Spalte reserviert. Der verbleibende horizontale Raum wird in sechs gleich Teile
geteilt (weil 2* + 1* + 3* = 6 Teile). Spalte vier (2*) bekommt zwei dieser Teile, Spalte f nf (1*)
bekommt einen Teil und Spalte sechs (3*) erh@lt drei.
<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, f r
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 f r die letzten beiden Spalten angegeben werden
kann.
Anmerkung: Obwohl das Attribut width des Elements TABLE nicht missbilligt ist, werden Autoren
angehalten, Stylesheets zur Angabe von Tabellenbreiten zu verwenden.
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 f r 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
[Link]>
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 f r die aktuelle
Datenzelle beinhalten. Der Wert dieses Attributs ist eine durch Leerzeichen getrennte
Liste von Zellnamen; diese Zellen m ssen durch Angabe ihres id-Attributs benannt werden.
Autoren verwenden das headers-Attribut im Allgemeinen, um nicht visuellen Benutzerpro-
grammen bei der Darstellung von Kopfinformationen f r Datenzellen zu helfen (z. B. wird
die Kopfinformation vor den Daten der Zelle gesprochen), jedoch k=nnte das Attribut auch
in Verbindung mit Stylesheets verwendet werden. Siehe auch: das Attribut scope.
scope = scope-name [CI]
Dieses Attribut gibt die Gruppe der Datenzellen an, f r die die aktuelle Kopfzelle Kopf-
informationen bereit h@lt. Dieses Attribut kann anstelle des Attributs headers verwendet
werden, insbesondere f r einfache Tabellen. Ist dieses Attribut angegeben, muss es einen
der folgenden Werte haben:
· row: Die aktuelle Zelle enth@lt Kopfinformationen f r den Rest der Zeile, die sie ent-
h@lt (siehe auch den Abschnitt ber Tabellenrichtung).
· col: Die aktuelle Zelle enth@lt Kopfinformationen f r den Rest der Spalte, die sie ent-
h@lt.
· rowgroup: Die Kopfzelle enth@lt Kopfinformationen f r den Rest der Zeilengruppe,
die sie enth@lt.
· colgroup: Die Kopfzelle enth@lt Kopfinformationen f r den Rest der Spaltengruppe,
die sie enth@lt.
abbr = text [CS]
Dieses Attribut sollte verwendet werden, um eine abgek rzte Form des Zellinhalts zur
Verf gung zu stellen und k=nnte von Benutzerprogrammen dargestellt werden, wenn es
anstelle des Zellinhalts sinnvoll ist. Abgek rzte Namen sollten kurz sein, weil Benutzerpro-
< 154 > Tabellen
Page size: 168,00 x 240,00 mm
gramme sie wiederholt darstellen k=nnten. Zum Beispiel k=nnten Sprachsythesizer den
abgek rzten 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“ f r weiterf hrende 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 f r 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
[Link]>
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 Verf gung: der Inhalt des Elements TH und der Wert
des Attributs abbr. Benutzerprogramme m ssen entweder den Inhalt der Zelle oder den Wert
des Attributs abbr darstellen. F r visuelle Medien kann das Letztere angebracht sein, wenn
ungen gend Platz zur Darstellung des gesamten Zelleninhalts zur Verf gung steht. F r nicht
visuelle Medien kann abbr als Abk rzung f r Tabellenk=pfe verwenden, wenn diese zusammen
mit dem Inhalt der Zellen, f r die sie g ltig sind, wiedergegeben werden.
Die Attribute headers und scope gestatten es Autoren ebenfalls, nicht visuellen Benutzerpro-
grammen bei der Verarbeitung der Kopfinformationen zu helfen. Bitte lesen Sie die Informa-
tionen und Beispiele im Abschnitt „Kopfinformationen mit Datenzellen verkn pfen“ f r nicht
visuelle Benutzerprogramme.
Das Element TD definiert eine Zelle, die Daten enth@lt.
Zellen k=nnen leer sein (d. h. keine Daten enthalten).
Zum Beispiel enth@lt die folgende Tabelle vier Spalten mit Daten, jede mit einer 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 ber cksichtigen. Deshalb definiert das zweite TD in Zeile zwei in diesem Fall die dritte
Zelle der Zeile. Visuell k=nnte die Tabelle von einem tty-Ger@t wie folgt dargestellt werden:
-------------
| 1 | 2 | 3 |
----| |----
| 4 | | 6 |
----|---|----
| 7 | 8 | 9 |
-------------
Elemente zur Tabellenerzeugung < 157 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
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 hinzugef gt 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 g ltige Beispiel zeigt, wie jemand bereinander liegende Zellen erzeugen
k=nnte. In dieser Tabelle erstreckt sich Zelle „5“ ber zwei Zeilen und Zelle „7“ erstreckt sich
ber zwei Spalten, so gibt es eine berlappung in der Zelle zwischen „7“ und „9“:
< 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 f r:
··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
[Link]>
·· 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 f r 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 f nf 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 Gr nden der R ckw@rts-
kompatibilit@t berwacht werden:
· Die Angabe border=„0“ impliziert frame=„void“ und, wenn nicht anders angegeben,
rules=„none“.
· Andere Werte f r border implizieren frame=„border“ und, wenn nicht anders angegeben,
rules=„all“.
· Der Wert „border“ im Start-Tag des Elements TABLE sollte wie der Wert des Attributs
frame interpretiert werden. Er impliziert rules=„all“ und irgendwelche Standardwerte (un-
gleich Null) f r 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 f r 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
[Link]>
<!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 f r Tabel-
lendaten.
·· center: Daten zentrieren/Text zentrieren. Das ist der Standardwert f r Tabellenk=pfe.
right: Daten fließen nach rechts/Text rechts ausrichten.
·· justify: Richtet Text an beiden R@ndern aus.
char: Richtet Text an einem bestimmten Zeichen aus. Unterst tzt ein 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 f r die
Ausrichtung fungiert. Der Standardwert f r dieses Attribut ist das Dezimaltrennzeichen der
aktuellen Sprache, die durch das Attribut lang eingestellt ist (z. B. der Punkt („.“) im Eng-
lischen und das Komma („,“) im Franz=sischen). Benutzerprogramme m ssen dieses Attri-
but nicht unterst tzen.
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 m ssen dieses Attribut nicht
unterst tzen.
< 162 > Tabellen
Page size: 168,00 x 240,00 mm
Anmerkung der bersetzer: Derzeit verbreitete Browser unterst tzen 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 f r 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) f r die Attribute align, char und charoff
ist die folgende:
1. Ein f r ein Element innerhalb der Zelldaten gesetztes Ausrichtungsattribut (z. B. P).
2. Ein f r eine Zelle gesetztes Ausrichtungsattribut (TH und TD).
3. Ein f r ein Spaltengruppen-Elements gesetztes Ausrichtungsattribut (COL und COLGROUP). Ist
eine Zelle Teil eines mehrspaltigen Bereiches, wird die Ausrichtungseigenschaft von der
Zelldefinition am Anfang des Bereiches vererbt.
Formatierung durch visuelle Benutzerprogramme < 163 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
4. Ein f r eine Zeile oder ein Zeilengruppen-Element gesetztes Ausrichtungsattribut (TR,
THEAD, TFOOT und TBODY). Ist eine Zelle Teil eines mehrzeiligen Bereiches, wird die Ausrich-
tungseigenschaft von der Zelldefinition am Anfang des Bereiches vererbt.
5. Ein f r die Tabelle gesetztes Ausrichtungsattribut (TABLE).
Die HTML 4.01- Spezifikation
6. Der Standardausrichtungswert.
Die Rangfolge (vom h=chsten zum niedrigsten Rang) f r die Attribute valign (wie auch f r die
anderen vererbten Attribute lang, dir und style) ist die folgende:
1. Ein f r ein Element innerhalb der Zelldaten gesetztes Attribut (z. B. P).
2. Ein f r eine Zelle gesetztes Attribut (TH und TD).
3. Ein f r eine Zeile oder ein Zeilengruppen-Element gesetztes Attribut (TR, THEAD, TFOOT und
TBODY). Ist eine Zelle Teil eines mehrzeiligen Bereiches, wird die Ausrichtungseigenschaft
von der Zelldefinition am Anfang des Bereiches vererbt.
4. Ein f r ein Spaltengruppen-Elements gesetztes Attribut (COL und COLGROUP). Ist eine Zelle
Teil eines mehrspaltigen Bereiches, wird die Ausrichtungseigenschaft von der Zelldefinition
am Anfang des Bereiches vererbt.
5. Ein f r 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 f r 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 unterst tzen, sollten den
Wert der vererbten Textflussrichtung an seiner Stelle verwenden.
Anmerkung: Beachten Sie, dass eine Zelle ein Attribut nicht von seinem Elternelement erben kann,
sondern von der ersten Zelle in einem Bereich. Dies ist eine Ausnahme von den allgemeinen Ver-
erbungsregeln fr Attribute. n
11.3.3 [Link]
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
f r 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 Verf gung stehenden vertikalen Raums, der linke und der
rechte Rand sollten gleichermaßen vom Inhalt abgesetzt werden, basierend auf einem pro-
zentualen Anteil des zur Verf gung 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 verf gbaren
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 verf gbaren
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:
· F r 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 f r 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
[Link]>
· F r eine gegebene Kopfzelle teilt das Attribut scope dem Benutzerprogramm mit, f r wel-
che Datenzellen dieser Kopf Informationen bereith@lt. Autoren w@hlen vielleicht dieses
Attribut anstatt headers, je nachdem, welches g nstiger ist; beide Attribute erf llen die 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, f r die sie gelten.
· Das Attribut abbr gibt einen abgek rzten Kopfinhalt f r 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 abgek rzt wird zu „Sor-
te“.
Hier ist das gleiche Beispiel mit dem Attribut scope anstelle des Attributs headers. Beachten Sie
den Wert „col“ f r das scope-Attribut, das besagt „alle Zellen in der aktuellen Spalte“:
< 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>£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
[Link]>
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>£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>£18</TD>
</TR>
</TABLE>
Ein graphisches Benutzerprogramm k=nnte dies so darstellen:
Achten Sie auf die Verwendung des scope-Attributs mit dem Wert „row“. Auch wenn die erste
Zelle in jeder Zeile Daten enth@lt, und keine Kopfinformationen, sorgt das das Attribut scope
daf r, dass die Datenzelle sich wie eine Zeilen-Kopfzelle verh@lt. Dadurch k=nnen 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 verkn pfen“).
< 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 f r 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 f r all meine Mahlzeiten ausgegeben?“
„Was habe ich am 25. August f r Mahlzeiten ausgegeben?“
· „Wie hoch waren die Gesamtkosten in San Jose?“
Jede Anfrage zieht eine Verarbeitung durch das Benutzerprogramm nach sich, die keine oder
mehr Zellen umfasst. Um zum Beispiel die Kosten f r Mahlzeiten am 25. August zu bestimmen,
muss das Benutzerprogramm wissen, welche Zellen sich auf „Mahlzeiten“ (alle von ihnen) und
welche sich auf „Datumsangaben“ (insbesondere den 25. August) beziehen, und die 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. F r die Reisekostentabelle zum Beispiel,
kann der Autor die Kopfzellen „San Jose“ und „Seattle“ in die Kategorie „Ort“, die K=pfe
„Mahlzeiten“, „Hotels“ und „Transport“ in die Kategorie „Ausgaben“ und die vier Tage in die
Kategorie „Datum“ einordnen. Die drei vorstehenden Fragen h@tten dann die folgende Bedeu-
tung:
· „Was habe ich f r alle meine Mahlzeiten ausgegeben?“ bedeutet „Wie teuer ist alles zusam-
men in den Zellen der Kategorie Ausgaben=Mahlzeiten?“
· „Was habe ich am 25. August f r 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 f r die
Zelle. In der Reisekostentabelle zum Beispiel kann die Zelle mit der Information „San Jose“ wie
folgt in die Kategorie „Ort“ eingeordnet werden:
<TH id="a6" axis="ort">San Jose</TH>
Darstellung durch nicht visuelle Benutzerprogramme < 169 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Jede Zelle, die Informationen bez glich „San Jose“ enth@lt, sollte sich auf diese Kopfzelle entwe-
der ber das headers- oder das scope-Attribut beziehen. Deshalb sollten Ausgaben f r 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 f r Mahlzeiten?“ sprechen, w@re ein Benutzer nicht in
der Lage, Tagesausgaben von Zwischensummen oder Gesamtsummen zu unterscheiden. Durch
die sorgf@ltige Kategorisierung der Datenzellen gestatten Autoren den Benutzerprogrammen,
wichtige semantische Unterschiede bei der Darstellung zu machen.
Nat rlich gibt es kein Grenze, inwieweit Autoren Informationen in einer Tabelle kategorisieren
k=nnen. In der Reisekostentabelle k=nnten wir zum Beispiel die zus@tzlichen Kategorien „Zwi-
schensummen“ und „Gesamtsummen“ hinzuf gen.
Diese Spezifikation verlangt von Benutzerprogrammen weder, axis-Attribut angegebene Infor-
mationen zu verarbeiten, noch gibt sie irgendwelche Empfehlungen dar ber, 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
[Link]>
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 f r Mahlzeiten in San Jose ausgegeben?“,
w rde 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 w rde die gemeinsamen Informationen ausklammern
und sie neu ordnen:
San Jose, Mahlzeiten, 25-Aug-1997: 37.74
26-Aug-1997: 27.28
Benutzerprogramme, die diese Art der Darstellung unterst tzen, sollten eine M=glichkeit 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 f r 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 eingef gt, in der sie in der Tabelle
erscheinen. In Tabellen der Richtung links nach rechts werden die K=pfe von links nach
rechts eingef gt.
· Spaltenk=pfe werden nach Zeilenk=pfen in der Reihenfolge eingef gt, in der sie in der
Tabelle erscheinen, von oben nach unten.
· Ist das headers-Attribut f r eine Kopfzelle angegeben, dann werden die Header, die von die-
sem Attribut referenziert werden, in die Liste eingef gt und die Suche stoppt f r 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 w rde die Tabelle
<TABLE border="2" frame="hsides" rules="groups"
summary="Code page support in different versions
of MS Windows.">
<CAPTION>CODE-PAGE SUPPORT IN MICROSOFT WINDOWS</CAPTION>
<COLGROUP align="center">
<COLGROUP align="left">
<COLGROUP align="center" span="2">
<COLGROUP align="center" span="3">
<THEAD valign="top">
<TR>
<TH>Code-Page<BR>ID
<TH>Name
<TH>ACP
<TH>OEMCP
<TH>Windows<BR>NT 3.1
<TH>Windows<BR>NT 3.51
<TH>Windows<BR>95
<TBODY>
<TR><TD>1200<TD>Unicode (BMP of ISO/IEC-10646)<TD><TD><TD>X<TD>X<TD>*
<TR><TD>1250<TD>Windows 3.1 Eastern European<TD>X<TD><TD>X<TD>X<TD>X
<TR><TD>1251<TD>Windows 3.1 Cyrillic<TD>X<TD><TD>X<TD>X<TD>X
<TR><TD>1252<TD>Windows 3.1 US (ANSI)<TD>X<TD><TD>X<TD>X<TD>X
<TR><TD>1253<TD>Windows 3.1 Greek<TD>X<TD><TD>X<TD>X<TD>X
<TR><TD>1254<TD>Windows 3.1 Turkish<TD>X<TD><TD>X<TD>X<TD>X
<TR><TD>1255<TD>Hebrew<TD>X<TD><TD><TD><TD>X
<TR><TD>1256<TD>Arabic<TD>X<TD><TD><TD><TD>X
<TR><TD>1257<TD>Baltic<TD>X<TD><TD><TD><TD>X
<TR><TD>1361<TD>Korean (Johab)<TD>X<TD><TD><TD>**<TD>X
<TBODY>
<TR><TD>437<TD>MS-DOS United States<TD><TD>X<TD>X<TD>X<TD>X
<TR><TD>708<TD>Arabic (ASMO 708)<TD><TD>X<TD><TD><TD>X
<TR><TD>709<TD>Arabic (ASMO 449+, BCON V4)<TD><TD>X<TD><TD><TD>X
<TR><TD>710<TD>Arabic (Transparent Arabic)<TD><TD>X<TD><TD><TD>X
<TR><TD>720<TD>Arabic (Transparent ASMO)<TD><TD>X<TD><TD><TD>X
</TABLE>
ungef@hr so dargestellt:
CODE-PAGE SUPPORT IN MICROSOFT WINDOWS
===============================================================================
Code-Page | Name | ACP OEMCP | Windows Windows Windows
ID | | | NT 3.1 NT 3.51 95
----------------------------------------------------------------------------- --
1200 | Unicode (BMP of ISO 10646) | | X X *
1250 | Windows 3.1 Eastern European | X | X X X
1251 | Windows 3.1 Cyrillic | X | X X X
1252 | Windows 3.1 US (ANSI) | X | X X X
1253 | Windows 3.1 Greek | X | X X X
1254 | Windows 3.1 Turkish | X | X X X
Beispieltabelle < 173 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
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
gew nscht 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
[Link]>
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="[Link]">Allerleirauh</a></p>
<p><a href="[Link]">Bruder Lustig</a></p>
<p><a href="[Link]">BrUderchen und
Schwesterchen</a></p>
<p><a href="[Link]">Das tapfere Schneiderlein</a></p>
<p><a href="[Link]">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="[Link] M]rchen</a></p>
<p><a href="[Link]">M]rchenbUcher</a></p>
< 176 > Tabellen
Page size: 168,00 x 240,00 mm
<p><a href="[Link]">M]rchenlinks</a></p>
<p><a href="[Link]">Impressum</a></p>
<p><a href="[Link]">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 geringf gigen 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 f r
Schriftgr=ßen (px), nur ist der Preis daf r, n@mlich die Aufgabe jeglicher Anpassungs-
f@hgkeit, zu hoch.
Fazit: Stylesheets sind die anzustrebende Alternative f r Tabellenlayouts, aber erst dann
eine wirkliche, wenn die Browserlandschaft ihr gewachsen ist. Bis dahin werden Auto-
ren und Benutzer mit Einschr@nkungen und eventuell mit Kompromissen leben.
Beispieltabelle < 177 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Anmerkung der bersetzer: Das Tabellenmodell von HTML ist zeilenorientiert.
Das heißt auch, dass Tabellen Zeile f r Zeile eingegeben werden. HTML- oder XML-
Editoren gestatten nat rlich auch eine Eingabe in eine graphisch dargestellte Tabelle.
Die HTML 4.01- Spezifikation
Manchmal kann diese Zeilenorientierung unbequem sein, und man w rde sich eine Spal-
tenorientierung w nschen. In einem solchen Fall muss die Tabelle „nur“ transponiert
werden (das heißt, Spiegelung an der Hauptdiagonalen). So fern es sich um eine 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 durchf hren. Da einer der bersetzer k rzlich selbst vor diesem
Problem stand, finden Sie unter [Link]/xslt/ ein kleines XSLT-Programm,
das die Transponierung f r eine solche XHTML-Tabelle durchf hrt.
12 Links
12.1 Einf-hrung in Links und Anker
HTML bietet viele der herk=mmlichen Publikationsm=glichkeiten f r 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 „[Link]“ ist, und einen anderen, dessen Zielanker ein GIF-Bild in der Datei
„[Link]“ ist:
<BODY>
...Text...
<P>Sie k^nnen eine Menge mehr in <A href="[Link]">Kapitel zwei</A> finden.
Schauen Sie bitte auch diese <A href="../images/[Link]">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 w rden 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 ausdr cken als einfach nur „akti-
viere diesen Link, um die betreffende Ressource aufzusuchen“. In Quellankern von Links, die
andere Arten von Beziehungen ausdr cken, 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
[Link]>
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="[Link]">
<LINK rel="next" href="[Link]">
</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 [Link]
[Link] an. Sie enth@lt folgende Links:
<link rel="previous" href="[Link]">
<link rel="next" href="[Link]">
<link rel="contents" href="../[Link]#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“,
[Link]), zur n@chsten Seite (das ist Kapitel 13, „Objects, Images, and Applets“,
[Link]) und zum Inhaltsverzeichnis ([Link]) gelangen kann.
< 180 > Links
Page size: 168,00 x 240,00 mm
Die HTML 4.01- Spezifikation
Auch wenn sie nicht f r 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 f r 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 f r
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
[Link]>
12.1.4 Linktitel
Das title-Attribut kann sowohl f r A als auch f r LINK gesetzt werden, um Informationen ber
ber den Link hinzuzuf gen. 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 f r jeden Link einen Titel
anbieten:
<BODY>
...Text...
<P>Sie k^nnen eine Menge mehr in <A href="[Link]"
title="Gehe zu Kapitel zwei">Kapitel zwei</A> finden.
<A href="./[Link]"
title="Hole Kapitel zwei.">chapter two</A>.
Schauen Sie bitte auch diese <A href="../images/[Link]"
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,
unterst tzen 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 Verf gung stellt.
Ausger stet mit diesem zus@tzlichen Wissen sollten es Benutzerprogramme vermeiden k=n-
nen, dem Benutzer „M ll“ zu pr@sentieren. Statt dessen k=nnen sie entweder Ressourcen aus-
findig machen, die f r 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 f r den Einsatz eines Fallback-Me-
chanismus zu entscheiden, statt den Inhalt zu holen, wenn sie dar ber benachrichtigt wer-
den, dass sie Inhalt mit einem Inhaltsyp erhalten, den sie nicht unterst tzen.
Autoren, die dieses Attribut benutzen, bernehmen die Verantwortung, das Risiko der
Inkonsistenz mit dem an der Zieladresse des Links verf gbaren 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 R ckw@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
[Link]>
·· 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 f r 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
Verf gung steht.
Im folgenden Beispiel definiert das A-Element einen Link. Quellanker ist der Text „W3C Web-
Site“ und Zielanker ist „[Link]
Mehr Informationen Uber das W3C bekommen Sie auf der
<A href="[Link] 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 f r 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="[Link] charset="ISO-8859-1">Web-Site des W3C</A>.
Angenommen, wir definieren einen Anker namens „anker-one“ in der Datei „[Link]“.
...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 f r solche
URIs:
·· Ein absoluter URI: [Link]
Ein relativer URI: ./[Link]#anchor-one oder [Link]#anchor-one
· Wenn der Verweis im gleichen Dokument definiert ist: #anchor-one
Ein Link, der in der in demselben Verzeichnis wie „[Link]“ befindlichen Datei „[Link]“
definiert ist, w rde folgendermaßen auf den Anker verweisen:
...Text vor dem Link...
Mehr Informationen finden Sie unter <A href="./[Link]#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="[Link]
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
[Link]>
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 unerw nschte 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 m ssen die folgenden Regeln beachten:
· Eindeutigkeit: Ankernamen m ssen 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
m ssen auf genaue bereinstimmung hin (Groß- und Kleinschreibung) durchgef hrt 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 bez glich der Eindeutigkeit ung ltig, da beiden Namen sich nur in
Groß- und Kleinschreibung unterscheiden:
<P><A name="xxx">...</A>
<P><A name="XXX">...</A>
Obwohl der folgende Auszug g ltiges 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 [Link]
Durch das A-Element definierte Anker und Verweise d rfen 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 f r die folgenden Elemente
anzugeben: A, APPLET, FORM, FRAME, IFRAME, IMG, und MAP. Wenn beide Attribute bei einem Element
benutzt werden, m ssen 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 ung ltig.
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
[Link]>
UNG LTIGES BEISPIEL:
Der folgende Auszug ist ung ltiges 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 m ssen, 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ürst als auch Dürst g ltige Werte f r 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 verf gbare 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 f r
· 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, f r deren Typ keine Behandlung
festgelegt ist (hier eine Word-Datei vom Typ application/msword), geschehen soll:
Anmerkung: Die Auswahlm=glichkeit „Sffnen“ f hrt 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
[Link]>
·· 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 „[Link]“. 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"
"[Link]
<HTML>
<HEAD>
<TITLE>Chapter 2</TITLE>
<LINK rel="Index" href="../[Link]">
<LINK rel="Next" href="[Link]">
<LINK rel="Prev" href="[Link]">
</HEAD>
...Der Rest des Dokuments...
12.3.1 [Link]- und [Link]-Links
Die rel- und rev-Attribute spielen entgegengesetzte Rollen – das rel-Attribut spezifiziert einen
Vorw@rts-Link und das rev-Attribut einen R ckw@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 f r 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 f r Suchmaschinen
bereitzustellen, darin enthalten:
·
Die HTML 4.01- Spezifikation
Verweise zu alternativen in anderen menschlichen Sprachen geschriebenen Versionen des
Dokuments
· Verweise zu alternativen f r andere Medien gestaltete Versionen, beispielsweise eine spe-
ziell f r 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 f r 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="[Link]
<LINK title="Das Handbuch auf portugiesisch"
type="text/html"
rel="alternate"
hreflang="pt"
href="[Link]
<LINK title="Das Handbuch auf arabisch"
type="text/html"
rel="alternate"
charset="ISO-8859-6"
hreflang="ar"
href="[Link]
<LINK lang="fr" title="La documentation en Français"
type="text/html"
rel="alternate"
hreflang="fr"
href="[Link]
</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
[Link]>
rel="alternate"
href="[Link]
</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="[Link]
</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 f r 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 w rden die folgende BASE- und A-Deklaration:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"[Link]
<HTML>
<HEAD>
<TITLE>Unsere Produkte</TITLE>
<BASE href="[Link]
< 192 > Links
Page size: 168,00 x 240,00 mm
</HEAD>
<BODY>
<P>Haben Sie unsere <A href="../cages/[Link]">Vogelk]fige</A> gesehen?
</BODY>
</HTML>
Die HTML 4.01- Spezifikation
den relativen URI „../cages/[Link]“ aufl=sen in:
[Link]
12.4.1 Relative URIs auflUsen
Benutzerprogramme m ssen den Basis-URI f r die Aufl=sung relativer URIs gem@ß [RFC1808],
Abschnitt 3 ermitteln. Nachfolgend ist beschrieben, wie [RFC1808] speziell in HTML angewen-
det wird.
Benutzeragenten m ssen 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 g ltiges 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 f r 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-
gef hrt 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
[Link]>
<BODY>
<P>Hier ist eine Großaufnahme des Grand Canyon:
<OBJECT data="[Link]" type="image/png">
Dies ist eine <EM>Großaufnahme</EM> des Grand Canyon.
</OBJECT>
Die HTML 4.01- Spezifikation
</BODY>
Fr here 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 zuk nftige 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, f hrt HTML 4 das Element OBJECT ein, das eine universelle
L=sung f r die allgemeine Objekteinbindung anbietet. Das OBJECT-Element erlaubt HTML-Auto-
ren, alle f r 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 f r diese Dinge sind: App-
lets, Plug-Ins, Medien-Handler usw.
Das neue Element OBJECT bernimmt so einige Aufgaben, die von bestehenden Elementen aus-
gef hrt 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 f r die Implementierung zuk nftiger 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 f r
Die HTML 4.01- Spezifikation
die Multimedia-Einbindung und zum Erstellen von Imagemaps daf r zur Verf gung 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-
kn pfte Imagemap, dann sollte dieses Attribut Informationen ber den Inhalt der Imagemap
anbieten. Dies ist besonders wichtig f r 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 f r den Zugriff auf die longdesc-Quelle des ersteren
von dem Mechanismus f r 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 R ckw@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
[Link]>
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
f r links oder rechts ausgerichtete Bilder, die aus dem Textfluss herausfließen.
In einem fr heren Beispiel haben wir einen Verweis zu einem Familienfoto definiert. Hier f gen
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="[Link]
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="[Link]
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 m ssen alternativen Text darstellen, wenn sie keine
Bilder unterst tzen, bestimmte Bildtypen nicht unterst tzen 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-
f hrlichere Beschreibung zu verweisen:
<BODY>
<P>
<IMG src="[Link]"
alt="HP Labs Site Map"
longdesc="[Link]">
</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 [Link].
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
[Link]>
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 f r nicht unterst tzte 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 f r 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 f r nicht unterst tzte Inhalts-
typen zu vermeiden. Unterscheidet sich der Wert dieses Attributs vom HTTP-Inhaltstyp,
der vom Server zur ckgegeben 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 f r das Objekt enthalten.
Darin eingeschlossen k=nnen die Quellen sein, die durch die Attribute classid und data
bezeichnet sind. Archive vorab herunterzuladen, f hrt im Allgemeinen zu einer verringerten
Ladezeit f r 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 Verf gung, 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 (Formular bertragung)
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 unterst tzen, verwen-
den Benutzerprogramme im Allgemeinen externe Anwendungen. Das Element OBJECT gestattet
dem Autor die Kontrolle dar ber, 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 ausf hrbaren 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 f r Parameter fordern.
Das Element OBJECT gestattet zwar Autoren die Angabe aller drei Datentypen, jedoch m ssen
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 f r 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 f r diese Implementierung verwenden. Um f r 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
[Link]>
13.3.1 Regeln zur Darstellung von Objekten
Benutzerprogramme m ssen 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 f gen 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="[Link]
</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="[Link]
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="[Link]
<!- - Sonst, versuche das MPEG-Video - ->
<OBJECT data="[Link]" type="application/mpeg">
<!- - Sonst, versuche das GIF-Bild - ->
<OBJECT data="[Link]" 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 f r 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 bem hen wird, die Datei „[Link]“ 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
[Link]>
value = cdata
Dieses Attribut gibt den Wert eines Laufzeitparameters an, der von name spezifiziert wird.
Eigenschaftswerte haben keine Bedeutung f r 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 f r 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 f r 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 f r valuetype der Wert ref angegeben ist. Dieses Attribut gibt so
den Typ der Werte f r 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 m ssen 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 zur ck, 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="[Link]
<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 f r 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="[Link]
standby="Elvis wird geladen ...">
<PARAM name="Init_values"
value="./images/[Link]">
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, m ssen Benutzerprogramme den Inhalt nur nach PARAM-
Elementen durchsuchen, die direkte Kinder sind und das OBJECT damit „f ttern“.
Daraus abgeleitet gilt f r das folgende Beispiel, dass „param1“ f r „obj1“ (und nicht f r „obj2“)
gilt, wenn „obj1“ dargestellt wird. Wird „obj1“ nicht dargestellt, jedoch „obj2“, dann wird „pa-
ram1“ ignoriert und „param2“ gilt f r „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, „Einf hrung 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. F r 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 f r ActiveX-Applets k=nnen Autoren das
„clsid“ verwenden.
Im folgenden Beispiel f gen wir ein Java-Applet in ein HTML-Dokument ein.
<P><OBJECT classid="java:[Link]">
</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:[Link]">
</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
[Link]>
<OBJECT codetype="application/java-archive"
classid="java:[Link]">
codebase="[Link]
</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="[Link]
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 f r 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 f r andere Objekte anzugeben.
Um ein Objekt zu deklarieren, ohne dass es ausgef hrt wird, wenn das Benutzerprogramm es
ausliest, setzt man das Boolesche Attribut declare im OBJECT-Element. Zur gleichen Zeit m ssen
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.
F r 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="[Link]"
data="[Link]"
type="application/mpeg">
Die <STRONG>Erde</STRONG> aus dem All betrachtet.
</OBJECT>
...sp3ter im Dokument...
<P>Eine tolle <A href="#[Link]"> 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="#[Link]"></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 f r diesen Parameter ist seinerseits ein Objekt, welches das Schriftart-Objekt
einf gt (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="[Link]">
</OBJECT>
...betrachte das Gedicht in [Link] hier...
<P><OBJECT classid="[Link]
data="[Link]">
<PARAM name="font" valuetype="object" value="#tribune">
<P>Ihnen fehlt ein wirklich cooler Gedichtbetrachter ...
</OBJECT>
Benutzerprogramme, die das Attribut declare nicht verstehen, m ssen 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 f r 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
[Link]>
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 Ber cksichtigung von „codebase“ des Applets auf-
gel=st. Entweder muss code oder object vorhanden sein.
name = cdata [CS]
Dieses Attribut gibt einen Namen f r 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 f r 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 f r 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 g ltig waren, als das Objekt serialisiert wur-
de, werden nicht wieder hergestellt. Jegliche Attribute, die an diese APPLET-Instanz bergeben
werden, werden f r das Applet zur Verf gung stehen. Autoren sollten dieses Feature mit gro-
ßer Vorsicht einsetzen. Ein Applet sollte vor der Serialisierung angehalten werden.
Entweder code oder object m ssen 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 unterst tzte 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 f r Benutzerprogramme, die
dieses Element nicht unterst tzen oder so konfiguriert sind, dass sie Applets nicht zu unterst t-
zen. Andernfalls m ssen Benutzerprogramme den Inhalt ignorieren.
< 206 > Objekte, Bilder und Applets
Page size: 168,00 x 240,00 mm
MISSBILLIGTES BEISPIEL:
Im folgenden Beispiel f gt 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="[Link]" 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:[Link]"
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="[Link]|[Link]">
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="[Link]|[Link]">
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 f r 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 f r Ziel-
Frames angeben“ finden Sie Details) und kann vom Benutzerprogramm als Fokus f r 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
[Link]>
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 ausgef hrt.
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 f r 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 f hrt irgendwelche Funktionen aus.
Client-seitige Imagemaps werden den Server-seitigen Imagemaps aus mindestens zwei Gr nden vor-
gezogen: Sie sind zug@nglicher f r Menschen, die mit nicht visuellen Benutzerprogrammen surfen, und
sie geben eine direkte R ckmeldung, 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 endg ltigen 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
[Link]>
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 Verf gung.
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-
gedr ckt, 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 verkn pft. Das Ele-
ment MAP kann als allgemeiner Navigationsmechanismus ohne ein verkn pftes Bild verwendet
werden.
Die Gegenwart eines usemap-Attributs in einem OBJECT bedingt, dass dieses eingebettete Objekt
ein Bild ist. Wenn das Element OBJECT dar ber hinaus eine verkn pfte 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 ausf hren zu m ssen; das Benutzerprogramm kann sogar entscheiden, das referenzierte
Objekt nicht zu laden (oder auszuf hren). Hat ein OBJECT-Element eine verkn pfte Imagemap,
sollten Autoren nicht erwarten, dass dieses Objekt von jedem Benutzerprogramm empfangen
oder ausgef hrt 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
Hierf r m ssen Autoren einen alternativen Text f r 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),
m ssen 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 f r den Fall, dass die Graphiken nicht verf gbar 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 f r 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="[Link]" type="image/gif" usemap="#map1">
<MAP name="map1">
<P>Navigiere durch die Web-Seiten:
<A href="[Link]" shape="rect" coords="0,0,118,28">Hilfe</a> |
<A href="[Link]" shape="rect" coords="118,0,184,28">Gehe zu</A> |
<A href="[Link]" shape="circle" coords="184,200,60">Suchen</A> |
<A href="[Link]" 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
[Link]>
</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 verkn pfen 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="[Link]" type="image/gif" usemap="#map1">
</OBJECT>
...der Rest der Seite hier...
<MAP name="map1">
<P>Navigiere durch die Seite:
<A href="[Link]" shape="rect" coords="0,0,118,28">Hilfe</a> |
<A href="[Link]" shape="rect" coords="118,0,184,28">Gehe zu</A> |
<A href="[Link]" shape="circle" coords="184,200,60">Suchen</A> |
<A href="[Link]" 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="[Link]" type="image/gif" usemap="#map1">
<P>Dies ist eine Navigationsleiste.
</OBJECT>
<MAP name="map1">
<AREA href="[Link]"
alt="Hilfe"
shape="rect"
coords="0,0,118,28">
<AREA href="[Link]"
alt="Suchen"
shape="rect"
coords="184,0,276,28">
<AREA href="[Link]"
alt="Gehe zu"
shape="circle"
coords="184,200,60">
<AREA href="[Link]"
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="[Link]" usemap="#map1" alt="Navigationsleiste">
Das folgende Beispiel zeigt, wie Imagemaps gemeinsam verwendet werden k=nnen.
Verschachtelte OBJECT-Elemente sind n tzlich, um Ausweichm=glichkeiten parat zu halten, falls
ein Benutzerprogramm ein bestimmtes Format nicht unterst tzt. Zum Beispiel:
<P>
<OBJECT data="[Link]" type="image/png">
<OBJECT data="[Link]" type="image/gif">
Text, der das Bild beschreibt...
</OBJECT>
</OBJECT>
Unterst tzt das Benutzerprogramm das PNG-Format nicht, versucht es, das GIF-Bild darzustel-
len. Wenn es GIF nicht unterst tzt (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 f r diese Ele-
mente gemeinsam nutzen.
<P>
<OBJECT data="[Link]" type="image/png" usemap="#map1">
<OBJECT data="[Link]" type="image/gif" usemap="#map1">
<MAP name="map1">
<P>Navigate the site:
<A href="[Link]" shape="rect" coords="0,0,118,28">Hilfe</a> |
<A href="[Link]" shape="rect" coords="118,0,184,28">Gehe zu</A> |
<A href="[Link]" shape="circle" coords="184,200,60">Suchen</A> |
<A href="[Link]" 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
[Link]>
<A href="[Link]" 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 f r eine
client-seitige Imagemap zu kompliziert ist.
Eine server-seitige Imagemap kann nur f r 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 ausgedr ckt. 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="[Link]
<IMG src="[Link]" 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 „[Link]
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 f r 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 verf g-
baren Raum beziehen, der aktuell zur Verf gung 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 f r 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
[Link]>
Die folgenden Werte f r 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 f r 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 unterst tzt Benutzer ohne graphische Anzeigeterminals, Benutzer, deren Browser keine
Formulare unterst tzen, 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 f r die Elemente IMG und AREA angegeben werden. Es ist optional f r 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 f r 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 nachdr cklich
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 f r 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, f hrten 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 f r einige Leuten manchmal, nicht f r alle Leuten f r immer. Diese Techniken sind es:
·· Propriet@re HTML-Erweiterungen
Text in Graphiken umwandeln
·· Graphiken f r 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 f r 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 Einr ckung von Zeilen zu steuern, Farben f r Text und Hintergrund
festzulegen, Schriftgr=ße und -art und eine F lle weiterer Details zu steuern.
Zum Beispiel bestimmt das folgende kurze CSS-Stylesheet (gespeichert in der Datei [Link])
die gr ne Textfarbe des Absatzes und umrandet diesen mit einer geschlossenen roten Linie:
Stylesheets < 217 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
[Link] {
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"
"[Link]
<HTML>
<HEAD>
<LINK href="[Link]" rel="stylesheet" type="text/css">
</HEAD>
<BODY>
<P class="special">Dieser Absatz sollte speziellen grUnen Text enthalten.</P>
</BODY>
</HTML>
HTML 4 unterst tzt 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 f r einen gesamten Website zu verwalten, beschreibt diese Spe-
zifikation wie HTTP-Header verwendet werden k=nnen, um einem Dokument Stylesheets
zuzuweisen.
[Link] von bestimmten Stylesheet-Sprachen
Diese Spezifikation bindet HTML nicht an irgendeine bestimmte Stylesheet-Sprache. Sie
erlaubt die Verwendung unterschiedlicher Sprachen, zum Beispiel einfache Sprachen f r die
Mehrheit der Benutzer und komplexere f r 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 f r 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 gegen ber den zuvor gelesenen. Nicht
alle Stylesheet-Sprachen sind kaskadierend.
[Link]
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 f r Computer, die mit Windows, Macintosh
< 218 > Stylesheets
Page size: 168,00 x 240,00 mm
OS und X11 laufen, mit Zusatzger@ten f r 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 f r die Ausgabe am Bildschirm gedacht ist, kann auch zum Drucken geeignet
sein, ist jedoch f r sprachbasierte Browser wenig hilfreich. Diese Spezifikation erlaubt
Ihnen, die groben Medienkategorien zu definieren, f r 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 f r ein CSS-Stylesheet, das Formatie-
rungen f r mehrere Ausgabemedien enth@lt, finden Sie in Abschnitt 7.2.1 der CSS2-Spe-
zifikation. In Anhang A von CSS2 finden Sie ein Stylesheet f r HTML 4-Dokumente.
Auch dieses Stylesheet besitzt Formatierungsregeln f r 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 f r 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 f r 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 verf gbar, wenn ein Benutzerprogramm die betref-
fenden Elemente darstellen m=chte.
In vielen F@llen werden Autoren den Vorteil eines gemeinsamen Stylesheets f r mehrere
Dokumente nutzen. In diesem Fall wird die Verwendung von Formatierungsregeln innerhalb
des Dokuments zu einer geringeren Leistung f hren, als wenn auf ein Stylesheet verwiesen
w rde, da f r die meisten Dokumente bereits ein Stylesheet im lokalen Cache vorhanden
sein wird. Die =ffentliche Verf gbarkeit 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
[Link]>
Jede Stylesheet-Sprache kann mit HTML verwendet werden. Eine einfache Stylesheet-Sprache
kann den Anforderungen der meisten Benutzer gen gen, andere Sprachen k=nnen jedoch f r
hochspezialisierte Anforderungen eher geeignet sein. Diese Spezifikation verwendet f r 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 m ssen die Stylesheet-Sprache angeben, die f r die Formatierungsinformationen eines
HTML-Dokuments gelten soll.
Anmerkung der bersetzer: Die praktische Relevanz dieses Abschnitts ist ziem-
lich gering: F r den Fall, dass Formatierungsinformationen im Element STYLE im Kopf
der HTML-Datei stehen, muss zwingend das Attribut type die Stylesheet-Sprache ange-
ben. F r 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 f r ein
Dokument zu bestimmen. Um die Voreinstellung zum Beispiel auf CSS zu setzen, sollten Auto-
ren die folgende Deklaration in den HEAD ihrer Dokumente einf gen:
<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 f r die Stylesheet-Sprache f r 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 f r die Stylesheet-Sprache.
2. Anderenfalls, wenn irgendwelche HTTP-Header den „Content-Style-Type“ angeben,
bestimmt die letzte Angabe in der Dokumentzeichenfolge die Voreinstellung f r die Style-
sheet-Sprache.
3. Ansonsten ist die Voreinstellung f r 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 f r Stylesheet-Informationen generieren ( blicherweise eine META-De-
klaration), so dass Benutzerprogramme sich nicht auf die Voreinstellung „text/css“ berufen
Die HTML 4.01- Spezifikation
m ssen.
14.2.2 Inzeilige Formatierungsinformation
Attributdefinitionen
style = style [CN]
Dieses Attribut gibt Formatierungsinformationen f r 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 f r 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
f r „Cascading Style Sheets, Level 2“, der erkl@rt, dass Deklarationen f r denselben
Selektor in durch Semikolons (;) voneinander getrennten Gruppen angeordnet werden
k=nnen.
Dieses CSS-Beispiel legt die Farbe und die Schriftgr=ße f r 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 f r 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
[Link]>
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 m ssen einen Wert f r dieses Attribut angeben; es gibt keinen
Standardwert f r dieses Attribut.
media = media-descriptors [CI]
Dieses Attribut gibt das anvisierte Zielmedium f r die Formatierungsinformationen an. Es
kann eine einzelne Medienbeschreibung sein oder eine durch Kommata getrennte Liste.
Der Standardwert f r dieses Attribut ist „screen“ f r die Bildschirmausgabe.
Anmerkung der bersetzer: Bislang spielt keine andere Stylesheet-Sprache
außer CSS eine Rolle f r 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.) F r 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 unterst tzen beziehungsweise die von einem STYLE-
Element verwendete spezifische Stylesheet-Sprache nicht unterst tzen, m ssen den Inhalt des
STYLE-Elements verbergen. Es ist ein Fehler, den Inhalt als Teil des Dokumenttextes darzustel-
len. Einige Stylesheet-Sprachen unterst tzen 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 f r:
· 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 f r H1-Elemente einer bestimmten
Klasse gelten soll, ver@ndern wir sie wie folgt:
<HEAD>
<STYLE type="text/css">
[Link] {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 f r 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">
[Link]-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
[Link]>
Im folgenden Beispiel verwenden wir DIV und das class-Attribut, um die Textausrichtung f r
diejenigen Abs@tze festzulegen, die den zusammenfassenden Abschnitt eines wissenschaftlichen
Beitrags ausmachen. Diese Formatierungsinformation kann f r 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">
[Link] { 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 f r 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 f r den „normalen“ Einsatz im
Web (letzteres wird dann nat rlich ber CSS-Anweisungen f r „screen“ formatiert).
< 224 > Stylesheets
Page size: 168,00 x 240,00 mm
Dieses Beispiel f gt Ankern Soundeffekte hinzu, wenn eine Sprachausgabe verwendet wird:
<STYLE type="text/css" media="aural">
A { cue-before: uri([Link]); cue-after: uri([Link])}
</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 f r das aktuelle Ger@t aus dem Netz laden. Zum Beispiel k=nnen sprachbasierte
Browser den Download von Stylesheets vermeiden, die f r die optische Darstellung entworfen
worden sind. Beachten Sie den Abschnitt 14.4.1, „Medienabh@ngige Kaskaden“, f r 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
verkn pfen. 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 f r
kleine Displays angeben und ein anderes f r 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
[Link]>
Namen anwenden. Benutzerprogramme d rfen 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 m ssen.
Benutzerprogramme m ssen 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
unterst tzten 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 Verf gung 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 [Link]
abgelegt ist:
<LINK href="[Link]" rel="stylesheet" type="text/css">
Die Angabe des Attributs title verwandelt dieses Stylesheet in das vom Autor bevorzugte
Stylesheet:
<LINK href="[Link]" title="compact" rel="stylesheet" type="text/css">
Der Zusatz des Schl sselworts „alternate“ zum Attribut rel verwandelt es in ein alternatives
Stylesheet:
<LINK href="[Link]" 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="[Link]"
rel="stylesheet"
type="text/css" />
<link href="[Link]"
title="Große Schrift"
rel="stylesheet"
type="text/css" />
<link href="[Link]"
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 gew nschten 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 einf gen:
<META http-equiv="Default-Style" content="compact">
Externe Stylesheets < 227 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
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 unterst tzen 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 „[Link]“ anwenden. W@hlt der Benutzer das For-
mat „big print“, werden nur das alternative Stylesheet „[Link]“ und das best@ndige „com-
[Link]“ verarbeitet.
<LINK rel="alternate stylesheet" title="compact" href="[Link]"
type="text/css">
<LINK rel="alternate stylesheet" title="compact" href="[Link]"
type="text/css">
<LINK rel="alternate stylesheet" title="big print" href="[Link]"
type="text/css">
<LINK rel="stylesheet" href="[Link]" type="text/css">
Hier das Beispiel einer Kaskade. Es wird sowohl das LINK- als auch das STYLE-Element einbezo-
gen.
<LINK rel="stylesheet" href="[Link]" type="text/css">
<LINK rel="stylesheet" href="[Link]" type="text/css">
<STYLE type="text/css">
[Link] { color: rgb(230, 100, 180) }
</STYLE>
< 228 > Stylesheets
Page size: 168,00 x 240,00 mm
14.4.1 [Link] Kaskaden
Eine Kaskade kann Stylesheets einschließen, die f r verschiedene Medien geeignet sind. Sowohl
LINK als auch STYLE k=nnen das Attribut media verwenden. Das Benutzerprogramm ist dann
Die HTML 4.01- Spezifikation
daf r verantwortlich, die Stylesheets herauszufiltern, die f r 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 f r die Druckausgabe, eine f r die Bildschirm-
ausgabe und eine f r sprachbasierte Browser (n tzlich, sagen wir mal, um E-Mails im Auto zu
„lesen“). Das Stylesheet „techreport“ gilt f r alle Medien. Die Farbregel des STYLE-Elements
wird f r die Druck- und Bildschirmausgabe verwendet, jedoch nicht f r die Sprachausgabe.
<LINK rel="stylesheet" media="aural" href="[Link]" type="text/css">
<LINK rel="stylesheet" media="screen" href="[Link]" type="text/css">
<LINK rel="stylesheet" media="print" href="[Link]" type="text/css">
<LINK rel="stylesheet" href="[Link]" type="text/css">
<STYLE media="screen, print" type="text/css">
[Link] { color: rgb(230, 100, 180) }
</STYLE>
14.4.2 Vererbung und Kaskadierung
M=chte das Benutzerprogramm ein Dokument darstellen, muss es Werte f r die Formateigen-
schaften finden, zum Beispiel f r 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
f r 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. F r diese Eigenschaften bie-
tet die Stylesheet-Sprache voreingestellte Werte an, die angewendet werden, wenn keine
expliziten Regeln f r 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 daf r existiert. Dieser Vorgang wird fortgef hrt bis
eine geeignete Regel gefunden wird. Dieser Mechanismus erlaubt die kompakte Angabe von
Stylesheets. Zum Beispiel k=nnen Autoren die Schriftart f r alle Elemente innerhalb des BODY
durch eine einzige Regel festlegen, die f r das Element BODY gilt.
14.5 Formatierungsangaben vor Benutzerprogrammen
verbergen
Einige Stylesheet-Sprachen unterst tzen eine Syntax, die Autoren erlaubt, den Inhalt eines
STYLE-Elements vor nicht konformen Benutzerprogrammen zu verbergen.
Dieses Beispiel zeigt f r 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
[Link]>
<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 f r 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: <[Link] REL=stylesheet
der Angabe
<LINK rel="stylesheet" href="[Link]
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 Schl sselwort
„alternate“ f r das rel-Attribut nicht gesetzt ist.
Link: <[Link]>; rel="stylesheet"; title="compact"
Link: <[Link]>; 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 sch tzen, dass die Kaskadierungsreihenfolge f r Stylesheets ber hrt wird, die ber
Link Header angegeben werden, k=nnen Autoren die Header-Verkettung verwenden, um meh-
rere Instanzen eines Header-Feldes zusammenzulegen. Die Anf hrungszeichen 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 Sicherheitsl cken in Mail-Programmen
werden erst durch HTML-Mails und darin eingebettete Programme zu einem Problem.
An dieser Stelle wollen wir kein Urteil f r 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
m ssen.
Die HTML 4.01- Spezifikation
15 Ausrichtung, Schriftarten und
horizontale Linien
Dieser Abschnitt der Spezifikation er=rtert einige HTML-Elemente und -Attribute, die f r 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. F r 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
[Link]>
Die Voreinstellung h@ngt von der Textflussrichtung ab. F r Text, der von links nach rechts ver-
l@uft, ist die Voreinstellung align=left, w@hrend f r 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 w rde. 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">
[Link] {text-align: center}
</STYLE>
<BODY>
<H1 class="wood"> Wie Holz geschnitzt wird </H1>
Anmerkung der bersetzer: class ist nat rlich 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 w rde mit CSS so aussehen:
<HEAD>
<TITLE>Wie Holz geschnitzt wird</TITLE>
<STYLE type="text/css">
[Link] {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">
[Link] {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 f r 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
[Link]>
· 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 daf r kann das align-Attribut gesetzt werden, denn nur daf r 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="[Link] 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. F r 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 f r 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
ber cksichtigt 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 Zeilenumbr che f r 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 f r 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
[Link]>
********* -------
| | -------
| 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 er brigt
sich in den weitaus meisten Einsatzf@llen nicht erst, seit Stylesheets zur Verf gung 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. Daf r bietet HTML jedoch das f r 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, f r die in der Mehrzahl der im Web zu sehen-
den Anwendungsf@lle, deren Autoren besser EM und KBD verwendet h@tten. Leider
unterst tzen eine Reihe von HTML-Editoren die Verbreitung dieser „Unsitte“, indem
sie B per Mausklick anbieten, STRONG aber in den Tiefen ihrer Men s 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é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
[Link]>
brauchen.</p>
<p><i>Antoine de Saint-Exupé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 m ssen richtig verschachtelt sein. Die Darstellung von verschachtelten
Schriftformat-Elementen ist abh@ngig vom Benutzerprogramm.
15.2.2 Schriftart [Link] 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 f r 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 verf gbar 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
[Link]>
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 f r 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 f r 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 Verf gung 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
[Link]>
Hier ist ein einfaches Frame-Dokument:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"[Link]
<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 f r Benutzerprogramme anbietet, die Frames nicht unterst tzen
oder so konfiguriert sind, dass sie keine Frames darstellen.
Elemente, die normalerweise im BODY-Element erscheinen w rden, d rfen nicht vor dem ersten
FRAMESET-Element stehen, sonst wird das FRAMESET ignoriert.
16.2.1 Das Element FRAMESET
<![ %[Link]; [
<!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
[Link]>
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 f r Spalten und von oben nach unten f r 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 Pixeln
(n tzlich um z. B. ein Bild mit bekannter Gr=ße zu beherbergen). Die erste Spalte erh@lt 25%
des brig gebliebenen Platzes und die dritte erh@lt 75% davon:
<FRAMESET cols="1*,250,3*">
...der Rest der Definition...
</FRAMESET>
< 244 > Frames
Page size: 168,00 x 240,00 mm
Anmerkung der bersetzer:
Die HTML 4.01- Spezifikation
Das n@chste Beispiel erzeugt ein 2x3-Gitter mit Unterr@umen:
<FRAMESET rows="30%,70%" cols="33%,34%,33%">
...der Rest der Definition...
</FRAMESET>
Anmerkung der bersetzer:
Nehmen Sie f r das folgende Beispiel an, ein Browser-Fenster sei aktuell 1000 Pixel hoch. Der
ersten Ansicht werden 30% der gesamten H=he zugeteilt (300 Pixel). Der zweiten Ansicht sind
genau 400 Pixel H=he zugewiesen. Das l@sst 300 Pixel brig, die unter den beiden verbliebenen
Frames aufgeteilt werden m ssen. Die H=he des vierten Frames ist mit „2*“ angegeben. Damit
ist er zweimal so hoch wie der dritte Frame, dessen H=he nur „*“ (@quivalent zu „1*“) ist. Des-
halb wird der dritte Frame 100 Pixel hoch sein und der vierte 200 Pixel.
Frame-Layout < 245 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<FRAMESET rows="30%,400,*,2*">
...der Rest der Definition...
</FRAMESET>
Absolute L@ngen, die in der Summe nicht 100% des tats@chlich zur Verf gung stehenden Raums
Die HTML 4.01- Spezifikation
ergeben, sollten vom Benutzerprogramm angeglichen werden. Sofern zu wenig angegeben ist,
sollte der verbleibende Platz jeder Ansicht proportional hinzugef gt werden. Ist zuviel angege-
ben, sollte jede Ansicht in dem Verh@ltnis verkleinert werden, das ihrem angegebenen Anteil
am gesamten Platz entspricht.
Verschachtelte Framesets
Framesets k=nnen beliebig tief verschachtelt werden.
Im folgenden Beispiel teilt der @ußere FRAMESET den verf gbaren Raum in drei gleiche Spalten auf.
Der innere FRAMESET teilt dann den zweiten Bereich in zwei Zeilen unterschiedlicher H=he ein.
<FRAMESET cols="33%, 33%, 34%">
...Inhalt des ersten Frames...
<FRAMESET rows="40%, 50%">
...Inhalt des zweiten Frames, erste Zeile...
...Inhalt des zweiten Frames, zweite Zeile...
</FRAMESET>
...Inhalt des dritten Frames...
</FRAMESET>
Anmerkung der bersetzer:
Daten teilen mit anderen Frames
Autoren k=nnen Daten f r mehrere Frames verwenden, wenn sie diese Daten ber ein
OBJECT-Element einf gen. Autoren sollten das Element OBJECT im HEAD-Element des Frameset-
Dokuments angeben und es mit dem Attribut id benennen. Jedes Dokument, das Inhalt eines
Frames im Frameset ist, kann sich auf diesen Bezeichner beziehen.
Das folgende Beispiel zeigt, wie sich ein Skript auf ein OBJECT-Element beziehen kann, das f r
einen ganzen Frameset definiert ist:
< 246 > Frames
Page size: 168,00 x 240,00 mm
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"[Link]
<HTML>
<HEAD>
<TITLE>Dies ist ein Frameset mit OBJECT im HEAD</TITLE>
Die HTML 4.01- Spezifikation
<!- - Dieses OBJECT wird nicht dargestellt! - ->
<OBJECT id="myobject" data="[Link]"></OBJECT>
</HEAD>
<FRAMESET>
<FRAME src="[Link]" name="bianca">
</FRAMESET>
</HTML>
<!- - In [Link] - ->
<HTML>
<HEAD>
<TITLE>Bianca's Seite</TITLE>
</HEAD>
<BODY>
...der Anfang des Dokuments...
<P>
<SCRIPT type="text/javascript">
[Link]
</SCRIPT>
...der Rest des Dokuments...
</BODY>
</HTML>
Anmerkung der bersetzer: Mehr dazu, wie man in Skripten – hier konkret in Java-
Script – Objekte, Funktionen u.@. frame- bergreifend erreicht und benutzt, finden Sie in der
FAQ auf der Homepage der deutschsprachigen Javascript-Newsgroup unter [Link]
faq/ in der Fragenliste unter „mehr Fenster und Frames - Kommunikation zwischen...“
16.2.2 Das Element FRAME
<![ %[Link]; [
<!- - reserved frame names start with "_" otherwise starts with letter - ->
<!ELEMENT FRAME - O EMPTY - - subwindow - ->
<!ATTLIST FRAME
%coreattrs; - - id, class, style, title - -
longdesc %URI; #IMPLIED - - link to long description
(complements title) - -
name CDATA #IMPLIED - - name of frame for targetting - -
src %URI; #IMPLIED - - source of frame content - -
frameborder (1|0) 1 - - request frame borders? - -
marginwidth %Pixels; #IMPLIED - - margin widths in pixels - -
marginheight %Pixels; #IMPLIED - - margin height in pixels - -
noresize (noresize) #IMPLIED - - allow users to resize frames? - -
scrolling (yes|no|auto) auto - - scrollbar or none - -
>
]]>
Frame-Layout < 247 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Attributdefinitionen
name = cdata [CI]
Dieses Attribut weist dem aktuellen Frame einen Namen (name) zu. Dieser Name kann als
Die HTML 4.01- Spezifikation
Ziel sp@terer Links dienen.
longdesc = uri [CT]
Dieses Attribut spezifiziert einen Link auf eine lange Beschreibung des Frames. Diese
Beschreibung sollte die durch das title-Attribut angebotene kurze Beschreibung erg@nzen,
und kann besonders f r nichtvisuelle Benutzerprogramme n tzlich sein.
src = uri [CT]
Dieses Attribut beschreibt den Ort des Ausgangsinhalts (initial contents), der im Frame
enthalten sein soll.
noresize [CI]
Sofern angegeben, teilt dieses Boolesche Attribut dem Benutzerprogramm mit, dass dieser
Frame nicht gr=ßenver@nderbar ist.
scrolling = auto|yes|no [CI]
Dieses Attribut gibt Scroll-Informationen f r diesen Frame an. M=gliche Werte sind:
· auto: Dieser Wert teilt dem Benutzerprogramm mit, dass es dem Frame-Fenster, wenn
erforderlich, Scroll-Balken geben soll. Dies ist der Standardwert.
· yes: Dieser Wert teilt dem Benutzerprogramm mit, dass es dem Frame-Fenster immer
Scroll-Balken geben soll.
· no: Dieser Wert teilt dem Benutzerprogramm mit, dass es dem Frame-Fenster keine
Scroll-Balken geben soll.
frameborder = 1|0 [CN]
Dieses Attribut versorgt das Benutzerprogramm mit Informationen ber Frame-Rahmen.
M=gliche Werte sind:
· 1: Dieser Wert teilt dem Benutzerprogramm mit, dass es eine Trennlinie zwischen die-
sen und jeden angrenzenden Frame zeichnen soll. Dies ist der Standardwert.
· 0: Dieser Wert teilt dem Benutzerprogramm mit, dass es zwischen diesen und jeden
angrenzenden Frame keine Trennlinie zeichnen soll. Beachten Sie, dass trotzdem Trenn-
linien an den R@ndern dieses Frames dargestellt werden k=nnen, sofern sie von anderen
Frames vorgegeben sind.
marginwidth = pixels [CN]
Dieses Attribut gibt den Abstand an, der zwischen dem Inhalt des Frames und dessen linken
und rechten Rand verbleiben soll. Der Wert muss gr=ßer als Null (Pixel) sein. Der Stan-
dardwert ist vom Benutzerprogramm abh@ngig.
marginheight = pixels [CN]
Dieses Attribut gibt den Abstand an, der zwischen dem Inhalt des Frames und dessen obe-
ren und unteren Rand verbleiben soll. Der Wert muss gr=ßer als Null (Pixel) sein. Der
Standardwert ist vom Benutzerprogramm abh@ngig.
An anderer Stelle definierte Attribute
·· id, class (dokumentweite Identifikatoren)
title (Elementtitel)
· style (inzeilige Formatierungsinformation)
Das Element FRAME definiert den Inhalt und die Darstellung eines einzelnen Frames.
< 248 > Frames
Page size: 168,00 x 240,00 mm
Einem Frame den Ausgangsinhalt zuweisen
Das Attribut src gibt das Anfangsdokument an, das der Frame enthalten wird.
Das folgende HTML-Beispieldokument
Die HTML 4.01- Spezifikation
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"[Link]
<HTML>
<HEAD>
<TITLE>Ein Frameset-Dokument</TITLE>
</HEAD>
<FRAMESET cols="33%,33%,33%">
<FRAMESET rows="*,200">
<FRAME src="inhalt_von_frame1.html">
<FRAME src="inhalt_von_frame2.gif">
</FRAMESET>
<FRAME src="inhalt_von_frame3.html">
<FRAME src="inhalt_von_frame4.html">
</FRAMESET>
</HTML>
sollte ein Frame-Layout wie dieses erzeugen
und das Benutzerprogramm veranlassen, jede Datei in eine eigene Ansicht zu laden.
Der Inhalt eines Frames darf nicht im gleichen Dokument sein wie die Definition des Frames.
Frame-Layout < 249 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
UNG LTIGES BEISPIEL:
Die folgende Definition eines Framesets ist kein g ltiges HTML, weil der Inhalt des zweiten
Frames im gleichen Dokument ist wie das Frameset.
Die HTML 4.01- Spezifikation
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"[Link]
<HTML>
<HEAD>
<TITLE>Ein Frameset-Dokument</TITLE>
</HEAD>
<FRAMESET cols="50%,50%">
<FRAME src="inhalt_von_frame1.html">
<FRAME src="#anker_im_gleichen_dokument">
<NOFRAMES>
...etwas Text...
<H2><A name="anker_im_gleichen_dokument">Wichtiger Abschnitt</A></H2>
...etwas Text...
</NOFRAMES>
</FRAMESET>
</HTML> n
Visuelle Darstellung eines Frames
Das folgende Beispiel veranschaulicht die Verwendung von dekorativen FRAME-Attributen. Wir
geben an, dass Frame 1 keine Scroll-Balken erlauben wird. Frame 2 wird Abstand um seinen
Inhalt herum lassen (anfangs eine Bild-Datei), die Frame-Gr=ße wird nicht ver@nderbar sein. Es
wird kein Rahmen zwischen den Frames 3 und 4 gezeichnet werden. Rahmen werden (durch
Standardwerte) zwischen den Frames 1, 2 und 3 gezeichnet werden.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"[Link]
<HTML>
<HEAD>
<TITLE>Ein Frameset-Dokument</TITLE>
</HEAD>
<FRAMESET cols="33%,33%,33%">
<FRAMESET rows="*,200">
<FRAME src="inhalt_von_frame1.html" scrolling="no">
<FRAME src="inhalt_von_frame2.gif"
marginwidth="10" marginheight="15"
noresize>
</FRAMESET>
<FRAME src="inhalt_von_frame3.html" frameborder="0">
<FRAME src="inhalt_von_frame4.html" frameborder="0">
</FRAMESET>
</HTML>
< 250 > Frames
Page size: 168,00 x 240,00 mm
Anmerkung der bersetzer:
Die HTML 4.01- Spezifikation
Da f r Frame 2 festgelegt ist, dass der Frame nicht in der Gr=ße ver@ndert werden darf,
gilt das in diesem Fall auch f r Frame 1: Frame 1 hat zwei Grenzen, eine nach unten zu
Frame 2 und eine nach rechts zu Frame 3. Die Grenze zwischen Frame 1 und 2 darf
nicht ver@ndert werden (explizites „noresize“ f r diese Grenze von Frame 2). Die
Grenze zwischen 1 und 3 ist aber die Verl@ngerung der Grenze zwischen 2 und 3. Die
unterliegt ebenfalls dem Verbot.
Die nebenstehende Abbildung zeigt nur das Layout, nicht die Einstellungen f r Rahmen
und R@nder.
16.3 Informationen f-r Ziel-Frames angeben
Anmerkung: Informationen ber die aktuelle Vorgehensweise, das Ziel eines Frames zu bestimmen,
finden Sie in Anhang B unter „Anmerkungen zu Frames“. n
Attributdefinitionen
target = frame-target [CI]
Das Attribut gibt den Namen eines Frames an, in dem ein Dokument ge=ffnet werden soll.
Wird mit Hilfe des Attributs name ein Name f r einen Frame angegeben, k=nnen Autoren die-
sen Frame als Ziel („target“) f r Links verwenden, die von anderen Elementen definiert wer-
den. Das target-Attribut kann in Elementen angegeben werden, die Links erzeugen (A, LINK), in
Imagemaps (AREA) und Formularen (FORM).
Informationen ber reservierte Frame-Namen finden Sie in Abschnitt 6.16, „Namen von Ziel-
Frames“.
Informationen f#r Ziel-Frames angeben < 251 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Dieses Beispiel verdeutlicht, wie Ziele die dynamische Ver@nderung des Frame-Inhalts gestat-
ten. Zuerst definieren wir ein Frameset im Dokument [Link], wie hier gezeigt:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
Die HTML 4.01- Spezifikation
"[Link]
<HTML>
<HEAD>
<TITLE>Ein Frameset-Dokument</TITLE>
</HEAD>
<FRAMESET cols="50%,50%">
<FRAME name="fixed" src="init_fixed.html">
<FRAME name="dynamic" src="init_dynamic.html">
</FRAMESET>
</HTML>
Dann verweisen wir in init_dynamic.html auf den Frame „dynamic“:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"[Link]
<HTML>
<HEAD>
<TITLE>Ein Dokument mit Ankern auf bestimmte Ziele</TITLE>
</HEAD>
<BODY>
...Anfang des Dokuments...
<P>Nun kannst Du weitergehen zu
<A href="[Link]" target="dynamic">Dia 2.</A>
...mehr Dokumentinhalt...
<P>Das machst Du hervorragend. Nun weiter zu
<A href="[Link]" target="dynamic">Dia 3.</A>
</BODY>
</HTML>
Die Aktivierung beider Links =ffnet ein neues Dokument im Frame „dynamic“, w@hrend der
andere Frame, „fixed“, seinen Ausgangsinhalt beibeh@lt.
Anmerkung der bersetzer:
< 252 > Frames
Page size: 168,00 x 240,00 mm
Anmerkung: Die Definition eines Framesets ver,ndert sich nie, aber der Inhalt eines seiner Frames
kann es. Ver,ndert sich der Ausgangsinhalt eines Frames einmal, spiegelt die Definition des Framesets
nicht l,nger den aktuellen Status seiner Frames wieder.
Es gibt zur Zeit keine M glichkeit, den gesamten Zustand eines Framesets in einem URI zu verschls-
Die HTML 4.01- Spezifikation
seln. Deshalb erlauben viele Benutzerprogramme es nicht, ein Lesezeichen fr ein Frameset zu setzen.
Framesets k nnen die Navigation vorw,rts und rckw,rts durch den Seitenverlauf (history) eines Benut-
zerprogramms fr den Benutzer erschweren. n
16.3.1 Das Standardziel (default target) f-r Links festlegen
Geben viele Links im selben Dokument dasselbe Ziel an, ist es m=glich, das Ziel einmal anzuge-
ben und auf das target-Attribut in jedem einzelnen Element zu verzichten. Dies geschieht durch
Angabe des target-Attributs im Element BASE.
Kehren wir zum vorherigen Beispiel zur ck: Diesmal geben wir die Zielinformationen durch
die Definition im Element BASE an und entfernen sie aus den A-Elementen.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"[Link]
<HTML>
<HEAD>
<TITLE>Ein Dokument mit BASE mit einem bestimmten Ziel</TITLE>
<BASE href="[Link] target="dynamic">
</HEAD>
<BODY>
...Anfang des Dokuments...
<P>Nun kannst Du weitergehen zu <A href="[Link]">Dia 2.</A>
...mehr Dokumentinhalt...
<P>Das machst Du hervorragend. Nun weiter zu
<A href="[Link]">Dia 3.</A>
</BODY>
</HTML>
16.3.2 Vorgehensweise zur Zielbestimmung
Benutzerprogramme sollten den Ziel-Frame, in den die referenzierte Quelle geladen werden
soll, der folgenden Vorgehensweisen entsprechend bestimmen (von h=chster Priorit@t zu nied-
rigster):
1. Ist das target-Attribut eines Elements auf einen bekannten Frame gesetzt, wenn das Ele-
ment aktiviert wird (d. h., ein Link wird aktiviert oder ein Formular verarbeitet), sollte die
vom Element bezeichnete Quelle in den Ziel-Frame geladen werden.
2. Ist das target-Attribut f r ein Element nicht gesetzt, jedoch f r das Element BASE, dann
bestimmt das target-Attribut des Elements BASE den Frame.
3. Weist weder das Element noch das BASE-Element auf ein Ziel, dann sollte die vom Element
bezeichnete Quelle in den Frame geladen werden, welcher das Element enth@lt.
4. Verweist irgendein target-Attribut auf einen unbekannten Frame F, dann sollte das Benut-
zerprogramm ein neues Fenster und einen neuen Frame erzeugen, dem Frame den Namen
F zuweisen und die vom Element bezeichnete Quelle in den neuen Frame laden.
Benutzerprogramme k=nnen dem Benutzer einen Mechanismus zur Verf gung stellen, um das
target-Attribut zu berschreiben.
Informationen f#r Ziel-Frames angeben < 253 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
16.4 Alternativer Inhalt
Autoren sollten alternativen Inhalt f r Benutzerprogramme vorhalten, die Frames nicht unter-
st tzen oder so konfiguriert sind, dass sie Frames nicht anzeigen.
Die HTML 4.01- Spezifikation
16.4.1 Das Element NOFRAMES
<![ %[Link]; [
<!ENTITY % [Link] "(BODY) -(NOFRAMES)">
]]>
<!ENTITY % [Link] "(%flow;)*">
<!ELEMENT NOFRAMES - - %[Link];
- - alternate content container for non frame-based rendering - ->
<!ATTLIST NOFRAMES
%attrs; - - %coreattrs, %i18n, %events - -
>
·· 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 Element NOFRAMES gibt Inhalt an, der nur von Benutzerprogrammen angezeigt werden sollte,
die keine Frames unterst tzen oder so konfiguriert sind, dass sie Frames nicht anzeigen. Benut-
zerprogramme, die Frames unterst tzen, m ssen den Inhalt einer NOFRAMES-Deklaration nur
dann anzeigen, wenn sie so konfiguriert sind, dass sie Frames nicht anzeigen. Benutzerprogram-
me, die Frames nicht unterst tzen, m ssen den Inhalt von NOFRAMES in jedem Fall anzeigen.
Das Element NOFRAMES ist sowohl Teil der Transitional DTD als auch der Frameset DTD. In
einem Dokument, das die Frameset DTD verwendet, kann NOFRAMES am Ende des FRAMESET-
Abschnitts des Dokuments verwendet werden.
Zum Beispiel:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"[Link]
<HTML>
<HEAD>
<TITLE>Ein Frameset-Dokument mit NOFRAMES</TITLE>
</HEAD>
<FRAMESET cols="50%, 50%">
<FRAME src="[Link]">
<FRAME src="[Link]">
<NOFRAMES>
<P>Hier ist die <A href="[Link]">
Version des Dokuments ohne Frames.</A>
</NOFRAMES>
</FRAMESET>
</HTML>
< 254 > Frames
Page size: 168,00 x 240,00 mm
NOFRAMES k=nnte zum Beispiel in einem Dokument verwendet werden, das die Quelle eines
Frames ist und die Transitional DTD verwendet. Dies erlaubt es Autoren, den Zweck eines
Dokuments zu erkl@ren, falls es außerhalb eines Framesets betrachtet wird oder mit einem
Benutzerprogramm, das keine Frames unterst tzt.
Die HTML 4.01- Spezifikation
16.4.2 Lange Beschreibung von Frames
Das Attribut longdesc gestattet es Autoren, Frame-Dokumente f r Menschen zug@nglicher zu
machen, die keine visuellen Benutzerprogramme verwenden. Dieses Attribut bezeichnet eine
Quelle, die eine lange Beschreibung f r einen Frame liefert. Autoren sollten beachten, dass der
Inhalt der langen Frame-Beschreibung an den Frame gebunden ist, nicht an den Inhalt des
Frames. Weil der Inhalt mit der Zeit variieren kann, ist es m=glich, dass die anf@ngliche lange
Beschreibung f r den sp@teren Inhalt keine G ltigkeit mehr besitzt. Insbesondere sollten Auto-
ren eine Bilddatei nicht als einzigen Inhalt eines Frames verwenden.
Das folgende Frameset-Dokument beschreibt zwei Frames. Der linke Frame enth@lt ein Inhalts-
verzeichnis und der rechte anf@nglich das Bild eines Straußes:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"[Link]
<HTML>
<HEAD>
<TITLE>Ein ]rmlich gestaltetes Frameset-Dokument</TITLE>
</HEAD>
<FRAMESET cols="20%, 80%">
<FRAME src="[Link]">
<FRAME src="[Link]" longdesc="[Link]">
</FRAMESET>
</HTML>
Beachten Sie, dass dieses Bild unabh@ngig von irgendeinem HTML-Element in den Frame einge-
f gt wurde, so dass der Autor keine M=glichkeit hat, alternativen Text anzugeben als ber das
longdesc-Attribut. Ver@ndert sich der Inhalt des rechten Frames (z. B. wenn der Benutzer eine
Klapperschlange aus dem Inhaltsverzeichnis w@hlt), werden die Benutzer keinen textbasierten
Zugang zum neuen Inhalt des Frames haben.
Deshalb sollten Autoren eine Bilddatei nicht direkt in einen Frame einf gen. Statt dessen sollte
das Bild in einem separaten HTML-Dokument angegeben und dort mit entsprechendem alter-
nativen Text kommentiert werden:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"[Link]
<HTML>
<HEAD>
<TITLE>Ein wohlgestaltetes Frameset-Dokument</TITLE>
</HEAD>
<FRAMESET cols="20%, 80%">
<FRAME src="[Link]">
<FRAME src="[Link]">
</FRAMESET>
</HTML>
Alternativer Inhalt < 255 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!- - In [Link]: - ->
<HTML>
<HEAD>
<TITLE>Der schnelle und kraftvolle Strauß</TITLE>
</HEAD>
Die HTML 4.01- Spezifikation
<P>
<OBJECT data="[Link]" type="image/gif">
Diese Strauße schmecken sicherlich gut!
</OBJECT>
</HTML>
16.5 Eingebettete Frames: das Element IFRAME
<!ELEMENT IFRAME - - (%flow;)* - - inline subwindow - ->
<!ATTLIST IFRAME
%coreattrs; - - id, class, style, title - -
longdesc %URI; #IMPLIED - - link to long description
(complements title) - -
name CDATA #IMPLIED - - name of frame for targetting - -
src %URI; #IMPLIED - - source of frame content - -
frameborder (1|0) 1 - - request frame borders? - -
marginwidth %Pixels; #IMPLIED - - margin widths in pixels - -
marginheight %Pixels; #IMPLIED - - margin height in pixels - -
scrolling (yes|no|auto) auto - - scrollbar or none - -
align %IAlign; #IMPLIED - - vertical or horizontal alignment - -
height %Length; #IMPLIED - - frame height - -
width %Length; #IMPLIED - - frame width - -
>
Attributdefinitionen
longdesc = uri [CT]
Dieses Attribut spezifiziert einen Link auf eine lange Beschreibung des Frames. Diese
Beschreibung sollte die durch das title-Attribut angebotene kurze Beschreibung erg@nzen,
und kann besonders f r nichtvisuelle Benutzerprogramme n tzlich sein.
name = cdata [CI]
Dieses Attribut gibt dem aktuellen Frame einen Namen. Dieser Name kann als Ziel sp@te-
rer Links dienen.
width = length [CN]
Die Breite des eingebetteten Frames.
height = length [CN]
Die H=he des eingebetteten Frames.
An anderer Stelle definierte Attribute
·· id, class (dokumentweite Identifikatoren)
title (Elementtitel)
·· style (inzeilige Formatierungsinformation)
name, src, frameborder, marginwidth, marginheight, scrolling (Frame-Steuerung und -Dekora-
tion)
· align (Ausrichtung)
< 256 > Frames
Page size: 168,00 x 240,00 mm
Das Element IFRAME gestattet dem Autor, einen Frame innerhalb eines Textblocks einzuf gen.
Das Einf gen eines eingebetteten Frames innerhalb eines Textblocks gleicht weitgehend dem
Einf gen eines Objekts ber das Element OBJECT: Sie erlauben beide, ein HTML-Dokument
inmitten eines anderen einzuf gen, sie k=nnen beide mit umgebendem Text ausgerichtet wer-
Die HTML 4.01- Spezifikation
den usw.
Die Information, die eingebettet werden soll, wird durch das Attribut src dieses Elements ange-
geben. Der Inhalt des IFRAME-Elements auf der anderen Seite, sollte nur von Benutzerprogram-
men angezeigt werden, die keine Frames unterst tzen oder die so konfiguriert sind, dass sie
Frames nicht anzeigen.
In Benutzerprogrammen, die Frames unterst tzen, wird das folgende Beispiel einen eingebette-
ten Frame, umgeben von einem Rahmen, inmitten des Texts einf gen:
<IFRAME src="[Link]" width="400" height="500"
scrolling="auto" frameborder="1">
[Ihr Benutzerprogramm unterstUtzt keine Frames oder ist derzeit nicht
konfiguriert, Frames anzuzeigen. Besuchen Sie jedoch
<A href="[Link]">das anzuzeigende Dokument</A>.]
</IFRAME>
Die Gr=ße eingebetteter Frames kann nicht ver@ndert werden (und deshalb akzeptieren sie
das noresize-Attribut nicht).
Anmerkung: HTML-Dokumente k nnen ebenso mit dem Element OBJECT in andere HTML-Doku-
mente eingebettet werden. Einzelheiten dazu finden Sie in Abschnitt 13.5, „Anmerkungen zu eingebet-
teten Dokumenten“. n
17 Formulare
17.1 Einf-hrung in Formulare
Ein HTML-Formular ist ein Abschnitt eines Dokuments, der normalen Inhalt, Bezeichner, spe-
zielle Elemente, genannt Steuerelemente (Checkboxen, Radio-Buttons, Men s und so weiter)
und Beschriftungen f r diese Steuerelemente enth@lt. Benutzer „vervollst@ndigen“ ein Formular
im Allgemeinen durch die Ver@nderung seiner Steuerelemente, bevor das Formular zu einer
Anwendung bertragen wird (zum Beispiel zu einem Webserver, zu einem Mailserver und so
weiter).
Hier ist ein einfaches Formular, das Beschriftungen, Radio-Buttons und Schaltfl@chen (Zur ck-
setzen oder Absenden des Formulars) enth@lt:
<FORM action="[Link] method="post">
<P>
<LABEL for="vorname">Vorname: </LABEL>
<INPUT type="text" id="vorname"><BR>
<LABEL for="nachname">Nachname: </LABEL>
<INPUT type="text" id="nachname"><BR>
<LABEL for="email">E-Mail: </LABEL>
Formulare < 257 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<INPUT type="text" id="email"><BR>
<INPUT type="radio" name="geschlecht" value="Maskulin"> Maskulin<BR>
<INPUT type="radio" name="geschlecht" value="Feminin"> Feminin<BR>
<INPUT type="submit" value="Absenden"> <INPUT type="reset" value="ZurUcksetzen">
</P>
Die HTML 4.01- Spezifikation
</FORM>
Anmerkung: Diese Spezifikation gibt in den Unterabschnitten von „Anmerkungen zu Formularen“
(Anhang B) detailliertere Informationen ber Formulare. n
17.2 Steuerelemente
Benutzer interagieren mit Formularen ber benannte Steuerelemente.
Der „Steuerelementname“ eines Steuerelements wird ber sein name-Attribut zugewiesen. Der
Geltungsbereich des name-Attributs f r ein Steuerelement innerhalb eines FORM-Elements ist das
FORM-Element.
Anmerkung der bersetzer: Ein kleines Beispiel wird das verdeutlichen. Wir
gehen von einer Seite aus, die die beiden folgenden Formulare enth@lt:
<FORM
ACTION="[Link]" METHOD="
get">
<P>
<LABEL FOR="vorname">Vorname: </LABEL>
<INPUT TYPE="text" NAME="vorname"><BR>
<LABEL FOR="nachname">Nachname: </LABEL>
<INPUT TYPE="text" NAME="nachname"><BR>
<LABEL FOR="email">E-Mail: </LABEL>
<INPUT TYPE="text" NAME="email"><BR>
<INPUT TYPE="radio" NAME="geschlecht" VALUE="Maskulin"> Maskulin<BR>
<INPUT TYPE="radio" NAME="geschlecht" VALUE="Feminin"> Feminin<BR>
<INPUT TYPE="submit" VALUE="Absenden">
<INPUT TYPE="reset" VALUE="ZurUcksetzen">
</P>
</FORM>
<FORM ACTION="[Link]" METHOD="get">
<P>
<LABEL FOR="vorname">Vorname: </LABEL>
<INPUT TYPE="text" NAME="vorname"><BR>
<LABEL FOR="nachname">Nachname: </LABEL>
<INPUT TYPE="text" NAME="nachname"><BR>
<INPUT TYPE="submit" VALUE="Absenden">
<INPUT TYPE="reset" VALUE="ZurUcksetzen">
</P>
</FORM>
Beim Absenden des ersten Formulars wird das Perl-Skript [Link] aufgerufen, beim
zweiten [Link]. Beide erwarten Parameter, n@mlich die Werte des ausgef llten
Formulars. F llt man die Formulare aus und schaut nach dem Absenden den URI an, so
erkent man deutlich, dass die Werte des jeweiligen Formulars bertragen werden.
< 258 > Formulare
Page size: 168,00 x 240,00 mm
Die HTML 4.01- Spezifikation
Der URI nach dem bertragen des ersten Formulars:
...[Link]?vorname=Albert&nachname=
Meier&email=[Link]%[Link]&geschlecht=Maskulin
Der URI nach dem bertragen des zweiten Formulars:
...[Link]?vorname=Ruth&nachname=Schulze
„vorname“ und „nachname“ werden in beiden F@llen bergeben, jedoch mit dem einge-
gebenen Wert des jeweiligen Formulars.
Jedes Steuerelement hat sowohl einen Anfangswert als auch einen aktuellen Wert, beide
Werte sind Zeichenketten. In den individuellen Definitionen der Steuerelemente finden Sie
Informationen ber Anfangswerte und m=gliche Beschr@nkungen f r Werte, die vom Steuer-
element auferlegt werden. Im Allgemeinen wird der Anfangswert ber das Attribut value des
Steuerelements angegeben. Jedoch wird der Anfangswert eines TEXTAREA-Elements durch seinen
Inhalt angegeben, und der Anfangswert eines OBJECT-Elements in einem Formular wird durch
die Implementierung des Objekts bestimmt (das heißt, er liegt außerhalb des Geltungsbereichs
dieser Spezifikation).
Der „aktuelle Wert“ eines Steuerelements wird zuerst auf seinen Anfangswert gesetzt. Danach
kann der aktuelle Wert des Steuerelements durch Interaktion des Benutzers oder durch
Skripte ver@ndert werden.
Der Anfangswert eines Steuerelements ver@ndert sich nicht. Wird ein Forumlar zur ckgesetzt,
werden folglich die aktuellen Werte aller Steuerelemente auf ihre Anfangswerte zur ckgesetzt.
Hat ein Steuerelement keinen Anfangswert, ist die Auswirkung einer Zur cksetzung f r dieses
Steuerelement nicht definiert.
Wird ein Formular f r die Verarbeitung bertragen, fassen einige Steuerelemente ihre Namen
mit den aktuellen Werten zu einem Paar zusammen, und diese Paare werden mit dem Formular
bertragen. Steuerelemente, f r die solche Name/Wert-Paare bertragen werden, nennt man
erfolgreiche Steuerelemente (successful controls).
Steuerelemente < 259 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
17.2.1 Steuerelementtypen
HTML definiert die folgenden Steuerelementtypen:
Die HTML 4.01- Spezifikation
[Link]
Autoren k=nnen drei verschiedene Schaltfl@chentypen erzeugen:
· Absenden-Schaltfl@chen (submit buttons): Wird sie aktiviert, sendet die Absenden-
Schaltfl@che ein Formular. Ein Formular kann mehr als eine Absenden-Schaltfl@che ent-
halten.
· Zur cksetzen-Schaltfl@chen (reset buttons): Wird sie aktiviert, setzt eine Zur cksetzen-
Schaltfl@che alle Steuerelemente auf ihren Anfangswert zur ck.
· Allgemeine Schaltfl@chen (push buttons): Allgemeine Schaltfl@chen zeigen kein voreinge-
stelltes Verhalten. Jede Schaltfl@che kann ber die Event-Attribute des Elements mit
einem Client-seitigen Skript verbunden sein. Wird das Event ausgel=st (zum Beispiel
wenn der Benutzer eine Schaltfl@che dr ckt, losl@sst und so weiter), wird das entspre-
chende Skript ausgef hrt.
Autoren sollten die Skriptsprache f r das Skript einer allgemeinen Schaltfl@che ber
eine Deklaration der Standard-Skriptsprache (siehe Abschnitt 18.2.2) angeben (mit dem
Element META).
Autoren k=nnen Schaltfl@chen mit den Elementen BUTTON oder INPUT erzeugen. Details ber
die Angabe unterschiedlicher Schaltfl@chentypen finden Sie in den Definitionen dieser Ele-
mente.
Anmerkung: Autoren sollten beachten, dass BUTTON -Elemente mehr Darstellungsm glichkeiten
bieten als INPUT-Elemente. n
Checkboxen
Checkboxen und Radio-Buttons sind Ein/Aus-Schalter, die vom Benutzer geschaltet werden
k=nnen. Ein Schalter ist auf „Ein“ gesetzt, wenn das Attribut checked eines Steuerelements
angegeben ist. Wird ein Formular bertragen, k=nnen nur Checkbox-Steuerelemente
erfolgreich werden, die auf „Ein“ stehen.
Einige Checkboxen in einem Formular k=nnen den gleichen Steuerelementnamen teilen. So
gestatten es Checkboxen zum Beispiel, mehrere Werte f r die gleiche Eigenschaft aus-
zuw@hlen. Checkbox-Steuerelemente werden mit dem Element INPUT erzeugt.
Radio-Buttons
Radio-Buttons gleichen normalen Checkboxen, wenn jedoch mehrere den gleichen Steuer-
elementnamen teilen, schließen Sie sich gegenseitig aus: ist eine Auswahl eingeschaltet, sind
alle anderen mit dem gleichen Namen ausgeschaltet. Steuerelemente vom Typ Radio-But-
ton werden mit dem Element INPUT erzeugt.
Ist zu Beginn kein Radio-Button in einer Gruppe mit Elementen gleichen Namens einge-
schaltet, dann ist nicht definiert, welches Steuerelement ein Benutzerprogramm zu Beginn
einschalten soll. Anmerkung: Weil bestehende Implementationen diese F@lle unterschiedlich
behandeln, weicht die aktuelle Spezifikation von RFC 1866 ([RFC1866] Abschnitt [Link])
ab, welcher aussagt: Zu allen Zeiten ist genau ein Radio-Button in einer Gruppe ausgew@hlt.
Ist f r keines der <INPUT>-Elemente einer Gruppe mit Radio-Button das Attribut CHECKED
gesetzt, dann muss das Benutzerprogramm den ersten Radio-Button der Gruppe zu Beginn
ausw@hlen.
< 260 > Formulare
Page size: 168,00 x 240,00 mm
Weil sich die Vorgehensweise der Benutzerprogramme voneinander unterscheidet, sollten
Autoren sicherstellen, dass in jeder Gruppe mit Radio-Buttons einer zu Beginn eingeschal-
tet ist.
Men-s
Die HTML 4.01- Spezifikation
Men s bieten Benutzern Auswahlm=glichkeiten, aus denen sie w@hlen k=nnen. Das Element
SELECT erzeugt in Verbindung mit den Elementen OPTGROUP und OPTION ein Men .
Texteingabe
Autoren k=nnen zwei verschiedene Steuerelementtypen einsetzen, die Benutzern die Text-
eingabe gestatten. Das Element INPUT erzeugt ein Eingabe-Steuerelement mit einer einzel-
nen Zeile, und das Element TEXTAREA erzeugt ein Eingabe-Steuerelement mit mehreren Zei-
len. In beiden F@llen wird der Eingabetext zum aktuellen Wert des Steuerelements.
Dateiauswahl
Dieser Steuerelementtyp gestattet dem Benutzer die Auswahl von Dateien, so dass ihr
Inhalt mit dem Formular bertragen werden kann. Dateiauswahl-Steuerelemente werden
mit dem Element INPUT erzeugt.
Versteckte Steuerelemente
Autoren k=nnen Steuerelemente erzeugen, die nicht dargestellt werden, deren Werte aber
mit dem Formular bertragen werden. Autoren verwenden diese Steuerelementtypen im
Allgemeinen, um Informationen von Client/Server-Operationen zu speichern, die ansonsten
dadurch, dass HTTP ein zustandsloses Protokoll ist (stateless nature), verloren gingen
(siehe [RFC2616]). Versteckte Steuerelemente werden mit dem Element INPUT erzeugt.
Objekt-Steuerelemente
Autoren k=nnen allgemeine Objekte so in Formulare einbinden, dass damit verbundene
Werte zusammen mit anderen Steuerelementen bertragen werden. Autoren k=nnen
Objekt-Steuerelemente mit dem Element OBJECT erzeugen.
Die Elemente, die zur Erzeugung eines Steuerelements verwendet werden, stehen im Allgemei-
nen innerhalb eines FORM-Elements, k=nnen aber auch außerhalb eines FORM-Elements stehen,
wenn sie zur Erzeugung von Benutzerschnittstellen verwendet werden. Dies wird in Abschnitt
18.2.3, „Eingebettete Ereignisse“ besprochen. Beachten Sie, dass Steuerelemente außerhalb
eines Formulars keine erfolgreichen Steuerelemente werden k=nnen.
17.3 Das Element FORM
<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) - - interactive form - ->
<!ATTLIST FORM
%attrs; - - %coreattrs, %i18n, %events - -
action %URI; #REQUIRED - - server-side form handler - -
method (GET|POST) GET - - HTTP method used to submit the form- -
enctype %ContentType; "application/x-www-form-urlencoded"
accept %ContentTypes; #IMPLIED - - list of MIME types for file upload - -
name CDATA #IMPLIED - - name of form for scripting - -
onsubmit %Script; #IMPLIED - - the form was submitted - -
onreset %Script; #IMPLIED - - the form was reset - -
accept-charset %Charsets; #IMPLIED - - list of supported charsets - -
>
Start-Tag: erforderlich, End-Tag: erforderlich
Das Element FORM < 261 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Attributdefinitionen
action = uri [CT]
Dieses Attribut gibt ein formularverarbeitendes Programm an. Ist der Wert kein HTTP-
Die HTML 4.01- Spezifikation
URI, dann ist die Vorgehensweise f r Benutzerprogramme nicht definiert.
method = get|post [CI]
Dieses Attribut gibt die HTTP-Methode zur bertragung des Formulardatensatzes an.
M=gliche Werte (bei denen nicht zwischen Groß- und Kleinschreibung unterschieden wird)
sind „get“ (Standardwert) und „post“. Informationen zur Verwendung finden Sie im
Abschnitt Formular bertragung.
enctype = content-type [CI]
Dieses Attribut gibt den Inhaltstyp f r die bertragung des Formulars zum Server an (so-
fern der Wert von method „post“ ist). Der Standardwert f r dieses Attribut ist „application/
x-www-form-urlencoded“. Der Wert „multipart/form-data“ sollte in Verbindung mit dem
INPUT-Element type=„file“ verwendet werden.
accept-charset = charset list [CI]
Dieses Attribut gibt die Liste der Zeichenkodierungen f r Eingabedaten an, die vom Server
bei der Verarbeitung des Formulars akzeptiert werden. Der Wert ist eine durch Leerzei-
chen und/oder Kommata getrennte Liste mit Zeichensatzwerten. Der Client muss diese
Liste als eine Exklusiv-Oder-Liste interpretieren, das heißt, der Server ist in der Lage, genau
eine der genannten Zeichenkodierungen je Formular bertragung zu akzeptieren.
Der Standardwert f r dieses Attribut ist die reservierte Zeichenkette „UNKNOWN“.
Benutzerprogramme k=nnen diesen Wert als die Zeichenkodierung interpretieren, die f r
die bertragung des Dokuments mit dem FORM-Element verwendet wurde.
accept = content-type-list [CI]
Dieses Attribut gibt eine durch Kommata getrennte Liste der Inhaltstypen an, die ein Ser-
ver, der dieses Formular verarbeitet, richtig behandeln wird. Benutzerprogramme k=nnen
diese Information dazu nutzen, nicht konforme Dateien herauszufiltern, wenn Benutzer auf-
gefordert werden, Dateien auszuw@hlen, die zum Server geschickt werden sollen (vgl.
INPUT-Element type=„file“).
name = cdata [CI]
Dieses Attribut benennt das Element, so dass sich Stylesheets oder Skripte darauf beziehen
k=nnen.
Anmerkung: Dieses Attribut wurde aus Grnden der Rckw,rtskompatibilit,t mit einbezogen.
Anwendungen sollten das id-Attribut verwenden, um Elemente zu kennzeichnen. n
An anderer Stelle definierte Attribute
·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)
·· style (inzeilige Formatierungsinformation)
title (Elementtitel)
·· target (Ziel-Frame-Angabe)
onsubmit, onreset, onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove,
onmouseout, onkeypress, onkeydown, onkeyup (eingebettete Ereignisse)
< 262 > Formulare
Page size: 168,00 x 240,00 mm
Das Element FORM ist ein Container f r Steuerelemente. Es gibt an:
·· Das Layout des Formulars (gegeben durch den Inhalt des Elements).
Das Programm, welches das vervollst@ndigte und bertragene Formular weiterverarbeiten
wird (das Attribut action). Das empfangende Programm muss in der Lage sein, die Name/
Die HTML 4.01- Spezifikation
Wert-Paare zu verarbeiten, um sie verwenden zu k=nnen.
·· Die Methode, mit der Benutzerdaten zum Server gesendet werden (das Attribut method).
Eine Zeichenkodierung, die vom Server akzeptiert werden muss, um dieses Formular zu
verarbeiten (das Attribut accept-charset). Benutzerprogramme k=nnen den Benutzer auf
diesen Wert des Attributs accept-charset hinweisen und/oder die M=glichkeit des Benut-
zers einschr@nken, nicht erkannte Zeichen einzugeben.
Ein Formular kann zus@tzlich zu Formular-Steuerelementen Text und Auszeichnungen (Abs@t-
ze, Listen und so weiter) enthalten.
Das folgende Beispiel zeigt ein Formular, das vom Programm „adduser“ verarbeitet werden
muss, wenn es bertragen wird. Das Formular wird ber die HTTP-Methode „post“ an das
Programm gesendet.
<FORM action="[Link] method="post">
...Formularinhalt...
</FORM>
Informationen dar ber, wie ein Benutzerprogramm die Formulardaten f r Server herrichten
muss und wie es die erwarteten Antworten verarbeiten soll, finden sie im Abschnitt „Formular-
bertragung“.
Anmerkung: Die weiterfhrende Diskussion ber das Verhalten der Server, die Formulardaten erhal-
ten, liegt nicht im Geltungsbereich dieser Spezifikation. n
17.4 Das Element INPUT
<!ENTITY % InputType
"(TEXT | PASSWORD | CHECKBOX |
RADIO | SUBMIT | RESET |
FILE | HIDDEN | IMAGE | BUTTON)"
>
<!- - attribute name required for all but submit and reset - ->
<!ELEMENT INPUT - O EMPTY - - form control - ->
<!ATTLIST INPUT
%attrs; - - %coreattrs, %i18n, %events - -
type %InputType; TEXT - - what kind of widget is needed - -
name CDATA #IMPLIED - - submit as part of form - -
value CDATA #IMPLIED - - Specify for radio buttons and checkboxes
--
checked (checked) #IMPLIED -- for radio buttons and check boxes - -
disabled (disabled) #IMPLIED -- unavailable in this context - -
readonly (readonly) #IMPLIED -- for text and passwd - -
size CDATA #IMPLIED -- specific to each type of field - -
maxlength NUMBER #IMPLIED -- max chars for text fields - -
src %URI; #IMPLIED -- for fields with images - -
alt CDATA #IMPLIED -- short description - -
Das Element INPUT < 263 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
usemap %URI; #IMPLIED -- use client-side image map - -
ismap (ismap) #IMPLIED -- use server-side image map - -
tabindex NUMBER #IMPLIED -- position in tabbing order - -
accesskey %Character; #IMPLIED -- accessibility key character - -
onfocus %Script; #IMPLIED -- the element got the focus - -
Die HTML 4.01- Spezifikation
onblur %Script; #IMPLIED -- the element lost the focus - -
onselect %Script; #IMPLIED -- some text was selected - -
onchange %Script; #IMPLIED -- the element value was changed - -
accept %ContentTypes; #IMPLIED -- list of MIME types for file upload - -
>
Start-Tag: erforderlich, End-Tag: verboten
Attributdefinitionen
type = text|password|checkbox|radio|submit|reset|file|hidden|image|button [CI]
Dieses Attribut gibt den Typ des Steuerelements an, das erzeugt werden soll. Die Vorein-
stellung f r dieses Attribut ist „text“.
name = cdata [CI]
Dieses Attribut weist den Steuerelementnamen zu.
value = cdata [CA]
Dieses Attribut weist dem Steuerelement den Anfangswert zu. Es ist optional, es sei denn,
das type-Attribut hat den Wert „radio“ oder „checkbox“.
size = cdata [CN]
Dieses Attribut gibt dem Benutzerprogramm die Anfangsbreite des Steuerelements an. Die
Breite wird in Pixeln angegeben, es sei denn, das type-Attribut hat den Wert text oder
password. In diesem Fall bezieht sich der Wert auf die Anzahl (Integer) der Zeichen.
maxlength = number [CN]
Hat das type-Attribut den Wert „text“ oder „password“, dann gibt dieses Attribut die
maximale Anzahl der Zeichen an, die ein Benutzer eingeben kann. Diese Zahl kann ber die
mit size deklarierte Breite hinausgehen. In diesem Fall sollte das Benutzerprogramm einen
Scroll-Mechanismus anbieten. Die Voreinstellung f r dieses Attribut ist eine unbegrenzte
Anzahl.
checked [CI]
Hat das type-Attribut den Wert „radio“ oder „checkbox“, gibt dieses Boolesche Attribut
an, dass die Schaltfl@che eingeschaltet ist. Benutzerprogramme m ssen dieses Attribut f r
andere Steuerelementtypen ignorieren.
src = uri [CT]
Hat das type-Attribut den Wert „image“, gibt dieses Attribut den Ort der Bilddatei an, die
diese graphische Absenden-Schaltfl@che zieren soll.
An anderer Stelle definierte Attribute
·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)
·· title (Elementtitel)
style (inzeilige Formatierungsinformation)
·· alt (alternativer Text)
align (Ausrichtung)
· accept (g ltiger Inhaltstyp f r einen Server)
< 264 > Formulare
Page size: 168,00 x 240,00 mm
·· readonly (schreibgesch tzte Eingabe-Steuerelemente)
disabled (deaktivierte Eingabe-Steuerelemente)
·· tabindex (Tabulatornavigation)
accesskey (Zugriffstaste)
··
Die HTML 4.01- Spezifikation
usemap (Client-seitige Imagemaps)
ismap (Server-seitige Imagemaps)
· onfocus, onblur, onselect, onchange, onclick, ondblclick, onmousedown, onmouseup, onmouseover,
onmousemove, onmouseout, onkeypress, onkeydown, onkeyup (eingebettete Ereignisse)
17.4.1 Steuerelementtypen mit INPUT
Der durch das INPUT-Element definierte Steuerelementtyp ist abh@ngig vom Wert des type-
Attributs:
text
Erzeugt ein einzeiliges Texteingabe-Steuerelement.
password
Wie „text“, jedoch wird der Eingabetext so dargestellt, dass die Zeichen versteckt werden
(zum Beispiel jeweils hinter einem Sternchen). Dieser Steuerelementtyp wird oft f r ver-
trauliche Eingaben wie Passworte verwendet. Beachten Sie, dass der aktuelle Wert der ein-
gegebene Text durch den Benutzer ist, nicht der Text, der vom Benutzerprogramm dar-
gestellt wird.
Anmerkung: Anwendungsentwickler sollten bercksichtigen, dass dieser Mechanismus nur
geringen Schutz bedeutet. Auch wenn das Benutzerprogramm das Passwort vor den Augen m gli-
cher Beobachter versteckt, wird es als normaler Text zum Server bertragen und k nnte von jedem
gelesen werden, der auf einer niedrigeren Ebene Zugang zum Netzwerk hat. n
checkbox
Erzeugt eine Checkbox.
radio
Erzeugt einen Radio-Button.
submit
Erzeugt eine Absenden-Schaltfl@che.
image
Erzeugt eine graphische Absenden-Schaltfl@che. Der Wert des src-Attributs gibt den URI
der Bilddatei an, welche die Schaltfl@che zieren wird. Aus Gr nden der Zug@nglichkeit soll-
ten Autoren mit Hilfe des alt-Attributs alternativen Text f r das Bild anbieten.
Wird ein Zeigerger@t verwendet, um auf ein Bild zu klicken, dann wird das Formular ber-
tragen und die Klick-Koordinaten werden an den Server weitergeleitet. Der x-Wert wird
in Pixeln von der linken Seite des Bildes und der y-Wert wird in Pixeln von der Oberseite
des Bildes gez@hlt. Die bermittelten Daten enthalten name.x=x-Wert und name.y=y-Wert,
wobei „name“ der Wert des Attributs name ist, und x-Wert sowie y-Wert die Werte der
x- bzw. y-Koordinaten sind.
Zeigt der Server abh@ngig vom angeklickten Ort unterschiedliche Reaktionen, werden
Benutzer von nicht graphischen Browsern benachteiligt sein. Aus diesem Grund sollten
Autoren alternative M=glichkeiten in Erw@gung ziehen:
Das Element INPUT < 265 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
· Verwenden Sie mehrere Schaltfl@chen (jede mit einem eigenen Bild), anstatt einer ein-
zelnen graphischen Absenden-Schaltfl@che. Autoren k=nnen Stylesheets verwenden, um
die Anordnung dieser Schaltfl@chen zu bestimmen.
· Verwenden Sie eine Client-seitige Imagemap in Verbindung mit Skripten.
Die HTML 4.01- Spezifikation
reset
Erzeugt eine Zur cksetzen-Schaltf@che.
button
Erzeugt eine allgemeine Schaltfl@che. Benutzerprogramme sollten den Wert des Attributs
value als Beschriftung f r die Schaltfl@che verwenden.
hidden
Erzeugt ein verstecktes Steuerelement.
file
Erzeugt ein Dateiauswahl-Steuerelement. Benutzerprogramme k=nnen den Wert des value-
Attributs als den Anfangsdateinamen verwenden.
17.4.2 Beispielformulare mit INPUT-Steuerelementen
Das folgende Beispiel eines HTML-Fragments definiert ein einfaches Formular, das es dem
Benutzer gestattet, einen Vornamen, einen Familiennamen, eine E-Mail-Adresse und ein
Geschlecht anzugeben. Wird die Absenden-Schaltfl@che aktiviert, wird das Formular an das
Programm bertragen, welches ber das action-Attribut angegeben ist.
<FORM action="[Link] method="post">
<P>
Vorname: <INPUT type="text" name="vorname"><BR>
Nachname: <INPUT type="text" name="nachname"><BR>
E-Mail: <INPUT type="text" name="email"><BR>
<INPUT type="radio" name="geschlecht" value="Maskulin"> Maskulin<BR>
<INPUT type="radio" name="geschlecht" value="Feminin"> Feminin<BR>
<INPUT type="submit" value="Absenden"> <INPUT type="reset" value="ZurUcksetzen">
</P>
</FORM>
Dieses Formular k=nnte wie folgt angezeigt werden:
Im Abschnitt ber das Element LABEL er=rtern wir die Erstellung von Beschriftungen wie "Vor-
name".
< 266 > Formulare
Page size: 168,00 x 240,00 mm
Anmerkung der bersetzer: Formularelemente werden in unterschiedlichen
Browsern und erst recht unter verschiedenen Betriebssystemen stark voneinander
abweichend dargestellt. Die folgenden Bilder des Formulars von oben, lediglich erwei-
Die HTML 4.01- Spezifikation
tert um ein Men -Element, illustrieren dies:
Das Element INPUT < 267 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Auch Stylesheets @ndern nichts an betriebssystemspezifischen Darstellungen von
Steuerelementen. Wir empfehlen daher beim Einsatz von Formularen, nicht zu ver-
suchen, optisch starre Layouts zu erstellen. Dieser Versuch wird sehr wahrscheinlich
Die HTML 4.01- Spezifikation
scheitern.
Im n@chsten Beispiel wird die JavaScript-Funktion verify aufgerufen, wenn das onclick-Event
auftritt:
<HEAD>
<META http-equiv="Content-Script-Type" content="text/javascript">
</HEAD>
<BODY>
<FORM action="..." method="post">
<P>
<INPUT type="button" value="DrUck Mich" onclick="verify()">
</FORM>
</BODY>
Mehr Informationen ber Skripte und Events finden Sie im Abschnitt „Eingebettete Ereignisse“.
Das folgende Beispiel zeigt, wie der Inhalt einer vom Benutzer angegebenen Datei mit einem
Formular bertragen werden kann. Der/die BenutzerIn wird nach seinem/ihrem Namen und
einer Liste mit Dateinamen gefragt, deren Inhalte mit dem Formular bertragen werden sollen.
Durch Angabe des enctype-Werts „multipart/form-data“ wird der Inhalt jeder Datei in einem
eigenen Bereich eines Multipart-Dokuments „verpackt“.
<FORM action="[Link]
enctype="multipart/form-data"
method="post">
<P>
Wie heißt Du? <INPUT type="text" name="name_des_absenders">
Welche Dateien verschickst Du? <INPUT type="file" name="name_der_dateien">
</P>
</FORM>
17.5 Das Element BUTTON
<!ELEMENT BUTTON - -
(%flow;)* -(A|%formctrl;|FORM|FIELDSET)
- - push button - ->
<!ATTLIST BUTTON
%attrs; - - %coreattrs, %i18n, %events - -
name CDATA #IMPLIED
value CDATA #IMPLIED - - sent to server when submitted - -
type (button|submit|reset) submit - - for use as form button - -
disabled (disabled) #IMPLIED - - unavailable in this context - -
tabindex NUMBER #IMPLIED - - position in tabbing order - -
accesskey %Character; #IMPLIED - - accessibility key character - -
< 268 > Formulare
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 [CI]
Dieses Attribut weist den Steuerelementnamen zu.
value = cdata [CS]
Dieses Attribut weist der Schaltfl@che den Anfangswert zu.
type = submit|button|reset [CI]
Dieses Attribut deklariert den Typ der Schaltfl@che. M=gliche Werte:
··
submit: Erzeugt eine Absenden-Schaltfl@che. Dies ist der Standardwert.
reset: Erzeugt eine Zur cksetzen-Schaltfl@che.
·
button: Erzeugt eine allgemeine Schaltfl@che.
An anderer Stelle definierte Attribute
·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)
·· title (Elementtitel)
style (inzeilige Formatierungsinformation)
·· disabled (deaktiviertes Eingabesteuerelement)
accesskey (Zugriffstatste)
··tabindex (Tabulatornavigation)
onfocus, onblur, onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmou-
seout, onkeypress, onkeydown, onkeyup (eingebettete Ereignisse)
Schaltfl@chen, die mit dem BUTTON-Element erzeugt werden, funktionieren wie Schaltfl@chen, die
mit dem INPUT-Element erzeugt wurden, bieten ledoch mehr Darstellungsm=glichkeiten: das
BUTTON-Element kann Inhalt haben. Zum Beispiel funktioniert ein BUTTON-Element mit Bild wie
ein INPUT-Element, dessen type-Attribut auf „image“ gesetzt ist und kann ihm gleichen, das Ele-
ment BUTTON gestattet jedoch Inhalt.
Visuelle Benutzerprogramme k=nnten BUTTON-Schaltfl@chen mit Relief und Auf/Ab-Bewegung
darstellen, wenn sie angeklickt werden, w@hrend sie INPUT-Schaltfl@chen als „flaches“ Bild anzei-
gen k=nnten.
Das folgende Beispiel erweitert das vorherige Beispiel, jedoch erzeugt es Absenden- und
Zur cksetzen-Schaltfl@chen mit BUTTON statt mit INPUT. Den Schaltfl@chen werden ber das IMG-
Element Bilder zugewiesen.
<FORM action="[Link] method="post">
<P>
Vorname: <INPUT type="text" name="vorname"><BR>
Nachname: <INPUT type="text" name="nachname"><BR>
E-Mail: <INPUT type="text" name="email"><BR>
<INPUT type="radio" name="genus" value="Maskulin"> Maskulin<BR>
<INPUT type="radio" name="genus" value="Feminin"> Feminin<BR>
<BUTTON name="senden" value="senden" type="submit">
Das Element BUTTON < 269 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Absenden<IMG src="/icons/[Link]" alt="wow"></BUTTON>
<BUTTON name="reset" type="reset">
ZurUcksetzen<IMG src="/icons/[Link]" alt="oops"></BUTTON>
</P>
</FORM>
Die HTML 4.01- Spezifikation
Rufen Sie sich in Erinnerung, dass Autoren alternativen Text f r ein IMG-Element angeben m s-
sen.
Es ist nicht gestattet, eine Imagemap mit einem IMG zu verkn pfen, das im Inhalt eines BUTTON-
Elements steht.
UNG LTIGES BEISPIEL
Das Folgende ist in HTML nicht gestattet:
<BUTTON>
<IMG src="[Link]" usemap="...">
</BUTTON> n
17.6 Die Elemente SELECT, OPTGROUP und OPTION
<!ELEMENT SELECT - - (OPTGROUP|OPTION)+ - - option selector - ->
<!ATTLIST SELECT
%attrs; - - %coreattrs, %i18n, %events - -
name CDATA #IMPLIED - - field name - -
size NUMBER #IMPLIED - - rows visible - -
multiple (multiple) #IMPLIED - - default is single selection - -
disabled (disabled) #IMPLIED - - unavailable in this context - -
tabindex NUMBER #IMPLIED - - position in tabbing order - -
onfocus %Script; #IMPLIED - - the element got the focus - -
onblur %Script; #IMPLIED - - the element lost the focus - -
onchange %Script; #IMPLIED - - the element value was changed - -
>
Start-Tag: erforderlich, End-Tag: erforderlich
Attributdefinitionen fr SELECT
name = cdata [CI]
Dieses Attribut weist den Steuerelementnamen zu.
size = number [CN]
Wird ein SELECT-Element als ein zu scrollendes Selektions-Listenfeld angezeigt, gibt dieses
Attribut die Anzahl der Zeilen in der Liste an, die zur gleichen Zeit sichtbar sein sollen.
Visuelle Benutzerprogramme m ssen ein SELECT-Element nicht als Listenfeld darstellen; sie
k=nnen auch andere Mechanismen w@hlen, wie zum Beispiel Drop-Down-Men s.
multiple [CI]
Wenn angegeben, gestattet dieses Boolesche Attribut mehrere Auswahlm=glichkeiten. Ist
es nicht gesetzt, erlaubt das SELECT-Element nur eine Auswahl.
< 270 > Formulare
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)
·· disabled (deaktivierte Eingabe-Steuerelemente)
tabindex (Tabulatornavigation)
· onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,
onkeydown, onkeyup (eingebettete Ereignisse)
Das SELECT-Element erzeugt ein Men . Jede Auswahlm=glichkeit wird durch ein OPTION-Element
repr@sentiert. Ein SELECT-Element muss mindestens ein OPTION-Element enthalten.
Das OPTGROUP-Element gestattet Autoren, die Auswahlm=glichkeiten logisch anzuordnen. Dies
ist besonders hilfreich, wenn der Benutzer aus einer langen Liste ausw@hlen muss; Gruppen
verwandter Auswahlm=glichkeiten sind einfacher zu verstehen und zu behalten als eine ein-
fache lange Liste mit Auswahlm=glichkeiten. In HTML 4 m ssen alle OPTGROUP-Elemente direkt
innerhalb eines SELECT-Elements angegeben werden (das heißt, Gruppen d rfen nicht ver-
schachtelt werden).
17.6.1 Vorauswahlen
Keine oder mehrere M=glichkeiten k=nnen f r den Benutzer vorausgew@hlt sein. Benutzerpro-
gramme sollten wie folgt feststellen, welche M=glichkeiten ausgew@hlt sind:
· Ist f r kein OPTION-Element das Attribut selected angegeben, ist f r Benutzerprogramme
nicht definiert, welche M=glichkeit zu Beginn ausgew@hlt wird.
Anmerkung: Weil vorhandene Implementationen diese F,lle unterschiedlich behandeln, weicht
die aktuelle Spezifikation vom RFC 1866 ([RFC1866] Abschnitt 8.1.3) ab, welcher aussagt: Im
Anfangszustand ist die erste M glichkeit ausgew,hlt, wenn kein SELECTED-Attribut fr irgendein
<OPTION>-Element angegeben ist. Weil sich die Vorgehensweise der Benutzerprogramme unter-
scheidet, sollten Autoren sicherstellen, dass jedes Men als Voreinstellung ein vorausgew,hltes
OPTION-Element enth,lt. n
·· Ist f r ein OPTION-Element das selected-Attribut angegeben, sollte es vorausgew@hlt sein.
Ist f r das SELECT-Element das multiple-Attribut angegeben und mehr als ein OPTION-Element
ber das selected-Attribut ausgew@hlt, sollten all diese vorausgew@hlt sein.
· Es wird als Fehler angesehen, wenn f r mehr als ein OPTION-Element das selected-Attribut
angegeben ist, f r das SELECT-Element jedoch kein multiple-Attribut gesetzt ist. Benutzer-
programme k=nnen bei diesem Fehler unterschiedlich vorgehen, jedoch sollten sie nicht
mehr als eine M=glichkeit vorausw@hlen.
<!ELEMENT OPTGROUP - - (OPTION)+ - - option group - ->
<!ATTLIST OPTGROUP
%attrs; - - %coreattrs, %i18n, %events - -
disabled (disabled) #IMPLIED - - unavailable in this context - -
label %Text; #REQUIRED - - for use in hierarchical menus - -
>
Die Elemente SELECT, OPTGROUP und OPTION < 271 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Start-Tag: erforderlich, End-Tag: erforderlich
Attributdefinitionen fr OPTGROUP
Die HTML 4.01- Spezifikation
label = text [CS]
Dieses Attribut gibt die Beschriftung f r die Gruppe der Auswahlm=glichkeiten an.
An anderer Stelle definierte Attribute
·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)
·· title (Elementtitel)
style (inzeilige Formatierungsinformation)
·· disabled (deaktivierte Eingabe-Steuerelemente)
onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,
onkeydown, onkeyup (eingebettete Ereignisse)
Anmerkung: Entwickler seien darauf hingewiesen, dass in zuknftigen Versionen von HTML die
Gruppierungsmechanismen eventuell erweitert werden und verschachtelte Gruppen gestattet werden
(das heißt, OPTGROUP-Elemente k nnen verschachtelt werden). Dies wird Autoren die M glichkeit geben,
eine reichhaltigere Hierarchie der Auswahlm glichkeiten darzustellen. n
<!ELEMENT OPTION - O (#PCDATA) - - selectable choice - ->
<!ATTLIST OPTION
%attrs; - - %coreattrs, %i18n, %events - -
selected (selected) #IMPLIED
disabled (disabled) #IMPLIED - - unavailable in this context - -
label %Text; #IMPLIED - - for use in hierarchical menus - -
value CDATA #IMPLIED - - defaults to element content - -
>
Start-Tag: erforderlich, End-Tag: optional
Attributdefinitionen fr OPTION
selected [CI]
Wenn angegeben, legt dieses Boolesche Attribut fest, dass die Option vorausgew@hlt ist.
value = cdata [CS]
Dieses Attribut gibt den Anfangswert eines Steuerelements an. Ist dieses Attribut nicht
angegeben, wird der Anfangswert auf den Inhalt des OPTION-Elements gesetzt.
label = text [CS]
Dieses Attribut erlaubt Autoren eine k rzere Beschreibung f r eine Option anzugeben als den
Inhalt des OPTION-Elements. Wenn es angegeben ist, sollten Benutzerprogramme den Wert die-
ses Attributs zur Beschreibung der Option verwenden, nicht den Inhalt des OPTION-Elements.
An anderer Stelle definierte Attribute
·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)
· title (Elementtitel)
< 272 > Formulare
Page size: 168,00 x 240,00 mm
·· style (inzeilige Formatierungsinformation)
disabled (deaktivierte Eingabe-Steuerelemente)
· onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,
onkeydown, onkeyup (eingebettete Ereignisse)
Die HTML 4.01- Spezifikation
Wird eine Men auswahl dargestellt, sollten Benutzerprogramme den Wert des label-Attributs
des OPTION-Elements als Auswahlm=glichkeit pr@sentieren. Ist dieses Attribut nicht angegeben,
sollten Benutzerprogramme den Inhalt des OPTION-Elements verwenden.
Das label-Attribut des OPTGROUP-Elements gibt die Beschriftung f r eine Gruppe mehrerer Aus-
wahlm=glichkeiten an.
In diesem Beispiel erzeugen wir ein Men , das dem Benutzer erlaubt zu entscheiden, welche der
sieben verschiedenen Software-Komponenten installiert werden sollen. Die erste und zweite
Komponente sind vorausgew@hlt, k=nnen aber vom Benutzer deselektiert werden. Die brigen
Komponenten sind nicht vorausgew@hlt. Das size-Attribut sagt aus, dass das Men nur vier Zei-
len haben soll, auch wenn der Benutzer aus sieben M=glichkeiten ausw@hlen kann. Die anderen
Auswahlm=glichkeiten sollten durch einen Scroll-Mechanismus verf gbar gemacht werden.
Dem SELECT folgen die Absenden- und Zur cksetzen-Schaltfl@chen.
<FORM action="[Link] method="post">
<P>
<SELECT multiple size="4" name="component-select">
<OPTION selected value="Komponente_1_a">Komponente_1</OPTION>
<OPTION selected value="Komponente_1_b">Komponente_2</OPTION>
<OPTION>Komponente_3</OPTION>
<OPTION>Komponente_4</OPTION>
<OPTION>Komponente_5</OPTION>
<OPTION>Komponente_6</OPTION>
<OPTION>Komponente_7</OPTION>
</SELECT>
<INPUT type="submit" value="Absenden"><INPUT type="reset" value="ZurUcksetzen">
</P>
</FORM>
Nur ausgew@hlte Optionen werden erfolgreich (unter Verwendung des Steuerelementnamens
„component-select“). Sind keine Optionen ausgew@hlt, ist das Steuerelement nicht erfolgreich
und weder der Name noch der Wert werden an den Server bertragen, wenn das Formular
bertragen wird. Beachten Sie, ist das value-Attribut angegeben, gibt es den Anfangswert des
Steuerelements an, ansonsten ist es der Inhalt des Elements.
In diesem Beispiel verwenden wir das Element OPTGROUP zur Gruppierung von Optionen. Der
folgende Quelltext:
<FORM action="[Link] method="post">
<P>
<SELECT name="ComOS">
<OPTION selected label="keine" value="keine">Keine</OPTION>
<OPTGROUP label="PortMaster 3">
<OPTION label="3.7.1" value="pm3_3.7.1">PortMaster 3 mit ComOS 3.7.1</OPTION>
<OPTION label="3.7" value="pm3_3.7">PortMaster 3 mit ComOS 3.7</OPTION>
<OPTION label="3.5" value="pm3_3.5">PortMaster 3 mit ComOS 3.5</OPTION>
</OPTGROUP>
<OPTGROUP label="PortMaster 2">
<OPTION label="3.7" value="pm2_3.7">PortMaster 2 mit ComOS 3.7</OPTION>
Die Elemente SELECT, OPTGROUP und OPTION < 273 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<OPTION label="3.5" value="pm2_3.5">PortMaster 2 mit ComOS 3.5</OPTION>
</OPTGROUP>
<OPTGROUP label="IRX">
<OPTION label="3.7R" value="IRX_3.7R">IRX mit ComOS 3.7R</OPTION>
<OPTION label="3.5R" value="IRX_3.5R">IRX mit ComOS 3.5R</OPTION>
Die HTML 4.01- Spezifikation
</OPTGROUP>
</SELECT>
</FORM>
repr@sentiert die folgende Gruppeneinteilung:
Keine
PortMaster 3
3.7.1
3.7
3.5
PortMaster 2
3.7
3.5
IRX
3.7R
3.5R
Optische Benutzerprogramme k=nnen Benutzern gestatten, ber ein hierarchisches Men aus Options-
gruppen auszuw@hlen oder ber einen anderen Mechanismus, der die Auswahlstruktur widerspiegelt.
Ein graphisches Benutzerprogramm k=nnte dies so darstellen:
Diese Graphik zeigt ein SELECT-Element, das als kaskadierende Men auswahl dargestellt wird.
Die oberste Beschriftung zeigt den aktuell ausgw@hlten Wert (PortMaster 3, 3.7.1). Der Benut-
zer hat zwei kaskadierende Men s aufgerufen, aber den neuen Wert noch nicht ausgew@hlt
(PortMaster 2, 3.7). Beachten Sie, dass jedes kaskadierende Men die Beschriftung eines
OPTGROUP- oder OPTION-Elements tr@gt.
Anmerkung der bersetzer: Die Darstellung derartige Men s ist von Benutzer-
programm zu Benutzerprogramm sehr verschieden. In der gleichen Situation wie eben
sieht ein Nutzer des Internet Explorer 5 unter MAC OS dieses:
< 274 > Formulare
Page size: 168,00 x 240,00 mm
Er sieht in diesem Moment zum Beispiel nicht mehr, dass er aktuell den Wert „Port-
Master 3, 3.7.1“ ausgew@hlt hat, weil er sich mit der Maus inzwischen ber „Portmaster
2“ befindet
Die HTML 4.01- Spezifikation
17.7 Das Element TEXTAREA
<!ELEMENT TEXTAREA - - (#PCDATA) - - multi-line text field - ->
<!ATTLIST TEXTAREA
%attrs; - - %coreattrs, %i18n, %events - -
name CDATA #IMPLIED
rows NUMBER #REQUIRED
cols NUMBER #REQUIRED
disabled (disabled) #IMPLIED - - unavailable in this context - -
readonly (readonly) #IMPLIED
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 - -
onselect %Script; #IMPLIED -- some text was selected - -
onchange %Script; #IMPLIED -- the element value was changed - -
>
Start-Tag: erforderlich, End-Tag: erforderlich
Attributdefinitionen
name = cdata [CI]
Dieses Attribut weist den Steuerelementnamen zu.
rows = number [CN]
Dieses Attribut gibt die Anzahl der sichtbaren Textzeilen an. Benutzer sollten in der Lage
sein, weitere Zeilen einzugeben. Folglich sollten Benutzerprogramme eine M=glichkeit bie-
ten, durch den Inhalt des Steuerelements zu scrollen, wenn der Inhalt ber den sichtbaren
Bereich hinausgeht.
cols = number [CN]
Dieses Attribut gibt die sichtbare Breite in durchschnittlicher Zeichenbreite an. Benutzer
sollten in der Lage sein, l@ngere Zeilen als diese einzugeben. Folglich sollten Benutzerpro-
gramme eine M=glichkeit bieten, durch den Inhalt des Steuerelements zu scrollen, wenn
der Inhalt ber den sichtbaren Bereich hinausgeht. Benutzerprogramme k=nnen sichtbare
Textzeilen umbrechen, um lange Zeilen anzuzeigen, so dass kein Scrollen notwendig wird.
An anderer Stelle definierte Attribute
·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)
·· title (Elementtitel)
style (inzeilige Formatierungsinformation)
·· readonly (schreibgesch tzte Eingabe-Steuerelemente)
disabled (deaktivierte Eingabe-Steuerelemente)
Das Element TEXTAREA < 275 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
·· tabindex (Tabulatornavigation)
onfocus, onblur, onselect, onchange, onclick, ondblclick, onmousedown, onmouseup, onmouseover,
onmousemove, onmouseout, onkeypress, onkeydown, onkeyup (eingebettete Ereignisse)
Das Element TEXTAREA erzeugt ein mehrzeiliges Texteingabe-Steuerelement. Benutzerpro-
Die HTML 4.01- Spezifikation
gramme sollten den Inhalt dieses Elements als den Anfangswert des Steuerelements verwenden
und diesen als Text zu Beginn darstellen.
Dieses Beispiel erzeugt ein TEXTAREA-Steuerelement mit 20 Zeilen und 80 Spalten, das zwei Zei-
len Anfangstext enth@lt. Dem Element TEXTAREA folgt eine Absenden- und eine Zur cksetzen-
Schaltfl@che.
<FORM action="[Link] method="post">
<P>
<TEXTAREA name="thetext" rows="20" cols="80">
Erste Zeile mit Anfangstext.
Zweite Zeile mit Anfangstext.
</TEXTAREA>
<INPUT type="submit" value="Absenden"><INPUT type="reset" value="ZurUcksetzen">
</P>
</FORM>
Die Angabe des readonly-Attributs gestattet Autoren die Anzeige von unver@nderbarem Text
in einer TEXTAREA. Dies unterscheidet sich davon, normal ausgezeichneten Text in einem Doku-
ment zu verwenden, weil der Wert von TEXTAREA mit dem Formular bertragen wird.
17.8 Das Element ISINDEX
ISINDEX ist missbilligt. Dieses Element erzeugt ein einzeiliges Texteingabe-Steuerelement. Auto-
ren sollten das INPUT-Element verwenden, um Texteingabe-Steuerelemente zu erzeugen.
Die formale Definition ist in der Transitional DTD nachzulesen.
Attributdefinitionen
prompt = text [CS]
Missbilligt. Dieses Attribut gibt eine Zeichenkette als Eingabeaufforderung f r das Ein-
gabefeld an.
An anderer Stelle definierte Attribute
·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)
·· title (Elementtitel)
style (inzeilige Formatierungsinformation)
Das Element ISINDEX erzeugt ein einzeiliges Texteingabe-Steuerelement, das eine beliebige
Anzahl von Zeichen erlaubt. Benutzerprogramme k=nnen den Wert des prompt-Attributs als
Titel f r die Eingabeaufforderung verwenden.
< 276 > Formulare
Page size: 168,00 x 240,00 mm
MISSBILLIGTES BEISPIEL:
Die folgende ISINDEX-Deklaration:
<ISINDEX prompt="Geben Sie Ihren Suchbegriff an: ">
Die HTML 4.01- Spezifikation
kann durch ein INPUT-Element wie folgt ausgedr ckt werden:
<FORM action="..." method="post">
<P>Geben Sie Ihren Suchbegriff an: <INPUT type="text"></P>
</FORM> n
Semantik von ISINDEX: Zur Zeit ist die Semantik fr ISINDEX nur wohldefiniert, wenn der Basis-
URI fr das einschließende Dokument ein HTTP-URI ist. In der Praxis ist die Eingabezeichenkette auf
Latin-1 beschr,nkt, weil es keinen Mechanismus fr den URI gibt, einen anderen Zeichensatz anzuge-
ben. n
17.9 Beschriftungen
Einige Formular-Steuerelemente haben bereits automatisch eine zugeh=rige Beschriftung
(Schaltfl@chen), w@hrend die meisten keine haben (Textfelder, Auswahlfelder, Radio-Buttons
und Men s).
F r Steuerelemente, die eine implizite Beschriftung haben, sollten Benutzerprogramme den
Wert des value-Attributs als Beschriftungszeichenkette verwenden.
Das Element LABEL wird f r die Beschriftung der Steuerelemente verwendet, die keine implizite
Beschriftung haben.
17.9.1 Das Element LABEL
<!ELEMENT LABEL - - (%inline;)* -(LABEL) - - form field label text - ->
<!ATTLIST LABEL
%attrs; - - %coreattrs, %i18n, %events - -
for IDREF #IMPLIED - - matches field ID value - -
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: erforderlich
Attributdefinitionen
for = idref [CS]
Dieses Attribut verbindet explizit diese definierte Beschriftung mit einem anderen Steuer-
element. Wenn vorhanden, muss dieser Attributwert gleich dem Wert eines id-Attributs
eines anderen Steuerelements im gleichen Dokument sein. Wenn nicht vorhanden, wird
die definierte Beschriftung dem Elementinhalt zugeordnet.
Beschriftungen < 277 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
An anderer Stelle definierte Attribute
·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)
·· title (Elementtitel)
Die HTML 4.01- Spezifikation
style (inzeilige Formatierungsinformation)
·· accesskey (Zugriffstatste)
onfocus, onblur, onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmou-
seout, onkeypress, onkeydown, onkeyup (eingebettete Ereignisse)
Das Element LABEL kann dazu verwendet werden, Steuerelementen Informationen hinzuzuf -
gen. Jedes LABEL-Element ist genau einem Formular-Steuerelement zugeordnet.
Das for-Attribut verkn pft eine Beschriftung explizit mit einem anderen Steuerelement: der
Wert des for-Attributs muss der gleiche sein, wie der des id-Attributs des verbundenen
Steuerelements. Mehr als ein LABEL kann mit dem gleichen Steuerelement verkn pft werden,
wenn mehrere Verweise ber das for-Attribut erzeugt werden.
Dieses Beispiel erzeugt eine Tabelle, die dazu verwendet wird, zwei Texteingabe-Steuerele-
mente und ihre entsprechenden Beschriftungen auszurichten. Jede Beschriftung ist mit genau
einer Texteingabe verkn pft:
<FORM action="..." method="post">
<TABLE>
<TR>
<TD><LABEL for="vname">Vorname</LABEL>
<TD><INPUT type="text" name="vorname" id="vname">
<TR>
<TD><LABEL for="nname">Nachname</LABEL>
<TD><INPUT type="text" name="nachname" id="nname">
</TABLE>
</FORM>
Dieses Beispiel erweitert ein vorheriges Beispielformular um LABEL-Elemente.
<FORM action="[Link] method="post">
<P>
<LABEL for="vorname">Vorname: </LABEL>
<INPUT type="text" id="vorname"><BR>
<LABEL for="nachname">Nachname: </LABEL>
<INPUT type="text" id="nachname"><BR>
<LABEL for="email">E-Mail: </LABEL>
<INPUT type="text" id="email"><BR>
<INPUT type="radio" name="geschlecht" value="Maskulin"> Maskulin<BR>
<INPUT type="radio" name="geschlecht" value="Feminin"> Feminin<BR>
<INPUT type="submit" value="Senden"> <INPUT type="reset" value="ZurUcksetzen">
</P>
</FORM>
Um eine Beschriftung mit einem anderen Steuerelement implizit zu verbinden, muss das
Steuerelement innerhalb des Inhalts des LABEL-Elements liegen. In diesem Fall sollte das LABEL
nur ein Steuerelement enthalten. Die Beschriftung selbst kann vor oder nach dem entsprechen-
den Steuerelement angebracht werden.
< 278 > Formulare
Page size: 168,00 x 240,00 mm
In diesem Beispiel verkn pfen wir implizit zwei Beschriftungen mit zwei Texteingabe-Steuerele-
menten:
<FORM action="..." method="post">
Die HTML 4.01- Spezifikation
<P>
<LABEL>
Vorame
<INPUT type="text" name="vorname">
</LABEL>
<LABEL>
<INPUT type="text" name="nachname">
Nachname
</LABEL>
</P>
</FORM>
Beachten Sie, dass diese Technik nicht angewandt werden kann, wenn eine Tabelle f r das Lay-
out verwendet wird, in der die Beschriftung in einer Zelle ist und das entsprechende Steuerele-
ment in einer anderen.
Bekommt ein LABEL-Element den Fokus, reicht es den Fokus weiter an sein entsprechendes
Steuerelement. Der folgende Abschnitt ber Zugriffstasten zeigt Beispiele.
Beschriftungen k=nnen von Benutzerprogrammen auf verschiedene Art dargestellt werden
(zum Beispiel optisch, durch Sprachsynthesizer gesprochen und so weiter).
17.10 Formularen Struktur hinzuf-gen: die Elemente
FIELDSET und LEGEND
<!- -
#PCDATA is to solve the mixed content problem,
per specification only whitespace is allowed there!
- ->
<!ELEMENT FIELDSET - - (#PCDATA,LEGEND,(%flow;)*) - - form control group - ->
<!ATTLIST FIELDSET
%attrs; - - %coreattrs, %i18n, %events - -
>
<!ELEMENT LEGEND - - (%inline;)* - - fieldset legend - ->
<!ATTLIST LEGEND
%attrs; - - %coreattrs, %i18n, %events - -
accesskey %Character; #IMPLIED - - accessibility key character - -
>
Start-Tag: erforderlich, End-Tag: erforderlich
Die Elemente FIELDSET und LEGEND < 279 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Attributdefinitionen fr LEGEND
align = top|bottom|left|right [CI]
Missbilligt. Dieses Attribut gibt die Position in Bezug auf die Steuerelementgruppe an.
Die HTML 4.01- Spezifikation
M=gliche Werte:
·top: Die Beschriftung befindet sich am Kopf der Steuerelementgruppe. Dies ist der
Standardwert.
··
bottom: Die Beschriftung befindet sich am Fuß der Steuerelementgruppe.
left: Die Beschriftung befindet sich an der linken Seite der Steuerelementgruppe.
·
right: Die Beschriftung befindet sich an der rechten Seite der Steuerelementgruppe.
An anderer Stelle definierte Attribute
·· id, class (dokumentweite Identifikatoren)
lang (Sprachcode), dir (Leserichtung)
·· title (Elementtitel)
style (inzeilige Formatierungsinformation)
·· accesskey (Zugriffstasten)
onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress,
onkeydown, onkeyup (eingebettete Ereignisse)
Das Element FIELDSET gestattet Autoren, thematisch vergleichbare Steuerelemente und
Beschriftungen zu gruppieren. Die Gruppierung von Steuerelementen vereinfacht Benutzern,
deren Zweck zu verstehen, gleichzeitig wird die Tabulatornavigation f r optische Benutzerpro-
gramme und die Sprachnavigation f r sprachorientierte Benutzerprogramme erleichtert. Die
sorgf@ltige Verwendung dieser Elemente macht Dokumente zug@nglicher.
Das Element LEGEND gestattet Autoren, einem FIELDSET eine Beschriftung zu verleihen. Die
Beschriftung verbessert die Zug@nglichkeit, wenn das FIELDSET nicht visuell ausgegeben wird.
In diesem Beispiel erzeugen wir ein Formular, dass man in der Arztpraxis ausf llen k=nnte. Es
ist in drei Bereiche aufgeteilt: pers=nliche Informationen, medizinische Vergangenheit und aktu-
elle Medikation. Jeder Bereich enth@lt Steuerelemente zur Eingabe der entsprechenden Infor-
mationen.
<FORM action="..." method="post">
<P>
<FIELDSET>
<LEGEND>Pers^nliche Informationen</LEGEND>
Nachname: <INPUT name="pers_nachname" type="text" tabindex="1">
Vorname: <INPUT name="pers_vorname" type="text" tabindex="2">
Adresse: <INPUT name="pers_adresse" type="text" tabindex="3">
...mehr pers0nliche Informationen...
</FIELDSET>
<FIELDSET>
<LEGEND>Medizinische Vergangenheit</LEGEND>
<INPUT name="geschichte_krankheit"
type="checkbox"
value="Pocken" tabindex="20"> Pocken
<INPUT name="geschichte_krankheit"
type="checkbox"
value="Mumps" tabindex="21"> Mumps
<INPUT name="geschichte_krankheit"
type="checkbox"
< 280 > Formulare
Page size: 168,00 x 240,00 mm
value="Schwindel" tabindex="22"> Schwindel
<INPUT name="geschichte_krankheit"
type="checkbox"
value="Schnupfen" tabindex="23"> Schnupfen
...mehr medizinische Vergangenheit...
Die HTML 4.01- Spezifikation
</FIELDSET>
<FIELDSET>
<LEGEND>Aktuelle Medikation</LEGEND>
Nehmen Sie zur Zeit irgendwelche Medikamente?
<INPUT name="medikamente_jetzt"
type="radio"
value="Ja" tabindex="35">Ja
<INPUT name="medikamente_jetzt"
type="radio"
value="Nein" tabindex="35">Nein
Wenn Sie zur Zeit Medikamente nehmen, geben Sie diese bitte
im Textfeld unten an:
<TEXTAREA name="aktuelle_medikamente"
rows="20" cols="50"
tabindex="40">
</TEXTAREA>
</FIELDSET>
</FORM>
Beachten Sie, dass wir die optische Darstellung des Formulars dadurch verbessern k=nnten,
dass wir die Elemente innerhalb der FIELDSET-Elemente ausrichten (mit Stylesheets), Farbe und
Informationen zur Schriftart hinzuf gen (mit Stylesheets), Skripte hinzuf gen (sagen wir, um das
Textfeld zur aktuellen Medikation nur zu =ffnen, wenn der Benutzer angibt, dass er zur Zeit
Medikamente einnimmt) und vieles mehr.
17.11 Einem Element den Fokus zuweisen
In einem HTML-Dokument muss ein Element vom Benutzer den Fokus zugewiesen bekommen,
um aktiv zu werden und seine Aufgabe zu erf llen. Zum Beispiel m ssen Benutzer einen durch
das A erzeugten Verweis aktivieren, um dem angegebenen Verweis zu folgen. Ohnlich m ssen
Benutzer einer TEXTAREA den Fokus zuweisen, um dort Text eingeben zu k=nnen.
Es gibt verschiedene Wege, einem Element den Fokus zuzuweisen:
·· Das Element mit einem Zeigerger@t kennzeichnen.
Von einem Element zum n@chsten mit der Tastatur navigieren. Der Autor eines Dokuments
kann die Tabulator-Reihenfolge definieren und so die Reihenfolge angeben, in der Elemente
den Fokus erlangen, wenn der Benutzer mit der Tastatur durch das Dokument navigiert
(siehe „Tabulatornavigation“). Einmal ausgew@hlt, kann das Element durch eine andere Tas-
tensequenz aktiviert werden.
· Ein Element durch eine Zugriffstaste (manchmal auch „Tastenkombination“ oder „Tasten-
k rzel bzw. Shortcut“ genannt) ausw@hlen.
Einem Element den Fokus zuweisen < 281 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
17.11.1 Tabulatornavigation
Attributdefinitionen
Die HTML 4.01- Spezifikation
tabindex = number [CN]
Dieses Attribut gibt die Position des aktuellen Elements in der Tabulator-Reihenfolge f r
das aktuelle Dokument an. Dieser Wert muss eine Zahl zwischen 0 und 32767 sein. Benut-
zerprogramme sollten f hrende Nullen ignorieren.
Die Tabulator-Reihenfolge definiert die Reihenfolge, in der die Elemente den Fokus erlangen,
wenn der Benutzer ber die Tastatur navigiert. Die Tabulator-Reihenfolge kann Elemente ent-
halten, die innerhalb anderer Elemente verschachtelt sind.
Elemente, die den Fokus erlangen k=nnen, sollten durch Benutzerprogramme nach folgenden
Regeln angesteuert werden:
1. Die Elemente, welche das tabindex-Attribut unterst tzen und einen positiven Wert daf r
enthalten, werden zuerst angesteuert. Die Navigation verf@hrt vom Element mit dem nied-
rigsten tabindex-Wert zu dem Element mit dem h=chsten Wert. Werte m ssen weder auf-
einanderfolgend sein, noch m ssen sie mit einem bestimmten Wert anfangen. Elemente mit
identischen tabindex-Werten sollten in der Reihenfolge angesteuert werden, in der sie im
Zeichenstrom erscheinen.
2. Die Elemente, die das tabindex-Attribut nicht unterst tzen oder es unterst tzen und ihnen
der Wert „0“ zugewiesen ist, werden als n@chstes angesteuert. Diese Elemente werden in
der Reihenfolge angesteuert, in der sie im Zeichenstrom erscheinen.
3. Elemente, die „disabled“ sind, sind nicht in der Tabulator-Reihenfolge enthalten.
Die folgenden Elemente unterst tzen das tabindex-Attribut: A, AREA, BUTTON, INPUT, OBJECT,
SELECT und TEXTAREA.
In diesem Beispiel wird die Tabulator-Reihenfolge wie folgt sein: das BUTTON-Element, die INPUT-
Elemente in Reihenfolge (beachten Sie, dass „feld1“ und die Schaltfl@che (button) den gleichen
Tab-Index teilen, „feld1“ jedoch sp@ter im Zeichenstrom erscheint) und schließlich der Link,
der durch das Element A erzeugt wird.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"[Link]
<HTML>
<HEAD>
<TITLE>Ein Dokument mit FORM</TITLE>
</HEAD>
<BODY>
...etwas Text...
<P>Gehe zu der
<A tabindex="10" href="[Link]
...noch mehr...
<BUTTON type="button" name="get-database"
tabindex="1" onclick="get-database">
Hole die aktuelle Datenbank.
</BUTTON>
...noch mehr...
<FORM action="..." method="post">
<P>
<INPUT tabindex="1" type="text" name="feld1">
< 282 > Formulare
Page size: 168,00 x 240,00 mm
<INPUT tabindex="2" type="text" name="feld2">
<INPUT tabindex="3" type="submit" name="submit">
</P>
</FORM>
</BODY>
Die HTML 4.01- Spezifikation
</HTML>
Tabulator-Tasten: Die Tastenfolge, die eine Tabulator-Navigation oder eine Elementaktivierung
hervorruft, h,ngt von der Konfiguration des Benutzerprogramms ab (zum Beispiel wird die „Tab“-Taste
zur Navigation verwendet und die „Enter“-Taste zur Aktivierung des ausgew,hlten Elements).
Benutzerprogramme k nnen ebenso Tastenfolgen zur entgegengesetzten Navigation durch die Tabula-
tor-Reihenfolge verwenden. Wenn das Ende (oder der Anfang) der Tabulator-Reihenfolge erreicht ist,
sollten Benutzerprogramme wieder zurck zum Anfang (oder zum Ende) schalten. n
17.11.2 Zugriffstasten
Attributdefinitionen
accesskey = character [CN]
Dieses Attribut weist einem Element ein Zugriffstaste zu. Eine Zugriffstaste ist ein einfaches
Zeichen des Dokumentzeichensatzes. Anmerkung: Autoren sollten die Eingabemethode des
erwarteten Lesers ber cksichtigen, wenn sie die Zugriffstaste angeben.
Das Dr cken einer Zugriffstaste, die einem Element zugeordnet ist, gibt dem Element den
Fokus. Die Aktion, die eintritt, wenn ein Element den Fokus erh@lt, ist abh@ngig vom Element
selbst. Wenn zum Beispiel ein Benutzer einen Link aktiviert, der vom A-Element erzeugt wird,
folgt das Benutzerprogramm im Allgemeinen dem Link. Aktiviert ein Benutzer einen Radio-But-
ton, ver@ndert das Benutzerprogramm den Wert des Radio-Buttons. Aktiviert ein Benutzer ein
Textfeld, erlaubt es die Texteingabe und so weiter.
Die folgenden Elemente unterst tzen das Attribut accesskey: A, AREA, BUTTON, INPUT, LABEL,
LEGEND und TEXTAREA.
Dieses Beispiel weist der Beschriftung eines INPUT-Steuerelements die Zugriffstaste „U“ zu. Das
Dr cken der Zugriffstaste vergibt den Fokus an die Beschriftung, welche ihrerseits den Fokus
an das verbundene Steuerelement weitergibt. Der Benutzer kann dann Text in den INPUT-Be-
reich eingeben.
<FORM action="..." method="post">
<P>
<LABEL for="fuser" accesskey="U">
User Name
</LABEL>
<INPUT type="text" name="user" id="fuser">
</P>
</FORM>
In diesem Beispiel weisen wir einem Verweis, der mit dem A-Element definiert ist, eine Zugriffs-
taste zu. Das Dr cken dieser Zugangstaste f hrt den Benutzer zu einem anderen Dokument, in
diesem Fall zum Inhaltsverzeichnis.
Einem Element den Fokus zuweisen < 283 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<P><A accesskey="I"
rel="content"
href="[Link]
Inhaltsverzeichnis</A>
Die HTML 4.01- Spezifikation
Der Aufruf der Zugriffstasten h@ngt vom basierenden System ab. Zum Beispiel muss man auf
Rechnern mit MS Windows im Allgemeinen die „Alt“-Taste zus@tzlich zur Zugriffstaste dr -
cken. Auf Apple-Systemen muss im Allgemeinen die „cmd“-Taste zus@tzlich zur Zugriffstaste
gedr ckt werden.
Die Darstellung der Zugriffstasten h@ngt vom Benutzerprogramm ab. Wir empfehlen, dass
Autoren die Zugriffstaste in die Beschriftung einschließen oder wo immer die Zugriffsaste ver-
wendet werden muss. Benutzerprogramme sollten den Wert einer Zugriffstaste so darstellen,
dass ihre Funktion unterstrichen wird und dass sie von den anderen Zeichen unterschieden
werden kann (zum Beispiel durch unterstreichen).
17.12 Deaktivierte und schreibgesch-tzte
Steuerelemente
In Kontexten, in denen Benutzereingaben entweder unerw nscht oder irrelevant sind, ist es
wichtig, Steuerelemente deaktivieren zu k=nnen oder sie schreibgesch tzt darzustellen. Zum
Beispiel m=chte vielleicht jemand eine Absenden-Schaltfl@che deaktivieren bis der Benutzer
erforderliche Daten eingegeben hat. Oder es m=chte ein Autor vielleicht schreibgesch tzten
Text einschließen, der als Wert mit dem Formular bertragen werden muss. Der folgende
Abschnitt beschreibt deaktivierte und schreibgesch tzte Steuerelemente.
17.12.1 Deaktivierte Steuerelemente
Attributdefinitionen
disabled [CI]
Ist es f r ein Formularsteuerelement angegeben, deaktiviert dieses Boolesche Attribut das
Steuerelement f r Benutzereingaben.
Ist es angegeben, hat das Attribut disabled die folgenden Auswirkungen auf ein Element:
·· Deaktivierte Steuerelemente erhalten keinen Fokus.
Deaktivierte Steuerelemente werden in der Tabulatornavigation bergangen.
· Deaktivierte Steuerelemente k=nnen nicht erfolgreich sein.
Die folgenden Elemente unterst tzen das Attribut disabled: BUTTON, INPUT, OPTGROUP, OPTION,
SELECT und TEXTAREA.
Dieses Attribut wird vererbt, jedoch berschreiben lokale Deklarationen den vererbten Wert.
Wie deaktivierte Elemente dargestellt werden, ist abh@ngig vom Benutzerprogramm. Zum Bei-
spiel stellen einige Benutzerprogramme deaktivierte Men punkte, Schaltfl@chenbeschriftungen
und so weiter grau dar.
In diesem Beispiel ist das INPUT-Element deaktiviert. Deshalb kann es weder Benutzereingaben
entgegennehmen noch wird sein Wert mit dem Formular bertragen.
<INPUT disabled name="fred" value="stone">
< 284 > Formulare
Page size: 168,00 x 240,00 mm
Anmerkung der bersetzer: disabled funktioniert bei einer Reihe etwas @lterer
Browser nicht.
Die HTML 4.01- Spezifikation
Anmerkung: Der einzige Weg, den Wert des disabled-Attributs dynamisch zu ver,ndern, ist durch
ein Skript. n
17.12.2 Schreibgesch-tzte Steuerelemente
Attributdefinitionen
readonly [CI]
Ist es f r ein Formular-Steuerelement angegeben, verbietet dieses Boolesche Attribut Ver-
@nderungen an dem Steuerelement.
Das Attribut readonly gibt an, ob das Steuerelement vom Benutzer ver@ndert werden kann.
Ist es angegeben, hat das readonly-Attribut die folgenden Auswirkungen auf ein Element:
· Schreibgesch tzte Elemente erhalten den Fokus, k=nnen jedoch nicht vom Benutzer ver-
@ndert werden.
·· Schreibgesch tzte Elemente sind Teil der Tabulatornavigation.
Schreibgesch tzte Elemente k=nnen erfolgreich sein.
Die folgenden Elemente unterst tzen das Attribut readonly: INPUT und TEXTAREA.
Wie schreibgesch tzte Elemente dargestellt werden, ist abh@ngig vom Benutzerprogramm.
Anmerkung: Der einzige Weg, den Wert des readonly-Attributs dynamisch zu ver,ndern, ist durch
ein Skript. n
17.13 Formular-bertragung
Der folgende Abschnitt erkl@rt, wie Benutzerprogramme Formulardaten zu formularverarbei-
tenden Programmen bertragen.
17.13.1 Formular-bertragungsmethode
Das Attribut method des FORM-Elements gibt die HTTP-Methode an, die zur bertragung des
Formulars an das verarbeitende Programm verwendet wird. Dieses Attribut kann zwei Werte
entgegennehmen:
· get: Mit der HTTP-Methode „get“ wird der Formulardatensatz an den URI geh@ngt, der
durch das action-Attribut angegeben ist (mit einem Fragezeichen („?“) als Trennzeichen)
und dieser neue URI wird zu dem verarbeitenden Programm geschickt.
· post: Mit der HTTP-Methode „post“ wird der Formulardatensatz im Rumpf des Formulars
eingeschlossen und zum verarbeitenden Programm geschickt.
Formular#bertragung < 285 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Die Methode „get“ sollte verwendet werden, wenn das Formular idempotent ist (das heißt,
keine Nebeneffekte hat). Viele Datenbankanfragen haben keinen sichtbaren Nebeneffekt und
bieten ideale Anwendungen f r die Methode „get“.
Wenn der Dienst zur Verarbeitung eines Formulars Nebeneffekte verursacht (wenn das For-
Die HTML 4.01- Spezifikation
mular zum Beispiel eine Datenbank oder ein Abonnement eines Dienstes ver@ndert), sollte die
Methode „post“ verwendet werden.
Anmerkung: Die Methode „get“ beschr,nkt Formulardatensatzwerte auf ASCII-Zeichen. Nur die
Methode „post“ (mit enctype=„multipart/form-data“) ist spezifiziert, den gesamten [ISO10646]-Zei-
chensatz zu untersttzen. n
17.13.2 Erfolgreiche Steuerelemente
Ein erfolgreiches Steuerelement ist „g ltig“ f r die bertragung. F r jedes erfolgreiche Steuer-
element wird sein Steuerelementname, gepaart mit seinem aktuellen Wert, als Teil des Formu-
lardatensatzes bermittelt. Ein erfolgreiches Steuerelement muss innerhalb eines FORM-Elements
definiert sein und muss einen Steuerelementnamen haben.
Jedoch:
·· Steuerelemente, die deaktiviert sind, k=nnen nicht erfolgreich sein.
Enth@lt ein Formular mehr als eine Absenden-Schaltfl@che ist nur die aktivierte Absenden-
Schaltfl@che erfolgreich.
·· Alle Checkboxen, die eingeschaltet sind, k=nnen erfolgreich sein.
Im Fall von Radio-Buttons, die den gleichen Wert des name-Attributs besitzen, kann nur der
Radio-Button erfolgreich sein, der eingeschaltet ist.
· Im Fall von Men s wird der Steuerelementname durch ein SELECT-Element angegeben und
Werte durch OPTION-Elemente. Nur ausgew@hlte Optionen k=nnen erfolgreich sein. Sind
keine Optionen ausgew@hlt, ist das Steuerelement nicht erfolgreich und weder der Name
noch irgendein Wert werden an den Server bertragen, wenn das Formular bertragen
wird.
· Der aktuelle Wert einer Dateiauswahl ist eine Liste mit einem oder mehreren Dateinamen.
Bei der bertragung des Formulars wird der Inhalt jeder Datei mit dem Rest der Formular-
daten bertragen. Der Dateiinhalt wird entsprechend dem Inhaltstypen des Formulars
gepackt.
· Der aktuelle Wert eines Objekt-Steuerelements wird durch die Implementation des
Objekts bestimmt.
Hat ein Steuerelement keinen aktuellen Wert, wenn das Formular bertragen wird, wird von
Benutzerprogrammen nicht gefordert, es als ein erfolgreiches Steuerelement zu behandeln.
berdies sollten Benutzerprogramme die folgenden Steuerelemente nicht als erfolgreich
betrachten:
·· Reset-Buttons.
OBJECT-Elemente, deren declare-Attribut angegeben ist.
Versteckte Steuerelemente und Steuerelemente, die aufgrund von Stylesheet-Angaben nicht
dargestellt werden, k=nnen dennoch erfolgreich sein. Zum Beispiel:
<FORM action="..." method="post">
<P>
<INPUT type="password" style="display:none"
< 286 > Formulare
Page size: 168,00 x 240,00 mm
name="unsichtbares-passwort"
value="meinpasswort">
</FORM>
wird trotzdem einen Wert zur Folge haben, der mit dem Namen „unsichtbares-passwort“
Die HTML 4.01- Spezifikation
gepaart und mit dem Formular bertragen wird.
17.13.3 Formulardaten verarbeiten
bertr@gt der Benutzer ein Formular (zum Beispiel durch die Aktivierung einer Absenden-
Schaltfl@che), verarbeitet das Benutzerprogramm dieses Formular wie folgt.
Schritt eins: erfolgreiche Steuerelemente identifizieren
Schritt zwei: Einen Formulardatensatz erzeugen
Ein Formulardatensatz ist eine Folge von Paaren aus Steuerelementname/aktueller Wert, die
aus erfolgreichen Steuerelementen erzeugt wird.
Schritt drei: Kodieren des Formulardatensatzes
Der Formulardatensatz wird dann entsprechend dem Inhaltstyp kodiert, der vom enctype-
Attribut des FORM-Elements angegeben wird.
Schritt vier: Den kodierten Formulardatensatz -bertragen
Schließlich werden die kodierten Daten unter Verwendung des vom method-Attribut angegeben
Protokolls zum vom action-Attribut ausgew@hlten verarbeitenden Programm gesendet.
Diese Spezifikation gibt nicht alle g ltigen bertragungsmethoden oder Inhaltstypen an, die mit
Formularen verwendet werden k=nnten. Jedoch m ssen HTML 4-Benutzerprogramme die
bestehenden Konventionen in den folgenden F@llen erf llen:
· Ist die Methode „get“ und der action-Wert ein HTTP-URI, verwendet das Benutzerpro-
gramm den Wert von action, h@ngt ein „?“ und dann den Formulardatensatz an, kodiert mit
dem Inhaltstypen „application/x-www-form-urlencoded“. Das Benutzerprogramm f hrt
daraufhin den Link zu diesem URI aus. In diesem Szenario sind Formulardaten auf ASCII-
Kode beschr@nkt.
· Ist die Methode „post“ und der action-Wert ein HTTP-URI, f hrt das Benutzerprogramm eine
HTTP-Post-Transaktion unter Verwendung des action-Attributwerts und einer entsprechend
dem Inhaltstypen, angegeben durch das enctype-Attribut, erzeugten Nachricht durch.
F r jeden anderen Wert von action oder method ist das Verhalten nicht spezifiziert.
Benutzerprogramme sollten die Antwort der HTTP-Transaktionen „get“ und „post“ darstellen.
17.13.4 Formular-Inhaltstypen
Das Attribut enctype des FORM-Elements gibt den Inhaltstypen an, der zur Kodierung des Formu-
lardatensatzes f r die bertragung zum Server notwendig ist. Benutzerprogramme m ssen die
unten aufgef hrten Inhaltstypen unterst tzen. Das Verhalten f r andere Inhaltstypen ist nicht
spezifiziert.
Bitte lesen Sie ebenfalls den Abschnitt „Und-Zeichen in URI-Attributwerten“(B.2.2).
Formular#bertragung < 287 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
application/x-www-form-urlencoded
Dies ist der Standard-Inhaltstyp. Formulare, die mit diesem Inhaltstyp bertragen werden, m s-
sen wie folgt kodiert werden:
1. Steuerelementnamen und Werte werden ersetzt. Leerraum-Zeichen werden durch „+“
Die HTML 4.01- Spezifikation
ersetzt, dann werden reservierte Zeichen ersetzt wie in [RFC1738], Abschnitt 2.2
beschrieben: Nicht alphanumerische Zeichen werden durch „%HH“, ein Prozent-Zeichen
und zwei hexadezimale Digits, die den ASCII-Kode des Zeichens repr@sentieren. Zeilen-
umbr che werden als „CR LF“-Paare repr@sentiert (zum Beispiel „%0D%0A“).
2. Die Steuerelementnamen/Werte werden in der Reihenfolge aufgef hrt, in der sie im Doku-
ment erscheinen. Der Name wird vom Wert durch ein „=“ getrennt und die Name/Wert-
Paare untereinander durch ein „&“.
multipart/form-data
Anmerkung: Bitte lesen Sie [RFC2388] fr weitere Informationen ber Datei-Uploads, einschließlich
Fragen zur Rckw,rtskompatibilit,t, die Beziehung zwischen „multipart/form-data“ und anderen
Inhaltstypen, Leistungsfragen und so weiter.
Bitte lesen Sie im Anhang B die „Anmerkungen zur Sicherheit“. n
Der Inhaltstyp „application/x-www-form-urlencoded“ ist nicht leistungsf@hig genug, um große
Mengen bin@rer Daten zu verschicken oder Daten, die Nicht-ASCII-Zeichen enthalten. Der
Inhaltstyp „multipart/form-data“ sollte zur bertragung von Formularen verwendet werden,
die Dateien, Nicht-ASCII-Daten und bin@re Daten enthalten.
Der Inhalt „multipart/form-data“ ist konform zu den Regeln aller mehrteiligen MIME-Daten-
str=me, wie in [RFC2045] umrissen. Die Definition von „multipart/form-data“ ist verf gbar bei
der [IANA]-Registratur.
Eine „multipart/form-data“-Nachricht enth@lt mehrere Teile, jedes repr@sentiert ein erfolgrei-
ches Steuerelement. Die Teile werden in der gleichen Reihenfolge zu dem verarbeitenden Pro-
gramm gesendet, in der sie im Dokumentfluss auftauchen. Teilgrenzen sollten nicht in irgend-
einem Teil der Daten auftauchen; wie dies erreicht wird, liegt außerhalb des Geltungsbereichs
dieser Spezifikation
Wie bei allen mehrteiligen MIME-Typen, hat jeder Teil einen optionalen „Content-Type“-
Header, dessen Voreinstellung „plain/text“ ist. Benutzerprogramme sollten den „Content-
Type“-Header angeben, begleitet von einem „charset“-Parameter.
In jedem Teil werden erwartet:
1. Einen „Content-Disposition“-Header, dessen Wert „form-data“ ist.
2. Ein name-Attribut, das den Steuerelementnamen des entsprechenden Steuerelements angibt.
Steuerelementnamen, die urspr nglich in Nicht-ASCII-Zeichens@tzen kodiert waren, k=n-
nen mit der Methode kodiert werden, die in [RFC2045] umrissen wird.
So w rde zum Beispiel f r ein Steuerelement mit Namen „meinesteuerung“ der korrespondie-
rende Teil so angegeben:
Content-Disposition: form-data; name="meinesteuerung"
Wie bei allen MIME- bertragungen wird „CR LF“ (zum Beispiel „%0D%0A“) dazu verwendet,
Datenzeilen voneinander zu trennen.
< 288 > Formulare
Page size: 168,00 x 240,00 mm
Jeder Teil kann kodiert und der „Content-Transfer-Encoding“-Header bergeben werden, falls
der Wert des Teils nicht konform zu der voreingestellten (7 Bit) Kodierung ist (siehe
[RFC2045], Abschnitt 6)
Wird der Inhalt einer Datei mit einem Formular bertragen, sollte der Dateiinhalt durch den
Die HTML 4.01- Spezifikation
entsprechenden Inhaltstypen (zum Beispiel „application/octet-stream“) identifiziert werden.
Werden mehrere Dateien als Ergebnis eines einfachen Formulareintrags zur ckgegeben, soll-
ten sie als „multipart/mixed“ eingebettet in „multipart/form-data“ zur ckgegeben werden.
Das Benutzerprogramm sollte versuchen, einen Dateinamen f r jede bertragene Datei zu
bergeben. Der Dateiname k=nnte mit dem Parameter „filename“ des „Content-Disposition:
form-data“-Headers angegeben werden, oder, im Fall von mehreren Dateien, in einem „Con-
tent-Disposition: file“-Header des Teilst ckes. Ist der Dateiname des Client-Betriebsystems
nicht in US-ASCII, k=nnte der Dateiname angen@hert oder mit einer Methode nach [RFC2045]
kodiert werden. Dies ist zum Beispiel in den F@llen praktisch, in denen die hochgeladenen
Dateien Verweise zueinander enthalten (zum Beispiel eine TeX-Datei und ihre „.sty“-Hilfsfor-
matbeschreibung).
Das folgende Beispiel zeigt eine „multipart/form-data“-Kodierung. Stellen Sie sich vor, wir
haben das folgende Formular:
<FORM action="[Link]
enctype="multipart/form-data"
method="post">
<P>
Wie ist Dein Name? <INPUT type="text" name="submit-name"><BR>
Welche Dateien schickst Du? <INPUT type="file" name="files"><BR>
<INPUT type="submit" value="Absenden"> <INPUT type="reset">
</FORM>
Gibt der Benutzer in der Texteingabe „Larry“ ein, und w@hlt die Textdatei „[Link]“ aus,
k=nnte das Benutzerprogramm folgende Daten zur cksenden:
Content-Type: multipart/form-data; boundary=AaB03x
- -AaB03x
Content-Disposition: form-data; name="submit-name"
Larry
- -AaB03x
Content-Disposition: form-data; name="files"; filename="[Link]"
Content-Type: text/plain
... Inhalt von [Link] ...
- -AaB03x- -
Hat der Benutzer eine zweite Datei „[Link]“ (ein Bild) ausgew@hlt, k=nnte das Benutzerpro-
gramm die Teile wie folgt aufbauen:
Content-Type: multipart/form-data; boundary=AaB03x
- -AaB03x
Content-Disposition: form-data; name="submit-name"
Formular#bertragung < 289 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Larry
- -AaB03x
Content-Disposition: form-data; name="files"
Content-Type: multipart/mixed; boundary=BbC04y
Die HTML 4.01- Spezifikation
- -BbC04y
Content-Disposition: file; filename="[Link]"
Content-Type: text/plain
... Inhalt von [Link] ...
- -BbC04y
Content-Disposition: file; filename="[Link]"
Content-Type: image/gif
Content-Transfer-Encoding: binary
...Inhalt von [Link]...
- -BbC04y- -
- -AaB03x- -
Anmerkung der bersetzer: F r diesen Abschnitt sind die Korrekturen in den
Errata zu beachten: „Beschreibung: RFC2388 beschreibt in Abschnitt 4.4 falsch: im Fall
von mehreren Dateien, in einem content-disposition: file-Header des untergeord-
neten Teils. Diese Syntax erscheint im Beispiel in Abschnitt [Link]. Berichtigung:
Ondern in content-disposition: attachment.“
18 Skripte
18.1 Einf-hrung in Skripte
Ein Client-seitiges Skript ist ein Programm, das ein HTML-Dokument begleiten kann oder
direkt in ihm eingebettet ist. Das Programm wird auf dem Rechner des Clients ausgef hrt,
wenn das Dokument geladen wird oder zu einem anderen Zeitpunkt, zum Beispiel, wenn ein
Link aktiviert wird. Die Skript-Unterst tzung von HTML ist unabh@ngig von der Skriptsprache.
Skripte bieten Autoren eine M=glichkeit, HTML-Dokumente in sehr aktiver und interaktiver
Weise zu erweitern. Beispiele daf r sind:
· Skripte k=nnen evaluiert werden, wenn ein Dokument geladen wird, um den Inhalt des
Dokuments dynamisch zu ver@ndern.
· Skripte k=nnen Formularen zur Seite gestellt werden, um Eingaben zu verarbeiten, wenn
sie gemacht werden. Autoren k=nnen dynamisch Teile eines Formulars ausf llen, die auf
den Werten anderer Felder basieren. Sie k=nnten ebenfalls sicherstellen, dass Eingabedaten
vorher festgelegten Wertebereichen entsprechen, dass Felder sich nicht gegenseitig aus-
schließen usw.
< 290 > Skripte
Page size: 168,00 x 240,00 mm
· Skripte k=nnen von Ereignissen (events) gesteuert werden, die das Dokument betreffen,
wie zum Beispiel Laden, Entladen, Elementfokus, Mausbewegung usw.
· Skripte k=nnen mit Formular-Steuerelementen verkn pft werden (zum Beispiel Schaltfl@-
chen), um graphische Elemente in der Benutzerschnittstelle zu erzeugen.
Die HTML 4.01- Spezifikation
Es gibt zwei Skriptarten, die Autoren zu einem HTML-Dokument hinzuf gen k=nnen:
· Diejenigen, die einmal ausgef hrt werden, wenn ein Dokument vom Benutzerprogramm
geladen wird. Skripte, die innerhalb eines SCRIPT-Elements stehen, werden ausgef hrt, wenn
das Dokument geladen wird. Benutzerprogrammen, die Skripte nicht verarbeiten k=nnen
oder werden, k=nnen Autoren alternativen Inhalt ber das NOSCRIPT-Element zur Verf gung
stellen.
· Diejenigen, die jedesmal ausgef hrt werden, wenn ein bestimmtes Ereignis eintritt. Diese
Skripte k=nnen mit mehreren Elementen ber die Attribute f r eingebettete Ereignisse ver-
kn pft werden.
Anmerkung: Diese Spezifikation enth,lt detailliertere Informationen zu Skripten in den Abschnitten
ber „Anmerkungen zu Skripten“ in Anhang B. n
18.2 Dokumente f-r Benutzerprogramme erstellen,
die Skripte unterst-tzen
Der folgende Abschnitt behandelt Fragen, die Benutzerprogramme betreffen, die Skripte unter-
st tzen.
18.2.1 Das Element SCRIPT
<!ELEMENT SCRIPT - - %Script; - - script statements - ->
<!ATTLIST SCRIPT
charset %Charset; #IMPLIED -- char encoding of linked resource - -
type %ContentType; #REQUIRED -- content type of script language - -
src %URI; #IMPLIED -- URI for an external script - -
defer (defer) #IMPLIED -- UA may defer execution of script - -
>
Start-Tag: erforderlich, End-Tag: erforderlich
Attributdefinitionen
src = uri [CT]
Dieses Attribut gibt den Ort eines externen Skripts an.
type = content-type [CI]
Dieses Attribut gibt die Skriptsprache des Elementinhalts an und berschreibt die Standard-
Skriptsprache. Die Skriptsprache wird als Inhaltstyp (zum Beispiel „text/javascript“) angege-
ben. Autoren m ssen einen Wert f r dieses Attribut angeben. Es gibt keinen voreingestell-
ten Wert f r dieses Attribut.
Dokumente f#r Benutzerprogramme erstellen < 291 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
language = cdata [CI]
Missbilligt. Dieses Attribut gibt die Skriptsprache des Elementinhalts an. Seine Wert ist
der Bezeichner einer Sprache, aber weil diese Bezeichner nicht standardisiert sind, wurde
dieses Attribut zu Gunsten des type-Attributs als missbilligt erkl@rt .
Die HTML 4.01- Spezifikation
defer [CI]
Ist es angegeben, gibt dieses Boolesche Attribut dem Benutzerprogramm einen Hinweis,
dass dieses Skript keinen Dokumentinhalt generieren wird (zum Beispiel kein „docu-
[Link]“ in JavaScript), so dass das Benutzerprogramm mit der Verarbeitung und Dar-
stellung fortfahren kann.
An anderer Stelle definierte Attribute
· charset (Zeichenkodierung)
Das Element SCRIPT platziert ein Skript innerhalb eines Dokuments. Diese Element kann belie-
big oft im HEAD oder BODY eines HTML-Dokuments stehen.
Das Skript kann im Inhalt des SCRIPT-Elements definiert werden oder in einer externen Datei.
Ist das src-Attribut nicht angegeben, m ssen Benutzerprogramme den Inhalt des Elements als
Skript interpretieren. Besitzt das src-Attribut einen URI-Wert, m ssen Benutzerprogramme
den Elementinhalt ignorieren und das Skript ber den URI empfangen. Beachten Sie, dass sich
das charset-Attribut auf die Zeichenkodierung des Skripts bezieht, das durch jenes src-Attribut
angegeben ist; es bezieht sich nicht auf den Inhalt des SCRIPT-Elements.
Anmerkung der bersetzer: Mit der Vorgabe, dass Benutzerprogramme den Ele-
mentinhalt ignorieren m ssen, wenn ber das src-Attribut eine externe Skript-Datei
eingebunden wird, weicht diese Spezifikation von @lteren Auffassungen einiger Browser-
anbieter ab. Bevor das src-Attribut in die HTML-Spezifikation aufgenommen wurde,
wurde der Elementinhalt als Alternative f r den Fall betrachtet, dass das Laden der
externen Datei nicht erfolgen kann.
Da viele Autoren diese Betrachtung noch in ihren K=pfen haben d rften, sei an dieser
Stelle deutlich darauf hingewiesen, dass dem nicht mehr so ist. Neuere Browser schlie-
ßen sich in ihrem Verhalten inzwischen auch dieser Spezifikation an.
Skripte werden durch Skript-Engines evaluiert, die dem Benutzerprogramm bekannt sein m s-
sen.
Die Syntax von Skriptdaten ist abh@ngig von der Skriptsprache (siehe Abschnitt 6.14).
18.2.2 Die Skriptsprache spezifizieren
Da HTML sich nicht auf eine bestimmte Skriptsprache beschr@nkt, m ssen Autoren dem
Benutzerprogramm die Sprache jedes einzelnen Skripts explizit mitteilen. Dies kann entweder
durch eine Standard-Deklaration oder durch eine lokale Deklaration geschehen.
< 292 > Skripte
Page size: 168,00 x 240,00 mm
Die Standard-Skriptsprache
Autoren sollten die Standard-Skriptsprache f r alle Skripte in einem Dokument durch Angabe
der folgenden META-Deklaration im HEAD festlegen:
Die HTML 4.01- Spezifikation
<META http-equiv="Content-Script-Type" content="type">
„type“ ist darin der Inhaltstyp (siehe Abschnitt 6.7), der die Skriptsprache benennt. Beispiele
f r Werte sind „text/tcl“, „text/javascript“, „text/vbscript“.
Ohne eine META-Deklaration kann der Standard durch den HTTP-Header „Content-Script-
Type“ gesetzt werden:
Content-Script-Type: type
„type“ ist hier ebenfalls ein Inhaltstyp, der die Skriptsprache benennt.
Benutzerprogramme sollten die Standard-Skriptsprache f r ein Dokument anhand der folgen-
den Schritte festlegen (von der h=chsten zur niedrigsten Priorit@t):
1. Spezifiziert eine META-Deklaration „Content-Script-Type“, so bestimmt der letzte im Zei-
chenstrom die Standard-Skriptsprache.
2. Anderenfalls, wenn dein HTTP-Header „Content-Script-Type“ spezifiziert, bestimmt der
letzte im Zeichenstrom die Standard-Skriptsprache.
Dokumente, die keine Informationen zur Standard-Skriptsprache geben und Elemente enthal-
ten, die Skripte f r eingebettete Ereignisse spezifizieren, sind inkorrekt. Benutzerprogramme
k=nnen trotzdem versuchen, inkorrekt angegebene Skripte zu interpretieren, sind jedoch nicht
dazu verpflichtet. Autoren-Tools sollten die Standard-Skriptsprachen-Information erzeugen,
um Autoren dabei zu unterst tzen, ung ltige Dokumente zu vermeiden.
Lokale Deklaration einer Skriptsprache
Das Attribut type muss f r jede SCRIPT-Elementinstanz in einem Dokument angegeben sein.
Der Wert des type-Attributs f r ein SCRIPT-Element berschreibt f r dieses Element die Stan-
dard-Skriptsprache.
In diesem Beispiel deklarieren wir die Standard-Skriptsprache als „text/tcl“. Wir integrieren ein
SCRIPT im Kopf, dessen Skript in einer externen Datei in der Skriptsprache „text/vbscript“ vor-
liegt. Wir beziehen auch ein SCRIPT in den Rumpf ein, das sein eigenes Skript, geschrieben in
„text/javascript“, enth@lt.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"[Link]
<HTML>
<HEAD>
<TITLE>Ein Dokument mit SCRIPT</TITLE>
<META http-equiv="Content-Script-Type" content="text/tcl">
<SCRIPT type="text/vbscript" src="[Link]
</SCRIPT>
</HEAD>
<BODY>
<SCRIPT type="text/javascript">
...etwas JavaScript...
Dokumente f#r Benutzerprogramme erstellen < 293 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
</SCRIPT>
</BODY>
</HTML>
Die HTML 4.01- Spezifikation
Referenzen auf HTML-Elemente aus einem Skript heraus
Jede Skriptsprache hat ihre eigenen Konventionen, HTML-Objekte aus einem Skript heraus zu
referenzieren. Diese Spezifikation definiert keinen Standardmechanismus, um sich auf HTML-
Objekte zu beziehen.
Jedoch sollten Skripte mit Hilfe des Elementnamens Bezug auf ein Element nehmen. Skript-Engi-
nes sollten den folgenden Ablauf beachten, wenn sie ein Element identifizieren: ein name-Attri-
but hat Vorrang vor einem id-Attribut, wenn beide angegeben sind. Ansonsten kann das eine
oder das andere verwendet werden.
18.2.3 Eingebette Ereignisse (intrinsic events)
Anmerkung: Autoren von HTML-Dokumenten werden darauf hingewiesen, dass es wahrscheinlich
Mnderungen im Bereich der eingebettetten Ereignisse geben kann (zum Beispiel, wie Skripte an Ereig-
nisse gebunden werden). Die Arbeit auf diesem Gebiet wird durch die Mitglieder der W3C Document
Object Model Working Group fortgesetzt (siehe Web-Site des W3C unter [Link] fr wei-
tere Informationen). n
Attributdefinitionen
onload = script [CT]
Das onload-Ereignis tritt ein, wenn das Benutzerprogramm den Ladevorgang eines Fensters
oder aller Frames innerhalb eines FRAMESETs abgeschlossen hat. Dieses Attribut kann mit
den Elementen BODY und FRAMESET verwendet werden.
onunload = script [CT]
Das onunload-Ereignis tritt ein, wenn ein Benutzerprogramm ein Dokument aus einem
Fenster oder Frame entfernt. Dieses Attribut kann mit den Elementen BODY und FRAMESET
verwendet werden.
onclick = script [CT]
Das onclick-Ereignis tritt ein, wenn die Taste des Zeigeger@ts ber einem Element ange-
klickt wird. Dieses Attribut kann mit den meisten Elementen verwendet werden.
ondblclick = script [CT]
Das ondblclick-Ereignis tritt ein, wenn die Taste des Zeigeger@ts ber einem Element dop-
pelt angeklickt wird. Dieses Attribut kann mit den meisten Elementen verwendet werden.
onmousedown = script [CT]
Das onmousedown-Ereignis tritt ein, wenn die Taste des Zeigeger@ts ber einem Element
heruntergedr ckt wird. Dieses Attribut kann mit den meisten Elementen verwendet wer-
den.
onmouseup = script [CT]
Das onmouseup-Ereignis tritt ein, wenn die Taste des Zeigeger@ts ber einem Element losge-
lassen wird. Dieses Attribut kann mit den meisten Elementen verwendet werden.
onmouseover = script [CT]
Das onmouseover-Ereignis tritt ein, wenn das Zeigeger@t ber ein Element bewegt wird. Die-
ses Attribut kann mit den meisten Elementen verwendet werden.
< 294 > Skripte
Page size: 168,00 x 240,00 mm
onmousemove = script [CT]
Das onmousemove-Ereignis tritt ein, wenn das Zeigeger@t ber einem Element bewegt wird,
w@hrend es ber dem Element ist. Dieses Attribut kann mit den meisten Elementen ver-
wendet werden.
Die HTML 4.01- Spezifikation
onmouseout = script [CT]
Das onmouseout-Ereignis tritt ein, wenn das Zeigeger@t von einem Element wegbewegt wird.
Dieses Attribut kann mit den meisten Elementen verwendet werden.
onfocus = script [CT]
Das onfocus-Ereignis tritt ein, wenn ein Element den Fokus erh@lt, entweder durch das Zei-
geger@t oder durch die Tabulatornavigation. Dieses Attribut kann mit den folgenden Ele-
menten verwendet werden: A, AREA, LABEL, INPUT, SELECT, TEXTAREA und BUTTON.
onblur = script [CT]
Das onblur-Ereignis tritt ein, wenn das Element den Fokus verliert, entweder durch das Zei-
geger@t oder durch die Tabulatornavigation. Es kann mit den gleichen Elementen verwendet
werden wie onfocus.
onkeypress = script [CT]
Das onkeypress-Ereignis tritt ein, wenn eine Taste ber einem Element gedr ckt und wieder
losgelassen wird. Dieses Attribut kann mit den meisten Elementen verwendet werden.
onkeydown = script [CT]
Das onkeydown-Ereignis tritt ein, wenn eine Taste ber einem Element gedr ckt wird. Dieses
Attribut kann mit den meisten Elementen verwendet werden.
onkeyup = script [CT]
Das onkeyup-Ereignis tritt ein, wenn eine Taste ber einem Element losgelassen wird. Dieses
Attribut kann mit den meisten Elementen verwendet werden.
onsubmit = script [CT]
Das onsubmit-Ereignis tritt ein, wenn ein Formular abgeschickt wird. Es gilt nur f r das Ele-
ment FORM.
onreset = script [CT]
Das onreset-Ereignis tritt ein, wenn ein Formular zur ckgesetzt wird. Es gilt nur f r das Ele-
ment FORM.
onselect = script [CT]
Das onselect-Ereignis tritt ein, wenn ein Benutzer Text in einem Textfeld ausw@hlt. Dieses
Attribut kann mit den Elementen INPUT und TEXTAREA verwendet werden.
onchange = script [CT]
Das onchange-Ereignis tritt ein, wenn ein Steuerelement den Eingabefokus verliert und sein
Wert seit dem Erhalt des Fokus ver@ndert wurde. Dieses Attribut gilt f r die folgenden Ele-
mente: INPUT, SELECT und TEXTAREA.
Anmerkung der bersetzer: Die HTML-Spezifikation hat sich erst vergleichs-
weise sp@t der konkreten Einbindung von Skripten angenommen (ab HTML 4). Skripte
werden aber schon geraume Zeit von den Browsern unterst tzt (erste Implementie-
rung unter dem Namen „LiveScript“ im Navigator 2 beta, Ende 1995; siehe www.
[Link]/javascript/#chronologie). Darunter sind Browser, deren Skript-Engines
eigene, voneinander abweichende Entwicklungswege nahmen. Beim Einsatz von Skripten
Dokumente f#r Benutzerprogramme erstellen < 295 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
muss man dieser Entwicklung noch immer Rechnung tragen. Man darf also nicht unbe-
dingt erwarten, dass mehrere Browser, die vermeintlich eine bestimmte Skriptsprache
unterst tzen, dies in der gleichen Weise tun.
Die HTML 4.01- Spezifikation
Die oben aufgelisteten Attribute zur Reaktion auf Ereignisse sind ein Beispiel daf r. Ob
die Reaktionsm=glichkeit auf ein Ereignis f r ein bestimmtes Element implementiert ist,
kann man nicht allgemeing ltig sagen. Auch diese Spezifikation, an die sich neuere
Browser durchaus halten, legt f r einige der Attribute nicht definitiv fest, f r welche Ele-
mente sie gelten m ssen, sagt nur „f r die meisten“. Als Autor sollte man sich dieser
Tatsache stets bewusst sein, wenn man praxistaugliche Dokumente erstellen m=chte.
Es ist m=glich, eine Aktion mit einer bestimmten Anzahl von Ereignissen zu verkn pfen, die auf-
treten, wenn ein Benutzer mit einem Benutzerprogramm interagiert. Jedes der oben aufgef hr-
ten „eingebetteten Ereignisse“ nimmt einen Wert an, der ein Skript ist. Das Skipt wird immer
dann ausgef hrt, wenn das Ereignis f r dieses Element eintritt. Die Syntax der Skriptdaten ist
abh@ngig von der Skriptsprache.
Anmerkung der bersetzer: Um genau zu sein: In der Auflistung oben sind nicht
die „eingebetteten Ereignisse“ selbst aufgef hrt, sondern die Attribute, deren Werte
Skripte darstellen, die bei Eintreten der eingebetteten Ereignisse ausgef hrt werden.
Eingangs dieses Kapitels werden sie korrekt „Attribute f r eingebettete Ereignisse (in-
trinsic event attributes)“ genannt. An dieser Stelle geht man etwas unsauberer, damit
eventuell auch irref hrend mit dem Begriff um.
Steuerelemente wie INPUT, SELECT, BUTTON, TEXTAREA und LABEL reagieren alle auf bestimmte ein-
gebettete Ereignisse. Stehen diese Elemente nicht innerhalb eines Formulars, k=nnen sie dazu
verwendet werden, die graphische Benutzerschnittstelle des Dokuments aufzuwerten.
Zum Beispiel wollen Autoren vielleicht Schaltfl@chen in ihre Dokumente einbinden, die zwar
kein Formular bertragen, aber dennoch mit einem Server kommunizieren, wenn sie aktiviert
werden.
Die folgenden Bespiele zeigen einige m=gliche Verhaltensweisen von Steuerelementen und
Benutzerschnittstellen, die auf eingebetteten Ereignissen beruhen.
Im folgenden Beispiel ist userName ein erforderliches Textfeld. Versucht der Benutzer, das
Feld zu verlassen, ruft das onblur-Ereignis eine JavaScript-Funktion auf, die best@tigt, dass user-
Name einen g ltigen Wert hat.
<INPUT NAME="userName" onblur="validUserName([Link])">
Anmerkung der bersetzer: Gemeint ist, dass onblur eine Funktion, hier valid-
UserName(), aufgerufen wird, die pr ft, ob ein g ltiger Wert eingegeben wurde. ber
eventuelle Reaktionen auf g ltige oder ung ltige Eingaben sagt das einfache Beispiel
nichts.
< 296 > Skripte
Page size: 168,00 x 240,00 mm
Hier ist ein weiteres JavaScript-Beispiel:
<INPUT NAME="num"
onchange="if (!checkNum([Link], 1, 10))
{[Link]();[Link]();} else {thanks()}"
Die HTML 4.01- Spezifikation
VALUE="0">
Hier ist ein VBScript-Beispiel eines Event-Handlers f r ein Textfeld:
<INPUT name="edit1" size="50">
<SCRIPT type="text/vbscript">
Sub edit1_changed()
If [Link] = "abc" Then
[Link] = True
Else
[Link] = False
End If
End Sub
</SCRIPT>
Hier ist das gleiche Beispiel mit Tcl:
<INPUT name="edit1" size="50">
<SCRIPT type="text/tcl">
proc edit1_changed {} {
if {[edit value] == abc} {
button1 enable 1
} else {
button1 enable 0
}
}
edit1 onChange edit1_changed
</SCRIPT>
Hier ist ein JavaScript-Beispiel f r die Ereignisbindung (event binding) in einem Skript. Zuerst
folgt ein einfacher Klick-Handler:
<BUTTON type="button" name="mybutton" value="10">
<SCRIPT type="text/javascript">
function my_onclick() {
. . .
}
[Link] = my_onclick
</SCRIPT>
</BUTTON>
Hier ist ein in interessanterer Fenster-Handler:
<SCRIPT type="text/javascript">
function my_onload() {
. . .
}
Dokumente f#r Benutzerprogramme erstellen < 297 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
var win = [Link]("some/other/URI")
if (win) [Link] = my_onload
</SCRIPT>
Mit Tcl sieht das so aus:
Die HTML 4.01- Spezifikation
<SCRIPT type="text/tcl">
proc my_onload {} {
. . .
}
set win [window open "some/other/URI"]
if {$win != ""} {
$win onload my_onload
}
</SCRIPT>
Anmerkung: Beachten Sie, dass „[Link]“ oder ,quivalente Ausdrcke in eingebetteten Event-
Handlern eher ein neues Dokument erzeugen und hineinschreiben als das aktuelle zu ver,ndern. n
Anmerkung der bersetzer: In der Regel funktioniert die Ausf hrung von docu-
[Link]() zur Modifikation des aktuellen Dokuments nur w@hrend das Dokument
zum ersten Mal aufgebaut wird (salopp ausgedr ckt: „w@hrend des Ladens“). Falls Sie
das Dokument nachtr,glich ver@ndern wollen, vergessen Sie [Link]() vollkom-
men! In einem solchen Fall ist DOM-Scripting (Document Object Model) angesagt.
Doch das ist ein Thema, das den Rahmen dieser Spezifikation sprengen w rde.
18.2.4 Dynamische Modifikation von Dokumenten
Skripte, die ausgef hrt werden, wenn das Dokument geladen wird, k=nnen in der Lage sein,
den Dokumentinhalt dynamisch zu modifizieren. Die F@higkeit, das zu tun, ist abh@ngig von der
Skriptsprache selbst (zum Beispiel die Angabe „[Link]“ im HTML-Objektmodell, die
von einigen Herstellern unterst tzt wird).
Die dynamische Modifikation des Dokuments k=nnte wie folgt ausgef hrt werden:
1. Alle SCRIPT-Elemente werden in der Reihenfolge evaluiert, in der das Dokument geladen
wird.
2. Alle Skripte innerhalb eines gegebenen SCRIPT-Elements, die SGML-konformes CDATA
erzeugen, werden evaluiert. Der generierte Text wird anstelle des SCRIPT-Elements in den
Dokumentinhalt eingef gt.
3. Das erzeugte CDATA wird wieder evaluiert.
HTML-Dokumente m ssen konform zu der HTML-DTD sein, sowohl bevor als auch nachdem
irgendein SCRIPT-Element verarbeitet wurde.
Anmerkung der bersetzer: Es sei noch einmal betont, was im vorhergehenden
Kommentar bereits gesagt wurde: Die berschrift der dynamischen Modifikation verlei-
tet zur Annahme, dass sich die HTML-Seite ver@ndert, w,hrend sie angezeigt wird. Hier
geht es jedoch ausschließlich um eine Modifikation vor dem ersten Anzeigen der Seite.
< 298 > Skripte
Page size: 168,00 x 240,00 mm
Alles andere erfordert einen programmgesteuerten Eingriff in das Document Object
Model der angezeigten Seite. Dieses Thema ist jedoch zu neu, als dass es in dieser
HTML-Spezifikation ber cksichtigt sein k=nnte.
Die HTML 4.01- Spezifikation
Die Details sind nat rlich auch von der verwendeten Script-Sprache abh@ngig. Da das
W3C keine Programmiersprachen „im Angebot“ hat, wird es im Rahmen der edition
[Link] auch keine Einf hrung dazu geben. Dem interessierten Leser sei deshalb ein
anderer Titel f r den Einstieg in JavaScript empfohlen: <eigenwerbung>[Link]-
[Link]</eigenwerbung>
Das folgende Beispiel zeigt, wie Skripte ein Dokument dynamisch ver@ndern k=nnen. Das fol-
gende Skript:
<TITLE>Testdokument</TITLE>
<SCRIPT type="text/javascript">
[Link]("<p><b>Hello World!<\/b>")
</SCRIPT>
hat die gleichen Auswirkungen wie dieser HTML-Auszeichnung:
<TITLE>Testdokument</TITLE>
<p><b>Hello World!</b>
18.3 Dokumente f-r Benutzerprogramme erstellen,
die Skripte nicht unterst-tzen
Der folgende Abschnitt er=rtert, wie Autoren Dokumente erzeugen k=nnen, die mit Benutzer-
programmen, die Skripte nicht unterst tzen, funktionieren.
18.3.1 Das Element NOSCRIPT
<!ELEMENT NOSCRIPT - - (%block;)+
-- alternate content container for non script-based rendering - ->
<!ATTLIST NOSCRIPT
%attrs; - - %coreattrs, %i18n, %events - -
>
Start-Tag: erforderlich, End-Tag: erforderlich
Das Element NOSCRIPT erlaubt es Autoren, alternativen Inhalt anzubieten, wenn ein Skript nicht
ausgef hrt wird. Der Inhalt eines NOSCRIPT-Elements sollte nur in den folgenden F@llen von
einem skriptf@higen Benutzerprogramm dargestellt werden:
·· Das Benutzerprogramm ist so konfiguriert, dass es Skripte nicht evaluiert.
Das Benutzerprogramm unterst tzt eine Skriptsprache nicht, die vorher durch ein SCRIPT-
Element im Dokument angef hrt wurde.
Benutzerprogramme, die Client-seitige Skripte nicht unterst tzen, m ssen den Inhalt dieses
Elements darstellen.
Dokumente f#r Benutzerprogramme erstellen < 299 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Im folgenden Beispiel wird ein Benutzerprogramm, welches das SCRIPT ausf hrt, einige dyna-
misch erzeugte Daten in das Dokument einf gen. Unterst tzt das Benutzerprogramm keine
Skripte, kann der Benutzer die Daten dennoch ber einen Link beziehen.
Die HTML 4.01- Spezifikation
<SCRIPT type="text/tcl">
...ein Tcl-Skript, um Daten einzufBgen...
</SCRIPT>
<NOSCRIPT>
<P>Zugang zu <A href="[Link]
</NOSCRIPT>
18.3.2 Skriptdaten vor Benutzerprogrammen verbergen
Benutzerprogramme, die das SCRIPT-Element nicht erkennen, werden wahrscheinlich den Inhalt
des Elements als Text darstellen. Einige Skript-Engines, einschließlich der Engines f r die Spra-
chen JavaScript, VBScript und Tcl, gestatten die Angabe der Skriptzeilen in SGML-Kommenta-
ren. Benutzerprogramme, die das SCRIPT-Element nicht erkennen, werden folglich den Kom-
mentar ignorieren, w@hrend clevere Skript-Engines verstehen werden, dass dieses Skript im
Kommentar ausgef hrt werden soll.
Eine weitere L=sung des Problems ist die Speicherung der Skripte in externen Dokumenten
und ihr Aufruf ber das Attribut src.
Skripte in JavaScript kommentieren
Die JavaScript-Engine erlaubt die Zeichenkette „<!- -“ zu Beginn des SCRIPT-Elements und
ignoriert weitere Zeichen bis zum Ende der Zeile. JavaScript interpretiert „//“ als den Beginn
eines Kommentars, der sich bis zum Ende der Zeile erstreckt. Dies wird ben=tigt, um die Zei-
chenkette „- ->“ vor dem JavaScript-Parser zu verbergen.
<SCRIPT type="text/javascript">
<!- - um Skriptinhalt vor alten Browsern zu verstecken
function square(i) {
[Link]("The call passed ", i ," to the function.","<BR>")
return i * i
}
[Link]("The function returned ",square(5),".")
// end hiding contents from old browsers - ->
</SCRIPT>
Skripte in VBScript kommentieren
In VBScript bewirkt ein Apostroph (single quote), dass der Rest der aktuellen Zeile als Kom-
mentar angesehen wird. Deshalb kann es dazu verwendet werden, die Zeichenkette „- ->“ vor
VBScript zu verbergen, zum Beispiel:
<SCRIPT type="text/vbscript">
<!- -
Sub foo()
...
End Sub
' - ->
</SCRIPT>
< 300 > Skripte
Page size: 168,00 x 240,00 mm
Skripte in TCL kommentieren
In Tcl wird der Rest der Zeile durch das Zeichen „#“ auskommentiert:
<SCRIPT type="text/tcl">
Die HTML 4.01- Spezifikation
<!- - um Skriptinhalt vor alten Browsern zu verstecken
proc square {i} {
document write "The call passed $i to the function.<BR>"
return [expr $i * $i]
}
document write "The function returned [square 5]."
# end hiding contents from old browsers - ->
</SCRIPT>
Anmerkung: Einige Browser schließen Kommentare nach dem ersten „>“-Zeichen. Um Skriptinhalt
vor solchen Browsern zu verbergen, k nnen Sie Operanden in Vergleichs- und Shift-Operationen vertau-
schen (verwenden Sie zum Beispiel „y < x“ statt „x > y“) oder verwenden Sie spezifische Ersatzzeichen
(escapes) der Skriptsprache fr „>“. n
19 SGML-Referenzinformationen f-r
HTML
Die folgenden Abschnitte enthalten die formale SGML-Definition von HTML 4. Dazu geh=ren
die SGML-Deklaration, die Documenttyp-Definition (DTD), die Zeichen-Entity-Referenzen,
sowie ein Beispiel f r einen SGML-Katalog.
Diese Dateien stehen auch im ASCII-Format zur Verf gung:
Default DTD:
[Link]
Transitional DTD:
[Link]
Frameset DTD:
[Link]
SGML-Deklaration:
[Link]
Dateien mit Entity-Definitionen:
[Link]
[Link]
[Link]
Beispielkatalog:
[Link]
SGML-Referenzinformationen f#r HTML < 301 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
19.1 Dokumentvalidierung
Viele Autoren verlassen sich darauf, ihre Dokumente mit einer kleinen Menge von Browsern
zu testen. Die Annahme ist, dass die Dokumente g ltig sind, falls die Browser sie darstellen
Die HTML 4.01- Spezifikation
k=nnen. Bedauerlicherweise ist das eine sehr unzul@ngliche Art die G ltigkeit eines Dokuments
pr@zise zu berpr fen. Der Grund ist der, dass die Browser so entworfen wurden, dass sie mit
ung ltigen Dokumenten umgehen k=nnen. Sie versuchen die Dokumente so gut wie m=glich
anzuzeigen, um frustrierte Benutzer zu vermeiden.
Zur besseren Validierung sollten Sie ihre Dokumente mit einem SGML-Parser wie nsgmls
(siehe [SP]) pr fen, um sicherzustellen, dass Ihre HTML-Dokumente konform zur HTML
4-DTD sind. Falls die Dokumenttyp-Deklaration ihres Dokuments einen URI enth@lt und Ihr
SGML-Parser diese Art von Systembezeichner unterst tzt, dann wird er die DTD ber das
Netz laden. Andernfalls k=nnen Sie folgenden SGML-Katalog verwenden. Er nimmt an, dass die
DTD unter dem Namen „[Link]“ gespeichert ist und dass sich die Entities in den Dateien
„[Link]“, „[Link]“ und „[Link]“ befinden. Stellen Sie in jedem Fall
sicher, dass Ihr SGML-Parser in der Lage ist Zeichen gem@ß [ISO10646] zu handhaben. F r
Details beachten Sie die Dokumentation ihres Validierungswerkzeugs.
Anmerkung der bersetzer: F r die Pr fung einer großen Zahl von HTML-Doku-
menten empfiehlt es sich, einen Parser wie den erw@hnten nsgmls lokal zu installieren.
F r einzelne Seiten ist der Service des W3C besser geeignet: Unter [Link] k=n-
nen Sie Ihre Dokumente online pr fen – nicht nur auf Konformit@t bez glich HTML, son-
dern auch bez glich XHTML, CSS und anderen W3C-Empfehlungen.
Beachten Sie bitte auch, dass eine solche Validierung, obwohl n tzlich und dringend empfohlen,
keine Garantie daf r darstellt, dass ein Dokument konform zur HTML 4-Spezifikation ist. Dies
liegt daran, dass sich ein SGML-Parser einzig und allein auf die vorgegebene SGML-DTD ver-
l@sst, die nicht alle Aspekte eines g ltigen HTML 4-Dokuments ausdr ckt. Ein SGML-Parser
sichert insbesondere ab, dass die Syntax, die Struktur, die Liste der Elemente und deren Attri-
bute g ltig sind. Er kann aber beispielsweise keine Fehler abfangen, wie die Zuweisung des
width-Attributs eines IMG-Elements auf einen ung ltigen Wert (zum Beispiel „bla“ oder „12,5“).
Obwohl die Spezifikation den Wert dieses Attributs auf eine ganze Zahl beschr@nkt, die eine
L@nge in Pixeln darstellt, legt die DTD diesen Wert lediglich auf CDATA fest, was praktisch
jeden beliebigen Wert zul@sst. Nur ein spezialisiertes Programm kann die HTML 4-Spezifikation
vollst@ndig erfassen.
Anmerkung der bersetzer: Mittlerweile gibt es neben den DTDs die so genann-
ten XML-Schemata. Sie erlauben zus@tzlich zu den M=glichkeiten, die DTDs er=ffnen,
auch die Definition von Datentypen f r Elementinhalt und Attributwerte. F r XHTML
gibt es bereits ein Schema und ein schemaf@higer Parser kann damit die G ltigkeit eines
XHTML-Dokuments noch besser pr fen als oben beschrieben.
Nichtsdestotrotz ist diese Art der Validierung sehr empfohlen. Sie kann eine große Zahl von
Fehlern finden, die Dokumente ung ltig machen.
< 302 > SGML-Referenzinformationen f#r HTML
Page size: 168,00 x 240,00 mm
19.2 Beispiel f-r einen SGML-Katalog
Dieser Katalog enth@lt die override-Anweisung, um sicherzustellen, dass verarbeitende Soft-
ware wie etwa nsgmls einen Public Identifier einem System Identifier vorzieht. Das bedeutet,
Die HTML 4.01- Spezifikation
dass Benutzer nicht mit dem Web verbunden sein m ssen, wenn sie URI-basierte System Iden-
tifier verwenden.
OVERRIDE YES
PUBLIC "-//W3C//DTD HTML 4.01//EN" [Link]
PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" [Link]
PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" [Link]
PUBLIC "-//W3C//ENTITIES Latin1//EN//HTML" [Link]
PUBLIC "-//W3C//ENTITIES Special//EN//HTML" [Link]
PUBLIC "-//W3C//ENTITIES Symbols//EN//HTML" [Link]
20 SGML-Deklaration von HTML 4
Anmerkung der bersetzer: Im Hinblick auf gegenw@rtige und zuk nftige Ent-
wicklungen, insbesondere XML und XHTML, kann man diesen Abschnitt als praktisch
wenig relevant bezeichnen. Sollten Sie HTML im Dialekt XHTML einsetzen, was einer-
seits empfehlenswert ist, andererseits diese HTML-Spezifikation noch keineswegs ber-
fl ssig macht, so ist wichtig, dass f r alle XML-Sprachen (wie XHTML) eine einheitliche
SGML-Deklaration gilt. Informationen dar ber finden Sie beim W3C unter
[Link]
Hinweis: Die Gesamtzahl der Codepunkte, die im Dokumentzeichensatz dieser SGML-Deklaration
erlaubt sind, enth,lt die ersten 17 Ebenen von [ISO10646] (17 mal 65536). Diese Einschr,nkung
wurde gemacht, weil die Anzahl durch die aktuelle Version der SGML-Norm auf eine L,nge von 8 Zif-
fern beschr,nkt ist. Damit ist keine Aussage ber die Wahrscheinlichkeit einer langfristigen Einschr,n-
kung von Zeichen in UCS auf die ersten 17 Ebenen. Es ist wahrscheinlich, dass die Beschr,nkunge auf
8 Ziffern in SGML entfernt, und diese Spezifikation aktualisiert sein wird, bevor die erste Zuweisung
eines Zeichens jenseits der ersten 17 Ebenen erfolgt. n
Hinweis: Streng genommen verweist die ISO-Registrierungsnummer 177 auf den ursprnglichen
Zustand von [ISO10646] aus 1993. Die Mnderungen seit 1993 waren das Hinzufgen von Zeichen
und das einmalige Verschieben einer großen Zahl von Codepunkten fr Korean Hangul (Amendment
5). Neuauflagen der HTML-4-Spezifikation k nnen die Verweise auf ISO 10646 aktualisieren, um wei-
tere Mnderungen zu bercksichtigen. n
Beispiel f#r einen SGML-Katalog < 303 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
20.1 SGML Declaration
<!SGML "ISO 8879:1986 (WWW)"
--
Die HTML 4.01- Spezifikation
SGML Declaration for HyperText Markup Language version HTML 4
With support for the first 17 planes of ISO 10646 and
increased limits for tag and literal lengths etc.
--
CHARSET
BASESET "ISO Registration Number 177//CHARSET
ISO/IEC 10646-1:1993 UCS-4 with
implementation level 3//ESC 2/5 2/15 4/6"
DESCSET 0 9 UNUSED
9 2 9
11 2 UNUSED
13 1 13
14 18 UNUSED
32 95 32
127 1 UNUSED
128 32 UNUSED
160 55136 160
55296 2048 UNUSED - - SURROGATES - -
57344 1056768 57344
CAPACITY SGMLREF
TOTALCAP 150000
GRPCAP 150000
ENTCAP 150000
SCOPE DOCUMENT
SYNTAX
SHUNCHAR CONTROLS 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 127
BASESET "ISO 646IRV:1991//CHARSET
International Reference Version
(IRV)//ESC 2/8 4/2"
DESCSET 0 128 0
FUNCTION
RE 13
RS 10
SPACE 32
TAB SEPCHAR 9
NAMING LCNMSTRT ""
UCNMSTRT ""
LCNMCHAR ".-_:"
UCNMCHAR ".-_:"
NAMECASE GENERAL YES
ENTITY NO
DELIM GENERAL SGMLREF
HCRO "&#x" - - 38 is the number for ampersand - -
SHORTREF SGMLREF
NAMES SGMLREF
< 304 > SGML-Deklaration von HTML 4
Page size: 168,00 x 240,00 mm
QUANTITY SGMLREF
ATTCNT 60 -- increased - -
ATTSPLEN 65536 -- These are the largest values --
LITLEN 65536 -- permitted in the declaration --
NAMELEN 65536 -- Avoid fixed limits in actual --
Die HTML 4.01- Spezifikation
PILEN 65536 -- implementations of HTML UA's --
TAGLVL 100
TAGLEN 65536
GRPGTCNT 150
GRPCNT 64
FEATURES
MINIMIZE
DATATAG NO
OMITTAG YES
RANK NO
SHORTTAG YES
LINK
SIMPLE NO
IMPLICIT NO
EXPLICIT NO
OTHER
CONCUR NO
SUBDOC NO
FORMAL YES
APPINFO NONE
>
Die Listings, die sich an der folgenden Stelle in der englischen Online-Fassung befinden, sind vor
allem in elektronischer Form interessant. Sie stehen deshalb auch in der deutschen Online-Fas-
sung zur Verf gung. Zur leichteren Orientierung haben wir die Abschnitt berschriften abge-
druckt.
21 Documenttyp-Definition
22 Transitional-
Documenttyp-Definition
23 Frameset-Dokumenttyp-Definition
Documenttyp-Definition < 305 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
24 Zeichen-Entity-Referenzen in
HTML 4
Die HTML 4.01- Spezifikation
24.1 Einf-hrung in Zeichen-Entity-Referenzen
Eine Zeichen-Entity-Referenz ist ein SGML-Konstrukt, das ein Zeichen aus dem f r das Doku-
ment g ltigen Zeichensatz referenziert.
Diese Version von HTML unterst tzt mehrere S@tze von Zeichen-Entity-Referenzen:
· Zeichen aus ISO 8859-1 (Latin-1): In bereinstimmung mit Abschnitt 14 von [RFC1866]
wurde die Menge der Latin-1-Entities durch diese Spezifikation erweitert, um den gesamten
rechten Teil von ISO-8859-1 (alle Code-Positionen mit gesetzem High-Order-Bit) abzude-
cken. Das schließt die bereits weit verbreiteten , © und ® ein. Die Namen
der Entities sind den Anh@ngen von SGML entnommen (definiert in [ISO8879]).
· Symbole, mathematische Symbole und griechische Buchstaben: Diese Zeichen k=nnen
durch Glyphen in der Adobe-Schrift „Symbol“ dargestellt werden.
· markup-relevante und internationale Zeichen (zum Beispiel f r bidirektionalen Text)
Die folgenden Abschnitte stellen die vollst@ndige Liste von Zeichen-Entity-Referenzen vor.
Obwohl durch [ISO10646] die Konvention besteht, die Kommentare nach jedem Eintrag in
Großbuchstaben zu schreiben, haben wir sie in dieser Spezifikation in Kleinbuchstaben gewan-
delt, um die Lesbarkeit zu verbessern.
Anmerkung der bersetzer: In den weiteren Abschnitten finden Sie die in Men-
gen gruppierten Zeichen-Entities, ihren Namen und eine Beschreibung, allerdings keine
Darstellung. F r diese bersetzung haben wir Abbildungen angefertigt und damit gleich
einen Browser getestet: Die hier gezeigten Grafiken zeigen Screenshots vom Mozilla-
Browser. Zu sehen sind HTML-Tabellen mit den Entity-Namen und der korrespondie-
renden Darstellung. Da einige Entities Leerraum darstellen, sind die Entity-Referenzen
in eckige Klammern gesetzt. Die Klammern geh=ren also nicht zur Darstellung. Beach-
ten Sie auch, dass in einigen F@llen die Unterl@ngen zu groß erscheinen. Eine Ursache zu
finden oder gar Abhilfe zu schaffen, ist nicht gelungen. Den Grafiken ist zu entnehmen,
dass eine weitgehende, aber keine vollst@ndige Abdeckung der HTML-4-Zeichen-Enti-
ties vorliegt.
Die einzelnen HTML-Tabellenzeilen sehen exemplarisch wie folgt aus:
<tr>
<td class="entname">aacute</td><td class="rendering">[á]</td>
<td class="entname">Aacute</td><td class="rendering">[Á]</td>
<td class="entname">Acirc</td><td class="rendering">[Â]</td>
<td class="entname">acirc</td><td class="rendering">[â]</td>
</tr>
< 306 > Zeichen-Entity-Referenzen in HTML 4
Page size: 168,00 x 240,00 mm
Die HTML 4.01- Spezifikation
Einf#hrung in Zeichen-Entity-Referenzen < 307 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Die HTML 4.01- Spezifikation
< 308 > Zeichen-Entity-Referenzen in HTML 4
Page size: 168,00 x 240,00 mm
Die HTML 4.01- Spezifikation
24.2 Zeichen-Entity-Referenzen f-r Zeichen aus ISO
8859-1
Die Zeichen-Entity-Referenzen in diesem Abschnitt erzeugen Zeichen, deren numerische Oqui-
valente bereits durch konforme HTML-2.0-Benutzerprogramme unterst tzt werden sollten.
Folglich ist die Zeichen-Entity-Referenz ÷ eine bequemere Form als ÷, um das
Geteilt-durch-Zeichen zu erhalten (*).
Um diese benannten Entities zu unterst tzen, m ssen Benutzerprogramme lediglich die Entity-Na-
men erkennen und sie in Zeichen wandeln, die innerhalb des Repertoires von [ISO88591] liegen.
Das Zeichen 65533 (hexadezimal FFFD) ist das letzte g ltige Zeichen in UCS-2. 65534 (hexa-
dezimal FFFE) ist nicht zugewiesen und als byte-vertauschte Version des ZERO WIDTH NON-
BREAKING SPACE zum Zwecke der Byte-Order-Erkennung reserviert. 65535 (hexadezimal
FFFF) ist nicht zugewiesen.
Zeichen-Entity-Referenzen f#r Zeichen aus ISO 8859-1 < 309 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
24.2.1 Die Liste der Zeichen
<!- - Portions * International Organization for Standardization 1986
Permission to copy in any form is granted for use with
conforming SGML systems and applications as defined in
Die HTML 4.01- Spezifikation
ISO 8879, provided this notice is included in all copies.
- ->
<!- - Character entity set. Typical invocation:
<!ENTITY % HTMLlat1 PUBLIC
"-//W3C//ENTITIES Latin 1//EN//HTML">
%HTMLlat1;
- ->
<!ENTITY nbsp CDATA " " - - no-break space = non-breaking space,
U+00A0 ISOnum - ->
<!ENTITY iexcl CDATA "¡" - - inverted exclamation mark, U+00A1 ISOnum - ->
<!ENTITY cent CDATA "¢" - - cent sign, U+00A2 ISOnum - ->
<!ENTITY pound CDATA "£" - - pound sign, U+00A3 ISOnum - ->
<!ENTITY curren CDATA "¤" - - currency sign, U+00A4 ISOnum - ->
<!ENTITY yen CDATA "¥" - - yen sign = yuan sign, U+00A5 ISOnum - ->
<!ENTITY brvbar CDATA "¦" - - broken bar = broken vertical bar,
U+00A6 ISOnum - ->
<!ENTITY sect CDATA "§" - - section sign, U+00A7 ISOnum - ->
<!ENTITY uml CDATA "¨" - - diaeresis = spacing diaeresis,
U+00A8 ISOdia - ->
<!ENTITY copy CDATA "©" - - copyright sign, U+00A9 ISOnum - ->
<!ENTITY ordf CDATA "ª" - - feminine ordinal indicator, U+00AA ISOnum - ->
<!ENTITY laquo CDATA "«" - - left-pointing double angle quotation mark
= left pointing guillemet, U+00AB ISOnum - ->
<!ENTITY not CDATA "¬" - - not sign, U+00AC ISOnum - ->
<!ENTITY shy CDATA "­" - - soft hyphen = discretionary hyphen,
U+00AD ISOnum - ->
<!ENTITY reg CDATA "®" - - registered sign = registered trade mark sign,
U+00AE ISOnum - ->
<!ENTITY macr CDATA "¯" - - macron = spacing macron = overline
= APL overbar, U+00AF ISOdia - ->
<!ENTITY deg CDATA "°" - - degree sign, U+00B0 ISOnum - ->
<!ENTITY plusmn CDATA "±" - - plus-minus sign = plus-or-minus sign,
U+00B1 ISOnum - ->
<!ENTITY sup2 CDATA "²" - - superscript two = superscript digit two
= squared, U+00B2 ISOnum - ->
<!ENTITY sup3 CDATA "³" - - superscript three = superscript digit three
= cubed, U+00B3 ISOnum - ->
<!ENTITY acute CDATA "´" - - acute accent = spacing acute,
U+00B4 ISOdia - ->
<!ENTITY micro CDATA "µ" - - micro sign, U+00B5 ISOnum - ->
<!ENTITY para CDATA "¶" - - pilcrow sign = paragraph sign,
U+00B6 ISOnum - ->
<!ENTITY middot CDATA "·" - - middle dot = Georgian comma
= Greek middle dot, U+00B7 ISOnum - ->
<!ENTITY cedil CDATA "¸" - - cedilla = spacing cedilla, U+00B8 ISOdia - ->
<!ENTITY sup1 CDATA "¹" - - superscript one = superscript digit one,
U+00B9 ISOnum - ->
<!ENTITY ordm CDATA "º" - - masculine ordinal indicator,
U+00BA ISOnum - ->
< 310 > Zeichen-Entity-Referenzen in HTML 4
Page size: 168,00 x 240,00 mm
<!ENTITY raquo CDATA "»" - - right-pointing double angle quotation mark
= right pointing guillemet, U+00BB ISOnum - ->
<!ENTITY frac14 CDATA "¼" - - vulgar fraction one quarter
= fraction one quarter, U+00BC ISOnum - ->
<!ENTITY frac12 CDATA "½" - - vulgar fraction one half
Die HTML 4.01- Spezifikation
= fraction one half, U+00BD ISOnum - ->
<!ENTITY frac34 CDATA "¾" - - vulgar fraction three quarters
= fraction three quarters, U+00BE ISOnum - ->
<!ENTITY iquest CDATA "¿" - - inverted question mark
= turned question mark, U+00BF ISOnum - ->
<!ENTITY Agrave CDATA "À" - - latin capital letter A with grave
= latin capital letter A grave,
U+00C0 ISOlat1 - ->
<!ENTITY Aacute CDATA "Á" - - latin capital letter A with acute,
U+00C1 ISOlat1 - ->
<!ENTITY Acirc CDATA "Â" - - latin capital letter A with circumflex,
U+00C2 ISOlat1 - ->
<!ENTITY Atilde CDATA "Ã" - - latin capital letter A with tilde,
U+00C3 ISOlat1 - ->
<!ENTITY Auml CDATA "Ä" - - latin capital letter A with diaeresis,
U+00C4 ISOlat1 - ->
<!ENTITY Aring CDATA "Å" - - latin capital letter A with ring above
= latin capital letter A ring,
U+00C5 ISOlat1 - ->
<!ENTITY AElig CDATA "Æ" - - latin capital letter AE
= latin capital ligature AE,
U+00C6 ISOlat1 - ->
<!ENTITY Ccedil CDATA "Ç" - - latin capital letter C with cedilla,
U+00C7 ISOlat1 - ->
<!ENTITY Egrave CDATA "È" - - latin capital letter E with grave,
U+00C8 ISOlat1 - ->
<!ENTITY Eacute CDATA "É" - - latin capital letter E with acute,
U+00C9 ISOlat1 - ->
<!ENTITY Ecirc CDATA "Ê" - - latin capital letter E with circumflex,
U+00CA ISOlat1 - ->
<!ENTITY Euml CDATA "Ë" - - latin capital letter E with diaeresis,
U+00CB ISOlat1 - ->
<!ENTITY Igrave CDATA "Ì" - - latin capital letter I with grave,
U+00CC ISOlat1 - ->
<!ENTITY Iacute CDATA "Í" - - latin capital letter I with acute,
U+00CD ISOlat1 - ->
<!ENTITY Icirc CDATA "Î" - - latin capital letter I with circumflex,
U+00CE ISOlat1 - ->
<!ENTITY Iuml CDATA "Ï" - - latin capital letter I with diaeresis,
U+00CF ISOlat1 - ->
<!ENTITY ETH CDATA "Ð" - - latin capital letter ETH, U+00D0 ISOlat1 - ->
<!ENTITY Ntilde CDATA "Ñ" - - latin capital letter N with tilde,
U+00D1 ISOlat1 - ->
<!ENTITY Ograve CDATA "Ò" - - latin capital letter O with grave,
U+00D2 ISOlat1 - ->
<!ENTITY Oacute CDATA "Ó" - - latin capital letter O with acute,
U+00D3 ISOlat1 - ->
<!ENTITY Ocirc CDATA "Ô" - - latin capital letter O with circumflex,
U+00D4 ISOlat1 - ->
Zeichen-Entity-Referenzen f#r Zeichen aus ISO 8859-1 < 311 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!ENTITY Otilde CDATA "Õ" - - latin capital letter O with tilde,
U+00D5 ISOlat1 - ->
<!ENTITY Ouml CDATA "Ö" - - latin capital letter O with diaeresis,
U+00D6 ISOlat1 - ->
<!ENTITY times CDATA "×" - - multiplication sign, U+00D7 ISOnum - ->
Die HTML 4.01- Spezifikation
<!ENTITY Oslash CDATA "Ø" - - latin capital letter O with stroke
= latin capital letter O slash,
U+00D8 ISOlat1 - ->
<!ENTITY Ugrave CDATA "Ù" - - latin capital letter U with grave,
U+00D9 ISOlat1 - ->
<!ENTITY Uacute CDATA "Ú" - - latin capital letter U with acute,
U+00DA ISOlat1 - ->
<!ENTITY Ucirc CDATA "Û" - - latin capital letter U with circumflex,
U+00DB ISOlat1 - ->
<!ENTITY Uuml CDATA "Ü" - - latin capital letter U with diaeresis,
U+00DC ISOlat1 - ->
<!ENTITY Yacute CDATA "Ý" - - latin capital letter Y with acute,
U+00DD ISOlat1 - ->
<!ENTITY THORN CDATA "Þ" - - latin capital letter THORN,
U+00DE ISOlat1 - ->
<!ENTITY szlig CDATA "ß" - - latin small letter sharp s = ess-zed,
U+00DF ISOlat1 - ->
<!ENTITY agrave CDATA "à" - - latin small letter a with grave
= latin small letter a grave,
U+00E0 ISOlat1 - ->
<!ENTITY aacute CDATA "á" - - latin small letter a with acute,
U+00E1 ISOlat1 - ->
<!ENTITY acirc CDATA "â" - - latin small letter a with circumflex,
U+00E2 ISOlat1 - ->
<!ENTITY atilde CDATA "ã" - - latin small letter a with tilde,
U+00E3 ISOlat1 - ->
<!ENTITY auml CDATA "ä" - - latin small letter a with diaeresis,
U+00E4 ISOlat1 - ->
<!ENTITY aring CDATA "å" - - latin small letter a with ring above
= latin small letter a ring,
U+00E5 ISOlat1 - ->
<!ENTITY aelig CDATA "æ" - - latin small letter ae
= latin small ligature ae, U+00E6 ISOlat1 - ->
<!ENTITY ccedil CDATA "ç" - - latin small letter c with cedilla,
U+00E7 ISOlat1 - ->
<!ENTITY egrave CDATA "è" - - latin small letter e with grave,
U+00E8 ISOlat1 - ->
<!ENTITY eacute CDATA "é" - - latin small letter e with acute,
U+00E9 ISOlat1 - ->
<!ENTITY ecirc CDATA "ê" - - latin small letter e with circumflex,
U+00EA ISOlat1 - ->
<!ENTITY euml CDATA "ë" - - latin small letter e with diaeresis,
U+00EB ISOlat1 - ->
<!ENTITY igrave CDATA "ì" - - latin small letter i with grave,
U+00EC ISOlat1 - ->
<!ENTITY iacute CDATA "í" - - latin small letter i with acute,
U+00ED ISOlat1 - ->
<!ENTITY icirc CDATA "î" - - latin small letter i with circumflex,
U+00EE ISOlat1 - ->
< 312 > Zeichen-Entity-Referenzen in HTML 4
Page size: 168,00 x 240,00 mm
<!ENTITY iuml CDATA "ï" - - latin small letter i with diaeresis,
U+00EF ISOlat1 - ->
<!ENTITY eth CDATA "ð" - - latin small letter eth, U+00F0 ISOlat1 - ->
<!ENTITY ntilde CDATA "ñ" - - latin small letter n with tilde,
U+00F1 ISOlat1 - ->
Die HTML 4.01- Spezifikation
<!ENTITY ograve CDATA "ò" - - latin small letter o with grave,
U+00F2 ISOlat1 - ->
<!ENTITY oacute CDATA "ó" - - latin small letter o with acute,
U+00F3 ISOlat1 - ->
<!ENTITY ocirc CDATA "ô" - - latin small letter o with circumflex,
U+00F4 ISOlat1 - ->
<!ENTITY otilde CDATA "õ" - - latin small letter o with tilde,
U+00F5 ISOlat1 - ->
<!ENTITY ouml CDATA "ö" - - latin small letter o with diaeresis,
U+00F6 ISOlat1 - ->
<!ENTITY divide CDATA "÷" - - division sign, U+00F7 ISOnum - ->
<!ENTITY oslash CDATA "ø" - - latin small letter o with stroke,
= latin small letter o slash,
U+00F8 ISOlat1 - ->
<!ENTITY ugrave CDATA "ù" - - latin small letter u with grave,
U+00F9 ISOlat1 - ->
<!ENTITY uacute CDATA "ú" - - latin small letter u with acute,
U+00FA ISOlat1 - ->
<!ENTITY ucirc CDATA "û" - - latin small letter u with circumflex,
U+00FB ISOlat1 - ->
<!ENTITY uuml CDATA "ü" - - latin small letter u with diaeresis,
U+00FC ISOlat1 - ->
<!ENTITY yacute CDATA "ý" - - latin small letter y with acute,
U+00FD ISOlat1 - ->
<!ENTITY thorn CDATA "þ" - - latin small letter thorn,
U+00FE ISOlat1 - ->
<!ENTITY yuml CDATA "ÿ" - - latin small letter y with diaeresis,
U+00FF ISOlat1 - ->
24.3 Zeichen-Entity-Referenzen f-r Symbole, mathe-
matische Symbole und griechische Buchstaben
Die Zeichen-Entity-Referenzen in diesem Abschnitt erzeugen Zeichen, die durch Glyphen der
weitverbreiteten Adobe-Symbolschrift dargestellt werden k=nnen. Darin enthalten sind grie-
chische Zeichen, verschiedene Klammersymbole und eine Auswahl mathematischer Operato-
ren, etwa Gradient-, Produkt- und Summensymbol.
Um diese Entities zu unterst tzen, k=nnen Benutzerprogramm [ISO10646] vollst@ndig unter-
st tzen oder auch andere Wege w@hlen. Die Darstellung von Glyphen f r diese Zeichen kann
dadurch erreicht werden, dass das Benutzerprogramm die relevanten Zeichen aus [ISO10646]
darstellen kann oder auf anderen Wegen. Dazu kann die interne Abbildung der aufgef hrten
Entities, nummerischen Zeichenreferenzen und Zeichen auf die passenden Positionen in irgend-
einer Schrift, die die ben=tigten Glyphen enth@lt, geh=ren.
Zeichen-Entity-Referenzen < 313 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Wann sollte man griechische Entities verwenden? Diese Entity-Menge enth,lt alle Buchsta-
ben, die in modernem Griechisch verwendet werden. Dennoch enth,lt sie weder die griechischen Inter-
punktionszeichen, akzentuierte Zeichen, noch die nicht-trennenden Akzente (tonos, dialytika), die
ben tigt werden, um sie zusammenzusetzen. Es gibt keine altgriechischen Buchstaben, koptischen
Die HTML 4.01- Spezifikation
Buchstaben oder zusammengesetzte Buchstaben fr polytonischen Griechisch. Die hier definierten Enti-
ties sind nicht fr die Repr,sentation moderner griechischer Texte gedacht und sie w,ren auch keine
effiziente Repr,sentation. Statt dessen sind sie fr gelegentliche griechische Buchstaben in technischen
und mathematischen Schriften bestimmt. n
24.3.1 Die Liste der Zeichen
<!- - Mathematical, Greek and Symbolic characters for HTML - ->
<!- - Character entity set. Typical invocation:
<!ENTITY % HTMLsymbol PUBLIC
"-//W3C//ENTITIES Symbols//EN//HTML">
%HTMLsymbol; - ->
<!- - Portions * International Organization for Standardization 1986:
Permission to copy in any form is granted for use with
conforming SGML systems and applications as defined in
ISO 8879, provided this notice is included in all copies.
- ->
<!- - Relevant ISO entity set is given unless names are newly introduced.
New names (i.e., not in ISO 8879 list) do not clash with any
existing ISO 8879 entity names. ISO 10646 character numbers
are given for each character, in hex. CDATA values are decimal
conversions of the ISO 10646 values and refer to the document
character set. Names are ISO 10646 names.
- ->
<!- - Latin Extended-B - ->
<!ENTITY fnof CDATA "ƒ" - - latin small f with hook = function
= florin, U+0192 ISOtech - ->
<!- - Greek - ->
<!ENTITY Alpha CDATA "Α" - - greek capital letter alpha, U+0391 - ->
<!ENTITY Beta CDATA "Β" - - greek capital letter beta, U+0392 - ->
<!ENTITY Gamma CDATA "Γ" - - greek capital letter gamma,
U+0393 ISOgrk3 - ->
<!ENTITY Delta CDATA "Δ" - - greek capital letter delta,
U+0394 ISOgrk3 - ->
<!ENTITY Epsilon CDATA "Ε" - - greek capital letter epsilon, U+0395 - ->
<!ENTITY Zeta CDATA "Ζ" - - greek capital letter zeta, U+0396 - ->
<!ENTITY Eta CDATA "Η" - - greek capital letter eta, U+0397 - ->
<!ENTITY Theta CDATA "Θ" - - greek capital letter theta,
U+0398 ISOgrk3 - ->
<!ENTITY Iota CDATA "Ι" - - greek capital letter iota, U+0399 - ->
<!ENTITY Kappa CDATA "Κ" - - greek capital letter kappa, U+039A - ->
<!ENTITY Lambda CDATA "Λ" - - greek capital letter lambda,
U+039B ISOgrk3 - ->
<!ENTITY Mu CDATA "Μ" - - greek capital letter mu, U+039C - ->
<!ENTITY Nu CDATA "Ν" - - greek capital letter nu, U+039D - ->
< 314 > Zeichen-Entity-Referenzen in HTML 4
Page size: 168,00 x 240,00 mm
<!ENTITY Xi CDATA "Ξ" - - greek capital letter xi, U+039E ISOgrk3 - ->
<!ENTITY Omicron CDATA "Ο" - - greek capital letter omicron, U+039F - ->
<!ENTITY Pi CDATA "Π" - - greek capital letter pi, U+03A0 ISOgrk3 - ->
<!ENTITY Rho CDATA "Ρ" - - greek capital letter rho, U+03A1 - ->
<!- - there is noSigmaf, and no U+03A2 character either - ->
Die HTML 4.01- Spezifikation
<!ENTITY Sigma CDATA "Σ" - - greek capital letter sigma,
U+03A3 ISOgrk3 - ->
<!ENTITY Tau CDATA "Τ" - - greek capital letter tau, U+03A4 - ->
<!ENTITY Upsilon CDATA "Υ" - - greek capital letter upsilon,
U+03A5 ISOgrk3 - ->
<!ENTITY Phi CDATA "Φ" - - greek capital letter phi,
U+03A6 ISOgrk3 - ->
<!ENTITY Chi CDATA "Χ" - - greek capital letter chi, U+03A7 - ->
<!ENTITY Psi CDATA "Ψ" - - greek capital letter psi,
U+03A8 ISOgrk3 - ->
<!ENTITY Omega CDATA "Ω" - - greek capital letter omega,
U+03A9 ISOgrk3 - ->
<!ENTITY alpha CDATA "α" - - greek small letter alpha,
U+03B1 ISOgrk3 - ->
<!ENTITY beta CDATA "β" - - greek small letter beta, U+03B2 ISOgrk3 - ->
<!ENTITY gamma CDATA "γ" - - greek small letter gamma,
U+03B3 ISOgrk3 - ->
<!ENTITY delta CDATA "δ" - - greek small letter delta,
U+03B4 ISOgrk3 - ->
<!ENTITY epsilon CDATA "ε" - - greek small letter epsilon,
U+03B5 ISOgrk3 - ->
<!ENTITY zeta CDATA "ζ" - - greek small letter zeta, U+03B6 ISOgrk3 - ->
<!ENTITY eta CDATA "η" - - greek small letter eta, U+03B7 ISOgrk3 - ->
<!ENTITY theta CDATA "θ" - - greek small letter theta,
U+03B8 ISOgrk3 - ->
<!ENTITY iota CDATA "ι" - - greek small letter iota, U+03B9 ISOgrk3 - ->
<!ENTITY kappa CDATA "κ" - - greek small letter kappa,
U+03BA ISOgrk3 - ->
<!ENTITY lambda CDATA "λ" - - greek small letter lambda,
U+03BB ISOgrk3 - ->
<!ENTITY mu CDATA "μ" - - greek small letter mu, U+03BC ISOgrk3 - ->
<!ENTITY nu CDATA "ν" - - greek small letter nu, U+03BD ISOgrk3 - ->
<!ENTITY xi CDATA "ξ" - - greek small letter xi, U+03BE ISOgrk3 - ->
<!ENTITY omicron CDATA "ο" - - greek small letter omicron, U+03BF NEW - ->
<!ENTITY pi CDATA "π" - - greek small letter pi, U+03C0 ISOgrk3 - ->
<!ENTITY rho CDATA "ρ" - - greek small letter rho, U+03C1 ISOgrk3 - ->
<!ENTITY sigmaf CDATA "ς" - - greek small letter final sigma,
U+03C2 ISOgrk3 - ->
<!ENTITY sigma CDATA "σ" - - greek small letter sigma,
U+03C3 ISOgrk3 - ->
<!ENTITY tau CDATA "τ" - - greek small letter tau, U+03C4 ISOgrk3 - ->
<!ENTITY upsilon CDATA "υ" - - greek small letter upsilon,
U+03C5 ISOgrk3 - ->
<!ENTITY phi CDATA "φ" - - greek small letter phi, U+03C6 ISOgrk3 - ->
<!ENTITY chi CDATA "χ" - - greek small letter chi, U+03C7 ISOgrk3 - ->
<!ENTITY psi CDATA "ψ" - - greek small letter psi, U+03C8 ISOgrk3 - ->
<!ENTITY omega CDATA "ω" - - greek small letter omega,
U+03C9 ISOgrk3 - ->
Zeichen-Entity-Referenzen < 315 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!ENTITY thetasym CDATA "ϑ" - - greek small letter theta symbol,
U+03D1 NEW - ->
<!ENTITY upsih CDATA "ϒ" - - greek upsilon with hook symbol,
U+03D2 NEW - ->
<!ENTITY piv CDATA "ϖ" - - greek pi symbol, U+03D6 ISOgrk3 - ->
Die HTML 4.01- Spezifikation
<!- - General Punctuation - ->
<!ENTITY bull CDATA "•" - - bullet = black small circle,
U+2022 ISOpub - ->
<!- - bullet is NOT the same as bullet operator, U+2219 - ->
<!ENTITY hellip CDATA "…" - - horizontal ellipsis = three dot leader,
U+2026 ISOpub - ->
<!ENTITY prime CDATA "′" - - prime = minutes = feet, U+2032 ISOtech - ->
<!ENTITY Prime CDATA "″" - - double prime = seconds = inches,
U+2033 ISOtech - ->
<!ENTITY oline CDATA "‾" - - overline = spacing overscore,
U+203E NEW - ->
<!ENTITY frasl CDATA "⁄" - - fraction slash, U+2044 NEW - ->
<!- - Letterlike Symbols - ->
<!ENTITY weierp CDATA "℘" - - script capital P = power set
= Weierstrass p, U+2118 ISOamso - ->
<!ENTITY image CDATA "ℑ" - - blackletter capital I = imaginary part,
U+2111 ISOamso - ->
<!ENTITY real CDATA "ℜ" - - blackletter capital R = real part symbol,
U+211C ISOamso - ->
<!ENTITY trade CDATA "™" - - trade mark sign, U+2122 ISOnum - ->
<!ENTITY alefsym CDATA "ℵ" - - alef symbol = first transfinite cardinal,
U+2135 NEW - ->
<!- - alef symbol is NOT the same as hebrew letter alef,
U+05D0 although the same glyph could be used to depict both characters - ->
<!- - Arrows - ->
<!ENTITY larr CDATA "←" --
leftwards arrow, U+2190 ISOnum - ->
<!ENTITY uarr CDATA "↑" --
upwards arrow, U+2191 ISOnum- ->
<!ENTITY rarr CDATA "→" --
rightwards arrow, U+2192 ISOnum - ->
<!ENTITY darr CDATA "↓" --
downwards arrow, U+2193 ISOnum - ->
<!ENTITY harr CDATA "↔" --
left right arrow, U+2194 ISOamsa - ->
<!ENTITY crarr CDATA "↵" --
downwards arrow with corner leftwards
= carriage return, U+21B5 NEW - ->
<!ENTITY lArr CDATA "⇐" - - leftwards double arrow, U+21D0 ISOtech - ->
<!- - ISO 10646 does not say that lArr is the same as the 'is implied by' arrow
but also does not have any other character for that function. So ? lArr can
be used for 'is implied by' as ISOtech suggests - ->
<!ENTITY uArr CDATA "⇑" - - upwards double arrow, U+21D1 ISOamsa - ->
<!ENTITY rArr CDATA "⇒" - - rightwards double arrow,
U+21D2 ISOtech - ->
<!- - ISO 10646 does not say this is the 'implies' character but does not have
another character with this function so ?
rArr can be used for 'implies' as ISOtech suggests - ->
<!ENTITY dArr CDATA "⇓" - - downwards double arrow, U+21D3 ISOamsa - ->
<!ENTITY hArr CDATA "⇔" - - left right double arrow,
U+21D4 ISOamsa - ->
< 316 > Zeichen-Entity-Referenzen in HTML 4
Page size: 168,00 x 240,00 mm
<!- - Mathematical Operators - ->
<!ENTITY forall CDATA "∀" --
for all, U+2200 ISOtech - ->
<!ENTITY part CDATA "∂" --
partial differential, U+2202 ISOtech - ->
<!ENTITY exist CDATA "∃" --
there exists, U+2203 ISOtech - ->
<!ENTITY empty CDATA "∅" --
empty set = null set = diameter,
Die HTML 4.01- Spezifikation
U+2205 ISOamso - ->
<!ENTITY nabla CDATA "∇" - - nabla = backward difference,
U+2207 ISOtech - ->
<!ENTITY isin CDATA "∈" - - element of, U+2208 ISOtech - ->
<!ENTITY notin CDATA "∉" - - not an element of, U+2209 ISOtech - ->
<!ENTITY ni CDATA "∋" - - contains as member, U+220B ISOtech - ->
<!- - should there be a more memorable name than 'ni'? - ->
<!ENTITY prod CDATA "∏" - - n-ary product = product sign,
U+220F ISOamsb - ->
<!- - prod is NOT the same character as U+03A0 'greek capital letter pi' though
the same glyph might be used for both - ->
<!ENTITY sum CDATA "∑" - - n-ary sumation, U+2211 ISOamsb - ->
<!- - sum is NOT the same character as U+03A3 'greek capital letter sigma'
though the same glyph might be used for both - ->
<!ENTITY minus CDATA "−" - - minus sign, U+2212 ISOtech - ->
<!ENTITY lowast CDATA "∗" - - asterisk operator, U+2217 ISOtech - ->
<!ENTITY radic CDATA "√" - - square root = radical sign,
U+221A ISOtech - ->
<!ENTITY prop CDATA "∝" - - proportional to, U+221D ISOtech - ->
<!ENTITY infin CDATA "∞" - - infinity, U+221E ISOtech - ->
<!ENTITY ang CDATA "∠" - - angle, U+2220 ISOamso - ->
<!ENTITY and CDATA "∧" - - logical and = wedge, U+2227 ISOtech - ->
<!ENTITY or CDATA "∨" - - logical or = vee, U+2228 ISOtech - ->
<!ENTITY cap CDATA "∩" - - intersection = cap, U+2229 ISOtech - ->
<!ENTITY cup CDATA "∪" - - union = cup, U+222A ISOtech - ->
<!ENTITY int CDATA "∫" - - integral, U+222B ISOtech - ->
<!ENTITY there4 CDATA "∴" - - therefore, U+2234 ISOtech - ->
<!ENTITY sim CDATA "∼" - - tilde operator = varies with = similar to,
U+223C ISOtech - ->
<!- - tilde operator is NOT the same character as the tilde, U+007E,
although the same glyph might be used to represent both - ->
<!ENTITY cong CDATA "≅" - - approximately equal to, U+2245 ISOtech - ->
<!ENTITY asymp CDATA "≈" - - almost equal to = asymptotic to,
U+2248 ISOamsr - ->
<!ENTITY ne CDATA "≠" - - not equal to, U+2260 ISOtech - ->
<!ENTITY equiv CDATA "≡" - - identical to, U+2261 ISOtech - ->
<!ENTITY le CDATA "≤" - - less-than or equal to, U+2264 ISOtech - ->
<!ENTITY ge CDATA "≥" - - greater-than or equal to,
U+2265 ISOtech - ->
<!ENTITY sub CDATA "⊂" - - subset of, U+2282 ISOtech - ->
<!ENTITY sup CDATA "⊃" - - superset of, U+2283 ISOtech - ->
<!- - note that nsup, 'not a superset of, U+2283' is not covered by the Symbol
font encoding and is not included. Should it be, for symmetry?
It is in ISOamsn - ->
<!ENTITY nsub CDATA "⊄" - - not a subset of, U+2284 ISOamsn - ->
<!ENTITY sube CDATA "⊆" - - subset of or equal to, U+2286 ISOtech - ->
<!ENTITY supe CDATA "⊇" - - superset of or equal to,
U+2287 ISOtech - ->
Zeichen-Entity-Referenzen < 317 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!ENTITY oplus CDATA "⊕" - - circled plus = direct sum,
U+2295 ISOamsb - ->
<!ENTITY otimes CDATA "⊗" - - circled times = vector product,
U+2297 ISOamsb - ->
<!ENTITY perp CDATA "⊥" - - up tack = orthogonal to = perpendicular,
Die HTML 4.01- Spezifikation
U+22A5 ISOtech - ->
<!ENTITY sdot CDATA "⋅" - - dot operator, U+22C5 ISOamsb - ->
<!- - dot operator is NOT the same character as U+00B7 middle dot - ->
<!- - Miscellaneous Technical - ->
<!ENTITY lceil CDATA "⌈" - - left ceiling = apl upstile,
U+2308 ISOamsc - ->
<!ENTITY rceil CDATA "⌉" - - right ceiling, U+2309 ISOamsc - ->
<!ENTITY lfloor CDATA "⌊" - - left floor = apl downstile,
U+230A ISOamsc - ->
<!ENTITY rfloor CDATA "⌋" - - right floor, U+230B ISOamsc - ->
<!ENTITY lang CDATA "〈" - - left-pointing angle bracket = bra,
U+2329 ISOtech - ->
<!- - lang is NOT the same character as U+003C 'less than'
or U+2039 'single left-pointing angle quotation mark' - ->
<!ENTITY rang CDATA "〉" - - right-pointing angle bracket = ket,
U+232A ISOtech - ->
<!- - rang is NOT the same character as U+003E 'greater than'
or U+203A 'single right-pointing angle quotation mark' - ->
<!- - Geometric Shapes - ->
<!ENTITY loz CDATA "◊" - - lozenge, U+25CA ISOpub - ->
<!- - Miscellaneous Symbols - ->
<!ENTITY spades CDATA "♠" - - black spade suit, U+2660 ISOpub - ->
<!- - black here seems to mean filled as opposed to hollow - ->
<!ENTITY clubs CDATA "♣" - - black club suit = shamrock,
U+2663 ISOpub - ->
<!ENTITY hearts CDATA "♥" - - black heart suit = valentine,
U+2665 ISOpub - ->
<!ENTITY diams CDATA "♦" - - black diamond suit, U+2666 ISOpub - ->
24.4 Zeichen-Entity-Referenzen f-r markup-relevante
und internationale Zeichen
Die Zeichen-Entity-Referenzen in diesem Abschnitt sind gesch tzte Zeichen (Escape) f r mar-
kup-relevante Zeichen (das sind die gleichen wie die in HTML 2.0 und 3.2), f r Leerzeichen und
Gedankenstriche. Andere Zeichen in diesem Abschnitt adressieren Fragen der Internationali-
sierung, wie die Eindeutigkeit von bidirektionalem Text (f r Details sei auf den Abschnitt ber
bidirektionalen Text verwiesen).
Des weiteren wurden Entities f r die in HTMLlat1 und HTMLsymbol fehlenden Zeichen in
CP-1252 erg@nzt. Sie stehen in CP-1252 alle im Bereich 128 bis 159. Diese Entities erlauben es,
die Zeichen in einer plattformunabh@ngigen Weise zu schreiben.
< 318 > Zeichen-Entity-Referenzen in HTML 4
Page size: 168,00 x 240,00 mm
Um diese Entities zu unterst tzen, k=nnen Benutzerprogramme [ISO10646] vollst@ndig unter-
st tzen oder auch andere Wege w@hlen. Die Darstellung von Glyphen f r diese Zeichen kann
dadurch erreicht werden, dass das Benutzerprogramme die relevanten Zeichen aus
[ISO10646] darstellen kann oder auf anderen Wegen. Dazu kann die interne Abbildung der auf-
Die HTML 4.01- Spezifikation
gef hrten Entities, numerischen Zeichenreferenzen und Zeichen auf die passenden Positionen
in irgendeiner Schrift, die die ben=tigten Glyphen enth@lt, geh=ren.
24.4.1 Die Liste der Zeichen
<!- - Special characters for HTML - ->
<!- - Character entity set. Typical invocation:
<!ENTITY % HTMLspecial PUBLIC
"-//W3C//ENTITIES Special//EN//HTML">
%HTMLspecial; - ->
<!- - Portions * International Organization for Standardization 1986:
Permission to copy in any form is granted for use with
conforming SGML systems and applications as defined in
ISO 8879, provided this notice is included in all copies.
- ->
<!- - Relevant ISO entity set is given unless names are newly introduced.
New names (i.e., not in ISO 8879 list) do not clash with any
existing ISO 8879 entity names. ISO 10646 character numbers
are given for each character, in hex. CDATA values are decimal
conversions of the ISO 10646 values and refer to the document
character set. Names are ISO 10646 names.
- ->
<!- - C0 Controls and Basic Latin - ->
<!ENTITY quot CDATA """ - - quotation mark = APL quote,
U+0022 ISOnum - ->
<!ENTITY amp CDATA "&" - - ampersand, U+0026 ISOnum - ->
<!ENTITY lt CDATA "<" - - less-than sign, U+003C ISOnum - ->
<!ENTITY gt CDATA ">" - - greater-than sign, U+003E ISOnum - ->
<!- - Latin Extended-A - ->
<!ENTITY OElig CDATA "Œ" - - latin capital ligature OE,
U+0152 ISOlat2 - ->
<!ENTITY oelig CDATA "œ" - - latin small ligature oe, U+0153 ISOlat2 - ->
<!- - ligature is a misnomer, this is a separate character in some languages - ->
<!ENTITY Scaron CDATA "Š" - - latin capital letter S with caron,
U+0160 ISOlat2 - ->
<!ENTITY scaron CDATA "š" - - latin small letter s with caron,
U+0161 ISOlat2 - ->
<!ENTITY Yuml CDATA "Ÿ" - - latin capital letter Y with diaeresis,
U+0178 ISOlat2 - ->
<!- - Spacing Modifier Letters - ->
<!ENTITY circ CDATA "ˆ" - - modifier letter circumflex accent,
U+02C6 ISOpub - ->
Zeichen-Entity-Referenzen < 319 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!ENTITY tilde CDATA "˜" - - small tilde, U+02DC ISOdia - ->
<!- - General Punctuation - ->
<!ENTITY ensp CDATA " " -- en space, U+2002 ISOpub - ->
<!ENTITY emsp CDATA " " -- em space, U+2003 ISOpub - ->
Die HTML 4.01- Spezifikation
<!ENTITY thinsp CDATA " " -- thin space, U+2009 ISOpub - ->
<!ENTITY zwnj CDATA "‌" -- zero width non-joiner,
U+200C NEW RFC 2070 - ->
<!ENTITY zwj CDATA "‍" -- zero width joiner, U+200D NEW RFC 2070 - ->
<!ENTITY lrm CDATA "‎" -- left-to-right mark, U+200E NEW RFC 2070 - ->
<!ENTITY rlm CDATA "‏" -- right-to-left mark, U+200F NEW RFC 2070 - ->
<!ENTITY ndash CDATA "–" -- en dash, U+2013 ISOpub - ->
<!ENTITY mdash CDATA "—" -- em dash, U+2014 ISOpub - ->
<!ENTITY lsquo CDATA "‘" -- left single quotation mark,
U+2018 ISOnum - ->
<!ENTITY rsquo CDATA "’" - - right single quotation mark,
U+2019 ISOnum - ->
<!ENTITY sbquo CDATA "‚" - - single low-9 quotation mark, U+201A NEW - ->
<!ENTITY ldquo CDATA "“" - - left double quotation mark,
U+201C ISOnum - ->
<!ENTITY rdquo CDATA "”" - - right double quotation mark,
U+201D ISOnum - ->
<!ENTITY bdquo CDATA "„" -- double low-9 quotation mark, U+201E NEW - ->
<!ENTITY dagger CDATA "†" -- dagger, U+2020 ISOpub - ->
<!ENTITY Dagger CDATA "‡" -- double dagger, U+2021 ISOpub - ->
<!ENTITY permil CDATA "‰" -- per mille sign, U+2030 ISOtech - ->
<!ENTITY lsaquo CDATA "‹" -- single left-pointing angle quotation mark,
U+2039 ISO proposed - ->
<!- - lsaquo is proposed but not yet ISO standardized - ->
<!ENTITY rsaquo CDATA "›" - - single right-pointing angle quotation mark,
U+203A ISO proposed - ->
<!- - rsaquo is proposed but not yet ISO standardized - ->
<!ENTITY euro CDATA "€" - - euro sign, U+20AC NEW - ->
< 320 > Zeichen-Entity-Referenzen in HTML 4
Page size: 168,00 x 240,00 mm
A Xnderungen
Die HTML 4.01- Spezifikation
Anmerkung der bersetzer: In diesem Anhang sind in der englischen HTML
4.01-Spezifikation die Onderungen zwischen der Version 4.01 und fr heren Versionen
von HTML zu finden. Zum Zeitpunkt der bersetzung besitzen fr here Versionen bereits
keine praktische Relevanz mehr. Aus diesem Grund ist der Anhang nicht bersetzt wor-
den. Falls Sie Interesse an der geschichtlichen Entwicklung haben, m=chten wir auf das
englische Original verweisen: [Link]
B Anmerkungen zur Performance,
Implementierung und Gestaltung
Die folgenden Anmerkungen sind informell, nicht normativ. Trotz auftauchender W=rter wie
„muss“ und „sollte“, erscheinen alle Anforderungen in diesem Abschnitt an anderer Stelle in
der Spezifikation.
B.1 Anmerkungen zu ung-ltigen Dokumenten
Diese Spezifikation definiert nicht, wie konforme Benutzerprogramme allgemeine Fehlersitua-
tionen verarbeiten, einschließlich ihres Verhaltens, wenn sie Elemente, Attribute, Attribut-
werte oder Entities vorfinden, die nicht in diesem Dokument spezifiziert sind.
Um jedoch das Experimentieren und die Interoperabilit@t zwischen den Implementationen der
verschiedenen HTML-Versionen zu vereinfachen, empfehlen wir das folgende Verhalten:
· Trifft ein Benutzerprogramm auf ein Element, das es nicht erkennt, sollte es versuchen, den
Inhalt des Elements darzustellen.
· Trifft ein Benutzerprogramm auf ein Attribut, das es nicht erkennt, sollte es die gesamte
Attributangabe ignorieren (d. h., das Attribut und dessen Wert).
· Trifft ein Benutzerprogramm auf einen Attributwert, den es nicht erkennt, sollte es den
Standardattributwert verwenden.
· Trifft es auf ein nicht deklariertes Entity, sollte das Entity wie Zeichendaten behandelt wer-
den.
Zudem empfehlen wir, dass Benutzerprogramme eine Unterst tzung daf r bieten sollten, den
Benutzer ber solche Fehler in Kenntnis zu setzen.
Anmerkung der bersetzer: Fr her haben die bekannten Browser stillschwei-
gend fast alles akzeptiert, was entfernt mit HTML zu tun hatte. Mittlerweile wird die
Ber cksichtigung von Standards langsam besser. Beim Mozilla wird das etwa dadurch
erkennbar, dass er unter „Page Info“ einen „Render Mode“ anzeigt. Bei Dokumenten,
die zum Beispiel gar keine DOCTYPE-Deklaration besitzen, steht dort: „Quirks Mode.“
Bnderungen < 321 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Bei ordentlichen Dokumenten: „Standards compliance mode.“
Die HTML 4.01- Spezifikation
Auf den ersten Blick ist das keine große Sache – wer schaut schon die „Page Info“ an?
Interessant ist, dass der Mozilla sich auch unterschiedlich verh@lt: Einer der bersetzer
hatte auf seiner Site eine HTML-Seite, die schon lange „funktionierte“. Es befand sich
jedoch ein kleiner Fehler darin, der daf r sorgte, dass die Seite nicht standardkonform
war. Die Onderung war schnell erledigt, auch gleich der „Aufstieg“ zu XHTML. Doch
nach dem Neuladen im Browser waren alle Formatierungsanweisungen ausgeschaltet!
Es dauerte eine Weile, bis der Grund klar wurde: Mozilla hat in den „Standards compli-
ance mode“ geschaltet. Doch leider wurde vom Server f r die externe CSS-Datei der
falsche MIME-Type „text/plain“ im HTTP-Kopf geschickt. Die XHTML war v=llig in
Ordnung, die CSS-Datei auch, nicht aber die Server-Konfiguration. Mit „defektem“
HTML-Code hat Mozilla diesen Fehler auch toleriert. Im „Standards compliance mode“
l@sst er sich offenkundig nicht alles bieten.
Weil Benutzerprogramme Fehlersituationen unterschiedlich behandeln k=nnen, d rfen sich
Autoren und Benutzer nicht auf ein bestimmtes Fehlerbehebungsverhalten verlassen.
Die Spezifikation HTML 2.0 ([RFC1866]) beobachtet, dass viele HTML 2.0-Benutzerpro-
gramme annehmen, dass sich ein Dokument ohne f hrende Dokumenttyp-Deklaration auf die
Spezifikation HTML 2.0 bezieht. Wie die Erfahrung zeigt, ist das eine schwache These. Die aktu-
elle Spezifikation empfiehlt dieses Verhalten nicht.
Aus Gr nden der Interoperabilit@t d rfen Autoren HTML nicht durch verf gbare SGML-Me-
chanismen „erweitern“ (z. B. die DTD erweitern, einen neuen Satz von Entity-Definitionen hin-
zuf gen und so weiter).
< 322 > Performance, Implementierung und Gestaltung
Page size: 168,00 x 240,00 mm
B.2 Besondere Zeichen in URI-Attributwerten
B.2.1 Nicht-ASCII-Zeichen in URI-Attributwerten
Die HTML 4.01- Spezifikation
Auch wenn URIs keine Nicht-ASCII-Werte enthalten (siehe [URI], Abschnitt 2.1), geben Auto-
ren sie manchmal in Attributwerten an, die URIs erwarten (d. h., in der %URI; definiert sind mit
DTD). Zum Beispiel ist der folgende href-Wert ung ltig:
<A href="[Link]
Wir empfehlen, dass Benutzerprogramme in solchen F@llen die folgenden Konventionen zur
Verarbeitung von Nicht-ASCII-Zeichen bernehmen:
1. Jedes Zeichen in UTF-8 (siehe [RFC2279]) als ein oder mehrere Bytes darstellen.
2. Diese Bytes mit dem URI-Ersatzmechanismus ersetzen (d. h., durch Konvertierung jedes
Bytes in %HH, wobei HH eine hexadizimale Schreibweise des Byte-Werts ist).
Dieser Vorgang f hrt zu einem syntaktisch g ltigen URI (wie in [RFC1738], Abschnitt 2.2 oder
[RFC2141], Abschnitt 2 definiert), der unabh@ngig von der Zeichenkodierung ist, in die das
HTML-Dokument, das diesen URI enth@lt, umkodiert worden sein kann.
Anmerkung: Einige ,ltere Benutzerprogramme verarbeiten URIs in HTML, indem sie die Bytes der
Zeichenkodierung verwenden, in der das Dokument empfangen wurde. Einige ,ltere HTML-Doku-
mente sind abh,ngig von dieser Praxis und funktionieren nicht, wenn sie umkodiert werden. Benutzer-
programme, die diese ,lteren Dokumente verarbeiten m chten, sollten, wenn sie einen URI empfan-
gen, der Zeichen außerhalb der gltigen Menge enth,lt, zuerst die Konvertierung nach UTF-8 verwen-
den. Nur wenn der resultierende URI nicht aufgel st werden kann, sollten sie versuchen, einen URI auf
Grundlage der Bytes der Zeichenkodierung zu erzeugen, in der das Dokument empfangen wurde. n
Anmerkung: Die gleiche Konvertierung auf Grundlage von UTF-8 sollte auch auf Werte des Attri-
buts name des Elements A angewandt werden. n
B.2.2 Und-Zeichen in URI-Attributwerten
Der URI, der erzeugt wird, wenn ein Formular bertragen wird, k=nnte als ein Ankerlink (z. B.
Attribut href des Elements A) verwendet werden. Leider beißt sich die Verwendung des Zei-
chens „&“ zur Trennung von Formularfeldern mit seiner Verwendung in SGML-Attributwerten
zur Begrenzung von Entity-Zeichenreferenzen. Um zum Beispiel den URI „[Link]
?x=1&y=2“ als einen Link-URI zu verwenden, muss er <A href="[Link]
oder <A href="[Link] geschrieben werden.
Wir empfehlen, dass Entwickler von HTTP-Servern, und insbesondere CGI-Entwickler die Ver-
wendung von „;“ anstatt von „&“ unterst tzen, um Autoren den Orger zu ersparen, „&“-Zei-
chen auf diese Weise zu ersetzen.
Besondere Zeichen in URI-Attributwerten < 323 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
B.3 Anmerkungen zur SGML-Implementierung
B.3.1 Zeilenumbr-che
Die HTML 4.01- Spezifikation
SGML (siehe [ISO8879], Abschnitt 7.6.1) gibt an, dass ein Zeilenumbruch, der direkt auf einen
Start-Tag folgt, ignoriert werden muss, genau wie ein Zeilenumbruch direkt vor einem End-Tag.
Dies gilt ohne Ausnahme f r alle HTML-Elemente.
Die beiden folgenden HTML-Beispiele m ssen identisch dargestellt werden:
<P>Thomas schaut TV.</P>
<P>
Thomas schaut TV.
</P>
Ebenso die beiden folgenden Beispiele:
<A>Meine Lieblings-Web-Site</A>
<A>
Meine Lieblings-Web-Site
</A>
B.3.2 Nicht-HTML-Daten angeben
Skript- und Formatierungsdaten k=nnen als Elementinhalt oder als Attributwerte erscheinen.
Die folgenden Abschnitte beschreiben die Grenzen zwischen HTML-Quelltext und Fremd-
daten.
Anmerkung: Die DTD definiert, dass Skript- und Formatierungsdaten sowohl fr Elementinhalt als
auch fr Attributwerte CDATA sein mssen. SGML-Regeln gestatten keine Zeichenreferenzen in CDA-
TA-Elementinhalt, erlauben sie jedoch in CDATA-Attributwerten. Autoren sollten besonders aufmerk-
sam sein, wenn Skript- und Formatierungsdaten zwischen Elementinhalt und Attributwerten aus-
getauscht (ausgeschnitten und eingefgt) werden.
Diese Asymetrie bedeutet auch, dass das Programm zur Umkodierung, wenn es von einer reichhaltige-
ren zu einer weniger Zeichen enthaltenden Zeichenkodierung transformiert, nicht einfach Zeichen in
Skript- oder Styledaten, die es nicht umformen kann, mit der entsprechenden numerischen Zeichenre-
ferenz ersetzen kann; es muss das HTML-Dokument parsen und jede Syntax einer Skript- und Forma-
tierungssprache kennen, um die Daten richtig zu verarbeiten. n
Elementinhalt
Wenn der Inhalt eines Elements aus Skript- oder Formatdaten (SCRIPT und STYLE) besteht,
beginnen die Daten direkt nach dem Start-Tag des Elements und enden vor dem ersten ETA-
GO-Begrenzer („</“), gefolgt von einem Namensbeginn-Zeichen ([a-zA-Z]); beachten Sie, dass
dies eventuell nicht der End-Tag des Elements ist. Autoren sollten „</“ deshalb im Inhalt erset-
zen. Ersetzungsmechanismen sind f r jede Skript- oder Stylesheet-Sprache spezifisch.
< 324 > Performance, Implementierung und Gestaltung
Page size: 168,00 x 240,00 mm
UNG LTIGES BEISPIEL:
Das folgende Skript enth@lt die ung ltige Zeichenkette "</" (als Teil von "</EM>") vor dem
End-Tag von SCRIPT:
Die HTML 4.01- Spezifikation
<SCRIPT type="text/javascript">
[Link] ("<EM>This won't work</EM>")
</SCRIPT>
In JavaScript k=nnte dieser Code durch Verstecken des ETAGO-Begrenzers vor einem SGML-
eigenen Namensbeginn-Zeichen g ltig formuliert werden:
<SCRIPT type="text/javascript">
[Link] ("<EM>Dies wird funktionieren<\/EM>")
</SCRIPT>
In Tcl k=nnte dies wie folgt erreicht werden:
<SCRIPT type="text/tcl">
document write "<EM>Dies wird funktionieren<\/EM>"
</SCRIPT>
In VBScript k=nnte das Problem mit der Funktion Chr() vermieden werden:
"<EM>Dies wird funktionieren<" & Chr(47) & "EM>"
Attributwerte
Sind Skript- oder Formatierungsdaten Wert eines Attributs (entweder style oder Attribute
eingebetteter Ereignisse), sollten Autoren das Vorkommen des zur Begrenzung des Attribut-
werts benutzten einfachen oder doppelten Anf hrungszeichens innerhalb des Wertes entspre-
chend den Konventionen der Skript- oder Stylesheet-Sprache sch tzen (escape). Autoren soll-
ten auch das „&“ sch tzen, wenn es nicht als Beginn einer Zeichenreferenz gedacht ist.
·· „"“ sollte als „"“ oder „"“ notiert werden
„&“ sollte als „&“ oder „&“ notiert werden
Deshalb kann man zum Beispiel schreiben:
<INPUT name="num" value="0"
onchange="if (compare([Link], "help")) {gethelp()}">
B.3.3 SGML-Eigenschaften mit begrenzter Unterst-tzung
Von SGML-Systemen, die konform zu [ISO8879] sind, wird erwartet, dass sie viele Eigenschaf-
ten erkennen, die von HTML-Benutzerprogrammen nur sp@rlich unterst tzt werden. Wir emp-
fehlen Autoren, die Verwendung all dieser Eigenschaften zu vermeiden.
Anmerkungen zur SGML-Implementierung < 325 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
B.3.4 Boolesche Attribute
Autoren sollten sich dessen bewusst sein, dass viele Benutzerprogramme nur die minimierte
Form der Booleschen Attribute erkennen, nicht die vollst@ndige Form.
Die HTML 4.01- Spezifikation
Autoren m=chten zum Beispiel angeben:
<OPTION selected>
An Stelle von:
<OPTION selected="selected">
B.3.5 Markierte Abschnitte (Marked Sections)
Markierte Abschnitte spielen eine @hnliche Rolle wie das #ifdef-Konstrukt, das von Pr@prozes-
soren der Programmiersprache C erkannt wird.
<![INCLUDE[
<!- - dies wird eingeschlossen - ->
]]>
<![IGNORE[
<!- - dies wird ausgeschlossen - ->
]]>
SGML definiert ebenso die Verwendung von markierten Abschnitten f r CDATA-Inhalt, inner-
halb dessen "<" nicht als Beginn eines Tags behandelt wird, z. B.:
<![CDATA[
<Ein> Beispiel mit <sgml>-Markup, in dem <ohne Bedenken>
ein < und solche Dinge geschrieben werden k^nnen.
]]>
Ein Anzeichen daf r, dass ein Benutzerprogramm einen markierten Abschnitt nicht erkennt, ist
das Auftauchen der Zeichen „]]>“, die angezeigt werden, wenn das Benutzerprogramm irrt m-
licherweise das erste „>“-Zeichen als Ende des Tags ansieht, der mit „<![“ beginnt.
B.3.6 Verarbeitungsanweisungen (PI)
Verarbeitungsanweisungen sind ein Mechanismus, um plattformspezifische Ausdr cke zu erfas-
sen. Eine Verarbeitungsanweisung beginnt mit einem <? und endet mit >
<?instruction >
Anmerkung der bersetzer: Vorsicht! In XML (und XHTML) sehen Verarbei-
tungsanweisungen wie folgt aus:
<?instruction ?>
< 326 > Performance, Implementierung und Gestaltung
Page size: 168,00 x 240,00 mm
Zum Beispiel:
<?>
<?style tt = font courier>
<?page break>
Die HTML 4.01- Spezifikation
<?experiment> ... <?/experiment>
Autoren sollte bewusst sein, dass viele Benutzerprogramme Arbeitsanweisungen als Teil des
Dokumenttextes darstellen.
B.3.7 Auszeichner abk-rzen
Einige SHORTTAG-Konstrukte von SGML sparen Tipparbeit, f gen der SGML-Anwendung aber
keine ausdrucksvolle F@higkeit hinzu. Auch wenn diese Konstrukte technisch gesehen keine
Zweideutigkeit einf hren, reduzieren sie die Robustheit eines Dokuments, besonders wenn die
Sprache erweitert wurde, um neue Elemente einzuschließen. W@hrend SHORTTAG-Konstrukte in
SGML, die sich auf Attribute beziehen, verbreitet verwendet werden und implementiert sind,
sind es jene, die sich auf Elemente beziehen, nicht. Dokumente, die sie verwenden, sind kon-
forme SGML-Dokumente, jedoch arbeiten sie wahrscheinlich nicht mit den meisten existieren-
den HTML-Werkzeugen zusammen.
Anmerkung der bersetzer: Nicht nur wegen obiger Begr ndung sollten Sie alle
SHORTTAGs vergessen: In XML gibt es sie nicht mehr.
Die fraglichen Kurzauszeichner-Konstrukte sind die folgenden:
· NET-Tags:
<name/.../
· Geschlossenes Start-Tag:
<name1<name2>
· Leeres Start-Tag:
<>
· Leeres End-Tag:
</>
B.4 Anmerkungen zum Thema: Suchmaschinen helfen,
die eigene Website zu indexieren
Dieser Abschnitt gibt einige einfache Ratschl@ge, um Ihre Dokumente zug@nglicher f r Such-
maschinen machen.
Suchmaschinen helfen, die Website zu indexieren < 327 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Definiere die Dokumentsprache
Im globalen Kontext des Webs ist es wichtig zu wissen, in welcher menschlichen Sprache
eine Seite geschrieben wurde. Dies wird in Abschnitt 8.1, Spezifizierung der Sprache des
Inhalts" besprochen.
Die HTML 4.01- Spezifikation
Sprachvarianten des Dokuments angeben
Haben Sie bersetzungen dieses Dokuments in anderen Sprachen angefertigt, sollten Sie
das Element LINK verwenden, um auf diese zu verweisen. Dies gestattet es einem indexie-
renden Programm, Benutzern ein Suchergebnis in der vom Benutzer bevorzugten Sprache
anzubieten, unabh@ngig davon, wie die Anfrage geschrieben war. Zum Beispiel bieten die
folgenden Verweise franz=siche und deutsche Alternativen f r Suchmaschinen:
<LINK rel="alternate"
type="text/html"
href="[Link]" hreflang="fr"
lang="fr" title="La vie souterraine">
<LINK rel="alternate"
type="text/html"
href="[Link]" hreflang="de"
lang="de" title="Das Leben im Untergrund">
Schl-sselworte und Beschreibungen hinzuf-gen
Einige indexierende Programme suchen nach META-Elementen, die eine durch Kommata
getrennte Liste mit Schl sselworten/Phrasen definieren oder eine kurze Beschreibung lie-
fern. Suchmaschinen k=nnen diese Schl sselworte als Ergebnis einer Suche pr@sentieren.
Der Wert des Attributs name, der von einer Suchmaschine begehrt wird, ist nicht in dieser
Spezifikation definiert. Betrachten Sie folgende Beispiele:
<META name="keywords" content="Urlaub,Griechenland,Sonnenschein">
<META name="description" content="Idyllische europ]ische Urlaubsreisen">
Zeige den Anfang einer (Dokument)sammlung an
Schriftsammlungen oder Pr@sentationen werden h@ufig in HTML-Dokumentsammlungen
bertragen. F r Suchergebnisse ist es hilfreich, den Anfang einer Sammlung zus@tzlich zur
gefundenen Seite zu referenzieren. Sie k=nnten Suchmaschinen helfen, wenn sie das Ele-
ment LINK in Verbindung mit rel="start" und dem Attribut title verwenden wie hier:
<LINK rel="start"
type="text/html"
href="[Link]"
title="Allgemeine Relativit]tstheorie">
Robots mit Indexieranweisungen f-ttern
Einge Leute m=gen manchmal berrascht sein, dass ihre Seite durch einen Robot indexiert
wurde, und dass dem Robot der Zugang zu einem sensitiven Teil der Seite nicht gestattet
h@tte sein d rfen. Viele Web-Robots bieten Administratoren von Websites und Autoren
die M=glichkeit, diese T@tigkeiten des Robots einzuschr@nken. Dies wird durch zwei Mecha-
nismen erreicht: durch eine Datei namens „[Link]“ und das META-Element im HTML-
Dokument, wie unten beschrieben.
< 328 > Performance, Implementierung und Gestaltung
Page size: 168,00 x 240,00 mm
B.4.1 Such-Robots
Die Datei [Link]
Wenn ein Robot eine Web-Seite besucht, z. B. [Link] berpr ft sucht er
Die HTML 4.01- Spezifikation
zuerst die Datei [Link] Kann er dieses Dokument finden, wird er
dessen Inhalt analysieren, um festzustellen, ob es gestattet ist, das Dokument zu empfangen. Sie
k=nnen die Datei [Link] anpassen, damit sie nur f r bestimmte Robots gilt, und um den
Zugang zu bestimmten Verzeichnissen oder Dateien zu verbieten.
Hier folgt ein Beispiel einer Datei [Link], die allen Robots untersagt, die gesamte Seite zu
besuchen:
User-agent: * # gilt fUr alle Robots
Disallow: / # verbiete Indexierung aller Seiten
Die Robots werden nur nach einem „/[Link]“-URI auf Ihrer Seite schauen, wenn der Web-
auftritt als ein HTTP-Server definiert ist, der auf einem bestimmten Host und einer bestimmten
Port-Nummer l@uft. Hier sind einige Beispielorte f r [Link]:
URI des Webauftritts URI f r [Link]
[Link] [Link]
[Link] [Link]
[Link] [Link]
[Link] [Link]
Es kann nur eine „/[Link]“ f r eine Site geben. Speziell sollten Sie „[Link]“-Dateien
nicht in Benutzerverzeichnissen ablegen, weil ein Robot niemals nach ihnen suchen wird. M=ch-
ten Sie, dass Ihre Benutzer in der Lage sind, ihre eigene „[Link]“ zu erzeugen, werden sie
all diese in einer einzigen „/[Link]“ zusammenf gen m ssen. M=chten Sie dies nicht tun,
k=nnten Ihre Benutzer stattdessen vielleicht das META-Tag f r Robots verwenden.
Einige Tipps: URIs unterscheiden zwischen Groß- und Kleinschreibung, „/[Link]“ muss voll-
kommen in Kleinbuchstaben vorliegen. Leere Zeilen sind innerhalb eines Einzeleintrags in der
Datei „[Link]“ nicht gestattet.
Es muss genau ein Feld „User-agent“ pro Eintrag geben. Die Robots sollten großz gig in der
Interpretation dieses Feldes sein. Es wird empfohlen, einen Treffer als g ltig anzusehen, wenn
eine Teilzeichenfolge des Namens unabh@ngig von Groß- und Kleinschreibung und Versio-
nsinformationen gefunden wird.
Ist der Wert „*“, beschreibt der Eintrag die Standard-Grunds@tze f r den Zugriff f r alle
Robots, die nicht einem der anderen Eintr@ge entsprechen. Mehrere Eintr@ge dieser Art sind in
der Datei „[Link]“ nicht gestattet.
Das Feld „Disallow“ gibt einen Teil-URI an, der nicht besucht werden darf. Dies kann ein voll-
st@ndiger Pfad oder ein Teilpfad sein; jeder URI, der mit diesem Wert beginnt, wird nicht abge-
rufen. Zum Beispiel,
Disallow: /help verbietet sowohl /[Link] als auch /help/[Link],
Disallow: /help/ dagegen wUrde /help/[Link] verbieten, aber /[Link] erlauben.
Suchmaschinen helfen, die Website zu indexieren < 329 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Ein leerer Wert f r „Disallow“ zeigt an, dass alle URIs abgerufen werden k=nnen. Zumindest
ein „Disallow“-Feld muss in der Datei „[Link]“ vorhanden sein.
Anmerkung der bersetzer: Hier noch einmal ein Beispiel, das die aktuelle Vor-
Die HTML 4.01- Spezifikation
gehensweise von Robots verdeutlicht. Dazu eine vollst@ndige [Link]:
User-Agent: *
Disallow: /nur_meinrobot/
Disallow:
User-Agent: meinrobot
Disallow:
Im ersten Eintrag wird allen Robots („*“) der Zugang zum Verzeichnis nur_meinrobot
verwehrt, der Zugang zu allen anderen Verzeichnisse ist durch Angabe die von
Disallow: ohne weiteren Parameter gestattet. Die folgende Leerzeile trennt den ersten
Eintrag vom zweiten. Im zweiten Eintrag wird dem Robot meinrobot der Zugang zu allen
Verzeichnissen gestattet. Die Angabe aus dem ersten Eintrag wird hiermit f r diesen
Robot außer Kraft gesetzt.
Robots und das META-Element
Das Element META gestattet es HTML-Autoren, besuchenden Robots mitzuteilen, ob das Doku-
ment indexiert oder verwendet werden soll, um mehr Links zu sammeln. Ein Eingreifen des
Server-Administrators ist nicht erforderlich.
Im folgenden Beispiel soll ein Robot dieses Dokument weder indexieren noch auf Links hin ana-
lysieren.
<META name="ROBOTS" content="NOINDEX, NOFOLLOW">
Die Liste der Begriffe „content“ ist ALL, INDEX, NOFOLLOW, NOINDEX.
Anmerkung: Anfang 1997 implementierten dies nur wenige Robots, aber es wird erwartet, dass sich
das ,ndert, da der Kontrolle von indexierenden Robots mehr ffentliche Aufmerksamkeit geschenkt
wird. n
B.5 Anmerkungen zu Tabellen
B.5.1 Begr-ndung des Tabellenentwurfs
Das HTML-Tabellenmodell hat sich aus Studien der existierenden SGML-Tabellenmodelle, der
Behandlung von Tabellen in bekannten Textverarbeitungsprogrammen und einer Vielfalt tabel-
larischer Layout-Techniken in Magazinen, B chern und anderen auf Papier basierenden Doku-
menten entwickelt. Das Modell wurde ausgesucht, um einfache Tabellen einfach ausdr cken zu
k=nnen, mit zus@tzlich verf gbarer Komplexit@t, wenn notwendig. Dies macht die Erzeugung
< 330 > Performance, Implementierung und Gestaltung
Page size: 168,00 x 240,00 mm
von Quellcode f r HTML-Tabellen mit allt@glichen Texteditoren praktikabel und reduziert die
Lernkurve, um die ersten Schritte zu vollziehen. Diese Eigenschaft ist sehr wichtig f r den
Erfolg gewesen, den HTML heute hat.
Benutzer erzeugen Tabellen zunehmend durch Konvertierung aus anderen Dokumentformaten
Die HTML 4.01- Spezifikation
oder dadurch, dass sie diese direkt in WYSIWYG-Editoren erzeugen. Es ist wichtig, dass sich
das HTML-Tabellenmodell an diese Landschaft der Autorenwerkzeuge gut anpasst. Dies betrifft
die Art der Darstellung von Zellen, die sich ber mehrere Zeilen oder Spalten erstrecken, und
die Verkn pfung von Ausrichtung und anderen Pr@sentationseigenschaften mit Zellgruppen.
Dynamisches Umformatieren
Eine weitreichende berlegung f r das HTML-Tabellenmodell ist, dass der Autor nicht kontrol-
liert, in welcher Gr=ße ein Benutzer eine Tabelle anzeigt, welche Schriftart er w@hlt und so
weiter. Dies gestaltet es riskant, sich auf Spaltenbreiten zu verlassen, die in absoluten Pixeln
angegeben sind. Stattdessen m ssen Tabellen in der Lage sein, Gr=ßen dynamisch zu ver@ndern,
um sich der aktuelle Fenster und der Schrifgr=ße anzupassen. Autoren k=nnen Beratung anbie-
ten die relative Breiten von Spalten betreffend, jedoch sollten Benutzerprogramme sicherstel-
len, dass Spalten breit genug sind, um die Breite des gr=ßten Elements im Inhalt der Zelle dar-
zustellen. Muss die Angabe des Autors berschrieben werden, sollten relative Breiten individu-
eller Spalten nicht drastisch ver@ndert werden.
Inkrementelle Darstellung
Inkrementelle Tabellendarstellung ist bei großen Tabellen oder langsamen Netzwerkverbindun-
gen wichtig f r die Benutzerzufriedenheit. Benutzerprogramme sollten in der Lage sein, eine
Tabelle darzustellen, bevor alle Daten empfangen worden sind. Die voreingestellte Fenster-
breite f r die meisten Benutzerprogramme ist ungef@hr 80 Zeichen und die Graphiken f r
HTML-Seiten werden mit diesen Werten im Hinterkopf erzeugt. Durch die Angabe der Anzahl
der Spalten und durch Einbeziehung von Festlegungen zur Kontrolle der Tabellenbreite und
der Breite verschiedener Spalten k=nnen Autoren den Benutzerprogrammen Hinweise geben,
die eine inkrementelle Darstellung des Tabelleninhalts gestatten.
Zur inkrementellen Darstellung braucht der Browser die Anzahl der Spalten und ihre Breite.
Die Standardreite ist die aktuelle Fensterbreite (width="100%"). Dies kann durch Angabe des
Attributs width des Elements TABLE ver@ndert werden. Standardm@ßig haben alle Spalten die
gleiche Breite, Sie k=nnen jedoch Spaltenbreiten ber ein oder mehrere COL-Elemente angeben,
bevor die Tabellendaten anfangen.
Die verbleibende Frage ist die nach der Anzahl der Spalten. Einige Leute haben vorgeschlagen
zu warten, bis die erste Zeile der Tabelle empfangen wird, aber das k=nnte eine lange Zeit dau-
ern, wenn die Zellen umfassenden Inhalts sind. Im Endeffekt macht es mehr Sinn, sofern inkre-
mentelle Darstellung erw nscht ist, Autoren dazu zu bewegen, die Anzahl der Spalten im Ele-
ment TABLE explizit anzugeben.
Autoren ben=tigen noch eine M=glichkeit, dem Benutzerprogramm mitzuteilen, ob inkreme-
telle Darstellung verwendet wird, oder ob die Tabelle automatisch angepasst werden soll, um
den Zellinhalt aufzunehmen. Im Modus der automatischen Gr=ßenbestimmung mit zwei Durch-
l@ufen wird die Anzahl der Spalten im ersten Durchlauf bestimmt. Im inkrementellen Modus
muss die Anzahl der Spalten zuerst festgelegt werden (mit den Elementen COL oder COLGROUP).
Anmerkungen zu Tabellen < 331 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Struktur und Darstellung
HTML unterscheidet strukturelle Auszeichnung, wie Abs@tze und Zitate, von darstellungsbezo-
genen Ausdr cken, wie Abst@nde, Schriftarten, Farben und so weiter. Wie beeinflusst diese
Unterscheidung Tabellen? Vom Standpunkt des Puristen aus gesehen, ist die Ausrichtung von
Die HTML 4.01- Spezifikation
Text innerhalb der Tabellenzellen und der Trennlinien zwischen Zellen ein Darstellungspro-
blem, kein Strukturproblem. Auf der praktischen Seite ist es aber n tzlich, diese mit den struk-
turellen Informationen zu gruppieren, weil diese Eigenschaften sehr einfach von einer Anwen-
dung zur n@chsten portiert werden k=nnen. Das HTML-Tabellenmodell berl@sst die meisten
Darstellungsinformationen verkn pften Stylesheets. Das Modell, das in dieser Spezifikation pr@-
sentiert wird, ist entworfen worden, um den Vorteil solcher Stylesheets zu nutzen, sie aber
nicht zu erfordern.
Aktuelle Desktop-Publishing-Software erlaubt eine diffizile Kontrolle ber die Darstellung von
Tabellen, und es w@re nicht m=glich, diese in HTML zu reproduzieren, ohne aus HTML ein
sperriges Rich-Text-Format zu machen wie RTF oder MIF. Diese Spezifikation bietet Autoren
jedoch die M=glichkeit, aus einer Menge verbreiteter Klassen von Rahmenformaten zu w@hlen.
Das Attribut frame kontrolliert die Darstellung von Rahmen um eine Tabelle herum, w@hrend
das Attribut rules die Wahl der Trennlinien innerhalb der Tabelle bestimmt. Eine feinere Kont-
rolle wird ber Formatierungsanweisungen unterst tzt. Das Attribut style kann zur Angabe
von Formatierungsinformationen f r individuelle Elemente verwendet werden. Weitere For-
matierungsinformationen k=nnen ber das Element STYLE im Dokumentkopf oder ber ver-
linkte Stylesheets angegeben werden.
W@hrend der Entwicklung dieser Spezifikation wurden einige Wege beschritten, die Linierungs-
muster f r Tabellen zu spezifizieren. Eine Frage betrifft die Art der Angaben, die gemacht wer-
den k=nnen. Unterst tzung f r die Entfernung und den Zusatz von Eckzellen einzuf gen, f hrt
zu relativ komplexen Algorithmen. Zum Beispiel f hrte die Arbeit, allen Tabellenelementen die
Unterst tzung der Attribute frame und rules zu gestatten, zu einem Algorithmus, der 24
Schritte einschloss, um zu bestimmen, ob eine bestimmte Ecke einer Zelle mit Linien versehen
werden sollte oder nicht. Selbst diese zus@tzliche Komplexit@t bietet nicht genug Darstellungs-
kontrolle, um den vollen Umfang der Erfordernisse von Tabellen zu befriedigen. Die aktuelle
Spezifikation bezieht sich absichtlich auf ein einfaches intuitives Modell, das f r die meisten
Zwecke ausreicht. Weitere experimentelle Arbeit wird ben=tigt, bevor ein komplexerer
Anlauf standardisiert wird.
Zeilen- und Spaltengruppen
Diese Spezifikation gibt eine Obermenge des einfacheren Modells an, das in fr heren Arbeiten
zu HTML+ pr@sentiert wurde. Es wird angenommen, dass Tabellen aus einer optionalen
Beschriftung, zusammen mit einer Sequenz aus Zeilen, welche ihrerseits aus einer Sequenz von
Tabellenzellen bestehen, gebildet werden. Das Modell differenziert weiterhin zwischen Kopf-
und Datenzellen und erlaubt Zellen, sich ber mehrere Zeilen und Spalten zu erstrecken.
Dem CALS-Tabellenmodell (siehe [CALS]) folgend, gestattet es diese Spezifikation, Tabellen-
zeilen in Kopf-, Rumpf- und Fußabschnitte zu gruppieren. Dies vereinfacht die Repr@sentation
von Darstellungsinformationen und kann dazu verwendet werden, Tabellenk=pfe und -f ße zu
wiederholen, wenn Tabellen ber Seitengrenzen umbrechen, oder um feste K=pfe ber scroll-
baren Rumpfbereichen anzugeben. Im der Auszeichnung wird der Fuß vor den Rumpfabschnit-
< 332 > Performance, Implementierung und Gestaltung
Page size: 168,00 x 240,00 mm
ten platziert. Dies ist eine Optimierung, die mit CALS geteilt wird, um mit sehr langen Tabellen
zurechtzukommen. Damit ist die Darstellung des Fußes gestattet, ohne auf die Verarbeitung
der gesamten Tabelle warten zu m ssen.
Die HTML 4.01- Spezifikation
[Link]
F r visuell Benachteiligte bietet HTML die Hoffnung, den Schaden wieder gutzumachen, den die
bernahme von Fenster-basierten graphischen Benutzerschnittstellen verursacht hat. Das
HTML-Tabellenmodell schließt Attribute zur Beschriftung jeder Zelle ein, um eine hohe Quali-
t@t bei der Sprachumwandlung zu unterst tzen. Die gleichen Attribute k=nnen auch dazu ver-
wendet werden, um automatischen Import und Export von Tabellendaten in Datenbanken
oder Arbeitsbl@tter zu unterst tzen.
B.5.2 Empfohlende Layout-Algorithmen
Wenn die Elemente COL oder COLGROUP vorhanden sind, geben sie die Anzahl der Spalten an, und
die Tabelle kann eventuell mit einem festen Layout dargestellt werden. Ansonsten sollte der
automatische Layout-Algorithmus verwendet werden, der weiter unten beschrieben ist.
Ist das Attribut width nicht angegeben, sollten visuelle Benutzerprogramme einen voreingestell-
ten Wert von 100% f r die Formatierung annehmen.
Es wird empfohlen, dass Benutzerprogramme die Tabellenbreite ber den mit width angegebe-
nen Wert hinaus erh=hen, weil der Zellinhalt sonst berlaufen w rde. Benutzerprogramme,
die die angegebene Breite berschreiben, sollten dies in einem vern nftigen Rahmen tun.
Benutzerprogramme k=nnen sich entscheiden, Worte auf mehrere Zeilen aufzuteilen, um die
Notwendigkeit berm@ßiger horizontaler Scrollbewegungen zu vermeiden, oder wenn solch
eine Scrollbewegung unm=glich oder nicht erw nscht ist.
Um des Layouts Willen sollten Benutzerprogramme bedenken, dass sich Tabellen berschriften
(angegeben durch das Element CAPTION) wie Zellen verhalten. Jede berschrift ist eine Zelle,
die sich ber alle Spalten der Tabelle erstreckt, wenn sie sich oberhalb oder unterhalb der
Tabelle befindet, und ber alle Zeilen, wenn sie links oder rechts der Tabelle ist.
Algorithmus f-r festes Layout
F r diesen Algorithmus wird angenommen, dass die Anzahl der Spalten bekannt ist. Die Spal-
tenbreite sollte per Voreinstellung gleich sein. Autoren k=nnen dies durch die Angabe relativer
oder absoluter Spaltenbreiten berschreiben, und zwar mit den Elementen COLGROUP oder COL.
Die Standardtabellenbreite ist der Raum zwischen dem aktuellen linken und rechten Rand, kann
aber durch das Attribut width des Elements TABLE berschrieben oder durch die absoluten Spal-
tenbreiten bestimmt werden. Um mit einem Mix aus absoluten und relativen Spaltenbreiten
zurechtzukommen, ist der erste Schritt zur L=sung, den Spalten mit absoluter Breite Raum von
der Tabellenbreite zuzuweisen. Danach wird den Spalten mit relativen Breiten der brig geblie-
bene Raum zugeteilt.
Die Tabellensyntax allein ist nicht ausreichend, um die Konsistenz von Attributwerten zu
garantieren. Zum Beispiel kann die Anzahl der Elemente COL und COLGROUP im Widerspruch zu
der Anzahl der Spalten stehen, die von den Tabellenzellen gefordert werden. Ein weiteres
Problem taucht auf, wenn die Spalten zu eng sind, um ein berlaufen des Zellinhalts zu vermei-
den. Die Breite der Tabelle, die durch das Element TABLE oder COL-Elemente angegeben ist,
Anmerkungen zu Tabellen < 333 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
k=nnte zum berlaufen des Zellinhalts f hren. Es wird empfohlen, dass Benutzerprogramme
versuchen, sich aus diesen Situationen elegant herauszuwinden, z. B. durch Silbentrennung und
Umverteilung in zu trennende Worte, wenn Silbentrennpunkte nicht bekannt sind.
F r den Fall, dass ein nicht teilbares Element einen Zell berlauf verursacht, sollte das Benutzer-
Die HTML 4.01- Spezifikation
programm erw@gen, die Spaltenbreite anzupassen und die Tabelle neu aufzubauen. Im
schlimmsten Fall sollte das Abschneiden des Inhalts erwogen werden, wenn eine Anpassung
der Spaltenbreite und/oder scrollbarer Zellinhalt nicht m=glich sind. In jedem Fall sollte dem
Benutzer die Trennung oder ein Abschneiden von Zellinhalt in angemessener Weise angezeigt
werden.
Algorithmus f-r automatisches Layout
Ist die Anzahl der Spalten nicht ber die Elemente COL und COLGROUP angegeben, dann sollte das
Benutzerprogramm den folgenden Algorithmus f r automatisches Layout verwenden. Er ben=-
tigt zwei Durchl@ufe durch die Tabellendaten und steigt linear mit der Gr=ße der Tabelle.
Beim ersten Durchlauf ist Zeilenumbruch deaktiviert, und das Benutzerprogramm merkt sich
die minimale und die maximale Zeilenbreite jeder Zelle. Die maximale Breite wird durch die
breiteste Zeile bestimmt. Weil Zeilenumbruch nicht aktiviert ist, werden Abs@tze als lange Zei-
len betrachtet, es sei denn, sie werden durch BR-Elemente umgebrochen. Die minimale Breite
wird durch das breiteste Textelement bestimmt (Wort, Graphik und so weiter), einschließlich
f hrender Einr ckungen, Listenzeichen und so weiter. Mit anderen Worten ist: Es notwendig,
die minimale Breite einer Zelle zu bestimmen, die eine Zelle in einem eigenen Fenster fordern
w rde, bevor sie berl@uft. Dem Benutzerprogramm zu gestatten, W=rter zu trennen, wird
die Notwendigkeit horizontalen Scrollens, oder im schlimmsten Fall, die Notwendigkeit zu
beschneiden, minimieren.
Dieser Vorgang gilt ebenso f r jede verschachtelte Tabelle im Zellinhalt. Die minimale und
maximale Breite f r Zellen in verschachtelten Tabellen werden verwendet, um die minimale
und maximale Breite f r diese Tabellen zu bestimmen und daher f r die Elterntabellenzelle
selbst. Der Algorithmus ist linear zum gesamten Zellinhalt und, allgemein gesprochen, unabh@n-
gig von der Tiefe der Verschachtelung.
Um mit der Zeichenausrichtung von Zellinhalt zurechtzukommen, beh@lt der Algorithmus drei
laufende min/max-St@nde f r jede Spalte: Links des Ausrichtungszeichens, rechts des Ausrich-
tungszeichens und nicht ausgerichtet. Die minimale Breite f r eine Spalte ist dann:
max(min_links + min_rechts, min_nicht-ausgerichtet).
Die minimalen und die maximalen Zellbreiten werden dann verwendet, um die entsprechende
minimalen und maximalen Breiten f r die Spalten zu bestimmen. Diese wiederum werden ver-
wendet, um die minimale und maximale Breite der Tabelle zu finden. Beachten Sie, dass Zellen
verschachtelte Tabellen enthalten k=nnen, jedoch kompliziert das den Code nicht signifikant.
Der n@chste Schritt ist, die Spaltenbreiten entsprechend des verf gbaren Platzes zu vergeben
(d. h., den Raum zwischen dem aktuellen linken und rechten Rand).
Ein einfacher Ansatz f r Zellen, die sich ber mehrere Spalten erstrecken, besteht darin, die
min/max-Breite gleichm@ßig jeder enthaltenden Zelle zuzuweisen. Eine etwas komplexere
Methode verwendet die min/max-Breiten der einzelnen Zellen um abzuw@gen, wie den gesam-
ten Spalten Breiten zugeteilt werden. Experimente zeigen, dass eine Mixtur dieser beiden
Methoden gute Ergebnisse f r sehr viele Tabellen liefert.
< 334 > Performance, Implementierung und Gestaltung
Page size: 168,00 x 240,00 mm
Tabellenrahmen und R@nder zwischen Zellen m ssen in die Verteilung der Spaltenbreiten mit
eingeschlossen werden. Es gibt drei F@lle:
1. Die minimale Tabellenbreite ist gleich oder grUßer als der verf-gbare Raum. In
diesem Fall weise die minimale Breite zu und gestatte dem Benutzer horizontal zu scrollen.
Die HTML 4.01- Spezifikation
F r eine Konvertierung in Braille ist es notwendig, die Zellen durch Verweise auf Anmer-
kungen zu ersetzen, die deren ganzen Inhalt enthalten. Per Konvention erfolgt dies vor der
Tabelle.
2. Die maximale Tabellenbreite passt in den verf-gbaren Raum. In diesem Fall setze
die Spalten auf ihre maximale Breite.
3. Die maximale Breite der Tabelle ist grUßer als der verf-gbare Raum, die mini-
male Tabelle ist jedoch kleiner. In diesem Fall finde den Unterschied zwischen dem
verf gbaren Raum und der minimalen Tabellenbreite, nennen wir ihn W. Ebenso lass uns
den Unterschied zwischen der maximalen und minimalen Breite der Tabelle D nennen.
F r jede Spalte lasse d die Differenz zwischen der maximalen und minimalen Breite der
Spalte sein. Nun setze die Spaltenbreite auf die minimale Breite plus d multipliziert mit W
geteilt durch D. Dies erweitert die Spalten mit großem Unterschied zwischen Minimum
und Maximum mehr als Spalten mit kleineren Unterschieden.
Dieser Zuweisungsschritt wird dann f r verschachtelte Tabellen unter Verwendung der min-
malen und maximalen Breiten, die von all diesen Tabellen im ersten Durchlauf gewonnen wur-
den, wiederholt. In diesem Fall ist die Breite der Elterntabellenzelle die aktuelle Fenstergr=ße
in der Beschreibung oben. Dieser Vorgang wird rekursiv f r alle verschachtelten Tabellen wie-
derholt. Die @ußere Tabelle wird dann mit den zugewiesenen Breiten dargestellt. Verschach-
telte Tabellen werden daraufhin als Teil des Zellinhalts der Elterntabelle dargestellt.
Ist die Tabellenbreite mit dem Attribut width angegeben, versucht das Benutzerprogramm,
Spaltenbreiten zuzuweisen, die passen. Das Attribut width ist nicht bindend, wenn daraus Spal-
ten resultieren, die enger sind als die minimale (d. h., unteilbare) Breite.
Sind relative Breiten ber das Element COL angegeben, wird der Algorithmus modifiziert, um
Spaltenbreiten ber die minimale Breite zu erweitern und die Beschr@nkungen f r relative Brei-
ten zu erf llen. Das Element COL sollte nur als Anhaltspunkt verstanden werden, so sollten Spal-
ten nicht schmaler als ihre minimale Breite gesetzt werden. Spalten sollten auf der anderen
Seite nicht so breit gemacht werden, dass die Tabelle weit ber die Grenzen des Fensters
hinausgeht. Gibt ein COL-Element eine relative Breite von Null an, sollte die Spalte immer auf
ihre minimale Breite gesetzt werden.
Wird der zweistufige Layout-Algorithmus verwendet, kann, so kein explizites oder vererbtes
charoff-Attribut vorliegt, die Standardausrichtungsposition durch Auswahl der Position
bestimmt werden, die Zeilen zentrieren w rde, deren Breiten vor und nach dem Ausrichtungs-
zeichen die Maximalwerte aller Zeilen in der Spalte mit align="char" sind. F r inkrementelles
Tabellenlayout ist die vorgeschlagene Voreinstellung charoff="50%". Wenn mehrere Zellen in
verschiedenen Zeilen derselben Spalte Zeichenausrichtung verwenden, dann sollten standard-
m@ßig alle dieser Zellen ausgerichtet werden, unabh@ngig davon, welches Ausrichtungszeichen
verwendet wird. Regeln f r die Verarbeitung von Objekten, die zu groß f r eine Spalte sind,
werden dann angewendet, wenn die explizite oder implizierte Ausrichtung zu einer Situation
f hrt, in der die Daten die zugewiesene Breite der Spalte berschreiten.
Wahl der Attributnamen: Es w,re besser gewesen, die Werte fr das Attribut frame mit dem
rules-Attribut und den Werten fr die Ausrichtung abzustimmen. Zum Beispiel: none, top, bottom,
topbot, left, right, leftright, all. Leider fordert SGML von Attributwerten des Aufz,hlungstyps in
Anmerkungen zu Tabellen < 335 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
jedem Element eindeutig zu sein, unabh,ngig vom Attributnamen. Dies verursacht unmittelbare Prob-
leme fr none, left, right und all. Die Werte fr das Attribut frame sind ausgew,hlt worden, um Kolli-
sionen mit den Attributen rules, align und valign zu verhindern. Hieran wird sich die zuknftige
Arbeit messen lassen, weil erwartet wird, dass die Attribute frame und rules zu anderen Tabellenele-
Die HTML 4.01- Spezifikation
menten in zuknftigen Revisionen dieser Spezifikation hinzugefgt werden. Eine Alternative w,re, aus
frame ein CDATA-Attribut zu machen. Der Konsens der W3C HTML Working Group war jedoch, dass
die Vorteile, SGML-Validierung fr Attribute des Aufz,hlungstyps nutzen zu k nnen, dem Nutzen der
konsistenten Namen berwiegen. n
B.6 Anmerkungen zu Formularen
B.6.1 Inkrementelle Darstellung
Die inkrementelle Darstellung ber das Netz empfangener Dokumente, verursacht bestimmte
Probleme in Bezug auf Formulare. Benutzerprogramme sollten Formulare davor bewahren,
bertragen (submitted) zu werden, bevor alle Formularelemente empfangen worden sind.
Die inkrementelle Darstellung von Dokumenten wirft einige Probleme in Bezug auf die Tabula-
tor-Navigation auf. Das Verfahren, den Fokus auf den niedrigsten tabindex-Wert im Dokument
zu lenken, scheint auf den ersten Blick vern nftig zu sein. Jedoch bedeutet dies, zu warten, bis
der gesamte Dokumenttext empfangen wurde, weil sich bis zu diesem Zeitpunkt der niedrigste
tabindex-Wert immer noch @ndern kann. Dr ckt der Benutzer die Tab-Taste vorher, ist es
angemessen, dass Benutzerprogramme den Fokus auf das aktuell niedrigste tabindex lenken.
Sind Formulare mit Client-seitigen Skripten verbunden, gibt es weiteres Potenzial f r Probleme.
Zum Beispiel kann sich ein Skript-Handler auf ein gegebenes Feld beziehen, das noch nicht exis-
tiert.
B.6.2 Zuk-nftige Projekte
Diese Spezifikation definiert bestimmte Elemente und Attribute, die leistungsstark genug sind,
um die allgemeinen Anforderungen f r die Erstellung von Formularen zu erf llen. Jedoch gibt
es noch genug Raum f r viele m=gliche Verbesserungen. Zum Beispiel k=nnten in Zukunft die
folgenden Probleme aufgegriffen werden:
· Das Spektrum der Formularfeldtypen ist im Vergleich zu modernen Benutzerschnittstellen
zu begrenzt. Zum Beispiel gibt es keine M=glichkeit f r tabellarische Dateneintr@ge, Kartei-
reiter oder mehrere Seiten-Layouts.
· Server k=nnen die Felder in einem bertragenen Formular nicht aktualisieren und m ssen
stattdessen ein komplettes HTML-Dokument schicken, das Bildschirmflackern verursacht.
· F r sprachbasierte Browser bringt dies ebenfalls Probleme mit sich. Sehbehinderte Per-
sonen haben es deshalb schwer, mit HTML-Formularen zu interagieren.
Eine weitere m=gliche Erweiterung w@re, das Attribut usemap zum Element INPUT als Client-sei-
tige Imagemap hinzuzuf gen, wenn type=\;image\( gesetzt ist. Das Element AREA, das zu dem
angeklickten Ort geh=rt, w rde den an den Server zu sendenden Wert liefern. Um zu vermei-
den, Serverskripte zu ver@ndern, ist es eventuell angemessen, AREA zu erweitern, so dass es
x- und y-Werte f r die Verwendung mit dem Element INPUT anbietet.
< 336 > Performance, Implementierung und Gestaltung
Page size: 168,00 x 240,00 mm
B.7 Anmerkungen zu Skripten
B.7.1 Reservierte Syntax f-r zuk-nftige Skriptmakros
Die HTML 4.01- Spezifikation
Diese Spezifikation reserviert eine Syntax f r zuk nftige Unterst tzung von Skriptmakros in
CDATA-Attributen. Die Absicht besteht darin, Attribute in Abh@ngigkeit von Objekteigen-
schaften zu setzen, die zuvor auf der Seiten auftreten. Die Syntax lautet:
attribute = "... &{ Makrorumpf }; ... "
Aktuelle Verwendung von Skriptmakros
Der Makrorumpf besteht aus einer oder mehreren Angaben in der voreingestellten Skriptspra-
che (wie bei eingebetteten Event-Attributen). Das der rechten geschweiften Klammer folgende
Semikolon wird immer ben=tigt, da die rechte geschweifte Klammer „}“ ansonsten als Teil des
Makrorumpfes behandelt werden w rde. Ebenfalls erw@hnenswert ist, dass f r Attribute, die
Skriptmakros enthalten, immer Anf hrungsstriche angegeben werden m ssen.
Die Verarbeitung von CDATA-Attributen geht wie folgt vonstatten:
1. Der SGML-Parser evaluiert jedes SGML-Entity (z. B. ">").
2. Dann werden die Skriptmakros vom skriptverarbeitenden Programm evaluiert.
3. Schließlich wird die resulierende Zeichenkette zur weiteren Bearbeitung an die Anwendung
weitergegeben.
Die Makroverarbeitung findet statt, wenn das Dokument geladen (oder aktualisiert), nicht
jedoch wenn das Dokument in der Gr=ße oder Farbe ver@ndert wird und so weiter.
MISSBILLIGTES BEISPIEL:
Hier sind einige Beispiele, die JavaScript verwenden. Das erste ver@ndert die Hintergrundfarbe wahllos.
<BODY bgcolor='&{randomrgb};'>
Vielleicht m=chten Sie den Hintergrund f r die abendliche Betrachtung abdunkeln:
<BODY bgcolor='&{if([Link] > 18)...};'>
Das n@chste Beispiel verwendet JavaScript, um die Koordinaten f r eine Client-seitige Image-
map anzugeben:
<MAP NAME=foo>
<AREA shape="rect" coords="&{myrect(imageuri)};" href="&{myuri};" alt="">
</MAP>
Dieses Beispiel gibt die Gr=ße einer Graphik entsprechend den Dokumenteigenschaften an:
<IMG src="[Link]" width='&{[Link]/2};' height='50%' alt="banner">
Sie k=nnen den URI f r einen Verweis oder ein Bild durch ein Skript angeben:
<SCRIPT type="text/javascript">
function manufacturer(widget) {
Anmerkungen zu Skripten < 337 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
...
}
function location(manufacturer) {
...
}
Die HTML 4.01- Spezifikation
function logo(manufacturer) {
...
}
</SCRIPT>
<A href='&{location(manufacturer("widget"))};'>widget</A>
<IMG src='&{logo(manufacturer("widget"))};' alt="logo">
Dieses letzte Beispiel zeigt, wie SGML-CDATA-Attribute mit einfachen oder doppelten Anf h-
rungszeichen eingefasst werden k=nnen. Verwenden Sie einfache Anf hrungszeichen um eine
Attributzeichenkette herum, dann k=nnen Sie doppelte Anf hrungszeichen als Teil der Attri-
butzeichenkette verwenden. Eine andere M=glichkeit ist, die Zeichenkette " f r Anf h-
rungszeichen zu benutzen:
<IMG src="&{logo(manufacturer("widget"))};" alt="logo"> n
Anmerkung der bersetzer: Im Beispiel oben wird die vielleicht etwas verwir-
rende Formulierung „Attributzeichenkette“ verwendet. An anderer Stelle wird
diese auch als Attributwert oder Wert bezeichnet.
B.8 Anmerkungen zu Frames
Es gibt keine Garantie, dass der Name eines Ziel-Frames einzigartig ist. Daher ist es angebracht,
die aktuelle Vorgehensweise zu beschreiben, wie ein Frame mit gegebenem Frame-Namen zu
finden ist:
1. Ist der Zielname ein reservierter Begriff, wie im normativen Text beschrieben, wende ihn
wie beschrieben an.
2. Ansonsten f hre eine Tiefensuche der Frame-Hierarchie in dem Fenster aus, das den Ver-
weis enth@lt. Verwende den ersten Frame, dessen Name genau passt.
3. Wurde solch ein Frame in (2) nicht gefunden, f hre Schritt 2 in jedem Fenster aus, in der
Reihenfolge von vorne nach hinten. Halte sofort an, wenn ein Frame mit genau dem glei-
chen Namen auftaucht.
4. Wurde solch ein Frame in (3) nicht gefunden, erzeuge ein neues Fenster und weise ihm den
Zielnamen zu.
B.9 Anmerkungen zur [Link]
Die W3C Web Accessibility Initiative ([WAI]) erarbeitet eine Reihe von Richtlinien, um die
Zug@nglichkeit zum Web f r Menschen mit Behinderungen zu verbessern. Es gibt drei verschie-
dene Richtlinien:
< 338 > Performance, Implementierung und Gestaltung
Page size: 168,00 x 240,00 mm
· Web Content Accessibility Guidelines ([WCGL]) f r Autoren und Verwalter von Websei-
ten. Bitte lesen Sie die Web Content Accessibility Guidelines, um Informationen ber die
Angabe von alternativem Text f r Bilder, Applets, Skripte und so weiter zu bekommen.
· User Agent Accessibility Guidelines ([UAGL]) f r Entwickler von Benutzerprogrammen
Die HTML 4.01- Spezifikation
(Browser, Multimedia-Player, mitwirkende Technologien). Bitte lesen Sie diese Richtlinien
zur Hilfe im Umgang mit alternativem Text.
· Authoring Tool Accessibility Guidelines ([ATGL]) f r Entwickler von Webseiten erstellen-
den Werkzeugen.
B.10 Anmerkungen zur Sicherheit
Anker, eingebettete Graphiken und alle anderen Elemente, die URIs als Parameter enthalten,
k=nnen veranlassen, dass ein URI als Antwort auf eine Benutzereingabe aufgel=st wird. In die-
sem Fall sollten die Sicherheitsfragen in [RFC1738], Abschnitt 6, beachtet werden. Die weit
verbreitete Methode, Formularanfragen zu bermitteln – HTTP und SMTP – bieten wenig
Sicherheit in Bezug auf eine vertrauliche Behandlung. Informationsanbieter, die sensitive Infor-
mationen ber Formulare einfordern – insbesondere mit dem Element INPUT und gesetztem
type=„password“ – sollten sich ber diesen Mangel an Vertraulichkeit im Klaren und es ihren
Benutzern bewusst machen.
Anmerkung der bersetzer: Neben der Verantwortung der Site-Betreiber, soll-
ten die Benutzer selbst darauf achten, welche Sicherheit eine Site bietet. Die Browser
bieten in der Regel vielf@ltige Konfigurationsm=glichkeiten. Dazu geh=rt zum Beispiel
die Option, beim Wechsel zwischen verschl sselter und unverschl sselter Daten ber-
tragung informiert zu werden.
Anmerkungen zur Sicherheit < 339 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
B.10.1 Sicherheitsfragen zu Formularen
Ein Benutzerprogramm sollte keine Datei absenden, die der Benutzer nicht vorher ausdr cklich
zur Absendung ausgew@hlt hat. Deshalb wird von Benutzerprogrammen erwartet, jeden vor-
Die HTML 4.01- Spezifikation
eingestellten Dateinamen zu best@tigen, der durch das Attribut value des Elements INPUT vor-
geschlagen sein k=nnte. Versteckte Kontrollelemente d rfen keine Dateien angeben.
Diese Spezifikation enth@lt keinen Mechanismus zur Verschl sselung von Daten; dies sollte von
irgendwelchen anderen Mechanismen vorgesehen werden, die gerade f r eine sichere bertra-
gung zur Verf gung stehen.
Wurde eine Datei hochgeladen, sollte das verarbeitende Programm sie verarbeiten und ent-
sprechend speichern.
Quellen
Normative Quellen
[CSS1]
„Cascading Style Sheets, level 1“, H. W. Lie and B. Bos, 17 December 1996. Revised 11
January 1999. This document is [Link]
[DATETIME]
„Date and Time Formats“, W3C Note, M. Wolf and C. Wicksteed, 15 September 1997.
Revised 27 August 1998. This document is [Link]
datetime-19980827
[HTML40]
„HTML 4.0 Specification“, D. Raggett, A. Le Hors, I. Jacobs. The 24 April 1998 version is
[Link] The 24 April version included
editorial changes from the original 18 December 1997 Revision.
[IANA]
„Assigned Numbers“, STD 2, RFC 1700, USC/ISI, J. Reynolds and J. Postel, October 1994.
[ISO639]
„Codes for the representation of names of languages“, ISO 639:1988. For more informa-
tion, consult [Link] Refer also to [Link]
cover/[Link].
[ISO3166]
„Codes for the representation of names of countries“, ISO 3166:1993.
[ISO8601]
„Data elements and interchange formats – Information interchange – Representation of
dates and times“, ISO 8601:1988.
[ISO8879]
„Information Processing – Text and Office Systems – Standard Generalized Markup
Language (SGML)“, ISO 8879:1986. Please consult [Link] for
information about the standard.
< 340 > Quellen
Page size: 168,00 x 240,00 mm
[ISO10646]
„Information Technology – Universal Multiple-Octet Coded Character Set (UCS) – Part 1:
Architecture and Basic Multilingual Plane“, ISO/IEC 10646-1:1993. This reference refers to
a set of codepoints that may evolve as new characters are assigned to them. This reference
Die HTML 4.01- Spezifikation
therefore includes future amendments as long as they do not change character assignments
up to and including the first five amendments to ISO/IEC 10646-1:1993. Also, this reference
assumes that the character sets defined by ISO 10646 and Unicode remain character-by-
character equivalent. This reference also includes future publications of other parts of
10646 (i.e., other than Part 1) that define characters in planes 1-16.
[ISO88591]
„Information Processing – 8-bit single-byte coded graphic character sets – Part 1: Latin
alphabet No. 1“, ISO 8859-1:1987.
[MIMETYPES]
List of registered content types (MIME types). Download a list of registered content types
from [Link]
[RFC1555]
„Hebrew Character Encoding for Internet Messages“, H. Nussbacher and Y. Bourvine,
December 1993.
[RFC1556]
„Handling of Bi-directional Texts in MIME“, H. Nussbacher, December 1993.
[RFC1738]
„Uniform Resource Locators“, T. Berners-Lee, L. Masinter, and M. McCahill, December
1994.
[RFC1766]
„Tags for the Identification of Languages“, H. Alvestrand, March 1995. RFC1766 is expected
to be updated by [Link]
currently a work in progress.
[RFC1808]
„Relative Uniform Resource Locators“, R. Fielding, June 1995.
[RFC2045]
„Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message
Bodies“, N. Freed and N. Borenstein, November 1996. Note that this RFC obsoletes
RFC1521, RFC1522, and RFC1590.
[RFC2046]
„Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types“, N. Freed and N.
Borenstein, November 1996. Note that this RFC obsoletes RFC1521, RFC1522, and
RFC1590.
[RFC2119]
„Key words for use in RFCs to Indicate Requirement Levels“, S. Bradner, March 1997.
[RFC2141]
„URN Syntax“, R. Moats, May 1997.
[RFC2279]
„UTF-8, a transformation format of ISO 10646“, F. Yergeau, January 1998. This RFC obso-
letes RFC 2044.
[RFC2616]
„Hypertext Transfer Protocol – HTTP/1.1“, R. Fielding, J. Gettys, J. Mogul, H. Frystyk Niel-
sen, L. Masinter, P. Leach and T. Berners-Lee, June 1999. This RFC obsoletes RFC 2068.
Normative Quellen < 341 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
[SRGB]
„A Standard Default color Space for the Internet“, version 1.10, M. Stokes, M. Anderson,
S. Chandrasekar, and R. Motta, 5 November 1996. This document is [Link]
Graphics/Color/sRGB
Die HTML 4.01- Spezifikation
[UNICODE]
The Unicode Consortium. „The Unicode Standard, Version 3.0“, Reading, MA, Addison-
Wesley Developers Press, 2000. ISBN 0-201-61633-5. Refer also to [Link]
[Link]/unicode/standard/versions/.
[URI]
„Uniform Resource Identifiers (URI): Generic Syntax“, T. Berners-Lee, R. Fielding, L. Masin-
ter, August 1998. Note that RFC 2396 updates [RFC1738] and [RFC1808].
[WEBSGML]
„Final text of revised TC2 to ISO 8879:1986“, C. F. Goldfarb, ed., 6 December 1998.
Informelle Quellen
[ATGL]
„Authoring Tool Accessibility Guidelines“, J. Treviranus, J. Richards, I. Jacobs, C. McCathie-
Nevile, eds. The latest Working Draft of these guidelines for designing accessible authoring
tools is available at [Link]
[BRYAN88]
„SGML: An Author's Guide to the Standard Generalized Markup Language“, M. Bryan,
Addison-Wesley Publishing Co., 1988.
[CALS]
Continuous Acquisition and Life-Cycle Support (CALS). CALS is a Department of Defense
strategy for achieving effective creation, exchange, and use of digital data for weapon sys-
tems and equipment. More information can be found on the CALS home page.
[CHARSETS]
Registered charset values. Download a list of registered charset values from [Link]
in-notes/iana/assignments/character-sets.
[CSS2]
„Cascading Style Sheets, level 2“, B. Bos, H. W. Lie, C. Lilley, and I. Jacobs, 12 May 1998.
This document is [Link]
[DCORE]
The Dublin Core. For more information refer to [Link]
[ETHNO]
„Ethnologue, Languages of the World“, 12th Edition, Barbara F. Grimes editor, Summer
Institute of Linguistics, October 1992.
[GOLD90]
„The SGML Handbook“, C. F. Goldfarb, Clarendon Press, 1991.
[HTML30]
„HyperText Markup Language Specification Version 3.0“, D. Raggett, September 1995. This
document is [Link]
[HTML32]
„HTML 3.2 Reference Specification“, D. Raggett, 14 January 1997. This document is
[Link]
< 342 > Quellen
Page size: 168,00 x 240,00 mm
[HTML3STYLE]
„HTML and Style Sheets“, B. Bos, D. Raggett, and H. Lie, 24 March 1997. This document is
[Link]
[LEXHTML]
Die HTML 4.01- Spezifikation
„A Lexical Analyzer for HTML and Basic SGML“, D. Connolly, 15 June 1996. This document
is [Link]
[OASISOPEN]
The Organization for the Advancement of Structured Information Standards (OASIS):
[Link]
[PICS]
Platform for Internet Content (PICS). For more information refer to [Link]
PICS/
[RDF10]
„Resource Description Framework (RDF) Model and Syntax Specification“, O. Lassila, R.
Swick, eds., 22 February 1999. This document is [Link]
tax-19990222
[RFC822]
„Standard for the Format of ARPA Internet Text Messages“, Revised by David H. Crocker,
August 1982.
[RFC850]
„Standard for Interchange of USENET Messages“, M. Horton, June 1983.
[RFC1468]
„Japanese Character Encoding for Internet Messages“, J. Murai, M. Crispin, and E. van der
Poel, June 1993.
[RFC1630]
„Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names
and Addresses of Objects on the Network as used in the World-Wide Web“, T. Berners-
Lee, June 1994.
[RFC1866]
„HyperText Markup Language 2.0“, T. Berners-Lee and D. Connolly, November 1995.
[RFC1942]
„HTML Tables“, Dave Raggett, May 1996.
[RFC2048]
„Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures“, N.
Freed, J. Klensin, and J. Postel, November 1996. Note that this RFC obsoletes RFC1521,
RFC1522, and RFC1590.
[RFC2070]
„Internationalization of the HyperText Markup Language“, F. Yergeau, G. Nicol, G. Adams,
and M. D rst, January 1997.
[RFC2388]
„Returning Values from Forms: multipart/form-data“, L. Masinter, August 1998. Refer also
to RFC 1867, „Form-based File Upload in HTML“, E. Nebel and L. Masinter, November
1995.
[SP]
SP is a public domain SGML parser. Further information is available at [Link]
com/sp/[Link].
Informelle Quellen < 343 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
[SQ91]
„The SGML Primer“, 3rd Edition, SoftQuad Inc., 1991.
[TAKADA]
„Multilingual Information Exchange through the World-Wide Web“, Toshihiro Takada,
Die HTML 4.01- Spezifikation
Computer Networks and ISDN Systems, Vol. 27, No. 2, pp. 235-241, November 1994.
[UAGL]
„User Agent Accessibility Guidelines“, J. Gunderson and I. Jacobs, eds. The latest Working
Draft of these guidelines for designing accessible user agents is available at
[Link]
[WAI]
Guidelines for designing accessible HTML documents are available at the Web Accessibility
Initiative (WAI) Web site: [Link]
[WCGL]
„Web Content Accessibility Guidelines 1.0“, W. Chisholm, G. Vanderheiden, and I. Jacobs,
eds., 5 May 1999. This document is [Link]
TENT-19990505.
[VANH90]
„Practical SGML“, E. van Herwijnen, Kluwer Academic Publishers Group, Norwell and
Dordrecht, 1990.
[XHTML]
„XHTML[tm] 1.0: The Extensible HyperText Markup Language“, S. Pemberton et al. The
latest version of this specification is available at [Link] As of the
publication of the current document, XHTML 1.0 is a W3C Proposed Recommendation.
[Link] Quellen f-r bersetzung und
Kommentierung
[HTML4ERR]
„HTML 4 Errata“ [Link]
< 344 > Quellen
Index der Elemente
Page size: 168,00 x 240,00 mm
Legende: Optional, Verboten, Leer, Missbilligt, Transitional-DTD, Frameset-DTD
Name Start-Tag End-Tag Leer Missbilligt DTD Beschreibung
A Anker eines Hyperlinks
ABBR Abk rzung (abbreviated form; z. B., WWW, HTTP, usw.)
ACRONYM Akronym
ADDRESS Information ber den Autor
APPLET M T Java-Applet
AREA V L Bereich einer Client-seitigen Imagemap
B fette Schrift (bold text style)
BASE V L Basis-URI des Dokuments
BASEFONT V L M T Grundschrifth=he
Zus,tzliche Quellen
BDO Schreibrichtung (I18N BiDi over-ride)
BIG große Schrift
BLOCK- langes Zitat
QUOTE
BODY O O Rumpf des Dokuments
BR V L erzwungener Zeilenumbruch (break)
BUTTON Schaltfl@che
CAPTION berschrift einer Tabelle
< 345 >
CENTER M T Abk rzung f r DIV align=center
CITE Zitierung
CODE Computer Code
Die HTML 4.01- Spezifikation
Die HTML 4.01- Spezifikation
< 346 >
COL V L Tabellenspalte
<edition
[Link]>
Page size: 168,00 x 240,00 mm
COLGROUP O Spaltengruppe einer Tabelle
DD O Definition in einer DL
DEL gel=schter Text
DFN Definition
Index der Elemente
DIR M T Verzeichnisliste (directory list)
DIV allgemeiner Container auf Blockebene
DL Definitionsliste
DT O Zu definierender Begriff in einer DL (definition term)
EM Betonung (emphasis)
FIELDSET Steuergruppe in einem Formular
FONT M T Schrift@nderung
FORM interaktives Formular
FRAME V L F Teilfenster
FRAMESET F Unterteilung des Fensters
H1 berschrift (heading)
H2 berschrift (heading)
H3 berschrift (heading)
H4 berschrift (heading)
H5 berschrift (heading)
H6 berschrift (heading)
HEAD O O Kopf des Dokuments
HR V L horizontale Linie (horizontal rule)
HTML O O Wurzelelement des Dokuments
Page size: 168,00 x 240,00 mm
I kursive Schrift (italic)
IFRAME T eingebettetes Teilfenster
IMG V L Bild (image)
INPUT V L Steuerelement im Formular
INS eingef gter Text (inserted text)
ISINDEX V L M T einzeiliges Eingabefeld
KBD vom Benutzer einzugebender Text (Keyboard)
LABEL Beschriftung eines Formularfelds
LEGEND Legendes eines Fieldset
LI O Listenpunkt (list item)
LINK V L Medienunabh@ngiger Link
MAP Client-seitige Imagemap
Zus,tzliche Quellen
MENU M T Men liste
META V L Metainformation
NOFRAMES F Alternativer Inhaltscontainter f r Frame-lose Darstellung
NOSCRIPT Alternativer Inhaltscontainter f r Script-freie Darstellung
OBJECT eingebettetes Objekt
OL Geordnete Liste (ordered list)
OPTGROUP Auswahlgruppe (option group)
OPTION O ausw@hlbare Option
< 347 >
P O Absatz (paragraph)
PARAM V L Wert einer benannten Eigenschaft
Die HTML 4.01- Spezifikation
Die HTML 4.01- Spezifikation
< 348 >
PRE vorformatierter Text (preformatted)
<edition
[Link]>
Page size: 168,00 x 240,00 mm
Q kurze inzeilige Zitierung
S M T durchgestrichener Text (strike-through)
SAMP Beispielausgabe eines Programm o.@. (sample)
SCRIPT Programmcode eines Scripts
Index der Attribute
SELECT Auswahl aus Optionen
SMALL kleine Schrift
SPAN allgemeiner Container auf Inline-Ebene
STRIKE M T durchgestrichener Text
STRONG starke Hervorhebung
STYLE Formatierungsanweisungen
SUB Tiefgestellter Text (subscript)
SUP Hochgestellter Text (superscript)
TABLE Tabelle
TBODY O O Tabellenrumpf
TD O Tabellendatenzelle
TEXTAREA Mehrzeiliges Textfeld
TFOOT O Tabellenfuß
TH O Tabellen berschriftzelle
THEAD O Tabellenkopf
TITLE Titel des Dokuments
TR O Tabellenzeile (table row)
TT Nicht proportionale Schrift (teletype)
U M T Unterstrichener Text
Page size: 168,00 x 240,00 mm
UL Nicht geordnete Liste
VAR Variable
Index der Attribute
Legende: Missbilligt, Transitional-DTD, Frameset-DTD
Name Verwandte Elemente Typ Vorgabe Missbilligt DTD Bemerkung
abbr TD, TH %Text; #IMPLIED Abk rzung des Tellinhalts
accept-charset FORM %Charsets; #IMPLIED Liste der unterst tzten Zeichens@tze
accept FORM, INPUT %Content- #IMPLIED Liste der MIME-Typen f r Datei-
Zus,tzliche Quellen
Types; Upload
accesskey A, AREA, BUTTON, INPUT, %Charac- #IMPLIED Zugriffstaste
LABEL, LEGEND, TEXTAREA ter;
action FORM %URI; #REQUI- Server-seitige Formularauswertung
RED
align CAPTION %CAlign; #IMPLIED M T relativ zur Tabelle
align APPLET, IFRAME, IMG, %IAlign; #IMPLIED M T vertikale oder horizontale Ausrich-
INPUT, OBJECT tung
align LEGEND %LAlign; #IMPLIED M T relativ zum Fieldset
< 349 >
align TABLE %TAlign; #IMPLIED M T Tabellenposition relativ zum Fenster
align HR (left | cen- #IMPLIED M T
ter | right)
Die HTML 4.01- Spezifikation
Die HTML 4.01- Spezifikation
< 350 >
align DIV, H1, H2, H3, H4, H5, H6, (left | cen- #IMPLIED M T Ausrichtung
<edition
[Link]>
Page size: 168,00 x 240,00 mm
P ter | right |
justify)
align COL, COLGROUP, TBODY, (left | cen- #IMPLIED
TD, TFOOT, TH, THEAD, ter | right |
TR justify |
Index der Attribute
char)
alink BODY %Color; #IMPLIED M T Farbe eines ausgew@hlten Links
alt APPLET %Text; #IMPLIED M T kurze Beschreibung
alt AREA, IMG %Text; #REQUI- kurze Beschreibung
RED
alt INPUT CDATA #IMPLIED kurze Beschreibung
archive APPLET CDATA #IMPLIED M T Komma-separierte Liste von Archi-
ven
archive OBJECT CDATA #IMPLIED Leerzeichen-separierte Liste von
URIs
axis TD, TH CDATA #IMPLIED Komma-separierte Liste verwandter
Zellen
background BODY %URI; #IMPLIED M T Hintergrundbild
bgcolor TABLE %Color; #IMPLIED M T Hintergrundfarbe
bgcolor TR %Color; #IMPLIED M T Hintergrundfarbe
bgcolor TD, TH %Color; #IMPLIED M T Hintergrundfarbe
bgcolor BODY %Color; #IMPLIED M T Hintergrundfarbe
border TABLE %Pixels; #IMPLIED Rahmen
border IMG, OBJECT %Pixels; #IMPLIED M T Rahmenbreite
cellpadding TABLE %Length; #IMPLIED Leerraum in Zellen
Page size: 168,00 x 240,00 mm
cellspacing TABLE %Length; #IMPLIED Leerraum zwischen Zellen
char COL, COLGROUP, TBODY, %Charac- #IMPLIED Ausrichtungzeichen, z. B. char=':'
TD, TFOOT, TH, THEAD, ter;
TR
charoff COL, COLGROUP, TBODY, %Length; #IMPLIED Abstand f r Ausrichtungszeichen
TD, TFOOT, TH, THEAD,
TR
charset A, LINK, SCRIPT %Charset; #IMPLIED Zeichenkodierung der verlinkten Res-
source
checked INPUT (checked) #IMPLIED f r Radio-Buttons und Checkboxen
cite BLOCKQUOTE, Q %URI; #IMPLIED Quell-URI des Zitats
cite DEL, INS %URI; #IMPLIED Onderungsgrund
class Alle Elemente außer BASE, CDATA #IMPLIED Leerzeichen-separierte Liste der
Zus,tzliche Quellen
BASEFONT, HEAD, HTML, Klassen
META, PARAM, SCRIPT, STY-
LE, TITLE
classid OBJECT %URI; #IMPLIED Implementierung
clear BR (left | all | none M T Textflusssteuerung
right |
none)
code APPLET CDATA #IMPLIED M T Class-Datei des Applets
codebase OBJECT %URI; #IMPLIED base URI for classid, data, archive
< 351 >
codebase APPLET %URI; #IMPLIED M T optionaler Basis-URI des Applets
codetype OBJECT %Content- #IMPLIED Inhaltstyp des Codes
Type;
Die HTML 4.01- Spezifikation
Die HTML 4.01- Spezifikation
< 352 >
color BASEFONT, FONT %Color; #IMPLIED M T Textfarbe
<edition
[Link]>
Page size: 168,00 x 240,00 mm
cols FRAMESET %Multi- #IMPLIED F Liste von Maßen, Vorgabe: 100% (1
Lengths; Spalte)
cols TEXTAREA NUMBER #REQUI-
RED
Index der Attribute
colspan TD, TH NUMBER 1 Anzahl der berdeckten Spalten
compact DIR, DL, MENU, OL, UL (compact) #IMPLIED M T Verringerter Raum zwischen LIs
content META CDATA #REQUI-
RED
coords AREA %Coords; #IMPLIED Komma-separierte Liste von Maßen
coords A %Coords; #IMPLIED f r client-seitige Image Maps
data OBJECT %URI; #IMPLIED Verweis auf Objektdaten
datetime DEL, INS %Datetime; #IMPLIED Datum/Zeit der Onderung
declare OBJECT (declare) #IMPLIED Deklarieren, aber nicht instanziieren
defer SCRIPT (defer) #IMPLIED Benutzerprogramm darf Skriptausf h-
rung verschieben
dir Alle Elemente außer APPLET, (ltr | rtl) #IMPLIED Richtung
BASE, BASEFONT, BDO, BR,
FRAME, FRAMESET, IFRAME,
PARAM, SCRIPT
dir BDO (ltr | rtl) #REQUI- Richtung
RED
disabled BUTTON, INPUT, (disabled) #IMPLIED nicht verf gbar
OPTGROUP, OPTION,
SELECT, TEXTAREA
enctype FORM %Content- "applicati-
Page size: 168,00 x 240,00 mm
Type; on/x-www-
form-urlen-
coded"
face BASEFONT, FONT CDATA #IMPLIED M T Komma-separierte Liste von Schrift-
namen
for LABEL IDREF #IMPLIED passender ID-Wert
frame TABLE %TFrame; #IMPLIED welche Tabellenrahmen darzustellen
sind
frameborder FRAME, IFRAME (1 | 0) 1 F Frame-Rahmen
headers TD, TH IDREFS #IMPLIED Liste von IDs f r Kopfzellen
height IFRAME %Length; #IMPLIED T H=he
height TD, TH %Length; #IMPLIED M T H=he
height IMG, OBJECT %Length; #IMPLIED H=he
Zus,tzliche Quellen
height APPLET %Length; #REQUI- M T H=he
RED
href A, AREA, LINK %URI; #IMPLIED URI der verlinkten Ressource
href BASE %URI; #IMPLIED Basis-URI
hreflang A, LINK %Language- #IMPLIED Sprachcode
Code;
hspace APPLET, IMG, OBJECT %Pixels; #IMPLIED M T horizontaler Leerraum
http-equiv META NAME #IMPLIED HTTP-Header-Name
id Alle Elemente außer BASE, ID #IMPLIED dokumentweit eindeutige ID
< 353 >
HEAD, HTML, META,
SCRIPT, STYLE, TITLE
Die HTML 4.01- Spezifikation
Die HTML 4.01- Spezifikation
< 354 >
ismap IMG, INPUT (ismap) #IMPLIED server-seitige Image Map
<edition
[Link]>
Page size: 168,00 x 240,00 mm
label OPTION %Text; #IMPLIED
label OPTGROUP %Text; #REQUI-
RED
lang Alle Elemente außer APPLET, %Language- #IMPLIED Sprachcode
Index der Attribute
BASE, BASEFONT, BR, Code;
FRAME, FRAMESET, IFRAME,
PARAM, SCRIPT
language SCRIPT CDATA #IMPLIED M T Skriptsprache
link BODY %Color; #IMPLIED M T Linkfarbe
longdesc IMG %URI; #IMPLIED Link zur langen Beschreibung (erg@nzt
alt)
longdesc FRAME, IFRAME %URI; #IMPLIED F Link zur langen Beschreibung (erg@nzt
title)
marginheight FRAME, IFRAME %Pixels; #IMPLIED F H=he in Pixeln
marginwidth FRAME, IFRAME %Pixels; #IMPLIED F Breite in Pixeln
maxlength INPUT NUMBER #IMPLIED maximale Anzahl Zeichen f r Textfel-
der
media STYLE %Media- #IMPLIED Angabe eines Mediums
Desc;
media LINK %Media- #IMPLIED Darstellung auf diesem Medium
Desc;
method FORM (GET | GET HTTP-Methode der Formular ber-
POST) mittlung
multiple SELECT (multiple) #IMPLIED Mehrfachauswahl
name BUTTON, TEXTAREA CDATA #IMPLIED
name APPLET CDATA #IMPLIED M T Name des Elements oder Objekts
Page size: 168,00 x 240,00 mm
name SELECT CDATA #IMPLIED Name des Elements oder Objekts
name FORM CDATA #IMPLIED Name des Elements oder Objekts
name FRAME, IFRAME CDATA #IMPLIED F Name des Elements oder Objekts
name IMG CDATA #IMPLIED Name des Elements oder Objekts
name A CDATA #IMPLIED Name des Elements oder Objekts
name INPUT, OBJECT CDATA #IMPLIED Name des Elements oder Objekts
name MAP CDATA #REQUI- Name des Elements oder Objekts
RED
name PARAM CDATA #REQUI- Name des Elements oder Objekts
RED
name META NAME #IMPLIED Metainformationsname
nohref AREA (nohref) #IMPLIED nicht verlinkt
Zus,tzliche Quellen
noresize FRAME (noresize) #IMPLIED F Gr=ßenver@nderung verbieten
noshade HR (noshade) #IMPLIED M T
nowrap TD, TH (nowrap) #IMPLIED M T Wortumbruch unterdr cken
object APPLET CDATA #IMPLIED M T serialisiertes Applet
onblur A, AREA, BUTTON, INPUT, %Script; #IMPLIED bei Verlieren des Fokus
LABEL, SELECT, TEXTAREA
onchange INPUT, SELECT, TEXTAREA %Script; #IMPLIED bei Wert@nderung
< 355 >
Die HTML 4.01- Spezifikation
Die HTML 4.01- Spezifikation
< 356 >
onclick Alle Elemente außer APPLET, %Script; #IMPLIED bei Klick
<edition
[Link]>
Page size: 168,00 x 240,00 mm
BASE, BASEFONT, BDO, BR,
FONT, FRAME, FRAMESET,
HEAD, HTML, IFRAME,
ISINDEX, META, PARAM,
SCRIPT, STYLE, TITLE
Index der Attribute
ondblclick Alle Elemente außer APPLET, %Script; #IMPLIED bei Doppelklick
BASE, BASEFONT, BDO, BR,
FONT, FRAME, FRAMESET,
HEAD, HTML, IFRAME,
ISINDEX, META, PARAM,
SCRIPT, STYLE, TITLE
onfocus A, AREA, BUTTON, INPUT, %Script; #IMPLIED bei Erlangen des Fokus
LABEL, SELECT, TEXTAREA
onkeydown Alle Elemente außer APPLET, %Script; #IMPLIED bei andauerndem Tastendruck
BASE, BASEFONT, BDO, BR,
FONT, FRAME, FRAMESET,
HEAD, HTML, IFRAME,
ISINDEX, META, PARAM,
SCRIPT, STYLE, TITLE
onkeypress Alle Elemente außer APPLET, %Script; #IMPLIED bei Tastendruck (und Loslassen)
BASE, BASEFONT, BDO, BR,
FONT, FRAME, FRAMESET,
HEAD, HTML, IFRAME,
ISINDEX, META, PARAM,
SCRIPT, STYLE, TITLE
onkeyup Alle Elemente außer APPLET, %Script; #IMPLIED beim Loslassen der Taste
Page size: 168,00 x 240,00 mm
BASE, BASEFONT, BDO, BR,
FONT, FRAME, FRAMESET,
HEAD, HTML, IFRAME,
ISINDEX, META, PARAM,
SCRIPT, STYLE, TITLE
onload FRAMESET %Script; #IMPLIED F bei Beendigung des Ladevorgangs
aller Frames
onload BODY %Script; #IMPLIED bei Beendigung des Ladevorgangs
onmouse- Alle Elemente außer APPLET, %Script; #IMPLIED bei Maustastendruck
down BASE, BASEFONT, BDO, BR,
FONT, FRAME, FRAMESET,
HEAD, HTML, IFRAME,
ISINDEX, META, PARAM,
SCRIPT, STYLE, TITLE
onmousemove Alle Elemente außer APPLET, %Script; #IMPLIED bei Mausbewegung
Zus,tzliche Quellen
BASE, BASEFONT, BDO, BR,
FONT, FRAME, FRAMESET,
HEAD, HTML, IFRAME,
ISINDEX, META, PARAM,
SCRIPT, STYLE, TITLE
onmouseout Alle Elemente außer APPLET, %Script; #IMPLIED bei Wegbewegen der Maus
BASE, BASEFONT, BDO, BR,
FONT, FRAME, FRAMESET,
HEAD, HTML, IFRAME,
ISINDEX, META, PARAM,
< 357 >
SCRIPT, STYLE, TITLE
Die HTML 4.01- Spezifikation
Die HTML 4.01- Spezifikation
< 358 >
onmouseover Alle Elemente außer APPLET, %Script; #IMPLIED bei Dar berbewegen der Maus
<edition
[Link]>
Page size: 168,00 x 240,00 mm
BASE, BASEFONT, BDO, BR,
FONT, FRAME, FRAMESET,
HEAD, HTML, IFRAME,
ISINDEX, META, PARAM,
SCRIPT, STYLE, TITLE
Index der Attribute
onmouseup Alle Elemente außer APPLET, %Script; #IMPLIED bei Loslassen der Maustaste
BASE, BASEFONT, BDO, BR,
FONT, FRAME, FRAMESET,
HEAD, HTML, IFRAME,
ISINDEX, META, PARAM,
SCRIPT, STYLE, TITLE
onreset FORM %Script; #IMPLIED bei Zur cksetzen des Formulars
onselect INPUT, TEXTAREA %Script; #IMPLIED bei Textauswahl
onsubmit FORM %Script; #IMPLIED bei Abschicken des Formulars
onunload FRAMESET %Script; #IMPLIED F bei Verlassen des Framesets
onunload BODY %Script; #IMPLIED bei Verlassen des Dokuments
profile HEAD %URI; #IMPLIED Metadatenprofil
prompt ISINDEX %Text; #IMPLIED M T
readonly TEXTAREA (readonly) #IMPLIED
readonly INPUT (readonly) #IMPLIED f r text und password
rel A, LINK %LinkTy- #IMPLIED Vorw@rtslinktyp
pes;
rev A, LINK %LinkTy- #IMPLIED R ckw@rtslinktyp
pes;
rows FRAMESET %Multi- #IMPLIED F Liste von Maßen, Vorgabe: 100%
Lengths; (1 Zeile)
rows TEXTAREA NUMBER #REQUI-
Page size: 168,00 x 240,00 mm
RED
rowspan TD, TH NUMBER 1 Anzahl berdeckter Zeilen
rules TABLE %TRules; #IMPLIED Linien zwischen Spalten und Zeilen
scheme META CDATA #IMPLIED
scope TD, TH %Scope; #IMPLIED
scrolling FRAME, IFRAME (yes | no | auto F Scrollbar oder nicht
auto)
selected OPTION (selected) #IMPLIED
shape AREA %Shape; rect Form
shape A %Shape; rect f r client-seitige Image Maps
size HR %Pixels; #IMPLIED M T
size FONT CDATA #IMPLIED M T Schriftgr=ße
Zus,tzliche Quellen
size INPUT CDATA #IMPLIED Gr=ße
size BASEFONT CDATA #REQUI- M T Basisschrift
RED
size SELECT NUMBER #IMPLIED Anzahl sichtbarer Zeilen
span COL NUMBER 1 COL betrifft n Spalten
span COLGROUP NUMBER 1 Vorgabanzahl Spalten in COLGROUP
src SCRIPT %URI; #IMPLIED URI f r externes Skript
src INPUT %URI; #IMPLIED f r Felder mit Bildern
src FRAME, IFRAME %URI; #IMPLIED F Frame-Inhalt
< 359 >
src IMG %URI; #REQUI- Bild-URI
RED
Die HTML 4.01- Spezifikation
Die HTML 4.01- Spezifikation
< 360 >
standby OBJECT %Text; #IMPLIED Nachricht w@hrend des Ladens
<edition
[Link]>
Page size: 168,00 x 240,00 mm
start OL NUMBER #IMPLIED M T Startnummer
style Alle Elemente außer BASE, %StyleS- #IMPLIED Formatierung
BASEFONT, HEAD, HTML, heet;
META, PARAM, SCRIPT, STY-
LE, TITLE
Index der Attribute
summary TABLE %Text; #IMPLIED Zusammenfassung f r Sprachausgabe
tabindex A, AREA, BUTTON, INPUT, NUMBER #IMPLIED Position
OBJECT, SELECT,
TEXTAREA
target A, AREA, BASE, FORM, LINK %Frame- #IMPLIED T Ziel-Frame
Target;
text BODY %Color; #IMPLIED M T Textfarbe
title Alle Elemente außer BASE, %Text; #IMPLIED advisory title
BASEFONT, HEAD, HTML,
META, PARAM, SCRIPT,
TITLE
type A, LINK %Content- #IMPLIED Inhaltstyp (MIME)
Type;
type OBJECT %Content- #IMPLIED Inhaltstyp (MIME)
Type;
type PARAM %Content- #IMPLIED Inhaltstyp (MIME) falls valuetype=ref
Type;
type SCRIPT %Content- #REQUI- Inhaltstyp (MIME)
Type; RED
type STYLE %Content- #REQUI- Inhaltstyp (MIME)
Type; RED
type INPUT %InputTy- TEXT Art des Steuerelements
Page size: 168,00 x 240,00 mm
pe;
type LI %LIStyle; #IMPLIED M T Stil der Liste
type OL %OLStyle; #IMPLIED M T Nummerierungsstil
type UL %ULStyle; #IMPLIED M T Stil der Liste
type BUTTON (button | submit Button-Art
submit |
reset)
usemap IMG, INPUT, OBJECT %URI; #IMPLIED client-seitige Image Map
valign COL, COLGROUP, TBODY, (top | #IMPLIED vertikale Ausrichtung
TD, TFOOT, TH, THEAD, middle |
TR bottom |
baseline)
value INPUT CDATA #IMPLIED Wert
Zus,tzliche Quellen
value OPTION CDATA #IMPLIED Wert
value PARAM CDATA #IMPLIED Wert
value BUTTON CDATA #IMPLIED Wert
value LI NUMBER #IMPLIED M T Nummerierung
valuetype PARAM (DATA | DATA Wertetyp
REF |
OBJECT)
version HTML CDATA %HTML.V- M T konstant
ersion;
< 361 >
vlink BODY %Color; #IMPLIED M T Farbe besuchter Links
vspace APPLET, IMG, OBJECT %Pixels; #IMPLIED M T vertikaler Leerraum
Die HTML 4.01- Spezifikation
Die HTML 4.01- Spezifikation
< 362 >
width HR %Length; #IMPLIED M T Breite
<edition
[Link]>
Page size: 168,00 x 240,00 mm
width IFRAME %Length; #IMPLIED T Breite
width IMG, OBJECT %Length; #IMPLIED Breite
width TABLE %Length; #IMPLIED Breite
width TD, TH %Length; #IMPLIED M T Breite
Index der Attribute
width APPLET %Length; #REQUI- M T Breite
RED
width COL %Multi- #IMPLIED Breite
Length;
width COLGROUP %Multi- #IMPLIED Breite
Length;
width PRE NUMBER #IMPLIED M T Breite
Page size: 168,00 x 240,00 mm
<edition
[Link]>
B
< XHTML 1.0:
Die Extensible
HyperText
Markup
Language >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
XHTML 1.0: Die Extensible HyperText Markup Language
(Zweite Auflage)
Deutsche bersetzung
Diese Version:
[Link]
Aktuelle Version:
XHTML 1.0: Die Extensible Hyper-
[Link]
bersetzer:
Text Markup Language
Judith Muhr ( bersetzung)
Stefan Mintert (Fachlektorat und Kommentierung), [Link]
<stefan@[Link]>
Bei diesem Dokument handelt es sich um eine bersetzung eines W3C-Textes. Dieser
Text ist urheberrechtlich gesch tzt; bitte beachten Sie die nachfolgenden Hinweise des
Originaldokuments. Die Rechte an der bersetzung liegen bei den bersetzern und
dem Verlag Addison-Wesley. Die bersetzung hat keine durch das W3C legitimierte,
normative Wirkung. Das einzige maßgebliche Dokument ist das englische Original.
Bitte senden Sie Fehler und Korrekturen zur deutschen Fassung an die bersetzer.
Kommentare der bersetzer, die als solche gekennzeichnet sind, unterliegen dem
Urheberrecht der bersetzer. Sie sind nicht Bestandteil des Ursprungsdokuments.
XHTML 1.0: Die Extensible HyperText Markup Language
(Zweite Auflage)
Eine Neuformulierung von HTML in XML 1.0
W3C-Empfehlung, 26. Januar 2000, -berarbeitet am 1. August 2002
Diese Version:
[Link]
Neueste Version:
[Link]
Vorhergehende Version:
[Link]
Version mit hervorgehobenen Xnderungen:
[Link]
Autoren:
Siehe Danksagungen.
Bitte beachten Sie die Errata f r dieses Dokument, die normative Korrekturen enthalten k=n-
nen. Siehe auch bersetzungen.
Dieses Dokument ist auch in folgenden nicht normativen Formaten erh@ltlich: Mehrteilige
XHTML-Dateien, PostScript, PDF, ZIP-Archiv und Gzip/TAR-Archiv.
< 364 > XHTML 1.0: Extensible HyperText Markup Language
Page size: 168,00 x 240,00 mm
Copyright L 2002 W3C M (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark,
document use and software licensing rules apply.
Kurzbeschreibung
Diese Spezifikation definiert die zweite Auflage von XHTML 1.0, eine Neufassung von HTML 4
als XML 1.0-Anwendung sowie drei DTDs, die den von HTML 4 definierten DTDs entspre-
chen. Die Semantik der Elemente und ihre Attribute sind in der W3C-Empfehlung f r HTML 4
definiert. Diese Semantiken stellen die Grundlage f r die zuk nftige Erweiterbarkeit von
XHTML 1.0: Die Extensible Hyper-
XHTML dar. Kompatibilit@t mit existierenden HTML-Benutzerprogrammen ist m=glich, wenn
einige wenige Richtlinien befolgt werden.
Text Markup Language
Anmerkung der bersetzer: Die Kurzbeschreibung sagt bereits zwei wichtige
Dinge: Erstens entspricht XHTML 1.0 inhaltlich HTML 4. Es gibt also keine neuen Ele-
menttypen. Zweitens ist die Bedeutung der Elementtypen in der HTML 4-Spezifikation
beschrieben. Aus diesem Grund ist die HTML 4-Spezifikation nicht berfl ssig und sollte
bekannt sein, wenn Sie mit HTML oder XHTML arbeiten m=chten. Die deutsche ber-
setzung von HTML 4 ist unter der Adresse [Link]
html401-19991224 zu finden.
Status dieses Dokuments
Dieser Abschnitt beschreibt den Status dieses Dokuments zum Zeitpunkt seiner Ver=ffent-
lichung. Neue Dokumente k=nnen dieses Dokument ersetzen. Der neueste Status dieser
Dokumentreihe wird vom W3C verwaltet.
Dieses Dokument ist die zweite Auflage der XHTML 1.0-Empfehlung, die die Korrektur@nde-
rungen bis zum 1. August 2002 enth@lt. Onderungen zwischen dieser Version und der vorher-
gehenden Empfehlung sind in einer Version mit hervorgehobenen Onderungen dargestellt.
Diese zweite Auflage ist keine neue Version von XHTML 1.0 (zum ersten mal am 26. Januar
2000 ver=ffentlicht). Die Onderungen in diesem Dokument spiegeln Korrekturen wider, die als
Ergebnis von Kommentaren, die von der Sffentlichkeit gemacht wurden, und als Ergebnis der
fortschreitenden Arbeit der HTML-Arbeitsgruppe entstanden sind. Es gibt keine substantiellen
Onderungen in diesem Dokument – ausschließlich die Integration der verschiedenen Errata.
Die Liste der bekannten Fehler in dieser Spezifikation ist unter [Link]
2002/08/REC-xhtml1-20020801-errata verf gbar.
Bitte melden Sie Fehler in diesem Dokument an www-html-editor@[Link] (Archiv). Die
=ffentliche Diskussion von HTML-Eigenschaften findet auf der Mailingliste www-html@[Link]
(Archiv) statt.
Dieses Dokument wurde als Teil der W3C HTML Activity hergestellt. Die Ziele der HTML
Working Group (nur Mitglieder) werden in der HTML Working Group Charta diskutiert.
Zur Zeit der Ver=ffentlichung war die Arbeitsgruppe davon berzeugt, dass es keine Patent-
bekanntmachungen gibt, die f r diese Spezifikation relevant sind. Eine aktuelle Liste von Patent-
bekanntmachungen, die f r diese Spezifikation relevant sind, ist auf der Seite f r Patentbekannt-
machungen der Arbeitsgruppe zu finden.
Eine Liste der aktuellen W3C-Empfehlungen sowie anderer technischer Dokumente finden Sie
unter [Link]
XHTML 1.0: Extensible HyperText Markup Language < 365 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Anmerkung der bersetzer: Eine Liste von deutschen bersetzungen von
W3C-Dokumenten finden Sie unter [Link]
XHTML 1.0: Die Extensible Hyper-
1 Was ist XHTML?
Text Markup Language
Dieser Abschnitt ist informell.
XHTML ist eine Familie aktueller und zuk nftiger Dokumenttypen und Module, die HTML 4
nachbilden, eine Untermenge davon bilden bzw. es erweitern [HTML4]. Dokumenttypen aus
der XHTML-Familie basieren auf XML und sind letztlich darauf ausgelegt, in Kombination mit
auf XML basierenden Benutzerprogrammen eingesetzt zu werden. Detaillierte Informationen
zu dieser Familie und ihrer Entwicklung finden Sie in [XHTMLMOD].
XHTML 1.0 (diese Spezifikation) ist der erste Dokumenttyp in der XHTML-Familie. Es handelt
sich dabei um eine Neuformulierung der drei HTML 4-Dokumenttypen als Anwendungen von
XML 1.0 [XML]. Es ist f r die Verwendung als Sprache f r Inhalte vorgesehen, die sowohl zu
XML konform sind, und die auch, falls sie einigen einfachen Richtlinien folgen, in zu HTML 4
konformen Benutzerprogrammen eingesetzt werden k=nnen. Entwickler, die ihre Inhalte auf
XHTML 1.0 umstellen, werden die folgenden Vorteile erkennen:
· XHTML-Dokumente sind konform zu XML. Als solche k=nnen sie ohne weiteres mit Stan-
dard-XML-Werkzeugen angezeigt, bearbeitet und validiert werden.
· XML-Dokumente k=nnen so formuliert werden, dass sie in bereits existierenden, zu HTML
4 konformen Benutzerprogrammen ebenso gut oder besser funktionieren als zuvor, ebenso
wie in neuen, zu XHMTL 1.0 konformen Benutzerprogrammen.
· XHTML-Dokumente k=nnen Applikationen (z. B. Skripte und Applets) einsetzen, die auf
dem HTML Document Object Model oder dem XML Document Object Model basieren
[DOM].
· Falls sich die XHTML-Familie weiterentwickelt, ist es wahrscheinlicher, dass Dokumente,
die konform zu XHTML 1.0 sind, innerhalb und zwischen unterschiedlichen XHTML-Umge-
bungen kombiniert werden k=nnen.
Die XHTML-Familie ist der n@chste Schritt in der Evolution des Internet. Wenn die Entwickler
von Inhalten heute auf XHTML umsteigen, k=nnen sie in die XML-Welt mit allen dort gebote-
nen Vorteilen vordringen und dennoch darauf vertrauen, dass ihr Inhalt vorw@rts- und r ck-
w@rtskompatibel ist.
1.1 Was ist HTML 4?
HTML 4 [HTML4] ist eine SGML-Anwendung (Standard Generalized Markup Language), die
konform zur internationalen Norm ISO 8879 ist und in weiten Kreisen als Standardpublika-
tionssprache des World Wide Web betrachtet wird.
SGML ist eine Sprache f r beschreibende Markup-Sprachen, insbesondere solche, die f r den
elektronischen Austausch von Dokumenten, die Dokumentverwaltung und die Dokumentver-
=ffentlichung verwendet werden. HTML ist ein Beispiel f r eine in SGML definierte Sprache.
< 366 > Was ist XHTML?
Page size: 168,00 x 240,00 mm
SGML gibt es schon seit Mitte der Achtzigerjahre, und sie ist relativ stabil geblieben. Ein Groß-
teil dieser Stabilit@t resultiert aus der Tatsache, dass die Sprache zum einen zahlreiche Funk-
tionsmerkmale aufweist, gleichzeitig aber auch flexibel ist. Diese Flexibilit@t hat jedoch ihren
Preis, n@mlich die Komplexit@t, die verhindert hat, dass es sich in unterschiedlichsten Umge-
bungen durchgesetzt hat, unter anderem auch im World Wide Web.
HTML war, wie urspr nglich vorgesehen, eine Sprache f r den Austausch wissenschaftlicher
und anderer technischer Dokumente, die auch von Benutzern eingesetzt werden konnte, die
keine Dokumentspezialisten waren. HTML l=st die Probleme, die sich aus der Komplexit@t von
XHTML 1.0: Die Extensible Hyper-
SGML ergeben, indem es eine kleine Menge strukturbildender und semantischer Tags bereit-
stellt, die f r die Auslegung relativ einfacher Dokumente geeignet sind. Um die Dokument-
Text Markup Language
struktur zu vereinfachen, unterst tzt HTML außerdem Hypertext. Multimedia-F@higkeiten wur-
den sp@ter hinzugef gt.
Innerhalb bemerkenswert kurzer Zeit wurde HTML allgemein beliebt und wuchs schnell ber
seinen urspr nglichen Zweck hinaus. Seit der Einf hrung von HTML wurden sehr schnell
immer wieder neue Elemente entwickelt, die in HTML (als Standard) eingesetzt werden und
die Anpassung von HTML an vertikale, hoch spezialisierte M@rkte unterst tzten. Diese Vielfalt
an neuen Elementen hat zu Problemen bez glich der Zusammenarbeit von Dokumenten
gef hrt, die ber verschiedene Plattformen hinweg verwendet wurden.
Weil sowohl Software als auch Plattformen immer schneller heterogen wurden, ist deutlich,
dass das „klassische“ HTML 4 f r die Verwendung auf diesen Plattformen gewissen Einschr@n-
kungen unterliegt.
1.2 Was ist XML?
XMLj ist die Abk rzung f r Extensible Markup Language [XML].
XML war darauf ausgelegt, die Leistungsf@higkeit und Flexibilit@t von SGML wiederzugewinnen,
ohne jedoch deren hohe Komplexit@t mit sich zu bringen. Obwohl XML eine eingeschr@nkte
Form von SGML ist, weist es trotzdem einen Großteil der Leistungsf@higkeit und Reichhaltig-
keit von SGML auf, ebenso wie die gebr@uchlichsten Funktionsmerkmale von SGML.
W@hrend XML diese vorteilhaften Leistungsmerkmale beibeh@lt, verzichtet es auf viele der
komplexeren Funktionsmerkmale von SGML, die das Schreiben und den Entwurf geeigneter
Software schwierig und teuer machen.
1.3 Wozu braucht man XHTML?
Die Vorteile, die ein Umstieg auf XHTML 1.0 mit sich bringt, sind oben beschrieben. Einige der
Vorteile beim Wechsel zu XHTML k=nnen ganz allgemein wie folgt beschrieben werden:
· Dokumententwickler und Designer von Benutzerprogrammen entdecken st@ndig neue
M=glichkeiten, ihre Ideen durch neues Markup auszudr cken. In XML ist es relativ einfach,
neue Elemente oder zus@tzliche Elementattribute einzuf hren. Die XHTML-Familie ist
darauf ausgelegt, diesen Erweiterungen durch XHTML-Module und Techniken f r die Ent-
wicklung neuer, XHTML-konformer Module (die in der bevorstehenden Spezifikation zur
XHTML-Modularisierung beschrieben ist) zu gen gen. Diese Module werden die Kombina-
tion existierender und neuer Funktionsmerkmale bei der Entwicklung von Inhalt und dem
Entwurf neuer Benutzerprogramme erlauben.
Was ist XML? < 367 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
· Es werden st@ndig neue M=glichkeiten f r den Zugriff auf das Internet eingef hrt. Einige
Sch@tzungen weisen darauf hin, dass im Jahr 2002 75% der Dokumentanzeigen im Internet
auf diesen alternativen Plattformen stattfindet. Die XHTML-Familie wurde mit Blick auf die
Interoperabilit@t von Benutzerprogrammen entworfen. Durch einen neuen Benutzerpro-
gramm- und Dokument-Profiling-Mechanismus sind Server, Proxies und Benutzerpro-
gramme in der Lage, die bestm=gliche Umwandlung des Inhalts zu erzielen. Letztlich wird
es irgendwann m=glich sein, XHTML-konformen Inhalt zu entwickeln, der von jedem zu
XHTML konformen Benutzerprogramm verwendet werden kann.
XHTML 1.0: Die Extensible Hyper-
Text Markup Language
2 Definitionen
Dieser Abschnitt ist normativ.
2.1 Terminologie
In dieser Spezifikation werden die nachfolgenden Begriffe verwendet. Diese Begriffe erweitern
die Definitionen aus [RFC2119], und basieren auf @hnlichen Definitionen wie in ISO/IEC
9945-1:1990 [POSIX.1]:
Kann, Darf (May)
In Hinblick auf Implementierungen sollte das Wort „kann“ als optionales Funktionsmerkmal
betrachtet werden, das in dieser Spezifikation nicht gefordert wird, das jedoch unterst tzt
werden kann. Was die Konformit@t des Dokuments betrifft, bedeutet das Wort „kann“,
dass das optionale Funktionsmerkmal nicht verwendet werden darf. Der Begriff „optional“
hat dieselbe Definition wie „kann“.
Muss (Must)
In dieser Spezifikation sollte das Wort „muss“ als zwingende Anforderung f r die Imple-
mentierung betrachtet werden oder f r streng konforme XHTML-Dokumente, abh@ngig
vom Kontext. Der Begriff „soll“ hat dieselbe Definition wie „muss“.
Nicht spezifiziert (Unspecified)
Ist ein Wert oder ein Verhalten nicht spezifiziert, definiert die Spezifikation keine Portabili-
t@tsanforderungen f r ein Funktionsmerkmal f r eine Implementierung, selbst wenn ein
Dokument vorliegt, das dieses Funktionsmerkmal nutzt. Ein Dokument, das f r einen sol-
chen Fall ein spezielles Verhalten bedingt, statt ein beliebiges Verhalten zu tolerieren,
obwohl es dieses Funktionsmerkmal aufweist, ist kein streng konformes XHTML-Doku-
ment.
Optional (Optional)
Siehe „Kann“.
Reserviert (Reserved)
Ein Wert oder Verhalten ist nicht spezifiziert, aber es darf von konformen Dokumenten
nicht verwendet und von einem konformen Benutzerprogramm nicht unterst tzt werden.
Soll (Shall)
Siehe „Muss“.
< 368 > Definitionen
Page size: 168,00 x 240,00 mm
Sollte (Should)
Im Hinblick auf Implementierungen sollte das Wort „sollte“ als Empfehlung f r die Imple-
mentierung, nicht aber als Forderung interpretiert werden. Im Hinblick auf Dokumente
sollte das Wort „sollte“ als empfohlene Vorgehensweise bei der Programmierung f r
Dokumente verstanden werden und als Forderung f r streng konforme XHTML-Doku-
mente.
Unterst-tzt (Supported)
Bestimmte Funktionsmerkmale in dieser Spezifikation sind optional. Wird ein Funk-
XHTML 1.0: Die Extensible Hyper-
tionsmerkmal unterst tzt, verh@lt es sich, wie in dieser Spezifikation beschrieben.
Text Markup Language
2.2 Allgemeine Begriffe
Attribut
Ein Attribut ist ein Parameter f r ein Element, der in der DTD deklariert ist. Der Typ und
der Wertebereich eines Attributs ebenso wie ein m=glicher Standardwert, sind in der
DTD definiert.
Anmerkung der bersetzer: Beispielsweise lautet bei <a href="[Link]">...</a>
der Attributname „href“. In der XHTML-DTD ist deklariert, dass Elemente vom Typ a
Attribute namens „href“ haben k=nnen. Der Wert ist in diesem Beispiel der Text
„[Link]“.
Benutzerprogramm
Ein Benutzerprogramm ist ein System, das XHTML-Dokumente in bereinstimmung mit
dieser Spezifikation verarbeitet. Weitere Informationen finden Sie in Abschnitt 3.2 ber
konforme Benutzerprogramme.
Anmerkung der bersetzer: Aus dem englischen „User Agent“ ist in unserer
bersetzung das „Benutzerprogramm“ geworden. Eine Begr ndung und Erl@uterung ist
in der kommentierten Fassung der CSS2-Spezifikation zu finden.
DTD
Eine DTD (Dokumenttypdefinition) setzt sich aus mehreren XML-Markup-Deklarationen
zusammen, die in ihrer Gesamtheit die erlaubte Struktur, Elemente und Attribute definiert,
die f r die Verwendung in einem Dokument zur Verf gung stehen, das konform zu der
DTD ist.
Anmerkung der bersetzer: Die DTD legt fest, welche Elemente (und ihre Attri-
bute) in einem Dokument verwendet werden k=nnen. Damit stellt die DTD die Gram-
matik der Sprache (in diesem Fall: XHTML) dar, die definiert wird.
Allgemeine Begriffe < 369 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Dokument
Ein Dokument ist ein Datenstrom, der nach der Kombination mit anderen Str=men, auf die
er verweist, so strukturiert ist, dass er Informationen enth@lt, die in Elementen enthalten
sind, die wie in der zugeh=rigen DTD definiert angeordnet sind. Weitere Informationen fin-
den Sie in Abschnitt 3.1 ber konforme Dokumente.
Element
Ein Element ist eine Einheit f r die Strukturierung eines Dokuments, die in der DTD dekla-
riert ist. Das Inhaltsmodell des Elements ist in der DTD definiert; zus@tzliche Semantiken
XHTML 1.0: Die Extensible Hyper-
k=nnen in der Textbeschreibung des Elements definiert sein.
Funktionsmerkmale
Text Markup Language
Funktionsmerkmale sind Elemente, Attribute und die diesen Elementen und Attributen
zugeordnete Semantik. Wenn eine Implementierung diese Funktionalit@t unterst tzt, sagt
man, sie stellt die erforderlichen Funktionsmerkmale bereit.
Implementierung
Siehe Benutzerprogramm.
Parsing
Parsing ist der Vorgang, w@hrenddessen ein Dokument berpr ft („gescannt„) und die in
dem Dokument enthaltene Information in den Kontext der Elemente gefiltert wird, in dem
die Information strukturiert ist.
Rendering
Rendering (Darstellen) ist der Vorgang, bei dem die Information aus einem Dokument dar-
gestellt wird. Diese Darstellung erfolgt in der f r die Umgebung am besten geeigneten Form
(z. B. akustisch, visuell, gedruckt).
Validierung
Bei der Validierung werden Dokumente im Hinblick auf die zugeordnete DTD berpr ft,
wobei sichergestellt wird, dass die Verwendung der Elemente sowie der Attribute konsis-
tent mit den Definitionen in der DTD erfolgt.
Wohlgeformtheit
Ein Dokument ist wohlgeformt, wenn es gem@ß den in Abschnitt 2.1 definierten Regeln der
XML 1.0-Empfehlung [XML] strukturiert ist. Grunds@tzlich sagt diese Definition aus, dass
Elemente, die durch ihre Start- und Ende-Tags begrenzt sind, korrekt ineinander verschach-
telt sein m ssen.
3 Normative Definition von
XHTML 1.0
Dieser Abschnitt ist normativ.
3.1 Konforme Dokumente
Diese Version von XHTML stellt eine Definition streng konformer XHTML 1.0-Dokumente
bereit, die auf die Elemente und Attribute aus dem XML- und XHTML 1.0-Namensraum
beschr@nkt sind. Weitere Informationen ber die Verwendung von XHTML in Kombination
< 370 > Normative Definition von XHTML 1.0
Page size: 168,00 x 240,00 mm
mit anderen Namensr@umen, wie beispielsweise f r das Einbinden von Metadaten, die in RDF
ausgedr ckt sind, in XHTML-Dokumente, finden Sie in Abschnitt 3.1.2.
Anmerkung der bersetzer: Im Gegensatz zur ersten Auflage wird hier zus@tz-
lich vom XML-Namensraum gesprochen. Diese Erweiterung der Aussage hinsichtlich
des XML-Namensraums ist schon deshalb notwendig, weil in dieser XHTML-Spezifika-
tion auch das Attribut xml:lang vorkommt.
XHTML 1.0: Die Extensible Hyper-
Text Markup Language
3.1.1 Streng konforme Dokumente
Ein streng konformes XHTML-Dokument ist ein XML-Dokument, das nur die Funk-
tionsmerkmale ben=tigt, die in dieser Spezifikation als zwingend erforderlich beschrieben sind.
Ein solches Dokument muss alle folgenden Kriterien erf llen:
1. Es muss konform zu den Beschr@nkungen sein, die in einer der drei in Anhang A beschrie-
benen DTDs und in Anhang B ausgedr ckt sind.
2. Das Wurzelelement des Dokuments muss html sein.
3. Das Wurzelelement des Dokuments muss eine xmlns-Deklaration f r den XHTML-Na-
mensraum enthalten [XMLNAMES]. Der Namensraum f r XTHML ist definiert als
[Link] Ein Wurzelelement kann z. B. so aussehen:
<html xmlns="[Link] xml:lang="en" lang="en">
4. Im Dokument muss es vor dem Wurzelelement eine DOCTYPE-Deklaration geben. Der in
der DOCTYPE-Deklaration enthaltene =ffentliche Bezeichner muss auf eine der drei in
Anhang A beschriebenen DTDs verweisen, und zwar unter Verwendung des betreffenden
Formal Public Identifier. Der Systembezeichner kann ge@ndert werden, um lokale System-
konventionen zu ber cksichtigen.
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"[Link]
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"[Link]
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"[Link] Die [interne]
DTD-Teilmenge darf nicht verwendet werden, um irgendwelche Parameter-Entities
der DTD zu Uberschreiben.
Eine XML-Deklaration ist nicht in allen XML-Dokumenten erforderlich. Den Autoren von
XHTML-Dokumenten wird jedoch sehr empfohlen, in all ihren Dokumenten XML-Deklarationen
zu verwenden. Eine solche Deklaration ist erforderlich, wenn die Zeichenkodierung des Doku-
ments nicht die Standardkodierung UTF-8 oder UTF-16 ist und keine Kodierung durch ein Hig-
her-Level-Protokoll bestimmt wurde. Im folgenden Beispiel ist die XML-Deklaration enthalten:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"[Link]
Konforme Dokumente < 371 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<html xmlns="[Link] xml:lang="en" lang="en">
<head>
<title>Virtual Library</title>
</head>
<body>
<p>Moved to <a href="[Link]
</body>
</html>
XHTML 1.0: Die Extensible Hyper-
Anmerkung der bersetzer: Die Namensraumbezeichner (hier [Link]
Text Markup Language
1999/xhtml) sehen aus wie URLs. Es handelt sich dabei jedoch ausschließlich um Zeichenket-
ten. Unter der gleichnamigen Adresse muss nicht einmal eine Webseite zu finden sein. Man
nutzt hier aus, dass durch den Aufbau eines Namensraumbezeichners in dieser Form welt-
weite Eindeutigkeit gew@hrleistet wird.
Der Bezeichner legt die Vermutung nahe, dass bei Zugriff per http auf den Rechner mit
dem Namen [Link] und Anforderung der Datei namens /1999/xhtml ein Doku-
ment geliefert wird, das den entsprechenden Namensraum in irgendeiner Syntax formal
definiert. Dies ist jedoch nicht so, was dazu beitr@gt, dass viele Stimmen f r eine andere
Syntax der Namensraumbezeichner pl@dieren.
3.1.2 XHTML mit anderen [Link] verwenden
Der XHTML-Namensraum kann in Kombination mit anderen XML-Namensr@umen verwendet
werden, gem@ß [XMLNAMES], obwohl solche Dokumente keine streng konformen XHTML
1.0-Dokumente sind, wie oben definiert. Fortlaufende Arbeiten des W3C suchen nach M=glich-
keiten, um Konformit@t f r Dokumente mit mehreren Namensr@umen zu definieren. Als Bei-
spiel siehe [XHTML+MathML].
Anmerkung der bersetzer: Die Kombination von Elementen aus zwei verschie-
denen Namensr@umen, wie auch im nachfolgenden Beispiel zu sehen, verhindert, dass
das Ergebnisdokument g ltig bez glich der einen (etwa XHTML) oder der anderen
DTD (etwa MathML) ist.
Das folgende Beispiel zeigt, wie XHTML 1.0 in Kombination mit der MathML-Empfehlung ver-
wendet werden kann:
<html xmlns="[Link] xml:lang="en" lang="en">
<head>
<title>Ein Beispiel aus der Mathematik</title>
</head>
<body>
<p>Das folgende ist MathML-Markup:</p>
<math xmlns="[Link]
<apply> <log/>
<logbase>
< 372 > Normative Definition von XHTML 1.0
Page size: 168,00 x 240,00 mm
<cn> 3 </cn>
</logbase>
<ci> x </ci>
</apply>
</math>
</body>
</html>
Das folgende Beispiel zeigt, wie XHTML 1.0-Markup in einen anderen XML-Namensraum auf-
XHTML 1.0: Die Extensible Hyper-
genommen werden k=nnte:
<?xml version="1.0" encoding="UTF-8"?>
Text Markup Language
<!- -anf]nglich ist der Standard-Namensraum "books" - ->
<book xmlns='urn:[Link]:books'
xmlns:isbn='urn:ISBN:0-395-36341-6' xml:lang="en" lang="en">
<title>Im Dutzend billiger</title>
<isbn:number>1568491379</isbn:number>
<notes>
<!- - HTML zum Standard-Namensraum fUr einen Hypertext-Kommentar machen - ->
<p xmlns='[Link]
Dies steht auch online <a href="[Link] VerfUgung</a>.
</p>
</notes>
</book>
3.2 Konforme Benutzerprogramme
Ein konformes Benutzerprogramm muss alle folgenden Kriterien erf llen:
1. Um zu der XML 1.0-Empfehlung [XML] konform zu sein, muss das Benutzerprogramm ein
XHTML-Dokument auf seinen korrekten Aufbau hin berpr fen. Gibt das Benutzerpro-
gramm an, dass es ein validierendes Benutzerprogramm ist, muss es Dokumente auch
gem@ß der DTDs berpr fen, auf die darin verwiesen wird, gem@ß [XML].
2. Gibt das Benutzerprogramm an, Funktionsmerkmale zu unterst tzen, die innerhalb dieser
Spezifikation definiert sind oder die von dieser Spezifikation durch einen normativen Verweis
gefordert werden, muss es das konsistent zu der Definition dieser Funktionsmerkmale tun.
3. Wenn ein Benutzerprogramm ein XHTML-Dokument als generisches XML verarbeitet, soll
es nur Attribute des Typs ID (z. B. f r die meisten XHTML-Elemente das id-Attribut) als
Fragmentbezeichner erkennen.
4. Wenn ein Benutzerprogramm auf ein Element trifft, das es nicht erkennt, muss es den Inhalt
des Elements verarbeiten.
5. Wenn ein Benutzerprogramm auf ein Attribut trifft, das es nicht erkennt, muss es die
gesamte Attributspezifikation ignorieren (d. h. das Attribut und seinen Wert).
6. Wenn ein Benutzerprogramm auf einen Attributwert trifft, den es nicht erkennt, muss es
den Standardattributwert verwenden.
7. Wenn es auf einen Entity-Verweis trifft (außer eines der in dieser Empfehlung oder in der
XML- Empfehlung vordefinierten Entities), f r den das Benutzerprogramm keine Deklara-
tion verarbeitet hat (was passieren k=nnte, wenn sich die Deklaration in der externen
Untermenge befindet, die das Benutzerprogramm noch nicht gelesen hat), sollte der Entity-
Verweis durch die Zeichen verarbeitet werden (beginnend mit dem Ampersand und
endend mit dem Semikolon), aus denen sich der eigentliche Verweis zusammensetzt.
Konforme Benutzerprogramme < 373 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
8. Treffen Benutzerprogramme bei der Verarbeitung von Inhalt auf Zeichen oder Zeichen-Enti-
ty-Verweise, die sie erkennen, aber nicht darstellen k=nnen, k=nnen sie eine andere Darstel-
lung w@hlen, die die gleiche Bedeutung hat, oder sie m ssen das Dokument so darstellen, dass
es f r den Benutzer offensichtlich ist, dass keine normale Darstellung stattfinden konnte.
9. Leerraum wird gem@ß den folgenden Regeln behandelt. Die folgenden Zeichen sind in
[XML] als Leerraumzeichen definiert:
·· Leerzeichen (Space,  )
Horizontaler Tabulator (Horizontal Tabulation, 	)
··
XHTML 1.0: Die Extensible Hyper-
Wagenr cklauf (Carriage-return, 
)
Zeilenvorschub (Line-feed, 
)
Text Markup Language
Der XML-Prozessor normalisiert die Zeilenende-Codes unterschiedlicher Systeme zu einem
einzigen Zeilenvorschubzeichen, das an die Applikation weitergegeben wird.
Das Benutzerprogramm muss die Definition f r die Verarbeitung von Leerraumzeichen aus
von CSS verwenden [CSS]. Beachten Sie, dass die CSS2-Empfehlung die Behandlung von Leer-
raum in Nicht-Latin-Zeichens@tzen nicht explizit anspricht. Dies wird in einer zuk nftigen Ver-
sion von CSS geschehen, woraufhin diese Spezifikation aktualisiert wird.
Beachten Sie, dass zur Erzeugung eines kanonischen XHTML-Dokuments die obigen Regeln,
genauso wie die Regeln in [XMLC14N] auf das Dokument angewendet werden m ssen.
4 Unterschiede zu HTML 4
Dieser Abschnitt ist informell
Aufgrund der Tatsache, dass es sich bei XHTML um eine XML-Anwendung handelt, m ssen
einige Vorgehensweisen, die im auf SGML basierenden HTML 4 [HTML4] v=llig korrekt waren,
ge@ndert werden.
4.1 Dokumente m-ssen korrekt aufgebaut sein
Der korrekte Aufbau („Wohlgeformtheit“) ist ein neues Konzept, das von [XML] eingef hrt wur-
de. Im Wesentlichen bedeutet es, dass alle Elemente entweder schließende Tags haben m ssen
oder dass sie in einer speziellen Form geschrieben sein m ssen (wie nachfolgend beschrieben),
und dass alle Elemente korrekt verschachtelt sein m ssen.
Obwohl in SGML keine berlappungen erlaubt sind, werden sie in existierenden Browsern
allgemein toleriert.
RICHTIG: verschachtelte Elemente.
<p>Hier sehen Sie einen betonten <em>Absatz</em>.</p>
FALSCH: berlappende Elemente
<p>Hier sehen Sie einen betonten <em>Absatz.</p></em>
< 374 > Unterschiede zu HTML 4
Page size: 168,00 x 240,00 mm
4.2 Element- und Attributnamen m-ssen in
Kleinbuchstaben dargestellt werden
XHTML-Dokumente m ssen f r alle HTML-Element- und Attributnamen Kleinbuchstaben ver-
wenden. Diese Unterscheidung ist erforderlich, weil XML die Groß-/Kleinschreibung ber ck-
sichtigt; <li> und <LI> sind demnach unterschiedliche Tags.
4.3 F-r nicht leere Elemente m-ssen End-Tags angegeben
XHTML 1.0: Die Extensible Hyper-
werden
Text Markup Language
In auf SGML basierendem HTML 4 konnten bestimmte Elemente das End-Tag einfach weglas-
sen; in diesem Fall stellten nachfolgende Elemente einen impliziten Abschluss dar. XML erlaubt
das Weglassen von End-Tags nicht. Alle Elemente, die in der DTD nicht als EMPTY deklariert
sind, m ssen ein End-Tag haben. Elemente, die in der DTD als EMPTY deklariert sind, k=nnen
ein End-Tag haben oder die Kurzschreibweise verwenden (siehe Leere Elemente).
RICHTIG: abgeschlossene Elemente
<p>Hier sehen Sie einen Absatz.</p><p>Und hier noch einen.</p>
FALSCH: nicht abgeschlossene Elemente
<p>Hier sehen Sie einen Absatz.<p>Und hier noch einen.
4.4 Attributwerte m-ssen immer in Anf-hrungszeichen
stehen
Alle Attributwerte m ssen in Anf hrungszeichen stehen, selbst solche, die scheinbar numerisch sind.
RICHTIG: Attributwerte in Anf hrungszeichen
<td rowspan="3">
FALSCH: Nicht in Anf hrungszeichen eingeschlossene Attributwerte
<td rowspan=3>
4.5 Attributminimierung
XML unterst tzt keine Attributminimierung. Attribut/Wert-Paare m ssen vollst@ndig aus-
geschrieben werden. Attributnamen wie beispielsweise compact und checked d rfen in Elemen-
ten nicht auftreten, ohne dass ihr Wert zuvor spezifiziert wurde.
RICHTIG: Nicht minimierte Attribute
<dl compact="compact">
Elemente, Attribute in Kleinbuchstaben darstellen < 375 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
FALSCH: Minimierte Attribute
<dl compact>
4.6 Leere Elemente
Leere Elemente m ssen ein End-Tag haben, oder das Start-Tag muss mit /> enden, beispiels-
weise <br/> oder <hr></hr>. Weitere Informationen dar ber, wie Sie diese Abw@rtskompatibili-
XHTML 1.0: Die Extensible Hyper-
t@t zu HTML 4-Benutzerprogrammen sicher stellen, finden Sie in den HTML-Kompatibilit@ts-
richtlinien (Anhang C).
Text Markup Language
RICHTIG: Abgeschlossene leere Elemente
<br/><hr/>
FALSCH: Nicht abgeschlossene leere Elemente
<br><hr>
4.7 Behandlung von Leerraum in Attributwerten
Wenn Benutzerprogramme Attribute verarbeiten, so tun sie dies gem@ß Abschnitt 3.3.3 in
[XML]:
·· Entferne f hrenden und abschließenden Leerraum.
Erzeuge aus Folgen von einem oder mehreren Leerraumzeichen (inklusive Zeilenumbr -
chen) ein einzelnes Leerzeichen zwischen W=rtern.
4.8 Script- und Style-Elemente
In XHTML sind die Schrift- und Stilelemente so deklariert, dass sie #PCDATA-Inhalt haben. Dem-
zufolge werden < und & als Anfang des Markups behandelt, und Entities wie beispielsweise <
und & werden vom Prozessor als Entity-Verweise f r < bzw. & erkannt. H llt man den Inhalt
des Schrift- oder Stilelements in einen mit CDATA markierten Abschnitt ein, vermeidet man
dadurch die Erweiterung dieser Entities.
<script type=\;text/javascript\;>
<![CDATA[
... nicht maskierter script-Inhalt...
]]>
</script>
CDATA-Abschnitte werden vom XML-Prozessor erkannt und erscheinen als Knoten im Docu-
ment Object Model (siehe Abschnitt 1.3 der DOM Level 1 Empfehlung [DOM]).
Als Alternative kann man externe Schrift- und Stildokumente verwenden.
< 376 > Unterschiede zu HTML 4
Page size: 168,00 x 240,00 mm
4.9 SGML-Ausschl-sse
SGML bietet dem Entwickler einer DTD die M=glichkeit, f r spezielle Elemente auszuschließen,
dass sie Inhalt eines anderen Elements werden. Solche Ausschl sse sind in XML nicht m=glich.
Die strenge DTD von HTML 4 beispielsweise verbietet, ein 'a'-Element in einem anderen
'a'-Element in einer beliebigen abgeleiteten Tiefe zu verschachteln. In XML ist es nicht m=glich,
solche Ausschl sse zu formulieren. Selbst wenn diese Ausschl sse in der DTD nicht definiert
werden k=nnen, sollten bestimmte Elemente nicht verschachtelt werden. Einen berblick ber
XHTML 1.0: Die Extensible Hyper-
diese Elemente und die Elemente, die nicht darin verschachtelt werden sollten, finden Sie im
normativen Anhang B.
Text Markup Language
4.10 Die Elemente mit 'id'- und 'name'-Attributen
HTML 4 hat das name-Attribut f r die Elemente a, applet, form, frame, iframe, img und map defi-
niert. Dar ber hinaus hat HTML 4 das id-Attribut eingef hrt. Beide Attribute sind f r die Ver-
wendung als Fragmentbezeichner vorgesehen.
In XML haben Fragmentbezeichner den Typ ID, und es kann nur ein einziges Attribut des Typs
ID pro Element geben. Deshalb ist das id-Attribut in XHTML 1.0 als vom Typ ID definiert. Um
sicherzustellen, dass XHTML 1.0-Dokumente korrekt strukturierte XML-Dokumente sind,
mssen XTHML 1.0-Dokumente das id-Attribut verwenden, wenn sie Fragmentbezeichner f r
die o.g. Elemente definieren. Weitere Informationen dar ber, wie Sie sicherstellen, dass solche
Anker abw@rtskompatibel sind, wenn Sie XHTML-Dokumente als Medientyp text/html bereit-
stellen, finden Sie in den Richtlinien zur HTML-Kompatibilit@t (Anhang C).
Beachten Sie, dass in XHTML 1.0 das name-Attribut dieser Elemente formal veraltet ist und in
einer zuk nftigen Version von XHTML entfernt wird.
4.11 Attribute mit vordefinierten Wertemengen
Sowohl HTML 4 als auch XHTML besitzen einige Attribute, die vordefinierte und einge-
schr@nkte Werte haben (z. B. das type-Attribute des input-Elements). In SGML und XML wer-
den sie Aufz@hlungsattribute genannt. In HTML 4 war die Interpretation dieser Werte von der
Groß/Kleinschreibung unabh@ngig, so dass der Wert „TEXT“ @quivalent zu „text“ ist. Durch
XML ist die Interpretation dieser Werte von der Groß/Kleinschreibung abh@ngig, und in
XHTML 1 sind alle diese Werte in Kleinschreibweise definiert.
4.12 Entity-Referenzen als hexadezimaler Wert
Sowohl SGML als auch XML erlauben Zeichenreferenzen in Form von hexadezimalen Werten.
In SGML konnten diese Referenzen entweder in &#Xnn; oder &#xnn; geschrieben werden. In
XML-Dokumenten m ssen Sie die Kleinschreibung verwenden (d. h. &#xnn;).
SGML-Ausschl#sse < 377 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
5 [Link]
Dieser Abschnitt ist normativ.
Obwohl nicht gefordert wird, dass XHTML 1.0-Dokumente mit existierenden Benutzerpro-
grammen kompatibel sind, ist dies in der Praxis ganz einfach zu bewerkstelligen. Richtlinien f r
die Erstellung kompatibler Dokumente finden Sie in Anhang C.
XHTML 1.0: Die Extensible Hyper-
5.1 Internet-Medientyp
XHTML-Dokumente, die den in Anhang C beschriebenen Richtlinien zur Kompatibilit@t mit
Text Markup Language
HTML folgen, k=nnen mit dem Internet-Medientyp "text/html" ausgezeichnet werden
[RFC2854], weil sie mit den meisten HTML-Browsern kompatibel sind. Diese Dokumente und
alle anderen, die konform zu dieser Spezifikation sind, k=nnen außerdem mit dem Internet-Me-
dientyp "application/xhtml+xml" ausgezeichnet werden [RFC3236]. F r weitere Informationen
ber die Verwendung von Medientypen mit XHTML lesen Sie bitte die informelle Note
[XHTMLMIME].
A DTDs
Dieser Abschnitt ist normativ.
Diese DTDs und Entity-Mengen bilden einen normativen Teil dieser Spezifikation. Die vollst@n-
dige Menge der DTD-Dateien zusammen mit einer XML-Deklaration und SGML Open Catalog
ist in der Zip-Datei und der Gzip/Tar-Datei f r diese Spezifikation enthalten. Benutzer, die
lokale Kopien suchen, um damit zu arbeiten, sollten die Archiv-Dateien herunterladen, anstatt
mit den nachfolgend referenzierten DTDs zu arbeiten.
A.1 Dokumenttypdefinitionen
Diese DTDs sind den HTML 4 DTDs ann@hernd gleich. Das W3C empfiehlt, dass Sie die maß-
geblichen Versionen dieser DTDs unter ihren definierten Systembezeichnern verwenden, wenn
Sie den Inhalt validieren. Wenn Sie diese DTDs lokal ben=tigen, sollten Sie eines der Archive
herunterladen. Zur Vollst@ndigkeit sind die normativen Versionen der DTDs hier zu finden:
A.1.1 XHTML-1.0-Strict
Die Datei DTD/[Link] ist ein normativer Bestandteil dieser Spezifikation. Der Voll-
st@ndigkeit halber ist der kommentierte Inhalt dieser Datei in einem eigenen Abschnitt erh@lt-
lich.
A.1.2 XHTML-1.0-Transitional
Die Datei DTD/[Link] ist ein normativer Bestandteil dieser Spezifikation. Der
Vollst@ndigkeit halber ist der kommentierte Inhalt dieser Datei in einem eigenen Abschnitt
erh@ltlich.
< 378 > Kompatibilit,tsaspekte
Page size: 168,00 x 240,00 mm
A.1.3 XHTML-1.0-Frameset
Die Datei DTD/[Link] ist ein normativer Bestandteil dieser Spezifikation. Der
Vollst@ndigkeit halber ist der kommentierte Inhalt dieser Datei in einem eigenen Abschnitt
erh@ltlich.
A.2 Entity-Mengen
XHTML 1.0: Die Extensible Hyper-
Die XHTML-Entity-Mengen sind dieselben wie f r HTML 4, wurden aber angepasst, so dass sie
g ltige XML 1.0-Entity-Deklarationen darstellen. Beachten Sie das Entity f r das Euro-W@h-
Text Markup Language
rungssymbol (€ oder € oder €), das als Teil der Sonderzeichen definiert ist.
A.2.1 Latin-1 characters
Die Datei DTD/[Link] ist ein normativer Bestandteil dieser Spezifikation. Der Vollst@n-
digkeit halber ist der kommentierte Inhalt dieser Datei in einem eigenen Abschnitt erh@ltlich.
A.2.2 Special characters
Die Datei DTD/[Link] ist ein normativer Bestandteil dieser Spezifikation. Der Voll-
st@ndigkeit halber ist der kommentierte Inhalt dieser Datei in einem eigenen Abschnitt erh@lt-
lich.
A.2.3 Symbols
Die Datei DTD/[Link] ist ein normativer Bestandteil dieser Spezifikation. Der Voll-
st@ndigkeit halber ist der kommentierte Inhalt dieser Datei in einem eigenen Abschnitt erh@lt-
lich.
B Element-Ausschl-sse
Dieser Abschnitt ist normativ.
Die folgenden Elemente weisen Ausschl sse dahingehend auf, welche Elemente sie enthalten
k=nnen (siehe Abschnitt 4.9). Diese Ausschl sse gelten f r alle Verschachtelungstiefen, das
heißt, sie erstrecken sich auf alle abgeleiteten Elemente.
a
Darf keine anderen a-Elemente enthalten.
pre
Darf nicht die Elemente img, object, big, small, sub oder sup enthalten.
button
Darf nicht die Elemente input, select, textarea, label, button, form, fieldset, iframe oder
isindex enthalten.
Entity-Mengen < 379 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
label
Darf keine anderen label-Elelemente enthalten.
form
Darf keine anderen form-Elemente enthalten.
C Richtlinien zur
XHTML 1.0: Die Extensible Hyper-
HTML-Kompatibilit.t
Text Markup Language
Dieser Abschnitt ist informell.
Dieser Anhang fasst die Design-Richtlinien f r Autoren zusammen, die ihre XHTML-Doku-
mente auf bereits existierenden HTML-Benutzerprogrammen anzeigen wollen. Beachten Sie,
dass diese Empfehlung nicht definiert, wie zu HTML konforme Benutzerprogramme HTML-Do-
kumente verarbeiten sollten. Auch definiert sie nicht die Bedeutung des Internet-Medientyps
text/html. F r diese Definitionen lesen Sie bitte [HTML4] bzw. [RFC2854].
C.1 Verarbeitungsanweisungen und die XML-Deklaration
Beachten Sie, dass Verarbeitungsanweisungen auf einigen Benutzerprogrammen dargestellt
werden. Außerdem interpretieren einige Benutzerprogramme die XML-Deklaration so, als ob
sie unbekanntes XML statt HTML vor sich h@tten; und folglich stellen sie das Dokument nicht
wie erwartet dar. Zur Kompatibilit@t mir diesen alten Browsern k=nnen Sie auf Verarbeitungs-
anweisungen und XML-Deklarationen verzichten. Beachten Sie jedoch auch, dass, wenn die
XML-Deklaration nicht in ein Dokument aufgenommen ist, das Dokument nur die Standard-
Zeichencodierungen UTF-8 oder UTF-16 verwenden kann.
C.2 Leere Elemente
F gen Sie ein Leerzeichen vor dem f hrenden / und > leerer Elemente ein. z. B. <br />, <hr />
und <img src="[Link]" alt="Karen" />. Verwenden Sie dar ber hinaus die minimierte Tag-
Syntax f r leere Elemente, z. B. <br />, weil die alternative Syntax <br></br>, die von XML
erlaubt ist, unsichere Ergebnisse in vielen bereits existierenden Benutzerprogrammen erzeugt.
C.3 Elementminimierung und leerer Elementinhalt
F r eine leere Instanz eines Elements, dessen Inhaltsmodell nicht EMPTY ist (z. B. ein leerer Titel oder
Absatz), verwenden Sie nicht die minimierte Form (verwenden Sie z. B. <p> </p>, und nicht <p />).
C.4 Eingebettete Stylesheets und Skripte
Verwenden Sie externe Stylesheets, wenn Ihr Stylesheet < oder & oder ]]> oder -- verwendet.
Verwenden Sie externe Skripts, wenn Ihr Skript < oder & oder ]]> oder -- verwendet. Beach-
ten Sie, dass XML-Parser den Inhalt von Kommentaren stillschweigend entfernen d rfen. Die
< 380 > Richtlinien zur HTML-Kompatibilit,t
Page size: 168,00 x 240,00 mm
bisherige Vorgehensweise, Skripts und Stylesheets innerhalb von „Kommentaren“ zu „verste-
cken“, um die Dokumente abw@rtskompatibel zu machen, funktioniert also sehr wahrscheinlich
in auf XML basierenden Benutzerprogrammen nicht, wie erwartet.
C.5 Zeilenumbr-che innerhalb von Attributwerten
Vermeiden Sie Zeilenumbr che und mehrere aufeinanderfolgende Leerraumzeichen innerhalb
von Attributwerten. Sie werden von den Benutzerprogrammen inkonsistent behandelt.
XHTML 1.0: Die Extensible Hyper-
C.6 Isindex
Text Markup Language
Nehmen Sie nicht mehr als ein isindex-Element in den Dokument-head auf. Das isindex-Ele-
ment ist veraltet und wird durch das input-Element ersetzt.
C.7 Die Attribute lang and xml:lang
Verwenden Sie f r die Angabe der Sprache eines Dokuments die Attribute lang und xml:lang.
Der Wert des Attributs xml:lang hat Priorit@t.
C.8 Fragmentbezeichner
In XML verweisen URI-Referenzen [RFC2396], die mit Fragmentbezeichnern der Form "#foo"
enden, nicht auf Elemente mit einem Attribut name="foo"; stattdessen verweisen sie auf Ele-
mente mit einem Attribut, das als vom Typ ID definiert ist, z. B. das id-Attribut in HTML 4.
Viele bereits existierende HTML-Clients unterst tzen die Verwendung von Attributen vom
Typ ID auf diese Weise nicht, deshalb k=nnen identische Werte f r beide Attribute angegeben
werden, um eine maximale Aufw@rts- und Abw@rtskompatibilit@t sicherzustellen (z. B.
<a id="foo" name="foo">...</a>).
Und weil dar ber hinaus die Menge der erlaubten Werte f r Attribute des Typs ID viel kleiner
als die f r den Typ CDATA ist, muss der Typ des name-Attributs in NMTOKEN ge@ndert werden. Die-
ses Attribut ist beschr@nkt, weil es nur dieselben Werte wie der Typ ID haben kann oder wie
die Name-Produktion in XML 1.0 Abschnitt 2.3 Produktion 5. Leider kann diese Beschr@nkung in
den DTDs von XHTML 1.0 nicht ausgedr ckt werden. Aufgrund dieser Onderung muss die
Umwandlung existierender HTML-Dokumente @ußerst sorgf@ltig erfolgen. Die Werte dieser
Attribute m ssen eindeutig innerhalb des Dokuments und g ltig sein, und alle Verweise auf
diese Fragmentbezeichner (sowohl intern als auch extern) m ssen aktualisiert werden, falls sich
die Werte w@hrend der Umwandlung @ndern.
Beachten Sie, dass die Menge der erlaubten Werte in XML 1.0, Abschnitt 2.3, Produktionsregel
5, viel gr=ßer ist als das, was duch die in HTML 4 definierten ID- und NAME-Typen erlaubt ist.
Wenn Sie Fragmenbezeichner definieren, die abw@rtskompatibel sein sollen, sollten nur solche
Zeichenketten verwendet werden, die zu dem Muster [A-Za-z][A-Za-z0-9:_.-]* passen. Siehe
[HTML4], Abschnitt 6.2 f r weitere Informationen.
Beachten Sie schließlich, dass XHTML 1.0 das name-Attribut der Elemente a, applet, form,
frame, iframe, img und map als veraltet betrachtet und es in sp@teren Versionen aus XHTML
entfernt wird.
Zeilenumbr#che innerhalb von Attributwerten < 381 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
C.9 Zeichencodierung
Historisch wurde die Zeichenkodierung eines HTML-Dokuments entweder durch einen Web-
Server durch Angabe des charset-Parameters im HTTP Content Type Header oder durch ein
Meta-Element im Dokument selbst angegeben. In einem XML-Dokument wird die Zeichenko-
dierung des Dokuments durch die XML-Deklaration angegeben (z. B. <?xml version="1.0" enco-
ding="EUC-JP"?>). Der beste Ansatz, um Dokumente mit einer bestimmten Zeichenkodierung
m=glichst portabel anzubieten, besteht darin, sicherzustellen, dass der Web-Server die korrek-
XHTML 1.0: Die Extensible Hyper-
ten Header verwendet. Wenn das nicht m=glich ist, muss ein Dokument, das seine Zeichenko-
dierung explizit setzen will, sowohl die XML-Deklaration mit Kodierungsdeklaration als auch
Text Markup Language
einen Meta-http-equiv-Ausdruck (z. B. <meta http-equiv="Content-type" content="text/html;
charset=EUC-JP" />) angeben. Der Wert des Kodierungsattributs der XML-Verarbeitungsanwei-
sung hat in XHTML-konformen Benutzerprogrammen Priorit@t.
Hinweis: Beachten Sie, dass ein Dokument, das die Zeichenkodierungsdeklaration in einem
Meta-http-equiv-Ausdruck enthalten muss, durch einen HTTP-Server und/oder durch Benut-
zerprogramme als vom angegebenen Medientyp angesehen werden kann. Wenn ein Dokument
unter mehreren Medientypen verschickt werden soll, dann muss der HTTP-Server zum Setzen
der Kodierung verwendet werden. n
C.10 Boolesche Attribute
Einige HTML-Benutzerprogramme k=nnen keine Booleschen Attribute interpretieren, wenn
diese in ihrer vollst@ndigen (nicht minimierten) Form auftreten, wie in XML 1.0 gefordert.
Beachten Sie, dass dieses Problem keinen Einfluss auf Benutzerprogramme hat, die konform zu
HTML 4 sind. Die folgenden Attribute sind betroffen: compact, nowrap, ismap, declare, noshade,
checked, disabled, readonly, multiple, selected, noresize, defer.
C.11 Document Object Model und XHTML
Die Document Object Model Level 1-Empfehlung [DOM] definiert Dokumentobjektmodell-
schnittstellen f r XML und HTML 4. Das HTML 4-Dokumentobjektmodell spezifiziert, dass
HTML-Element- und Attributnamen in Großbuchstaben zur ckgegeben werden. Das XML-Do-
kumentobjektmodell spezifiziert, dass Element- und Attributnamen so zur ckgegeben werden,
wie sie angegeben wurden. In XHTML 1.0 werden Elemente und Attribute in Kleinbuchstaben
angegeben. Dieser offensichtliche Unterschied kann auf zwei Arten kompensiert werden:
1. Benutzerprogramme, die auf XHTML-Dokumente zugreifen, die als Internet-Medientyp
text/html ber das DOM bereitgestellt werden, k=nnen das HTML DOM verwenden und
davon ausgehen, dass Element- und Attributnamen von diesen Schnittstellen in Großbuch-
staben zur ckgegeben werden.
2. Benutzerprogramme, die auf XHTML-Dokumente zugreifen, die als Internet-Medientypen
text/xml, application/xml oder application/xhtml+xml bereitgestellt werden, k=nnen eben-
falls das XML DOM verwenden. Elemente und Attribute werden in Kleinbuchstaben
zur ckgegeben. Dar ber hinaus kann es sein, dass bestimmte Elemente im Objektbaum
erscheinen oder nicht erscheinen, weil einige im Inhaltsmodell optional sind (z. B. das tbody-
Element in table). Das passiert, weil in HTML 4 einige Elemente minimiert sein durften, so
dass ihre Start- und End-Tags weggelassen werden konnten (ein SGML-Funktionsmerkmal).
< 382 > Richtlinien zur HTML-Kompatibilit,t
Page size: 168,00 x 240,00 mm
In XML ist das nicht m=glich. Statt von den Dokumentautoren zu fordern, unwesentliche
Elemente einzuf gen, hat XHTML die Elemente optional gemacht. Benutzerprogramme
m ssen dies entsprechend bernehmen. F r weitere Informationen siehe [DOM2].
C.12 Die Verwendung von et-Zeichen in Attributwerten
(und anderswo)
XHTML 1.0: Die Extensible Hyper-
Sowohl in SGML als auch in XML bezeichnet das et-Zeichen (&) den Anfang einer Entity-Refe-
renz (z. B. ® f r "*"). Ungl cklicherweise haben viele HTML-Benutzerprogramme die
Text Markup Language
unkorrekte Benutzung des et-Zeichens stillschweigend ignoriert. Sie haben et-Zeichen, die
nicht wie Entity-Referenzen aussehen, als „w=rtliche“ et-Zeichen behandelt. XML-basierte
Benutzerprogramme werden diese unkorrekte Verwendung nicht tolerieren. Jedes Dokument,
das ein et-Zeichen unkorrekt benutzt, wird nicht g ltig sein und folglich nicht konform zu die-
ser Spezifikation sein. Um sicherzustellen, dass Dokumente mit alten HTML-Benutzerprogram-
men und XML-basierten Benutzerprogrammen kompatibel sind, m ssen et-Zeichen, die als
normale Zeichen behandelt werden sollen, selbst als Entity-Referenzen (d. h. &) geschrie-
ben werden. Verweist beispielsweise das href-Attribut des a-Elements auf ein CGI-Skript, das
Parameter entgegennimmt, muss es wie folgt ausgedr ckt werden: [Link]
[Link]?class=guest&name=user, und nicht als [Link]
pl?class=guest&name=user.
C.13 Cascading Style Sheets (CSS) und XHTML
Die Cascading Style Sheets Level 2-Empfehlung [CSS2] definiert Stileigenschaften, die auf den
Parsing-Baum des HTML- oder XML-Dokuments angewendet werden. Unterschiede beim Par-
sing erzeugen unterschiedliche visuelle oder akustische Ergebnisse, abh@ngig von den verwen-
deten Selektoren. Die folgenden Hinweise reduzieren diesen Effekt f r Dokumente, die ohne
Ver@nderung als beide Medientypen bereitgestellt werden:
1. CSS-Stylesheets f r XHTML sollten f r Element- und Attributnamen Kleinbuchstaben ver-
wenden.
2. In Tabellen wird das tbody-Element durch den Parser eines HTML-Benutzerprogramms
abgeleitet, nicht aber vom Parser eines XML-Benutzerprogramms. Deshalb sollten Sie
immer explizit ein tbody-Element einf gen, wenn in einem CSS-Selektor darauf verwiesen
wird.
3. Innerhalb des XHTML-Namensraums geht man davon aus, dass Benutzerprogramme das id-
Attribut als Attribut des Typs ID erkennen. Deshalb sollten Stylesheets in der Lage sein, die
abk rzende Selektorsyntax "#" weiterhin zu erkennen, auch wenn das Benutzerprogramm
die DTD nicht liest.
4. Innerhalb des XHTML-Namensraums erwartet man von den Benutzerprogrammen, dass
sie das class-Attribut erkennen. Deshalb sollten die Stylesheets weiterhin in der Lage sein,
die abk rzende Selektorsyntax “.“ zu verwenden.
5. CSS definiert unterschiedliche Konformit@tsregeln f r HTML- und XML-Dokumente;
beachten Sie, dass die HTML-Regeln f r XHTML-Dokumente gelten, die als HTML ausgelie-
fert werden, und die XML-Regeln f r XHTML-Dokumente, die als XML ausgeliefert wer-
den.
Die Verwendung von et-Zeichen in Attributwerten < 383 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
C.14 Referenzierung von Style-Elementen bei
Verwendung als XML
In HTML 4 und in XHTML kann das style-Element benutzt werden, um dokumentinterne For-
matierungsregeln zu definieren. In XML wird eine XML-Stylesheet-Deklaration verwendet, um
Formatierungsregeln zu definieren. Um mit dieser Konvention kompatibel zu sein, sollten style-
Elemente ihren Fragmentbezeichner mit Hilfe des id-Attributs setzen. Eine XML-Stylesheet-
Deklaration sollte dieses Fragment referenzieren. Zum Beispiel:
XHTML 1.0: Die Extensible Hyper-
<?xml-stylesheet href="[Link]
Text Markup Language
type="text/css"?>
<?xml-stylesheet href="#internalStyle" type="text/css"?>
<html xmlns="[Link]
xml:lang="en"
lang="en">
<head>
<title>An internal stylesheet example</title>
<style id="internalStyle">
code {
color: green;
font-family: monospace;
font-weight: bold;
}
</style>
</head>
<body>
<p>
This is text that uses our
<code>internal stylesheet</code>.
</p>
</body>
</html>
C.15 Leerraumzeichen in HTML vs. XML
Einige Zeichen, die in HTML-Dokumenten erlaubt sind, sind in XML-Dokumenten nicht
erlaubt. Zum Beispiel wird das Seitenvorschubzeichen (Form-feed, U+000C) in HTML als Leer-
aum behandelt. In XHTML ist es wegen der Zeichendefinition von XML nicht erlaubt.
C.16 Die benannte Zeichenreferenz '
Die benannte Zeichenreferenz ' (das Apostroph, U+0027) wurde in XML 1.0 eingef hrt,
erscheint aber nicht in HTML. Autoren sollten deshalb ' anstelle von ' verwenden,
damit es wie erwartet mit HTML 4-Benutzerprogrammen l@uft.
< 384 > Richtlinien zur HTML-Kompatibilit,t
Page size: 168,00 x 240,00 mm
D Danksagungen
Dieser Abschnitt ist informell.
Diese Spezifikation wurde unter Beteiligung der Mitglieder der HTML-Arbeitsgruppe des W3C
geschrieben.
Bei Ver=ffentlichung der zweiten Auflage hatte die Arbeitsgruppe folgende Mitglieder:
Steven Pemberton, CWI/W3C (HTML Working Group Chair); Daniel Austin, Grainger; Jonny
Axelsson, Opera Software; Tantek kelik, Microsoft; Doug Dominiak, Openwave Systems; Her-
XHTML 1.0: Die Extensible Hyper-
man Elenbaas, Philips Electronics; Beth Epperson, Netscape/ AOL; Masayasu Ishikawa, W3C
(HTML Activity Lead); Shin'ichi Matsui, Panasonic; Shane McCarron, Applied Testing and Tech-
Text Markup Language
nology; Ann Navarro, WebGeek, Inc.; Subramanian Peruvemba, Oracle; Rob Relyea, Microsoft;
Sebastian Schnitzenbaumer, SAP; Peter Stark, Sony Ericsson
Bei Ver=ffentlichung der ersten Auflage hatte die Arbeitsgruppe folgende Mitglieder:
Steven Pemberton, CWI (HTML Working Group Chair); Murray Altheim, Sun Microsystems;
Daniel Austin, AskJeeves (CNET: The Computer Network bis Juli 1999); Frank Boumphrey,
HTML Writers Guild; John Burger, Mitre; Andrew W. Donoho, IBM; Sam Dooley, IBM; Klaus
Hofrichter, GMD; Philipp Hoschka, W3C; Masayasu Ishikawa, W3C; Warner ten Kate, Philips
Electronics; Peter King, [Link]; Paula Klante, JetForm; Shin'ichi Matsui, Panasonic (W3C
Gast-Ingenieur bis September 1999); Shane McCarron, Applied Testing and Technology (The
Open Group bis August 1999); Ann Navarro, HTML Writers Guild; Zach Nies, Quark; Dave
Raggett, W3C/HP (HTML Activity Lead); Patrick Schmitz, Microsoft; Sebastian Schnitzenbau-
mer, Stack Overflow; Peter Stark, [Link]; Chris Wilson, Microsoft; Ted Wugofski, Gate-
way 2000; Dan Zigmond, WebTV Networks
E Literaturverzeichnis
Dieser Abschnitt ist informell.
[CSS2]
"Cascading Style Sheets, level 2 (CSS2) Specification", B. Bos, H. W. Lie, C. Lilley, I. Jacobs,
12. Mai 1998. Neueste Version unter: [Link]
[DOM]
"Document Object Model (DOM) Level 1 Specification", Lauren Wood et al., 1. Oktober
1998. Neueste Version unter: [Link]
[DOM2]
"Document Object Model (DOM) Level 2 Core Specification ", A. Le Hors, et al. ,13
November 2000. Neueste Version unter: [Link]
2-Core .
[HTML]
"HTML 4.01 Specification", D. Raggett, A. Le Hors, I. Jacobs, 24. Dezember 1999. Neueste
Version unter: [Link]
Danksagungen < 385 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
[POSIX.1]
"ISO/IEC 9945-1:1990 Information Technology - Portable Operating System Interface (PO-
SIX) - Part 1: System Application Program Interface (API) [C Language]", Institute of Electri-
cal and Electronics Engineers, Inc, 1990.
[RFC2045]
"Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message
Bodies", N. Freed and N. Borenstein, November 1996. Dieser RFC ersetzt die veralteten
RFC1521, RFC1522, und RFC1590.
XHTML 1.0: Die Extensible Hyper-
[RFC2046]
"RFC2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", N.
Text Markup Language
Freed und N. Borenstein, November 1996. Verf gbar unter: [Link]
[Link]. Beachten Sie, dass nach diesem RFC die RFCs RFC1521, RFC1522 und
RFC1590 veraltet sind.
[RFC2119]
"RFC2119: Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, M@rz
1997. Verf gbar unter: [Link]
[RFC2376]
"RFC2376: XML Media Types", E. Whitehead, M. Murata, Juli 1998. Verf gbar unter:
[Link]
[RFC2396]
"RFC2396: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fiel-
ding, L. Masinter, August 1998. Dieses Dokument aktualisiert RFC1738 und RFC1808. Ver-
f gbar unter: [Link]
[RFC2854]
"RFC2854: The text/html Media Type", D. Conolly, L. Masinter, June 2000. Verf gbar unter:
[Link]
[RFC3023]
"RFC3023: XML Media Types", M. Murata, S. [Link], D. Kohn, Januar 2001. Dieses
Dokument ersetzt den veralteten [RFC2376]. Verf gbar unter: [Link]
[Link]
[RFC3066]
"Tags for the Identification of Languages", H. Alvestrand, Januar 2001. Verf gbar unter:
[Link]
[RFC3236]
"The 'application/xhtml+xml' Media Type", M. Baker, P. Stark, January 2002. Verf gbar
unter: [Link]
[XHTML+MathML]
"XHTML plus Math 1.1 DTD", "A.2 MathML as a DTD Module", Mathematical Markup
Language (MathML) Version 2.0. Verf gbar unter: [Link]
MathML2/dtd/[Link]
[XHTMLMIME]
" XHTML Media Types ", Masayasu Ishikawa, 1 August 2002. Neueste Version unter:
[Link]
[XHTMLMOD]
"Modularization of XHTML", M. Altheim et al., 10 April 2001. Neueste Version unter:
[Link]
< 386 > Literaturverzeichnis
Page size: 168,00 x 240,00 mm
[XML]
"Extensible Markup Language (XML) 1.0 Specification", T. Bray, J. Paoli, C. M. Sperberg-
McQueen, 10. Februar 1998. Neueste Version unter: [Link]
xml
[XMLNAMES]
"Namespaces in XML", T. Bray, D. Hollander, A. Layman, [Link] 199. XML-Namens-
r@ume stellen eine einfache Methode f r die Qualifizierung von Namen dar, die in XML-Do-
kumenten verwendet werden, indem ihnen Namensr@ume zugeordnet sind, die durch URI
XHTML 1.0: Die Extensible Hyper-
identifiziert werden. Neueste Version unter: [Link]
mes
Text Markup Language
[XMLC14N]
"Canonical XML Version 1.0", J. Boyer, 15 March 2001. Dieses Dokument beschreibt ein
Verfahren zur Erzeugung einer physischen Repr@sentation, die kanonische Form, eines
XML-Dokuments. Aktuelle Version erh@ltlich unter [Link]
xml-c14n
Literaturverzeichnis < 387 >
Page size: 168,00 x 240,00 mm
Page size: 168,00 x 240,00 mm
<edition
[Link]>
C
< Modularisierung
von XHTML >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Modularisierung von XHTML
Deutsche bersetzung
7. Januar 2003
Diese Version:
[Link]
Aktuelle Version:
[Link]
bersetzer:
Stefan Mintert, [Link] <stefan@[Link]>
Bei diesem Dokument handelt es sich um eine bersetzung eines W3C-Textes. Dieser
Text ist urheberrechtlich gesch tzt; bitte beachten Sie die nachfolgenden Hinweise des
Modularisierung von XHTML
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.
Modularisierung von XHTML
W3C-Empfehlung, 10. April 2001
Diese Version:
[Link]
(Einzelnes HTML file, PostScript-Version, PDF-Version, ZIP-Archiv, or Gzip/TAR-Archiv)
Aktuellste Version:
[Link]
Vorhergehende Version:
[Link]
Herausgeber:
Murray Altheim, Sun Microsystems
Frank Boumphrey, HTML Writers Guild
Sam Dooley, IBM
Shane McCarron, Applied Testing and Technology
Sebastian Schnitzenbaumer, Mozquito Technologies AG
Ted Wugofski, Openwave (formerly Gateway)
Copyright L 2001 W3CM (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark,
document use and software licensing rules apply.
< 390 > Modularisierung von XHTML
Page size: 168,00 x 240,00 mm
Zusammenfassung
Diese Empfehlung spezifiziert eine abstrakte Modularisierung von XHTML und eine Implemen-
tierung dieser Abstraktion unter Verwendung von XML-Dokumenttyp-Definitionen (DTDs).
Diese Modularisierung stellt Mittel zur Verf gung, um Teilmengen von XHTML zu bilden und
um XHTML zu erweitern; eine Eigenschaft, die f r die Ausweitung von XHTML auf kommende
Plattformen ben=tigt wird.
Status dieses Dokuments
Dieser Abschnitt beschreibt den Status dieses Dokuments zur Zeit seiner Ver=ffentlichung.
Andere Dokumente k=nnen dieses Dokument ersetzen. Der aktuelle Status dieser Dokument-
serie wird beim W3C verwaltet.
Dieses Dokument wurde von W3C-Mitgliedern und anderen Interessierten begutachtet, und
Modularisierung von XHTML
es wurde vom Direktor als W3C Recommendation gebilligt. Es handelt sich um ein stabiles
Dokument und kann als Referenzmaterial verwendet oder als normative Referenz in anderen
Dokumenten zitiert werden. Bei der Herstellung der Recommendation ist es die Rolle des
W3C, die Aufmerksamkeit auf diese Spezifikation zu lenken und ihre Verbreitung zu f=rdern.
Das verbessert die Funktionsweise und Interoperabilit@t des Web.
Dieses Dokument wurde von der W3C HTML Working Group ([Link]/MarkUp/
Group/; nur f r Mitglieder: [Link]/MemberAccess/AccessRequest) als Teil der W3C
HTML Activity produziert. Die Ziele der HTML Working Group werden in der HTML
Working Group charter ([Link]/MarkUp/2000/Charter) diskutiert. Der W3C-Kon-
takt f r HTML ist Masayasu Ishikawa (mimasa@[Link]).
Die =ffentliche Diskussion von HTML findet auf www-html@[Link] statt (Archiv: [Link]/
Archives/Public/www-html/). Zur Anmeldung schicken Sie bitte eine Mail mit dem Wort sub-
scribe im Subject an www-html-request@[Link].
Bitte berichten Sie Fehler in diesem Dokument an www-html-editor@[Link] (Archiv:
[Link]/Archives/Public/www-html-editor/). Die Liste der bekannten Fehler in dieser Spezi-
fikation steht unter [Link]
zur Verf gung.
Die englische Version dieser Spezifikation ist die einzige normative Version. Informationen ber
bersetzungen von diesem Text sind unter [Link] zu finden.
Eine Liste aktueller W3C Recommendations und anderer technischer Dokumente befindet sich
unter [Link]
1 Einf-hrung
Dieser Abschnitt ist informell.
1.1 Was ist XHTML?
XHTML ist eine Neuformulierung von HTML 4 als Anwendung von XML. XHTML 1.0
[XHTML1] spezifiziert drei XML-Dokumenttypen, die zu den drei HTML 4-DTDs korrespon-
Zusammenfassung < 391 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
dieren: Strict, Transitional, and Frameset. XHTML 1.0 ist die Basis einer Familie von Doku-
menttypen, die eine Teilmenge von HTML bilden und HTML erweitern.
1.2 Was ist XHTML-Modularisierung?
XHTML-Modularisierung ist eine Aufteilung von XHTML 1.0 – und durch Verweise auch von
HTML 4 – in eine Sammlung von abstrakten Modulen, die bestimmte Funktionstypen anbieten.
Diese abstrakten Module werden in dieser Sepzifikation unter Verwendung von XML-Doku-
menttyp-Deklarationen implementiert; eine Implementierung mit XML-Schema wird erwartet.
Die Regeln zur Definition der abstrakten Module und zur Implementierung mit XML-DTDs
werden ebenfalls in diesem Dokument definiert.
Diese Module k=nnen miteinander und mit anderen Modulen kombiniert werden, um Teilmen-
gen von XHTML oder erweiterte Dokumenttypen zu schaffen, die sich als Teil der Familie von
XHTML-Dokumenttypen auszeichnen.
Modularisierung von XHTML
1.3 Warum XHTML modularisieren?
Die Modularisierung von XHTML stellt sich der Herausforderung, wohldefinierte Mengen von
XHTML-Elementen zu spezifizieren, die von Dokumentverfassern, Dokumenttyp-Architekten,
anderen XML-Spezifikationen und Anwendungs- und Produktdesignern kombiniert und erwei-
tert werden k=nnen, um es f r Inhalte-Lieferanten =konomisch tragbar zu machen, Inhalte f r
eine gr=ßere Zahl und ein gr=ßeres Spektrum verschiedener Plattformen zu liefern.
W@hrend der letzten Jahre haben viele spezialisierte M@rkte begonnen, HTML als eine Inhalt-
sprache zu sehen. Es zeichnet sich mehr und mehr die Tendenz ab, HTML ber die Grenzen
von zunehmend heterogenen Computerplattformen zu nutzen. Momentan gibt es den Trend,
HTML auf mobile Ger@te (tragbare Computer, Telefone und so weiter), Fernsehger@te (digita-
les Fernsehen, fernsehbasierte Web-Browser und so weiter) und andere Ger@te zu bringen.
Alle dieser Ger@te haben unterschiedliche Anforderungen und unterliegen verschiedenen
Beschr@nkungen.
XHTML zu modularisieren, stellt f r Produktentwickler Mittel zur Verf gung, mit denen sie
angeben k=nnen, welche Elemente durch ein Ger@t unterst tzt werden. Sie tun dies unter Ver-
wendung von Standardbauteilen und -methoden zur Angabe, welche Bauteile benutzt werden.
Die Module dienen der Inhalte-Gemeinschaft als „Konformit@tsmarken“. Die Inhalte-Gemein-
schaft kann nun die installierte Basis, die eine bestimmte Sammlung von Modulen unterst tzt,
adressieren; im Gegensatz dazu, sich Gedanken ber die installierte Basis zu machen, die diese
oder jene Permutation von XHTML-Elementen unterst tzt. Die Verwendung von Standards ist
ein kritischer Faktor f r modularisiertes XHTML, um im großen Maßstab erfolgreich zu sein. Es
ist f r Inhalte-Lieferanten wirtschaftlich nicht tragbar, Inhalte f r alle und jede Permutation
maßzuschneidern. Durch die Spezifikation eines Standards k=nnen entweder Software-Pro-
zesse den Inhalt f r ein Ger@t automatisch maßschneidern, oder das Ger@t kann die f r die Ver-
arbeitung eines Moduls n=tige Software automatisch laden.
Modularisierung gestattet, unter Verwendung der Erweiterbarkeit von XML, auch eine Erwei-
terung der Layout- und Pr@sentationsf@higkeiten von XHTML, ohne den XHTML-Standard zu
verletzen. Dieser Entwicklungspfad sorgt f r einen stabilen, n tzlichen und implementierbaren
Rahmen f r Inhalte-Lieferanten und Publizisten, das schnelle Tempo der technischen Ver@nde-
rung des Web zu handhaben.
< 392 > Einf#hrung
Page size: 168,00 x 240,00 mm
1.3.1 Abstrakte Module
Ein XHTML-Dokumenttyp ist als eine Menge von abstrakten Modulen definiert. Ein abstraktes
Modul definiert eine Art von Daten, die sich semantisch von allen anderen unterscheidet. Abs-
trakte Module k=nnen ohne Verst@ndnis der ihnen zugrunde liegenden Schemata, die die
Module definieren, zu Dokumenttypen kombiniert werden.
1.3.2 Modulimplementierungen
Eine Modulimplementierung besteht aus einer Menge von Elementtypen, einer Menge von
Attributlistendeklarationen und einer Menge von Inhaltsmodelldeklarationen, wobei jede der
drei Mengen leer sein kann. Eine Attributlistendeklaration in einem Modul darf einen Element-
typ modifizieren, der außerhalb der im Modul definierten Elementtypen steht. Und eine Inhalts-
modelldeklaration darf einen Elementtyp modifizieren, der außerhalb der im Modul definierten
Modularisierung von XHTML
Elementtypen steht.
Ein Mechanismus zur Implementierung sind XML-DTDs. Eine XML-DTD ist ein Mittel, um die
Struktur einer Klasse von XML-Dokumenten zu beschreiben, allgemein bekannt als XML-Do-
kumenttyp. XML-DTDs werden in der XML 1.0-Empfehlung beschrieben [XML]. Ein anderer
Implementierungsmechanismus ist XML-Schema [XMLSCHEMA].
1.3.3 Hybride Dokumenttypen
Ein hybrider Dokumenttyp ist ein Dokumenttyp, der aus einer Sammlung von XML-DTDs oder
DTD-Modulen zusammengef gt wird. Der prim@re Zweck des Rahmenwerks zur Modularisie-
rung, das in diesem Dokument beschrieben wird, besteht darin, DTD-Autoren zu erlauben,
Elemente von verschiedenen abstrakten Modulen zu hybriden Dokumenttypen zu kombinieren,
Dokumente zu diesen hybriden Dokumenttyp zu erzeugen und die G ltigkeit des Dokuments
bez glich des entsprechenden hybriden Dokumenttyps zu validieren.
Einer der wertvollsten Vorteile von XML gegen ber SGML ist, dass XML den Einstiegsaufwand
zur Standardisierung von Elementmengen reduziert, die Gemeinschaften erlauben, Datenaus-
tausch in einem austauschf@higen Format zu betreiben. Jedenfalls hat die relativ statische Natur
von HTML als Inhaltssprache des Web bedeutet, dass jede dieser Gemeinschaft nur wenig
Hoffnung hegen konnte, dass ihre XML-Dokumenttypen eine großfl@chige Anerkung als Web-
Standard erfahren w rden. Das Rahmenwerk zur Modularisierung erlaubt die dynamische Auf-
nahme dieser verschiedenen Dokumenttypen durch die Familie der XHTML-Dokumenttypen.
Damit wird der Aufwand zur Aufnahme dieser dom@nenspezifischen Vokabulare in XHTML-
Dokumente weiter verringert.
1.3.4 Validierung
Die Verwendung von wohlgeformten, aber nicht g ltigen Dokumenten ist ein wichtiger Vorteil
von XML. W@hrend der Entwicklung eines Dokumenttyps ist dennoch die zus@tzliche Hilfe
wichtig, die ein validierender Parser zur Fehlerpr fung bietet. Die gleiche Aussage gilt f r
XHTML-Dokumenttypen mit Elementen von verschiedenen abstrakten Modulen.
Ein Dokument ist eine Instanz eines bestimmten Dokumenttyps, der durch die DTD definiert
wird, die im Prolog des Dokuments angegeben ist. Das Validieren des Dokuments ist der Vor-
gang der berpr fung, ob sich das Dokument an die Regeln in der Dokumenttyp-Definition h@lt.
Warum XHTML modularisieren? < 393 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Ein Dokument kann aus mehreren Dokumentfragmenten bestehen. Das Validieren nur von
Fragmenten eines Dokuments, wobei jedes Fragment von einem verschiedenen Dokumenttyp
als die anderen Fragmente im Dokument ist, liegt außerhalb der Zust@ndigkeit dieses Rahmen-
werks – dies w rde eine Technik erfordern, die noch nicht definiert ist.
Jedenfalls erlaubt es das Rahmenwerk zur Modularisierung mehrere Dokumenttyp-Definitionen
zu einem neuen Dokumenttyp zusammenzufassen (zum Beispiel SVG integriert mit XHTML).
Die neue Dokumenttyp-Definition kann f r die normale XML 1.0-Validierung benutzt werden.
1.3.5 Formatierungsmodell
Fr here Versionen von HTML versuchten Teile des Modells zu definieren, die Benutzerpro-
gramme brauchen, wenn sie ein Dokument formatieren. Mit dem Aufkommen von HTML 4
begann das W3C damit, Pr@sentation von Struktur zu trennen. XHTML 1.0 behielt diese Tren-
nung bei und dieses Dokument f@hrt damit fort, HTML und seine Nachkommen auf diesem
Modularisierung von XHTML
Weg weiterzuf hren. In der Folge davon stellt dieses Dokument keine Anforderungen an das
Formatierungsmodell f r die Darstellung von Dokumenten, die gem@ß der Familie von
XHTML-Dokumenttypen ausgezeichnet sind.
Statt dessen empfiehlt dieses Dokument, dass sich Inhaltsverfasser auf Stilmechanismen wie
CSS verlassen, um das Formatierungsmodell f r ihren Inhalt zu definieren. Wenn Benutzerpro-
gramme den Stilmechanismus unterst tzen, werden Dokumente wie erwartet formatiert.
Wenn Benutzerprogramme den Stilmechanismus nicht unterst tzen, werden Dokumente so
formatiert, wie es f r dieses Benutzerprogramm angemessen ist. Dies erlaubt Benutzerpro-
grammen f r die XHTML-Familie komplexe Formatierungsmodelle auf solchen Ger@ten zu
unterst tzen, wo es angemessen ist, und einfache Formatierungsmodelle auf solchen Ger@ten,
wo dies angemessen ist.
2 Begriffe und Definitionen
Dieser Abschnitt ist informell.
W@hrend einige Begriffe an der Stelle ihres Auftretens definiert werden, werden die folgenden
Definitionen im gesamten Dokument benutzt. Die Kenntnis der XML 1.0-Empfehlung [XML]
wird sehr empfohlen.
Abstraktes Modul (abstract module)
Eine Einheit einer Dokumenttyp-Spezifikation korrespondierend mit einer bestimmten Art von
Inhalt, korrespondierend mit einem Markup-Konstrukt, die diese bestimmte Art widerspiegelt.
Dokumentmodell (document model)
Die tats@chliche Struktur und Beschr@nkungen eines gegebenen Dokumenttyps. Das Doku-
mentmodell konstituiert die abstrakte Darstellung einer physischen oder semantischen
Struktur einer Klasse von Dokumenten.
Dokumenttyp (document type)
Eine Klasse von Dokumenttypen mit einer gemeinsamen abstrakten Struktur. Die Defini-
tion in ISO 8879 [SGML] lautet wie folgt: „Eine Klasse von Dokumenten mit @hnlichen Cha-
rakteristiken; zum Beispiel ein Journal, ein Artikel, ein technisches Handbuch oder eine
Notiz. (4.102)“
< 394 > Begriffe und Definitionen
Page size: 168,00 x 240,00 mm
Dokumenttyp-Definition (document type definition, DTD)
Eine formale, maschinenlesbare Beschreibung der XML-Struktur und -Syntaxregeln, zu
denen eine Dokumentinstanz eines bestimmten Dokumenttyps konform sein muss; der
Schematyp, der in XML 1.0 verwendet wird, um Konformit@t einer Dokumentinstanz zu
seinem deklarierten Dokumenttyp zu validieren. Ein und dasselbe Markup-Modell kann
durch eine Vielzahl von DTDs ausgedr ckt werden.
Element (element)
Eine Instanz eines Elementtyps.
Elementtyp (element type)
Die Definition eines Elements, das heißt eines Containers f r eine bestimmte semantische
Klasse von Dokumentinhalt.
Eltern-Dokumenttyp (parent document type)
Ein Eltern-Dokumenttyp eines hybriden Dokuments ist der Dokumenttyp des Wurzelele-
ments.
Modularisierung von XHTML
Entity (entity)
Ein Entity ist eine logische oder physische Speicherungseinheit, die Dokumentinhalt enth@lt.
Entities k=nnen aus analysierbarem (parse-able) XML-Markup oder Zeichendaten bestehen
oder aus nicht analysierbarem Inhalt (das heißt, nicht XML, m=glicherweise nicht textuell).
Entity-Inhalt kann entweder vollst@ndig innerhalb des Dokument-Entity definiert sein („in-
terne Entities“) oder zum Dokument-Entity extern vorliegen („externe Entities“). In ana-
lysierten Entities darf der Ersetzungstext Referenzen auf andere Entities enthalten.
Entity-Referenz (entity reference)
Eine mnemonische Zeichenkette („Eselsbr cke“), die als Referenz auf den Inhalt eines dekla-
rierten Entity benutzt wird (zum Beispiel „&“ f r „&“, „<“ f r „<“, „©“ f r „*“).
Generic Identifier (generic identifier; artm.ßiger Bezeichner)
Der Name, der den Elementtyp eines Elements bezeichnet; auch Elementtypname.
hybrides Dokument (hybrid document)
Ein hybrides Dokument ist eines, das mehr als einen XML-Namensraum benutzt. Hybride
Dokumente k=nnen als Dokumente definiert werden, die Elemente oder Attribute von
hybriden Dokumenttypen enthalten.
Inhaltsmodell (content model)
Die deklarierte Markup-Struktur, die in Instanzen eines Elementtyps erlaubt ist. XML 1.0
unterscheidet zwei Typen: Elemente, die nur Elementinhalt enthalten (keine Zeichendaten)
und solche mit gemischtem Inhalt (mixed content; Elemente, die Zeichendaten, optional
durch Kindelemente getrennt, enthalten d rfen). Letztere sind durch eine Inhaltsspezifika-
tion charakterisiert, die mit „#PCDATA“ beginnt (was f r Zeichendaten steht).
Instanziieren (instantiate)
Eine Entity-Referenz durch eine Instanz ihres deklarierten Inhalts ersetzen.
Markup-Deklaration (markup declaration)
Ein syntaktisches Konstrukt innerhalb einer DTD, das ein Entity deklariert oder eine Mark-
up-Struktur definiert. Innerhalb von XML-DTDs gibt es vier bestimmte Typen: Eine Entity-
Deklaration verbindet ein mnemonisches Symbol mit seinem Ersetzungsinhalt; eine Ele-
mentdeklaration beschr@nkt, welche Elementtypen als Kinder innerhalb eines Elements vor-
kommen d rfen (siehe auch Inhaltsmodell); eine Attributlisten-Deklaration definiert die
Menge von Attributen f r einen gegebenen Elementtyp und kann außerdem Typbeschr@n-
Begriffe und Definitionen < 395 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
kungen auferlegen und Vorgabewerte festlegen; Notationsdeklarationen definieren eine
Verbindung zwischen einem Notationsnamen und einem externen Bezeichner, der das For-
mat f r ein nicht analysiertes Entity benennt.
Markup-Modell (markup model)
Das Markup-Vokabular (das heißt, die Palette von Element- und Attributnamen, Notationen
und so weiter) und -Grammatik (das heißt die vorgeschriebene Verwendung jenes Vokabu-
lars) gem@ß Definition durch eine Dokumenttyp-Definition (das heißt, ein Schema). Das
Markup-Modell ist die konkrete Darstellung, ausgedr ckt in Markup-Syntax, des Doku-
mentmodells und kann mit unterschiedlichen Stufen strikter Konformit@t definiert werden.
Dasselbe Dokumentmodell kann durch eine Vielzahl von Markup-Modellen ausgedr ckt
werden.
Modul (module)
Eine abstrakte Einheit innerhalb eines Dokumentmodells, ausgedr ckt durch ein DTD-Frag-
ment, die verwendet wird, um Markup-Deklarationen zu konsolidieren, die Flexibilit@t,
Modularisierung von XHTML
Onderbarkeit, Wiederverwendbarkeit und Verst@ndnis bestimmter logische und semanti-
scher Strukturen verbessern.
Modularisierung (modularization)
Eine Implementierung eines Modularisierungsmodells; der Vorgang des Zusammenf gens
oder Auseinandernehmens einer DTD, indem deren Markup-Deklarationen in Einheiten
oder Gruppen angeordnet werden. Module k=nnen als getrennte Datei-Entities vorliegen
(das heißt, die physische und logische Struktur einer DTD k=nnen einander entsprechen;
dies muss aber nicht so sein).
Modularisierungmodell (modularization model)
Der abstrakte Entwurf einer Dokumenttyp-Definition (DTD) mit Unterst tzung der Mo-
dularisierungsziele, wie etwa Wiederverwendbarkeit, Ausdrucksst@rke, einfache Doku-
mentierbarkeit, Code-Gr=ße, Konsistenz und intuitive Benutzbarkeit. Es ist wichtig
festzustellen, dass ein Modularisierungsmodell orthogonal (unabh@ngig) bez glich des
Dokumentmodells ist, das es beschreibt. Folglich k=nnen zwei sehr verschiedene Modulari-
sierungsmodelle den selben Dokumenttyp beschreiben.
Parameter-Entity (parameter entity)
Ein Entity, dessen G ltigkeitsbereich innerhalb des Dokumentprologs (das heißt, externe
und interne Teilmenge der DTD) liegt. Parameter-Entities sind innerhalb der Dokument-
instanz nicht erlaubt.
Tag (tag; Schildchen, Etikett)
Beschreibende Auszeichnungen, die den Start und das Ende (inklusive des Generic Identifier
und aller Attribute) eines Elements begrenzen.
Treiber (driver)
Eine blicherweise kurze Datei, die die Module einer DTD deklariert und instanziiert. Als
gute Faustregel gilt, dass ein DTD-Treiber keine Markup-Deklarationen enth@lt, die irgend-
einen Teil des eigentlichen Dokumentmodells umfassen.
< 396 > Begriffe und Definitionen
Page size: 168,00 x 240,00 mm
3 Definition der Konformit.t
Dieser Abschnitt ist normativ.
Um sicherzustellen, dass Dokumente der XHTML-Familie zwischen Benutzerprogrammen der
XHTML-Familie maximal austauschbar sind, definiert diese Spezifikation die Anforderungen
sowohl an diese beiden als auch an Dokumenttypen der XHTML-Familie sehr streng. W@hrend
die Konformit@tsdefinitionen in diesem Abschnitt zu finden sind, verweisen sie notwendiger-
weise auf normativen Text innerhalb dieser Spezifikation, innerhalb der Basisspezifikation f r
XHTML [XHTML1] und innerhalb anderer verwandter Spezifikationen. Nur das vollst@ndige
Lesen aller normativer Referenzen erm=glicht ein volles Verst@ndnis der Konformit@tsanforde-
rungen an XHTML.
Die Schl sselworte „MUSS“ („MUST“), „DARF NICHT“ („MUST NOT“), „NOTWENDIG“
(„REQUIRED“), „SOLL“ („SHALL“), „SOLL NICHT“ („SHALL NOT“), „SOLLTE“
(„SHOULD“), „EMPFOHLEN“ („RECOMMENDED“), „DARF“ („MAY“) und „OPTIONAL“
Modularisierung von XHTML
(„OPTIONAL“) in diesem Dokument sind, wie in [RFC2119] beschrieben, zu verstehen.
3.1 Konformit.t eines Dokumenttyps als
XHTML Host Language
Es ist m=glich, vorhandene Dokumenttypen zu ver@ndern oder v=llig neue zu definieren, die
die beiden in dieser Spezifikation definierten Module und weitere Module benutzen. Ein solcher
Dokumenttyp ist eine „konforme XHTML Host Language“, wenn er die folgenden Kriterien
erf llt:
1. Der Dokumenttyp muss unter Verwendung einer durch das W3C definierten Implementie-
rungsmethode definiert sein. Momentan ist dies auf XML-DTDs beschr@nkt, aber XML-
Schema wird bald verf gbar sein. Der Rest dieses Abschnitts verweist auf „DTDs“, auch
wenn andere Implementierungen m=glich sind.
2. Die DTD, die den Dokumenttyp definiert, muss einen eindeutigen Bezeichner gem@ß Defi-
nition in Abschnitt 3.6 (Namensregeln) haben, der die Zeichenkette „XHTML“ im ersten
Token seines Public Text Identifiers tr@gt.
3. Die DTD, die den Dokumenttyp definiert, muss mindestens die in dieser Spezifikation defi-
nierten Module Struktur, Hypertext, Text und Listen enthalten.
4. Von jedem der W3C-definierten Module, die enthalten sind, m ssen alle Elemente, Attribu-
te, Attributtypen (inklusive aller notwendigen Aufz@hlungswerte) und muss jedes minimale
Inhaltsmodell ins Inhaltsmodell des Dokumenttyps bernommen (und optional erweitert)
werden. Falls Inhaltsmodelle erweitert werden, m ssen alle Elemente und Attribute, die im
urspr nglichen Inhaltsmodell als notwendig gekennzeichnet sind (zusammen mit ihren
Typen und allen Aufz@hlungswerten, die als notwendig gekennzeichnet sind), auch weiterhin
als notwendig gekennzeichnet sein.
5. Die DTD, die den Dokumenttyp definiert, darf zus@tzliche Elemente und Attribute definie-
ren. Diese m ssen sich in ihrem eigenen Namensraum [XMLNAMES] befinden.
Definition der Konformit,t < 397 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
3.2 Konformit.t eines Dokumenttyps als XHTML
Integration Set
Es ist auch m=glich, Dokumenttypen zu definieren, die auf XHTML basieren, sich aber nicht an
deren Struktur halten. Solch ein Dokumenttyp ist „konform als XHTML Integration Set“, wenn
er die folgenden Kriterien erf llt:
1. Der Dokumenttyp muss unter Verwendung einer durch das W3C definierten Implementie-
rungsmethode definiert sein. Momentan ist dies auf XML-DTDs beschr@nkt, aber XML-
Schema wird bald verf gbar sein. Der Rest dieses Abschnitts verweist auf „DTDs“, auch
wenn andere Implementierungen m=glich sind.
2. Die DTD, die den Dokumenttyp definiert, muss einen eindeutigen Bezeichner gem@ß Defi-
nition in Abschnitt 3.6 (Namensregeln) haben, der NICHT die Zeichenkette „XHTML“ im
ersten Token seines Public Text Identifiers tr@gt.
3. Die DTD, die den Dokumenttyp definiert, muss mindestens die in dieser Spezifikation defi-
Modularisierung von XHTML
nierten Module Hypertext, Text und Listen enthalten.
4. Von jedem der W3C-definierten Module, die enthalten sind, m ssen alle Elemente, Attribu-
te, Attributtypen (inklusive aller notwendigen Aufz@hlungswerte) und muss jedes minimale
Inhaltsmodell ins Inhaltsmodell des Dokumenttyps bernommen (und optional erweitert)
werden. Falls Inhaltsmodelle erweitert werden, m ssen alle Elemente und Attribute, die im
urspr nglichen Inhaltsmodell als notwendig gekennzeichnet sind (zusammen mit ihren
Typen und allen Aufz@hlungswerten, die als notwendig gekennzeichnet sind), auch weiterhin
als notwendig gekennzeichnet sein.
5. Die DTD, die den Dokumenttyp definiert, darf zus@tzliche Elemente und Attribute definie-
ren. Diese m ssen sich in ihrem eigenen Namensraum [XMLNAMES] befinden.
3.3 Konformit.t eines Moduls zur XHTML-Familie
Diese Spezifikation definiert eine Methode zur Definition von XHTML-konformen Modulen.
Ein Modul ist konform zu dieser Spezifikation, wenn es die folgenden Kriterien erf llt:
1. Der Dokumenttyp muss unter Verwendung einer durch das W3C definierten Implementie-
rungsmethode definiert sein. Momentan ist dies auf XML-DTDs beschr@nkt, aber XML-
Schema wird bald verf gbar sein. Der Rest dieses Abschnitts verweist auf „DTDs“, auch
wenn andere Implementierungen m=glich sind.
2. Die DTD, die den Dokumenttyp definiert, muss einen eindeutigen Bezeichner gem@ß Defi-
nition in Abschnitt 3.6 (Namensregeln) haben.
3. Falls das Modul unter Verwendung einer XML-DTD definiert ist, muss das Modul seine
Paramter-Entity-Namen durch Benutzung von eindeutigen Pr@fixen o.@. isolieren.
4. Die Moduldefinition muss eine Definition in Klartext haben, die die syntaktischen und
semantischen Anforderungen von Elementen, Attributen und/oder Inhaltsmodellen, die sie
deklariert, beschreibt.
5. Die Moduldefinition darf keine Elementnamen wiederverwenden, die in anderen W3C-defi-
nierten Modulen definiert werden. Ausgenommen sind die F@lle, in denen das Inhaltsmodell
und die Bedeutungen solcher Elemente entweder identisch zum Original oder eine Erweite-
rung des Originals sind oder in denen sich der wiederverwendete Elementname innerhalb
seines eigenen Namensraums befindet (siehe unten).
< 398 > Definition der Konformit,t
Page size: 168,00 x 240,00 mm
6. Die Elemente und Attribute der Moduldefinition m ssen Teil eines XML-Namensraums
sein [XMLNAMES]. Falls das Modul durch eine andere Organisation als W3C definiert
wird, darf der Namensraum NICHT derselbe sein wie der Namensraum, in dem andere
W3C-Module definiert werden.
3.4 Konformit.t eines Dokuments zur XHTML-Familie
Ein zur XHTML-Familie konformes Dokument ist eine g ltige Instanz eines konformen XHTML
Host Language-Dokumenttyps.
3.5 Konformit.t eines Benutzerprogramms zur
XHTML-Familie
Modularisierung von XHTML
Ein konformes Benutzerprogramm muss alle folgenden Kriterien erf llen (gem@ß Definition in
[XHTML1]):
1. Um konsistent mit der XML 1.0-Empfehlung [XML] zu sein, muss das Benutzerprogramm
ein XHTML-Dokument parsen und auf Wohlgeformtheit hin auswerten. Falls das Benutzer-
programm behauptet, ein validierendes Benutzerprogramm zu sein, muss es das Dokument
gegen die angegebene DTD gem@ß [XML] validieren.
2. Falls das Benutzerprogramm behauptet, Eigenschaften zu unterst tzen, die innerhalb dieser
Spezifikation definiert sind oder die von dieser Spezifikation durch normative Verweise
ben=tigt werden, so muss es sich konsistent mit der Definition der Eigenschaften verhalten.
3. Falls ein Benutzerprogramm ein XHTML-Dokument als allgemeines [XML] verarbeitet, so
soll es ausschließlich Attribute des Typs ID (das heißt, bei den meisten XHTML-Elementen
das id-Attribut) als Fragmentbezeichner anerkennen.
4. Falls ein Benutzerprgramm auf ein Element trifft, das es nicht kennt, so muss es mit der Ver-
arbeitung der Kinder des Elements fortfahren. Falls der Inhalt aus Text besteht, so muss
dem Benutzer jener Text dargestellt werden.
5. Falls ein Benutzerprogramm auf ein Attribut trifft, das es nicht kennt, so muss es die
gesamte Attributangabe (das heißt, das Attribut und seinen Wert) ignorieren.
6. Fall das Benutzerprogramm auf einen Attributwert trifft, den es nicht kennt, so muss es den
Vorgabewert benutzen.
7. Falls es eine Entity-Referenz (eine andere als die vordefinierten Entities) antrifft, f r die das
Benutzerprogramm keine Deklaration verarbeitet hat (was passieren kann, wenn sich die
Deklaration in der externen Teilmenge, die das Benutzerprogramm nicht gelesen hat, befin-
det), so sollte die gesamte Entity-Referenz als Folge der Zeichen ausgegeben werden, die
die Entity-Referenz bilden (angefangen beim et-Zeichen bis zum Semikolon einschließlich).
8. Falls Benutzerprogramme bei der Darstellung von Inhalt auf Zeichen oder Zeichen-Entity-
Referenzen treffen, die erkannt werden, aber nicht darstellbar sind, sollten sie das Doku-
ment in einer Weise ausgeben, die es f r den Benutzer offensichtlich macht, dass die nor-
male Ausgabe nicht durchgef hrt werden konnte.
9. Leerraum wird gem@ß den nachfolgenden Regeln behandelt. Die folgenden Zeichen werden
in [XML] als Leeraumzeichen definiert:
·· Leerzeichen (SPACE,  )
Horizontaler Tabulator (HORIZONTAL TABULATION, 	)
Konformit,t eines Dokuments zur XHTML-Familie < 399 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
·· Wagenr cklauf (CARRIAGE RETURN, 
)
Zeilenvorschub (LINE FEED, 
)
Der XML-Prozessor normalisiert die Zeilenendekodierung von unterschiedlichen System
zu einem einzigen Zeilenvorschubzeichen, welches an die Anwendung weitergegeben wird.
Das Benutzerprogramm muss Leerraumzeichen, die in den vom XML-Prozessor erhaltenen
Daten vorkommen, wie folgt verarbeiten:
·· Leeraum, der Blockelemente umgibt, sollte entfernt werden.
Kommentare werden vollst@ndig entfernt und ber hren die Leeraumbehandlung nicht.
Zwei Leeraumzeichen beiderseits eines Kommentars (je eines vor und eines hinter
einem Kommentar) werden als zwei Leerraumzeichen behandelt.
· Falls das 'xml:space'-Attribut auf 'preserve' gesetzt ist, m ssen Leerraumzeichen erhalten
bleiben, und folglich d rfen Zeilenvorschubzeichen innerhalb eines Blocks nicht umge-
wandelt werden.
·· Falls das 'xml:space'-Attribut nicht auf 'preserve' gesetzt ist, dann:
Modularisierung von XHTML
F hrender und abschließender Leeraum innerhalb eines Blockelements muss ent-
fernt werden.
· Zeilenvorschubzeichen m ssen in eines der folgenden Zeichen umgewandelt wer-
den: ein Leerzeichen, ein Leerzeichen mit Breite Null (ZERO WIDTH SPACE cha-
racter, ​) oder kein Zeichen (das heißt entfernt). Die Wahl des resultieren-
den Zeichens ist abh@ngig vom Benutzerprogramm und wird bedingt durch die
Schrift-Eigenschaft (script) der dem Zeilenvorschub vorausgehenden und nachfol-
genden Zeichen.
· Eine Folge von Leerraumzeichen ohne ein Zeilenvorschubzeichen muss auf ein ein-
zelnes Leerzeichen reduziert werden.
· Eine Folge von Leerraumzeichen mit einem oder mehreren Zeilenvorschubzeichen
muss in gleicher Weise auf ein einzelnes Zeilenvorschubzeichen reduziert werden.
Leeraum in Attributwerten wird gem@ß [XML] verarbeitet.
Anmerkung (informell): Bei der Bestimmung, wie ein Zeilenvorschubzeichen umzuwandeln
ist, sollte ein Benutzerprogramm die folgenden F,lle bercksichtigen, wobei die Schrift-Eigenschaft
(script) der Zeichen beiderseits des Zeilenvorschubs die Wahl der Ersetzung bestimmt. Zeichen
der Allgemeinen Schrift (COMMON script) wie Interpunktion werden als gleiche Schrift wie auf der
anderen Seite behandelt. n
1. Falls die Zeichen vor und nach dem Zeilenvorschubzeichen zu einer Schrift geh=ren, in
welcher das Leerzeichen als Worttrenner eingesetzt wird, so sollte das Zeilenvor-
schubzeichen in ein Leerzeichen umgewandelt werden. Beispiele solcher Schriften sind
Lateinisch, Griechisch und Kyrillisch.
2. Falls die Zeichen vor und nach dem Zeilenvorschubzeichen zu einer ideographischen
Schrift oder Schreibsystem geh=ren, in der oder in dem es keinen Worttrenner gibt,
sollte der Zeilenvorschub in kein Zeichen (das heißt entfernt) werden. Beispiele solcher
Schriften oder Schreibsysteme sind Chinesisch oder Japanisch.
Anmerkung der bersetzer: Ein Ideogramm ist „ein Schriftzeichen, das einen gan-
zen Begriff darstellt“. (Quelle: Duden-Fremdw=rterbuch, Bibliographisches Institut 1982).
< 400 > Definition der Konformit,t
Page size: 168,00 x 240,00 mm
3. Falls die Zeichen vor und hinter dem Zeilenvorschubzeichen zu einer nicht ideographi-
schen Schrift geh=ren, in der es keinen Worttrenner gibt, sollte der Zeilenvorschub in
ein Leerzeichen mit Breite Null (ZERO WIDTH SPACE character, ​) oder kein
Zeichen gewandelt werden. Beispiele solcher Schriften sind Thai und Khmer.
4. Falls keine der Bedingungen (1) bis (3) zutreffen, so sollte das Zeilenvorschubzeichen in
ein Leerzeichen umgewandelt werden.
Der Unicode [UNICODE] technical report TR#24 (Script Names) stellt eine Zuweisung
von Schriftnamen zu allen Zeichen zur Verf gung.
3.6 Namensregeln
Dokumenttypen, die eine XHTML Host Language darstellen, m ssen sich an strenge Namens-
konventionen halten, so dass es f r Software und Anwender leicht ist, die Verwandtschaft von
Modularisierung von XHTML
Dokumenttypen mit XHTML zu erkennen. Die Namen von Dokumenttypen, die als XML-Do-
kumenttyp-Definitionen implementiert sind, sind durch Formal Public Identifiers (FPIs) defi-
niert. Innerhalb von FPIs werden Felder durch doppelte Schr@gstriche voneinander getrennt
(//). Die verschiedenen Felder m ssen wie folgt zusammengesetzt werden:
1. Das f hrende Fehld muss „-“ sein, um eine privat definierte Ressource anzuzeigen.
Anmerkung der bersetzer: Das Gegenteil einer privat definierten Ressource ist
eine, deren Organisationsk rzel (siehe n@chstes Feld) bei der ISO registriert ist. Solche
FPIs beginnen mit „+“. Selbst das W3C verwendet „-“ und auch schon vor Gr ndung
des W3C war es in der SGML-Gemeinde blich, „-“ zu verwenden. Die Registrierung,
so sie denn berhaupt m=glich ist, hat sich nie durchgesetzt. Heute treten an die Stelle
mehr und mehr Bezeichner, die wie URIs aussehen (etwa Namensraumbezeichner). Sie
enthalten einen Domainnamen, der der Domainregistrierung unterliegt und damit welt-
weit eindeutig ist.
2. Das zweite Feld muss den Namen der Organisation enthalten, die f r die Pflege des
benannten Objekts verantwortlich ist. Es gibt keine formale Registrierung f r diese Organi-
sationsnamen. Jede Organisation sollte einen eindeutigen Namen definieren. Der Namen
der beispielsweise vom W3C verwendet wird, ist W3C.
3. Das dritte Feld enth@lt zwei Dinge: die Klasse des Sffentlichen Texts (public text class),
gefolgt von der Beschreibung des Sffentlichen Texts (public text description). Das erste
Token im dritten Feld ist die Klasse des Sffentlichen Texts, die sich an „ISO 8879 Clause
[Link] Public Text Class“ halten sollte. Nur Dokumente, die konform zur XHTML Host
Language sind, sollten die Beschreibung des Sffentlichen Texts mit dem Token XHTML
beginnen. Die Beschreibung des Sffentlichen Texts sollte die Zeichenkette XHTML bein-
halten, wenn der Dokumenttyp konform als Integration Set ist. Das Feld muss außerdem
einen durch die Organisation definierten, eindeutigen Bezeichner (zum Beispiel MyML 1.0)
enthalten. Dieser Bezeichner sollte aus einem eindeutigen Namen und einem Ver-
sionsbezeichner zusammengesetzt sein, der aktualisiert wird, wenn sich das Dokument wei-
terentwickelt.
4. Das vierte Feld definiert die Sprache, in der das Objekt entwickelt wurde (zum Beispiel DE).
Namensregeln < 401 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Unter Verwendung dieser Regeln kann ein Name f r einen konformen XHTML Host Language-
Dokumenttypen -//MyCompany//DTD XHTML MyML 1.0//EN sein. Der Name f r ein zur XHTML-Fa-
milie konformes Modul kann -//MyCompany//ELEMENTS XHTML MyElements 1.0//EN lauten. Der
Name f r einen als XHTML Integration Set konformen Dokumenttypen kann -//MyCompany//
DTD Special Markup with XHTML//EN sein.
3.7 Evolution von XHTML-Modulen
Jedem in dieser Spezifikation definierten Modul ist ein eindeutiger Bezeichner gegeben, der den
Namensregeln des vorhergehenden Abschnitts folgt. Mit der Zeit kann sich ein Modul ent-
wickeln. Eine logische Folge einer solchen Entwicklung kann sein, dass einige Aspekte des
Moduls mit ihrer vorhergehenden Definition nicht mehr kompatibel sind. Um sicherzustellen,
dass Dokumenttypen, die in Bezug auf Module, die in dieser Spezifikation definiert werden, wei-
terhin funktionieren, werden die Bezeichner von ge@nderten Modulen aktualisiert. Insbeson-
Modularisierung von XHTML
dere die Formal Public Identifier und System Identifier des Moduls werden sich @ndern, indem
der Versions-Bezeichner in jedem Modul ge@ndert wird. Dokumenttypen, die den aktualisier-
ten Funktionsumfang einbeziehen m=chten, werden in @hnlicher Weise aktualisiert werden
m ssen.
Zus@tzlich werden die fr heren Versionen des Moduls auch weiterhin ber ihre fr heren, ein-
deutigen Bezeichner zug@nglich sein. Auf diese Weise werden Dokumenttypen, die unter Ver-
wendung von XHTML-Modulen entwickelt wurden, unter Benutzung ihrer urspr nglichen
Definitionen nahtlos weiterfunktionieren, selbst wenn sich die Sammlung von Modulen vergr=-
ßert und entwickelt. Ebenso werden Dokumentinstanzen, die bzgl. eines Dokumenttyps
geschrieben sind, unter Verwendung der fr heren Moduldefinitionen auch weiterhin g ltig sein.
Autoren von Modulen und Dokumenttypen der XHTML-Familie sind aufgerufen, eine @hnliche
Strategie anzuwenden, um das zuk nftige Funktionieren von Dokumenttypen, die auf solchen
Modulen basieren, und von Dokumentinstanzen, die auf solchen Dokumenttypen basieren, zu
gew@hrleisten.
4 Definition abstrakter Module
Dieser Abschnitt ist normativ.
Ein abstraktes Modul ist eine Definition eines XHTML-Moduls, die Klartext und einige infor-
melle Markup-Konventionen enth@lt. W@hrend eine solche Definition im Allgemeinen nicht
besonders hilfreich bei der maschinellen Verarbeitung von Dokumenttypen ist, ist sie eine
wichtige Hilfe, damit Menschen verstehen, was in einem Modul enthalten ist. Dieser Abschnitt
definiert, wie abstrakte XHTML-Module definiert sind. Es ist nicht notwendig, dass ein XHTML-
konformes Modul eine abstrakte Moduldefinition zur Verf gung stellt. Dennoch ist jeder, der
ein XHTML-Modul entwickelt, aufgerufen, eine Abstraktion zur Verf gung zu stellen, um die
Benutzung des Moduls zu vereinfachen.
< 402 > Definition abstrakter Module
Page size: 168,00 x 240,00 mm
4.1 Syntaktische Konventionen
Die abstrakten Module sind nicht in einer formalen Grammatik definiert. Dennoch halten sich
die Definitionen an die folgenden syntaktischen Konventionen. Diese Konventionen sind denen
in XML-DTDs @hnlich und sollten jedem Autor von XML-DTDs vertraut sein. Jedes einzelne
syntaktische Element kann mit anderen kombiniert werden, um einen komplexeren Ausdruck
zu bilden, der zur hier definierten Algebra konform ist.
Elementname (element name)
Wenn ein Element in einem Inhaltsmodell enthalten ist, wird sein expliziter Name auf-
gef hrt.
Inhaltsmenge (content set)
Einige Module definieren Listen expliziter Elementnamen, genannt Inhaltsmengen. Wenn
eine Inhaltsmenge in einem Inhaltsmodell enthalten ist, wird ihr expliziter Name aufgef hrt.
Modularisierung von XHTML
expr ?
Null oder eine Instanz von expr ist erlaubt.
expr +
Eine oder mehrere Instanzen von expr werden verlangt.
expr *
Null oder mehrere Instanzen von expr sind erlaubt.
a,b
Ausdruck a wird verlangt, gefolgt von Ausdruck b.
a|b
Entweder a oder b sind notwendig.
a-b
Ausdruck a ist erlaubt, ohne Elemente aus b.
Klammern
Wenn ein Ausdruck in Klammern steht, wird die Auswertung von irgendwelchen Unteraus-
dr cken innerhalb der Klammern zuerst durchgef hrt, bevor die Auswertung von Ausdr -
cken außerhalb der Klammern beginnt (beginnend mit der tiefsten Verschachtelungsebene).
Erweitern vordefinierter Elemente
In einigen F@llen f gt ein Modul Attribute einem Element hinzu. In diesen F@llen folgt dem
Elementnamen ein et-Zeichen (&).
Definieren von notwendigen Attributen
Wenn ein Element die Definition eines Attributs verlangt, folgt dem Attributnamen ein
Stern (*).
Definieren des Typs von Attributwerten
Wenn ein Modul den Typ eines Attributwertes definiert, geschieht dies durch Auff hren
des Typs in Klammern hinter dem Attributnamen.
Definieren der erlaubten Werte von Attributen
Wenn ein Modul die f r ein Attribut erlaubten Werte definiert, geschieht dies durch expli-
zites Auff hren der erlaubten Werte (eingeschlossen in Anf hrungszeichen), getrennt
durch vertikale Striche (|), eingeschlossen in Klammern hinter dem Attributnamen. Falls
das Attribut einen Vorgabewert hat, folgt diesem Wert ein Stern (*). Falls das Attribut
einen festen Wert hat, folgt dem Attributnamen ein Gleichheitszeichen (=) und der in
Anf hrungszeichen eingeschlossene feste Wert.
Syntaktische Konventionen < 403 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
4.2 Inhaltstypen
Die Definitionen abstrakter Module definieren minimale, atomare Inhaltsmodelle f r jedes
Modul. Diese minimalen Inhaltsmodelle referenzieren die Elemente im selben Modul. Die k=n-
nen außerdem Elemente in anderen Modulen, auf denen dieses abstrakte Modul aufbaut, refe-
renzieren. Schließlich erfordert das Inhaltsmodell in vielen F@llen, dass Text als Inhalt von einem
oder mehreren Elementen zugelassen ist. In diesen F@llen wird PCDATA als Symbol f r Text
benutzt. Dies ist ein Ausdruck, definiert in der XML 1.0-Empfehlung, der f r „Processed Cha-
racter Data“ steht. Ein Inhaltstyp kann auch als EMPTY definiert werden, was bedeutet, dass
das Element in seinem minimalen Inhaltsmodell keinen Inhalt hat.
Anmerkung der bersetzer: Tats@chlich wird PCDATA in XML 1.0 nicht defi-
niert, was nach meinem Verst@ndnis ein Vers@umnis ist. Eine entsprechende Mail an die
Herausgeber von XML wurde in dem Sinne beantwortet, dass eine Definition in XML
Modularisierung von XHTML
nicht notwendig sei.
Damit kann als Referenz f r diese Abk rzung nur SGML genannt werden. PCDATA
bedeutet demnach nicht „Processed Character Data“, sondern „Parsed Character
Data“.
4.3 Attributtypen
In einigen F@llen ist es notwendig, die Typen der Attributwerte zu definieren beziehungsweise
die Menge der erlaubten Werte explizit vorzugeben. Die folgenden Attributtypen (definiert in
der XML 1.0-Empfehlung) werden in den Definitionen der abstrakten Module verwendet:
Attributtypen Definition
CDATA Zeichendaten (Character data)
ID Ein dokumentweit eindeutiger Bezeichner
IDREF Eine Referenz auf einen dokumentweit eindeutigen Bezeichner
IDREFS Eine Leerzeichen-getrennte Liste von Referenzen auf dokumentweit
eindeutige Bezeichner
NAME Ein Name mit denselben Zeichenbeschr@nkungen wie ID
NMTOKEN Ein Name, der nur aus Name Tokens gem@ß Definition in XML 1.0 [XML]
besteht
NMTOKENS Ein oder mehrere, durch Leerzeichen getrennte NMTOKEN-Werte
PCDATA Processed character data
Anmerkung der bersetzer: Bez glich PCDATA siehe die Bemerkung im vor-
hergehenden Abschnitt
< 404 > Definition abstrakter Module
Page size: 168,00 x 240,00 mm
Zus@tzlich zu diesen vordefinierten Datentypen definiert „Modularisierung von XHTML“ die
folgenden Datentypen und ihre Semantiken (soweit sinnvoll):
Datentyp Beschreibung
Zeichen (Character) Ein einzelnes Zeichen aus [ISO10646].
Zeichensatz (Charset) Eine Zeichenkodierung gem@ß [RFC2045].
Zeichens@tze (Charsets) Eine durch Leerzeichen getrennte Liste von Zeichen-
kodierungen gem@ß [RFC2045].
Farbe (Color) Der Attributwerttyp „Farbe“ bezieht sich auf Farb-
definitionen gem@ß [SRGB]. Ein Farbwert darf entweder
eine hexadezimale Zahl (eingeleitet durch ein Doppel-
kreuz) oder einer der folgenden 16 Farbnamen sein. Die
Farbnamen sind unabh@ngig von Groß/Kleinschreibung.
Modularisierung von XHTML
Farbnamen und sRGB-Werte
Black = Green =
"#000000" "#008000"
Silver = Lime =
"#C0C0C0" "#00FF00"
Gray = Olive =
"#808080" "#808000"
White = Yellow =
"#FFFFFF" "#FFFF00"
Maroon = Navy =
"#800000" "#000080"
Red = Blue =
"#FF0000" "#0000FF"
Purple = Teal =
"#800080" "#008080"
Fuchsia = Aqua =
"#FF00FF" "#00FFFF"
Also bezeichnen der Farbwert „#800080“ und „Purple“
beide die Farbe Violett.
Inhaltstyp (ContentType) Ein Medientyp gem@ß [RFC2045].
Attributtypen < 405 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Inhaltstypen (ContentTypes) Eine Komma-separierte Liste von Medientypen gem@ß
[RFC2045].
Koordinaten (Coords) Eine Komma-separierte Liste von Koordinaten zur Defi-
nition von Gebieten.
Datum/Zeit (Datetime) Information ber Datum und Zeit.
FPI Eine Zeichenkette, die einen „SGML Formal Public Iden-
tifier“ darstellt.
FrameTarget Ein Frame-Name, der als Ziel des Ergebnisses bestimm-
ter Aktionen dient.
Sprach-Code Ein Sprach-Code gem@ß [RFC3066].
(LanguageCode)
L@nge (Length) Der Wert darf entweder in Pixeln oder als Prozent-
Modularisierung von XHTML
angabe bez glich des verf gbaren horizontalen oder ver-
tikalen Raums angegeben werden. Also bedeutet der
Wert „50%“ die H@lfte des verf gbaren Platzes.
Link-Typen (LinkTypes)
Autoren k=nnen die folgenden Link-Typen verwenden, die hier mit ihrer blichen Interpretation
aufgef hrt sind. Ein Link-Typ-Wert verweist auf eine Leerzeichen-getrennte Liste von Link-Ty-
pen. Leeraumzeichen sind innerhalb von Link-Typen nicht erlaubt. Diese Link-Typen sind von
Groß/Kleinschreibung unabh@ngig, das heißt, „Alternate“ hat dieselbe Bedeutung wie „alternate“.
Benutzerprogramme, Suchmaschinen usw k=nnen diese Link-Typen auf sehr unterschiedliche
Arten interpretieren. Zum Beispiel k=nnen Benutzerprogramme den Zugriff auf verlinkte
Dokumente ber eine Navigationsleiste erlauben.
Alternate
Bestimmt alternative Versionen des Dokuments, in dem der Link auftritt. Wenn es zusam-
men mit dem hreflang-Attribut benutzt wird, impliziert es eine bersetzte Version des
Dokuments. Wenn es zusammen mit dem media-Attribut benutzt wird, impliziert es eine
Version, die f r ein anderes Medium (oder Medien) bestimmt ist.
Stylesheet
Verweist auf ein externes Stylesheet. Siehe Abschnitt 5.17 (Stylesheet-Modul) f r Details.
Dies wird zusammen mit dem Link-Typ „Alternate“ verwendet, um dem Benutzer die Aus-
wahl zwischen verschiedenen Stylesheets zu erlauben.
Start
Verweist auf das erste Dokument einer Sammlung von Dokumenten. Dieser Link-Typ ver-
r@t den Suchmaschinen, welches Dokument vom Autor als Startpunkt der Sammlung ange-
sehen wird.
Next
Verweist auf das n@chste Dokument in einer lineare Abfolge von Dokumenten. Benutzer-
programme k=nnen das „n@chste“ Dokument im Voraus laden, um die wahrgenommene
Ladezeit zu verringern.
< 406 > Definition abstrakter Module
Page size: 168,00 x 240,00 mm
Prev
Verweist auf das vorhergehende Dokument in einer geordneten Folge von Dokumenten.
Einige Benutzerprogramme unterst tzen auch das Synonym „Previous“.
Contents
Verweist auf ein Dokument, das als Inhaltsverzeichnis dient. Einige Benutzerprogramme
unterst tzen auch das Synonym „ToC“ („Table of Contents“).
Index
Verweist auf ein Dokument, das ein Stichwortverzeichnis f r das aktuelle Dokument bereit-
h@lt.
Glossary
Verweist auf ein Dokument, das ein Glossar von Begriffen, die sich auf das aktuelle Doku-
ment beziehen, bereith@lt.
Copyright
Verweist auf Copyright-Hinweise f r das aktuelle Dokument.
Modularisierung von XHTML
Chapter
Verweist auf ein Dokument, das ein Kapitel in einer Sammlung von Dokumenten darstellt.
Section
Verweist auf ein Dokument, das einen Abschnitt in einer Sammlung von Dokumenten dar-
stellt.
Subsection
Verweist auf ein Dokument, das einen Unterabschnitt in einer Sammlung von Dokumenten
darstellt.
Appendix
Verweist auf ein Dokument, das einen Anhang in einer Sammlung von Dokumenten dar-
stellt .
Help
Verweist auf ein Dokument, das Hilfe anbietet (weitere Informationen, Links auf andere
Informationsquellen und so weiter)
Bookmark
Verweist auf ein Lesezeichen. Ein Lesezeichen ist ein Link zu einem Einstiegspunkt innerhalb
eines erweiterten Dokuments. Das title-Attribut kann benutzt werden, um das Lesezeichen
zum Beispiel zu benennen. Beachten Sie, dass in jedem Dokument mehrere Lesezeichen
definiert sein d rfen.
MediaDesc
Das MediaDesc-Attribut ist eine durch Kommata separierte Liste von Medienbezeichnern.
Nachfolgend eine Liste von bekannten Medienbezeichnern:
screen
Gedacht f r nicht seitenorientierte Computer-Bildschirme.
tty
Gedacht f r Medien, die ein Zeichenraster mit festen Abstand besitzen wie zum Beispiel
Fernschreiber, Terminals oder portable Ger@te mit beschr@nkten Anzeigef@higkeiten.
tv
Gedacht f r fernsehartige Ger@te (niedrige Aufl=sung, Farbe, beschr@nkte Scroll-F@higkeit).
Attributtypen < 407 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
projection
Gedacht f r Projektoren.
handheld
Gedacht f r tragbare Ger@te (kleiner Bildschirm, Monochrom, Rastergraphiken, begrenzte
Bandbreite).
print
Gedacht f r seitenorientiertes, undurchsichtiges Material und f r Dokumente, die auf dem
Bildschirm in der Druckvorschau betrachtet werden.
braille
Gedacht f r taktile Braille-Ger@te.
aural
Gedacht f r Sprach-Synthesizer.
all
Geeignet f r alle Ger@te.
Modularisierung von XHTML
Zuk nftige Versionen von XHTML k=nnen neue Werte einf hren und k=nnen parametrisierte
Werte erlauben. Um die Einf hrung dieser Erweiterungen zu unterst tzen, m ssen Benutzer-
programme in der Lage sein, den media-Attributwert wie folgt zu parsen:
1. Der Wert ist eine durch Kommata separierte 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 Zeichen abgeschnitten, das kein US-ASCII-Buchstabe
[a-zA-Z] (ISO 10646 hex 41-5a, 61-7a), Ziffer [0-9] (hex 30-39) oder Minuszeichen (hex
2d) ist. Im Beispiel f hrt das zu:
"screen"
"3d-glasses"
"print"
3. Es wird dann ein Vergleich ohne Ber cksichtigung von Groß/Kleinschreibung mit der oben
definierten Menge von Medientypen durchgef hrt. Benutzerprogramme k=nnen Eintr@ge,
die nicht passen, ignorieren. Im Beispiel bleiben screen und print brig.
Anmerkung: Stylesheets k nnen medienabh,ngige Variationen enthalten (zum Beispiel das CSS-
Konstrukt @media). In solchen F,llen kann es angemessen sein, „media =all“ zu verwenden. n
[Link] (MultiLength)
Der Wert darf eine absolute oder relative L@ngenangabe sein. Eine relative L@ngenangabe hat
die Form „i*“, wobei „i“ eine ganze Zahl ist. Bei der Zuweisung von Leeraum unter Elementen,
die um diesen Leeraum konkurrieren, weisen Benutzerprogramme Pixel- und Prozentl@ngen
< 408 > Definition abstrakter Module
Page size: 168,00 x 240,00 mm
zuerst zu; dann teilen sie den verbleibenden Raum unter den relativen L@ngen auf. Jede relative
L@nge erh@lt den Anteil des verf gbaren Raums, der proportional zu der Zahl ist, die dem „*“
vorangeht. Der Wert „*“ ist @quivalent zu „1*“. Folglich gilt: Wenn 60 Pixel an Raum verf gbar
sind, nachdem das Benutzerprogramm Pixel- und Prozentwerte zugewiesen hat, und die kon-
kurrierenden relativen L@ngen lauten „1*“, „2*“ und „3*“, dann wird „1*“ 10 Pixel, „2*“ 20
Pixel und „3*“ 30 Pixel zugewiesen.
[Link] (MultiLengths)
Eine durch Kommata separierte Liste von Eintr@gen des Typs MultiLength.
Zahl (Number)
Ein oder mehrere Ziffern.
Pixel
Modularisierung von XHTML
Der Wert ist eine ganze Zahl, die die Anzahl der Pixel auf der Zeichenfl@che (Bildschirm,
Papier) angibt. Folglich bedeutet der Wert „50“ f nfzig Pixel. F r normative Informationen ber
die Definition von Pixeln sei auf [CSS2] verwiesen.
Script
Script-Daten k=nnen der Inhalt des „script“-Elements und der Wert von eingebauten Ereigni-
sattributen (Events) sein. Benutzerprogramme d rfen Script-Daten nicht als HTML-Markup
auswerten, sondern m ssen sie statt dessen als Daten an den Script-Prozessor durchreichen.
Die Abh@ngigkeit von Groß/Kleinschreibung von Script-Daten h@ngt von der Scripting- Sprache
ab. Bitte beachten Sie, dass Script-Daten, die Elementinhalt darstellen, keine Zeichenreferenzen
enthalten d rfen; Script-Daten hingegen, die ein Attributwert sind, d rfen sie enthalten.
Form (Shape)
Die Form einer Fl@che.
Text
Beliebige textuelle Daten, meistens gedacht, um f r Menschen lesbar zu sein.
URI
Ein Uniform Resource Identifier gem@ß [URI].
URIs
Eine durch Leerzeichen getrennte Liste von Uniform Resource Identifiern gem@ß [URI].
4.4 Ein Beispiel f-r eine Definition eines abstrakten Moduls
Dieser Abschnitt ist informell.
Dieser Abschnitt definiert ein abstraktes Modul als Beispiel daf r, wie man die Vorteile der
oben definierten Syntaxregeln nutzt. Da dieses Beispiel versucht, alle definierten, verschiede-
nen syntaktischen Elemente zu nutzen, ist es ziemlich kompliziert. Typische Moduldefinitionen
w rden viel einfacher als diese sein. Schließlich beachten Sie bitte, dass dieses Modul auf eine
Attributsammlung namens „Common“ verweist. Diese Sammlung, die in dieser Spezifikation
definiert ist, enth@lt alle Grundattribute, die die meisten Elemente brauchen.
Ein Beispiel f#r eine Definition eines abstrakten Moduls < 409 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
4.4.1 XHTML-Ski-Modul
Das XHTML-Ski-Modul definiert Markup, das bei der Beschreibung einer Ski-H tte benutzt
wird. Die Elemente und Attribute, die in diesem Modul definiert werden, sind die folgenden:
Elemente Attribute Minimales Inhaltsmodell
urlaubsort Common, href (CDATA) beschreibung, Garmisch+
h tte Common beschreibung, (Garmisch - lift)+
lift Common, href beschreibung?
apartment Common, href beschreibung?
zimmer Common, href beschreibung?
foyer Common, href beschreibung?
Modularisierung von XHTML
kamin Common, href beschreibung?
beschreibung Common PCDATA*
Dieses Modul definiert außerdem die Inhaltsmenge Garmisch mit dem minimalen Inhaltsmodell
h tte | lift | apartment | zimmer | foyer | kamin.
5 Abstrakte XHTML-Module
Dieser Abschnitt ist normativ.
Dieser Abschnitt spezifiziert den Inhalt der abstrakten XHTML-Module. Diese Module sind
abstrakte Definitionen von Sammlungen von Elementen, Attributen und deren Inhaltsmodellen.
Diese abstrakten Module k=nnen auf jeden geeigneten Spezifikationsmechanismus abgebildet
werden. Implementierungen von XHTML-Modulen mit DTDs, zum Beispiel, bildet diese
Module auf DTDs gem@ß [XML] ab.
Inhaltentwickler und Ger@tentwickler sollten diesen Abschnitt als eine Anleitung zur Definition
des durch die verschiedenen XHTML-definierten Module bereitgestellten Funktionsumfangs
ansehen. Bei der Entwicklung von Dokumenten oder der Definition eines Profils f r eine Klasse
von Dokumenten k=nnen Inhaltentwickler bestimmen, welche dieser Module essentiell zur
Vermittlung ihrer Information sind. Beim Enturf von Client-Software sollten Entwickler die Pro-
file ihrer Ger@te durch Auswahl aus den hier definierten abstrakten Modulen entwickeln.
Sofern hier nichts anderes steht, sind die Bedeutungen der Elemente und Attribute in [HTML4]
definiert.
5.1 Sammlungen von Attributen
Viele der abstrakten Module dieses Abschnitts definieren die ben=tigten Attribute f r Elemen-
te. Die nachfolgende Tabelle definiert einige Sammlungen von Attributen, die von den Modulen
referenziert werden. Diese Ausdr cke sollten in keiner Weise als normativ oder unabdingbar
angesehen werden. Sie sind eine schreiberische Bequemlichkeit innerhalb dieses Dokuments.
Bei Verwendung im weiteren Verlauf dieses Abschnitts ist die Expandierung des Ausdrucks
normativ, nicht der Ausdruck selbst.
< 410 > Abstrakte XHTML-Module
Page size: 168,00 x 240,00 mm
Die folgenden Basisattributmengen werden bei vielen Elementen benutzt. In jedem Fall ihrer
Verwendung werden sie durch Angabe ihres Sammlungsnamens statt durch Aufz@hlung der
Liste angegeben.
Name der Sammlung Attribut in der Sammlung
Core class (NMTOKENS), id (ID), title (CDATA)
I18N xml:lang (NMTOKEN)
Events onclick (Script), ondblclick (Script), onmousedown (Script),
onmouseup (Script), onmouseover (Script), onmousemove
(Script), onmouseout (Script), onkeypress (Script), onkey-
down (Script), onkeyup (Script)
Style style (CDATA)
Common Core + Events + I18N + Style
Modularisierung von XHTML
Beachten Sie, dass die Ereignissammlung (Events) nur definiert ist, wenn das Modul f r einge-
baute Ereignisse (Intrinsic Events) ausgew@hlt ist. Andernfalls ist die Ereignissammlung leer.
Beachten Sie auch, dass die Stilsammlung (Style) nur definiert ist, wenn das Modul Stilattribute
(Style Attribute) ausgew@hlt ist. Andernfalls ist die Stilsammlung leer.
5.2 Kernmodule (Core Modules)
Die Kernmodule sind Module, die notwendigerweise in jedem zur XHTML-Familie konformen
Dokumenttyp (siehe Abschnitt 3.1) vorhanden sein m ssen.
5.2.1 Strukturmodul (Structure Module)
Das Strukturmodul definiert die haupts@chlichen Strukturelemente f r XHTML. Diese Ele-
mente sind praktisch die Basis f r das Inhaltsmodell von vielen Dokumenttypen der XHTML-
Familie. Die in diesem Modul enthaltenen Elemente und Attribute sind:
Elemente Attribute Minimales Inhaltsmodell
body Common (Heading | Block | List)*
head I18N, profile (URI) title
html I18N, version (CDATA), xmlns head, body
(URI = "[Link]
title I18N PCDATA
Dieses Modul ist die zugrunde liegende Strukturdefinition f r XHTML-Inhalt. Das html-Element
ist das Wurzelelement aller Dokumenttypen der XHTML-Familie.
Beachten Sie, dass der Wert des xmlns-Attributs als „[Link] definiert
ist. Beachten Sie auch, dass es aufgrund der besonderen Behandlung des xmlns-Attributs durch
XML-Namensraum-f@hige Parser [XMLNAMES] erlaubt ist, das Attribut an jedem Element zu
haben. Jedenfalls soll bei jeder Verwendung des xmlns-Attributs im Kontext eines XHTML-Mo-
Kernmodule (Core Modules) < 411 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
duls, egal ob mit Pr@fix oder ohne, der Wert des Attributs der hier definierte XHTML-Na-
mensraum sein. Siehe Abschnitt D.2 (Definieren des Namensraums f r ein Modul) f r weitere
Regeln bez glich der Namensraumverwendung mit Modulen der XHTML-Familie.
Implementierung: DTD
5.2.2 Textmodul (Text Module)
Dieses Modul definiert die Basis-Textcontainer-Elemente, Attribute und ihr Inhaltsmodell:
Element Attribute Minimales Inhaltsmodell
abbr Common (PCDATA | Inline)*
acronym Common (PCDATA | Inline)*
address Common (PCDATA | Inline)*
Modularisierung von XHTML
blockquote Common, cite (URI) (PCDATA | Heading | Block | List)*
br Core EMPTY
cite Common (PCDATA | Inline)*
code Common (PCDATA | Inline)*
dfn Common (PCDATA | Inline)*
div Common (PCDATA | Flow)*
em Common (PCDATA | Inline)*
h1 Common (PCDATA | Inline)*
h2 Common (PCDATA | Inline)*
h3 Common (PCDATA | Inline)*
h4 Common (PCDATA | Inline)*
h5 Common (PCDATA | Inline)*
h6 Common (PCDATA | Inline)*
kbd Common (PCDATA | Inline)*
p Common (PCDATA | Inline)*
pre Common, xml:space="preserve" (PCDATA | Inline)*
q Common, cite (URI) (PCDATA | Inline)*
samp Common (PCDATA | Inline)*
< 412 > Abstrakte XHTML-Module
Page size: 168,00 x 240,00 mm
Element Attribute Minimales Inhaltsmodell
span Common (PCDATA | Inline)*
strong Common (PCDATA | Inline)*
var Common (PCDATA | Inline)*
Das minimale Inhaltsmodell dieses Moduls definiert einige Inhaltsmengen:
Heading
h1 | h2 | h3 | h4 | h5 | h6
Block
address | blockquote | div | p | pre
Inline
Modularisierung von XHTML
abbr | acronym | br | cite | code | dfn | em | kbd | q | samp | span | strong | var
Flow
Heading | Block | Inline
Implementierung: DTD
5.2.3 Hypertext-Modul (Hypertext Module)
Das Hypertext-Modul stellt das Element zur Verf gung, das zur Definition von Hyperlinks zu
anderen Ressourcen benutzt wird. Dieses Modul unterst tzt die folgenden Elemente und Attri-
bute:
Element Attribute Minimales Inhaltsmodell
a Common, accesskey (Character), charset (PCDATA | Inline - a)*
(Charset), href (URI), hreflang (Language-
Code), rel (LinkTypes), rev (LinkTypes),
tabindex (Number), type (ContentType)
Dieses Modul f gt das a-Element zur Inline-Inhaltsmenge des Textmoduls hinzu.
Implementierung: DTD
5.2.4 Listenmodul (List Module)
Wie schon der Name sagt, stellt das Listenmodul listenorientierte Elemente zur Verf gung. Ins-
besondere unterst tzt das Listenmodul die folgenden Elemente und Attribute:
Elemente Attribute Minimales Inhaltsmodell
dl Common (dt | dd)+
dt Common (PCDATA | Inline)*
dd Common (PCDATA | Flow)*
ol Common li+
Kernmodule (Core Modules) < 413 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Elemente Attribute Minimales Inhaltsmodell
ul Common li+
li Common (PCDATA | Flow)*
Diese Modul definiert auch die Inhaltsmenge „List“ mit dem minimalen Inhaltsmodell (dl | ol |
ul)+ und f gt diese Menge zur Flow-Inhaltsmenge des Textmoduls hinzu.
Implementierung: DTD
5.3 Applet-Modul (Applet Module)
Dieses Modul ist missbilligt. Eine vergleichbare Funktion steht mit dem Objektmodul zur Ver-
f gung.
Modularisierung von XHTML
Das Applet-Modul stellt Elemente f r den Verweis auf externe Anwendungen zur Verf gung.
Insbesondere unterst tzt das Applet-Modul die folgenden Elemente und Attribute:
Element Attribute Minimales Inhaltsmodell
applet Core, alt* (Text), archive (CDATA), code (PCDATA | Flow |
(CDATA), codebase (URI), height* param)*
(Length), object (CDATA), width*
(Length)
param id (ID), name* (CDATA), type (Content- EMPTY
Type), value (CDATA), valuetype ("data"* |
"ref" | "object")
Wenn das Applet-Modul verwendet wird, f gt es das applet-Element zur Inline-Inhaltsmenge
des Textmoduls hinzu.
Implementierung: DTD
5.4 Texterweiterungsmodule (Text Extension Modules)
Dieser Abschnitt definiert verschiedene zus@tzliche Markup-Modelle f r Text.
5.4.1 Darstellungsmodul (Presentation Module)
Dieses Modul definiert Elemente, Attribute und ein minimales Inhaltsmodell f r einfache dar-
stellungsorientierte Auszeichnungen:
Element Attribute Minimales Inhaltsmodell
b Common (PCDATA | Inline)*
big Common (PCDATA | Inline)*
hr Common EMPTY
i Common (PCDATA | Inline)*
small Common (PCDATA | Inline)*
< 414 > Abstrakte XHTML-Module
Page size: 168,00 x 240,00 mm
Element Attribute Minimales Inhaltsmodell
sub Common (PCDATA | Inline)*
sup Common (PCDATA | Inline)*
tt Common (PCDATA | Inline)*
Wenn das Modul verwendet wird, wird das hr-Element zur Inhaltsmenge Block des Text-
moduls erg@nzt. Des Weiteren werden die Elemente b, big, i, small, sub, sup, und tt zur
Inhaltsmenge Inline des Textmoduls erg@nzt.
Implementierung: DTD
5.4.2 Edit-Modul (Edit Module)
Modularisierung von XHTML
Dieses Modul definiert Elemente und Attribute zum Redigieren von Texten.
Element Attribute Minimales Inhaltsmodell
del Common, cite (URI), datetime (Datetime) (PCDATA | Flow)*
ins Common, cite (URI), datetime (Datetime) (PCDATA | Flow)*
Wenn das Modul verwendet wird, werden die Elemente del und ins der Inline-Inhaltsmenge
des Textmoduls hinzugef gt.
Implementierung: DTD
5.4.3 Modul f-r bidirektionalen Text
Das Modul f r bidirektionalen Text definiert ein Element f r die Definition der Schreibrichtung
des Elementinhalts.
Elemente Attribute Minimales Inhaltsmodell
bdo Core, dir* ("ltr" | "rtl") (PCDATA | Inline)*
Wenn das Modul verwendet wird, wird das Element bdo der Inline-Inhaltsmenge des Text-
moduls hinzugef gt. Ausw@hlen dieses Moduls f gt außerdem das Attribut dir* ("ltr" | "rtl")
der Attributsammlung I18N hinzu.
Implementierung: DTD
5.5 Formularmodul (Forms Modules)
5.5.1 Basisformularmodul (Basic Forms Module)
Das Basisformularmodul stellt Formularelemente, allerdings nur in eingeschr@nkter Form zur
Verf gung. Das Basisformularmodul unterst tzt insbesondere die folgenden Elemente, Attri-
bute und folgendes minimales Inhaltsmodell:
Formularmodul (Forms Modules) < 415 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Elemente Attribute Minimales Inhaltsmodell
form Common, action* (URI), method ("get"* | (Heading | List | Block -
"post"), enctype (ContentType) form)+
input Common, accesskey (Character), checked EMPTY
("checked"), maxlength (Number), name
(CDATA), size (Number), src (URI),
tabindex (Number), type ("text"* |
"password" | "checkbox" | "radio" | "submit" |
"reset" | "hidden" ), value (CDATA)
label Common, accesskey (Character), for (PCDATA | Inline - label)*
(IDREF)
select Common, multiple ("multiple"), name option+
Modularisierung von XHTML
(CDATA), size (Number), tabindex
(Number)
option Common, selected ("selected"), value PCDATA
(CDATA)
textarea Common, accesskey (Character), cols* PCDATA
(Number), name (CDATA), rows*
(Number), tabindex (Number)
Diese Modul definiert zwei Inhaltsmengen:
Form
form
Formctrl
input | label | select | textarea
Wenn dieses Modul verwendet wird, f gt es die Form-Inhaltsmenge der Block-Inhaltsmenge
und die Formctrl-Inhaltsmenge der Inline-Inhaltsmenge hinzu, jeweils definiert im Text-
modul.
Implementierung: DTD
5.5.2 Formularmodul (Forms Module)
Das Formularmodul stellt alle Formularf@higkeiten von HTML 4.0 zur Verf gung. Das Formu-
larmodul unterst tzt:
Elemente Attribute Minimales Inhaltsmodell
form Common, accept (ContentTypes), accept- (Heading | List | Block -
charset (Charsets), action* (URI), method form | fieldset)+
("get"* | "post"), enctype (ContentType)
< 416 > Abstrakte XHTML-Module
Page size: 168,00 x 240,00 mm
Elemente Attribute Minimales Inhaltsmodell
input Common, accept (ContentTypes), access- EMPTY
key (Character), alt (Text), checked
("checked"), disabled ("disabled"), maxlength
(Number), name (CDATA), readonly
("readonly"), size (Number), src (URI),
tabindex (Number), type ("text"* | "pass-
word" | "checkbox" | "button" | "radio" |
"submit" | "reset" | "file" | "hidden" | "image"),
value (CDATA)
select Common, disabled ("disabled"), multiple ("mul- (optgroup | option)+
tiple"), name (CDATA), size (Number),
tabindex (Number)
Modularisierung von XHTML
option Common, disabled ("disabled"), label (Text), PCDATA
selected ("selected"), value (CDATA)
textarea Common, accesskey (Character), cols* PCDATA
(Number), disabled ("disabled"), name
(CDATA), readonly ("readonly"), rows*
(Number), tabindex (Number)
button Common, accesskey (Character), disabled (PCDATA | Heading | List
("disabled"), name (CDATA), tabindex | Block - Form | Inline -
(Number), type ("button" | "submit"* | Formctrl)*
"reset"), value (CDATA)
fieldset Common (PCDATA | legend |
Flow)*
label Common, accesskey (Character), for (PCDATA | Inline - label)*
(IDREF)
legend Common, accesskey (Character) (PCDATA | Inline)+
optgroup Common, disabled ("disabled"), label* (Text) option+
Diese Modul definiert zwei Inhaltsmengen:
Form
form | fieldset
Formctrl
input | select | textarea | label | button
Wenn dieses Modul verwendet wird, f gt es die Form-Inhaltsmenge der Block-Inhaltsmenge
und die Formctrl-Inhaltsmenge der Inline-Inhaltsmenge hinzu, jeweils definiert im Text-
modul.
Das Formularmodul ist eine Obermenge des Basisformularmoduls. Diese Module d rfen nicht
zusammen in einem einzelnen Dokumenttyp verwendet werden.
Implementierung: DTD
Formularmodul (Forms Modules) < 417 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
5.6 Tabellenmodul (Table Modules)
5.6.1 Basistabellenmodul (Basic Tables Module)
Das Basistabellenmodul stellt Tabellenelemente, allerdings nur in eingeschr@nkter Form zur
Verf gung. Das Basistabellenmodul unterst tzt:
Elemente Attribute Minimales Inhaltsmodell
caption Common (PCDATA | Inline)*
table Common, summary ( Text ), width ( caption?, tr+
Length )
td Common, abbr (Text), align ("left" | "center" | (PCDATA | Flow - table)*
"right"), axis (CDATA), colspan (Number),
headers (IDREFS), rowspan (Number),
Modularisierung von XHTML
scope ("row" | "col"), valign ("top" | "middle" |
"bottom")
th Common, abbr (Text), align ("left" | "center" | (PCDATA | Flow - table)*
"right"), axis (CDATA), colspan (Number),
headers (IDREFS), rowspan (Number),
scope ("row" | "col" ), valign ("top" | "middle" |
"bottom")
tr Common, align ("left" | "center" | "right"), (td | th)+
valign ("top" | "middle" | "bottom")
Wenn dieses Modul verwendet wird, f gt es das table-Element der Block-Inhaltsmenge des
Textmoduls hinzu.
Implementierung: DTD
5.6.2 Tabellenmodul (Tables Module)
Wie bereits der Name andeutet, stellt das Tabellenmodul Tabellenelemente zur Verf gung, auf
die nicht visuelle Benutzerprogramme besser zugreifen k=nnen. Das Tabellenmodul stellt die
folgenden Elemente, Attribute und minimalen Inhaltsmodelle zur Verf gung:
Elemente Attribute Minimales Inhaltsmodell
caption Common (PCDATA | Inline)*
table Common, border (Pixels), cellpadding caption?, ( col* | colgroup* ),
(Length), cellspacing (Length), datapagesize (( thead?, tfoot?, tbody+ ) |
(CDATA), frame ("void" | "above" | below" | ( tr+ ))
"hsides" | "lhs" | "rhs" | "vsides" | "box" | "bor-
der"), rules ("none" | "groups" | "rows" | "cols"
| "all"), summary (Text), width (Length)
< 418 > Abstrakte XHTML-Module
Page size: 168,00 x 240,00 mm
Elemente Attribute Minimales Inhaltsmodell
td Common, abbr (Text), align ("left" | "center" | (PCDATA | Flow)*
"right" | "justify" | "char"), axis (CDATA), char
(Character), charoff (Length), colspan
(Number), headers (IDREFS), rowspan
(Number), scope ("row", "col", "rowgroup",
"colgroup"), valign ("top" | "middle" | "bottom"
| "baseline")
th Common, abbr (Text), align ("left" | "center" | (PCDATA | Flow)*
"right" | "justify" | "char"), axis (CDATA), char
(Character), charoff (Length), colspan
(Number), headers (IDREFS), rowspan
(Number), scope ("row", "col", "rowgroup",
Modularisierung von XHTML
"colgroup"), valign ("top" | "middle" | "bottom"
| "baseline")
tr Common, align ("left" | "center" | "right" | (td | th)+
"justify", "char"), char (Character), charoff
(Length), valign ("top" | "middle" | "bottom" |
"baseline")
col Common, align ("left" | "center" | "right" | EMPTY
"justify", "char"), char (Character), charoff
(Length), span (Number), valign ("top" |
"middle" | "bottom" | "baseline"), width
(MultiLength)
colgroup Common, align ("left" | "center" | "right" | col*
"justify", "char"), char (Character), charoff
(Length), span (Number), valign ("top" |
"middle" | "bottom" | "baseline"), width
(MultiLength)
tbody Common, align ("left" | "center" | "right" | tr+
"justify", "char"), char (Character), charoff
(Length), valign ("top" | "middle" | "bottom" |
"baseline")
thead Common, align ("left" | "center" | "right" | tr+
"justify", "char"), char (Character), charoff
(Length), valign ("top" | "middle" | "bottom" |
"baseline")
tfoot Common, align ("left" | "center" | "right" | tr+
"justify", "char"), char (Character), charoff
(Length), valign ("top" | "middle" | "bottom" |
"baseline")
Tabellenmodul (Table Modules) < 419 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Wenn dieses Modul verwendet wird, f gt es das table-Element der Block-Inhaltsmenge des
Textmoduls hinzu.
Implementierung: DTD
5.7 Bildmodul (Image Module)
Das Bildmodul ist die Grundlage f r die Einbindung von Bildern und kann in einigen Implemen-
tationen unabh@ngig von client-seitigen Image Maps benutzt werden. Das Bildmodul unterst tzt
die folgenden Elemente und Attribute:
Elemente Attribute Minimales Inhaltsmodell
img Common, alt* (Text), height (Length), EMPTY
longdesc (URI), src* (URI), width (Length)
Modularisierung von XHTML
Wenn das Modul verwendet wird, f gt es das img-Element der Inline-Inhaltsmenge des Text-
moduls hinzu.
Implementierung: DTD
5.8 Modul f-r client-seitige Image Maps (Client-side Image
Map Module)
Das Modul f r client-seitige Image Maps stellt Elemente f r client-seitige Image Maps zur Ver-
f gung. Es setzt das Bildmodul (oder ein anderes Modul, das das img-Element enth@lt) voraus.
Das Modul f r client-seitige Image Maps unterst tzt folgende Elemente:
Elemente Attribute Minimales Inhaltsmodell
a& coords (CDATA), shape ("rect" | "circle" | n/a
"poly" | "default")
area Common, accesskey (Character), alt* EMPTY
(Text), coords (CDATA), href (URI), nohref
("nohref"), shape ("rect"* | "circle" | "poly" |
"default"), tabindex (Number)
img& usemap (IDREF) n/a
input& usemap (IDREF) n/a
map I18N, Events, class (NMTOKEN), id* (ID), ((Heading | Block) | area)+
title (CDATA)
object& usemap (IDREF) Beachten Sie: Nur wenn
das Objektmodul einge-
bunden wurde.
Wenn das Modul verwendet wird, f gt es das map-Element der Inline-Inhaltsmenge des Text-
moduls hinzu.
Implementierung: DTD
< 420 > Abstrakte XHTML-Module
Page size: 168,00 x 240,00 mm
5.9 Modul f-r server-seitige Image Maps (Server-side
Image Map Module)
Das Modul f r server-seitige Image Maps unterst tzt Auswahl und bertragung von Bild-
koordinaten. Es setzt das Bildmodul (oder ein anderes Modul, das das img-Element enth@lt)
voraus. Das Modul f r server-seitige Image Maps unterst tzt folgende Attribute:
Elemente Attribute Minimales Inhaltsmodell Bemerkungen
img& ismap ("ismap") n/a
input& ismap ("ismap") n/a Falls das Formular- oder
Basisformularmodul einge-
bunden wurde.
Modularisierung von XHTML
Implementierung: DTD
5.10 Objektmodul (Object Module)
Das Objektmodul stellt Elemente f r die Einbindung von allgemeinen Objekten zu Verf gung.
Das Objektmodul unterst tzt:
Elemente Attribute Minimales Inhaltsmodell
object Common, archive (URIs), classid (URI), code- (PCDATA | Flow |
base (URI), codetype (ContentType), data param)*
(URI), declare ("declare"), height (Length),
name (CDATA), standby (Text), tabindex
(Number), type (ContentType), width
(Length)
param id (ID), name* (CDATA), type (Content- EMPTY
Type), value (CDATA), valuetype ("data"* |
"ref" | "object")
Wenn das Modul verwendet wird, f gt es das object-Element der Inline-Inhaltsmenge des
Textmoduls hinzu.
Implementierung: DTD
5.11 Frames-Modul (Frames Module)
Wie der Name verrr@t, stellt das Frames-Modul Elemente f r Frames zur Verf gung. Das
Frames-Modul unterst tzt:
Elemente Attribute Minimales Inhaltsmodell
frameset Core, cols ( MultiLength ), rows ( Multi- (frameset | frame)+,
Length ) noframes?
Modul f#r server-seitige Image Maps < 421 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Elemente Attribute Minimales Inhaltsmodell
frame Core, frameborder ("1" | "0"), longdesc EMPTY
( URI ), marginheight ( Pixels ), marginwidth (
Pixels ), noresize ("noresize"), scrolling ("yes"
| "no" | "auto"*), src ( URI )
noframes Common body
Wenn dieses Modul ausgew@hlt wird, wird das minimale Inhaltsmodell des html-Elements des
Strukturmoduls zu (head, frameset) ge@ndert.
Implementierung: DTD
5.12 Target-Modul (Target Module)
Modularisierung von XHTML
Aus einem Frame heraus kann veranlasst werden, dass ein verlinktes Dokument in einem
bestimmten Ziel-Frame erscheint. Dieses Modul f gt das target-Attribut zu den Link-definie-
renden Elementen (a, area und so weiter) hinzu. Diese Funktion ist als separates Modul defi-
niert, damit es in Dokumente eingebaut werden kann, die in Frames auftreten, und auch in
Dokumente, die target verwenden, um ein neues Fenster zu =ffnen.
Elemente Attribute Bemerkungen
a& target ( CDATA )
area& target ( CDATA ) Wenn das Modul f r client-seitige Image
Maps ausgew@hlt ist.
base& target ( CDATA ) Wenn das Altlastenmodul ausgew@hlt ist.
link& target ( CDATA ) Wenn das Link-Modul ausgew@hlt ist.
form& target ( CDATA ) Wenn das Formular- oder Basisformular-
modul ausgew@hlt ist.
Implementierung: DTD
5.13 Iframe-Modul (Iframe Module)
Das Iframe-Modul definiert ein Element f r Inline Frames. Das Element und Attribute in diesem
Modul sind:
Elemente Attribute Minimales Inhaltsmodell
iframe Core, frameborder ("1" | "0"), height (PCDATA | Flow)*
(Length), longdesc (URI), marginheight
(Pixels), marginwidth (Pixels), scrolling ("yes"
| "no" | "auto"*), src (URI), width (Length)
< 422 > Abstrakte XHTML-Module
Page size: 168,00 x 240,00 mm
Wenn das Modul verwendet wird, f gt es das iframe-Element der Inline-Inhaltsmenge des
Textmoduls hinzu.
Implementierung: DTD
5.14 Modul f-r eingebaute Ereignisse (Intrinsic Events
Module)
Eingebaute Ereignisse sind Attribute einiger Elemente. Diese Elemente zeichnen sich dadurch
aus, dass ein bestimmtes Ereignis eintritt, wenn der Benutzer eine bestimmte Handlung aus-
f hrt. Die in der nachfolgenden Tabelle aufgelisteten Attribute werden nur dann der Attribut-
menge der jeweiligen Elemente hinzugef gt, wenn die Module, die diese Elemente definieren,
auch ausgew@hlt wurden. Beachten Sie, dass die Auswahl dieses Moduls die oben beschriebene
Attributsammlung Events definiert. In diesem Modul definierte Attribute lauten:
Modularisierung von XHTML
Elemente Attribute Bemerkungen
a& onblur (Script), onfocus (Script)
area& onblur (Script), onfocus (Script) Wenn das Modul f r
client-seitige Image Maps
ausgew@hlt ist.
frame- onload (Script), onunload (Script) Wenn das Frames-Modul
set& ausgew@hlt ist.
form& onreset (Script), onsubmit (Script) Wenn das Formular- oder
Basisformularmodul aus-
gew@hlt ist.
body& onload (Script), onunload (Script)
label& onblur (Script), onfocus (Script) Wenn das Formularmodul
ausgew@hlt ist.
input& onblur (Script), onchange (Script), onfocus Wenn das Formular- oder
(Script), onselect (Script) Basisformularmodul aus-
gew@hlt ist.
select& onblur (Script), onchange (Script), onfocus Wenn das Formular- oder
(Script) Basisformularmodul aus-
gew@hlt ist.
texta- onblur (Script), onchange (Script), onfocus Wenn das Formular- oder
rea& (Script), onselect (Script) Basisformularmodul aus-
gew@hlt ist.
button& onblur (Script), onfocus (Script) Wenn das Formularmodul
ausgew@hlt ist.
Implementierung: DTD
Modul f#r eingebaute Ereignisse < 423 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
5.15 Metainformationsmodul (Metainformation Module)
Das Metainformationsmodul definiert ein Element, das Information innerhalb des deklarativen
Teils eines Dokuments beschreibt (in XHTML das head-Element). Das Modul enth@lt das fol-
gende Element:
Elemente Attribute Minimales Inhaltsmodell
meta I18N, content* (CDATA), http-equiv EMPTY
(NMTOKEN), name (NMTOKEN), scheme
(CDATA)
Wenn dieses Modul gew@hlt wird, wird das meta-Element dem Inhaltsmodell des head-Elements,
definiert im Strukturmodul, hinzugef gt.
Implementierung: DTD
Modularisierung von XHTML
5.16 Scripting-Modul (Scripting Module)
Das Scripting-Modul definiert Elemente, die Informationen bez glich ausf hrbarer Programme
oder bez glich der fehlenden Unterst tzung f r die Ausf hrung solcher Programme enthalten.
Elemente und Attribute in diesem Modul sind:
Elemente Attribute Minimales Inhaltsmodell
noscript Common (Heading | List | Block)+
script charset (Charset), defer ("defer"), src (URI), PCDATA
type* (ContentType), xml:space="preserve"
Wenn dieses Modul verwendet wird, werden die script- und noscript-Elemente zu den Block
und Inline-Inhaltsmengen des Textmoduls hinzugef gt. Außerdem wird das script-Element
dem Inhaltsmodell des head-Elements, definiert im Strukturmodul, zugef gt.
Implementierung: DTD
5.17 Stylesheet-Modul (Style Sheet Module)
Das Stylesheet-Modul definiert ein Element zur Deklaration von internen Stylesheets. Das Ele-
ment und die Attribute dieses Moduls sind:
Elemente Attribute Minimales Inhaltsmodell
style I18N, media (MediaDesc), title (Text), type* PCDATA
(ContentType), xml:space="preserve"
Wenn dieses Modul verwendet wird, f gt es das style-Element dem Inhaltsmodell des head-Ele-
ments, definiert im Strukturmodul, hinzu.
Implementierung: DTD
< 424 > Abstrakte XHTML-Module
Page size: 168,00 x 240,00 mm
5.18 Style-Attributmodul (Style Attribute Module)
Das Style-Attributmodul definiert das style-Attribut. Wenn dieses Modul gew@hlt wird, akti-
viert es die Style-Attributsammlung.
Implementierung: DTD
5.19 Link-Modul (Link Module)
Das Link-Modul definiert ein Element, mit dem Links zu externen Ressourcen definiert werden
k=nnen. Diese Ressourcen werden h@ufig verwendet, um die F@higkeit von Benutzerprogram-
men zur Verarbeitung des XHTML-Dokuments zu verbessern. Das Element und die Attribute
in diesem Modul sind:
Elemente Attribute Minimales Inhaltsmodell
Modularisierung von XHTML
link Common, charset (Charset), href (URI), EMPTY
hreflang (LanguageCode), media (Media-
Desc), rel (LinkTypes), rev (LinkTypes),
type (ContentType)
Wenn dieses Modul verwendet wird, f gt es das link-Element zum Inhaltsmodell des head-Ele-
ments, definiert im Strukturmodul.
Implementierung: DTD
5.20 Base-Modul (Base Module)
Das Base-Modul definiert ein Element, mit dem ein Basis-URI definiert werden kann, bez glich
dessen relative URIs im Dokument aufgel=st werden. Das Element und Attribut in diesem
Modul sind:
Elemente Attribute Minimales Inhaltsmodell
base href* (URI) EMPTY
Wenn dieses Modul verwendet wird, f gt es das base-Element dem Inhaltsmodell des head-Ele-
ments, definiert im Strukturmodul, hinzu.
Implementierung: DTD
5.21 Name-Identifizierungsmodul (Name Identification
Module)
Dieses Modul ist missbilligt.
Das Name-Identifizierungsmodul definiert das Attribut name f r eine Sammlung von Elementen.
Das name-Attribut wurde urspr nglich zur Benennung bestimmter Elemente in HTML-Doku-
menten benutzt. Obgleich das name-Attribut durch das id-Attribut ersetzt wurde, kann es F@lle
geben, in denen Auszeichnungssprachen beide unterst tzen m=chten. Solche Auszeichnungs-
sprachen k=nnen dies durch Einbinden dieses Moduls tun.
Style-Attributmodul (Style Attribute Module) < 425 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Beachten Sie, dass durch Einbinden des Moduls sowohl das name- als auch das id-Attribut f r
die aufgef hrten Elemente definiert werden. Wenn dann das name-Attribut f r ein Element defi-
niert wird, so muss auch das id-Attribut definiert werden. Des Weiteren m ssen beide Attri-
bute denselben Wert haben. Wenn schließlich das Dokument, welches das Attribut benutzt,
mit dem Internet-Medientyp „text/xml“ oder „application/xml“ ausgeliefert wird, dann soll der
Wert des name-Attributs dieser Elemente nicht als Fragmentbezeichner benutzt werden.
Elemente Attribute Bemerkungen
a& name (CDATA)
applet& name (CDATA) Wenn das Applet-Modul
ausgew@hlt ist.
form& name (CDATA) Wenn das Formular- oder
Basisformularmodul aus-
Modularisierung von XHTML
gew@hlt ist.
frame& name (CDATA) Wenn das Frames-Modul
ausgew@hlt ist.
iframe& name (CDATA) Wenn das Iframe-Modul
ausgew@hlt ist.
img& name (CDATA) Wenn das Bildmodul aus-
gew@hlt ist.
map& name (CDATA) Wenn das Modul f r
client-seitige Image Maps
ausgew@hlt ist.
Implementierung: DTD
5.22 Altlastenmodul (Legacy Module)
Das Altlastenmodul defniert Elemente und Attribute, die bereits in fr heren Versionen von
HTML und XHTML missbilligt waren und auch in Modularisierung von XHTML missbilligt blei-
ben. Autoren von Auszeichnungssprachen sollten diese Elemente und Attribute nicht l@nger
benutzen.
Die folgende Tabelle zeigt die Elemente und Attribute, die definiert werden, wenn das Altlas-
tenmodul ausgew@hlt wird.
Elemente Attribute Minimales Inhaltsmodell
basefont color (Color), face (CDATA), id (ID), size EMPTY
(CDATA)
center Common (PCDATA | Flow)*
dir Common, compact ("compact") (li)+
font Core, I18N, color (Color), face (CDATA), (PCDATA | Inline)*
size (CDATA)
isindex Core, I18N, prompt (Text) EMPTY
< 426 > Abstrakte XHTML-Module
Page size: 168,00 x 240,00 mm
Elemente Attribute Minimales Inhaltsmodell
menu Common, compact ("compact") (li)+
s Common (PCDATA | Inline)*
strike Common (PCDATA | Inline)*
u Common (PCDATA | Inline)*
Die folgende Tabelle zeigt weitere Attribute f r Elemente, die an anderer Stelle definiert wer-
den, wenn das Altlastenmodul ausgew@hlt wird.
Elemente Attribute Bemerkungen
body& alink (Color), background (URI), bgcolor
(Color), link (Color), text (Color), vlink
Modularisierung von XHTML
(Color)
br& clear ("left" | "all" | "right" | "none"*)
caption& align ("top" | "bottom" | "left" | "right")
div& align ("left" | "center" | "right" | "justify")
dl& compact ("compact"), type (CDATA)
h1-h6& align ("left" | "center" | "right" | "justify")
hr& align ("left" | "center" | "right" | "justify"),
noshade ("noshade"), size (Pixels), width
(Length),
img& align ("left" | "center" | "right" | "justify"), bor-
der (Pixels), hspace (Pixels), vspace (Pixels)
input& align ("top" | "middle" | "bottom" | "left" | Wenn das Formular- oder
"right") Basisformularmodul aus-
gew@hlt ist.
legend& align ("left" | "center" | "right" | "justify") Wenn das Formularmodul
ausgew@hlt ist.
li& type (CDATA), value (Number)
ol& compact ("compact"), start (Number), type
(CDATA)
p& align ("left" | "center" | "right", "justify")
pre& width (Number)
script& language (CDATA) Wenn das Scripting-Modul
ausgew@hlt ist.
table& align ("left" | "center" | "right"), bgcolor Wenn das Tabellenmodul
(Color) ausgew@hlt ist.
tr& bgcolor (Color) Wenn das Tabellenmodul
ausgew@hlt ist.
Altlastenmodul (Legacy Module) < 427 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Elemente Attribute Bemerkungen
th& bgcolor (Color), height (Pixels) nowrap Wenn das Tabellenmodul
("nowrap"), width (Length) ausgew@hlt ist.
td& bgcolor (Color), height (Length) nowrap Wenn das Tabellenmodul
("nowrap"), width (Pixels) ausgew@hlt ist.
ul& compact ("compact"), type (CDATA)
Implementierung: DTD
A Erstellen von Schema-Modulen
Modularisierung von XHTML
Dieser Anhang ist normativ.
Sobald XML-Schema zu einer W3C Recommendation wird, wird dieser Anhang Anweisungen
f r die Definition von XML-Schema-Modulen enthalten, die kompatibel zur Implementierung
der Modularisierung von XHTML per XML-Schema [XMLSCHEMA] sind.
B Entwicklung eines Schemas mit
definierten und erweiterten
Modulen
Dieser Anhang ist normativ.
Sobald XML-Schema zu einer W3C Recommendation wird, wird dieser Anhang Anweisungen
enthalten, wie man vollst@ndige Auszeichnungssprachen mit XHTML-Modulen per XML-
Schema [XMLSCHEMA] definiert.
C Implementierungen der
XHTML-Schema-Module
Dieser Anhang ist normativ.
Sobald XML-Schema zu einer W3C Recommendation wird, wird dieser Anhang die Implemen-
tierungen der in Abschnitt 5 (Abstrakte XHTML-Module) definierten Module per XML-Schema
enthalten.
< 428 > Erstellen von Schema-Modulen
Page size: 168,00 x 240,00 mm
D Erstellen von DTD-Modulen
Dieser Anhang ist normativ.
XHTML-Module sind in Form von DTD-Fragmenten implementiert. Wenn diese Fragmente in
einer bestimmten Weise (beschrieben in Anhang E (Entwickeln von DTDs mit definierten und
erweiterten Modulen)) zusammengef gt werden, dann ist die entstehende DTD die Repr@sen-
tation eines vollst@ndigen Dokumenttyps. Diese Repr@sentation kann dann zur Validierung von
Instanzen des Dokumenttyps verwendet werden.
Der Schl ssel dazu, wie diese Fragmente zu einer sinnvollen DTD kombiniert werden k=nnen,
besteht in den Regeln, mit denen die Fragmente definiert werden. Dieser Abschnitt definiert
jene Regeln. Durch das Befolgen der Regeln k=nnen DTD-Autoren sicher sein, dass ihre
Module saubere Schnittstellen zu anderen XHTML-kompatiblen Modulen besitzen.
Damit sich Module, die zu diesen Regeln konform sind, als Modul der XHTML-Familie bezeichnen
d rfen, m ssen sie zudem die Konformit@tsanforderungen erf llen, die in Abschnitt 3.3 (Kon-
Modularisierung von XHTML
formit@t eines Moduls zur XHTML-Familie) definiert sind.
D.1 Benennung von Parameter-Entities
Dieses Spezifikation klassifiziert Parameter-Entities in Kategorien und benennt sie konsistent
unter Verwendung der folgenden Suffixe:
.mod
Parameter-Entities tragen das Suffix .mod, wenn sie ein DTD-Modul darstellen (eine Samm-
lung von Elementen, Attributen, Parameter-Entities und so weiter). In dieser Spezifikation
ist jedes Modul eine atomare Einheit und kann als separates Datei-Entity dargestellt wer-
den.
.module
Parameter-Entities tragen das Suffix .module, wenn sie die Aufnahme eines DTD-Moduls
durch eines der Schl sselw=rter INCLUDE oder IGNORE f r bedingte Abschnitte steuern.
.qname
Parameter-Entities tragen das Suffix .qname, wenn sie den qualifizierten Namen f r ein Ele-
ment repr@sentieren. Siehe Abschnitt D.2 (Definieren des Namensraums f r ein Modul) f r
weitere Informationen ber qualifizierte Namen.
.content
Parameter-Entities tragen das Suffix .content, wenn sie das Inhaltsmodell eines Elementtyps
darstellen.
.class
Parameter-Entities tragen das Suffix .class, wenn sie Elemente derselben Klasse darstellen.
.mix
Parameter-Entities tragen das Suffix .mix, wenn sie eine Sammlung von Elementtypen ver-
schiedener Klassen darstellen.
.attrib
Parameter-Entities tragen das Suffix .attrib, wenn sie eine Gruppe von Token darstellen,
die ein oder mehrere vollst@ndige Attributspezifikationen innerhalb einer ATTLIST-Dekla-
ration bilden.
Erstellen von DTD-Modulen < 429 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Zum Beispiel wurde in HTML 4 das Parameter-Entity %block; definiert, um die heterogene
Sammlung von Elementtypen darzustellen, die Block-Elemente sind. In dieser Spezifikation heißt
das entsprechende Parameter-Entity %[Link];.
Bei der Definition von Parameter-Entities innerhalb der hier definierten Klassen, sollten
Module den G ltigkeitsbereich der Entity-Namen durch Einsatz von eindeutigen Pr@fixen ein-
schr@nken. Zum Beispiel k=nnte das Inhaltsmodell des Elements myelement im Modul mymodule
den Namen [Link] tragen. Andere Schemata sind m=glich. Unabh@ngig
von dem verwendeten Schema sollten Modulautoren sicherstellen, dass die von ihnen definier-
ten Parameter-Entities eindeutig benannt sind, so dass sie nicht mit den Namen anderer Para-
meter-Entities kollidieren und die Schnittstellen der Module f r deren Anwender offensichtlich
sind.
D.2 Definieren des Namensraums f-r ein Modul
Modularisierung von XHTML
XHTML verlangt, dass sich die in einem Modul deklarierten Elemente und Attribute innerhalb
eines definierten Namensraums befinden [XMLNAMES]. Die Kennzeichnung dieses Namens-
raums ist ein beliebiger URI. XHTML verlangt, dass das Modul, im Falle der Implementierung
des Moduls durch eine XML-DTD, den Namensraum in einer bestimmten Weise deklariert.
Der Zweck davon ist, dass das Namensraumpr@fix sowie das Pr,fix, mit dem Elemente und
Attribute des Moduls identifiziert werden, zum Zeitpunkt des Parsings beziehungsweise der
Validierung des Dokuments gew@hlt werden k=nnen.
Autoren, die Dokumente schreiben m=chten, die auf hybriden Dokumenttypen basieren, steht
es frei, Namensraumpr@fixe bei Elementen aus dem XHTML-Namensraum, bei Elementen aus
anderen Namensr@umen oder beide M=glichkeiten zu w@hlen. Um sicherzugehen, dass solche
Dokumente XHTML-konform und abw@rtskompatibel zu Werkzeugen sind, die Namensr@ume
nicht kennen, empfiehlt das W3C, keine Namensraumpr@fixe bei Elementen aus dem XHTML-
Namensraum zu verwenden. Falls Autoren ihre Inhalte durch namensraumf@hige Software ver-
arbeiten lassen m=chten, r@t das W3C dar berhinaus, dass Elemente außerhalb des XHTML-
Namensraum mit einem Namensraumpr@fix angegeben werden; sie sollten sich nicht auf den
XML-Default-Namensraum verlassen.
Jedes XHTML-konforme Modul, das in Form einer XML-DTD implementiert ist, muss ein
Default-Namensraumpr@fix, eine M=glichkeit, dieses Pr@fix innerhalb einer Dokumentinstanz
zu @ndern, sowie einen ausgezeichneten Abschnitt (marked section) besitzen, der die Verarbei-
tung des Pr@fixes einschaltet.
Beachten Sie, dass es erlaubt ist und erwartet wird, dass mehrere verwandte Module Teil des-
selben Namensraums sind. Zum Beispiel sind alle XHTML-Module Teil desselben Namens-
raums.
D.2.1 Teilmodul f-r qualifizierte Namen
Als erstes m ssen Sie ein Teilmodul f r qualifizierte Namen definieren (ein Teilmodul ist ledig-
lich ein Datei-Entity, das getrennt ist, um in die end ltige DTD an geeigneter Stelle eingef gt zu
werden). Das Teilmodul f r qualifizierte Namen wird gem@ß den folgenden Schritten erstellt
(dabei wird MODULE durch eine geeignete Zeichenkette f r das neue Modul ersetzt):
1. Definiere ein Parameter-Entity [Link], das anzeigt, ob die Elementnamen im
Modul mit XML-Namensraumpr@fixen verwendet werden oder nicht. Der Ausgangswert
dieses Parameter-Entities sollte „%[Link];“ sein. Das Parameter-Entity [Link] ist
< 430 > Erstellen von DTD-Modulen
Page size: 168,00 x 240,00 mm
durch das XHTML-Rahmenwerk als IGNORE definiert. Es kann in einer Dokumentinstanz
benutzt werden, um alle enthaltenen Namensr@ume einzuschalten (inklusive des Namens-
raums der XHTML-Module).
2. Definiere ein Parameter-Entity [Link], das den Namensraumbezeichner f r das
Modul enth@lt.
3. Definiere ein Parameter-Entity [Link], das das vorgegebene Pr@fix enth@lt, wel-
ches verwendet wird, wenn Pr@fixe eingeschalten werden.
4. Definiere ein Parameter-Entity [Link], das den Wert „%[Link];:“ besitzt,
falls Pr@fixe eingeschaltet sind und „“ andernfalls.
5. Definiere ein Parameter-Entity [Link], das die Deklaration f r alle mit
XML-Namensr@umen versehenen Attribute enth@lt, die Namensr@ume außerhalb dieses
Moduls referenzieren (zum Beispiel xmlns:xlink). Sobald %[Link] auf INCLUDE
gesetzt wird, dann sollte dieses Attribut auch die Deklaration xmlns:%[Link]; ent-
halten.
Modularisierung von XHTML
6. Definiere ein Parameter-Entity [Link] als [Link].
Dies wird blicherweise durch den Treiber des Dokumenttyps berschrieben, aber falls
nicht, wird diese Definition einspringen.
7. Lege f r jeden durch das Modul definierten Elementtyp ein Parameter-Entity der Form
„[Link]“, das dessen qualifizierten Namen enth@lt. Der Wert dieses Para-
meter-Entities muss „%[Link];NAME“ lauten. Auf diese Weise wird der ersetzte
Wert „PREFIX:NAME“ lauten, falls Pr@fixe eingeschalten sind und „NAME“ im anderen Fall.
Falls das Modul Attribute f r solche Elemente hinzuf gt, die in Modulen definiert sind, die
sich nicht im gleichen Namensraum befinden, dann deklariere diese Attribute so, dass sie
das Pr@fix %[Link] verwenden. Zum Beispiel:
<!ENTITY % [Link] "%[Link];myattr" >
Ein Beispiel f r ein qname-Teilmodul f r ein hypothetisches Inventarmodul ist Folgendes:
<!- - ...................................................................... - ->
<!- - Inventory Qname Module ................................................... - ->
<!- - file: [Link]
PUBLIC "-//MY COMPANY//ELEMENTS XHTML Inventory Qnames 1.0//EN"
SYSTEM "[Link]
xmlns:inventory="[Link]
...................................................................... - ->
<!- - Declare the default value for prefixing of this module's elements - ->
<!- - Note that the [Link] will get overridden by the XHTML Framework or
by a document instance. - ->
<!ENTITY % [Link] "IGNORE" >
<!ENTITY % [Link] "%[Link];" >
<!- - Declare the actual namespace of this module - ->
<!ENTITY % [Link] "[Link] >
<!- - Declare the default prefix for this module - ->
<!ENTITY % [Link] "inventory" >
Definieren des Namensraums f#r ein Modul < 431 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!- - Declare the prefix for this module - ->
<![%[Link];[
<!ENTITY % [Link] "%[Link];:" >
]]>
<!ENTITY % [Link] "" >
<!- - Declare the xml namespace attribute for this module - ->
<![%[Link];[
<!ENTITY % [Link]
"xmlns:%[Link]; %[Link]; #FIXED '%[Link];'" >
]]>
<!ENTITY % [Link] "" >
<!- - Declare the extra namespace that should be included in the XHTML
elements - ->
<!ENTITY % [Link]
%[Link]; >
Modularisierung von XHTML
<!- - Now declare the qualified names for all of the elements in the
module - ->
<!ENTITY % [Link] "%[Link];shelf" >
<!ENTITY % [Link] "%[Link];item" >
<!ENTITY % [Link] "%[Link];desc" >
<!ENTITY % [Link] "%[Link];sku" >
<!ENTITY % [Link] "%[Link];price" >
D.2.2 Deklarationsteilmodul(e)
Als n@chstes m ssen Sie ein oder mehrere „Deklarationsteilmodule“ definieren. Der Zweck
dieser Datei-Entities besteht in der Deklaration der XML-DTD-Elemente und -Attributlisten.
Ein XHTML-Deklarationsteilmodul sollte wie folgt aufgebaut werden:
1. Definiere ein Parameter-Entity zur Verwendung innerhalb der ATTLIST jedes deklarierten
Elements. Dieses Parameter-Entity sollte %[Link]; enthalten, falls %[Link]-
xed; auf INCLUDE gesetzt ist und %[Link]; plus "xmlns %[Link]; #FIXED
'%[Link];'", falls %[Link]; auf IGNORE gesetzt ist.
2. Deklariere alle Elemente und Attribute des Moduls. F ge das oben definierte Parameter-
Entity zu jeder ATTLIST eines Elements, so dass alle erforderlichen xmlns-Attribute f r
jedes Element des Moduls verf gbar sind.
3. Falls das Modul Attribute f r Elemente definiert, die in Modulen definiert sind, die sich nicht
im selben Namensraum befinden, deklariere solche Attribute mit dem Pr@fix %MODU-
[Link]. Zum Beispiel:
<!ENTITY % [Link] "%[Link];myattr" >
<!ATTLIST %[Link];
%[Link]; CDATA #IMPLIED
>
Dies w rde dem img-Element des Bildmoduls ein Attribut hinzuf gen. Der Name des Attri-
buts w@re der qualifizierte Name, einschließlich Pr@fix, sofern Pr@fixe f r eine Dokument-
instanz aktiviert w@ren. Es w rde zudem das Attribut xmlns:MODULE_PREFIX der Attri-
butliste des img-Elements hinzuf gen, so dass ein namensraumf@higer XML-Parser wissen
w rde, wie er das Namensraumpr@fix aufzul=sen h@tte.
< 432 > Erstellen von DTD-Modulen
Page size: 168,00 x 240,00 mm
Das folgende Beispiel zeigt ein Deklarationsteilmodul f r ein hypothetisches Inventarmodul:
<!- - ...................................................................... - ->
<!- - Inventory Elements Module ...................................................
- ->
<!- - file: [Link]
PUBLIC "-//MY COMPANY//ELEMENTS XHTML Inventory Elements 1.0//EN"
SYSTEM "[Link]
xmlns:inventory="[Link]
...................................................................... - ->
<!- - Inventory Module
shelf
item
Modularisierung von XHTML
sku
desc
price
This module defines a simple inventory item structure
- ->
<!- - Define the global namespace attributes - ->
<![%[Link];[
<!ENTITY % [Link]
"%[Link];"
>
]]>
<!ENTITY % [Link]
"xmlns %[Link]; #FIXED '%[Link];'"
>
<!- - Define a common set of attributes for all module elements - ->
<!ENTITY % [Link]
"%[Link];
id ID #IMPLIED
>
<!- - Define the elements and attributes of the module - ->
<!ELEMENT %[Link];
( %[Link]; )* >
<!ATTLIST %[Link];
location CDATA #IMPLIED
%[Link];
>
<!ELEMENT %[Link];
( %[Link];, %[Link];, %[Link];) >
<!ATTLIST %[Link];
location CDATA #IMPLIED
%[Link];
>
<!ELEMENT %[Link]; ( #PCDATA ) >
<!ATTLIST %[Link];
Definieren des Namensraums f#r ein Modul < 433 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
%[Link];
>
<!ELEMENT %[Link]; ( #PCDATA ) >
<!ATTLIST %[Link];
%[Link];
>
<!ELEMENT %[Link]; ( #PCDATA ) >
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->
D.2.3 Einsatz eines Moduls als alleinstehende DTD
Modularisierung von XHTML
Manchmal ist es w nschenswert, ein XHTML-Modul auch als alleinstehende DTD verwenden
zu k=nnen. Ein gutes Beispiel daf r, ist unser obiges Inventarmodul. Die „Items“ m ssen in ein
XHTML-Dokument einzubetten sein und zudem beispielsweise als alleinstehende, aus einer
Datenbank exportierte Dokumente verf gbar sein. Der einfachste Weg, dies zu erreichen, ist
das Definieren einer DTD-Datei, die die Komponenten des Moduls instanziiert. Solch eine
DTD w rde die folgende Struktur besitzen:
1. Einbinden des XHTML-Datentypmoduls (das qnames-Modul wird wahrscheinlich einige
Datentypen benutzen – in jedem Fall den URI-Datentyp f r das xmlns-Attribut).
2. Einbinden des qnames-Moduls in das eigene Modul.
3. Definieren des Parameter-Entities [Link] als %[Link];.
4. Einbinden des Deklarationsmoduls in das eigene Modul.
Am Beispiel des Inventarmoduls sieht das wie folgt aus:
<!- - ...................................................................... - ->
<!- - Inventory Elements DTD ............................................... - ->
<!- - file: [Link]
PUBLIC "-//MY COMPANY//DTD XHTML Inventory 1.0//EN"
SYSTEM "[Link]
xmlns:inventory="[Link]
...................................................................... - ->
<!- - Inventory Module
shelf
item
sku
desc
price
This module defines a simple inventory item structure
- ->
<!- - Bring in the datatypes - ->
< 434 > Erstellen von DTD-Modulen
Page size: 168,00 x 240,00 mm
<!ENTITY % [Link]
PUBLIC "-//W3C//ENTITIES XHTML Datatypes 1.0//EN"
"[Link] >
%[Link];
<!- - Bring in the qualified names - ->
<!ENTITY % [Link] SYSTEM "[Link]" >
%[Link];
<!ENTITY % [Link] "%[Link];">
<!ENTITY % [Link] SYSTEM "[Link]" >
%[Link];
<!- - end of [Link] - ->
Die DTD kann dann aus Dokumenten heraus referenziert werden, die nur die Elemente aus
Modularisierung von XHTML
dem eigenen Modul benutzen:
<!DOCTYPE shelf SYSTEM "[Link]">
<shelf xmlns="[Link]
<item>
<desc>
this is a description.
</desc>
<sku>
this is the price.
</sku>
<price>
this is the price.
</price>
</item>
</shelf>
Diese Vorgehensweise erlaubt die Definition von Elementen und Attributen, die sich im Gel-
tungsbereich ihres eigenen Namensraums befinden. Zudem k=nnen Autoren das vorgegebene
Pr@fix f r Elemente und Attribute verwenden:
<!DOCTYPE inventory:shelf SYSTEM "[Link]" [
<!ENTITY % [Link] "INCLUDE">
]>
<inventory:shelf xmlns:inventory="[Link]
<inventory:item>
<inventory:desc>
this is a description.
</inventory:desc>
<inventory:sku>
this is the sku.
</inventory:sku>
<inventory:price>
this is the price.
</inventory:price>
</inventory:item>
</inventory:shelf>
Definieren des Namensraums f#r ein Modul < 435 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Schließlich kann eine Dokumentinstanz ein anderes XML-Namensraumpr@fix durch Umdekla-
rierung in der internen DTD-Teilmenge:
<!DOCTYPE i:shelf SYSTEM "[Link]" [
<!ENTITY % [Link] "INCLUDE">
<!ENTITY % [Link] "i">
]>
<i:shelf xmlns:i="[Link]
<i:item>
<i:desc>
this is a description.
</i:desc>
<i:sku>
this is the price.
</i:sku>
<i:price>
Modularisierung von XHTML
this is the price.
</i:price>
</i:item>
</i:shelf>
D.2.4 Eigenheiten von [Link]
W@hrend der hier gezeigte Ansatz die Definition von Auszeichnungssprachen erlaubt, die XML-
und XML-Namensraumkonform sind, werden einige Eigenschaften von XML-Namensr@umen
nicht unterst tzt:
1. XML-Namensr@ume gestatten die Neudeklarierung des xmlns-Attributs f r einen Namens-
raum an jeder Stelle im Baum. Dar ber hinaus erlaubt diese Neudeklarierung zwischen vor-
gegebenem Namensraum (kein Pr@fix) und Verwendung des Pr@fixes umzuschalten und das
Pr@fix zu @ndern. Die Methode, die in diesem Dokument definiert wurde, l@sst das nicht zu.
In der gesamten Dokumentinstanz muss ein vorgegebener Namensraum dasselbe Pr@fix
(falls eines benutzt wird) oder keines verwenden.
2. Falls der vorgegebene Namensraum (kein Pr@fix) verwendet wird, darf man sich darauf ver-
lassen, dass die DTD der Dokumente den Parser ber den Namensraum von Elementen
informiert. Da aber namensraumf@hige Prozessoren die DTD nicht unbedingt lesen m ssen,
sollten Autoren den XML-Namensraum eines Elements immer deklarieren, wenn er sich
@ndert:
...
<p>
<myelement xmlns="..." />
</p>
< 436 > Erstellen von DTD-Modulen
Page size: 168,00 x 240,00 mm
E Entwickeln von DTDs mit
definierten und erweiterten
Modulen
Dieser Abschnitt ist informell.
Der prim@re Zweck der Definition von XHTML-Modulen und einer allgemeinen Methodik zur
Modularisierung besteht darin, die Entwicklung von XHTML-basierten Dokumenttypen zu ver-
einfachen. Diese Dokumenttypen k=nnen XHTML durch Integration weiterer F@higkeiten
erweitern (zum Beispiel [SMIL]), oder sie k=nnen eine Teilmenge von XHTML f r den Einsatz
mit einem speziellen Ger@t definieren. Dieser Abschnitt beschreibt, welche Techniken die Ent-
wickler von Dokumenttypen anwenden m ssen, um die XML-DTD-Implementierung der
Modularisierungsarchitektur nutzen zu k=nnen. Er macht dies durch Anwendung der Modulari-
Modularisierung von XHTML
sierungstechniken in einer nach und nach komplexeren Weise, die schließlich in der Erschaffung
eines vollst@ndigen Dokumenttyps aus voneinander unabh@ngigen Modulen m ndet.
Beachten Sie, dass es diese Beispiele in keinem Fall erforderlich machen, die durch XHTML zur
Verf gung gestellten Datei-Entities der Module zu modifizieren. Die Datei-Entities der
XHTML-Module sind vollst@ndig parametrisiert. Dadurch ist es durch separate Moduldefinitio-
nen und Treiber m=glich, die Definition und das Inhaltsmodell von jedem Element und jeder
Elementhierachie zu @ndern.
Abschließend sollten Sie daran denken, dass die meisten Anwender von XHTML vermutlich
keine DTD-Autoren sind. DTD-Autoren sind in der Regel Menschen, die spezialisierte Aus-
zeichnungen definieren, welche die Lesbarkeit erh=hen, die Darstellung eines Dokuments ver-
einfachen, die maschinelle Verarbeitung von Dokumenten erleichtern, oder sie sind Entwickler
von Client-Software, die die spezialisierte DTD f r ihren jeweiligen Client entwerfen. Beden-
ken Sie die folgenden F@lle:
· Eine Organisation stellt Informationen ber Mitglieder mittels einer Web-Schnittstelle zur
Verf gung. Die Mitgliederdaten sind in einer XML-basierten Datenbasis gespeichert. Ein
Weg, die Daten aus der Datenbasis ins Web zu bringen, besteht darin, die XML-Datens@tze
direkt in das XHTML-Dokument einzubetten. Abgesehen von der M=glichkeit, die Daten-
s@tze schlicht einzubetten, kann die Organisation ein DTD-Modul definieren, das die Daten-
s@tze beschreibt. Dieses Modul wird an eine XHTML-DTD gekoppelt, und damit entsteht
eine vollst@ndige DTD f r die Seiten. Nun ist es m=glich, auf die Daten innerhalb der neuen
Elemente per Document Object Model [DOM] zuzugreifen, die Dokumente zu validieren,
unter Verwendung von Cascading Style Sheets [CSS2] kaskadierende Formatierungsdefi-
nitionen vorzunehmen und so weiter. Dank der sauberen Definition der Datenstruktur und
der Schaffung der DTD mittels des hier beschriebenen Vorgehens, kann die Organisation
den ganzen Nutzen von XML erzielen.
· Ein Entwickler entwirft ein spezielles Ger@t mit einem Internet-Client. Dieses Ger@t wird
nur einen Teil von XHTML unterst tzen und wird auf das Internet nur ber einen Proxy-
Server zugreifen, der die Daten vor der Weiterleitung an den Client validiert (um die Feh-
lerbehandlung auf Seiten des Clients zu minimieren). Der Entwickler entwirft eine DTD,
um sicherzustellen, dass der Inhalt g ltig ist. Die DTD stellt eine Teilmenge von XHTML
dar und entsteht mit der hier beschriebenen Vorgehensweise. Nun k=nnen der Proxy-Ser-
ver und die Ger@te die neue DTD verwenden. Zudem kann die DTD ver=ffentlicht werden,
damit Autoren ihre Dokumente vor dem Publizieren validieren k=nnen. Mit wenigen, ein-
Entwickeln von DTDs < 437 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
fachen Schritten kann der Client-Entwickler die in diesem Dokument definierte Architektur
einsetzen, um die Entwicklungskosten f r die DTD zu senken und um sicherzustellen, dass
er die ausgew@hlte XHTML-Teilmenge vollst@ndig unterst tzt.
E.1 Definition [Link] Attribute
Eine Erweiterung von XHTML kann auch nur aus zus@tzlichen Attributen bestehen. Attribute
lassen sich einem Element durch eine zus@tzliche ATTLIST f r den Elementtyp zuf gen. Zum
Beispiel:
<!ATTLIST %[Link];
%[Link];myattr CDATA #IMPLIED
%[Link];
>
Modularisierung von XHTML
Dies w rde das Attribut „myattr“, mit dem optionalen, durch „%[Link]“ definierten
Pr@fix, dem Element „a“ hinzuf gen. Das funktioniert, weil XML die Definition oder Erweite-
rung einer Attributliste an jeder Stelle in einer DTD gestattet. Eine Beschreibung von qualifi-
zierten Namen und Namensraumpr@fixen finden Sie in Abschnitt D.2 (Definieren des Namens-
raums f r ein Modul).
Selbstverst@ndlich bedeutet das Hinzuf gen eines Attributs zu einer DTD nicht, dass irgendein
neues Verhalten f r beliebige Clients definiert w@re. Ein Autor k=nnte das zus@tzliche Attribut
aber dazu verwenden, um Information darin abzulegen, die etwa durch Skripte per Document
Object Model verarbeitet werden.
E.2 Definition [Link] Elemente
Die Definition zus@tzlicher Elemente ist nur wenig schwieriger als die Definition neuer Attribu-
te. Im Wesentlichen sollten DTD-Autoren die Elementdeklaration f r jedes Element schreiben:
<!- - In the qname sub-module - ->
<!ENTITY % [Link] "%[Link];myelement" >
<!ENTITY % [Link] "%[Link];myotherelement" >
<!- - In the declaration sub-module - ->
<!ELEMENT %[Link];
( #PCDATA | %[Link]; )* >
<!ATTLIST %[Link];
myattribute CDATA #IMPLIED
>
<!ELEMENT %[Link]; EMPTY >
Nachdem die Elemente deklariert sind, m ssen sie in das Inhaltsmodell integriert werden. Stra-
tegien f r die Integration eines neuen oder mehrerer neuer Elemente in das Inhaltsmodell wer-
den im folgenden Abschnitt besprochen.
< 438 > Entwickeln von DTDs
Page size: 168,00 x 240,00 mm
E.3 Definition des Inhaltsmodells f-r eine Modulsammlung
Weil die Inhaltsmodelle der XHTML-Module v=llig parametrisiert sind, k=nnen DTD-Autoren
diese f r jedes Element in jedem Modul @ndern. Die Details der DTD-Modulschnittstellen sind
im Abschnitt D (Building DTD Modules) definiert. Im Wesentlichen gibt es zwei Ans@tze:
1. Definieren Sie das Parameter-Entity “.content“ f r jedes Element neu.
2. Definieren Sie eines oder mehrere der globalen Inhalstmodell-Entities neu (normalerweise
mittels des Parameter-Entities “.extras“).
Welche Strategie zu w@hlen ist, h@ngt von der Natur der zu kombinierenden Module und von
der Natur der zu integrierenden Elemente ab. Der Rest dieses Abschnitts beschreibt Tech-
niken f r die Integration von Modulen zweier verschiedener Klassen.
E.3.1 Integration eines alleinstehenden Moduls mit XHTML
Modularisierung von XHTML
Wenn ein Modul (nicht zu vergessen, dass ein Modul eine Sammlung anderer Module sein kann)
Elemente enth@lt, die sich in ihren Inhaltsmodellen nur untereinander referenzieren, nennt man
es „in sich vollst@ndig“. Als ein solches kann das Modul alleinstehend verwendet werden (zum
Beispiel kann eine DTD nur aus diesem Modul bestehen, und eines der Elemente dient als
Wurzelelement). Die Integration eines solchen Moduls mit XHTML ist ein dreistufiger Prozess:
1. Entscheiden Sie, welche(s) Element(e) als Wurzel(n) des neuen Modul in Frage kommen.
2. Entscheiden Sie, wo diese Elemente in den XHTML-Baum eingeh@ngt werden m ssen.
3. F gen Sie dann f r jeden Aufh@ngpunkt das oder die Wurzelelemente zur Inhaltsdefinition
des XHTML-Elements hinzu.
Nehmen wir an, wie wollen die in E.2 deklarierten Elemente hinzuf [Link] diesem Beispiel ist
myelement die Wurzel. Um dieses Element unterhalb des img-Elements von XHTML hinzuzuf -
gen, und nur darunter, k=nnte man wie folgt vorgehen:
<!ENTITY % [Link] "( %[Link]; )*">
Eine DTD mit diesem Inhaltsmodell w rde ein Dokument mit folgendem Ausschnitt zulassen:
<img src="...">
<myml:myelement >This is content of a locally defined element</myml:myelement>
</img>
Es ist wichtig, darauf hinzuweisen, dass das img-Element normalerweise das Inhaltsmodell EMPTY
besitzt. Durch das Hinzuf gen von myelement zum Inhaltsmodell, wird tats@chlich nur EMPTY
durch myelement ersetzt. Im Fall von anderen Elementen, die bereits ein definiertes Inhalts-
modell besitzen, w rde das Hinzuf gen eines Elements die vollst@ndige bernahme des vorhan-
denen Inhaltsmodells zuz glich myelement erfordern.
Definition des Inhaltsmodells f#r Modulsammlungen < 439 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
E.3.2 Einmischen eines neuen Moduls in alle XHTML-Module
In Erweiterung des obigen Beispiel wollen wir nun dieses Modul berall dort einbringen, wo die
Inhaltsmodellgruppe „%[Link]“ erlaubt ist. Das geht beispielsweise so:
<!ENTITY % [Link]
"| %[Link];" >
Da die Inhaltsmodellklasse „%[Link]“ im Parameter-Entity „%[Link]“ benutzt wird, und
weil dieses Parameter-Entity durchg@ngig in allen XHTML-Modulen zum Einsatz kommt, w@re
das neue Modul durchg@ngig in dem erweiterten XHTML-Dokumenttyp verf gbar.
E.4 Erstellen einer neuen DTD
Modularisierung von XHTML
Bis hierhin haben die Beispiele die Methoden zur Erweiterung von XHTML und ihren Inhalts-
modellen gezeigt. Ist dies erst einmal geschehen, besteht der folgende Schritt darin, die Module,
die die DTD bilden, zu einem einzigen DTD-Treiber zusammenzufassen. Der Treiber enth@lt
die neuen Definitionen, so dass sie die zugrunde liegenden XHTML-Definitionen berschreiben
beziehungsweise erweitern.
E.4.1 Erstellen einer einfachen DTD
Unter Verwendung des einfachen Beispiels von oben, l@sst sich eine neue DTD definieren, die
sehr einfach die XHTML-Module benutzt und erweitert. Als erstes definieren wir die neuen
Elemente und ihre Inhaltsmodelle in einem Modul:
<!- - File: [Link] - ->
<!- - Declare a Parameter Entity (PE) that defines any external namespaces
that are used by this module - ->
<!- - Set the PE that is used in every ATTLIST in this module
[Link] is initialized in the xhtml-qname module, and
[Link] is initialized in the SimpleML DTD driver
file.- ->
<!ENTITY % [Link]
"%[Link];"
>
<!ENTITY % [Link]
"%[Link];
id ID #IMPLIED"
>
<!ENTITY % [Link] "%[Link];element" >
<!ENTITY % [Link] "%[Link];otherelement" >
<!ELEMENT %[Link];
( #PCDATA | %[Link]; )* >
<!ATTLIST %[Link];
< 440 > Entwickeln von DTDs
Page size: 168,00 x 240,00 mm
myattribute CDATA #IMPLIED
%[Link];
>
<!ELEMENT %[Link]; EMPTY >
<!ATTLIST %[Link];
%[Link];
>
<!ENTITY % [Link] "%[Link];myattr" >
<!ATTLIST %[Link];
%[Link]; CDATA #IMPLIED
>
<!- - Add our elements to the XHTML content model - ->
<!ENTITY % [Link]
"| %[Link];" >
Modularisierung von XHTML
<!- - Now bring in the XHTML Basic content model - ->
<!ENTITY % [Link]
PUBLIC "-//W3C//ENTITIES XHTML Basic 1.0 Document Model 1.0//EN"
"[Link] >
%[Link];
Als n@chstes definieren wir den DTD-Treiber f r die neue Sprache:
<!- - file: simpleml-1_0.dtd - ->
<!- - Bring in the XHTML datatypes - ->
<!ENTITY % [Link]
PUBLIC "-//W3C//ENTITIES XHTML Datatypes 1.0//EN"
"[Link] >
%[Link];
<!- - Declare the actual namespace of this module - ->
<!ENTITY % [Link] "[Link] >
<!- - By default, disable prefixing of new module - ->
<!ENTITY % [Link] "IGNORE" >
<!ENTITY % [Link] "%[Link];" >
<!- - Default prefix for module elements and attributes - ->
<!ENTITY % [Link] "simpleml" >
<!- - If this module's namespace is prefixed - ->
<![%[Link];[
<!ENTITY % [Link] "%[Link];:" >
]]>
<!ENTITY % [Link] "" >
<![%[Link];[
<!ENTITY % [Link]
"xmlns:%[Link]; %[Link]; #FIXED '%[Link];'" >
]]>
<!ENTITY % [Link] "" >
Erstellen einer neuen DTD < 441 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!ENTITY % [Link]
"%[Link];"
>
<!- - Set the content model for our language - ->
<!ENTITY % [Link]
SYSTEM "[Link]" >
<!- - Instantiate xhtml basic's DTD to do all the work - ->
<!ENTITY % [Link]
PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"[Link] >
%[Link];
Bei Einsatz dieser DTD lassen sich XML-Namensraumpr@fixe wie im folgenden Beispiel ein-
schalten:
<!DOCTYPE html SYSTEM "simpleml-1_0.dtd" [
Modularisierung von XHTML
<!ENTITY % [Link] "INCLUDE">
]>
<html xmlns="[Link]
xmlns:simpleml="[Link] >
<head>
<title>An example using defaults</title>
</head>
<body>
<p>This is content in the XHTML namespace</p>
<simpleml:element>
This is content in the SimpleML namespace.
<simpleml:otherelement />
</simpleml:element>
<p><img src="missing" alt="Missing image" simpleml:myattr="value"/></p>
</body>
</html>
E.4.2 Erstellen einer DTD durch Erweiterung von XHTML
Als n@chstes folgt der Fall, wobei ein vollst@ndiges, zus@tzliches und komplexes Modul zu
XHTML (oder einer Teilmenge von XHTML) hinzugef gt wird. Im Grunde ist es das gleiche
wie in dem trivialen Beispiel oben. Der einzige Unterschied besteht darin, dass das Modul durch
Referenzierung in die DTD eingebaut wird und nicht durch explizite Aufnahme der neuen Defi-
nitionen.
Ein solches komplexes Modul ist die DTD f r [MATHML]. Um MathML und XHTML in einer
einzigen DTD zu integrieren, w rde ein Autor nur entscheiden, wo MathML-Inhalt im Doku-
ment zul@ssig ist und dann das Wurzelelement von MathML an dieser Stelle dem Inhaltsmodell
hinzuf [Link] erstes definieren wir ein Modul f r das Inhaltsmodell, instanziieren die Math-
ML-DTD und verbinden sie mit dem Inhaltsmodell:
<!- - File: [Link] - ->
<!ENTITY % XHTML1-math
PUBLIC "-//W3C//DTD MathML 2.0//EN"
"[Link] >
%XHTML1-math;
< 442 > Entwickeln von DTDs
Page size: 168,00 x 240,00 mm
<!ENTITY % [Link]
"%[Link]; | %[Link]; | %[Link]; | %[Link];
| %[Link];" >
Als n@chstes definieren wir den DTD-Treiber, der unser neues Inhaltsmodellmodul als Inhalts-
modell f r die DTD benennt und dann die weitere Arbeit beispielsweise dem Treiber von
XHTML 1.1 berl@sst:
<!- - File: [Link] - ->
<!ENTITY % [Link]
SYSTEM "[Link]" >
<!ENTITY % [Link]
PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"[Link] >
%[Link];
Modularisierung von XHTML
E.4.3 Erstellen einer DTD durch Entfernen und Ersetzen von
XHTML-Modulen
Eine weitere M=glichkeit, wie DTD-Autoren XHTML-Module benutzen k=nnen, besteht in der
Definition einer DTD, die aus einer Teilmenge eines Dokumenttyps der XHTML-Familie
besteht (zum Beispiel weil sie Ger@te oder Software entwickeln, die nur einen Teil von XHTML
unterst tzen). Dies zu tun, ist nur wenig aufwendiger als das vorhergehende Beispiel. Die
wesentlichen Schritte sind:
1. Nehmen Sie eine DTD der XHTML-Familie als Startpunkt des neuen Dokumenttyps (wir
werden XHTML 1.1 nehmen).
2. W@hlen Sie die Module, die aus dieser DTD entfernt werden sollen.
3. Definieren Sie eine neue DTD, die die Module ignoriert („IGNORE“).
4. Bauen Sie ein paar neue Module ein.
Nehmen wir beispielsweise ein Ger@t an, das XHTML-Module, jedoch ohne Formulare und
Tabellen benutzt. Die DTD f r ein solches Ger@t s@he wie folgt aus:
<!- - File: [Link] - ->
<!ENTITY % [Link] "IGNORE" >
<!ENTITY % [Link] "IGNORE" >
<!ENTITY % [Link] "IGNORE" >
<!- - Bring in the basic tables module - ->
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Basic Tables 1.0//EN"
"[Link]
>
%[Link];
<!ENTITY % [Link]
PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"[Link] >
%[Link];
Beachten Sie, dass die Inhaltsmodelle der XHTML 1.1-DTD dadurch in keiner Weise ver@ndert
werden. Da XML jedoch Elemente, in nicht definierten Inhaltsmodellen ignoriert, werden die
Formular- und Tabellenelemente automatisch aus dem Modell entfernt.
Erstellen einer neuen DTD < 443 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
E.4.4 Erstellen einer neuen DTD
Schließlich wollen einige DTD-Autoren vielleicht von vorn beginnen und das Modularisierungs-
rahmenwerk von XHTML als Baukasten f r eine neue Auszeichnungssprache nutzen. Diese
Sprache muss aus den mindestens ben=tigten Modulen von XHTML bestehen. Dar ber hinaus
darf sie andere XHTML-definierte Module oder jedes andere Modul enthalten, das der Autor
einbauen m=chte. In diesem Beispiel nehmen wir die notwendigen XHTML-Module, erg@nzen
ein paar weitere XHTML-Module und zudem das oben definierte Modul.
Im ersten Schritt benutzen wir das durch XHTML bereitgestellte Muster ([Link]/TR/
xhtml-modularization/DTD/templates/[Link]) f r ein neues Teilmodul f r
qualifizierte Namen; wir @ndern es, um die qualifizierten Namen und Namensr@ume f r unsere
neuen Elemente zu definieren.
<!- - file: [Link] - ->
Modularisierung von XHTML
<!- - Bring in the datatypes - we use the [Link] PE for declaring the
xmlns attributes. - ->
<!ENTITY % [Link]
PUBLIC "-//W3C//ENTITIES XHTML Datatypes 1.0//EN"
"[Link] >
%[Link];
<!- - By default, disable prefixing of this module - ->
<!ENTITY % [Link] "IGNORE" >
<!ENTITY % [Link] "%[Link];" >
<!- - Declare the actual namespace of this module - ->
<!ENTITY % [Link] "[Link] >
<!- - Declare the default prefix for this module - ->
<!ENTITY % [Link] "myml" >
<!- - If this module's namespace is prefixed - ->
<![%[Link];[
<!ENTITY % [Link] "%[Link];:" >
]]>
<!ENTITY % [Link] "" >
<!- - Declare a Parameter Entity (PE) that defines any external namespaces
that are used by this module - ->
<!ENTITY % [Link] "" >
<!- - Declare a PE that defines the xmlns attributes for use by MyML. - ->
<![%[Link];[
<!ENTITY % [Link]
"xmlns:%[Link]; %[Link]; #FIXED '%[Link];'
%[Link];"
>
]]>
<!ENTITY % [Link]
"xmlns %[Link]; #FIXED '%[Link];'
%[Link];"
>
< 444 > Entwickeln von DTDs
Page size: 168,00 x 240,00 mm
<!- - Make sure that the MyML namespace attributes are included on the XHTML
attribute set - ->
<![%[Link];[
<!ENTITY % [Link]
"%[Link];" >
]]>
<!ENTITY % [Link]
""
>
<!- - Now declare the element names - ->
<!ENTITY % [Link] "%[Link];myelement" >
<!ENTITY % [Link] "%[Link];myotherelement" >
Als n@chstes definieren wir ein Modul mit den Element- und Attributdefinitionen auf Basis des
entsprechenden Musters ([Link]/TR/xhtml-modularization/DTD/templates/template-1.
Modularisierung von XHTML
mod).
<!- - ...................................................................... - ->
<!- - My Elements Module ................................................... - ->
<!- - file: myml-elements-1_0.mod
PUBLIC "-//MY COMPANY//ELEMENTS XHTML MyML Elements 1.0//EN"
SYSTEM "[Link]
xmlns:myml="[Link]
...................................................................... - ->
<!- - My Elements Module
myelement
myotherelement
This module has no purpose other than to provide structure for some
PCDATA content.
- ->
<!ELEMENT %[Link];
( #PCDATA | %[Link]; )* >
<!ATTLIST %[Link];
myattribute CDATA #IMPLIED
%[Link];
>
<!ELEMENT %[Link]; EMPTY >
<!ATTLIST %[Link];
%[Link];
>
<!ENTITY % [Link] "%[Link];myattr" >
<!ATTLIST %[Link];
%[Link]; CDATA #IMPLIED
%[Link];
Erstellen einer neuen DTD < 445 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
>
<!- - end of myml-elements-1_0.mod - ->
Nun schreiben wir Inhaltsmodelle, die die neuen Elemente und Attribute in die anderen
XHTML-Elemente einh@ngen. Das folgende Beispiel ist entsprechend dem Inhaltsmodell von
XHTML-Basic aufgebaut, es ist jedoch ein vollst@ndiges, unabh@ngiges Inhaltsmodellmodul:
<!- - ...................................................................... - ->
<!- - MyML Model Module ................................................... - ->
<!- - file: [Link]
PUBLIC "-//MY COMPANY//ELEMENTS XHTML MyML Model 1.0//EN"
SYSTEM "[Link]
xmlns:myml="[Link]
Modularisierung von XHTML
...................................................................... - ->
<!- - Define the content model for [Link] - ->
<!ENTITY % [Link]
"| %[Link]; ">
<!- - .................... Inline Elements ...................... - ->
<!ENTITY % [Link]
"( %[Link]; )*" >
<!ENTITY % [Link] "" >
<!ENTITY % [Link] "%[Link]; | %[Link];" >
<!ENTITY % [Link]
"| %[Link]; | %[Link]; | %[Link]; | %[Link];
| %[Link]; | %[Link]; | %[Link]; | %[Link];
| %[Link]; | %[Link]; | %[Link];" >
<!ENTITY % [Link]
"" >
<!ENTITY % [Link] "| %[Link];" >
<!ENTITY % [Link] "| %[Link]; " >
<!ENTITY % [Link] "" >
<!- - %[Link]; includes all inline elements,
used as a component in mixes
- ->
<!ENTITY % [Link]
"%[Link];
%[Link];
%[Link];
%[Link];
%[Link];"
>
< 446 > Entwickeln von DTDs
Page size: 168,00 x 240,00 mm
<!- - %[Link]; includes all non-anchor inlines,
used as a component in mixes
- ->
<!ENTITY % [Link]
"%[Link];
%[Link];
%[Link];
%[Link];"
>
<!- - %[Link]; includes all non-anchor inlines
- ->
<!ENTITY % [Link]
"%[Link];
%[Link];"
>
Modularisierung von XHTML
<!- - %[Link]; includes all inline elements, including %[Link];
- ->
<!ENTITY % [Link]
"%[Link];
%[Link];"
>
<!- - ..................... Block Elements ...................... - ->
<!ENTITY % [Link]
"%[Link]; | %[Link]; | %[Link];
| %[Link]; | %[Link]; | %[Link];" >
<!ENTITY % [Link] "%[Link]; | %[Link]; | %[Link];" >
<!ENTITY % [Link] "%[Link]; | %[Link];" >
<!ENTITY % [Link]
"| %[Link]; | %[Link]; | %[Link];" >
<!ENTITY % [Link] "" >
<!ENTITY % [Link] "" >
<!- - %[Link]; includes all block elements,
used as an component in mixes
- ->
<!ENTITY % [Link]
"%[Link];
%[Link];
%[Link];
%[Link];"
>
<!- - %[Link]; includes all block elements plus %[Link];
- ->
<!ENTITY % [Link]
"%[Link];
Erstellen einer neuen DTD < 447 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
| %[Link];
| %[Link];
%[Link];"
>
<!- - ................ All Content Elements .................. - ->
<!- - %[Link]; includes all text content, block and inline
- ->
<!ENTITY % [Link]
"%[Link];
| %[Link];
| %[Link];
| %[Link];
%[Link];"
>
Modularisierung von XHTML
<!- - special content model for pre element - ->
<!ENTITY % [Link]
"( #PCDATA
| %[Link]; )*"
>
<!- - end of [Link] - ->
Schließlich verwenden wir ein vorgegebenes Muster ([Link]/TR/xhtml-modularization/
DTD/templates/[Link]) f r eine neue DTD, so modifiziert, wie es f r unsere neue Aus-
zeichnungssprache angebracht ist:
<!- - ....................................................................... - ->
<!- - MYML DTD ............................................................. - ->
<!- - file: myml-1_0.dtd - ->
<!- - This is the DTD driver for myml 1.0.
Please use this formal public identifier to identify it:
"-//MY COMPANY//DTD XHTML MYML 1.0//EN"
And this namespace for myml-unique elements:
xmlns:myml="[Link]
- ->
<!ENTITY % [Link] "-//MY COMPANY//DTD XHTML MYML 1.0//EN" >
<!- - reserved for use with document profiles - ->
<!ENTITY % [Link] "" >
<!- - Tell the framework to use our qualified names module as an extra qname
driver - ->
<!ENTITY % [Link]
SYSTEM "[Link]" >
<!- - Define the Content Model for the framework to use - ->
<!ENTITY % [Link]
< 448 > Entwickeln von DTDs
Page size: 168,00 x 240,00 mm
SYSTEM "[Link]" >
<!- - Disable bidirectional text support - ->
<!ENTITY % [Link] "IGNORE" >
<!- - Bring in the XHTML Framework - ->
<!ENTITY % [Link]
PUBLIC "-//W3C//ENTITIES XHTML Modular Framework 1.0//EN"
"[Link] >
%[Link];
<!- - Basic Text Module (Required) ............................... - ->
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Basic Text 1.0//EN"
"[Link] >
%[Link];
Modularisierung von XHTML
<!- - Hypertext Module (required) ................................. - ->
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Hypertext 1.0//EN"
"[Link] >
%[Link];
<!- - Lists Module (required) .................................... - ->
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Lists 1.0//EN"
"[Link] >
%[Link];
<!- - My Elements Module ........................................ - ->
<!ENTITY % [Link]
SYSTEM "[Link]" >
%[Link];
<!- - XHTML Images module ........................................ - ->
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Images 1.0//EN"
"[Link] >
%[Link];
<!- - Document Metainformation Module ............................ - ->
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Metainformation 1.0//EN"
"[Link] >
%[Link];
<!- - Document Structure Module (required) ....................... - ->
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Document Structure 1.0//EN"
"[Link] >
%[Link];
Erstellen einer neuen DTD < 449 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
E.5 Benutzen der neuen DTD
Wenn die DTD erst einmal fertig ist, kann sie in beliebigen Dokumenten benutzt werden. Die
Benutzung besteht einfach aus dem Referenzieren in der DOCTYPE-Deklaration der Instanz:
<!DOCTYPE html SYSTEM "myml-1_0.dtd" >
<html xmlns="[Link] >
<head>
<title>An example using defaults</title>
</head>
<body>
<p>This is content in the XHTML namespace</p>
<myelement>
This is content in the SimpleML namespace.
<myotherelement />
</myelement>
Modularisierung von XHTML
<p><img src="missing" alt="Missing image" myattr="value"/></p>
</body>
</html>
Das Dokument kann die Elemente außerhalb des XHTML-Namensraums auch mit Pr@fixen ver-
wenden:
<!DOCTYPE html SYSTEM "myml-1_0.dtd" [
<!ENTITY % [Link] "INCLUDE" >
]>
<html xmlns="[Link] >
<head>
<title>An example using defaults</title>
</head>
<body>
<p>This is content in the XHTML namespace</p>
<myml:myelement>
This is content in the myml namespace.
<myml:myotherelement />
</myml:myelement>
<p><img src="missing" alt="Missing image" myml:myattr="value" /></p>
</body>
</html>
F Implementierungen von
XHTML-Modulen mit DTDs
Dieser Anhang ist normativ.
Dieser Anhang enth@lt die DTD-Implementierungen der in Abschnitt 5 (Abstrakte XHTML-
Module) definierten Module. Diese Modulimplementierungen k=nnen von jedem Dokumenttyp
der XHTML-Familie benutzt werden.
< 450 > Implementierungen von XHTML-Modulen mit DTDs
Page size: 168,00 x 240,00 mm
F.1 XHTML-Zeichen-Entities
XHTML-DTDs stellen eine Sammlung von benannten Zeichen-Entities zur Verf gung; sie wer-
den in diesem Abschnitt definiert.
Anmerkung der bersetzer: Beachten Sie bitte auch den Abschnitt 24 der kom-
mentierten deutschen bersetzung von HTML 4. Dort finden Sie graphische Darstel-
lungen der Zeichen-Entities im Web-Browser.
F.1.1 XHTML-Latin 1-Zeichen-Entities
<!- - ...................................................................... - ->
Modularisierung von XHTML
<!- - XML-compatible ISO Latin 1 Character Entity Set for XHTML ............ - ->
<!- - file: [Link]
Typical invocation:
<!ENTITY % xhtml-lat1
PUBLIC "-//W3C//ENTITIES Latin 1 for XHTML//EN"
"[Link]" >
%xhtml-lat1;
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//ENTITIES Latin 1 for XHTML//EN"
SYSTEM "[Link]
Revision: $Id: [Link],v 4.1 2001/04/10 09:34:14 altheim Exp $ SMI
Portions (C) International Organization for Standardization 1986:
Permission to copy in any form is granted for use with conforming
SGML systems and applications as defined in ISO 8879, provided
this notice is included in all copies.
- ->
<!ENTITY nbsp " " ><!- - no-break space = non-breaking space, U+00A0 ISOnum
- ->
<!ENTITY iexcl "¡" ><!- - inverted exclamation mark, U+00A1 ISOnum - ->
<!ENTITY cent "¢" ><!- - cent sign, U+00A2 ISOnum - ->
<!ENTITY pound "£" ><!- - pound sign, U+00A3 ISOnum - ->
<!ENTITY curren "¤" ><!- - currency sign, U+00A4 ISOnum - ->
<!ENTITY yen "¥" ><!- - yen sign = yuan sign, U+00A5 ISOnum - ->
<!ENTITY brvbar "¦" ><!- - broken bar = broken vertical bar, U+00A6 ISOnum - ->
<!ENTITY sect "§" ><!- - section sign, U+00A7 ISOnum - ->
<!ENTITY uml "¨" ><!- - diaeresis = spacing diaeresis, U+00A8 ISOdia - ->
<!ENTITY copy "©" ><!- - copyright sign, U+00A9 ISOnum - ->
<!ENTITY ordf "ª" ><!- - feminine ordinal indicator, U+00AA ISOnum - ->
<!ENTITY laquo "«" ><!- - left-pointing double angle quotation mark = left
pointing guillemet, U+00AB ISOnum - ->
<!ENTITY not "¬" ><!- - not sign, U+00AC ISOnum - ->
<!ENTITY shy "­" ><!- - soft hyphen = discretionary hyphen, U+00AD ISOnum
- ->
XHTML-Zeichen-Entities < 451 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!ENTITY reg "®" ><!- - registered sign = registered trade mark sign, U+00AE
ISOnum - ->
<!ENTITY macr "¯" ><!- - macron = spacing macron = overline = APL overbar,
U+00AF ISOdia - ->
<!ENTITY deg "°" ><!- - degree sign, U+00B0 ISOnum - ->
<!ENTITY plusmn "±" ><!- - plus-minus sign = plus-or-minus sign, U+00B1 ISOnum
- ->
<!ENTITY sup2 "²" ><!- - superscript two = superscript digit two = squared,
U+00B2 ISOnum - ->
<!ENTITY sup3 "³" ><!- - superscript three = superscript digit three = cubed,
U+00B3 ISOnum - ->
<!ENTITY acute "´" ><!- - acute accent = spacing acute, U+00B4 ISOdia - ->
<!ENTITY micro "µ" ><!- - micro sign, U+00B5 ISOnum - ->
<!ENTITY para "¶" ><!- - pilcrow sign = paragraph sign, U+00B6 ISOnum - ->
<!ENTITY middot "·" ><!- - middle dot = Georgian comma = Greek middle dot,
U+00B7 ISOnum - ->
<!ENTITY cedil "¸" ><!- - cedilla = spacing cedilla, U+00B8 ISOdia - ->
Modularisierung von XHTML
<!ENTITY sup1 "¹" ><!- - superscript one = superscript digit one, U+00B9
ISOnum - ->
<!ENTITY ordm "º" ><!- - masculine ordinal indicator, U+00BA ISOnum - ->
<!ENTITY raquo "»" ><!- - right-pointing double angle quotation mark = right
pointing guillemet, U+00BB ISOnum - ->
<!ENTITY frac14 "¼" ><!- - vulgar fraction one quarter = fraction one quarter,
U+00BC ISOnum - ->
<!ENTITY frac12 "½" ><!- - vulgar fraction one half = fraction one half, U+00BD
ISOnum - ->
<!ENTITY frac34 "¾" ><!- - vulgar fraction three quarters = fraction three
quarters, U+00BE ISOnum - ->
<!ENTITY iquest "¿" ><!- - inverted question mark = turned question mark,
U+00BF ISOnum - ->
<!ENTITY Agrave "À" ><!- - latin capital A with grave = latin capital A grave,
U+00C0 ISOlat1 - ->
<!ENTITY Aacute "Á" ><!- - latin capital A with acute, U+00C1 ISOlat1 - ->
<!ENTITY Acirc "Â" ><!- - latin capital A with circumflex, U+00C2 ISOlat1 - ->
<!ENTITY Atilde "Ã" ><!- - latin capital A with tilde, U+00C3 ISOlat1 - ->
<!ENTITY Auml "Ä" ><!- - latin capital A with diaeresis, U+00C4 ISOlat1 - ->
<!ENTITY Aring "Å" ><!- - latin capital A with ring above = latin capital A
ring, U+00C5 ISOlat1 - ->
<!ENTITY AElig "Æ" ><!- - latin capital AE = latin capital ligature AE, U+00C6
ISOlat1 - ->
<!ENTITY Ccedil "Ç" ><!- - latin capital C with cedilla, U+00C7 ISOlat1 - ->
<!ENTITY Egrave "È" ><!- - latin capital E with grave, U+00C8 ISOlat1 - ->
<!ENTITY Eacute "É" ><!- - latin capital E with acute, U+00C9 ISOlat1 - ->
<!ENTITY Ecirc "Ê" ><!- - latin capital E with circumflex, U+00CA ISOlat1 - ->
<!ENTITY Euml "Ë" ><!- - latin capital E with diaeresis, U+00CB ISOlat1 - ->
<!ENTITY Igrave "Ì" ><!- - latin capital I with grave, U+00CC ISOlat1 - ->
<!ENTITY Iacute "Í" ><!- - latin capital I with acute, U+00CD ISOlat1 - ->
<!ENTITY Icirc "Î" ><!- - latin capital I with circumflex, U+00CE ISOlat1 - ->
<!ENTITY Iuml "Ï" ><!- - latin capital I with diaeresis, U+00CF ISOlat1 - ->
<!ENTITY ETH "Ð" ><!- - latin capital ETH, U+00D0 ISOlat1 - ->
<!ENTITY Ntilde "Ñ" ><!- - latin capital N with tilde, U+00D1 ISOlat1 - ->
<!ENTITY Ograve "Ò" ><!- - latin capital O with grave, U+00D2 ISOlat1 - ->
<!ENTITY Oacute "Ó" ><!- - latin capital O with acute, U+00D3 ISOlat1 - ->
<!ENTITY Ocirc "Ô" ><!- - latin capital O with circumflex, U+00D4 ISOlat1 - ->
<!ENTITY Otilde "Õ" ><!- - latin capital O with tilde, U+00D5 ISOlat1 - ->
<!ENTITY Ouml "Ö" ><!- - latin capital O with diaeresis, U+00D6 ISOlat1 - ->
< 452 > Implementierungen von XHTML-Modulen mit DTDs
Page size: 168,00 x 240,00 mm
<!ENTITY times "×" ><!- - multiplication sign, U+00D7 ISOnum - ->
<!ENTITY Oslash "Ø" ><!- - latin capital O with stroke = latin capital O slash,
U+00D8 ISOlat1 - ->
<!ENTITY Ugrave "Ù" ><!- - latin capital U with grave, U+00D9 ISOlat1 - ->
<!ENTITY Uacute "Ú" ><!- - latin capital U with acute, U+00DA ISOlat1 - ->
<!ENTITY Ucirc "Û" ><!- - latin capital U with circumflex, U+00DB ISOlat1 - ->
<!ENTITY Uuml "Ü" ><!- - latin capital U with diaeresis, U+00DC ISOlat1 - ->
<!ENTITY Yacute "Ý" ><!- - latin capital Y with acute, U+00DD ISOlat1 - ->
<!ENTITY THORN "Þ" ><!- - latin capital THORN, U+00DE ISOlat1 - ->
<!ENTITY szlig "ß" ><!- - latin small sharp s = ess-zed, U+00DF ISOlat1 - ->
<!ENTITY agrave "à" ><!- - latin small a with grave = latin small a grave,
U+00E0 ISOlat1 - ->
<!ENTITY aacute "á" ><!- - latin small a with acute, U+00E1 ISOlat1 - ->
<!ENTITY acirc "â" ><!- - latin small a with circumflex, U+00E2 ISOlat1 - ->
<!ENTITY atilde "ã" ><!- - latin small a with tilde, U+00E3 ISOlat1 - ->
<!ENTITY auml "ä" ><!- - latin small a with diaeresis, U+00E4 ISOlat1 - ->
<!ENTITY aring "å" ><!- - latin small a with ring above = latin small a ring,
Modularisierung von XHTML
U+00E5 ISOlat1 - ->
<!ENTITY aelig "æ" ><!- - latin small ae = latin small ligature ae, U+00E6
ISOlat1 - ->
<!ENTITY ccedil "ç" ><!- - latin small c with cedilla, U+00E7 ISOlat1 - ->
<!ENTITY egrave "è" ><!- - latin small e with grave, U+00E8 ISOlat1 - ->
<!ENTITY eacute "é" ><!- - latin small e with acute, U+00E9 ISOlat1 - ->
<!ENTITY ecirc "ê" ><!- - latin small e with circumflex, U+00EA ISOlat1 - ->
<!ENTITY euml "ë" ><!- - latin small e with diaeresis, U+00EB ISOlat1 - ->
<!ENTITY igrave "ì" ><!- - latin small i with grave, U+00EC ISOlat1 - ->
<!ENTITY iacute "í" ><!- - latin small i with acute, U+00ED ISOlat1 - ->
<!ENTITY icirc "î" ><!- - latin small i with circumflex, U+00EE ISOlat1 - ->
<!ENTITY iuml "ï" ><!- - latin small i with diaeresis, U+00EF ISOlat1 - ->
<!ENTITY eth "ð" ><!- - latin small eth, U+00F0 ISOlat1 - ->
<!ENTITY ntilde "ñ" ><!- - latin small n with tilde, U+00F1 ISOlat1 - ->
<!ENTITY ograve "ò" ><!- - latin small o with grave, U+00F2 ISOlat1 - ->
<!ENTITY oacute "ó" ><!- - latin small o with acute, U+00F3 ISOlat1 - ->
<!ENTITY ocirc "ô" ><!- - latin small o with circumflex, U+00F4 ISOlat1 - ->
<!ENTITY otilde "õ" ><!- - latin small o with tilde, U+00F5 ISOlat1 - ->
<!ENTITY ouml "ö" ><!- - latin small o with diaeresis, U+00F6 ISOlat1 - ->
<!ENTITY divide "÷" ><!- - division sign, U+00F7 ISOnum - ->
<!ENTITY oslash "ø" ><!- - latin small o with stroke, = latin small o slash,
U+00F8 ISOlat1 - ->
<!ENTITY ugrave "ù" ><!- - latin small u with grave, U+00F9 ISOlat1 - ->
<!ENTITY uacute "ú" ><!- - latin small u with acute, U+00FA ISOlat1 - ->
<!ENTITY ucirc "û" ><!- - latin small u with circumflex, U+00FB ISOlat1 - ->
<!ENTITY uuml "ü" ><!- - latin small u with diaeresis, U+00FC ISOlat1 - ->
<!ENTITY yacute "ý" ><!- - latin small y with acute, U+00FD ISOlat1 - ->
<!ENTITY thorn "þ" ><!- - latin small thorn with, U+00FE ISOlat1 - ->
<!ENTITY yuml "ÿ" ><!- - latin small y with diaeresis, U+00FF ISOlat1 - ->
<!- - end of [Link] - ->
F.1.2 Sonderzeichen von XHTML
<!- - ...................................................................... - ->
<!- - XML-compatible ISO Special Character Entity Set for XHTML ............ - ->
<!- - file: [Link]
Typical invocation:
XHTML-Zeichen-Entities < 453 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!ENTITY % xhtml-special
PUBLIC "-//W3C//ENTITIES Special for XHTML//EN"
"[Link]" >
%xhtml-special;
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//ENTITIES Special for XHTML//EN"
SYSTEM "[Link]
Revision: $Id: [Link],v 4.1 2001/04/10 09:34:14 altheim Exp $ SMI
Portions (C) International Organization for Standardization 1986:
Permission to copy in any form is granted for use with conforming
SGML systems and applications as defined in ISO 8879, provided
this notice is included in all copies.
Modularisierung von XHTML
Revisions:
2000-10-28: added ' and altered XML Predefined Entities for compatibility
- ->
<!- - Relevant ISO entity set is given unless names are newly introduced.
New names (i.e., not in ISO 8879 [SGML] list) do not clash with
any existing ISO 8879 entity names. ISO 10646 [ISO10646] character
numbers are given for each character, in hex. Entity values are
decimal conversions of the ISO 10646 values and refer to the
document character set. Names are Unicode [UNICODE] names.
- ->
<!- - C0 Controls and Basic Latin - ->
<!ENTITY lt "&<" ><!- - less-than sign, U+003C ISOnum - ->
<!ENTITY gt ">" ><!- - greater-than sign, U+003E ISOnum - ->
<!ENTITY amp "&&" ><!- - ampersand, U+0026 ISOnum - ->
<!ENTITY apos "'" ><!- - apostrophe, U+0027 ISOnum - ->
<!ENTITY quot """ ><!- - quotation mark = APL quote, U+0022 ISOnum - ->
<!- - Latin Extended-A - ->
<!ENTITY OElig "Œ" ><!- - latin capital ligature OE, U+0152 ISOlat2 - ->
<!ENTITY oelig "œ" ><!- - latin small ligature oe, U+0153 ISOlat2 - ->
<!- - ligature is a misnomer, this is a separate character in some languages - ->
<!ENTITY Scaron "Š" ><!- - latin capital letter S with caron, U+0160 ISOlat2
- ->
<!ENTITY scaron "š" ><!- - latin small letter s with caron, U+0161 ISOlat2 - ->
<!ENTITY Yuml "Ÿ" ><!- - latin capital letter Y with diaeresis, U+0178
ISOlat2 - ->
<!- - Spacing Modifier Letters - ->
<!ENTITY circ "ˆ" ><!- - modifier letter circumflex accent, U+02C6 ISOpub
- ->
<!ENTITY tilde "˜" ><!- - small tilde, U+02DC ISOdia - ->
<!- - General Punctuation - ->
<!ENTITY ensp " " ><!- - en space, U+2002 ISOpub - ->
<!ENTITY emsp " " ><!- - em space, U+2003 ISOpub - ->
< 454 > Implementierungen von XHTML-Modulen mit DTDs
Page size: 168,00 x 240,00 mm
<!ENTITY thinsp " " ><!- - thin space, U+2009 ISOpub - ->
<!ENTITY zwnj "‌" ><!- - zero width non-joiner, U+200C NEW RFC 2070 - ->
<!ENTITY zwj "‍" ><!- - zero width joiner, U+200D NEW RFC 2070 - ->
<!ENTITY lrm "‎" ><!- - left-to-right mark, U+200E NEW RFC 2070 - ->
<!ENTITY rlm "‏" ><!- - right-to-left mark, U+200F NEW RFC 2070 - ->
<!ENTITY ndash "–" ><!- - en dash, U+2013 ISOpub - ->
<!ENTITY mdash "—" ><!- - em dash, U+2014 ISOpub - ->
<!ENTITY lsquo "‘" ><!- - left single quotation mark, U+2018 ISOnum - ->
<!ENTITY rsquo "’" ><!- - right single quotation mark, U+2019 ISOnum - ->
<!ENTITY sbquo "‚" ><!- - single low-9 quotation mark, U+201A NEW - ->
<!ENTITY ldquo "“" ><!- - left double quotation mark, U+201C ISOnum - ->
<!ENTITY rdquo "”" ><!- - right double quotation mark, U+201D ISOnum - ->
<!ENTITY bdquo "„" ><!- - double low-9 quotation mark, U+201E NEW - ->
<!ENTITY dagger "†" ><!- - dagger, U+2020 ISOpub - ->
<!ENTITY Dagger "‡" ><!- - double dagger, U+2021 ISOpub - ->
<!ENTITY permil "‰" ><!- - per mille sign, U+2030 ISOtech - ->
Modularisierung von XHTML
<!- - lsaquo is proposed but not yet ISO standardized - ->
<!ENTITY lsaquo "‹" ><!- - single left-pointing angle quotation mark, U+2039
ISO proposed - ->
<!- - rsaquo is proposed but not yet ISO standardized - ->
<!ENTITY rsaquo "›" ><!- - single right-pointing angle quotation mark, U+203A
ISO proposed - ->
<!ENTITY euro "€" ><!- - euro sign, U+20AC NEW - ->
<!- - end of [Link] - ->
F.1.3 Mathematische, griechische und Symbolzeichen von XHTML
<!- - ...................................................................... - ->
<!- - ISO Math, Greek and Symbolic Character Entity Set for XHTML .......... - ->
<!- - file: [Link]
Typical invocation:
<!ENTITY % xhtml-symbol
PUBLIC "-//W3C//ENTITIES Symbols for XHTML//EN"
"[Link]" >
%xhtml-symbol;
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//ENTITIES Symbols for XHTML//EN"
SYSTEM "[Link]
Revision: $Id: [Link],v 4.1 2001/04/10 09:34:14 altheim Exp $ SMI
Portions (C) International Organization for Standardization 1986:
Permission to copy in any form is granted for use with conforming
SGML systems and applications as defined in ISO 8879, provided
this notice is included in all copies.
- ->
<!- - Relevant ISO entity set is given unless names are newly introduced.
New names (i.e., not in ISO 8879 [SGML] list) do not clash with
any existing ISO 8879 entity names. ISO 10646 [ISO10646] character
XHTML-Zeichen-Entities < 455 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
numbers are given for each character, in hex. Entity values are
decimal conversions of the ISO 10646 values and refer to the
document character set. Names are Unicode [UNICODE] names.
- ->
<!- - Latin Extended-B - ->
<!ENTITY fnof "ƒ" ><!- - latin small f with hook = function
= florin, U+0192 ISOtech - ->
<!- - Greek - ->
<!ENTITY Alpha "Α" ><!- - greek capital letter alpha, U+0391 - ->
<!ENTITY Beta "Β" ><!- - greek capital letter beta, U+0392 - ->
<!ENTITY Gamma "Γ" ><!- - greek capital letter gamma, U+0393 ISOgrk3 - ->
<!ENTITY Delta "Δ" ><!- - greek capital letter delta, U+0394 ISOgrk3 - ->
<!ENTITY Epsilon "Ε" ><!- - greek capital letter epsilon, U+0395 - ->
<!ENTITY Zeta "Ζ" ><!- - greek capital letter zeta, U+0396 - ->
<!ENTITY Eta "Η" ><!- - greek capital letter eta, U+0397 - ->
Modularisierung von XHTML
<!ENTITY Theta "Θ" ><!- - greek capital letter theta, U+0398 ISOgrk3 - ->
<!ENTITY Iota "Ι" ><!- - greek capital letter iota, U+0399 - ->
<!ENTITY Kappa "Κ" ><!- - greek capital letter kappa, U+039A - ->
<!ENTITY Lambda "Λ" ><!- - greek capital letter lambda, U+039B ISOgrk3 - ->
<!ENTITY Mu "Μ" ><!- - greek capital letter mu, U+039C - ->
<!ENTITY Nu "Ν" ><!- - greek capital letter nu, U+039D - ->
<!ENTITY Xi "Ξ" ><!- - greek capital letter xi, U+039E ISOgrk3 - ->
<!ENTITY Omicron "Ο" ><!- - greek capital letter omicron, U+039F - ->
<!ENTITY Pi "Π" ><!- - greek capital letter pi, U+03A0 ISOgrk3 - ->
<!ENTITY Rho "Ρ" ><!- - greek capital letter rho, U+03A1 - ->
<!- - there is noSigmaf, and no U+03A2 character either - ->
<!ENTITY Sigma "Σ" ><!- - greek capital letter sigma, U+03A3 ISOgrk3 - ->
<!ENTITY Tau "Τ" ><!- - greek capital letter tau, U+03A4 - ->
<!ENTITY Upsilon "Υ" ><!- - greek capital letter upsilon,
U+03A5 ISOgrk3 - ->
<!ENTITY Phi "Φ" ><!- - greek capital letter phi, U+03A6 ISOgrk3 - ->
<!ENTITY Chi "Χ" ><!- - greek capital letter chi, U+03A7 - ->
<!ENTITY Psi "Ψ" ><!- - greek capital letter psi, U+03A8 ISOgrk3 - ->
<!ENTITY Omega "Ω" ><!- - greek capital letter omega, U+03A9 ISOgrk3 - ->
<!ENTITY alpha "α" ><!- - greek small letter alpha, U+03B1 ISOgrk3 - ->
<!ENTITY beta "β" ><!- - greek small letter beta, U+03B2 ISOgrk3 - ->
<!ENTITY gamma "γ" ><!- - greek small letter gamma, U+03B3 ISOgrk3 - ->
<!ENTITY delta "δ" ><!- - greek small letter delta, U+03B4 ISOgrk3 - ->
<!ENTITY epsilon "ε" ><!- - greek small letter epsilon, U+03B5 ISOgrk3 - ->
<!ENTITY zeta "ζ" ><!- - greek small letter zeta, U+03B6 ISOgrk3 - ->
<!ENTITY eta "η" ><!- - greek small letter eta, U+03B7 ISOgrk3 - ->
<!ENTITY theta "θ" ><!- - greek small letter theta, U+03B8 ISOgrk3 - ->
<!ENTITY iota "ι" ><!- - greek small letter iota, U+03B9 ISOgrk3 - ->
<!ENTITY kappa "κ" ><!- - greek small letter kappa, U+03BA ISOgrk3 - ->
<!ENTITY lambda "λ" ><!- - greek small letter lambda, U+03BB ISOgrk3 - ->
<!ENTITY mu "μ" ><!- - greek small letter mu, U+03BC ISOgrk3 - ->
<!ENTITY nu "ν" ><!- - greek small letter nu, U+03BD ISOgrk3 - ->
<!ENTITY xi "ξ" ><!- - greek small letter xi, U+03BE ISOgrk3 - ->
<!ENTITY omicron "ο" ><!- - greek small letter omicron, U+03BF NEW - ->
<!ENTITY pi "π" ><!- - greek small letter pi, U+03C0 ISOgrk3 - ->
<!ENTITY rho "ρ" ><!- - greek small letter rho, U+03C1 ISOgrk3 - ->
<!ENTITY sigmaf "ς" ><!- - greek small letter final sigma, U+03C2 ISOgrk3 - ->
<!ENTITY sigma "σ" ><!- - greek small letter sigma, U+03C3 ISOgrk3 - ->
<!ENTITY tau "τ" ><!- - greek small letter tau, U+03C4 ISOgrk3 - ->
< 456 > Implementierungen von XHTML-Modulen mit DTDs
Page size: 168,00 x 240,00 mm
<!ENTITY upsilon "υ" ><!- - greek small letter upsilon, U+03C5 ISOgrk3 - ->
<!ENTITY phi "φ" ><!- - greek small letter phi, U+03C6 ISOgrk3 - ->
<!ENTITY chi "χ" ><!- - greek small letter chi, U+03C7 ISOgrk3 - ->
<!ENTITY psi "ψ" ><!- - greek small letter psi, U+03C8 ISOgrk3 - ->
<!ENTITY omega "ω" ><!- - greek small letter omega, U+03C9 ISOgrk3 - ->
<!ENTITY thetasym "ϑ" ><!- - greek small letter theta symbol, U+03D1 NEW - ->
<!ENTITY upsih "ϒ" ><!- - greek upsilon with hook symbol, U+03D2 NEW - ->
<!ENTITY piv "ϖ" ><!- - greek pi symbol, U+03D6 ISOgrk3 - ->
<!- - General Punctuation - ->
<!ENTITY bull "•" ><!- - bullet = black small circle, U+2022 ISOpub - ->
<!- - bullet is NOT the same as bullet operator, U+2219 - ->
<!ENTITY hellip "…" ><!- - horizontal ellipsis = three dot leader, U+2026
ISOpub - ->
<!ENTITY prime "′" ><!- - prime = minutes = feet, U+2032 ISOtech - ->
<!ENTITY Prime "″" ><!- - double prime = seconds = inches, U+2033 ISOtech
- ->
Modularisierung von XHTML
<!ENTITY oline "‾" ><!- - overline = spacing overscore, U+203E NEW - ->
<!ENTITY frasl "⁄" ><!- - fraction slash, U+2044 NEW - ->
<!- - Letterlike Symbols - ->
<!ENTITY weierp "℘" ><!- - script capital P = power set = Weierstrass p,
U+2118 ISOamso - ->
<!ENTITY image "ℑ" ><!- - blackletter capital I = imaginary part, U+2111
ISOamso - ->
<!ENTITY real "ℜ" ><!- - blackletter capital R = real part symbol, U+211C
ISOamso - ->
<!ENTITY trade "™" ><!- - trade mark sign, U+2122 ISOnum - ->
<!ENTITY alefsym "ℵ" ><!- - alef symbol = first transfinite cardinal, U+2135
NEW - ->
<!- - alef symbol is NOT the same as hebrew letter alef, U+05D0 although
the same glyph could be used to depict both characters - ->
<!- - Arrows - ->
<!ENTITY larr "←" ><!- - leftwards arrow, U+2190 ISOnum - ->
<!ENTITY uarr "↑" ><!- - upwards arrow, U+2191 ISOnum- ->
<!ENTITY rarr "→" ><!- - rightwards arrow, U+2192 ISOnum - ->
<!ENTITY darr "↓" ><!- - downwards arrow, U+2193 ISOnum - ->
<!ENTITY harr "↔" ><!- - left right arrow, U+2194 ISOamsa - ->
<!ENTITY crarr "↵" ><!- - downwards arrow with corner leftwards
= carriage return, U+21B5 NEW - ->
<!ENTITY lArr "⇐" ><!- - leftwards double arrow, U+21D0 ISOtech - ->
<!- - Unicode does not say that lArr is the same as the 'is implied by' arrow
but also does not have any other character for that function. So ? lArr can
be used for 'is implied by' as ISOtech suggests - ->
<!ENTITY uArr "⇑" ><!- - upwards double arrow, U+21D1 ISOamsa - ->
<!ENTITY rArr "⇒" ><!- - rightwards double arrow, U+21D2 ISOtech - ->
<!- - Unicode does not say this is the 'implies' character but does not have
another character with this function so ?
rArr can be used for 'implies' as ISOtech suggests - ->
<!ENTITY dArr "⇓" ><!- - downwards double arrow, U+21D3 ISOamsa - ->
<!ENTITY hArr "⇔" ><!- - left right double arrow, U+21D4 ISOamsa - ->
<!- - Mathematical Operators - ->
<!ENTITY forall "∀" ><!- - for all, U+2200 ISOtech - ->
XHTML-Zeichen-Entities < 457 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!ENTITY part "∂" ><!- - partial differential, U+2202 ISOtech - ->
<!ENTITY exist "∃" ><!- - there exists, U+2203 ISOtech - ->
<!ENTITY empty "∅" ><!- - empty set = null set = diameter, U+2205 ISOamso
- ->
<!ENTITY nabla "∇" ><!- - nabla = backward difference, U+2207 ISOtech - ->
<!ENTITY isin "∈" ><!- - element of, U+2208 ISOtech - ->
<!ENTITY notin "∉" ><!- - not an element of, U+2209 ISOtech - ->
<!ENTITY ni "∋" ><!- - contains as member, U+220B ISOtech - ->
<!- - should there be a more memorable name than 'ni'? - ->
<!ENTITY prod "∏" ><!- - n-ary product = product sign, U+220F ISOamsb - ->
<!- - prod is NOT the same character as U+03A0 'greek capital letter pi' though
the same glyph might be used for both - ->
<!ENTITY sum "∑" ><!- - n-ary sumation, U+2211 ISOamsb - ->
<!- - sum is NOT the same character as U+03A3 'greek capital letter sigma'
though the same glyph might be used for both - ->
<!ENTITY minus "−" ><!- - minus sign, U+2212 ISOtech - ->
<!ENTITY lowast "∗" ><!- - asterisk operator, U+2217 ISOtech - ->
Modularisierung von XHTML
<!ENTITY radic "√" ><!- - square root = radical sign, U+221A ISOtech - ->
<!ENTITY prop "∝" ><!- - proportional to, U+221D ISOtech - ->
<!ENTITY infin "∞" ><!- - infinity, U+221E ISOtech - ->
<!ENTITY ang "∠" ><!- - angle, U+2220 ISOamso - ->
<!ENTITY and "∧" ><!- - logical and = wedge, U+2227 ISOtech - ->
<!ENTITY or "∨" ><!- - logical or = vee, U+2228 ISOtech - ->
<!ENTITY cap "∩" ><!- - intersection = cap, U+2229 ISOtech - ->
<!ENTITY cup "∪" ><!- - union = cup, U+222A ISOtech - ->
<!ENTITY int "∫" ><!- - integral, U+222B ISOtech - ->
<!ENTITY there4 "∴" ><!- - therefore, U+2234 ISOtech - ->
<!ENTITY sim "∼" ><!- - tilde operator = varies with = similar to, U+223C
ISOtech - ->
<!- - tilde operator is NOT the same character as the tilde, U+007E,
although the same glyph might be used to represent both - ->
<!ENTITY cong "≅" ><!- - approximately equal to, U+2245 ISOtech - ->
<!ENTITY asymp "≈" ><!- - almost equal to = asymptotic to, U+2248 ISOamsr
- ->
<!ENTITY ne "≠" ><!- - not equal to, U+2260 ISOtech - ->
<!ENTITY equiv "≡" ><!- - identical to, U+2261 ISOtech - ->
<!ENTITY le "≤" ><!- - less-than or equal to, U+2264 ISOtech - ->
<!ENTITY ge "≥" ><!- - greater-than or equal to, U+2265 ISOtech - ->
<!ENTITY sub "⊂" ><!- - subset of, U+2282 ISOtech - ->
<!ENTITY sup "⊃" ><!- - superset of, U+2283 ISOtech - ->
<!- - note that nsup, 'not a superset of, U+2283' is not covered by the Symbol
font encoding and is not included. Should it be, for symmetry?
It is in ISOamsn - ->
<!ENTITY nsub "⊄" ><!- - not a subset of, U+2284 ISOamsn - ->
<!ENTITY sube "⊆" ><!- - subset of or equal to, U+2286 ISOtech - ->
<!ENTITY supe "⊇" ><!- - superset of or equal to, U+2287 ISOtech - ->
<!ENTITY oplus "⊕" ><!- - circled plus = direct sum, U+2295 ISOamsb - ->
<!ENTITY otimes "⊗" ><!- - circled times = vector product, U+2297 ISOamsb
- ->
<!ENTITY perp "⊥" ><!- - up tack = orthogonal to = perpendicular, U+22A5
ISOtech - ->
<!ENTITY sdot "⋅" ><!- - dot operator, U+22C5 ISOamsb - ->
<!- - dot operator is NOT the same character as U+00B7 middle dot - ->
<!- - Miscellaneous Technical - ->
<!ENTITY lceil "⌈" ><!- - left ceiling = apl upstile, U+2308 ISOamsc - ->
< 458 > Implementierungen von XHTML-Modulen mit DTDs
Page size: 168,00 x 240,00 mm
<!ENTITY rceil "⌉" ><!- - right ceiling, U+2309 ISOamsc - ->
<!ENTITY lfloor "⌊" ><!- - left floor = apl downstile, U+230A ISOamsc - ->
<!ENTITY rfloor "⌋" ><!- - right floor, U+230B ISOamsc - ->
<!ENTITY lang "〈" ><!- - left-pointing angle bracket = bra, U+2329 ISOtech
- ->
<!- - lang is NOT the same character as U+003C 'less than'
or U+2039 'single left-pointing angle quotation mark' - ->
<!ENTITY rang "〉" ><!- - right-pointing angle bracket = ket, U+232A
ISOtech - ->
<!- - rang is NOT the same character as U+003E 'greater than'
or U+203A 'single right-pointing angle quotation mark' - ->
<!- - Geometric Shapes - ->
<!ENTITY loz "◊" ><!- - lozenge, U+25CA ISOpub - ->
<!- - Miscellaneous Symbols - ->
<!ENTITY spades "♠" ><!- - black spade suit, U+2660 ISOpub - ->
Modularisierung von XHTML
<!- - black here seems to mean filled as opposed to hollow - ->
<!ENTITY clubs "♣" ><!- - black club suit = shamrock, U+2663 ISOpub - ->
<!ENTITY hearts "♥" ><!- - black heart suit = valentine, U+2665 ISOpub - ->
<!ENTITY diams "♦" ><!- - black diamond suit, U+2666 ISOpub - ->
<!- - end of [Link] - ->
F.2 Modulares Rahmenwerk von XHTML
Damit DTD-Autoren Nutzen aus den XHTML-DTD-Modulen ziehen k=nnen, m ssen sie die
Inhaltsmodelle f r ihre DTD definieren. XHTML stellt eine F lle an Werkzeugen zur Ver-
f gung, um diese Arbeit zu erleichtern. Sie sind in einem Satz unterst tzender Module definiert
und werden durch ein zentrales Rahmenwerkmodul instanziiert:
<!- - ...................................................................... - ->
<!- - XHTML Modular Framework Module ...................................... - ->
<!- - file: [Link]
This is XHTML, a reformulation of HTML as a modular XML application.
Copyright 1998-2001 W3C (MIT, INRIA, Keio), All Rights Reserved.
Revision: $Id: [Link],v 4.0 2001/04/02 22:42:49 altheim Exp $
SMI
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//ENTITIES XHTML Modular Framework 1.0//EN"
SYSTEM "[Link]
Revisions:
(none)
....................................................................... - ->
<!- - Modular Framework
This required module instantiates the modules needed
to support the XHTML modularization model, including:
Modulares Rahmenwerk von XHTML < 459 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
+ notations
+ datatypes
+ namespace-qualified names
+ common attributes
+ document model
+ character entities
The Intrinsic Events module is ignored by default but
occurs in this module because it must be instantiated
prior to Attributes but after Datatypes.
- ->
<!ENTITY % [Link] "IGNORE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Base Architecture 1.0//EN"
"[Link]" >
Modularisierung von XHTML
%[Link];]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//NOTATIONS XHTML Notations 1.0//EN"
"[Link]" >
%[Link];]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ENTITIES XHTML Datatypes 1.0//EN"
"[Link]" >
%[Link];]]>
<!- - placeholder for XLink support module - ->
<!ENTITY % [Link] "" >
%[Link];
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ENTITIES XHTML Qualified Names 1.0//EN"
"[Link]" >
%[Link];]]>
<!ENTITY % [Link] "IGNORE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ENTITIES XHTML Intrinsic Events 1.0//EN"
"[Link]" >
%[Link];]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ENTITIES XHTML Common Attributes 1.0//EN"
"[Link]" >
< 460 > Implementierungen von XHTML-Modulen mit DTDs
Page size: 168,00 x 240,00 mm
%[Link];]]>
<!- - placeholder for content model redeclarations - ->
<!ENTITY % [Link] "" >
%[Link];
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!- - instantiate the Document Model module declared in the DTD driver
- ->
%[Link];]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ENTITIES XHTML Character Entities 1.0//EN"
"[Link]" >
Modularisierung von XHTML
%[Link];]]>
<!- - end of [Link] - ->
Beachten Sie, dass das obige Modul ein Inhaltsmodellmodul referenziert. Dieses Modul wird „je
Dokument“ zus@tzlich zum Dokumenttyp-Treiber definiert. Das modulare Rahmenwerk st tzt
sich außerdem auf die folgenden Komponentenmodule:
F.2.1 XHTML-Basisarchitektur
<!- - ...................................................................... - ->
<!- - XHTML Base Architecture Module ...................................... - ->
<!- - file: [Link]
This is XHTML, a reformulation of HTML as a modular XML application.
Copyright 1998-2001 W3C (MIT, INRIA, Keio), All Rights Reserved.
Revision: $Id: [Link],v 4.0 2001/04/02 22:42:49 altheim Exp $ SMI
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//ELEMENTS XHTML Base Architecture 1.0//EN"
SYSTEM "[Link]
Revisions:
(none)
....................................................................... - ->
<!- - This optional module includes declarations that enable XHTML to be used
as a base architecture according to the 'Architectural Forms Definition
Requirements' (Annex A.3, ISO/IEC 10744, 2nd edition). For more information
on use of architectural forms, see the HyTime web site at:
[Link]
- ->
<?IS10744 ArcBase xhtml ?>
<!NOTATION xhtml PUBLIC "-//W3C//NOTATION AFDR ARCBASE XHTML 1.1//EN" >
Modulares Rahmenwerk von XHTML < 461 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!- - Entity declaration for associated Architectural DTD
- ->
<!ENTITY [Link]
PUBLIC "-//W3C//DTD XHTML Architecture 1.1//EN"
"[Link]" >
<?IS10744:arch xhtml
public-id = "-//W3C//NOTATION AFDR ARCBASE XHTML 1.1//EN"
dtd-public-id = "-//W3C//DTD XHTML 1.1//EN"
dtd-system-id = "[Link]"
doc-elem-form = "html"
form-att = "html"
renamer-att = "htnames"
suppressor-att = "htsupp"
data-ignore-att = "htign"
auto = "ArcAuto"
options = "HtModReq HtModOpt"
Modularisierung von XHTML
HtModReq = "Framework Text Hypertext Lists Structure"
HtModOpt = "Standard"
?>
<!- - end of [Link] - ->
F.2.2 XHTML-Notationen
<!- - ...................................................................... - ->
<!- - XHTML Notations Module .............................................. - ->
<!- - file: [Link]
This is XHTML, a reformulation of HTML as a modular XML application.
Copyright 1998-2001 W3C (MIT, INRIA, Keio), All Rights Reserved.
Revision: $Id: [Link],v 4.0 2001/04/02 22:42:49 altheim Exp $
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//NOTATIONS XHTML Notations 1.0//EN"
SYSTEM "[Link]
Revisions:
(none)
....................................................................... - ->
<!- - Notations
defines the following notations, many of these imported from
other specifications and standards. When an existing FPI is
known, it is incorporated here.
- ->
<!- - XML Notations ..................................... - ->
<!- - SGML and XML Notations ............................ - ->
<!- - W3C XML 1.0 Recommendation - ->
<!NOTATION w3c-xml
PUBLIC "ISO 8879//NOTATION Extensible Markup Language (XML) 1.0//EN" >
< 462 > Implementierungen von XHTML-Modulen mit DTDs
Page size: 168,00 x 240,00 mm
<!- - XML 1.0 CDATA - ->
<!NOTATION cdata
PUBLIC "-//W3C//NOTATION XML 1.0: CDATA//EN" >
<!- - SGML Formal Public Identifiers - ->
<!NOTATION fpi
PUBLIC "ISO 8879:1986//NOTATION Formal Public Identifier//EN" >
<!- - XHTML Notations ................................... - ->
<!- - Length defined for cellpadding/cellspacing - ->
<!- - nn for pixels or nn% for percentage length - ->
<!NOTATION length
PUBLIC "-//W3C//NOTATION XHTML Datatype: Length//EN" >
<!- - space-separated list of link types - ->
Modularisierung von XHTML
<!NOTATION linkTypes
PUBLIC "-//W3C//NOTATION XHTML Datatype: LinkTypes//EN" >
<!- - single or comma-separated list of media descriptors - ->
<!NOTATION mediaDesc
PUBLIC "-//W3C//NOTATION XHTML Datatype: MediaDesc//EN" >
<!- - pixel, percentage, or relative - ->
<!NOTATION multiLength
PUBLIC "-//W3C//NOTATION XHTML Datatype: MultiLength//EN" >
<!- - one or more digits (NUMBER) - ->
<!NOTATION number
PUBLIC "-//W3C//NOTATION XHTML Datatype: Number//EN" >
<!- - integer representing length in pixels - ->
<!NOTATION pixels
PUBLIC "-//W3C//NOTATION XHTML Datatype: Pixels//EN" >
<!- - script expression - ->
<!NOTATION script
PUBLIC "-//W3C//NOTATION XHTML Datatype: Script//EN" >
<!- - textual content - ->
<!NOTATION text
PUBLIC "-//W3C//NOTATION XHTML Datatype: Text//EN" >
<!- - Imported Notations ................................ - ->
<!- - a single character from [ISO10646] - ->
<!NOTATION character
PUBLIC "-//W3C//NOTATION XHTML Datatype: Character//EN" >
<!- - a character encoding, as per [RFC2045] - ->
<!NOTATION charset
PUBLIC "-//W3C//NOTATION XHTML Datatype: Charset//EN" >
<!- - a space separated list of character encodings, as per [RFC2045] - ->
<!NOTATION charsets
Modulares Rahmenwerk von XHTML < 463 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
PUBLIC "-//W3C//NOTATION XHTML Datatype: Charsets//EN" >
<!- - media type, as per [RFC2045] - ->
<!NOTATION contentType
PUBLIC "-//W3C//NOTATION XHTML Datatype: ContentType//EN" >
<!- - comma-separated list of media types, as per [RFC2045] - ->
<!NOTATION contentTypes
PUBLIC "-//W3C//NOTATION XHTML Datatype: ContentTypes//EN" >
<!- - date and time information. ISO date format - ->
<!NOTATION datetime
PUBLIC "-//W3C//NOTATION XHTML Datatype: Datetime//EN" >
<!- - a language code, as per [RFC3066] - ->
<!NOTATION languageCode
PUBLIC "-//W3C//NOTATION XHTML Datatype: LanguageCode//EN" >
Modularisierung von XHTML
<!- - a Uniform Resource Identifier, see [URI] - ->
<!NOTATION uri
PUBLIC "-//W3C//NOTATION XHTML Datatype: URI//EN" >
<!- - a space-separated list of Uniform Resource Identifiers, see [URI] - ->
<!NOTATION uris
PUBLIC "-//W3C//NOTATION XHTML Datatype: URIs//EN" >
<!- - end of [Link] - ->
F.2.3 XHTML-Datentypen
<!- - ...................................................................... - ->
<!- - XHTML Datatypes Module .............................................. - ->
<!- - file: [Link]
This is XHTML, a reformulation of HTML as a modular XML application.
Copyright 1998-2001 W3C (MIT, INRIA, Keio), All Rights Reserved.
Revision: $Id: [Link],v 4.1 2001/04/06 19:23:32 altheim Exp $
SMI
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//ENTITIES XHTML Datatypes 1.0//EN"
SYSTEM "[Link]
Revisions:
(none)
....................................................................... - ->
<!- - Datatypes
defines containers for the following datatypes, many of
these imported from other specifications and standards.
- ->
<!- - Length defined for cellpadding/cellspacing - ->
< 464 > Implementierungen von XHTML-Modulen mit DTDs
Page size: 168,00 x 240,00 mm
<!- - nn for pixels or nn% for percentage length - ->
<!ENTITY % [Link] "CDATA" >
<!- - space-separated list of link types - ->
<!ENTITY % [Link] "NMTOKENS" >
<!- - single or comma-separated list of media descriptors - ->
<!ENTITY % [Link] "CDATA" >
<!- - pixel, percentage, or relative - ->
<!ENTITY % [Link] "CDATA" >
<!- - one or more digits (NUMBER) - ->
<!ENTITY % [Link] "CDATA" >
<!- - integer representing length in pixels - ->
<!ENTITY % [Link] "CDATA" >
Modularisierung von XHTML
<!- - script expression - ->
<!ENTITY % [Link] "CDATA" >
<!- - textual content - ->
<!ENTITY % [Link] "CDATA" >
<!- - Imported Datatypes ................................ - ->
<!- - a single character from [ISO10646] - ->
<!ENTITY % [Link] "CDATA" >
<!- - a character encoding, as per [RFC2045] - ->
<!ENTITY % [Link] "CDATA" >
<!- - a space separated list of character encodings, as per [RFC2045] - ->
<!ENTITY % [Link] "CDATA" >
<!- - Color specification using color name or sRGB (#RRGGBB) values - ->
<!ENTITY % [Link] "CDATA" >
<!- - media type, as per [RFC2045] - ->
<!ENTITY % [Link] "CDATA" >
<!- - comma-separated list of media types, as per [RFC2045] - ->
<!ENTITY % [Link] "CDATA" >
<!- - date and time information. ISO date format - ->
<!ENTITY % [Link] "CDATA" >
<!- - formal public identifier, as per [ISO8879] - ->
<!ENTITY % [Link] "CDATA" >
<!- - a language code, as per [RFC3066] - ->
<!ENTITY % [Link] "NMTOKEN" >
<!- - a Uniform Resource Identifier, see [URI] - ->
<!ENTITY % [Link] "CDATA" >
Modulares Rahmenwerk von XHTML < 465 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!- - a space-separated list of Uniform Resource Identifiers, see [URI] - ->
<!ENTITY % [Link] "CDATA" >
<!- - end of [Link] - ->
F.2.4 Definition allgemeiner Attribute von XHTML
<!- - ...................................................................... - ->
<!- - XHTML Common Attributes Module ...................................... - ->
<!- - file: [Link]
This is XHTML, a reformulation of HTML as a modular XML application.
Copyright 1998-2001 W3C (MIT, INRIA, Keio), All Rights Reserved.
Revision: $Id: [Link],v 4.0 2001/04/02 22:42:49 altheim Exp $ SMI
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
Modularisierung von XHTML
PUBLIC "-//W3C//ENTITIES XHTML Common Attributes 1.0//EN"
SYSTEM "[Link]
Revisions:
(none)
....................................................................... - ->
<!- - Common Attributes
This module declares many of the common attributes for the XHTML DTD.
%[Link]; is declared in the XHTML Qname module.
- ->
<!ENTITY % [Link]
"id ID #IMPLIED"
>
<!ENTITY % [Link]
"class NMTOKENS #IMPLIED"
>
<!ENTITY % [Link]
"title %[Link]; #IMPLIED"
>
<!ENTITY % [Link] "" >
<!ENTITY % [Link]
"%[Link];
%[Link];
%[Link];
%[Link];
%[Link];"
>
<!ENTITY % [Link]
"xml:lang %[Link]; #IMPLIED"
>
< 466 > Implementierungen von XHTML-Modulen mit DTDs
Page size: 168,00 x 240,00 mm
<![%[Link];[
<!ENTITY % [Link]
"dir ( ltr | rtl ) #IMPLIED"
>
<!ENTITY % [Link]
"%[Link];
%[Link];"
>
]]>
<!ENTITY % [Link]
"%[Link];"
>
<!ENTITY % [Link] "" >
Modularisierung von XHTML
<!- - intrinsic event attributes declared previously
- ->
<!ENTITY % [Link] "" >
<!ENTITY % [Link]
"%[Link];
%[Link];
%[Link];
%[Link];"
>
<!- - end of [Link] - ->
F.2.5 Qualifizierte Namen von XHTML
<!- - ....................................................................... - ->
<!- - XHTML Qname Module ................................................... - ->
<!- - file: [Link]
This is XHTML, a reformulation of HTML as a modular XML application.
Copyright 1998-2001 W3C (MIT, INRIA, Keio), All Rights Reserved.
Revision: $Id: [Link],v 4.0 2001/04/02 22:42:49 altheim Exp $ SMI
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//ENTITIES XHTML Qualified Names 1.0//EN"
SYSTEM "[Link]
Revisions:
#2000-10-22: added qname declarations for ruby elements
....................................................................... - ->
<!- - XHTML Qname (Qualified Name) Module
This module is contained in two parts, labeled Section 'A' and 'B':
Modulares Rahmenwerk von XHTML < 467 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Section A declares parameter entities to support namespace-
qualified names, namespace declarations, and name prefixing
for XHTML and extensions.
Section B declares parameter entities used to provide
namespace-qualified names for all XHTML element types:
%[Link]; the xmlns-qualified name for <applet>
%[Link]; the xmlns-qualified name for <base>
...
XHTML extensions would create a module similar to this one.
Included in the XHTML distribution is a template module
('[Link]') suitable for this purpose.
- ->
<!- - Section A: XHTML XML Namespace Framework :::::::::::::::::::: - ->
Modularisierung von XHTML
<!- - 1. Declare a %[Link]; conditional section keyword, used
to activate namespace prefixing. The default value should
inherit '%[Link];' from the DTD driver, so that unless
overridden, the default behaviour follows the overall DTD
prefixing scheme.
- ->
<!ENTITY % [Link] "IGNORE" >
<!ENTITY % [Link] "%[Link];" >
<!- - 2. Declare a parameter entity (eg., %[Link];) containing
the URI reference used to identify the XHTML namespace:
- ->
<!ENTITY % [Link] "[Link] >
<!- - 3. Declare parameter entities (eg., %[Link];) containing
the default namespace prefix string(s) to use when prefixing
is enabled. This may be overridden in the DTD driver or the
internal subset of an document instance. If no default prefix
is desired, this may be declared as an empty string.
NOTE: As specified in [XMLNAMES], the namespace prefix serves
as a proxy for the URI reference, and is not in itself significant.
- ->
<!ENTITY % [Link] "" >
<!- - 4. Declare parameter entities (eg., %[Link];) containing the
colonized prefix(es) (eg., '%[Link];:') used when
prefixing is active, an empty string when it is not.
- ->
<![%[Link];[
<!ENTITY % [Link] "%[Link];:" >
]]>
<!ENTITY % [Link] "" >
<!- - declare qualified name extensions here ............ - ->
<!ENTITY % [Link] "" >
%[Link];
< 468 > Implementierungen von XHTML-Modulen mit DTDs
Page size: 168,00 x 240,00 mm
<!- - 5. The parameter entity %[Link]; may be
redeclared to contain any non-XHTML namespace declaration
attributes for namespaces embedded in XHTML. The default
is an empty string. XLink should be included here if used
in the DTD.
- ->
<!ENTITY % [Link] "" >
<!- - The remainder of Section A is only followed in XHTML, not extensions. - ->
<!- - Declare a parameter entity %[Link]; containing
all XML Namespace declarations used in the DTD, plus the
xmlns declaration for XHTML, its form dependent on whether
prefixing is active.
- ->
<![%[Link];[
<!ENTITY % [Link]
Modularisierung von XHTML
"xmlns:%[Link]; %[Link]; #FIXED '%[Link];'
%[Link];"
>
]]>
<!ENTITY % [Link]
"%[Link];"
>
<!- - This is a placeholder for future XLink support.
- ->
<!ENTITY % [Link] "" >
<!- - Declare a parameter entity %[Link]; containing all
XML namespace declaration attributes used by XHTML, including
a default xmlns attribute when prefixing is inactive.
- ->
<![%[Link];[
<!ENTITY % [Link]
"%[Link];
%[Link];"
>
]]>
<!ENTITY % [Link]
"xmlns %[Link]; #FIXED '%[Link];'
%[Link];"
>
<!- - placeholder for qualified name redeclarations - ->
<!ENTITY % [Link] "" >
%[Link];
<!- - Section B: XHTML Qualified Names ::::::::::::::::::::::::::::: - ->
<!- - 6. This section declares parameter entities used to provide
namespace-qualified names for all XHTML element types.
- ->
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];applet" >
Modulares Rahmenwerk von XHTML < 469 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];base" >
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];bdo" >
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];address" >
<!ENTITY % [Link] "%[Link];blockquote" >
<!ENTITY % [Link] "%[Link];pre" >
<!ENTITY % [Link] "%[Link];h1" >
<!ENTITY % [Link] "%[Link];h2" >
<!ENTITY % [Link] "%[Link];h3" >
<!ENTITY % [Link] "%[Link];h4" >
<!ENTITY % [Link] "%[Link];h5" >
<!ENTITY % [Link] "%[Link];h6" >
Modularisierung von XHTML
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];hr" >
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];div" >
<!ENTITY % [Link] "%[Link];p" >
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];ins" >
<!ENTITY % [Link] "%[Link];del" >
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];form" >
<!ENTITY % [Link] "%[Link];label" >
<!ENTITY % [Link] "%[Link];input" >
<!ENTITY % [Link] "%[Link];select" >
<!ENTITY % [Link] "%[Link];optgroup" >
<!ENTITY % [Link] "%[Link];option" >
<!ENTITY % [Link] "%[Link];textarea" >
<!ENTITY % [Link] "%[Link];fieldset" >
<!ENTITY % [Link] "%[Link];legend" >
<!ENTITY % [Link] "%[Link];button" >
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];a" >
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];img" >
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];abbr" >
<!ENTITY % [Link] "%[Link];acronym" >
<!ENTITY % [Link] "%[Link];cite" >
<!ENTITY % [Link] "%[Link];code" >
<!ENTITY % [Link] "%[Link];dfn" >
<!ENTITY % [Link] "%[Link];em" >
<!ENTITY % [Link] "%[Link];kbd" >
<!ENTITY % [Link] "%[Link];q" >
<!ENTITY % [Link] "%[Link];samp" >
< 470 > Implementierungen von XHTML-Modulen mit DTDs
Page size: 168,00 x 240,00 mm
<!ENTITY % [Link] "%[Link];strong" >
<!ENTITY % [Link] "%[Link];var" >
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];b" >
<!ENTITY % [Link] "%[Link];big" >
<!ENTITY % [Link] "%[Link];i" >
<!ENTITY % [Link] "%[Link];small" >
<!ENTITY % [Link] "%[Link];sub" >
<!ENTITY % [Link] "%[Link];sup" >
<!ENTITY % [Link] "%[Link];tt" >
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];br" >
<!ENTITY % [Link] "%[Link];span" >
<!- - module: [Link] (also csismap, ssismap) - ->
Modularisierung von XHTML
<!ENTITY % [Link] "%[Link];map" >
<!ENTITY % [Link] "%[Link];area" >
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];link" >
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];dl" >
<!ENTITY % [Link] "%[Link];dt" >
<!ENTITY % [Link] "%[Link];dd" >
<!ENTITY % [Link] "%[Link];ol" >
<!ENTITY % [Link] "%[Link];ul" >
<!ENTITY % [Link] "%[Link];li" >
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];meta" >
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];param" >
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];object" >
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];script" >
<!ENTITY % [Link] "%[Link];noscript" >
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];html" >
<!ENTITY % [Link] "%[Link];head" >
<!ENTITY % [Link] "%[Link];title" >
<!ENTITY % [Link] "%[Link];body" >
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];style" >
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];table" >
<!ENTITY % [Link] "%[Link];caption" >
Modulares Rahmenwerk von XHTML < 471 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!ENTITY % [Link] "%[Link];thead" >
<!ENTITY % [Link] "%[Link];tfoot" >
<!ENTITY % [Link] "%[Link];tbody" >
<!ENTITY % [Link] "%[Link];colgroup" >
<!ENTITY % [Link] "%[Link];col" >
<!ENTITY % [Link] "%[Link];tr" >
<!ENTITY % [Link] "%[Link];th" >
<!ENTITY % [Link] "%[Link];td" >
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];ruby" >
<!ENTITY % [Link] "%[Link];rbc" >
<!ENTITY % [Link] "%[Link];rtc" >
<!ENTITY % [Link] "%[Link];rb" >
<!ENTITY % [Link] "%[Link];rt" >
<!ENTITY % [Link] "%[Link];rp" >
Modularisierung von XHTML
<!- - Provisional XHTML 2.0 Qualified Names ...................... - ->
<!- - module: [Link] - ->
<!ENTITY % [Link] "%[Link];alt" >
<!- - end of [Link] - ->
F.2.6 Zeichen-Entities von XHTML
<!- - ...................................................................... - ->
<!- - XHTML Character Entities Module ......................................... - ->
<!- - file: [Link]
This is XHTML, a reformulation of HTML as a modular XML application.
Copyright 1998-2001 W3C (MIT, INRIA, Keio), All Rights Reserved.
Revision: $Id: [Link],v 4.0 2001/04/02 22:42:49 altheim Exp $ SMI
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//ENTITIES XHTML Character Entities 1.0//EN"
SYSTEM "[Link]
Revisions:
(none)
....................................................................... - ->
<!- - Character Entities for XHTML
This module declares the set of character entities for XHTML,
including the Latin 1, Symbol and Special character collections.
- ->
<!ENTITY % xhtml-lat1
PUBLIC "-//W3C//ENTITIES Latin 1 for XHTML//EN"
"[Link]" >
%xhtml-lat1;
< 472 > Implementierungen von XHTML-Modulen mit DTDs
Page size: 168,00 x 240,00 mm
<!ENTITY % xhtml-symbol
PUBLIC "-//W3C//ENTITIES Symbols for XHTML//EN"
"[Link]" >
%xhtml-symbol;
<!ENTITY % xhtml-special
PUBLIC "-//W3C//ENTITIES Special for XHTML//EN"
"[Link]" >
%xhtml-special;
<!- - end of [Link] - ->
F.3 Implementierungen der XHTML-Module
Dieser Abschnitt enth@lt die formalen Definitionen jedes der abstrakten XHTML-Module in
Modularisierung von XHTML
Form eines DTD-Moduls.
Die Listings, die sich an dieser Stelle in der englischen Online-Fassung befinden, sind vor allem
in elektronischer Form interessant. Sie stehen deshalb auch in der deutschen Online-Fassung
zur Verf gung. Zur leichteren Orientierung haben wir die Abschnitt berschriften abgedruckt.
F.3.1 Kernmodule von XHTML
F.3.1.1 Struktur
F.3.1.2 Text
F.3.1.3 Hypertext
F.3.1.4 Listen
F.3.2 Applet
F.3.3 Text-Module
F.3.3.1 Darstellung
F.3.3.3 Bidirektionaler Text
F.3.4 Formulare
F.3.4.1 Basisformulare
F.3.4.2 Formulare
F.3.5 Tabellen
F.3.5.1 Basistabellen
F.3.5.2 Tabellen
F.3.6 Bild
Implementierungen der XHTML-Module < 473 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
F.3.7 Client-seitige Image Maps
F.3.8 Server-seitige Image Maps
F.3.9 Objekt
F.3.10 Frames
F.3.11 Target
F.3.12 Iframe
F.3.13 Eingebaute Ereignisse
F.3.14 Metainformation
Modularisierung von XHTML
F.3.15 Scripting
F.3.16 Stylesheet
F.3.17 Style-Attribut
F.3.18 Link
F.3.19 Base
F.3.20 Name-Identifizierung
F.3.21 Altlasten
F.4 Unterst-tzende Module der
XHTML-DTD-Implementierung
Die Module in diesem Abschnitt sind Teil der DTD-Implementierung von XHTML. W@hrend
sie vor Gelegenheitsanwendern versteckt sind, ist ihr Verst@ndnis wichtig f r die Herstellung
abgeleiteter Auszeichnungssprachen unter Verwendung der Modularisierungsarchitektur.
F.4.1 Ausdr-cke auf Blockebene
<!- - ...................................................................... - ->
<!- - XHTML Block Phrasal Module .......................................... - ->
<!- - file: [Link]
This is XHTML, a reformulation of HTML as a modular XML application.
Copyright 1998-2001 W3C (MIT, INRIA, Keio), All Rights Reserved.
Revision: $Id: [Link],v 4.0 2001/04/02 22:42:49 altheim Exp $ SMI
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//ELEMENTS XHTML Block Phrasal 1.0//EN"
SYSTEM "[Link]
< 474 > Module der XHTML-DTD-Implementierung
Page size: 168,00 x 240,00 mm
Revisions:
(none)
....................................................................... - ->
<!- - Block Phrasal
address, blockquote, pre, h1, h2, h3, h4, h5, h6
This module declares the elements and their attributes used to
support block-level phrasal markup.
- ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*" >
<!ENTITY % [Link] "address" >
<!ELEMENT %[Link]; %[Link]; >
Modularisierung von XHTML
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( %[Link]; )+"
>
<!ENTITY % [Link] "blockquote" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
cite %[Link]; #IMPLIED
>
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA
| %[Link];
%[Link];
| %[Link]; | %[Link]; | %[Link];
%[Link];
%[Link];
| %[Link]; | %[Link];
%[Link]; )*"
>
<!ENTITY % [Link] "pre" >
Implementierungen der XHTML-Module < 475 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
xml:space ( preserve ) #FIXED 'preserve'
>
<!- - end of [Link] - ->]]>
<!- - ................... Heading Elements ................... - ->
<!ENTITY % [Link] "( #PCDATA | %[Link]; )*" >
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
Modularisierung von XHTML
<!ENTITY % [Link] "h1" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link] "h2" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link] "h3" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
< 476 > Module der XHTML-DTD-Implementierung
Page size: 168,00 x 240,00 mm
<!ENTITY % [Link] "h4" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link] "h5" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
Modularisierung von XHTML
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link] "h6" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!- - end of [Link] - ->
F.4.2 Darstellung auf Blockebene
<!- - ...................................................................... - ->
<!- - XHTML Block Presentation Module ..................................... - ->
<!- - file: [Link]
This is XHTML, a reformulation of HTML as a modular XML application.
Copyright 1998-2001 W3C (MIT, INRIA, Keio), All Rights Reserved.
Revision: $Id: [Link],v 4.0 2001/04/02 22:42:49 altheim Exp $ SMI
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//ELEMENTS XHTML Block Presentation 1.0//EN"
SYSTEM "[Link]
Revisions:
(none)
....................................................................... - ->
Implementierungen der XHTML-Module < 477 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!- - Block Presentational Elements
hr
This module declares the elements and their attributes used to
support block-level presentational markup.
- ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link] "EMPTY" >
<!ENTITY % [Link] "hr" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
Modularisierung von XHTML
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!- - end of [Link] - ->
F.4.3 Strukturelle Blockelemente
<!- - ...................................................................... - ->
<!- - XHTML Block Structural Module ....................................... - ->
<!- - file: [Link]
This is XHTML, a reformulation of HTML as a modular XML application.
Copyright 1998-2001 W3C (MIT, INRIA, Keio), All Rights Reserved.
Revision: $Id: [Link],v 4.0 2001/04/02 22:42:49 altheim Exp $
SMI
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//ELEMENTS XHTML Block Structural 1.0//EN"
SYSTEM "[Link]
Revisions:
(none)
....................................................................... - ->
<!- - Block Structural
div, p
This module declares the elements and their attributes used to
support block-level structural markup.
- ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
< 478 > Module der XHTML-DTD-Implementierung
Page size: 168,00 x 240,00 mm
"( #PCDATA | %[Link]; )*"
>
<!ENTITY % [Link] "div" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*" >
Modularisierung von XHTML
<!ENTITY % [Link] "p" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!- - end of [Link] - ->
F.4.4 Inzeilige Ausdr-cke
<!- - ...................................................................... - ->
<!- - XHTML Inline Phrasal Module ......................................... - ->
<!- - file: [Link]
This is XHTML, a reformulation of HTML as a modular XML application.
Copyright 1998-2001 W3C (MIT, INRIA, Keio), All Rights Reserved.
Revision: $Id: [Link],v 4.0 2001/04/02 22:42:49 altheim Exp $ SMI
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//ELEMENTS XHTML Inline Phrasal 1.0//EN"
SYSTEM "[Link]
Revisions:
(none)
....................................................................... - ->
<!- - Inline Phrasal
abbr, acronym, cite, code, dfn, em, kbd, q, samp, strong, var
This module declares the elements and their attributes used to
support inline-level phrasal markup.
Implementierungen der XHTML-Module < 479 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
- ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*"
>
<!ENTITY % [Link] "abbr" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
Modularisierung von XHTML
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*"
>
<!ENTITY % [Link] "acronym" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*"
>
<!ENTITY % [Link] "cite" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*"
>
<!ENTITY % [Link] "code" >
< 480 > Module der XHTML-DTD-Implementierung
Page size: 168,00 x 240,00 mm
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*"
>
<!ENTITY % [Link] "dfn" >
<!ELEMENT %[Link]; %[Link]; >
Modularisierung von XHTML
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*"
>
<!ENTITY % [Link] "em" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*"
>
<!ENTITY % [Link] "kbd" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
Implementierungen der XHTML-Module < 481 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*"
>
<!ENTITY % [Link] "q" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
cite %[Link]; #IMPLIED
>
Modularisierung von XHTML
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*"
>
<!ENTITY % [Link] "samp" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*"
>
<!ENTITY % [Link] "strong" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*"
>
< 482 > Module der XHTML-DTD-Implementierung
Page size: 168,00 x 240,00 mm
<!ENTITY % [Link] "var" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!- - end of [Link] - ->
F.4.5 Inzeilige Darstellung
<!- - ...................................................................... - ->
Modularisierung von XHTML
<!- - XHTML Inline Presentation Module .................................... - ->
<!- - file: [Link]
This is XHTML, a reformulation of HTML as a modular XML application.
Copyright 1998-2001 W3C (MIT, INRIA, Keio), All Rights Reserved.
Revision: $Id: [Link],v 4.0 2001/04/02 22:42:49 altheim Exp $ SMI
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//ELEMENTS XHTML Inline Presentation 1.0//EN"
SYSTEM "[Link]
Revisions:
(none)
....................................................................... - ->
<!- - Inline Presentational Elements
b, big, i, small, sub, sup, tt
This module declares the elements and their attributes used to
support inline-level presentational markup.
- ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*"
>
<!ENTITY % [Link] "b" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
Implementierungen der XHTML-Module < 483 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*"
>
<!ENTITY % [Link] "big" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
Modularisierung von XHTML
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*"
>
<!ENTITY % [Link] "i" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*"
>
<!ENTITY % [Link] "small" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*"
>
<!ENTITY % [Link] "sub" >
<!ELEMENT %[Link]; %[Link]; >
< 484 > Module der XHTML-DTD-Implementierung
Page size: 168,00 x 240,00 mm
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*"
>
<!ENTITY % [Link] "sup" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
Modularisierung von XHTML
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*"
>
<!ENTITY % [Link] "tt" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!- - end of [Link] - ->
F.4.6 Inzeilige Strukturelemente
<!- - ...................................................................... - ->
<!- - XHTML Inline Structural Module ...................................... - ->
<!- - file: [Link]
This is XHTML, a reformulation of HTML as a modular XML application.
Copyright 1998-2001 W3C (MIT, INRIA, Keio), All Rights Reserved.
Revision: $Id: [Link],v 4.0 2001/04/02 22:42:49 altheim Exp $
Implementierungen der XHTML-Module < 485 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
SMI
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//ELEMENTS XHTML Inline Structural 1.0//EN"
SYSTEM "[Link]
Revisions:
(none)
....................................................................... - ->
<!- - Inline Structural
br, span
This module declares the elements and their attributes
used to support inline-level structural markup.
Modularisierung von XHTML
- ->
<!- - br: forced line break ............................. - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link] "EMPTY" >
<!ENTITY % [Link] "br" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!- - span: generic inline container .................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*"
>
<!ENTITY % [Link] "span" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
>
<!- - end of [Link] - ->]]>
<!- - end of [Link] - ->
< 486 > Module der XHTML-DTD-Implementierung
Page size: 168,00 x 240,00 mm
F.4.7 Param
<!- - ...................................................................... - ->
<!- - XHTML Param Element Module ..................................... - ->
<!- - file: [Link]
This is XHTML, a reformulation of HTML as a modular XML application.
Copyright 1998-2001 W3C (MIT, INRIA, Keio), All Rights Reserved.
Revision: $Id: [Link],v 4.0 2001/04/02 22:42:49 altheim Exp $ SMI
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//ELEMENTS XHTML Param Element 1.0//EN"
SYSTEM "[Link]
Revisions:
(none)
Modularisierung von XHTML
....................................................................... - ->
<!- - Parameters for Java Applets and Embedded Objects
param
This module provides declarations for the param element,
used to provide named property values for the applet
and object elements.
- ->
<!- - param: Named Property Value ....................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link] "EMPTY" >
<!ENTITY % [Link] "param" >
<!ELEMENT %[Link]; %[Link]; >
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ATTLIST %[Link];
%[Link];
%[Link];
name CDATA #REQUIRED
value CDATA #IMPLIED
valuetype ( data | ref | object ) 'data'
type %[Link]; #IMPLIED
>
<!- - end of [Link] - ->]]>
<!- - end of [Link] - ->
Implementierungen der XHTML-Module < 487 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
F.4.8 Neudeklarierung von Altlasten
<!- - ...................................................................... - ->
<!- - XHTML Legacy Redeclarations Module ................................... - ->
<!- - file: [Link]
This is an extension of XHTML, a reformulation of HTML as a modular XML
application.
Copyright 1998-2001 W3C (MIT, INRIA, Keio), All Rights Reserved.
Revision: $Id: [Link],v 4.4 2001/04/10 09:42:30 altheim Exp
$ SMI
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//ELEMENTS XHTML Legacy Redeclarations 1.0//EN"
SYSTEM
"[Link]
Modularisierung von XHTML
Revisions:
(none)
....................................................................... - ->
<!- - Legacy Redeclarations
This optional module replaces the Modular Framework module, interspersing
redeclarations of various parameter entities to allow for inclusions of
Transitional markup in the XHTML 1.1 document model. This instantiates
the modules needed to support the XHTML modularization model, including:
+ notations
+ datatypes
+ namespace-qualified names
+ common attributes
+ document model
+ character entities
By default, the Object module is included, with Frames and IFrames ignored.
The Intrinsic Events module is ignored by default but
occurs in this module because it must be instantiated
prior to Attributes but after Datatypes.
- ->
<!ENTITY % [Link] "INCLUDE" >
<!ENTITY % [Link] "IGNORE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Base Architecture 1.0//EN"
"[Link]" >
%[Link];]]>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//NOTATIONS XHTML Notations 1.0//EN"
< 488 > Module der XHTML-DTD-Implementierung
Page size: 168,00 x 240,00 mm
"[Link]" >
%[Link];]]>
<!- - Datatypes Module ............................................ - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ENTITIES XHTML Datatypes 1.0//EN"
"[Link]" >
%[Link];]]>
<!- - Qualified Names Module ...................................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ENTITIES XHTML Qualified Names 1.0//EN"
"[Link]" >
Modularisierung von XHTML
%[Link];]]>
<!- - Additional Qualified Names .................................. - ->
<!- - [Link] - ->
<!ENTITY % [Link] "%[Link];font" >
<!ENTITY % [Link] "%[Link];basefont" >
<!ENTITY % [Link] "%[Link];center" >
<!ENTITY % [Link] "%[Link];s" >
<!ENTITY % [Link] "%[Link];strike" >
<!ENTITY % [Link] "%[Link];u" >
<!ENTITY % [Link] "%[Link];dir" >
<!ENTITY % [Link] "%[Link];menu" >
<!ENTITY % [Link] "%[Link];isindex" >
<!- - [Link] - ->
<!ENTITY % [Link] "%[Link];frameset" >
<!ENTITY % [Link] "%[Link];frame" >
<!ENTITY % [Link] "%[Link];noframes" >
<!- - [Link] - ->
<!ENTITY % [Link] "%[Link];iframe" >
<!ENTITY % [Link] "IGNORE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ENTITIES XHTML Intrinsic Events 1.0//EN"
"[Link]" >
%[Link];]]>
<!- - Additional Common Attributes ................................ - ->
<!- - include historical 'lang' attribute (which should
always match the value of 'xml:lang')
- ->
Implementierungen der XHTML-Module < 489 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!ENTITY % [Link]
"xml:lang %[Link]; #IMPLIED
lang %[Link]; #IMPLIED"
>
<!- - Common Attributes Module .................................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ENTITIES XHTML Common Attributes 1.0//EN"
"[Link]" >
%[Link];]]>
<!- - placeholder for content model redeclarations - ->
<!ENTITY % [Link] "" >
%[Link];
Modularisierung von XHTML
<!- - Document Model Redeclarations ............................... - ->
<!ENTITY % [Link]
"| %[Link]; | %[Link]; | %[Link]; | %[Link];
| %[Link]; | %[Link]; | %[Link];
| %[Link]; | %[Link]; | %[Link];
| %[Link]; | %[Link]; | %[Link];"
>
<!ENTITY % [Link]
"| %[Link]; | %[Link];
| %[Link]; | %[Link];" >
<!ENTITY % [Link]
"| %[Link]; | %[Link];"
>
<!ENTITY % [Link]
"| %[Link]; | %[Link]; | %[Link];
| %[Link]; | %[Link];"
>
<!ENTITY % [Link]
"%[Link]; | %[Link]; | %[Link];
| %[Link]; | %[Link];"
>
<!- - Document Model Module ...................................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!- - instantiate the Document Model module declared in the DTD driver
- ->
%[Link];]]>
<!ENTITY % [Link]
"( #PCDATA | %[Link]; | %[Link]; )*"
>
<!ENTITY % [Link]
< 490 > Module der XHTML-DTD-Implementierung
Page size: 168,00 x 240,00 mm
"( #PCDATA | %[Link]; )*"
>
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*"
>
<!ENTITY % [Link]
"( #PCDATA | %[Link]; )*"
>
<!- - redeclare content model of <html> to allow for either
body or frameset content. The SGML markup minimization
features used in HTML 4 do not apply, so the ambiguity
that necessitated separation into the separate Frameset
and Transitional DTDs is eliminated.
- ->
Modularisierung von XHTML
<!ENTITY % [Link]
"( %[Link];, ( %[Link]; | %[Link]; ) )"
>
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ENTITIES XHTML Character Entities 1.0//EN"
"[Link]" >
%[Link];]]>
<!- - end of [Link] - ->
G Bibliographie
Dieser Anhang ist normativ.
G.1 Normative Quellen
[CSS2]
"Cascading Style Sheets, level 2 (CSS2) Specification", W3C Recommendation, B. Bos,
H. W. Lie, C. Lilley, I. Jacobs (Hrsg.), 12 May 1998.
Verf gbar unter: [Link]
[DOM]
"Document Object Model (DOM) Level 1 Specification", L. Wood et al., 1 Oktober 1998.
Verf gbar unter: [Link]
[HTML4]
"HTML 4.01 Specification: W3C Recommendation", W3C Recommendation, D. Raggett,
A. Le Hors, I. Jacobs (Hrsg.), 24 Dezember 1999.
Verf gbar unter: [Link]
Bibliographie < 491 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
[ISO10646]
"Information Technology – Universal Multiple-Octet Coded Character Set (UCS) – Part 1:
Architecture and Basic Multilingual Plane", ISO/IEC 10646-1:2000. Diese Referenz verweist
auf eine Menge von Codepunkten, die sich ver@ndern k=nnen, wenn ihnen neue Zeichen
zugewiesen werden. Zudem nimmt diese Referenz an, dass die durch ISO 10646 und [UNI-
CODE] definierten Zeichenmenge Zeichen-f r-Zeichen @quivalent bleiben. Des weiteren
schließt diese Referenz zuk nftige Ver=ffentlichungen anderer Teile von 10646 (das heißt,
andere als Teil 1) ein, die Zeichen in den Ebenen 1-16 definieren.
[RFC1808]
"Relative Uniform Resource Locators", RFC 1808, R. Fielding, Juni 1995.
Verf gbar unter: [Link]
[RFC2045]
"Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, N. Freed, N. Borenstein, November 1996.
Modularisierung von XHTML
Verf gbar unter: [Link]
[RFC2119]
"Key words for use in RFCs to indicate requirement levels", RFC 2119, S. Bradner, M@rz
1997.
Verf gbar unter: [Link]
[RFC3066]
"Tags for the Identification of Languages", RFC 3066, H. Alvestrand, Januar 2001.
Verf gbar unter: [Link]
[SGML]
"Information Processing – Text and Office Systems – Standard Generalized Markup
Language (SGML)", ISO 8879:1986.
Unter [Link] finden Sie Informationen ber die Norm und
unter [Link] Allgemeines zu SGML.
[SRGB]
"A Standard Default Color Space for the Internet", version 1.10, M. Stokes, M. Anderson,
S. Chandrasekar und R. Motta, 5 November 1996. Verf gbar unter: [Link]
Graphics/Color/sRGB
[UNICODE]
"The Unicode Standard", The Unicode Consortium. Version 3.1 des Unicode-Standards
besteht aus einem Buch, das Version 3.0 abdeckt, sowie aus einem Anhang zum Unicode-
Standard, der die Onderungen und Erg@nzungen, die Version 3.1 ausmachen, dokumentiert.
"The Unicode Standard – Version 3.0", The Unicode Consortium, Reading, Mass.: Addison-
Wesley Developers Press, 2000. ISBN 0-201-61633-5 (siehe [Link]
unicode/uni2book/[Link] f r eine Online-Ausgabe des Buches).
"Unicode Standard Annex #27 – Unicode 3.1", Mark Davis, Michael Everson, Asmus Frey-
tag, John H. Jenkins et al. (siehe [Link]
F r Weiteres ber Unicode siehe [Link]
[URI]
"Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, T. Berners-Lee, R. Fiel-
ding, L. Masinter, August 1998.
Verf gbar unter: [Link] Dieser RFC aktualisiert RFC 1738
[URL] und [RFC1808].
< 492 > Bibliographie
Page size: 168,00 x 240,00 mm
[URL]
"Uniform Resource Locators (URL)", RFC 1738, T. Berners-Lee, L. Masinter, M. McCahill,
Dezember 1994.
Verf gbar unter: [Link]
[XHTML1]
"XHTML 1.0: The Extensible HyperText Markup Language", W3C Recommendation,
S. Pemberton et al., 26 Januar 2000.
Verf gbar unter: [Link]
[XML]
"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation, T. Bray,
J. Paoli, C. M. Sperberg-McQueen, E. Maler (Hrsg.), 6 Oktober 2000.
Verf gbar unter: [Link]
[XMLNAMES]
"Namespaces in XML", W3C Recommendation, T. Bray, D. Hollander, A. Layman (Hrsg.),
Modularisierung von XHTML
14 Januar 1999.
Verf gbar unter: [Link]
[XMLSCHEMA]
"XML Schema Part 1: Structures", W3C Proposed Recommendation, H. S. Thompson,
D. Beech, M. Maloney, N. Mendelsohn (Hrsg.), 30 M@rz 2001.
Verf gbar unter: [Link]
Siehe auch "XML Schema Part 2: Datatypes", Verf gbar unter: [Link]
TR/2001/PR-xmlschema-2-20010330
G.2 Informelle Quellen
[MATHML]
"Mathematical Markup Language (MathML) Version 2.0", W3C Recommendation, D. Carlis-
le, P. Ion, R. Miner, N. Poppelie (Hrsg.), 21 February 2001.
Verf gbar unter: [Link]
[SMIL]
"Synchronized Multimedia Integration Language (SMIL) 1.0 Specification", W3C Recommen-
dation, P. Hoschka (Hrsg.), 15 Juni 1998.
Verf gbar unter: [Link]
[XLINK]
"XML Linking Language (XLink) Version 1.0", W3C Proposed Recommendation, S. DeRose,
E. Maler, D. Orchard (Hrsg.), 20 Dezember 2000.
Verf gbar unter: [Link]
[XMLSTYLE]
"Associating Style Sheets with XML documents Version 1.0", W3C Recommendation,
J. Clark (Hrsg.), 29 Juni 1999.
Verf gbar unter: [Link]
Informelle Quellen < 493 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
H Entwurfsziele
Dieser Anhang ist informell.
In diesem Anhang sind Entwurfziele (Design Goals) mit der Markierung „Gn“ versehen und
Anforderungen (Requirements) mit „Rn.n“. Es gibt vier Hauptziele f r das Modularisierungsrah-
menwerk f r XHTML::
·· [G1] Semantisch verwandte Teile von XHTML zusammenzufassen.
[G2] Einsatz von DTDs, um die Herstellung von verwandten Sprachen (Teilmengen, Ober-
mengen) f r bestimmte Zwecke (kleine Ger@te, Spezialger@te) zu unterst tzen und gleich-
zeitig Gemeinsamkeiten sich berlappender Teil zu gew@hrleisten.
· [G3] Zuk nftige Entwicklungen dadurch zu f=rdern, dass Teile der Sprache durch verbes-
serte Module (Formulare zum Beispiel) ersetzt werden k=nnen, ohne den Rest der Sprache
zu beeinflussen.
· [G4] Zur Wiederverwendung von Modulen in anderen Sprachen zu ermutigen und dies zu
Modularisierung von XHTML
f=rdern.
H.1 Anforderungen
Die Entwurfsziele des vorhergehenden Abschnitts f hren zu einer großen Zahl von Anforde-
rungen f r das Modularisierungsrahmenwerk. Diese Anforderungen, in diesem Absschnitt
zusammengefasst, k=nnen nach den zentralen Eigenschaften des Frameworks weiter klassifi-
ziert werden.
H.1.1 Granularit.t
Zusammengenommen dr cken die Anforderungen in diesem Abschnitt das Verlangen aus, dass
die im Rahmenwerk definierten Module den richtigen Grad der Granularit@t bekommen haben:
·· [R1.1] Abstrakte Module sollten Portabilit@t des Inhalts f=rdern und erhalten.
[R1.2] Abstrakte Module sollten die Normierung von Plattformprofilen f=rdern.
·· [R1.3] Abstrakte Module sollten groß genug sein, um Interoperabilit@t zu f=rdern.
[R1.4] Abstrakte Module sollten klein genung sein, um Bedarf f r Teilmengen zu vermei-
den.
· [R1.5] Abstrakte Module sollten Elemente mit @hnlicher oder verwandter Bedeutung sam-
meln.
· [R1.6] Abstrakte Module sollten Elemente mit un@hnlicher oder nicht verwandter Bedeu-
tung trennen.
· [R1.7] Module sollten klein genug sein, um einelementige Dokumenttyp-Module zu erlau-
ben.
< 494 > Entwurfsziele
Page size: 168,00 x 240,00 mm
H.1.2 Zusammensetzbarkeit
Die hier aufgef hrten Anforderungen der Zusammensetzbarkeit sollen gew@hrleisten, dass das
Modularisierungsrahmenwerk in der Lage ist, die richtige Menge von Zielmodulen auszudr -
cken, die von der Zielgruppe des Rahmenwerks ben=tigt werden:
·· [R2.1] Das Rahmenwerk sollte die Herstellung abstrakter Module f r XHTML 1.0 erlauben.
[R2.2] Das Rahmenwerk sollte die Herstellung abstrakter Module erlauben, die eine gute
N@herung an HTML 4 sind.
· [R2.3] Das Rahmenwerk sollte die Herstellung abstrakter Module f r ander W3C Recom-
mendations erlauben.
· [R2.4] Das Rahmenwerk sollte die Herstellung abstrakter Module f r andere XML-Doku-
menttypen erlauben.
· [R2.5] Das Rahmenwerk sollte die Herstellung abstrakter Module f r ein breites Spektrum
von Plattformprofilen erlauben.
Modularisierung von XHTML
H.1.3 Einfache Verwendbarkeit
Das Modularisierungsrahmenwerk wird nur dann allgemein akzeptiert, wenn es die beschriebe-
nen Mechanismen f r unsere Zielgruppe einfach gestalten, das Rahmenwerk zu benutzen:
· [R3.1] Das Rahmenwerk sollte es f r Dokumenttypentwickler einfach gestalten, abstrakte
XHTML-Module einzuschr@nken und zu erweitern.
· [R3.2] Das Rahmenwerk sollte es f r Dokumenttypentwickler einfach gestalten, abstrakte
Module f r andere XML-Dokumenttypen herzustellen.
· [R3.3] Das Rahmenwerk sollte es f r Dokumentautoren einfach gestalten, Elemente ver-
schiedener abstrakter Module zu validieren.
H.1.4 Kompatibilit.t
Das hier beschriebene Modularisierungsrahmenwerk sollte gut mit XML und anderen, vom
W3C entwickelten Standards zusammen arbeiten:
·· [R4.1] Das Rahmenwerk sollte streng konform zur XML 1.0 Recommendation sein.
[R4.2] Das Rahmenwerk sollte kompatibel mit der XML Linking Language (XLink) [XLINK]
sein.
· [R4.3] Das Rahmenwerk sollte kompatibel mit „Associating Style Sheets with XML docu-
ments“ [XMLSTYLE] sein.
· [R4.4] Das Rahmenwerk sollte in der Lage sein, neue W3C Recommendations anzuneh-
men, soweit das sinnvoll ist.
· [R4.5] Das Rahmenwerk sollte keinesfalls von nicht abgeschlossenen W3C-Arbeiten abh@n-
gig sein.
· [R4.6] Das Rahmenwerk sollte nicht von Arbeiten außerhalb des W3C abh@ngig sein.
H.1.5 Konformit.t
Die Effektivit@t des Rahmenwerks wird auch daran gemessen werden, wie einfach es ist, das
Verhalten von Modulen zu pr fen, die gem@ß dem Rahmenwerk entwickelt wurden, sowie die
G ltigkeit von Dokumenten, die auf die Module zur ckgreifen:
Anforderungen < 495 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
· [R5.1] Es sollte m=glich sein, Dokumente zu validieren, die aus Elementen und Attributen
aus abstrakten Modulen aufgebaut sind.
· [R5.2] Es sollte m=glich sein, das Verhalten von Elementen und Attributen aus abstrakten
Modulen explizit zu beschreiben.
· [R5.3] Es sollte m=glich sein, das Verhalten von Elementen und Attributen aus abstrakten
Modulen zu berpr fen.
· [R5.4] Es sollte m=glich sein, einen hybriden Dokumenttyp als einen XHTML-Dokumenttyp
zu berpr fen.
· [R5.5] Module, die in bereinstimmung mit den hier beschriebenen Methoden definiert
werden, sollen die Namen von Elementen und Parameter-Entities, die in XHTML-Modulen
definiert werden, nicht duplizieren.
Modularisierung von XHTML
J Danksagungen
Dieser Anhang ist informell.
Diese Spezifikation wurde von der W3C HTML Working Group erstellt. Zum Zeitpunkt der
Publikation hatte die Gruppe folgende Mitglieder: Steven Pemberton, CWI (HTML Working
Group Chair); Murray Altheim, Sun Microsystems; Daniel Austin, Mozquito Technologies;Jonny
Axelsson, Opera Software; Mark Baker, Sun Microsystems; Wayne Carr, Intel; Tantek kelik,
Microsoft;Doug Dominiak, Openwave Systems; Andrew W. Donoho, IBM; Herman Elenbaas,
Philips Electronics;Beth Epperson, Netscape/AOL;Masayasu Ishikawa, W3C (HTML Activity
Lead); Shin'ichi Matsui, Panasonic; Shane McCarron, Applied Testing and Technology; Ann
Navarro, WebGeek, Inc.; Peter Stark, Ericsson; Michel Suignard, Microsoft; Jeremy Wads-
worth, Quark Inc.; Malte Wedel, Mozquito Technologies; Ted Wugofski, Openwave Systems;
< 496 > Danksagungen
Page size: 168,00 x 240,00 mm
<edition
[Link]>
D
< XHTML Basic >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
XHTML Basic
Deutsche bersetzung
Diese Version:
[Link]
Aktuelle Version:
[Link]
bersetzer:
Stefan Schumacher <sts@[Link]>
Bei diesem Dokument handelt es sich um eine bersetzung eines W3C-Textes. Dieser
Text ist urheberrechtlich gesch tzt; bitte beachten Sie die nachfolgenden Hinweise des
Originaldokuments. Die Rechte an der bersetzung liegen bei den bersetzern und
dem Verlag Addison-Wesley. Die bersetzung hat keine durch das W3C legitimierte,
normative Wirkung. Das einzige maßgebliche Dokument ist das englische Original.
Bitte senden Sie Fehler und Korrekturen zur deutschen Fassung an die bersetzer.
Kommentare der bersetzer, die als solche gekennzeichnet sind, unterliegen dem
Urheberrecht der bersetzer. Sie sind nicht Bestandteil des Ursprungsdokuments.
XHTML Basic
XHTMLZ Basic
W3C Recommendation vom 19. Dezember 2000
Diese Version:
[Link]
Aktuelle Version:
[Link]
Vorherige Version:
[Link]
Editoren:
Mark Baker, Sun Microsystems
Masayasu Ishikawa, W3C
Shinichi Matsui, Panasonic
Peter Stark, Ericsson
Ted Wugofski, Openwave Systems
Toshihiko Yamakami, ACCESS Co., Ltd.
Copyright L 1999-2000 W3CM (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trade-
mark, document use and software licensing rules apply.
< 498 > XHTML Basic
Page size: 168,00 x 240,00 mm
Zusammenfassung
Der XHTML-Basic-Dokumenttyp schließt die Module ein, die mindestens erforderlich sind, um
ein Dokumenttyp einer XHTML Host Language zu sein. Zus@tzlich beinhaltet er Graphiken,
Formulare, grundlegende Tabellen und Objektunterst tzung. Er ist f r Web-Clients geschaffen
worden, die nicht alle XHTML-Eigenschaften unterst tzen; zum Beispiel Web-Clients wie
Mobiltelefone, PDAs, Pager oder Settop-Boxen. Dieser Dokumenttyp ist ausreichend f r
Inhaltserstellung ausgestattet.
XHTML Basic ist als allgemeine Grundlage entworfen worden, die erweitert werden kann.
Zum Beispiel kann ein Event-Modul, das umfassender ist als das traditionelle HTML-4-Event-
System, eingef gt werden, oder es kann um zus@tzliche Module der XHTML-Modularisierung,
wie das Scripting-Modul, erweitert werden. Das Ziel von XHTML Basic ist es, eine allgemeine
Sprache vorzulegen, die von verschiedensten Benutzerschnittstellen unterst tzt wird.
Die Dokumenttyp-Definition ist auf Grundlage der XHTML-Module implementiert, wie in „Mo-
dularisierung von XHTML“ [XHTMLMOD] beschrieben.
Status dieses Dokuments
Dieser Abschnitt beschreibt den Status dieses Dokuments zur Zeit seiner Publikation. Andere
Dokumente k=nnen dieses Dokument ersetzen. Der letzte Status dieser Dokumentenreihe
wird vom W3C gepflegt.
Dieses Dokument wurde von Mitgliedern des W3C und anderen interessierten Gruppen ber-
XHTML Basic
pr ft und vom Direktor als W3C Recommendation anerkannt. Es ist ein stabiles Dokument
und darf als Referenzmaterial verwendet werden oder als normative Referenz von anderen
Dokumenten zitiert werden. Die Rolle des W3C bei der Erstellung dieser Recommendation ist
es, die Spezifikation bekannt zu machen und ihre weite Verbreitung zu f=rdern. Dies erh=ht die
Funktionalit@t und die Interoperabilit@t des Webs.
Dieses Dokument wurde von den Mitgliedern der W3C HTML Working Group (nur fr Mitglie-
der) als Teil der W3C HTML Activity" erstellt. Es ber cksichtigt das Feedback des WAP-Fo-
rums und der Mitglieder der W3C Mobile Access Interest Group (nur fr Mitglieder). Dieses
Dokument wird von der W3C HTML Working Group und der W3C Mobile Access Interest
Group verwendet, um gemeinsame Grundlagen f r zuk nftige Auszeichnungssprachen zu fin-
den, die auf den Inhalt kleiner Informationsapplikationen ausgerichtet sind.
"Modularisierung von XHTML" [XHTMLMOD] definiert die XHTML-Module im XHTML-Ba-
sic-Dokumenttyp. Zur Zeit dieser Publikation wurde die berpr fungsperiode f r die Candi-
date Recommendation "Modularisierung von XHTML" beendet. Von dieser berpr fung aus-
gehend, glaubt die "W3C HTML Working Group", dass die Definition der Module in XHTML
Basic stabil ist, und die Working Group erwartet nicht, dass Onderungen an der "Modularisie-
rung von XHTML" vorgenommen werden, die inkompatibel zu XHTML Basic sein werden.
Die =ffentliche Diskussion um HTML findet auf der Mailing-Liste www-html@[Link] statt (Ar-
chiv). Um der Mailing-Liste beizutreten, schreiben Sie eine Mail an www-html-request@[Link]
mit dem Wort subscribe in der Betreffzeile.
Bitte senden Sie Mitteilungen ber Fehler in diesem Dokument an www-html-editor@[Link].
Die Liste bekannter Fehler in diesem Dokument ist unter [Link]
xhtml-basic-20001219-errata verf gbar.
0ieses Dokuments < 499 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Die englische Version dieser Spezifikation ist die einzige normative Version. Informationen zu
bersetzungen dieses Dokuments sind unter [Link] verf gbar.
Eine Liste der aktuellen W3C Recommendations und anderen technischen Dokumenten ist
unter [Link] verf gbar.
1 Einleitung
1.1 XHTML f-r [Link]
HTML 4 ist eine m@chtige Sprache f r das Verfassen von Webinhalten, aber das Design passt
nicht zu den Anforderungen kleiner Benutzerschnittstellen, etwa der Implementierungsaufwand
(Prozessortakt, Speicher und so weiter) bei Verwendung aller Eigenschaften. Benutzerschnitt-
stellen mit begrenzten Ressourcen k=nnen eine volle Implementierung der HTML-4-Eigenschaf-
ten im Allgemeinen nicht unterst tzen. Da nur mit einem voll ausger steten Computer der
Zugang zum World Wide Web m=glich ist, ist eine große Personengruppe vom Zugang zu
Online-Informationen und Online-Diensten ausgeschlossen.
Da es viele M=glichkeiten gibt, HTML einzuschr@nken, existieren viele fast identische Teilmen-
gen, die von Organisationen und Gesellschaften definiert wurden. Ohne eine gemeinsame
Grundlage wird es schwierig, Applikationen f r eine große Zahl verschiedener Web-Clients zu
entwickeln.
XHTML Basic
Die Motivation f r XHTML Basic besteht darin, einen XHTML-Dokumenttyp bereitzustellen,
der von Gemeinschaften gemeinsam verwendet werden kann, (zum Beispiel von Desktops, TV
und Mobiltelefonen) und der reich genug ist f r einfache Inhaltserstellung. Neue gemeinschafts-
weite Dokumenttypen k=nnen durch die Erweiterung von XHTML Basic in der Weise definiert
werden, dass XHTML-Basic-Dokumente innerhalb des g ltigen Bereichs des neuen Dokument-
typs liegen. So kann ein XHTML-Basic-Dokument von m=glichst vielen Web-Clients angezeigt
werden.
Die Dokumenttyp-Definition f r XHTML Basic ist auf Grundlage der XHTML-Module, wie in
„Modularisierung von XHTML“ [XHTMLMOD] beschrieben, implementiert.
1.2 Hintergrund und Voraussetzungen
Informationsger@te sind auf einen bestimmten Gebrauch hin ausgelegt. Sie unterst tzen die
Eigenschaften, die sie f r die Funktionen ben=tigen, die sie ausf hren sollen. Im Folgenden
einige Beispiele f r verschiedenartige Informationsger@te:
·· Mobiltelefone
Fernsehger@te
·· Taschencomputer (PDAs)
Verkaufsautomaten
·· Pager
KFZ-Navigationssysteme
··Mobile Spielger@te
Digitale Buchleseger@te
·Multifunktionale Uhren
< 500 > Einleitung
Page size: 168,00 x 240,00 mm
Existierende Teilmengen und Varianten von HTML f r diese Clients schließen „Compact
HTML“ [CHTML], die „Wireless Markup Language“ [WML] und die „HTML 4.0 Guidelines for
Mobile Access“ [GUIDELINES] ein. Die gemeinsamen Eigenschaften in diesen Dokumenttypen
beinhalten:
·· Grundlegenden Text (einschließlich berschriften, Abs@tze und Listen)
Hyperlinks und Verweise zu verwandten Dokumenten
·· Grundlegende Formulare
Grundlegende Tabellen
·· Graphiken
Meta-Informationen
Diese HTML-Eigenschaften waren der Ausgangspunkt f r das Design von XHTML Basic. Weil
sich viele Autoren mit den Eigenschaften von HTML auskennen, bildet sie eine n tzliche Aus-
gangssprache, die mit Modulen anderer Sprachen kombiniert werden kann, entsprechend den
Methoden, die in "Modularisierung von XHTML" [XHTMLMOD] beschrieben sind. Zum Bei-
spiel kann XHTML Basic mit einem Event-Modul erweitert werden, das umfassender als ein
traditionelles HTML 4 Event-System ist, oder es kann durch zus@tzliche Module der XHTML-
Modularisierung wie dem Scripting-Modul erweitert werden.
Die Intention von XHTML Basic ist es nicht, zuk nftige Sprachen zu limitieren. Weil aber die
Charakteristiken von HTML 4 (Rahmen, komplexe Tabellen, bestimmte Attribut-Event-Hand-
ler usw.) f r Clients wie Desktop-Computer entwickelt wurden, hat sich gezeigt, dass sie nicht
f r kleinere Ger@te geeignet sind. XHTML Basic wird erweitert und ausgebaut werden.
XHTML von gemeinsamen und grundlegenden Eigenschaften aus zu erweitern, anstatt von fast
XHTML Basic
identischen Teilmengen oder zu umfangreichen Funktionen in HTML 4, wird sowohl f r die
Interoperabilit@t im Web als auch f r die Skalierbarkeit von Vorteil sein.
Verglichen mit der reichhaltigen Funktionalit@t von HTML 4, sieht XHTML Basic vielleicht wie
ein R ckschritt aus, aber in der Tat sind es zwei Schritte nach vorn: Auf der einen Seite f r
Clients, die viele Eigenheiten von HTML 4 nicht ben=tigen, und auf der anderen Seite f r Ent-
wickler, die nur eine XHTML-Teilmenge anstatt viele bekommen.
1.3 Gr-nde f-r Entwurfsentscheidungen
Dieser Abschnitt erkl@rt, warum bestimmte HTML-Eigenschaften nicht Teil von XHTML Basic sind.
1.3.1 Stylesheets
Das style-Element wird nicht unterst tzt. Externe Stylesheets sind erforderlich. Das link-
Element kann zum Aufruf von externen Stylesheets verwendet werden. Die Elemente div, span
und class werden unterst tzt, um Style-Informationen mit der Struktur zu verbinden. Die
Trennung zwischen Struktur und Darstellung erlaubt Benutzerschnittstellen, Stylesheets herun-
terzuladen, falls sie Stylesheets unterst tzen. Benutzerschnittstellen, die keine Stylesheets
unterst tzen, k=nnen das externe Stylesheet ignorieren. Das media-Attribut kann zur Auswahl
des geeigneten Stylesheets verwendet werden. F r weitere Details konsultieren Sie den
Abschnitt ber „Medientypen“ in der „HTML 4.01-Spezifikation“ ([HTML4], Abschnitt 14.2.4).
Gr#nde f#r Entwurfsentscheidungen < 501 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
1.3.2 Skripte und Ereignisse
Die Elemente script und noscript werden nicht unterst tzt. Normalerweise haben kleine End-
ger@te begrenzten Speicher und begrenzte Rechenleistung. Die Ausf hrung von Skriptprogram-
men wird eventuell nicht unterst tzt. Der Inhalt sollte auch lesbar sein, wenn Skripte nicht aus-
gef hrt werden.
Event-Handler-Attribute zur Einbindung von Script-Programmen werden nicht unterst tzt.
Events sind ger@teabh@ngig. Ein „Eingehender Anruf“-Event ist nicht f r die Ausf hrung in einem
Fernsehger@t bestimmt. Ein bergreifender Event-Handling-Mechanismus wird angemessener
sein, als die Event-Namen in der Dokumenttyp-Definition festzuschreiben.
1.3.3 Darstellung
Viele einfache Web-Clients k=nnen nur Nicht-Proportionalschrift (Monospace) anzeigen. Bidi-
rektionaler Text, fettgedruckte Schrift und andere erweiterte Schriftelemente werden nicht
unterst tzt.
Es wird empfohlen, dass Stylesheets f r eine Darstellung benutzt werden, die f r das Endger@t
angemessen ist.
1.3.4 Formulare
Grundlegende XHTML-Formulare ([XHTMLMOD], Abschnitt 5.5.1) werden unterst tzt. Weil
nur Ger@te mit einem lokalen Dateisystem Vorteile aus Datei- oder Graphikeingabetypen in
XHTML Basic
Formularen ziehen k=nnen, sind sie nicht Teil der Grundformulare. Ebenso sollten Autoren
daran denken, dass die Benutzer vielleicht nicht in der Lage sind, viele Zeichen in einige Ger@te
einzugeben (z. B. in Mobiltelefonen).
1.3.5 Tabellen
Grundlegende XHTML-Tabellen ([XHTMLMOD], Abschnitt 5.6.1) werden unterst tzt, aber
Tabellen k=nnen auf kleinen Ger@ten schwer darstellbar sein. Es ist erforderlich, dass Autoren
den „Web Content Accessibility Guidelines 1.0“ zur Erzeugung zug@nglicher Tabellen
([WCAG10], Guideline 5) folgen. Beachten Sie, dass in grundlegenden Tabellenmodulen das
Verschachteln von Tabellen verboten ist.
1.3.6 Frames
Frames werden nicht unterst tzt. Frames h@ngen von der Bildschirmschnittstelle ab und sind
eventuell auf einigen kleine Endger@te wie Telefonen, Pagern und Uhren nicht anwendbar.
< 502 > Einleitung
Page size: 168,00 x 240,00 mm
2 Konformit.t
Dieser Abschnitt ist normativ.
2.1 Konformit.t der Dokumente
Ein Dokument, das konform zu XHTML Basic ist, muss nur die Eigenschaften, die in dieser Spe-
zifikation als zwingend erforderlich beschrieben werden, besitzen. Solch ein Dokument muss
jedem einzelnen der folgenden Kriterien entsprechen:
1. Das Dokument muss den Anforderungen im Anhang B entsprechen.
2. Das Wurzelelement des Dokuments muss <html> sein.
3. Der Name des voreingestellten Namensraums des Wurzelelements muss der XHTML-
Namensraumname sein, [Link]
4. Es muss eine DOCTYPE-Deklaration im Dokument vor dem Wurzelelement existieren.
Wenn vorhanden, muss der Public Identifier in der DOCTYPE-Deklaration auf die DTD
verweisen, die im Anhang B zu finden ist, unter Verwendung seines Formal Public Identi-
fiers. Der System Identifier darf geeignet angepasst werden.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"[Link]
5. Die interne DTD-Teilmenge darf keine Parameter-Entities der DTD berschreiben.
XHTML Basic
2.2 Konformit.t der Benutzerschnittstelle
Die Benutzerschnittstelle muss dem Abschnitt „Konforme Benutzerprogramme“ der "XHTML
1.0 Spezifikation" ([XHTML1], Abschnitt 3.2) folgen.
3 Der XHTML-Basic-Dokumenttyp
Dieser Abschnitt ist normativ.
Der XHTML-Basic-Dokumenttyp ist definiert als eine Zusammenstellung von XHTML-Modu-
len. Alle XHTML-Module sind in der Spezifikation „Modularisierung von XHTML“
[XHTMLMOD] definiert.
XHTML Basic besteht aus den folgenden XHTML-Modulen:
Strukturmodule*
body, head, html, title
Textmodule*
abbr, acronym, address, blockquote, br, cite, code, dfn, div, em, h1, h2, h3, h4, h5, h6, kbd,
p, pre, q, samp, span, strong, var
Hypertext Module*
a
Konformit,t < 503 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Listenmodule*
dl, dt, dd, ol, ul, li
Grundlegende Formularmodule
form, input, label, select, option, textarea
Grundlegende Tabellenmodule
caption, table, td, th, tr
Graphikmodule
img
Objektmodule
object, param
Metainformationsmodule
meta
Verweismodule
link
Base-Module
base
(*) = Dieses Modul ist ein erforderliches „XHTML Host Language“-Modul.
Eine XML 1.0 DTD ist im Anhang B verf gbar.
Anmerkung: Weil die „HTML Event Handler“-Attribute nicht Teil von XHTML Basic sind, funk-
tionieren Formularkontrollelemente außerhalb von Formularen eventuell nicht, wie vom Benutzer
erwartet. n
XHTML Basic
4 Wie XHTML Basic verwendet wird
Obwohl die Sprache XHTML Basic so verwendet werden kann, wie sie ist – als eine einfache
XHTML-Sprache mit Text, Verweisen und Graphiken – ist die Intention der einfachen Gestal-
tung die Verwendung als Host Language. Eine Host Language kann verschiedenartige Vokabeln,
alle zusammengew rfelt in einem Dokument, enthalten. Es ist nat rlich, das XHTML die Host
Language ist, weil die meisten Web-Entwickler an sie gew=hnt sind.
Wenn Auszeichnungen aus anderen Sprachen zu XHTML Basic hinzugef gt werden, wird der
resultierende Dokumenttyp eine Erweiterung von XHTML Basic sein. Autoren k=nnen f r
XHTML Basic entwickeln, oder sie nutzen den Vorteil der Erweiterungen. Das Ziel von
XHTML Basic ist es, eine allgemeine Sprache vorzulegen, die von verschiedensten Benutzer-
schnittstellen unterst tzt wird.
< 504 > Wie XHTML Basic verwendet wird
Page size: 168,00 x 240,00 mm
5 Danksagung
Diese Spezifikation wurde von der W3C HTML Working Group erarbeitet. Die Mitglieder
waren:
Steven Pemberton, CWI (HTML Working Group Chair); Robert Adams, Intel (bis November
2000); Murray Altheim, Sun Microsystems; Takuya Asada, W3C (bis Oktober 2000); Daniel
Austin, Mozquito Technologies; Mark Baker, Sun Microsystems; Wayne Carr, Intel; Tantek
kelik, Microsoft; Andrew W. Donoho, IBM; Herman Elenbaas, Philips Electronics; Beth Epper-
son, Netscape/AOL; Masayasu Ishikawa, W3C (HTML Activity Lead); Shin'ichi Matsui, Panaso-
nic; Shane McCarron, Applied Testing and Technology; Ann Navarro, WebGeek, Inc.; Dave
Raggett, W3C/Openwave Systems; Sebastian Schnitzenbaumer, Mozquito Technologies (bis
September 2000); Peter Stark, Ericsson; Michel Suignard, Microsoft; Markku Vartiainen, Open-
wave Systems; Jeremy Wadsworth, Quark Inc.; Malte Wedel, Mozquito Technologies; Linda
Welsh, Intel; Ted Wugofski, Openwave Systems
Dank an Gary Adams (Sun Microsystems), Jonny Axelsson (Metastasis design), Peter Chen (Phi-
lips), Dan Connolly (W3C), John Cowan (Reuters), Martin J. D rst (W3C), Johan Hjelm
(Ericsson), Ian Jacobs (W3C), Susan Lesch (W3C), Louis Theran (Nokia), Quinton Zondervan
(Lotus), Mitglied der „W3C Mobile Access Interest Group“, der „W3C Synchronized Multi-
media Working Group“, der „W3C WAI Protocols and Formats Working Group“ und dem
WAP-Forum, f r die Beitr@ge, die berpr fung und die Kommentare zu diesem Dokument.
XHTML Basic
A Referenzen
A.1 Normative Referenzen
[HTML4]
"HTML 4.01 Spezifikation", W3C Recommendation, D. Raggett, A. Le Hors, I. Jacobs, Edito-
ren, 24. Dezember 1999. Verf gbar unter: [Link]
html401-19991224
Die aktuelle Version ist verf gbar unter: [Link]
[XHTML1]
"XHTML 1.0: The Extensible HyperText Markup Language - A Reformulation of HTML 4 in
XML 1.0", W3C Recommendation, Steven Pemberton et al., 26. Januar 2000. Verf gbar
unter: [Link]
Die aktuelle Version ist verf gbar unter: [Link]
[XHTMLMOD]
"Modularisierung von XHTML", W3C Candidate Recommendation, R. Adams, M. Altheim,
F. Boumphrey, S. Dooley, S. McCarron, S. Schnitzenbaumer, T. Wugofski, Editoren,
20. Oktober 2000. Verf gbar unter: [Link]
modularization-20001020
Die aktuelle Version ist verf gbar unter:
[Link] modularization
Danksagung < 505 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
[XML]
"Extensible Markup Language (XML) 1.0 (Zweite Ausgabe)", W3C Recommendation,
T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, Editoren, 6. Oktober 2000. Verf gbar
unter: [Link]
Die aktuelle Version ist verf gbar unter: [Link]
A.2 Informelle Referenzen
[CHTML]
"Compact HTML f r Kleinstinformationsger@te", W3C Note, T. Kamada, 9. Februar 1998.
Verf gbar unter: [Link]
[GUIDELINES]
"HTML 4.0 Guidelines for Mobile Access, W3C Note, T. Kamada, T. Asada, M. Ishikawa,
S. Matsui, Editoren, 15. M@rz 1999. Verf gbar unter: [Link]
html40-mobile-19990315
Die aktuelle Version ist verf gbar unter: [Link]
[WCAG10]
"Web Content Accessibility Guidelines 1.0", W3C Recommendation, W. Chisholm, G.
Vanderheiden, I. Jacobs, Editoren, 5. Mai 1999. Verf gbar unter: [Link]
TR/1999/WAI-WEBCONTENT-19990505
Die aktuelle Version ist verf gbar unter: [Link]
[WML]
XHTML Basic
"Wireless Markup Language Specification", WAP-Forum Ltd. Verf gbar unter:
[Link]
B XHTML-Basic-
Dokumenttyp-Definition
Dieser Anhang ist normativ.
B.1 "SGML Open Catalog Entry" f-r XHTML Basic
Dieser Abschnitt enth@lt die "SGML Open Catalog-format Definition" der "XHTML Basic FPI".
- - .......................................................................... - -
- - File catalog ............................................................ - -
- - XHTML Basic Catalog Data File
Revision: $Id: [Link],v 2.4 2000/12/18 21:42:58 mimasa Exp $ SMI
See "Entity Management", SGML Open Technical Resolution 9401 for detailed
information on supplying and using catalog data. This document is available
from OASIS at URL:
< 506 > XHTML-Basic- Dokumenttyp-Definition
Page size: 168,00 x 240,00 mm
<[Link]
--
- - .......................................................................... - -
- - SGML declaration associated with XML .................................... - -
OVERRIDE YES
SGMLDECL "[Link]"
- - :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: - -
- - XHTML Basic DTD modular driver file ..................................... - -
PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "[Link]"
- - XHTML Basic framework module ............................................. - -
PUBLIC "-//W3C//ENTITIES XHTML Basic 1.0 Document Model 1.0//EN"
"[Link]"
- - End of catalog data ..................................................... - -
- - .......................................................................... - -
B.2 XHTML Basic-Treiber
XHTML Basic
Dieser Abschnitt enth@lt den Treiber f r die XHTML-Basic-Dokumenttyp-Implementation in
Form einer XML-DTD. Sie unterliegt den XHTML-Modul-Implementationen, definiert in
[XHTMLMOD].
<!- - XHTML Basic 1.0 DTD ......................................................
- ->
<!- - file: [Link] - ->
<!- - XHTML Basic 1.0 DTD
This is XHTML Basic, a proper subset of XHTML.
The Extensible HyperText Markup Language (XHTML)
Copyright 1998-2000 World Wide Web Consortium
(Massachusetts Institute of Technology, Institut National de
Recherche en Informatique et en Automatique, Keio University).
All Rights Reserved.
Permission to use, copy, modify and distribute the XHTML Basic DTD
and its accompanying documentation for any purpose and without fee is
hereby granted in perpetuity, provided that the above copyright notice
and this paragraph appear in all copies. The copyright holders make
no representation about the suitability of the DTD for any purpose.
It is provided "as is" without expressed or implied warranty.
XHTML Basic-Treiber < 507 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Editors: Murray M. Altheim <[Link]
Peter Stark <[Link]
Revision: $Id: [Link],v 2.13 2000/12/18 12:56:23 mimasa Exp $
SMI
- ->
<!- - This is the driver file for version 1.0 of the XHTML Basic DTD.
This DTD is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC: "-//W3C//DTD XHTML Basic 1.0//EN"
SYSTEM: "[Link]
- ->
<!ENTITY % [Link] "-//W3C//DTD XHTML Basic 1.0//EN" >
<!- - Use this URI to identify the default namespace:
"[Link]
See the Qualified Names module for information
on the use of namespace prefixes in the DTD.
- ->
<!ENTITY % [Link] "IGNORE" >
<!ENTITY % [Link] "" >
<!- - Reserved for use with the XLink namespace:
- ->
XHTML Basic
<!ENTITY % [Link] "" >
<!ENTITY % [Link] "" >
<!- - For example, if you are using XHTML Basic 1.0 directly, use
the FPI in the DOCTYPE declaration, with the xmlns attribute
on the document element to identify the default namespace:
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"[Link] >
<html xmlns="[Link]
xml:lang="en" >
...
</html>
- ->
<!- - reserved for future use with document profiles - ->
<!ENTITY % [Link] "" >
<!- - Bidirectional Text features
This feature-test entity is used to declare elements
and attributes used for bidirectional text support.
- ->
<!ENTITY % [Link] "IGNORE" >
<?doc type="doctype" role="title" { XHTML Basic 1.0 } ?>
<!- - :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: - ->
< 508 > XHTML-Basic- Dokumenttyp-Definition
Page size: 168,00 x 240,00 mm
<!ENTITY % [Link] "IGNORE" >
<!ENTITY % [Link] "%[Link];" >
<!ENTITY % [Link]
PUBLIC "-//W3C//ENTITIES XHTML Basic 1.0 Document Model 1.0//EN"
"[Link]" >
<!ENTITY % [Link]
PUBLIC "-//W3C//ENTITIES XHTML Modular Framework 1.0//EN"
"[Link]" >
%[Link];
<!ENTITY % [Link]
"( #PCDATA
| %[Link];
%[Link];
%[Link];
%[Link]; )*"
>
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Text 1.0//EN"
"[Link]" >
%[Link];
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Hypertext 1.0//EN"
"[Link]" >
XHTML Basic
%[Link];
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Lists 1.0//EN"
"[Link]" >
%[Link];
<!- - ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: - ->
<!- - Image Module ............................................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Images 1.0//EN"
"[Link]" >
%[Link];]]>
<!- - Tables Module ............................................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Basic Tables 1.0//EN"
"[Link]" >
%[Link];]]>
<!- - Forms Module ............................................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
XHTML Basic-Treiber < 509 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
PUBLIC "-//W3C//ELEMENTS XHTML Basic Forms 1.0//EN"
"[Link]" >
%[Link];]]>
<!- - Link Element Module ........................................ - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Link Element 1.0//EN"
"[Link]" >
%[Link];]]>
<!- - Document Metainformation Module ............................ - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Metainformation 1.0//EN"
"[Link]" >
%[Link];]]>
<!- - Base Element Module ........................................ - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Base Element 1.0//EN"
"[Link]" >
%[Link];]]>
XHTML Basic
<!- - Param Element Module ....................................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Param Element 1.0//EN"
"[Link]" >
%[Link];]]>
<!- - Embedded Object Module ..................................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Embedded Object 1.0//EN"
"[Link]" >
%[Link];]]>
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Document Structure 1.0//EN"
"[Link]" >
%[Link];
<!- - end of XHTML Basic 1.0 DTD ........................................... - ->
< 510 > XHTML-Basic- Dokumenttyp-Definition
Page size: 168,00 x 240,00 mm
B.3 XHTML-Basic-Anpassungen
Ein Dokumenttyp der XHTML-Familie (so wie XHTML Basic) muss das Inhaltsmodell definie-
ren, das er benutzt. Das wird durch ein seperates "Content Model"-Modul verwirklicht, das
durch das "XHTML Modular Framework" instantisiert wird. Das "Content Model"-Modul und
der XHTML-Basic-Treiber arbeiten zusammen, um die Modulimplementationen an die spezi-
fischen Erfordernisse des Dokumenttyps anzupassen. Das "Content Model"-Modul f r XHTML
Basic ist wie folgt definiert:
<!- - ....................................................................... - ->
<!- - XHTML Basic 1.0 Document Model Module ....................................
- ->
<!- - file: [Link]
This is XHTML Basic, a proper subset of XHTML.
Copyright 1998-2000 W3C (MIT, INRIA, Keio), All Rights Reserved.
Revision: $Id: [Link],v 2.8 2000/11/03 14:28:25 mimasa Exp $
SMI
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//ENTITIES XHTML Basic 1.0 Document Model 1.0//EN"
SYSTEM "[Link]
Revisions:
XHTML Basic
(none)
....................................................................... - ->
<!- - XHTML Basic Document Model
This module describes the groupings of elements that make up
common content models for XHTML elements.
- ->
<!- - Optional Elements in head .............. - ->
<!ENTITY % [Link]
"( %[Link]; | %[Link]; | %[Link]; )*" >
<!- - Miscellaneous Elements ................. - ->
<!ENTITY % [Link] "" >
<!- - Inline Elements ........................ - ->
<!ENTITY % [Link] "%[Link]; | %[Link];" >
<!ENTITY % [Link]
"| %[Link]; | %[Link]; | %[Link]; | %[Link];
| %[Link]; | %[Link]; | %[Link]; | %[Link];
| %[Link]; | %[Link]; | %[Link];" >
<!ENTITY % [Link] "" >
<!ENTITY % [Link] "" >
XHTML-Basic-Anpassungen < 511 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!ENTITY % [Link] "| %[Link];" >
<!ENTITY % [Link] "| %[Link]; | %[Link];" >
<!ENTITY % [Link]
"| %[Link]; | %[Link]; | %[Link];
| %[Link];"
>
<!ENTITY % [Link] "" >
<!ENTITY % [Link]
"%[Link];
%[Link];
%[Link];
%[Link];
%[Link];
%[Link];"
>
<!ENTITY % [Link]
"%[Link];
%[Link];
%[Link];
%[Link];
%[Link];"
>
XHTML Basic
<!ENTITY % [Link]
"%[Link];
%[Link];"
>
<!ENTITY % [Link]
"%[Link];
%[Link];"
>
<!- - Block Elements ......................... - ->
<!ENTITY % [Link]
"%[Link]; | %[Link]; | %[Link];
| %[Link]; | %[Link]; | %[Link];"
>
<!ENTITY % [Link] "%[Link]; | %[Link]; | %[Link];" >
<!ENTITY % [Link] "| %[Link];" >
<!ENTITY % [Link] "| %[Link];" >
<!ENTITY % [Link] "%[Link]; | %[Link];" >
<!ENTITY % [Link]
"| %[Link]; | %[Link]; | %[Link];"
>
< 512 > XHTML-Basic- Dokumenttyp-Definition
Page size: 168,00 x 240,00 mm
<!ENTITY % [Link] "" >
<!ENTITY % [Link]
"%[Link];
%[Link];"
>
<!ENTITY % [Link] "" >
<!ENTITY % [Link]
"%[Link];
%[Link];
%[Link];
%[Link];"
>
<!ENTITY % [Link]
"%[Link];
| %[Link];
| %[Link];
%[Link];"
>
<!- - All Content Elements ................... - ->
<!- - declares all content except tables
- ->
XHTML Basic
<!ENTITY % [Link]
"%[Link];
| %[Link];
| %[Link];
%[Link];
%[Link];
%[Link];
| %[Link];
%[Link];"
>
<!ENTITY % [Link]
"%[Link];
| %[Link];
| %[Link];
| %[Link];
%[Link];"
>
<!- - end of [Link] - ->
XHTML-Basic-Anpassungen < 513 >
Page size: 168,00 x 240,00 mm
Page size: 168,00 x 240,00 mm
<edition
[Link]>
E
< XHTML 1.1 -
Modulbasiertes
XHTML >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
XHTML 1.1 - Modulbasiertes XHTML
Deutsche bersetzung
7. Januar 2003
Diese Version:
[Link]
Aktuelle Version:
[Link]
bersetzer:
Stefan Mintert, [Link] <stefan@[Link]>
Bei diesem Dokument handelt es sich um eine bersetzung eines W3C-Textes. Dieser
Text ist urheberrechtlich gesch tzt; bitte beachten Sie die nachfolgenden Hinweise des
Originaldokuments. Die Rechte an der bersetzung liegen bei den bersetzern und
dem Verlag Addison-Wesley. Die bersetzung hat keine durch das W3C legitimierte,
normative Wirkung. Das einzige maßgebliche Dokument ist das englische Original.
Bitte senden Sie Fehler und Korrekturen zur deutschen Fassung an die bersetzer.
Kommentare der bersetzer, die als solche gekennzeichnet sind, unterliegen dem
Urheberrecht der bersetzer. Sie sind nicht Bestandteil des Ursprungsdokuments.
XHTML 1.1 - Modulbasiertes XHTML
XHTML 1.1 – Modulbasiertes XHTML
W3C Recommendation 31. Mai 2001
Diese Version:
[Link]
(Einzelne Datei, PostScript-Version, PDF-Version, ZIP-Archiv, Gzip/TAR-Archiv)
Aktuellste Version:
[Link]
Vorherige Version:
[Link]
Herausgeber:
Murray Altheim, Sun Microsystems
Shane McCarron, Applied Testing and Technology
Copyright L 2001 W3CM (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark,
document use and software licensing rules apply.
< 516 > XHTML 1.1 - Modulbasiertes XHTML
Page size: 168,00 x 240,00 mm
Zusammenfassung
Diese Empfehlung definiert einen neuen XHTML-Dokumenttyp, der auf dem Modulrahmen-
werk und den Modulen basiert, die in „Modularisierung von XHTML“ [XHTMLMOD] definiert
sind. Der Zweck dieses Dokumenttyps besteht darin, als Basis f r zuk nftige, erweiterte Doku-
menttypen der XHTML-Familie zu dienen. Zudem soll er einen konsistenten, nach vorne
gerichteten Dokumenttyp darstellen, der sauber von den missbilligten Altlasten aus HTML 4
[HTML4] getrennt ist, die in die Dokumenttypen von XHTML 1.0 [XHTML1] bernommen
wurden. Der hier definierte Dokumenttyp ist im Wesentlichen eine Neuformulierung von
XHTML 1.0 Strict unter Verwendung von XHTML-Modulen. Das bedeutet, dass viele F@higkei-
ten, die in anderen Dokumenttypen der XHTML-Familie verf gbar sind (zum Beispiel XHTML-
Frames), hier fehlen. Diese anderen F@higkeiten sind als Module verf gbar, die in der Modulari-
sierung von XHTML definiert sind. Es steht Dokumentautoren frei, Dokumenttypen auf Basis
von XHTML 1.1 zu bilden, die diese F@higkeiten besitzen (siehe [XHTMLMOD], um zu erfah-
ren, wie man neue Dokumenttypen erstellt).
Status dieses Dokuments
Dieser Abschnitt beschreibt den Status dieses Dokuments zum Zeitpunkt seiner Ver=ffent-
lichung. Andere Dokumente k=nnen dieses Dokument ersetzen. Der aktuelle Status dieser
Dokumentreihe wird vom W3C betreut.
Dieses Dokument wurde von W3C-Mitglieder und anderen Interessierten begutachtet, und es
XHTML 1.1 - Modulbasiertes XHTML
wurde vom Direktor als W3C Recommendation gebilligt. Es handelt sich um ein stabiles Doku-
ment und kann als Referenzmaterial verwendet oder als normative Referenz in anderen Doku-
menten zitiert werden. Bei der Herstellung der Recommendation ist es die Rolle des W3C, die
Aufmerksamkeit auf diese Spezifikation zu lenken und ihre Verbreitung zu f=rdern. Das verbes-
sert die Funktionsweise und Interoperabilit@t des Web.
Dieses Dokument wurde von der W3C HTML Working Group ([Link]/MarkUp/
Group/; nur fr Mitglieder: [Link]/MemberAccess/AccessRequest) als Teil der W3C HTML Acti-
vity produziert. Die Ziele der HTML Working Group werden in der HTML Working Group
charter ([Link]/MarkUp/2000/Charter) diskutiert. Der W3C-Kontakt f r HTML ist
Masayasu Ishikawa (mimasa@[Link]).
Die =ffentliche Diskussion von HTML findet auf www-html@[Link] statt (Archiv: [Link]/
Archives/Public/www-html/). Zur Anmeldung schicken Sie bitte eine Mail mit dem Wort sub-
scribe im Subject an www-html-request@[Link].
Bitte berichten Sie Fehler in diesem Dokument an www-html-editor@[Link] (Archiv:
[Link]/Archives/Public/www-html-editor/). Die Liste der bekannten Fehler in dieser Spezi-
fikation steht unter [Link] zur Verf gung.
Die englische Version dieser Spezifikation ist die einzige normative Version. Informationen ber
bersetzungen von diesem Text sind unter [Link] zu finden.
Eine Liste aktueller W3C Recommendations und anderer technischer Dokumente befindet sich
unter [Link]
Zusammenfassung < 517 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
1 Einf-hrung
Dieser Abschnitt ist normativ.
Mit der Einf hrung der XHTML-Familie aus Modulen und Dokumenttypen, hat das W3C der
Gemeinschaft der Inhalteschaffenden geholfen, aus den Tagen der verst mmelten, nicht stan-
dardkonformen Auszeichnungen in die wohlgeformte, g ltige Welt von XML [XML] voran-
zuschreiten. In XHTML 1.0 war dieser Schritt dadurch beschr@nkt, dass es eine einfache Migra-
tion von bestehenden, auf HTML 4 (oder fr heren Versionen) basierenden Inhalten hin zu
XHTML und XML geben sollte. Mit dem Auftauchen der in Modularisierung von XHTML defi-
nierten XHTML-Module hat das W3C die missbilligten Elemente und Attribute aus der
XHTML-Familie entfernt. Diese Elemente und Attribute dienten vor allem der Darstellung, die
besser durch Stylesheet oder client-spezifisches Verhalten geregelt wird.
In der Zukunft werden Dokumenttypen der XHTML-Familie auf dieser neuen, auf strukturelle
Funktionen ausgelegten Sammlung basieren. In dieser Spezifikation hat die HTML-Arbeits-
gruppe des W3C einen ersten Dokumenttyp definiert, der auf Modulen allein aufsetzt. Er ist
entworfen, um auf ein breites Spektrum von Ger@ten bertragbar zu sein und um auf den
Großteil des Internetinhalts anwendbar zu sein. Autoren, die ihren Inhalt auf den in dieser Spe-
zifikation formulierten Funktionsumfang st tzen, k=nnen sicher sein, dass er auf alle zur
XHTML-Familie konformen Benutzerprogramme bertragbar ist.
XHTML 1.1 - Modulbasiertes XHTML
2 Definition der Konformit.t
Dieser Abschnitt ist normativ.
Die Worte „muss“, „darf nicht“, „erforderlich“ (required), „soll“, „soll nicht“, „sollte“, „emp-
fohlen“, „darf“ und „optional“ in diesem Dokument sind so zu interpretieren, wie es in
[RFC2119] beschrieben ist.
2.1 Dokumentkonformit.t
Diese Version von XHTML gibt die Definition f r streng konforme XHTML-Dokumente. Doku-
mente sind auf Elemente und Attribute aus dem XHTML-Namensraum beschr@nkt.
2.1.1 Streng konforme Dokumente
Ein streng konformes XHTML 1.1-Dokument ist ein Dokument, f r das nur solche Eigenschaf-
ten erforderlich sind, die in dieser Spezifikation als zwingend beschrieben sind. Ein solches
Dokument muss allen folgenden Kriterien gen gen:
1. Das Dokument muss konform zu den in Anhang C formulierten Beschr@nkungen sein.
2. Das Wurzelelement des Dokuments muss <html> lauten.
3. Das Wurzelelement des Dokuments muss den XHTML-Namensraum im xmlns-Attribut
angeben [XMLNAMES]. Der Namensraumbezeichner f r XHTML lautet [Link]
1999/xhtml.
< 518 > Einf#hrung
Page size: 168,00 x 240,00 mm
4. Es muss im Dokument vor dem Wurzelelement eine DOCTYPE-Deklaration geben. Falls
vorhanden, muss der Public Identifier in der DOCTYPE-Deklaration die in Anhang C ent-
haltene DTD ber deren Formal Public Identifier referenzieren. Der System Identifier darf
geeignet modifiziert werden.
<!DOCTYPE
html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"[Link]
Hier ist ein Beispiel eines XHTML 1.1-Dokuments:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"[Link]
<html xmlns="[Link] xml:lang="en" >
<head>
<title>Virtual Library</title>
</head>
<body>
<p>Moved to <a href="[Link]
</body>
</html>
Beachten Sie, dass in diesem Beispiel die XML-Deklaration enthalten ist. Eine XML-Deklaration,
XHTML 1.1 - Modulbasiertes XHTML
wie die obige, ist nicht in allen XML-Dokumenten erforderlich. Autoren von XHTML-Doku-
menten sind nachdr cklich dazu aufgefordert, XML-Deklarationen in all ihren Dokumenten zu
verwenden. Eine solche Deklaration ist erforderlich, falls die Zeichenkodierung des Dokuments
eine andere als die vorgegebenen UTF-8 oder UTF-16 sind.
2.2 Konformit.t eines Benutzerprogramms
Ein konformes Benutzerprogramm muss alle Konformit@tsanforderungen f r Benutzerpro-
gramme erf llen, die in [XHTMLMOD] definiert sind.
3 Der XHTML 1.1-Dokumenttyp
Dieser Abschnitt ist normativ.
Der XHTML 1.1-Dokumenttyp ist ein voll funktionsf@higer Dokumenttyp mit umfangreichen
semantischen Eigenschaften. Er ist in seinem Funktionsumfang jedoch nicht so variantenreich
wie die Transitional- und Frameset-Dokumenttypen von XHTML 1.0. Diese beiden Dokument-
typen definieren viele pr@sentationsorientierte Aspekte, die durch Stylesheets oder @hnliche
Mechanismen besser abgedeckt werden. Da der XHTML 1.1-Dokumenttyp ausschließlich auf
den F@higkeiten der XHTML-Module [XHTMLMOD] fußt, enth@lt er außerdem keine der miss-
billigten Funktionen von XHTML 1.0 oder HTML 4. Trotz (oder vielleicht wegen) diesen Ein-
schr@nkungen stellt der XHTML 1.1-Dokumenttyp eine solide Grundlage f r zuk nftige Doku-
menttypen dar, die sich an Umgebungen mit variantenreichen Benutzerprogrammen richten.
Konformit,t eines Benutzerprogramms < 519 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Der XHTML 1.1-Dokumenttyp besteht aus den folgenden XHTML-Modulen. Die zu den
Modulen geh=renden Elemente, Attribute und minimalen Inhaltsmodelle sind in „Modularisie-
rung von XHTML“ [XHTMLMOD]) definiert. Die Elemente sind hier nur zur Information auf-
gef hrt; maßgeblich sind die Definitionen in „Modularisierung von XHTML“. In der Online-Ver-
sion dieses Dokuments sind die Modulnamen in der nachfolgenden Aufstellung mit den Defini-
tionen der Module in der aktuellen Version von „Modularisierung von XHTML“ verlinkt.
Strukturmodul*
body, head, html, title
Textmodul*
abbr, acronym, address, blockquote, br, cite, code, dfn, div, em, h1, h2, h3, h4, h5, h6, kbd,
p, pre, q, samp, span, strong, var
Hypertext-Modul*
a
Listenmodul*
dl, dt, dd, ol, ul, li
Objektmodul
object, param
Darstellungsmodul
b, big, hr, i, small, sub, sup, tt
Edit-Modul
del, ins
XHTML 1.1 - Modulbasiertes XHTML
Modul f-r bidirektionalen Text
bdo
Formularmodul
button, fieldset, form, input, label, legend, select, optgroup, option, textarea
Tabellenmodul
caption, col, colgroup, table, tbody, td, tfoot, th, thead, tr
Bildmodul
img
Modul f-r client-seitige Image Maps
area, map
Modul f-r server-seitige Image Maps
Attribute ismap on img
Modul f-r eingebaute Ereignisse
Events attributes
Metainformationsmodul
meta
Scripting-Modul
noscript, script
Stylesheet-Modul
style element
Style-Attributmodul Deprecated
style attribute
< 520 > Der XHTML 1.1-Dokumenttyp
Page size: 168,00 x 240,00 mm
Link-Modul
link
Base-Modul
base
XHTML benutzt auch das „Ruby Annotation“-Modul gem@ß Definition in [RUBY]:
Ruby Annotation-Modul
ruby, rbc, rtc, rb, rt, rp
Es gibt keine zus@tzlichen Definitionen, die f r diesen Dokumenttyp erforderlich w@ren. Eine
Implementierung dieses Dokumenttyps in Form einer XML-DTD ist in Anhang C definieren.
A Xnderungen gegen-ber
XHTML 1.0 Strict
Dieser Anhang ist informell.
Dieser Anhang beschreibt Unterschiede zwischen XHTML 1.1 und XHTML 1.0 Strict. XHTML
1.1 stellt eine Abkehr sowohl von HTML 4 als auch von XHTML 1.0 dar. Am auff@lligsten ist
XHTML 1.1 - Modulbasiertes XHTML
das Entfernen von missbilligten Eigenschaften. Im Allgemeinen besteht die Strategie darin, eine
Auszeichnungssprache zu definieren, die umfangreiche strukturierende Eigenschaften besitzt,
sich zur Darstellung aber auf Stylesheets verl@sst.
Die Unterschiede k=nnen wie folgt zusammengefasst werden:
1. Von jedem Element wurde das lang-Attribut zugunsten des xml:lang-Attributs (gem@ß Defi-
nition in [XHTMLMOD]) entfernt.
2. Von den Elementen a und map wurde das name-Attribut zugunsten des id-Attributs (gem@ß
Definition in [XHTMLMOD]) entfernt.
3. Die ruby-Elementsammlung (gem@ß Definition in [RUBY]) wurde hinzugef gt.
B Bibliographie
Dieser Anhang ist normativ.
B.1 Normative Quellen
[HTML4]
HTML 4.01 Specification, W3C Recommendation, Dave Raggett, Arnaud Le Hors, Ian
Jacobs, 24. Dezember 1999.
Siehe: [Link]
Bnderungen gegen#ber XHTML 1.0 Strict < 521 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
[XHTML1]
XHTML 1.0: The Extensible HyperText Markup Language, W3C Recommendation, Steven
Pemberton et al., 26. Januar 2000.
Siehe: [Link]
[XHTMLMOD]
Modularization of XHTML, W3C Recommendation, Murray Altheim et al., 10. April 2001
Siehe: [Link]
[XML]
Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation, Tim
Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 6. Oktober 2000.
Siehe: [Link]
[RUBY]
Ruby Annotation, W3C Recommendation, Marcin Sawicki et al., 31. Mai 2001.
Siehe: [Link]
B.2 Informelle Quellen
[CATALOG]
Entity Management: OASIS Technical Resolution 9401:1997 (Amendment 2 to TR 9401),
Paul Grosso, Chair, Entity Management Subcommittee, SGML Open, 10. September 1997.
Siehe: [Link]
[RFC2119]
XHTML 1.1 - Modulbasiertes XHTML
"Key words for use in RFCs to indicate requirement levels", RFC 2119, S. Bradner, M@rz
1997.
Available at: [Link]
[XMLNAMES]
"Namespaces in XML", W3C Recommendation, Tim Bray, Dave Hollander, Andrew
Layman, 14. Januar 1999.
Available at: [Link]
C XHTML
1.1-Dokumenttyp-Definition
Dieser Anhang ist normativ.
C.1 SGML Open Catalog-Eintrag f-r XHTML 1.1
Dieser Abschnitt enth@lt die SGML Open Catalog-Definition [CATALOG] f r den XHTML 1.1 FPI.
- - .......................................................................... - -
- - File catalog ............................................................ - -
- - XHTML 1.1 Catalog Data File
< 522 > XHTML 1.1-Dokumenttyp-Definition
Page size: 168,00 x 240,00 mm
Revision: @(#)[Link] 1.9 2001/04/04 SMI
See "Entity Management", SGML Open Technical Resolution 9401 for detailed
information on supplying and using catalog data. This document is available
from OASIS at URL:
<[Link]
--
- - .......................................................................... - -
- - SGML declaration associated with XHTML .................................. - -
OVERRIDE YES
SGMLDECL "[Link]"
- - :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: - -
- - XHTML 1.1 DTD modular driver file ....................................... - -
- - note that this uses the local, flattened version of the DTD. If you want
your catalog to use the master version of the XHTML Modules, change the
entry to reference [Link] instead of [Link]
--
PUBLIC "-//W3C//DTD XHTML 1.1//EN" "[Link]"
- - XHTML 1.1 framework modules .............................................. - -
XHTML 1.1 - Modulbasiertes XHTML
PUBLIC "-//W3C//ENTITIES XHTML 1.1 Document Model 1.0//EN"
"[Link]"
- - End of catalog data ..................................................... - -
- - .......................................................................... - -
C.2 XHTML 1.1-Treiber
Dieser Abschnitt enth@lt den Treiber f r die XML-DTD-Implementation des XHTML 1.1-
Dokumenttyps. Sie basiert auf den XHTML-Modulimplementierungen gem@ß Definition in
[XHTMLMOD] und in [RUBY].
<!- - ....................................................................... - ->
<!- - XHTML 1.1 DTD ........................................................ - ->
<!- - file: [Link]
- ->
<!- - XHTML 1.1 DTD
This is XHTML, a reformulation of HTML as a modular XML application.
The Extensible HyperText Markup Language (XHTML)
Copyright 1998-2001 World Wide Web Consortium
(Massachusetts Institute of Technology, Institut National de
XHTML 1.1-Treiber < 523 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Recherche en Informatique et en Automatique, Keio University).
All Rights Reserved.
Permission to use, copy, modify and distribute the XHTML DTD and its
accompanying documentation for any purpose and without fee is hereby
granted in perpetuity, provided that the above copyright notice and
this paragraph appear in all copies. The copyright holders make no
representation about the suitability of the DTD for any purpose.
It is provided \;as is\( without expressed or implied warranty.
Author: Murray M. Altheim <altheim@[Link]>
Revision: $Id: [Link],v 1.21 2001/05/29 16:37:01 ahby Exp $
- ->
<!- - This is the driver file for version 1.1 of the XHTML DTD.
Please use this formal public identifier to identify it:
"-//W3C//DTD XHTML 1.1//EN"
- ->
<!ENTITY % [Link] "-//W3C//DTD XHTML 1.1//EN" >
<!- - Use this URI to identify the default namespace:
"[Link]
XHTML 1.1 - Modulbasiertes XHTML
See the Qualified Names module for information
on the use of namespace prefixes in the DTD.
- ->
<!ENTITY % [Link] "IGNORE" >
<!ENTITY % [Link] "" >
<!- - Reserved for use with the XLink namespace:
- ->
<!ENTITY % [Link] "" >
<!ENTITY % [Link] "" >
<!- - For example, if you are using XHTML 1.1 directly, use the FPI
in the DOCTYPE declaration, with the xmlns attribute on the
document element to identify the default namespace:
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "[Link]">
<html xmlns="[Link]
xml:lang="en">
...
</html>
Revisions:
(none)
- ->
<!- - reserved for future use with document profiles - ->
<!ENTITY % [Link] "" >
< 524 > XHTML 1.1-Dokumenttyp-Definition
Page size: 168,00 x 240,00 mm
<!- - Bidirectional Text features
This feature-test entity is used to declare elements
and attributes used for bidirectional text support.
- ->
<!ENTITY % [Link] "INCLUDE" >
<?doc type="doctype" role="title" { XHTML 1.1 } ?>
<!- - ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: - ->
<!- - Pre-Framework Redeclaration placeholder .................... - ->
<!- - this serves as a location to insert markup declarations
into the DTD prior to the framework declarations.
- ->
<!ENTITY % [Link] "IGNORE" >
<![%[Link];[
%[Link];
<!- - end of [Link] - ->]]>
<!ENTITY % [Link] "INCLUDE" >
<!- - Inline Style Module ........................................ - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Inline Style 1.0//EN"
"[Link] >
XHTML 1.1 - Modulbasiertes XHTML
%[Link];]]>
<!- - declare Document Model module instantiated in framework
- ->
<!ENTITY % [Link]
PUBLIC "-//W3C//ENTITIES XHTML 1.1 Document Model 1.0//EN"
"[Link]" >
<!- - Modular Framework Module (required) ......................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ENTITIES XHTML Modular Framework 1.0//EN"
"[Link] >
%[Link];]]>
<!- - Post-Framework Redeclaration placeholder ................... - ->
<!- - this serves as a location to insert markup declarations
into the DTD following the framework declarations.
- ->
<!ENTITY % [Link] "IGNORE" >
<![%[Link];[
%[Link];
<!- - end of [Link] - ->]]>
<!- - Text Module (Required) ..................................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
XHTML 1.1-Treiber < 525 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
PUBLIC "-//W3C//ELEMENTS XHTML Text 1.0//EN"
"[Link] >
%[Link];]]>
<!- - Hypertext Module (required) ................................. - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Hypertext 1.0//EN"
"[Link] >
%[Link];]]>
<!- - Lists Module (required) .................................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Lists 1.0//EN"
"[Link] >
%[Link];]]>
<!- - ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: - ->
<!- - Edit Module ................................................ - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Editing Elements 1.0//EN"
XHTML 1.1 - Modulbasiertes XHTML
"[Link] >
%[Link];]]>
<!- - BIDI Override Module ....................................... - ->
<!ENTITY % [Link] "%[Link];" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML BIDI Override Element 1.0//EN"
"[Link] >
%[Link];]]>
<!- - Ruby Module ................................................ - ->
<!ENTITY % [Link] "INCLUDE" >
<!ENTITY % [Link] "%[Link];" >
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Ruby 1.0//EN"
"[Link] >
%[Link];]]>
<!- - Presentation Module ........................................ - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Presentation 1.0//EN"
"[Link] >
%[Link];]]>
< 526 > XHTML 1.1-Dokumenttyp-Definition
Page size: 168,00 x 240,00 mm
<!- - Link Element Module ........................................ - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Link Element 1.0//EN"
"[Link] >
%[Link];]]>
<!- - Document Metainformation Module ............................ - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Metainformation 1.0//EN"
"[Link] >
%[Link];]]>
<!- - Base Element Module ........................................ - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Base Element 1.0//EN"
"[Link] >
%[Link];]]>
<!- - Scripting Module ........................................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
XHTML 1.1 - Modulbasiertes XHTML
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Scripting 1.0//EN"
"[Link] >
%[Link];]]>
<!- - Style Sheets Module ......................................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Style Sheets 1.0//EN"
"[Link] >
%[Link];]]>
<!- - Image Module ............................................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Images 1.0//EN"
"[Link] >
%[Link];]]>
<!- - Client-side Image Map Module ............................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Client-side Image Maps 1.0//EN"
"[Link] >
%[Link];]]>
XHTML 1.1-Treiber < 527 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!- - Server-side Image Map Module ............................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Server-side Image Maps 1.0//EN"
"[Link] >
%[Link];]]>
<!- - Param Element Module ....................................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Param Element 1.0//EN"
"[Link] >
%[Link];]]>
<!- - Embedded Object Module ..................................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Embedded Object 1.0//EN"
"[Link] >
%[Link];]]>
<!- - Tables Module ............................................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
XHTML 1.1 - Modulbasiertes XHTML
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Tables 1.0//EN"
"[Link] >
%[Link];]]>
<!- - Forms Module ............................................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Forms 1.0//EN"
"[Link] >
%[Link];]]>
<!- - Legacy Markup ............................................... - ->
<!ENTITY % [Link] "IGNORE" >
<![%[Link];[
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Legacy Markup 1.0//EN"
"[Link] >
%[Link];]]>
<!- - Document Structure Module (required) ....................... - ->
<!ENTITY % [Link] "INCLUDE" >
<![%[Link];[
< 528 > XHTML 1.1-Dokumenttyp-Definition
Page size: 168,00 x 240,00 mm
<!ENTITY % [Link]
PUBLIC "-//W3C//ELEMENTS XHTML Document Structure 1.0//EN"
"[Link] >
%[Link];]]>
<!- - end of XHTML 1.1 DTD ................................................. - ->
<!- - ....................................................................... - ->
C.3 Anpassung f-r XHTML 1.1
Ein Dokumenttyp der XHTML-Familie (so wie XHTML 1.1) muss das von ihm verwendete
Inhaltsmodell definieren. Dies geschieht mit einem eigenen Inhaltsmodellmodul, das durch das
XHTML-Modulrahmenwerk instanziiert wird. Das Inhaltsmodellmodul und der XHTML
1.1-Treiber (siehe oben) arbeiten zusammen, um die Modulimplementierungen an die doku-
menttypspezifischen Erfordernisse anzupassen. Das Inhaltsmodellmodul f r XHTML 1.1 ist im
Folgenden definiert:
<!- - ....................................................................... - ->
<!- - XHTML 1.1 Document Model Module ...................................... - ->
<!- - file: [Link]
This is XHTML 1.1, a reformulation of HTML as a modular XML application.
Copyright 1998-2001 W3C (MIT, INRIA, Keio), All Rights Reserved.
Revision: $Id: [Link],v 1.13 2001/05/29 16:37:01 ahby Exp $ SMI
XHTML 1.1 - Modulbasiertes XHTML
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//ENTITIES XHTML 1.1 Document Model 1.0//EN"
SYSTEM "[Link]
Revisions:
(none)
....................................................................... - ->
<!- - XHTML 1.1 Document Model
This module describes the groupings of elements that make up
common content models for XHTML elements.
XHTML has three basic content models:
%[Link]; character-level elements
%[Link]; block-like elements, eg., paragraphs and lists
%[Link]; any block or inline elements
Any parameter entities declared in this module may be used
to create element content models, but the above three are
considered 'global' (insofar as that term applies here).
The reserved word '#PCDATA' (indicating a text string) is now
included explicitly with each element declaration that is
declared as mixed content, as XML requires that this token
occur first in a content model specification.
- ->
Anpassung f#r XHTML 1.1 < 529 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!- - Extending the Model
While in some cases this module may need to be rewritten to
accommodate changes to the document model, minor extensions
may be accomplished by redeclaring any of the three *.extra;
parameter entities to contain extension element types as follows:
%[Link]; whose parent may be any block or
inline element.
%[Link]; whose parent may be any inline element.
%[Link]; whose parent may be any block element.
If used, these parameter entities must be an OR-separated
list beginning with an OR separator ("|"), eg., "| a | b | c"
All block and inline *.class parameter entities not part
of the *[Link] classes begin with "| " to allow for
exclusion from mixes.
- ->
<!- - .............. Optional Elements in head .................. - ->
<!ENTITY % [Link]
"( %[Link]; | %[Link]; | %[Link];
| %[Link]; | %[Link]; )*"
XHTML 1.1 - Modulbasiertes XHTML
>
<!- - ................. Miscellaneous Elements .................. - ->
<!- - ins and del are used to denote editing changes
- ->
<!ENTITY % [Link] "| %[Link]; | %[Link];" >
<!- - script and noscript are used to contain scripts
and alternative content
- ->
<!ENTITY % [Link] "| %[Link]; | %[Link];" >
<!ENTITY % [Link] "" >
<!- - These elements are neither block nor inline, and can
essentially be used anywhere in the document body.
- ->
<!ENTITY % [Link]
"%[Link];
%[Link];
%[Link];"
>
<!- - .................... Inline Elements ...................... - ->
<!ENTITY % [Link] "%[Link]; | %[Link];" >
< 530 > XHTML 1.1-Dokumenttyp-Definition
Page size: 168,00 x 240,00 mm
<!ENTITY % [Link]
"| %[Link]; | %[Link]; | %[Link]; | %[Link];
| %[Link]; | %[Link]; | %[Link]; | %[Link];
| %[Link]; | %[Link]; | %[Link];" >
<!ENTITY % [Link]
"| %[Link]; | %[Link]; | %[Link]; | %[Link];
| %[Link]; | %[Link]; | %[Link];" >
<!ENTITY % [Link] "| %[Link];" >
<!ENTITY % [Link] "| %[Link];" >
<!ENTITY % [Link]
"| %[Link]; | %[Link];
| %[Link];" >
<!ENTITY % [Link]
"| %[Link]; | %[Link]; | %[Link];
| %[Link]; | %[Link];" >
<!ENTITY % [Link] "" >
<!ENTITY % [Link] "| %[Link];" >
<!- - %[Link]; includes all inline elements,
used as a component in mixes
XHTML 1.1 - Modulbasiertes XHTML
- ->
<!ENTITY % [Link]
"%[Link];
%[Link];
%[Link];
%[Link];
%[Link];
%[Link];
%[Link];
%[Link];
%[Link];"
>
<!- - %[Link]; includes all inline elements
except ruby, used as a component in mixes
- ->
<!ENTITY % [Link]
"%[Link];
%[Link];
%[Link];
%[Link];
%[Link];
%[Link];
%[Link];
%[Link];"
>
Anpassung f#r XHTML 1.1 < 531 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<!- - %[Link]; includes all inlines except ruby
- ->
<!ENTITY % [Link]
"( #PCDATA
| %[Link];
%[Link]; )*"
>
<!- - %[Link]; includes all non-anchor inlines,
used as a component in mixes
- ->
<!ENTITY % [Link]
"%[Link];
%[Link];
%[Link];
%[Link];
%[Link];
%[Link];
%[Link];
%[Link];"
>
<!- - %[Link]; includes all non-anchor inlines
- ->
<!ENTITY % [Link]
"%[Link];
%[Link];"
XHTML 1.1 - Modulbasiertes XHTML
>
<!- - %[Link]; includes all inline elements, including %[Link];
- ->
<!ENTITY % [Link]
"%[Link];
%[Link];"
>
<!- - ..................... Block Elements ...................... - ->
<!- - In the HTML 4.0 DTD, heading and list elements were included
in the %block; parameter entity. The %[Link]; and
%[Link]; parameter entities must now be included explicitly
on element declarations where desired.
- ->
<!ENTITY % [Link]
"%[Link]; | %[Link]; | %[Link];
| %[Link]; | %[Link]; | %[Link];" >
<!ENTITY % [Link] "%[Link]; | %[Link]; | %[Link];" >
<!ENTITY % [Link] "| %[Link];" >
<!ENTITY % [Link] "| %[Link];" >
<!ENTITY % [Link] "| %[Link];" >
< 532 > XHTML 1.1-Dokumenttyp-Definition
Page size: 168,00 x 240,00 mm
<!ENTITY % [Link] "%[Link]; | %[Link];" >
<!ENTITY % [Link]
"| %[Link]; | %[Link]; | %[Link];" >
<!ENTITY % [Link] "| %[Link];" >
<!ENTITY % [Link]
"%[Link];
%[Link];
%[Link];"
>
<!ENTITY % [Link] "" >
<!- - %[Link]; includes all block elements,
used as an component in mixes
- ->
<!ENTITY % [Link]
"%[Link];
%[Link];
%[Link];
%[Link];
%[Link];"
>
<!- - %[Link]; includes all block elements plus %[Link];
XHTML 1.1 - Modulbasiertes XHTML
- ->
<!ENTITY % [Link]
"%[Link];
| %[Link];
| %[Link];
%[Link];"
>
<!- - ................ All Content Elements .................. - ->
<!- - %[Link]; includes all text content, block and inline
- ->
<!ENTITY % [Link]
"%[Link];
| %[Link];
| %[Link];
| %[Link];
%[Link];"
>
<!- - end of [Link] - ->
Anpassung f#r XHTML 1.1 < 533 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
D Danksagungen
Dieser Anhang ist informell.
Diese Spezifikation wurde von der HTML Working Group des W3C erstellt. Die Mitglieder
dieser Gruppe zum Zeitpunkt der Ver=ffentlichung waren:
Steven Pemberton, CWI (HTML Working Group Chair);Murray Altheim, Sun Microsystems;
Daniel Austin, Mozquito Technologies; Jonny Axelsson, Opera Software;Mark Baker, Sun
Microsystems; Tantek kelik, Microsoft; Doug Dominiak, Openwave Systems; Herman Elen-
baas, Philips Electronics; Beth Epperson, Netscape/AOL; Masayasu Ishikawa, W3C (HTML Acti-
vity Lead); Shin'ichi Matsui, Panasonic; Shane McCarron, Applied Testing and Technology; Ann
Navarro, WebGeek, Inc.; Peter Stark, Ericsson;Michel Suignard, Microsoft;Jeremy Wadsworth,
Quark Inc.; Malte Wedel, Mozquito Technologies; Ted Wugofski, Openwave Systems;
XHTML 1.1 - Modulbasiertes XHTML
< 534 > Danksagungen
Page size: 168,00 x 240,00 mm
<edition
[Link]>
F
< Cascading Style
Sheets, Level 2 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Cascading Style Sheets, Level 2
Deutsche bersetzung
Diese Version:
[Link]
Aktuelle Version:
[Link]
bersetzer:
Judith Muhr ( bersetzung)
Stefan Mintert (Fachlektorat und Kommentierung), [Link]
<stefan@[Link]>
Bei diesem Dokument handelt es sich um eine bersetzung eines W3C-Textes. Dieser
Text ist urheberrechtlich gesch tzt; bitte beachten Sie die nachfolgenden Hinweise des
Originaldokuments. Die Rechte an der bersetzung liegen bei den bersetzern und
dem Verlag Addison-Wesley. Die bersetzung hat keine durch das W3C legitimierte,
normative Wirkung. Das einzige maßgebliche Dokument ist das englische Original.
Bitte senden Sie Fehler und Korrekturen zur deutschen Fassung an die bersetzer.
Kommentare der bersetzer, die als solche gekennzeichnet sind, unterliegen dem
Urheberrecht der bersetzer. Sie sind nicht Bestandteil des Ursprungsdokuments.
Diese Ver=ffentlichung ist eine Vorver ffentlichung. Kein Teil dieses Textes darf kopiert
werden. Alle Rechte vorbehalten. Nach Abschluss der Arbeit wird das endg ltige
Dokument unter der oben angegebenen Adresse ver=ffentlicht. Die jetzige Ver=ffent-
lichung w@hrend der laufenden Arbeit dient zur Information von Interessierten und zur
Pr fung durch die Fach=ffentlichkeit. Sollten Sie Fehler finden oder Verbesserungsvor-
schl@ge haben, schicken Sie diese bitte per Mail an Stefan Mintert.
Cascading Style Sheets, Level 2
Cascading Style Sheets, Level 2
CSS2-Spezifikation
W3C Recommendation 12-May-1998
Diese Version
[Link]
Aktuelle Version
[Link]
Vorhergehende Version
[Link]
Herausgeber
Bert Bos <bbos@[Link]>
Hakon Wium Lie <howcome@[Link]>
Chris Lilley <chris@[Link]>
Ian Jacobs <ij@[Link]>
< 536 > Cascading Style Sheets, Level 2
Page size: 168,00 x 240,00 mm
Zusammenfassung
Diese Spezifikation definiert Cascading Style Sheets, level 2 (CSS2). CSS2 ist eine Formatie-
rungssprache, die es Autoren und Benutzern gestattet, Formatierungen (zum Beispiel Schriften,
Abst@nde und akustische Aspekte) von strukturierten Dokumenten (zum Beispiel HTML-Do-
kumente und XML-Instanzen) durchzuf hren. Mit der Trennung der Pr@sentation eines Doku-
ments vom Inhalt des Dokuments vereinfacht CSS2 die Erfassung von Web-Dokumenten und
die Verwaltung von Sites.
CSS2 basiert auf CSS1 (siehe [CSS1]) und mit sehr wenigen Ausnahmen sind alle g ltigen
CSS1-Stylesheets auch g ltige CSS2-Stylesheets. CSS2 unterst tzt medienspezifische Style-
sheets, so dass Autoren die Darstellung ihrer Dokumente auf visuelle Browser, akustische
Ger@te, Drucker, Braille-Ger@te, Handhelds und so weiter zuschneiden k=nnen. Diese Spezifi-
kation unterst tzt zudem die Positionierung von Inhalt, herunterladbare Schriften, Tabellen-
Layout, Internationalisierung, automatische Z@hler und Nummerierung, sowie einige Eigen-
schaften, die mit der Benutzerschnittstelle zu tun haben.
Status dieses Dokuments
Dieses Dokument wurde von W3C-Mitglieder und anderen Interessierten begutachtet, und es
wurde vom Direktor als W3C Recommendation gebilligt. Es handelt sich um ein stabiles Doku-
ment und kann als Referenzmaterial verwendet oder als normative Referenz in anderen Doku-
menten zitiert werden. Bei der Herstellung der Recommendation ist es die Rolle des W3C, die
Aufmerksamkeit auf diese Spezifikation zu lenken und ihre Verbreitung zu f=rdern. Das verbes-
sert die Funktionsweise und Interoperabilit@t des Web.
Eine Liste aktueller W3C Recommendations und anderer technischer Dokumente steht unter
[Link] zur Verf gung.
Die =ffentliche Diskussion von CSS-Eigenschaften findet auf www-style@[Link] statt.
Verf-gbare Formate
Die CSS2-Spezifikation steht in folgenden Formaten zur Verf gung:
Cascading Style Sheets, Level 2
HTML:
[Link]
Textdatei:
[Link]
HTML (gzip/tar-Datei):
[Link]
HTML (zip-Datei; dies ist eine '.zip'-Datei, keine '.exe'):
[Link]
PostScript-Datei (gzip):
[Link]
PDF-Datei:
[Link]
Cascading Style Sheets, Level 2 < 537 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Anmerkung der bersetzer: Die deutsche bersetzung der Spezifikation steht
online unter [Link] zur Verf gung.
In gedruckter Form ist CSS2 als Teil der edition [Link] bei Addison-Wesley erschienen.
Informationen ber dieses und weitere B cher der edition [Link] erhalten Sie unter
[Link]
Im Falle von Abweichungen zwischen den diversen Formen der Spezifikation ist [Link]
TR/1998/REC-CSS2-19980512 die maßgebliche Version.
Verf-gbare Sprachen
Die englische Version dieser Spezifikation ist die einzige normative Version. bersetzung in
andere Sprachen erreichen Sie ber [Link]
Errata
Die Liste bekannter Fehler in dieser Spezifikation steht unter [Link]
dates/[Link] zur Verf gung. Bitte berichten Sie Fehler in diesem
Dokument an css2-editors@[Link].
Anmerkung der bersetzer: Bitte berichten Sie Fehler in dieser bersetzung an
die bersetzer.
Cascading Style Sheets, Level 2
1 Informationen zur
CSS2-Spezifikation
1.1 Wie Sie die Spezifikation lesen
Diese Spezifikation richtet sich haupts@chlich an zwei Lesergruppen: CSS-Autoren und CSS-Im-
plementierer. Wir hoffen, die Spezifikation versorgt die Autoren mit dem Werkzeug, das sie
brauchen, um effiziente, attraktive Dokumente zu erstellen, auf die ein einfacher Zugriff m=g-
lich ist, ohne sie zu sehr mit den Implementierungsdetails von CSS zu belasten. Die Implemen-
tierer hingegen sollen hier alles finden, was sie brauchen, um konforme Benutzerprogramme
(User Agents) zu schreiben. Die Spezifikation beginnt mit einer allgemeinen Einf hrung in CSS
und wird zum Ende hin immer technischer und spezifischer. Damit Sie alle wichtigen Informa-
tionen m=glichst schnell finden, wird die einfache Navigation sowohl in der elektronischen als
auch in der gedruckten Version durch ein allgemeines Inhaltsverzeichnis, spezielle Inhaltsver-
zeichnisse am Anfang eines jeden Abschnitts sowie einen Index sichergestellt.
< 538 > Informationen zur CSS2-Spezifikation
Page size: 168,00 x 240,00 mm
Anmerkung der bersetzer: An dieser Stelle taucht zum ersten Mal der Begriff
„User Agent“ auf. Nach reiflicher berlegung und Abw@gung haben wir uns entschie-
den, im Deutschen daf r den Begriff „Benutzerprogramm“ zu verwenden. Da unserer
Auffassung nach kein deutscher Begriff existiert, der das Bedeutungsspektrum des
„User Agent“ besitzt, ist eine Erkl@rung notwendig:
Der bekannteste Programmtyp, mit denen Menschen das WWW nutzen und auf Inhalte
zugreifen, ist der Web-Browser. Der Browser ist ein Beispiel fr einen User Agent. Der
„User Agent“ ist die Verallgemeinerung davon. Ein User Agent ist die Software, die als
Vertreter eines menschlichen Benutzers auf die Daten im Web zugreift. Der User Agent
kann die Suchmaschine sein, die Daten aus dem Web l@dt, um sie zu indexieren.
Damit kommt der „User Agent“ dem Begriff „Client“ sehr nah. W@hrend der „Client“
jedoch auf einen technischen Aspekt abzielt, beschreibt der Begriff „User Agent“ eine
Funktion; n@mlich die, dass er im Namen des Benutzers t@tig wird.
Im Englischen wird der „Agent“ allgemeiner als im Deutschen benutzt. Aber auch in der
deutschen Sprache haben wir Beispiele f r eine Begriffsbedeutung, die mit diesem Fall
vergleichbar ist: Wir kennen Agenturen und Theateragenten, die als Vertreter des K nst-
lers und in seinem Namen t@tig werden. Die gleiche Rolle bernimmt der User Agent
im WWW.
Da aber die erste Assoziation zum Agenten die des Spions ist, haben wir uns f r den
neutralen Begriff „Benutzerprogramm“ entschieden. Dabei sollten Sie als Leser nicht
vergessen, dass das Benutzerprogramm auch ein Programm sein kann, dass automatisch
im Web nach Daten sucht, oder auch irgendeine Software, die auf die Daten zugreift.
Diese Spezifikation wird in zwei Formen bereitgestellt: elektronisch und gedruckt. Obwohl die
beiden Darstellungen zweifellos sehr @hnlich sind, werden die Leser einige Unterschiede erken-
nen. In der gedruckten Version funktionieren beispielsweise (offensichtlich) keine Links, und in
Cascading Style Sheets, Level 2
der elektronischen Version gibt es keine Seitenzahlen. Bei inhaltlichen Abweichungen ist die
elektronische Version die ausschlaggebende.
1.2 Der Aufbau der Spezifikation
Die Spezifikation ist in die folgenden Abschnitte unterteilt:
1.2.1 Abschnitt 2: Eine Einf-hrung in CSS2
Die Einf hrung enth@lt einen kurzen berblick ber CSS2 sowie eine Beschreibung der Ent-
wurfsgrundlagen, die hinter CSS2 stehen.
1.2.2 Abschnitt 3 – 20: CSS2-Referenzhandbuch
Die CSS-Sprachreferenz bildet einen Großteil des Referenzhandbuchs. Diese Referenz defi-
niert, was in einem CSS2-Stylesheet enthalten sein darf (Syntax, Eigenschaften und Eigenschafts-
werte) und wie die Benutzerprogramme diese Stylesheets interpretieren m ssen, um konform
zur Spezifikation zu sein.
Der Aufbau der Spezifikation < 539 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
1.2.3 [Link]
Die Anh@nge beschreiben ein Beispiel-Stylesheet f r HTML 4.0, Onderungen im Vergleich zu
CSS1, Anmerkungen zu Implementierung und Leistung, die Grammatik von CSS2, eine Liste
normativer und informativer Literaturhinweise sowie drei Indizes: einen f r Eigenschaften,
einen f r Deskriptoren und einen allgemeinen Gesamtindex.
1.3 Konventionen
1.3.1 Elemente und Attribute der Dokumentsprache
· Namen von CSS-Eigenschaften, Deskriptoren und Pseudo-Klassen sind in einfache Anf h-
rungszeichen eingeschlossen.
·· CSS-Werte sind in einfache Anf hrungszeichen eingeschlossen.
Namen von Elementen der Dokumentsprache sind in Großbuchstaben dargestellt.
· Namen von Attributen der Dokumentsprache sind in Kleinbuchstaben dargestellt und in
doppelte Anf hrungszeichen eingeschlossen.
1.3.2 CSS-Eigenschaftsdefinitionen
Jede CSS-Eigenschaftsdefinition beginnt mit einem berblick ber die Schl sselinformationen,
der etwa wie folgt aussieht:
'eigenschaftsname'
Wert: erlaubte Werte & Syntax
Ausgangswert: Ausgangswert
Angewendet auf: Elemente, auf die sich diese Eigenschaft bezieht
Cascading Style Sheets, Level 2
Vererbt: Gibt an, ob diese Eigenschaft vererbt wird
Prozentwerte: Gibt an, wie Prozentwerte interpretiert werden
Medium Gibt an, auf welche Mediengruppe sich die Eigenschaft bezieht
Anmerkung der bersetzer: Wie die Syntax von erlaubten Werten aussieht,
erkl@rt der nachfolgende Abschnitt zwar sehr pr@zise, aber nicht unbedingt bei der ers-
ten Lekt re verst@ndlich. Es bietet sich an, zun@chst einige Beispiele in sp@teren Teilen
der CSS2-Spezifikation zu lesen. Sollten dabei Fragen auftauchen, kann man an dieser
Stelle nachsehen, was die Wertangabe genau bedeutet.
< 540 > Informationen zur CSS2-Spezifikation
Page size: 168,00 x 240,00 mm
Wert
Dieser Teil listet die g ltigen Werte f r die Eigenschaft auf. Es gibt mehrere M=glichkeiten,
Werttypen anzugeben:
1. Schl sselwortwerte (z. B. auto, disc usw.)
2. Grundlegende Datentypen, die zwischen "<" und ">" stehen (z. B. <length>, <percentage>
usw.). In der elektronischen Version des Dokuments verweist jede Instanz eines grund-
legenden Datentyps mit Hilfe eines Links auf ihre Definition.
3. Typen, die denselben Wertebereich haben wie eine Eigenschaft mit demselben Namen (z. B.
<'border-width'>, <'background-attachment'> usw.). In diesem Fall ist der Typname der
Eigenschaftsname (einschließlich Anf hrungszeichen) zwischen "<" und ">" (z. B.
<'border-width'>). In der elektronischen Version des Dokuments verweist jede Instanz die-
ser Art von Nicht-Terminal-Symbolen mit Hilfe eines Links auf die entsprechende Eigen-
schaftsdefinition.
4. Nicht-Terminal-Symbole, die nicht denselben Namen wie eine Eigenschaft haben. In diesem
Fall erscheint der Name des Nicht-Terminal-Symbols zwischen "<" und ">", wie in
<border-width>. Beachten Sie die Unterscheidung zwischen <border-width> und
<'border-width'>; Letzteres wird relativ zu Ersterem definiert. Die Definition eines Nicht-
Terminal-Symbols befindet sich in der N@he des ersten Auftretens in der Spezifikation. In
der elektronischen Version des Dokuments verweist jede Instanz dieses Werttyps mit Hilfe
eines Links auf die entsprechende Wertdefinition.
Andere W=rter in diesen Definitionen sind Schl sselw=rter und m ssen dort w=rtlich und
ohne Anf hrungszeichen erscheinen (z. B. red). Der Schr@gstrich (/) und das Komma (,) m ssen
ebenfalls exakt erscheinen.
Werte k=nnen wie folgt angeordnet werden:
· Mehrere nebeneinander gestellte W=rter bedeuten, dass sie alle in der vorgegebenen Rei-
henfolge erscheinen m ssen.
· Ein L@ngsstrich (|) trennt zwei oder mehr Alternativen voneinander ab: genau eine von
Cascading Style Sheets, Level 2
ihnen muss erscheinen.
· Ein doppelter L@ngsstrich (||) trennt zwei oder mehr Optionen voneinander ab: eine oder
mehrere davon m ssen in beliebiger Reihenfolge erscheinen.
· Eckige Klammern ([ ]) dienen der Gruppierung.
Das Nebeneinanderstellen bedeutet eine st@rkere Gewichtung als der doppelte L@ngsstrich,
und der doppelte L@ngsstrich ist st@rker als der einfache L@ngsstrich. Die nachfolgenden Zeilen
sind also @quivalent:
a b | c || d e
[ a b ] | [ c || [ d e ]]
Jedem Typ, jedem Schl sselwort und jeder in eckigen Klammern platzierten Gruppe kann einer
der folgenden Modifizierer folgen:
· Ein Stern (*) legt fest, dass der vorhergehende Typ, das vorhergehende Wort oder die vor-
hergehende Gruppe null Mal oder =fter vorkommt.
· Ein Plus-Zeichen (+) legt fest, dass der vorhergehende Typ, das vorhergehende Wort oder
die vorhergehende Gruppe einmal oder mehrmals vorkommen.
· Ein Fragezeichen (?) legt fest, dass der vorhergehende Typ, das vorhergehende Wort oder
die vorhergehende Gruppe optional sind.
Konventionen < 541 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
· Ein Zahlenpaar in geschweiften Klammern ({A,B}) legt fest, dass der vorhergehende Typ,
das vorhergehende Wort oder die vorhergehende Gruppe mindestens A-mal und h=chs-
tens B-mal vorkommen.
Die nachfolgenden Beispiele demonstrieren die verschiedenen Werttypen:
Wert: N | NW | NE
Wert: [ <length> | thick | thin ]{1,4}
Wert: [<family-name> , ]* <family-name>
Wert: <uri>? <color> [ / <color> ]?
Wert: <uri> || <color>
Ausgangswert
Dieser Teil spezifiziert den Ausgangswert der Eigenschaft. Falls die Eigenschaft vererbt ist, ist
dies der Wert, den das Wurzelelement des Dokumentbaums aufweist. Weitere Informationen
finden Sie im Abschnitt ber die Kaskade, wo Sie auch mehr ber die im Stylesheet spezifizier-
ten Werte, geerbte Werte und Ausgangswerte erfahren.
Angewendet auf
Dieser Teil listet die Elemente auf, auf die sich die Eigenschaft bezieht. Man geht davon aus, dass
alle Elemente alle Eigenschaften besitzen, aber einige Eigenschaften haben keine Auswirkung auf
die Darstellung bestimmter Elementtypen. Beispielsweise bezieht sich 'white-space' nur auf Ele-
mente auf Blockebene.
Vererbt
Dieser Teil gibt an, ob der Eigenschaftswert von einem Vorfahrenelement geerbt wurde. Lesen
Sie bitte im Abschnitt ber die Kaskade nach, wo Sie weitere Informationen ber das Zusam-
menspiel zwischen im Stylesheet spezifizierten Werten, geerbten Werten und Ausgangswerten
Cascading Style Sheets, Level 2
finden.
Prozentwerte
Dieser Teil gibt an, wie Prozentwerte interpretiert werden sollen, wenn sie im Wert der Eigen-
schaft auftreten. Ist hier "N/A" angegeben, heißt das, die Eigenschaft akzeptiert keine Prozent-
werte als Wert.
Mediengruppen
Dieser Teil gibt die Mediengruppen an, auf die sich die Eigenschaft bezieht. Die Konformit@ts-
bedingungen sagen aus, dass Benutzerprogramme diese Eigenschaft unterst tzen m ssen, wenn
sie die Darstellung der in diesen Mediengruppen enthaltenen Medientypen unterst tzen wol-
len.
1.3.3 Zusammenfassende Eigenschaften
Einige Eigenschaften sind zusammenfassende Eigenschaften, die es den Autoren erlauben, die
Werte mehrerer Eigenschaften innerhalb einer einzigen Eigenschaft anzugeben.
< 542 > Informationen zur CSS2-Spezifikation
Page size: 168,00 x 240,00 mm
Die Eigenschaft 'font' beispielsweise ist eine zusammenfassende Eigenschaft f r die gleichzeitige
Einstellung von 'font-style', 'font-variant', 'font-weight', 'font-size', 'line-height' und 'font-family'.
Werden in einer zusammenfassenden Form Werte weggelassen, wird diesen „fehlenden“ Eigen-
schaften ihr Ausgangswert zugewiesen (lesen Sie dazu auch den Abschnitt ber die Kaskade).
Die Stilregeln des folgenden Beispiels:
H1 {
font-weight: bold;
font-size: 12pt;
line-height: 14pt;
font-family: Helvetica;
font-variant: normal;
font-style: normal;
font-stretch: normal;
font-size-adjust: none
}
k=nnten auch innerhalb einer einzigen zusammenfassenden Eigenschaft geschrieben werden:
H1 { font: bold 12pt/14pt Helvetica }
In diesem Beispiel nehmen 'font-variant', 'font-stretch', 'font-size-adjust' und 'font-style' ihre
Ausgangswerte an.
1.3.4 Anmerkungen und Beispiele
Alle Beispiele, die eine falsche Verwendung demonstrieren, sind als „FEHLERHAFTES BEI-
SPIEL“ gekennzeichnet.
Alle HTML-Beispiele sind konform zur strengen HTML 4.0 DTD (die in [HTML40] definiert
ist), es sei denn, es wird durch eine Dokumenttypdeklaration etwas anderes angegeben.
Cascading Style Sheets, Level 2
Anmerkungen dienen nur zu Ihrer Information.
Anmerkung der bersetzer: Bei den HTML-Beispielen ist Folgendes zu beach-
ten: Nach der Verabschiedung von HTML und CSS2 wurde eine neue Fassung von
HTML unter dem Namen XHTML verabschiedet. Das X deutet darauf hin, dass
XHTML auf Grundlage von XML definiert wurde. HTML basiert hingegen auf SGML.
XML verlangt nun, dass die Groß/Kleinschreibung von Element- und Attributnamen zu
ber cksichtigen ist. Das heißt, dass der Elementtypename h1 von H1 verschieden ist. In
XHTML sind Elementnamen nur in Kleinschreibweise definiert. Des Weiteren muss es
zu jedem Start-Tag ein korrespondierendes End-Tag geben. Es ist nicht mehr erlaubt,
Tags wegzulassen.
Es gibt noch weitere Unterschiede dieser Art. Im Zweifelsfall finden Sie in der Spezifika-
tion von XHTML verl@ssliche Informationen. Beim Lesen der CSS2-Spezifikation sollten
Sie aber daran denken, dass es sich empfiehlt, alle Elementnamen klein zu schreiben und
keine Tags wegzulassen. Dies gilt selbst dann, wenn die Web-Browser eine Seite den-
noch wie gew nscht darstellen, denn es wird ein bergang von HTML zu XHTML
erleichtert.
Konventionen < 543 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Beispiele und Anmerkungen sind innerhalb der HTML-Quellen f r die Spezifikation gekenn-
zeichnet, und CSS1-Benutzerprogramme stellen sie auf spezielle Weise dar.
1.3.5 Bilder und ausf-hrliche Beschreibungen
Die meisten Bilder in der elektronischen Version dieser Spezifikation werden von einer „aus-
f hrlichen Beschreibung“ begleitet, die den Bildinhalt zusammenfasst. Ein Link zu der ausf hr-
lichen Beschreibung wird durch ein „[D]„ am rechten Bildrand gekennzeichnet.
Bilder und ausf hrliche Beschreibungen haben nur informativen Charakter.
1.4 Danksagungen
Diese Spezifikation entstand in der W3C-Arbeitsgruppe zu Cascading Style Sheets und Forma-
tierungseigenschaften. Neben den Herausgebern dieser Spezifikation sind die Mitglieder dieser
Arbeitsgruppe: Brad Chase (Bitstream), Chris Wilson (Microsoft), Daniel Glazman (ElectricitW
de France), Dave Raggett (W3C/HP), Ed Tecot (Microsoft), Jared Sorensen (Novell), Lauren
Wood (SoftQuad), Laurie Anna Kaplan (Microsoft), Mike Wexler (Adobe), Murray Maloney
(Grif), Powell Smith (IBM), Robert Stevahn (HP), Steve Byrne (JavaSoft), Steven Pemberton
(CWI), Thom Phillabaum (Netscape), Douglas Rand (Silicon Graphics), Robert Pernett (Lotus),
Dwayne Dicks (SoftQuad) und Sho Kuwamoto (Macromedia). Wir danken ihnen f r ihre steti-
gen Bem hungen.
Einige der in die Arbeitsgruppe eingeladenen Experten haben ebenfalls Beitr@ge geleistet:
George Kersher, Glenn Rippel (Bitstream), Jeff Veen (HotWired), Markku T. Hakkinen (The
Productivity Works), Martin D rst (W3C, fr her Universit@t Z rich), Roy Platon (RAL), Todd
Fahrner (Verso), Tim Boland (NIST), Eric Meyer (Case Western Reserve University) und Vin-
cent Quint (W3C).
Der Abschnitt ber Web-Schriften wurde stark gepr@gt durch Brad Chase (Bitstream), David
Meltzer (Microsoft Typography) und Steve Zilles (Adobe). Die folgenden Leute haben ebenfalls
Cascading Style Sheets, Level 2
auf die unterschiedlichsten Arten zu dem Abschnitt ber Schriften beigetragen: Alex Beamon
(Apple), Ashok Saxena (Adobe), Ben Bauermeister (HP), Dave Raggett (W3C/HP), David Ops-
tad (Apple), David Goldsmith (Apple), Ed Tecot (Microsoft), Erik van Blokland (LettError),
Franlois Yergeau (Alis), Gavin Nicol (Inso), Herbert van Zijl (Elsevier), Liam Quin, Misha Wolf
(Reuters), Paul Haeberli (SGI) und Phil Karlton (Netscape).
Der Abschnitt ber Seitenmedien wurde gr=ßtenteils von Robert Stevahn (HP) und Stephen
Waters (Microsoft) geschrieben.
Robert Stevahn (HP), Scott Furman (Netscape) und Scott Isaacs (Microsoft) haben wichtige
Beitr@ge zur CSS-Positionierung geleistet.
Mike Wexler (Adobe) war Herausgeber des tempor@ren Arbeitsentwurfs, der viele der neuen
Funktionsmerkmale von CSS2 beschrieb.
< 544 > Informationen zur CSS2-Spezifikation
Page size: 168,00 x 240,00 mm
T.V. Raman (Adobe) leistete wesentliche Beitr@ge zu ACSS (Aural Cascading Style Sheets) und
den Konzepten der akustischen Darstellung, basierend auf seiner Arbeit ber AsTeR (Audio
System For Technical Readings). Er brachte eine erste Skizze der ACSS-Spezifikation ein, die
die Form der aktuellen Spezifikation wesentlich gepr@gt hat. Werte f r akustische Eigenschaften
im HTML 4.0 Beispiel-Stylesheet stammen aus dieser Quelle; momentan verwendet er sie t@g-
lich auf seinem Audio-Desktop in Kombination mit Emacspeak und dem Emacs W3-Browser
(von William Perry, der auch die akustischen Erweiterungen auf der W3-Seite des Zauns imple-
mentiert hat).
Todd Fahrner (Verso) untersuchte aktuelle und @ltere Browser, um das Beispiel-Stylesheet im
Anhang zu entwickeln.
Unser Dank gilt Jan K@rrman, Autor von html2ps, der uns tatkr@ftig dabei half, die PostScript-
Version der Spezifikation zu erstellen.
In elektronischer und physischer Form haben die folgenden Leute zur Entwicklung von CSS2
beigetragen: Alan Borning, Robert Cailliau, Liz Castro, James Clark, Dan Connolly, Donna Con-
verse, Daniel Dardailler, Al Gilman, Daniel Greene, Scott Isaacs, Geir Ivarsøy, Vincent Mallet,
Kim Marriott, Brian Michalowski, Lou Montulli, Henrik Frystyk Nielsen, Jacob Nielsen, Eva von
Pepel, William Perry, David Siegel, Peter Stuckey und Jason White.
Die Diskussionen ber www-style@[Link] haben viele Schl sselaspekte von CSS beeinflusst. Ins-
besondere danken wir Bjorn Backlund, Todd Fahrner, Lars Marius Garshol, Sue Jordan, Ian
Hickson, Susan Lesch, Andrew Marshall, MegaZone, Eric Meyer, Russell O’Connor, David Per-
rell, Liam Quinn, Jon Seymour, Neil St. Laurent, Taylor, Brian Wilson und Chris Wilson f r ihre
Teilnahme.
Unser Dank geht an die WAI PF-Arbeitsgruppe (Web Accessibility Inititaive Protocols and For-
mats Technical Review), die uns geholfen hat, Aspekte der Zug@nglichkeit f r CSS2 zu verbes-
sern.
Dank an Philippe Le HWgaret, dessen CSS-Validator uns geholfen hat, korrekte Beispiele und
eine sensible Grammatik sicherzustellen.
Besonderer Dank gilt Arnaud Le Hors, dessen Engineering-Beitr@ge daf r gesorgt haben, dass
Cascading Style Sheets, Level 2
dieses Dokument funktioniert.
Adam Costello hat diese Spezifikation verbessert, indem er sie detailliert berpr ft hat.
Und schließlich geht unser Dank an Tim Berners-Lee, ohne den nichts von alledem m=glich
gewesen w@re.
1.5 Copyright-Hinweis
Copyright L 1997 World Wide Web Consortium (Massachusetts Institute of Technology, Insi-
tut National de Recherche en Informatique et en Automatique, Keio University). Alle Rechte
vorbehalten.
Dokumente auf der Site des W3C werden von den Copyright-Inhabern unter der nachfolgen-
den Lizenz bereitgestellt. Durch das Herunterladen, Verwenden und/oder Kopieren dieses
Dokuments oder des W3C-Dokuments, aus dem der Link f r diese Aussage stammt, best@ti-
gen Sie, dass Sie die folgenden Bestimmungen und Bedingungen gelesen und verstanden haben
und dass Sie sich entsprechend verhalten:
Die Berechtigung f r die Verwendung, das Kopieren und die Weitergabe des Inhalts dieses
Dokuments oder des entsprechenden W3C-Dokuments auf jedem Medium f r jeden Zweck
und ohne Geb hr oder Tantiemen wird hiermit erteilt, vorausgesetzt, Sie nehmen Folgendes in
ALLE Kopien des Dokuments oder Teile davon, die Sie verwenden, auf:
Copyright-Hinweis < 545 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
1. Einen Link oder die URI zum Original-W3C-Dokument.
2. Die oben aufgef hrte Copyright-Notiz des Originalautors, und falls diese nicht existiert,
einen Hinweis der folgenden Form: „Copyright L World Wide Web Consortium, (Massa-
chusetts Institute of Technology, Institut National de Recherche en Informatique et en
Automatique, Keio University). Alle Rechte vorbehalten.“
3. Falls existent, den STATUS des W3C-Dokuments.
Falls der Platz es erlaubt, sollte der vollst@ndige Text dieses HINWEISES bereitgestellt werden.
Dar ber hinaus sollten die Copyright-Inhaber aller Software, Dokumente oder anderer Dinge
oder Produkte, die Sie der Implementierung dieses Dokuments oder eines Teils davon folgend
erstellen, erw@hnt werden.
Diese Lizenz berechtigt Sie nicht, Onderungen oder Ableitungen zu erstellen.
DIESES DOKUMENT WIRD „ALS SOLCHES“ BEREITGESTELLT, UND DIE COPYRIGHT-IN-
HABER BERNEHMEN KEINE GARANTIEN, WEDER AUSDR CKLICH NOCH IMPLIZIT,
INKLUSIVE ABER NICHT BEGRENZT AUF GARANTIEN DER HANDELBARKEIT, DER EIG-
NUNG F R EINEN BESTIMMTEN ZWECK, DIE NICHT BERTRETUNG GELTENDER
GESETZE ODER TITEL, DASS DER INHALT DES DOKUMENTS F R EINEN BESTIMMTEN
ZWECK GEEIGNET IST, UND AUCH NICHT, DASS DIE IMPLEMENTIERUNG DIESES
INHALTS KEINE GELTENDEN RECHTE ODER PATENTE DRITTER, COPYRIGHTS,
WARENZEICHEN ODER ANDERE RECHTE VERLETZT.
DIE COPYRIGHT-INHABER SIND NICHT F R DIREKTE, INDIREKTE, SPEZIELLE ODER
FOLGESCHODEN, DIE AUS DER NUTZUNG DES DOKUMENTS ENTSTEHEN, HAFTBAR,
UND AUCH NICHT F R DIE LEISTUNG ODER IMPLEMENTIERUNG SEINES INHALTS.
Die Namen und Warenzeichen der Copyright-Inhaber d rfen NICHT in der Werbung oder
anderen Ver=ffentlichungen genutzt werden, was dieses Dokument betrifft, ebenso wenig wie
sein Inhalt, wenn nicht vorab eine spezielle schriftliche Genehmigung daf r eingeholt wurde. Das
in diesem Dokument genannte Copyright bleibt immer den Copyright-Inhabern vorbehalten.
Cascading Style Sheets, Level 2
2 Einf-hrung in CSS2
2.1 Ein kurzer CSS2-berblick f-r HTML
In diesem berblick zeigen wir, wie einfach es sein kann, einfache Stylesheets zu entwerfen.
Dazu ben=tigen Sie Grundkenntnisse in HTML (siehe [HTML40]), und Sie sollten die wichtigs-
ten Begriffe aus dem Desktop-Publishing kennen.
Wir beginnen mit einem kleinen HTML-Dokument:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>Bachs Homepage</TITLE>
</HEAD>
<BODY>
<H1>Bachs Homepage</H1>
<P>Johann Sebastian Bach war ein
< 546 > Einf#hrung in CSS2
Page size: 168,00 x 240,00 mm
begnadeter Komponist.
</BODY>
</HTML>
Um die Textfarbe der H1-Elemente auf Blau zu setzen, schreiben Sie die folgende CSS-Regel:
H1 { color: blue }
Eine CSS-Regel besteht aus zwei Hauptteilen: Selektor ('H1') und Deklaration ('color: blue').
Die Deklaration setzt sich aus zwei Teilen zusammen: Eigenschaft ('color') und Wert ('blue').
Obwohl das obige Beispiel nur versucht, eine einzige der f r die Darstellung eines HTML-Do-
kuments ben=tigte Eigenschaft zu steuern, qualifiziert es sich selbst als Stylesheet. Kombiniert
mit anderen Stylesheets (ein grundlegendes Funktionsmerkmal von CSS ist, dass Stylesheets
kombiniert werden k=nnen) legt es die endg ltige Darstellung des Dokuments fest.
Die HTML 4.0-Spezifikation definiert, wie Stylesheet-Regeln f r HTML-Dokumente angegeben
werden k=nnen: entweder innerhalb des HTML-Dokuments oder ber ein externes Stylesheet.
Um das Stylesheet in das Dokument einzuf gen, verwenden Sie das STYLE-Element:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>Bachs Homepage</TITLE>
<STYLE type="text/css">
H1 { color: blue }
</STYLE>
</HEAD>
<BODY>
<H1>Bachs Homepage</H1>
<P>Johann Sebastian Bach war
ein begnadeter Komponist.
</BODY>
Cascading Style Sheets, Level 2
</HTML>
Einer maximalen Flexibilit@t halber empfehlen wir Autoren, externe Stylesheets zu verwenden;
diese k=nnen ver@ndert werden, ohne dass das HTML-Quelldokument ver@ndert werden
muss, und sie k=nnen zudem von mehreren Dokumenten gemeinsam genutzt werden. F r die
Verkn pfung mit einem externen Stylesheet verwenden Sie das LINK-Element:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>Bachs Homepage</TITLE>
<LINK rel="stylesheet" href="[Link]"
type="text/css">
</HEAD>
<BODY>
<H1>Bachs Homepage</H1>
<P>Johann Sebastian Bach war
ein begnadeter Komponist.
</BODY>
</HTML>
Ein kurzer CSS2-berblick f#r HTML < 547 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Das LINK-Element gibt Folgendes an:
·· den Typ des Links: zu einem "Stylesheet".
die Position des Stylesheets: ber das Attribut 'href'.
· den Typ des zu verkn pfenden Stylesheets: "text/css".
Um die enge Beziehung zwischen einem Stylesheet und der strukturierten Auszeichnungspra-
che zu zeigen, verwenden wir in diesem berblick ebenfalls das STYLE-Element. Jetzt f gen wir
mehr Farben ein:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>Bachs Homepage</TITLE>
<STYLE type="text/css">
BODY { color: red }
H1 { color: blue }
</STYLE>
</HEAD>
<BODY>
<H1>Bachs Homepage</H1>
<P>Johann Sebastian Bach war
ein begnadeter Komponist. </BODY>
</HTML>
Jetzt enth@lt das Stylesheet zwei Regeln: die erste setzt die Farbe des BODY-Elements auf 'red',
w@hrend die zweite die Farbe des H1-Elements auf 'blue' setzt. Weil f r das P-Element kein
Farbwert angegeben wurde, erbt es die Farbe von seinem bergeordneten Element, BODY.
Das H1-Element ist ebenfalls ein untergeordnetes Element von BODY, aber die zweite Regel
berschreibt den geerbten Wert. In CSS gibt es h@ufig solche Konflikte zwischen unterschiedli-
chen Werten, und diese Spezifikation beschreibt, wie sie aufgel=st werden.
CSS2 unterst tzt mehr als 100 verschiedene Eigenschaften, unter anderem 'color'. Jetzt
Cascading Style Sheets, Level 2
betrachten wir einige der anderen:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>Bachs Homepage</TITLE>
<STYLE type="text/css">
BODY {
font-family: "Gill Sans", sans-serif;
font-size: 12pt;
margin: 3em;
}
</STYLE>
</HEAD>
<BODY>
<H1>Bachs Homepage</H1>
<P>Johann Sebastian Bach
war ein begnadeter Komponist.
</BODY>
</HTML>
< 548 > Einf#hrung in CSS2
Page size: 168,00 x 240,00 mm
Als Erstes bemerken Sie, dass mehrere Deklarationen innerhalb eines Blocks gruppiert sind,
der in geschweifte Klammern ({...}) eingeschlossen ist, und dass diese Deklarationen durch
Semikolons voneinander getrennt sind. Auch der letzten Deklaration kann ein Semikolon fol-
gen.
Die erste Deklaration des BODY-Elements setzt die Schriftfamilie auf „Gill Sans“. Falls diese
Schrift nicht verf gbar ist, verwendet das Benutzerprogramm (h@ufig auch als „Browser“
bezeichnet) die Schriftfamilie 'sans-serif', eine der f nf abstrakten Schriftfamilien, die alle Benut-
zerprogramme kennen. Untergeordnete Elemente von BODY erben den Wert der Eigenschaft
'font-family'.
Anmerkung der bersetzer: Schriften im Web sind keine einfache Sache. Sie
k=nnen sich nicht darauf verlassen, dass auf dem Computer, auf dem eine Webseite
angezeigt wird, genau die Schrift vorhanden ist, die Sie angeben. Auch die Namen von
Schriften k=nnen variieren. Deshalb ist unbedingt zu empfehlen, mehrere alternative
Schriften anzugeben und zuletzt immer einen der gezeigten abstrakten Namen zu benut-
zen. Im gezeigten Beispiel k=nnte es sein, dass bei einem Leser nicht Gill Sans verwen-
det wird (weil sie nicht vorhanden ist), sondern Helvetica oder Arial (beides sind seri-
fenlose (sans serif) Schriften).
Die zweite Deklaration setzt die Schriftgr=ße des BODY-Elements auf 12 Punkte. Die Einheit
„Punkt“ wird im Schriftsatz h@ufig verwendet, um Schriftgr=ßen und andere L@ngenwerte anzu-
geben. Es handelt sich dabei um ein Beispiel f r eine absolute Einheit, die nicht relativ zur
Umgebung skaliert wird.
Die dritte Deklaration verwendet eine relative Einheit, die in Hinblick auf ihre Umgebung ska-
liert wird. Die Einheit „em“ bezieht sich auf die Schriftgr=ße des Elements. In diesem Fall sind
die R@nder um das BODY-Element dreimal breiter als die Schriftgr=ße.
Cascading Style Sheets, Level 2
2.2 Ein kurzer CSS2-berblick f-r XML
CSS kann f r beliebige strukturierte Dokumentformate verwendet werden, beispielsweise in
Anwendungen von XML (eXtensible Markup Language, [XML10]). Tats@chlich ist XML mehr
von Stylesheets abh@ngig als HTML, weil Autoren ihre eigenen Elemente kreieren k=nnen, von
denen die Benutzerprogramme nicht automatisch wissen, wie sie anzuzeigen sind.
Nachfolgend sehen Sie einen einfachen XML-Ausschnitt:
<?xml version="1.0" encoding="iso-8859-1"?>
<ARTICLE>
<HEADLINE>Friedrich der Große trifft Bach</HEADLINE>
<AUTHOR>Johann Nikolaus Forkel</AUTHOR>
<PARA>
Eines Abends, als er gerade seine
<INSTRUMENT>Fl^te</INSTRUMENT> vorbereitete
und seine Musiker versammelt waren, brachte
ihm ein Offizier eine Liste aller angekommenen
Fremden.
</PARA>
</ARTICLE>
Ein kurzer CSS2-berblick f#r XML < 549 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Um diesen Ausschnitt als Dokument anzuzeigen, m ssen wir zuerst deklarieren, welche Ele-
mente inzeilig sind (das heißt, es werden keine Leerzeilen eingef gt) und welche sich auf Block-
ebene befinden (das heißt, es werden Leerzeilen zwischen ihnen eingef gt).
INSTRUMENT { display: inline }
ARTICLE, HEADLINE, AUTHOR, PARA { display: block }
Die erste Regel deklariert INSTRUMENT als inline, und die zweite Regel, die eine Liste durch
Kommas voneinander getrennten Selektoren angibt, deklariert alle anderen Elemente als auf
Blockebene befindlich.
Ein Vorschlag f r die Verkn pfung eines Stylesheets mit einem XML-Dokument ist die Verwen-
dung einer Verarbeitungsanweisung:
<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet type="text/css" href="[Link]"?>
<ARTICLE>
<HEADLINE>Friedrich der Große trifft Bach</HEADLINE>
<AUTHOR>Johann Nikolaus Forkel</AUTHOR>
<PARA>
Eines Abends, als er gerade seine
<INSTRUMENT>Fl^te</INSTRUMENT> vorbereitete
und seine Musiker versammelt waren, brachte ihm ein
Offizier eine Liste aller angekommenen Fremden.
</PARA>
</ARTICLE>
Ein visuelles Benutzerprogramm k=nnte das obige Beispiel wie folgt formatieren:
Cascading Style Sheets, Level 2
Beachten Sie, dass das Wort „Fl=te„ innerhalb des Absatzes bleibt, weil es sich dabei um den
Inhalt des inzeiligen Elements INSTRUMENT handelt.
Dennoch ist der Text immer noch nicht so formatiert, wie Sie das erwarten w rden. Beispiels-
weise sollte die Schriftgr=ße f r die berschrift gr=ßer sein als f r den restlichen Text, und
man k=nnte den Namen des Autors kursiv darstellen:
INSTRUMENT { display: inline }
ARTICLE, HEADLINE, AUTHOR, PARA { display: block }
HEADLINE { font-size: 1.3em }
AUTHOR { font-style: italic }
ARTICLE, HEADLINE, AUTHOR, PARA { margin: 0.5em }
< 550 > Einf#hrung in CSS2
Page size: 168,00 x 240,00 mm
Ein visuelles Benutzerprogramm k=nnte das obige Beispiel wie folgt formatieren:
Durch zus@tzliche Regeln, die Sie dem Stylesheet hinzuf gen, k=nnen Sie die Darstellung des
Dokuments weiter verbessern.
Anmerkung der bersetzer: F r die deutsche Fassung dieses Textes wurde das
obige Beispiel wie folgt behandelt: Offensichtlich wurde der Text ins Deutsche ber-
setzt. Da das Resultat Umlaute sowie das ß enth@lt, mussten diese Zeichen im XML-Do-
kument in geeigneter Weise behandelt werden. Dies w@re durch Deklaration entspre-
chender Zeichen-Entities m=glich gewesen. Wir haben uns hier jedoch daf r entschie-
den, die Zeichen direkt einzutippen, die XML-Datei in der Zeichenkodierung
ISO-8859-1 abzuspeichern und diese Kodierung in der XML-Deklaration (erste Zeile)
anzugeben. Das so enstandene Beispiel wurde im Mozilla 1.1 ausprobiert. Das Ergebnis
sehen Sie in den Abbildungen.
Cascading Style Sheets, Level 2
2.3 Das CSS2-Verarbeitungsmodell
Anmerkung der bersetzer: Beim ersten Lesen der Spezifikation und, wenn es
darum geht, CSS nur anzuwenden, kann dieser Abschnitt getrost bersprungen werden.
Dieser Abschnitt stellt ein m=gliches Modell vor, wie Benutzerprogramme funktionieren, die
CSS unterst tzen. Dabei handelt es sich nur um ein konzeptuelles Modell; reale Implementie-
rungen k=nnen davon abweichen.
In diesem Modell verarbeitet ein Benutzerprogramm eine Quelle, indem es die folgenden
Schritte durchl@uft:
1. Parsing des Quelldokuments und Anlegen eines Dokumentbaums.
2. Identifizieren des Ziel-Medientyps.
Das CSS2-Verarbeitungsmodell < 551 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
3. Laden aller dem Dokument zugeordneten Stylesheets, die f r den Ziel-Medientyp angege-
ben sind.
4. Vorbereitung jedes Elements des Dokumentbaums, indem jeder Eigenschaft, die auf den
Ziel-Medientyp anzuwenden ist, ein einziger Wert zugewiesen wird. Eigenschaften werden
entsprechend den im Abschnitt ber Kaskaden und Vererbung beschriebenen Mechanis-
men Werte zugewiesen.
Die Berechnung von Werten ist teilweise von dem f r den Ziel-Medientyp geeigneten For-
matierungsalgorithmus abh@ngig. Ist das Zielmedium beispielsweise der Bildschirm, wenden
Benutzerprogramme das visuelle Formatierungsmodell an. Handelt es sich bei dem Zielme-
dium um eine gedruckte Seite, wenden Benutzerprogramme das Seitenmodell an. Handelt
es sich bei dem Zielmedium um ein akustisches Darstellungsger@t (z. B. Sprachsynthesizer),
wenden Benutzerprogramme das akustische Darstellungsmodell an.
5. Aus dem vorbereiteten Dokumentbaum wird eine Formatierungsstruktur erzeugt. H@ufig
erinnert die Formatierungsstruktur stark an den Dokumentbaum, sie kann sich aber auch
wesentlich davon unterscheiden, insbesondere, wenn Autoren Pseudo-Elemente und
erzeugten Inhalt verwenden. Erstens muss die Formatierungsstruktur berhaupt keine
Baumform aufweisen – welche Form die Struktur hat, ist von der Implementierung abh@n-
gig. Zweitens kann die Formatierungsstruktur mehr oder weniger Information enthalten als
der Dokumentbaum. Hat beispielsweise ein Element im Dokumentbaum den Wert 'none'
f r die 'display'-Eigenschaft, erzeugt dieses Element nichts in der Formatierungsstruktur. Ein
Listenelement hingegen kann in der Formatierungsstruktur mehr Informationen erzeugen:
den Inhalt des Listenelements und die Listenstilinformation (z. B. ein Bild von einem Markie-
rungspunkt).
Beachten Sie, dass das CSS-Benutzerprogramm den Dokumentbaum w@hrend dieser Phase
nicht ver@ndert. Insbesondere wird der durch Stylesheets erzeugte Inhalt nicht an den
Dokumentsprachprozessor zur ckgemeldet (z. B. f r ein erneutes Parsing).
6. bertragen der Formatierungsstruktur an das Zielmedium (z. B. Ausdrucken der Ergebnis-
se, Anzeige auf dem Bildschirm, sprachliche Darstellung usw.).
Cascading Style Sheets, Level 2
Schritt 1 liegt außerhalb des G ltigkeitsbereichs dieser Spezifikation (siehe z. B. [DOM]).
Die Schritte 2 bis 5 werden in dieser Spezifikation behandelt.
Schritt 6 liegt außerhalb des G ltigkeitsbereichs dieser Spezifikation.
2.3.1 Die [Link]
Der Begriff Zeichenfl,che (Canvas) beschreibt f r alle Medien den „Bereich, wo die Formatie-
rungsstruktur dargestellt wird“. Die Zeichenfl@che ist f r jede Dimension des Raums unendlich,
aber die Darstellung erfolgt normalerweise innerhalb eines endlichen Bereichs der Zeichenfl@-
che, der dem Zielmedium entsprechend durch das Benutzerprogramm eingerichtet wird. Bei-
spielsweise geben Benutzerprogramme, die etwas auf einem Bildschirm darstellen, eine Min-
destbreite vor und w@hlen eine Ausgangsbreite, die auf den Maßen des Viewports basiert.
Benutzerprogramme, die etwas auf einer gedruckten Seite anzeigen, geben Beschr@nkungen f r
Breite und H=he vor. Akustische Benutzerprogramme k=nnen Beschr@nkungen im Audioraum
vorgeben, nicht aber hinsichtlich der Zeit.
< 552 > Einf#hrung in CSS2
Page size: 168,00 x 240,00 mm
2.3.2 CSS2-Adressierungsmodell
CSS2-Selektoren und Eigenschaften erlauben, dass sich Stylesheets auf die folgenden Teile eines
Dokuments oder Benutzerprogramms beziehen:
· Elemente im Dokumentbaum und bestimmte Beziehungen zwischen ihnen (siehe Abschnitt
ber Selektoren).
· Attribute von Elementen im Dokumentbaum sowie Werte dieser Attribute (siehe
Abschnitt ber Attributselektoren).
·· Einige Teile des Elementinhalts (siehe Pseudo-Elemente :first-line und :first-letter).
Elemente des Dokumentbaums, wenn sie sich in einem bestimmten Status befinden (siehe
Abschnitt ber Pseudo-Klassen).
·· Einige Aspekte der Zeichenfl@che, auf der das Dokument dargestellt wird.
Einige Systeminformationen (siehe den Abschnitt ber die Benutzeroberfl@che).
2.4 CSS-Entwurfskonzepte
CSS2 basiert wie auch CSS1 auf bestimmten Entwurfsgrundlagen:
· [Link]- und [Link].t. CSS2-Benutzerprogramme verstehen CSS1-
Stylesheets. CSS1–Benutzerprogramme k=nnen CSS2-Stylesheets lesen und verwerfen alle
Teile, die sie nicht verstehen. Außerdem k=nnen Benutzerprogramme ohne CSS-Unterst t-
zung Stil-erweiterte Dokumente anzeigen. Nat rlich k=nnen die durch CSS erm=glichten
stilistischen Erweiterungen nicht dargestellt werden, aber der gesamte Inhalt wird ange-
zeigt.
Anmerkung der bersetzer: Dieser Punkt ist f r HTML-Dokumente uneinge-
schr@nkt richtig. Der Grund daf r ist, dass ein Browser HTML grunds@tzlich darstellen
kann. Das Stylesheet kann diese Vorgaben ver@ndern. Bei der Anwendung von CSS auf
Cascading Style Sheets, Level 2
XML-Dokumente sieht es anders aus: In diesem Fall gibt es keine „normale“ Darstellung
ohne Stylesheet.
· [Link] strukturierter Dokumente. Stylesheets erg@nzen strukturierte Doku-
mente (z. B. HTML- und XML-Applikationen) und stellen daf r stilistische Informationen f r
den mit Markup gekennzeichneten Text bereit. Es sollte ganz einfach sein, das Stylesheet zu
@ndern, und zwar mit wenig oder ohne Einfluss auf das Markup.
· [Link] von Hersteller, Plattform und Ger.t. Stylesheets er=ffnen die M=g-
lichkeit, dass Dokumente unabh@ngig vom Hersteller, von der Plattform und vom Ger@t
werden. Stylesheets als solche sind ebenfalls unabh@ngig von Hersteller und Plattform, aber
CSS2 erm=glicht es Ihnen, ein Stylesheet f r eine bestimmte Gruppe von Ger@ten (z. B.
Drucker) anzulegen.
· Wartbarkeit. Webmaster k=nnen die Wartbarkeit ihrer Site verbessern und ein konsis-
tentes Look&Feel f r eine gesamte Site schaffen, indem sie von Dokumenten aus auf Style-
sheets verweisen. Ondert sich beispielsweise die Hintergrundfarbe f r ein Unternehmen,
muss nur eine einzige Datei ge@ndert werden.
CSS-Entwurfskonzepte < 553 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
· Einfachheit. CSS2 ist komplexer als CSS1, bleibt aber eine einfache Stilsprache, die vom
Menschen lesbar und schreibbar ist. Die CSS-Eigenschaften werden so weit m=glich von-
einander unabh@ngig verwaltet, und es gibt im Allgemeinen jeweils nur eine einzige Metho-
de, um einen bestimmten Effekt zu erzielen.
· Netzwerkleistung. CSS unterst tzt kompakte Codierungen f r die Darstellung von
Inhalt. Verglichen mit Bildern oder Audiodateien, die von Autoren oft verwendet werden,
um bestimmte Darstellungseffekte zu erzielen, verringern Stylesheets h@ufig die Inhaltsgr=-
ße. Dar ber hinaus m ssen weniger Netzwerkverbindungen ge=ffnet werden, wodurch die
Netzwerkleistung weiter gesteigert wird.
· Flexibilit.t. CSS kann auf mehrere Arten auf Inhalt angewendet werden. Das Schl ssel-
konzept ist es, Stilinformationen zu kaskadieren, die im Standard-Stylesheet (des Benutzer-
programms), in Benutzer-Stylesheets, in verkn pften Stylesheets, im Dokumentkopf und in
Attributen f r die Elemente, die den Dokumentrumpf bilden, enthalten sind.
· Reichhaltigkeit. Den Autoren steht eine umfassende Menge an Darstellungseffekten zur
Verf gung, die die Reichhaltigkeit des Web als Ausdrucksmedium vergr=ßern. Die Designer
haben lange auf die Funktionalit@t gewartet, die man h@ufig im Desktop-Publishing und in
Diashow-Applikationen findet. Einige der geforderten Darstellungseffekte stehen in Konflikt
mit der Ger@teunabh@ngigkeit, aber CSS2 ist auf dem besten Weg, die Anforderungen der
Designer zu erf llen.
· Alternative Sprachbindungen. Die Menge der in dieser Spezifikation beschriebenen
CSS-Eigenschaften bildet ein konsistentes Formatierungsmodell f r visuelle und akustische
Darstellungen. Der Zugriff auf dieses Formatierungsmodell kann ber die Sprache CSS
erfolgen, aber es sind auch Bindungen zu anderen Sprachen m=glich. Beispielsweise k=nnte
ein JavaScript-Programm den Wert der 'color'-Eigenschaft eines bestimmten Elements
@ndern.
Anmerkung der bersetzer: Dieser Punkt beschreibt, was sich hinter dem
Cascading Style Sheets, Level 2
Schlagwort „Dynamic HTML“ verbirgt: HTML, CSS und JavaScript. Mit JavaScript lassen
sich z. B. einzelne Seitenelemente, die per CSS positioniert wurden, verschieben.
· [Link]. Einige Funktionsmerkmale von CSS bieten behinderten Benutzern einen
verbesserten Zugriff auf das Web:
· Eigenschaften zur Steuerung der Schriftdarstellung erlauben den Autoren, Bitmap-Textbil-
der zu vermeiden, die z. B. f r Blinde nicht zug@nglich sind.
· Positionierungseigenschaften erlauben Autoren, Markup-Tricks zu vermeiden (z. B. unsicht-
bare Bilder), um ein Layout zu erzwingen.
· Die Semantik von !important-Regeln bedeutet, dass Benutzer mit bestimmten Anforderun-
gen an die Darstellung die Stylesheets des Autors berschreiben k=nnen.
· Der neue 'inherit'-Wert f r alle Eigenschaften verbessert die Allgemeinheit der Kaskadie-
rung und erlaubt eine einfachere und konsistentere Einstellung der Formatierung.
· Eine verbesserte Medienunterst tzung, unter anderem Mediengruppen, Braille und TTY-
Medientypen, erlaubt Benutzern und Autoren, Seiten auf diese Ger@te zuzuschneiden.
· Akustische Eigenschaften bieten Kontrolle ber Sprach- und Audioausgabe.
< 554 > Einf#hrung in CSS2
Page size: 168,00 x 240,00 mm
· Die Attributselektoren, die 'attr()'-Funktion und die 'content'-Eigenschaft bieten Zugriff auf
alternativen Inhalt.
· Z@hler und Abschnitt/Absatz-Nummerierung k=nnen die Navigation im Dokument verbes-
sern und Einr ckungen ersparen (wichtig f r Braille-Ger@te). Die Eigenschaften 'word-spa-
cing' und 'text-independent' vermeiden dar ber hinaus den Bedarf an zus@tzlichem Leer-
raum im Dokument.
Hinweis: Weitere Informationen zum Entwurf zug@nglicher Dokumente mit CSS und HTML
finden Sie in [WAI-PAGEAUTH]. n
3 Konformit.t: Anforderungen und
Empfehlungen
3.1 Definitionen
In diesem Abschnitt beginnen wir mit der formalen Spezifikation von CSS. Wir beginnen mit
einer Begriffskl@rung zwischen Autoren, Benutzern und Implementierern.
Die Schl sselw=rter „M SSEN“, „D RFEN NICHT“, „GEFORDERT“, „SOLLEN“, „SOLLEN
NICHT“, „SOLLTEN“, „SOLLTEN NICHT“, „EMPFOHLEN“, „D RFEN“ und „OPTIONAL“
in diesem Dokument sollten, wie in RFC 2119 beschrieben, interpretiert werden (siehe
[RFC2119]). Der Lesbarkeit halber erscheinen diese W=rter in dieser Spezifikation jedoch
nicht immer in Großbuchstaben.
Manchmal empfiehlt diese Spezifikation eine sinnvolle Vorgehensweise f r Autoren und Benut-
zerprogramme. Diese Empfehlungen sind nicht normativ, und die Konformit@t zu dieser Spezifi-
Cascading Style Sheets, Level 2
kation ist nicht davon abh@ngig, dass sie befolgt werden. Diese Empfehlungen enthalten den
Ausdruck „Wir empfehlen...“, „Diese Spezifikation empfiehlt...“ oder einen @hnlichen Wortlaut.
Stylesheet
Mehrere Anweisungen, die die Darstellung eines Dokuments spezifizieren.
Stylesheets k=nnen unterschiedliche Urspr nge haben: Autor, Benutzer und Benutzerpro-
gramm. Das Zusammenspiel dieser Quellen ist im Abschnitt ber Kaskaden und Vererbung
beschrieben.
G-ltiges Stylesheet
Die G ltigkeit eines Stylesheets ist von dem daf r verwendeten CSS-Level abh@ngig. Alle
g ltigen CSS1-Stylesheets sind auch g ltige CSS2-Stylesheets. Bestimmte Mnderungen gegen-
ber CSS1 f hren jedoch dazu, dass einige CSS1-Stylesheets in CSS2 eine etwas andere
Semantik haben.
Ein g ltiges CSS2-Stylesheet muss entsprechend der CSS2-Grammatik geschrieben sein.
Dar ber hinaus darf es nur at-Regeln, Eigenschaftsnamen und Eigenschaftswerte enthalten,
die in dieser Spezifikation definiert wurden. Nicht erlaubte (ung ltige) at-Regeln, Eigen-
schaftsnamen oder Eigenschaftswerte sind solche, die nicht g ltig sind.
Konformit,t: Anforderungen und Empfehlungen < 555 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Quelldokument
Das Dokument, auf das ein oder mehrere Stylesheets verweisen. Es ist in irgendeiner Spra-
che codiert, die das Dokument als Elementbaum darstellt. Jedes Element besteht aus einem
Namen, der den Typ des Elements identifiziert, optional mehreren Attributen und einem
(m=glicherweise leeren) Inhalt.
Dokumentsprache
Die Codiersprache des Quelldokuments (z. B. HTML oder eine XML-Applikation).
Element
(Ein SGML-Begriff, siehe [ISO8879].) Elemente sind die prim@ren syntaktischen Kons-
trukte der Dokumentsprache. Die meisten CSS-Stylesheet-Regeln verwenden die Namen
dieser Elemente (wie beispielsweise „P“, „TABLE“ und „OL“ f r HTML), um Darstellungs-
informationen f r sie anzugeben.
Ersetztes Element
Ein Element, f r das der CSS-Formatierer nur dessen eigene Gr=ße kennt. In HTML sind
IMG-, INPUT-, TEXTAREA-, SELECT- und OBJECT-Elemente Beispiele f r ersetzte Ele-
mente. Beispielsweise wird der Inhalt des IMG-Elements h@ufig durch das Bild ersetzt, das
im "src"-Attribut angegeben ist. CSS definiert nicht, wie die eigenen Gr=ßen ermittelt wer-
den.
Eigene GrUße
Die Breite und die H=he, wie sie durch das eigentliche Element definiert sind, nicht wie sie
durch das Umfeld vorgegeben werden. In CSS2 wird vorausgesetzt, dass alle ersetzten Ele-
mente – und nur ersetzte Elemente – eigene Gr=ßen besitzen.
Attribut
Ein Wert, der einem Element zugeordnet wird, bestehend aus einem Namen und einem
zugeordneten (Text-)Wert.
Inhalt
Der Inhalt eines Elements im Quelldokument. Nicht alle Elemente haben Inhalt; in diesem
Fall werden sie leer genannt. Der Inhalt eines Elements kann Text enthalten und es kann
Cascading Style Sheets, Level 2
eine Reihe von Unterelementen enthalten; in diesem Fall wird das Element Elternelement
dieser Unterelemente genannt.
Dargestellter Inhalt
Der Inhalt eines Elements, nachdem die entsprechenden Stylesheets f r seine Darstellung
darauf angewendet wurden. Der dargestellte Inhalt eines ersetzten Elements kommt von
außerhalb des Quelldokuments. Dargestellter Inhalt kann auch alternativer Text f r ein Ele-
ment sein (z. B. der Wert des "alt"-Attributs in HTML) und Dinge enthalten, die implizit
oder explizit durch das Stylesheet eingef gt wurden, wie beispielsweise Markierungen,
Nummerierungen usw.
Dokumentbaum
Der Baum der im Quelldokument codierten Elemente. Jedes Element in diesem Baum hat
genau ein bergeordnetes Element, mit Ausnahme des Wurzel-Elements (root), das kei-
nes hat.
Untergeordnetes Element („Kind“)
Ein Element A wird als untergeordnetes Element oder Kind von Element B bezeichnet, dann
und nur dann, wenn B das bergeordnete Element („Elternelement“) von A ist.
< 556 > Konformit,t: Anforderungen und Empfehlungen
Page size: 168,00 x 240,00 mm
Nachkomme
Ein Element A wird als Nachkomme von Element B bezeichnet, wenn (1) A ein untergeord-
netes Element von B ist, oder (2) A das untergeordnete Element eines Elements C ist, das
Nachkomme von B ist.
Vorfahre
Ein Element A wird als Vorfahre von Element B bezeichnet, dann und nur dann, wenn B ein
Nachkomme von A ist.
Gleichrangiges oder Geschwisterelement
Ein Element A wird als gleichrangiges oder Geschwisterelement eines Elements B bezeich-
net, dann und nur dann, wenn B und A dasselbe bergeordnete Element haben. Element A
ist ein vorhergehendes gleichrangiges Element, wenn es im Elementbaum vor B steht. Ele-
ment B ist ein nachfolgendes gleichrangiges Element, wenn es im Elementbaum nach A
steht.
Vorhergehendes Element
Ein Element A wird als vorhergehendes Element eines Elements B bezeichnet, dann und nur
dann, wenn (1) A ein Vorfahre von B ist, oder (2) A ein vorhergehendes gleichrangiges Ele-
ment von B ist.
Nachfolgendes Element
Ein Element A wird als nachfolgendes Element eines Elements B bezeichnet, dann und nur
dann, wenn B ein vorhergehendes Element von A ist.
Autor
Ein Autor ist eine Person, die Dokumente und zugeh=rige Stylesheets schreibt. Ein Auto-
renwerkzeug erzeugt Dokumente und zugeordnete Stylesheets.
Benutzer
Ein Benutzer ist eine Person, die mit einem Benutzerprogramm arbeitet, um ein Dokument
und das ihm zugeordnete Stylesheet anzusehen, anzuh=ren oder es anderweitig zu nutzen.
Der Benutzer kann ein pers=nliches Stylesheet bereitstellen, das seine pers=nlichen Vorlie-
ben codiert.
Cascading Style Sheets, Level 2
Benutzerprogramm (User Agent, UA)
Ein Benutzerprogramm ist ein beliebiges Programm, das ein in der Dokumentsprache
geschriebenes Dokument interpretiert und ein zugeordnetes Stylesheet gem@ß den Vor-
gaben dieser Spezifikation darauf anwendet. Ein Benutzerprogramm kann ein Dokument
anzeigen, es laut vorlesen, seinen Ausdruck veranlassen, es in ein anderes Format umwan-
deln usw.
Anmerkung der bersetzer: Zu den Begriffen „User Agent“ und „Benutzerpro-
gramm“ beachten Sie bitte die Anmerkung im ersten Kapitel.
Beispiel
Nachfolgend sehen Sie ein Beispiel f r ein in HTML codiertes Quelldokument:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<TITLE>Meine Homepage</TITLE>
<BODY>
Definitionen < 557 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<H1>Meine Homepage</H1>
<P>Willkommen auf meiner Homepage. Ich will Ihnen
etwas Uber meine Lieblingskomponisten erz]hlen:
<UL>
<LI> Elvis Costello
<LI> Johannes Brahms
<LI> Georges Brassens
</UL>
</BODY>
</HTML>
Daraus ergibt sich der folgende Baum:
HTML
HEAD BODY
TITLE H1 P UL
LI LI LI
Gem@ß der HTML-Definition werden HEAD-Elemente w@hrend des Parsings abgeleitet und
werden Teil des Dokumentbaums, selbst wenn die HEAD-Tags nicht in der Dokumentquelle
enthalten sind. Analog dazu erkennt der Parser, wo P und LIs enden, obwohl es in der Quelle
keine </P>- und </LI>-Tags gibt.
Anmerkung der bersetzer: Hier ist zu beachten, dass das obige Beispiel und die
Cascading Style Sheets, Level 2
nachfolgende Bemerkung mit XHTML nicht mehr g ltig ist. Als Anwendung von SGML
ist das obige HTML-Beispiel korrekt. Im Gegensatz dazu ist das Weglassen von Tags
(Start-, End-Tags) bei XHTML nicht mehr m=glich. Der Ursache liegt darin, dass XML
als Grundlage von XHTML diese Freiheit nicht mehr erlaubt. Nicht-leere Elemente
m ssen dann immer vollst@ndig (mit Start- und End-Tag) geschrieben werden.
3.2 Konformit.t
Dieser Abschnitt definiert nur die Konformit@t mit der CSS2-Spezifikation. In der Zukunft wird
es m=glicherweise noch andere CSS-Levels geben, f r die es unter Umst@nden erforderlich ist,
dass ein Benutzerprogramm andere Funktionsmerkmale definiert, um Konformit@t zu erzielen.
Im Allgemeinen muss ein Benutzerprogramm, das konform zu dieser Spezifikation arbeiten will,
die folgenden Aspekte ber cksichtigen:
< 558 > Konformit,t: Anforderungen und Empfehlungen
Page size: 168,00 x 240,00 mm
1. Es muss einen oder mehrere der CSS2-Medientypen unterst tzen.
2. Es muss f r jedes Quelldokument versuchen, alle zugeordneten Stylesheets zu laden, die
f r die unterst tzten Medientypen geeignet sind. Falls es nicht alle zugeordneten Style-
sheets laden kann (m=glicherweise aufgrund von Netzwerkfehlern), muss es das Dokument
unter Verwendung der gefundenen Stylesheets anzeigen.
3. Es muss die Stylesheets gem@ß dieser Spezifikation auswerten. Insbesondere muss es alle at-
Regeln, Bl=cke, Deklarationen und Selektoren (siehe CSS2-Grammatik) erkennen. Trifft ein
Benutzerprogramm auf eine Eigenschaft, die f r einen unterst tzten Medientyp angewendet
werden soll, muss es den Wert gem@ß der Eigenschaftsdefinition auswerten. Das bedeutet,
das Benutzerprogramm muss alle g ltigen Werte akzeptieren und Deklarationen mit ung l-
tigen Werten ignorieren. Benutzerprogramme m ssen Regeln ignorieren, die sich auf nicht
unterst tzte Medientypen beziehen.
4. F r jedes Element in einem Dokumentbaum muss es f r jede anwendbare Eigenschaft einen
Wert zuweisen, und zwar gem@ß der Eigenschaftsdefinition und den Regeln von Kaskadie-
rung und Vererbung.
5. Falls das Quelldokument alternative Stylesheets enth@lt (wie beispielsweise durch das
Schl sselwort ‘alternate’ in HTML 4.0 gekennzeichnet, [HTML40]), muss das Benutzer-
programm dem Benutzer erlauben, eines dieser Stylesheets auszuw@hlen, und dann das aus-
gew@hlte anwenden.
Es muss jedoch nicht jeder Benutzerprogramm jeden Punkt beachten:
·· Ein Benutzerprogramm, das Stylesheets eingibt, muss die Punkte 1 – 3 ber cksichtigen.
Von einem Autorenwerkzeug wird nur verlangt gltige Stylesheets auszugeben.
· Ein Benutzerprogramm, das ein Dokument mit einem zugeh=rigen Stylesheet darstellt, muss
die Punkte 1 – 5 ber cksichtigen und das Dokument gem@ß den medienspezifischen Anfor-
derungen darstellen, die in dieser Spezifikation festgelegt werden. Die Werte k=nnen ange-
n@hert werden, wenn das Benutzerprogramm sie ben=tigt.
Wenn ein Benutzerprogramm einen Teil dieser Spezifikation nicht implementieren kann, weil
Cascading Style Sheets, Level 2
beispielsweise ein bestimmtes Ger@t keine entsprechenden Funktionen aufweist (z. B. kann ein
Benutzerprogramm keine Farben auf einem Schwarzweißmonitor oder auf einer Schwarzweiß-
seite darstellen), bedeutet das nicht, dass die Konformit@t verletzt ist.
Diese Spezifikation empfiehlt, dass ein Benutzerprogramm dem Benutzer erlaubt, benutzerde-
finierte Stylesheets anzugeben.
Anmerkung der bersetzer: Aufgrund der letzten Empfehlung sollte Autoren
bewusst sein, dass es – wie im Web blich – keine Garantie daf r gibt, dass ein Doku-
ment so dargestellt wird, wie vom Autor vorgegeben. Der Benutzer kann in der Lage
sein, Stylesheets auszuschalten oder eigene auf das Dokument anzuwenden. Neben
einem eigenen @sthetischen Empfinden kann es ganz rationale Gr nde daf r geben:
Benutzer mit Sehbehinderungen m=chten eventuell große Schriften einstellen, damit
Seiten berhaupt lesbar sind. Ein benutzerorientiertes (kundenorientiertes) CSS-Design
sollte solche F@lle ber cksichtigen.
Konformit,t < 559 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
3.3 Fehlerbedingungen
Im Allgemeinen spezifiziert dieses Dokument keine Verhaltensweisen f r die Fehlerverarbei-
tung durch Benutzerprogramme (z. B. wie sie sich verhalten, wenn sie eine durch eine URI
angegebene Ressource nicht finden).
Die Benutzerprogramme m ssen jedoch den Regeln fr die Verarbeitung von Parsing-Fehlern
gehorchen.
Weil sich die Vorgehensweise der Benutzerprogramme bei der Verarbeitung von Fehlerbedin-
gungen unterscheiden kann, d rfen sich Autoren und Benutzer nicht auf ein bestimmtes Verhal-
ten bei der Fehlerverarbeitung verlassen.
3.4 Der text/css-Inhaltstyp
CSS-Stylesheets, die in separaten Dateien vorliegen, werden als Bytefolge ber das Internet
geschickt, begleitet von Codierungsinformationen (siehe [HTML40], Kapitel 5). Die Struktur
der bertragung, auch als Nachrichteneinheit bezeichnet, ist in RFC 2045 und RFC 2068 defi-
niert (siehe [RFC2045] und [RFC2068]). Eine Nachrichteneinheit mit dem Inhaltstyp ‘text/
css’ stellt ein unabh@ngiges CSS-Dokument dar. Der Inhaltstyp ‘text/css’ wurde in RFC 2318
([RFC2318]) registriert.
4 CSS2-Syntax und grundlegende
Datentypen
4.1 Syntax
Cascading Style Sheets, Level 2
Dieser Abschnitt beschreibt eine Grammatik (sowie vorw,rts-kompatible Parsing-Regeln), die f r
jede CSS-Version g ltig sind (auch f r CSS2). Zuk nftige CSS-Versionen werden dieser Kern-
syntax entsprechen, f hren aber m=glicherweise zus@tzliche syntaktische Einschr@nkungen ein.
Diese Beschreibungen sind normativ. Sie werden erg@nzt durch die normativen Grammatik-
regeln, die Sie in Anhang D finden.
4.1.1 Token-Bildung
Alle CSS-Level – Level 1, Level 2 und alle zuk nftigen Level – verwenden dieselbe Kernsyntax.
Auf diese Weise ist es m=glich, dass ein Benutzerprogramm auch Stylesheets in CSS-Levels
parst (auch wenn er sie nicht vollst@ndig versteht), die noch gar nicht existiert haben, als das
Benutzerprogramm entwickelt wurde. Die Designer k=nnen dieses Funktionsmerkmal nutzen,
um Stylesheets anzulegen, die auch mit @lteren Benutzerprogrammen eingesetzt werden k=n-
nen, w@hrend sie gleichzeitig alle M=glichkeiten der neuesten CSS-Level aussch=pfen.
Auf der lexikalischen Ebene bestehen CSS-Stylesheets aus einer Folge von Token. Diese
Token-Liste f r CSS2 sieht wie im Folgenden gezeigt aus. Die Definitionen verwenden regul@re
Ausdr cke im Stil von Lex. Bytecodes beziehen sich auf ISO 10646 ([ISO10646]). Wie in Lex
legt im Fall von mehreren bereinstimmungen die l@ngste bereinstimmung das Token fest.
< 560 > CSS2-Syntax und grundlegende Datentypen
Page size: 168,00 x 240,00 mm
Anmerkung der bersetzer: Lex ist ein auf Unix-Systemen verbreitetes Werk-
zeug, das dazu dient, Programme zum Parsing einer Sprache zu generieren.
Token Definition
IDENT {ident}
ATKEYWORD @{ident}
STRING {string}
HASH #{name}
NUMBER {num}
PERCENTAGE {num}%
DIMENSION {num}{ident}
URI url\({w} {string} {w}\) | url\ ([!#$%&*-~]| {escape})*{w})
UNICODE-RANGE U\+[0-9-F?]{1,6}(-[0-9A-F]{1,6})?
CDO <!- -
CDC - ->
; ;
{ \{
} \}
( \(
) \)
Cascading Style Sheets, Level 2
[ \[
] \]
S [ \t\r\n\f]+
COMMENT \/\*[^*]*\*+([^/][^*]*\*+)*\/
FUNCTION {ident}\(
INCLUDES ~=
DASHMATCH |=
DELIM Ein beliebiges anderes Zeichen, das in den oben
beschriebenen Regeln nicht verwendet wird, sowie
keine einfachen oder doppelten Anf hrungszeichen.
Syntax < 561 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Die Makros in den geschweiften Klammern ({}) sind wie folgt definiert:
Makro Definition
ident {nmstart}{nmchar}*
name {nmchar}+
nmstart [a-zA-Z_]|{nonascii}|{escape}
nonascii [^\0-\177]
unicode \\[0-9a-f]{1,6}[ \n\r\t\f]?
escape \\[0-9a-f]{1,6}[ \n\r\t\f]?
nmchar [a-zA-Z0-9-_]|{nonascii}|{escape}
num [0-9]+|[0-9]*\.[0-9]+
string {string1}|{string2}
nl \n|\r\n|\r|\f
w [ \t\r\n\f]*
Nachfolgend sehen Sie die Kernsyntax f r CSS. Die folgenden Abschnitte beschreiben, wie sie
zu verwenden ist. Anhang D beschreibt eine einschr@nkendere Grammatik, die n@her an der
CSS Level 2-Sprache ist.
stylesheet : [ CDO | CDC | S | statement ]*;
statement : ruleset | at-rule;
at-rule : ATKEYWORD S* any* [ block | ';' S* ];
block : '{' S* [ any | block | ATKEYWORD S* | ';' ]* '}' S*;
ruleset : selector? '{' S* declaration? [ ';' S* declaration? ]* '}' S*;
selector : any+;
declaration : property ':' S* value;
Cascading Style Sheets, Level 2
property : IDENT S*;
value : [ any | block | ATKEYWORD S* ]+;
any : [ IDENT | NUMBER | PERCENTAGE | DIMENSION | STRING
| DELIM | URI | HASH | UNICODE-RANGE | INCLUDES
| FUNCTION '(' any* ')' | DASHMATCH | '(' any* ')' | '[' any* ']' ]
S*;
In der Grammatik treten (der Lesbarkeit halber) keine COMMENT-Token auf, zwischen den
anderen Token sind jedoch an beliebiger Stelle beliebig viele solcher Token erlaubt.
Das Token S in der obigen Grammatik steht f r Leerraum. In Leerraum k=nnen nur die
Zeichen „Leerzeichen“ (Unicode-Code 32), „Tabulator“ (9), „Line Feed“ (10, Zeilenvor-
schub), „Carriage Return“ (13, Wagenr cklauf) und „Form Feed“ (12, Seitenvorschub)
auftreten. Andere leerzeichen@hnliche Zeichen, wie beispielsweise das „em-Leerzeichen“
(8195) und das „ideographische Leerzeichen“ (12288), sind niemals Teil eines Whitespace.
4.1.2 Schl-sselwUrter
Schl sselw=rter haben die Form von Bezeichnern. Schl sselw=rter d rfen nicht zwischen
Anf hrungszeichen ("..." oder '...') stehen. Damit ist
< 562 > CSS2-Syntax und grundlegende Datentypen
Page size: 168,00 x 240,00 mm
red
ein Schl sselwort,
"red"
dagegen nicht. (Es handelt sich um eine Zeichenkette.) Weitere fehlerhafte Beispiele:
width: "auto";
border: "none";
font-family: "serif";
background: "red";
4.1.3 Zeichen und Groß-/Kleinschreibung
Die folgenden Regeln gelten immer:
· In CSS-Stylesheets wird die Groß-/Kleinschreibung grunds@tzlich nicht ber cksichtigt, außer
in Teilen, die nicht unter der Kontrolle von CSS stehen. Die Groß-/Kleinschreibung von
Werten der HTML-Attribute "id" und "class", von Schriftnamen und URIs liegen außerhalb
des G ltigkeitsbereichs dieser Spezifikation. Beachten Sie insbesondere, dass f r Element-
namen in HTML die Groß-/Kleinschreibung nicht ber cksichtigt wird, in XML dagegen
schon.
Anmerkung der bersetzer: Folglich wird Groß-/Kleinschreibung auch in
XHTML unterschieden.
· In CSS2 d rfen Bezeichner (inklusive Elementnamen, Klassen und IDs in Selektoren) nur die
Zeichen [A-Za-z0-9_] und ISO 10646-Zeichen 161 und h=her enthalten, ebenso wie den
Cascading Style Sheets, Level 2
Trennstrich (-); sie d rfen nicht mit einem Trennstrich oder einer Ziffer beginnen. Außer-
dem d rfen sie gesch tzte Zeichen („escaped characters“) enthalten, ebenso wie beliebige
ISO 10646-Zeichen als numerischen Code (siehe n@chsten Punkt). Beispielsweise k=nnte
der Bezeichner "B&W?" als "B\&W\?" oder "B\26 W\3F"geschrieben werden. Beachten Sie,
dass Unicode Code-zu-Code-@quivalent zu ISO 10646 ist (siehe [UNICODE] und
[ISO10646]).
Anmerkung der bersetzer: Praktisch bedeutet das, dass berall wo „ISO
10646“ steht, auch „UNICODE“ gelesen werden kann.
· In CSS2 kennzeichnet ein Backslash (\) drei Arten von Zeichen-Escapefolgen.
Erstens, innerhalb eines Strings wird ein Backslash gefolgt von einem Neuezeilezeichen
ignoriert (das heißt, der String wird so interpretiert, als enthielte er weder den Backslash
noch das Neuezeilezeichen).
Syntax < 563 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Zweitens, er verwirft die Bedeutung spezieller CSS-Zeichen. Alle Zeichen (außer einer
hexadezimalen Ziffer) k=nnen mit einem Backslash gekennzeichnet („escaped“) werden,
um ihre spezielle Bedeutung aufzuheben. Beispielsweise ist "\"" ein String, der aus einem
doppelten Anf hrungszeichen besteht. Stylesheet-Pr@prozessoren d rfen diese Backslas-
hes nicht aus einem Stylesheet entfernen, weil das die Bedeutung des Stylesheets ver-
@ndern w rde.
Drittens, die Backslash-Escapes erlauben den Autoren, Zeichen zu verwenden, die nicht
ganz einfach in ein Dokument aufgenommen werden k=nnen. In diesem Fall folgen dem
Backslash h=chstens sechs hexadezimale Ziffern (0..9A..F), was f r die ISO 10646-Zeichen
([ISO10646]) mit der jeweiligen Nummer steht. Wenn der hexadezimalen Nummer eine
Ziffer oder ein Buchstabe folgt, muss das Ende der Nummer erkennbar sein. Dazu gibt es
zwei M=glichkeiten:
1. Durch Einf gen eines Leerzeichens (oder eines anderen Leerraum-Zeichens): "\26 B"
("&B")
2. Durch die Angabe von genau 6 hexadezimalen Ziffern: "\000026B" ("&B")
Diese beiden Methoden k=nnen auch kombiniert werden. Hinter einem hexadezimalen
Escape wird nur ein Leerraum-Zeichen ignoriert. Beachten Sie, dass das bedeutet, dass ein
„reales“ Leerzeichen hinter der Escape-Folge mit Escape gekennzeichnet oder verdoppelt
werden muss.
· Backslash-Escapes werden immer als Teil eines Bezeichners oder eines Strings betrachtet
(z. B. ist "\7B" kein Interpunktionszeichen, obwohl "{" das ist, und "\32" darf am Anfang eines
Klassennamens stehen, obwohl "2" nicht dort stehen darf).
4.1.4 Anweisungen
Ein CSS-Stylesheet besteht in jeder CSS-Version aus einer Liste mit Anweisungen (siehe nachfol-
gende Grammatik). Es gibt zwei Arten von Anweisungen: at-Regeln und Regelmengen. Um die
Anweisungen herum darf Whitespace stehen.
Cascading Style Sheets, Level 2
In dieser Spezifikation bedeuten die Ausdr cke „unmittelbar vor“ oder „unmittelbar hinter“,
dass keine Whitespaces oder Kommentare dazwischen stehen.
4.1.5 At-Regeln
At-Regeln beginnen mit einem At-Schlsselwort, einem '@'-Zeichen, unmittelbar gefolgt von
einem Bezeichner (z. B. '@import', '@page').
Eine At-Regel umfasst alles bis und inklusive des n@chsten Semikolons (;) oder dem n@chsten
Block, abh@ngig davon, was zuerst kommt. Ein CSS-Benutzerprogramm, das auf eine nicht
erkannte At-Regel trifft, muss die gesamte At-Regel ignorieren und das Parsing hinter dieser
At-Regel fortsetzen.
CSS2-Benutzerprogramme m ssen jede @import-Regel ignorieren, die innerhalb eines Blocks
steht oder die nicht vor allen anderen Regelmengen steht.
< 564 > CSS2-Syntax und grundlegende Datentypen
Page size: 168,00 x 240,00 mm
Angenommen, ein CSS2-Parser trifft auf das folgende Stylesheet:
@import "[Link]";
H1 { color: blue }
@import "[Link]";
Das zweite '@import' ist gem@ß CSS2 nicht erlaubt. Der CSS2-Parser ignoriert die gesamte At-
Regel, wodurch das Stylesheet letztlich auf Folgendes reduziert wird:
@import "[Link]";
H1 { color: blue }
Im folgenden Beispiel ist die zweite '@import'-Regel ung ltig, weil sie innerhalb eines '@me-
dia'-Blocks steht.
@import "[Link]";
@media print {
@import "[Link]";
BODY { font-size: 10pt }
}
H1 {color: blue }
4.1.6 BlUcke
Ein Block beginnt mit einer =ffnenden geschweiften Klammer ({) und endet mit der zugeh=rigen
schließenden geschweiften Klammer (}). Innerhalb der geschweiften Klammern d rfen beliebige
Zeichen stehen. Klammern (()), eckige Klammern ([ ]) und geschweifte Klammern ({}) m ssen
immer paarweise auftreten und d rfen verschachtelt werden. Einfache (') und doppelte Anf h-
rungszeichen (") m ssen ebenfalls paarweise auftreten, und die Zeichen zwischen ihnen werden
als Zeichenkette („String“) geparst. Die Definition eines Strings finden Sie im Abschnitt ber
Cascading Style Sheets, Level 2
die Tokenbildung, am Anfang dieses Kapitels.
Nachfolgend sehen Sie ein Beispiel f r einen Block. Beachten Sie, dass die schließende
geschweifte Klammer innerhalb der doppelten Anf hrungszeichen nicht zu der =ffnenden
geschweiften Klammer des Blockes geh=rt und dass das zweite einfache Anf hrungszeichen ein
mit Escape gekennzeichnetes Zeichen ist und damit nicht zum ersten einfachen Anf hrungszei-
chen geh=rt:
{ causta: "}" + ({7} * '\'') }
Beachten Sie, dass die obige Regel kein g ltiges CSS2 ist, aber nach der obigen Definition den-
noch einen Block darstellt.
Syntax < 565 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
4.1.7 Regelmengen, DeklarationsblUcke und Selektoren
Eine Regelmenge (auch als „Regel “ bezeichnet) besteht aus einem Selektor gefolgt von einem
Deklarationsblock.
Ein Deklarationsblock (im Folgenden auch als {}-Block bezeichnet) beginnt mit einer =ffnenden
geschweiften Klammer ({) und endet mit einer paarweise dazugeh=rigen schließenden
geschweiften Klammer (}). Zwischen diesen Klammern muss sich eine Liste mit null oder mehr
durch Semikolons (;) voneinander abgetrennten Deklarationen befinden.
Der Selektor besteht aus allem bis (aber nicht inklusive) zu der ersten =ffnenden geschweiften
Klammer ({). Ein Selektor existiert immer in Kombination mit einem {}-Block. Wenn ein Benut-
zerprogramm den Selektor nicht parsen kann (wenn es sich dabei beispielsweise nicht um g lti-
ges CSS2 handelt), muss er den {}-Block ebenfalls ignorieren.
In CSS2 hat das Komma (,) in Selektoren eine spezielle Bedeutung. Weil jedoch nicht bekannt
ist, ob dem Komma in zuk nftigen Versionen von CSS eine andere Bedeutung zuteil wird, sollte
die gesamte Anweisung ignoriert werden, falls sich irgendwo im Selektor ein Fehler befindet,
auch wenn der restliche Selektor CSS2 entsprechend korrekt aussieht.
Beispiel
Weil beispielsweise "&" kein g ltiges Token in einem CSS2-Selektor ist, muss ein
CSS2-Benutzerprogramm die gesamte zweite Zeile ignorieren und darf die Farbe von
H3 nicht auf rot setzen:
H1, H2 {color: green }
H3, H4 & H5 {color: red }
H6 {color: black }
Nachfolgend sehen Sie ein komplexeres Beispiel. Die beiden ersten Paare geschweifter Klam-
mern befinden sich innerhalb einer Zeichenkette und markieren nicht das Ende des Selektors.
Dies ist eine g ltige CSS2-Anweisung.
Cascading Style Sheets, Level 2
P[example="public class foo\
{\
private int x;\
\
foo(int x) {\
this.x = x;\
}\
\
}"] { color: red }
4.1.8 Deklarationen und Eigenschaften
Eine Deklaration ist entweder leer oder besteht aus einer Eigenschaft gefolgt von einem Dop-
pelpunkt (:) gefolgt von einem Wert. Vor und hinter diesen Bestandteilen k=nnen sich beliebige
Leerraum-Zeichen befinden.
Aufgrund der Arbeitsweise von Selektoren k=nnen mehrere Deklarationen f r denselben
Selektor in durch Semikolons (;) voneinander getrennten Gruppen angeordnet werden.
< 566 > CSS2-Syntax und grundlegende Datentypen
Page size: 168,00 x 240,00 mm
Beispiel
Die folgenden Regeln:
H1 { font-weight: bold }
H1 { font-size: 12pt }
H1 { line-height: 14pt }
H1 { font-family: Helvetica }
H1 { font-variant: normal }
H1 { font-style: normal }
sind also @quivalent zu:
H1 {
font-weight: bold;
font-size: 12pt;
line-height: 14pt;
font-family: Helvetica;
font-variant: normal;
font-style: normal
}
Eine Eigenschaft ist ein Bezeichner. Innerhalb des Wertes d rfen beliebige Zeichen auftre-
ten, wobei jedoch Klammern ("()"), eckige Klammern ("[ ]"), geschweifte Klammern ("{}"),
einfache Anf hrungszeichen (') und doppelte Anf hrungszeichen (") nur paarweise auftre-
ten d rfen. Semikolons, die sich nicht innerhalb von Strings befinden, m ssen mit dem
Escape-Zeichen gekennzeichnet werden. Klammern, eckige Klammern und geschweifte
Klammern d rfen verschachtelt werden. Innerhalb der Anf hrungszeichen werden Zei-
chen als String geparst.
Die Syntax von Werten wird f r jede Eigenschaft separat angegeben, aber in jedem Fall werden
Werte aus Bezeichnern, Strings, Zahlen, L@ngen, Prozentwerten, URIs, Farben, Winkeln, Zei-
ten und Frequenzen zusammengesetzt.
Cascading Style Sheets, Level 2
Beispiel
Angenommen, ein CSS2-Parser trifft auf das folgende Stylesheet:
H1 { color: red; font-style: 12pt } /* UngUltiger Wert: 12pt */
P { color: blue; font-vendor: any; /* UngUltige Eigenschaft: font-vendor */
font-variant: small-caps }
EM EM { font-style: normal }
Die zweite Deklaration der ersten Zeile enth@lt den ung ltigen Wert '12pt'. Die zweite Dekla-
ration in der zweiten Zeile enth@lt eine undefinierte Eigenschaft 'font-vendor'. Der CSS2-Parser
ignoriert diese Deklarationen, wodurch er das Stylesheet letztlich auf Folgendes reduziert:
H1 { color: red; }
P { color: blue; font-variant: small-caps }
EM EM { font-style: normal }
Syntax < 567 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Anmerkung der bersetzer: Der Wert '12pt' ist zwar syntaktisch korrekt,
jedoch nicht f r die Eigenschaft 'font-style' g ltig.
4.1.9 Kommentare
Kommentare beginnen mit den Zeichen "/*" und enden mit den Zeichen "*/". Sie k=nnen ber-
all zwischen Token stehen, und ihr Inhalt hat keinerlei Einfluss auf die Darstellung. Kommentare
d rfen nicht verschachtelt werden.
CSS erlaubt an einigen Stellen auch die SGML-Kommentarkennzeichner ("<!- -" und "- ->"), aber
sie kennzeichnen keine CSS-Kommentare. Sie sind erlaubt, damit Formatierungsregeln, die in
einem HTML-Quelldokument (im STYLE-Element) enthalten sind, vor Benutzerprogrammen,
die @lter als HTML 3.2 sind, verborgen werden k=nnen. Weitere Informationen finden Sie in
der HTML 4.0-Spezifikation ([HTML40]).
Anmerkung der bersetzer: Es ist zu beachten, dass <!- -...- -> g ltige SGML-
Kommentare sind – wie oben gesagt –, dass SGML aber eine allgemeinere Form der
Kommentare kennt (f r Fachkundige: - - ... - - innerhalb einer Markup-Deklaration). Es
ist blich, den Inhalt des STYLE-Elements in <!- - und - -> einzuschließen. Diese Form
der Kommentierung ist heute kaum mehr relevant, da praktisch alle g@ngigen Web-
Browser das STYLE-Element kennen und nicht auf die Idee kommen, den Inhalt anzuzei-
gen.
4.2 Regeln f-r die Verarbeitung von Parser-Fehlern
Cascading Style Sheets, Level 2
In einigen F@llen m ssen Benutzerprogramme Teile eines fehlerhaften Stylesheets ignorieren.
Diese Spezifikation definiert ignorieren so, dass das Benutzerprogramm den fehlerhaften Teil
parst (um seinen Anfang und sein Ende zu ermitteln), sich aber ansonsten so verh@lt, als g@be es
ihn nicht.
Um sicherzustellen, dass in der Zukunft neue Eigenschaften und neue Werte f r existierende
Eigenschaften hinzugef gt werden k=nnen, m ssen Benutzerprogramme die folgenden Regeln
beachten, wenn sie auf die nachfolgenden Szenarien treffen:
Unbekannte Eigenschaften
Benutzerprogramme m ssen eine Deklaration mit einer unbekannten Eigenschaft ignorie-
ren. F r das folgende Stylesheet beispielsweise:
H1 { color: red; rotation: 70minutes }
verh@lt sich der Benutzerprogramm genau so, als l@ge das folgende Stylesheet vor:
H1 { color: red }
< 568 > CSS2-Syntax und grundlegende Datentypen
Page size: 168,00 x 240,00 mm
Fehlerhafte Werte
Benutzerprogramme m ssen eine Deklaration mit fehlerhaftem Wert ignorieren. Beispiel:
IMG { float: left } /* korrektes CSS2 */
IMG { float: left here } /* "here" ist kein Wert von 'float' */
IMG { background: "red" } /* SchlUsselw^rter dUrfen in CSS2 nicht in doppelten
AnfUhrungszeichen stehen */
IMG { border-width: 3 } /* fUr L]ngenangaben muss eine Einheit
angegeben werden */
Ein CSS2-Parser w rde die erste Regel ber cksichtigen, den Rest aber ignorieren, als s@he
das Stylesheet wie folgt aus:
IMG { float: left }
IMG { }
IMG { }
IMG { }
Ein Benutzerprogramm, das zu einer zuk nftigen CSS-Spezifikation konform ist, kann m=gli-
cherweise eine oder mehrere der anderen Regeln ebenfalls akzeptieren.
Ung-ltige At-Schl-sselworte
Benutzerprogramme m ssen ein ung ltiges At-Schl sselwort mit allem Folgenden bis und
einschließlich dem n@chsten Semikolon (;) oder Block ({...}) ignorieren – je nach dem, was
zuerst kommt. Betrachten Sie zum Beispiel Folgendes:
@three-dee {
@background-lighting {
azimuth: 30deg;
elevation: 190deg;
}
H1 { color: red }
}
H1 { color: blue }
Cascading Style Sheets, Level 2
Die At-Regel '@three-dee' ist nicht Teil von CSS2. Deshalb wird die gesamte At-Regel
ignoriert (bis zur dritten schließenden geschweiften Klammer inklusive). Ein CSS2-Benut-
zerprogramm ignoriert sie, so dass das Stylesheet letztlich reduziert wird auf:
H1 { color: blue }
4.3 Werte
4.3.1 Integer und reelle Zahlen
Einige Wertetypen k=nnen ganzzahlige Werte aufnehmen (gekennzeichnet durch <integer> ),
oder reelle Zahlenwerte (gekennzeichnet durch <number> ). Reelle Zahlen und ganze Zahlen
werden nur in dezimaler Notation angegeben. Ein <integer> besteht aus einer oder mehreren
Ziffern, „0“ bis „9“. Eine <number> kann ein <integer> sein, oder sie kann null oder mehr Zif-
fern gefolgt von einem Punkt (.) gefolgt von einer oder mehreren Ziffern sein. Sowohl ganzen
als auch reellen Zahlen kann ein „-“ oder ein „+“ vorausgehen, die das Vorzeichen darstellen.
Werte < 569 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Beachten Sie, dass viele Eigenschaften, f r die eine ganze oder eine reelle Zahl als Wert angegeben
werden kann, einen bestimmten Wertebereich vorgeben, h@ufig einen nicht negativen Wert.
4.3.2 [Link]
L@ngen stellen horizontale oder vertikale Maße dar.
Das Format eines L@ngenwertes (in dieser Spezifikation durch <length> gekennzeichnet) ist
ein optionales Vorzeichen ('+' oder '-', wobei '+' den Standardwert darstellt), unmittelbar
gefolgt von einer <number> (mit oder ohne Dezimalpunkt), unmittelbar gefolgt von einem Ein-
heitenbezeichner (z. B. px, deg usw.). Hinter der L@nge '0' ist die Angabe eines Einheitenbe-
zeichners optional.
Anmerkung der bersetzer: In diesen Abschnitt hat sich in mehreren Unter-
abschnitten ein Fehler eingeschlichen, der in den CSS2-Errata wie folgt behandelt wird:
„Mehrere Werte, die in den Unterabschnitten dieses Abschnitts beschrieben werden,
erlauben unkorrekterweise zwei ‚+‘- oder ‚-‘-Zeichen am Anfang. [...] [Mit Bezug auf
<length>:] Da bereits <number> ein ‚+‘- oder ‚-‘-Zeichen erlaubt, bedeutet die obige
Definition [von <length>], dass zwei Zeichen vorkommen k=nnen. Die folgenden Wer-
tetypen erlauben zwei Zeichen, sollten jedoch nur eines erlauben: L@ngen, Prozentwer-
te, Winkel.“
Einige Eigenschaften erlauben die Angabe negativer L@ngenwerte, aber das kann das Formatie-
rungsmodell verkomplizieren, und es kann von der jeweiligen Implementierung abh@ngige
Beschr@nkungen geben. Wenn kein negativer Wert unterst tzt werden kann, sollte er in den
n@chsten Wert umgewandelt werden, der unterst tzt werden kann.
Es gibt zwei Arten L@ngeneinheiten: relative und absolute. Relative L,ngeneinheiten geben eine
L@nge relativ zu einer anderen L@ngeneigenschaft an. Stylesheets, die relative Einheiten verwen-
Cascading Style Sheets, Level 2
den, k=nnen einfacher von einem Medium auf ein anderes skaliert werden (z. B. von einer Bild-
schirmanzeige auf einen Laserdrucker).
Relative Einheiten sind:
·· em : die 'font-size' der betreffenden Schrift
ex : die 'x-height' der betreffenden Schrift.
· px : Pixel, relativ zum Anzeigeger@t
H1 { margin: 0.5em } /* em */
H1 { margin: 1ex } /* ex */
P { font-size: 12px } /* px */
Anmerkung der bersetzer: Dass em und ex relative Einheiten sind, ist offen-
sichtlich, da ihre Gr=ße von der aktuellen Schrift abh@ngt. Sie stellen also gute M=glich-
keiten zur Verf gung, den Benutzer die Gr=ße w@hlen zu lassen ( ber die Schriftgr=ße)
und andere Werte (z. B. R@nder) davon abh@ngig zu machen. Im Gegensatz dazu ist ein
Pixel im allgemeinen Verst@ndnis keine relative Gr=ße. Im Folgenden wird beschrieben,
< 570 > CSS2-Syntax und grundlegende Datentypen
Page size: 168,00 x 240,00 mm
was es damit auf sich hat. Ob die g@ngigen Ausgabeger@te ein Pixel als relative Gr=ße
ansehen, darf jedoch zumindest bezweifelt werden. Aus praktischer Sicht sind deshalb
em und ex zu empfehlen.
Die Einheit 'em' ist gleich dem berechneten Wert der Eigenschaft 'font-size' des Elements, auf
das sie angewendet wird. Die Ausnahme ist, wenn 'em' im Wert der Eigenschaft 'font-size'
selbst vorkommt, dann bezieht es sich auf die Schriftgr=ße des bergeordneten Elements. Sie
kann f r vertikale oder horizontale Maße verwendet werden. (Diese Einheit wird in typographi-
schen Texten manchmal auch als die „Geviert-Breite“ bezeichnet.)
Die Einheit 'ex' ist durch die 'x-height' der Schrift definiert. Die x-H=he wird so bezeichnet,
weil sie h@ufig gleich der H=he des kleinen „x“ ist. 'ex' ist jedoch selbst f r Schriften definiert, in
denen kein „x“ enthalten ist.
Beispiel
Die Regel
H1 { line-height: 1.2em }
bedeutet, dass die Zeilenh=he von H1-Elementen 20% gr=ßer als die Schriftgr=ße von H1-Ele-
menten ist. Andererseits bedeutet
H1 { font-size: 1.2em }
dass die Schriftgr=ße von H1-Elementen um 20% gr=ßer als die von H1-Elementen geerbte
Schriftgr=ße ist.
Wenn 'em' und 'ex' f r die Wurzel (Root) des Dokumentbaums (z. B. "HTML" in HTML) ange-
geben werden, beziehen sie sich auf den Ausgangswert der Eigenschaft.
Cascading Style Sheets, Level 2
Pixeleinheiten sind relativ zur Aufl=sung des Anzeigeger@ts, wobei es sich gr=ßtenteils um eine
Bildschirmanzeige handelt. Wenn die Pixeldichte des Ausgabeger@ts sich stark von der eines typi-
schen Computerbildschirms unterscheidet, sollte das Benutzerprogramm die Pixelwerte neu ska-
lieren. Es wird empfohlen, dass das Referenzpixel der Sichtwinkel eines Pixels auf einem Ger@t mit
einer Pixeldichte von 90dpi und einem Abstand vom Leser von einer Arml@nge ist. F r eine Arm-
l@nge von beispielsweise 70 cm w@re der Sichtwinkel damit etwa 0,0227 Grad.
F r das Lesen in Arml@ngenabstand entspricht 1px also etwa 0,28 mm (1/90 Zoll). Beim Ausdruck
auf einem Laserdrucker, der zum Lesen bei etwas weniger als Arml@nge vorgesehen ist (55 cm),
betr@gt 1px etwa 0,21 mm. Auf einem 300dpi-Drucker („dots per inch“, Punkte pro Zoll) kann
daf r auf 3 Punkte (0,25mm) aufgerundet werden; auf einem 600dpi-Drucker auf 5 Punkte.
Die beiden nachfolgenden Bilder demonstrieren den Effekt des Ansichtabstands f r die Gr=ße
eines Pixels sowie den Effekt der Aufl=sung eines Ger@ts. Im ersten Bild f hrt ein Leseabstand
von 71 cm (28 Zoll) zu einem px-Wert von 0,28 mm, w@hrend ein Leseabstand von 3,5 m (12
Fuß) zu einem px-Wert von 1,4 mm f hrt.
Werte < 571 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Anmerkung der bersetzer: Die CSS2-Errata korrigieren: „Der empfohlene
Referenzpixel basiert auf einem 96dpi-Ger@t, nicht 90dpi. Der Sichtwinkel betr@gt folg-
lich ungef@hr 0,0213 Grad anstatt 0,0227 und ein Pixel auf Arml@nge ist ungef@hr 0,26
mm statt 0,28.“
1.4 mm
0.28 mm
viewer
28 inch
71 cm
140 inch
3.5 m
Im zweiten Bild wird ein Bereich von 1px mal 1px durch einen einzigen Punkt auf einem gering
aufl=senden Ger@t (einem Computerbildschirm) abgedeckt, w@hrend derselbe Bereich auf
einem h=her aufl=senden Ger@t (wie beispielsweise einem 400dpi-Laserdrucker) von 16 Punk-
ten abgedeckt wird.
laserprint
Cascading Style Sheets, Level 2
monitor screen
1px
1px
= 1 device pixel
Untergeordnete Elemente erben nicht die f r ihre bergeordneten Elemente angegebenen
relativen Werte; sie erben (im Allgemeinen) die berechneten Werte.
< 572 > CSS2-Syntax und grundlegende Datentypen
Page size: 168,00 x 240,00 mm
Beispiel
In den folgenden Regeln ist der berechnete Wert von 'text-indent' f r H1-Elemente
gleich 36pt, nicht 45pt, falls H1 ein untergeordnetes Element des BODY-Elements ist.
BODY {
font-size: 12pt;
text-indent: 3em; /* z. B. 36pt */
}
H1 { font-size: 15pt }
Absolute L,ngeneinheiten sind nur dann sinnvoll, wenn die physischen Eigenschaften des Aus-
gabemediums bekannt sind. Die absoluten Einheiten sind:
·· in : Inch (Zoll) – 1 Zoll ist gleich 2,54 Zentimeter.
cm : Zentimeter
·· mm : Millimeter
pt : Punkte – die in CSS2 verwendeten Punkte entsprechen 1/72 Zoll.
· pc : Picas – 1 Pica entspricht 12 Punkten.
H1 { margin: 0.5in } /* Zoll */
H2 { line-height: 3cm } /* Zentimeter */
H3 { word-spacing: 4mm } /* Millimeter */
H4 { font-size: 12pt } /* Punkte */
H4 { font-size: 1pc } /* Picas */
In F@llen, in denen die angegebene L@nge nicht unterst tzt werden kann, m ssen Benutzerpro-
gramme den tats@chlichen Wert approximieren.
4.3.3 Prozentwerte
Das Format eines Prozentwerts (in dieser Spezifikation als <percentage> gekennzeichnet) ist
Cascading Style Sheets, Level 2
ein optionales Vorzeichen ('+' oder '-', wobei '+' der Standard ist, unmittelbar gefolgt von einer
<number>, unmittelbar gefolgt von '%'.
Prozentwerte sind immer relativ zu einem anderen Wert, z. B. einer L@nge. Jede Eigenschaft,
die Prozentwerte unterst tzt, definiert auch den Wert, auf den sich der Prozentwert bezieht.
Der Wert kann der Wert einer anderen Eigenschaft f r dasselbe Element sein, eine Eigenschaft
f r ein Vorg@ngerelement oder ein Wert des Formatierungskontexts (z. B. die Breite eines
umschließenden Blocks). Wenn ein Prozentwert f r eine Eigenschaft des Wurzel-Elements ange-
geben wird und so definiert ist, dass er auf den geerbten Wert einer Eigenschaft verweist, ist der
resultierende Wert der Prozentwert multipliziert mit dem Ausgangswert dieser Eigenschaft.
Beispiel
Weil untergeordnete Elemente (im Allgemeinen) die berechneten Werte ihres berge-
ordneten Elements erben, erben im folgenden Beispiel die untergeordneten Elemente
des P-Elements einen Wert von 12pt f r 'line-height', nicht etwa den Prozentwert
(120%):
P { font-size: 10pt }
P { line-height: 120% } /* 120% von 'font-size' */
Werte < 573 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
4.3.4 URL + URN = URI
URLs (Uniform Resource Locators, siehe [RFC1738] und [RFC1808]) stellen die Adresse einer
Ressource im Web bereit. Eine voraussichtlich neue Methode, Ressourcen zu identifizieren, ist
URN (Uniform Resource Name). Zusammen werden sie als URIs (Uniform Resource Identi-
fiers, siehe [URI]) bezeichnet. In dieser Spezifikation wird der Begriff URI verwendet.
URI-Werte in dieser Spezifikation werden als <uri> gekennzeichnet. Die funktionale Notation
zur Angabe von URIs in Eigenschaftswerten ist ‘url()’, wie in:
BODY { background: url("[Link] }
Das Format eines URI-Wertes ist 'url(', gefolgt von optionalem Leerraum, gefolgt von
einem optionalen einfachen Anf hrungszeichen (') oder doppelten Anf hrungszeichen ("),
gefolgt von dem eigentlichen URI, gefolgt von einem optionalen einfachen Anf hrungszei-
chen (') oder doppelten Anf hrungszeichen ("), gefolgt von optionalem Whitespace,
gefolgt von ')'. Die beiden Anf hrungszeichen m ssen gleich sein.
Beispiel
Ein Beispiel ohne Anf hrungszeichen:
LI { list-style: url([Link] disc }
Klammern, Kommas, Whitespace-Zeichen, einfache Anf hrungszeichen (') und doppelte Anf hrungs-
zeichen (") in einer URI m ssen durch einen Backslash als Escape gekennzeichnet werden: '\(', '\)', '\,'.
Abh@ngig vom Typ des URI kann es auch m=glich sein, die oben gezeigten Zeichen als URI-Esca-
pes zu schreiben (wobei "(" = %28, ")" = %29 usw.), wie in [URI] beschrieben.
Um modulare Stylesheets zu erzeugen, die nicht von der absoluten Position einer Ressource
abh@ngig sind, k=nnen die Autoren relative URIs verwenden. Relative URIs (wie in [RFC1808]
definiert) werden unter Verwendung eines Basis-URI zu vollst@ndigen URIs aufgel=st. RFC 1808
Cascading Style Sheets, Level 2
Abschnitt 3 definiert den normativen Algorithmus f r diesen Prozess. F r CSS-Stylesheets ist
der Basis-URI der des Stylesheets, nicht der des Quelldokuments.
Beispiel
Angenommen, die folgende Regel:
BODY { background: url("yellow") }
befindet sich in einem Stylesheet, das durch die folgende URI angegeben wird:
[Link]
Der Hintergrund des BODY des Quelldokuments wird kachelartig mit dem Bild gef llt, das in
der durch den folgenden URI angegebenen Ressource bereitgestellt ist:
[Link]
Benutzerprogramme k=nnen dahingehend variieren, wie sie URIs verarbeiten, die nicht verf g-
bare oder nicht anwendbare Ressourcen bezeichnen.
< 574 > CSS2-Syntax und grundlegende Datentypen
Page size: 168,00 x 240,00 mm
4.3.5 [Link]
Z@hler werden durch Bezeichner gekennzeichnet (siehe die Eigenschaften 'counter-increment'
und 'counter-reset'). Um auf den Wert eines Z@hlers zu verweisen, wird die Notation 'coun-
ter(<identifier>)' oder 'counter(<identifier>, <list-style-type>)' verwendet. Der Standardstil ist
'decimal'.
Um auf eine Folge verschachtelter Z@hler desselben Namens zu verweisen, wird die Notation
'counters(<identifier>, <string>)' oder 'counters(<identifer>, <string>, <list-style-type>)' ver-
wendet. Weitere Informationen finden Sie im Abschnitt „Verschachtelte Z@hler und G ltig-
keitsbereich“ im Kapitel ber den erzeugten Inhalt.
In CSS2 kann ein Verweis auf die Werte von Z@hlern nur aus der Eigenschaft 'content' erfolgen.
Beachten Sie, dass 'none' ein m=glicher <list-style-type> ist: 'counter(x, none)' ergibt einen lee-
ren String.
Beispiel
Nachfolgend sehen Sie ein Stylesheet, das die Abs@tze (P) f r jedes Kapitel (H1) num-
meriert. Die Abs@tze werden mit r=mischen Zahlen nummeriert, gefolgt von einem
Punkt und einem Leerzeichen:
P {counter-increment: par-num}
H1 {counter-reset: par-num}
P:before {content: counter(par-num, upper-roman) ". "}
F r Z@hler, die nicht im G ltigkeitsbereich eines 'counter-reset' liegen, nimmt man an, dass sie
durch einen 'counter-reset' f r das Wurzel-Element auf 0 zur ckgesetzt wurden.
4.3.6 Farben
Eine <color> ist entweder ein Schl sselwort oder eine numerische RGB-Angabe.
Cascading Style Sheets, Level 2
Anmerkung der bersetzer: In der RGB-Angabe werden die Rot-, Gr n- und
Blau-Anteile (RGB) der gew nschten Farbe genannt.
Die Liste der Schl sselwort-Farbnamen ist: aqua, black, blue, fuchsia, gray, green, lime, maroon,
navy, olive, purple, red, silver, teal, white und yellow (aquamarinblau, schwarz, blau, fuchsia,
grau, gr n, limonengelb, kastanienbraun, navygr n, olivgr n, violett, rot, silber, (blau-gr n (teal),
weiß und gelb). Diese 16 Farben sind in HTML 4.0 ([HTML40]) definiert. Neben diesen Farb-
schl sselw=rtern k=nnen Benutzer auch Schl sselw=rter angeben, die den von bestimmten
Objekten in der Benutzerumgebung verwendeten Farben entsprechen. Weitere Informationen
finden Sie im Abschnitt ber Systemfarben.
Beispiel
BODY {color: black; background: white }
H1 { color: maroon }
H2 { color: olive }
Werte < 575 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Das RGB-Farbmodell wird in numerischen Farbspezifikationen verwendet. Die folgenden Bei-
spiele geben alle dieselbe Farbe an:
Beispiel
EM { color: #f00 } /* #rgb */
EM { color: #ff0000 } /* #rrggbb */
EM { color: rgb(255,0,0) } /* Integer-Bereich 0 - 255 */
EM { color: rgb(100%, 0%, 0%) } /* Float-Bereich 0.0% - 100.0% */
Das Format eines RGB-Werts in hexadezimaler Notation ist ein '#', unmittelbar gefolgt von
drei oder sechs hexadezimalen Zeichen. Die dreistellige RGB-Notation (#rgb) wird in eine
sechsstellige Form (#rrggbb) umgewandelt, indem die Ziffern repliziert werden, nicht, indem
Nullen hinzugef gt werden. Beispielsweise wird #fb0 zu #ffbb00 expandiert. Damit wird sicher-
gestellt, dass weiß (#ffffff) mit der Kurznotation (#fff) dargestellt werden kann, und es werden
alle Abh@ngigkeiten von der Farbtiefe der Anzeige ausgeschlossen.
Das Format eines RGB-Wertes in der funktionalen Notation ist 'rgb(' gefolgt von einer Liste
mit durch Kommas voneinander getrennten Eintr@gen der drei numerischen Werte (entweder
drei ganzzahlige Werte oder drei Prozentwerte), gefolgt von ')'. Der ganzzahlige Wert 255 ent-
spricht 100%, und F oder FF in der hexadezimalen Notation: rgb(255,255,255) = rgb(100%,
100%, 100%) = #FFF. Leerraum-Zeichen um die numerischen Werte herum sind erlaubt.
Alle RGB-Farben werden im sRGB-Farbraum angegeben (siehe [SRGB]). Benutzerprogramme
k=nnen sich darin unterscheiden, in welcher Farbtreue sie diese Farben darstellen, aber die
Verwendung von sRGB stellt eine eindeutige und objektiv messbare Definition dessen dar, wie
die Farbe aussehen soll, was mit internationalen Standards in Verbindung gebracht werden kann
(siehe [COLORIMETRY]).
Konforme Benutzerprogramme k=nnen ihre Bem hungen zur Farbanzeige darauf begrenzen,
eine Gammakorrektur darauf auszuf hren. sRGB gibt ein Anzeigegamma von 2.2 unter vor-
gegebenen Anzeigebedingungen. Benutzerprogramme sollten die in CSS angegebenen Farben
Cascading Style Sheets, Level 2
so anpassen, dass in Kombination mit dem „nat rlichen“ Anzeigegamma eines Ausgabeger@ts
ein effektives Anzeigegamma von 2.2 erzielt wird. Weitere Informationen finden Sie im
Abschnitt ber Gammakorrektur. Beachten Sie, dass nur die in CSS angegebenen Farben
betroffen sind; bei Bildern beispielsweise geht man davon aus, dass sie ihre eigenen Farbinfor-
mationen beinhalten.
Werte außerhalb der Ger@teskala sollten ausgeschlossen werden: die Rot-, Gr n- und Blau-
werte m ssen so ge@ndert werden, dass sie innerhalb des von dem Ger@t unterst tzten
Bereichs liegen. F r einen typischen CRT-Bildschirm, dessen Ger@teskala dieselbe wie sRGB ist,
sind die drei folgenden Regeln @quivalent:
EM { color: rgb(255,0,0) } /* Integer-Bereich 0 - 255 */
EM { color: rgb(300,0,0) } /* zugeschnitten auf rgb(255,0,0) */
EM { color: rgb(255,-10,0) } /* zugeschnitten auf rgb(255,0,0) */
EM { color: rgb(110%, 0%, 0%) } /* zugeschnitten auf rgb(100%,0%,0%) */
Andere Ger@te wie beispielsweise Drucker haben andere Skalen f r sRGB; einige Farben
außerhalb des sRGB-Bereichs 0..255 sind darstellbar (innerhalb der Ger@teskala), w@hrend
andere Farben innerhalb des sRGB-Bereichs 0..255 außerhalb der Ger@teskala liegen und damit
ausgeschlossen werden.
< 576 > CSS2-Syntax und grundlegende Datentypen
Page size: 168,00 x 240,00 mm
Hinweis: Obwohl Farben einem Dokument wesentliche Informationen hinzuf gen k=nnen
und es lesbarer machen, sollten Sie beachten, dass bestimmte Farbkombinationen Probleme f r
farbenblinde Benutzer verursachen k=nnen. Wenn Sie ein Hintergrundbild verwenden oder die
Hintergrundfarbe setzen, sollten Sie die Vordergrundfarben entsprechend anpassen. n
4.3.7 Winkel
Winkelwerte (im Text als <angle> angegeben) werden in Kombination mit akustischen Style-
sheets verwendet.
Ihr Format ist ein optionales Vorzeichen ('+'oder '-', wobei '+' der Standard ist), unmittelbar
gefolgt von einer <number>, unmittelbar gefolgt von einem Winkeleinheitenbezeichner.
Winkeleinheitenbezeichner sind:
·· deg : Grad
grad : Gradienten
· rad : Bogenmaß
Winkelwerte k=nnen negativ sein. Sie sollten vom Benutzerprogramm in den Bereich 0-360deg
normalisiert werden. Beispielsweise sind –10deg und 350deg @quivalent.
Beispielsweise ist ein rechter Winkel '90deg' oder '100grad' oder '1.570796326794897rad'.
4.3.8 Zeiten
Zeitwerte (im Text durch <time> gekennzeichnet) werden in Kombination mit akustischen
Stylesheets verwendet.
Ihr Format ist eine <number> unmittelbar gefolgt von einem Zeiteinheitenbezeichner.
Zeiteinheitenbezeichner sind:
·· ms : Millisekunden
s : Sekunden
Cascading Style Sheets, Level 2
Zeitwerte k=nnen nicht negativ sein.
4.3.9 Frequenzen
Frequenzwerte (im Text durch <frequency> gekennzeichnet) werden in Kombination mit
akustischen kaskadierenden Stylesheets verwendet.
Ihr Format ist eine <number>, unmittelbar gefolgt von einem Frequenzeinheitenbezeichner.
Frequenzeinheitenbezeichner sind:
·· Hz : Hertz
kHz : Kilo Hertz
Frequenzwerte d rfen nicht negativ sein.
200Hz (oder 200hz) beispielsweise ist ein Basston, 6kHz (oder 6khz) ist ein hoher Ton.
Werte < 577 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
4.3.10 Zeichenketten
Zeichenketten („Strings“) k=nnen in doppelten oder einfachen Anf hrungszeichen angegeben
werden. Doppelte Anf hrungszeichen d rfen nicht innerhalb von doppelten Anf hrungszei-
chen vorkommen, es sei denn, es wird ihnen ein Escape vorangestellt (wie etwa '\"' oder '\22').
Gleiches gilt f r einfache Anf hrungszeichen ("\'") oder "\27").
"Dies ist ein 'String'"
"Dies ist ein \"String\""
'Dies ist ein "String"'
'Dies ist ein \'String\''
Eine Zeichenkette darf nicht direkt ein Neuezeile-Zeichen enthalten. Um ein Neuezeile-Zeichen
in einen String aufzunehmen, verwenden Sie das Escape-Zeichen ‘\A’ (hexadezimal A ist das Zei-
lenvorschub-Zeichen in Unicode, stellt aber in CSS das allgemeine Konzept von „Neue Zeile“
dar). Ein Beispiel daf r finden Sie in der Beschreibung der Eigenschaft 'content'.
Es ist m=glich, Zeichenketten aus @sthetischen oder anderen Gr nden ber mehrere Zeilen zu
umbrechen, aber in diesem Fall muss das eigentliche Neuezeile-Zeichen mit einem Backslash (\)
als Escape gekennzeichnet werden. Die beiden folgenden Selektoren beispielsweise sind identisch:
A[TITLE="ein nicht s\
o sehr langer Titel"] {/*...*/}
A[TITLE="ein nicht so sehr langer Titel"] {/*...*/}
4.4 CSS-Dokumentdarstellung
Ein CSS-Stylesheet ist eine Zeichenfolge aus dem Universal Character Set (siehe [ISO10646]).
Zur bertragung und Speicherung m ssen diese Zeichen durch eine Zeichencodierung codiert
werden, die den in US-ASCII verf gbaren Zeichensatz unterst tzt (z. B. ISO 8859-x, SHIFT JIS
Cascading Style Sheets, Level 2
usw.). Eine gute Einf hrung in Zeichens@tze und Zeichencodierungen finden Sie in der HTML
4.0-Spezifikation ([HTML40], Kapitel 5), und auch in der XML 1.0-Spezifikation ([XML10]),
Abschnitte 2.2 und 4.3.3 und in Anhang F.
Wenn ein Stylesheet in ein anderes Dokument eingebettet wird, wie beispielsweise in das
STYLE-Element oder „style“-Attribut von HTML, verwendet das Stylesheet dieselbe Zeichen-
codierung wie das gesamte Dokument.
Wenn sich ein Stylesheet in einer separaten Datei befindet, m ssen Benutzerprogramme die
nachfolgend aufgelisteten Priorit@ten befolgen, wenn die Zeichencodierung eines Dokuments
festgelegt werden soll (angeordnet von der h=chsten zur geringsten Priorit@t):
1. Ein HTTP-‘charset’-Parameter in einem ‘Content-Type’-Feld.
2. Die At-Regel @charset.
3. Mechanismen der Sprache des referenzierenden Dokuments (z. B. in HTML das "char-
set"-Attribut des LINK-Elements).
In einem externen Stylesheet darf h=chstens eine @charset-Regel erscheinen – sie darf nicht in
einem eingebetteten Stylesheet erscheinen –, und sie muss ganz am Anfang des Dokuments ste-
hen, und es d rfen ihr keine Zeichen vorangehen. Nach "@charset" geben Autoren den
< 578 > CSS2-Syntax und grundlegende Datentypen
Page size: 168,00 x 240,00 mm
Namen einer Zeichencodierung an. Bei dem Namen muss es sich um einen Zeichensatznamen
handeln, wie in der IANA-Registrierung beschrieben (siehe [IANA]; eine vollst@ndige Liste der
Zeichens@tze finden Sie in [CHARSETS]. Beispiel:
@charset "ISO-8859-1";
Diese Spezifikation schreibt nicht vor, welche Zeichencodierungen ein Benutzerprogramm
unterst tzen muss.
Beachten Sie, dass ein Vertrauen auf das @charset-Konstrukt theoretisch ein Problem aufwirft,
weil es keine a priori-Information dar ber gibt, wie es codiert wird. In der Praxis basieren die
allgemein im Internet verwendeten Codierungen entweder auf ASCII, UTF-16, UCS-4 oder
(selten) EBCDIC. Das bedeutet im allgemeinen, das Benutzerprogramm kann anhand der ers-
ten Bytewerte eines Dokuments die Codierungsfamilie zuverl@ssig erkennen, wodurch ausrei-
chend viele Informationen bereitgestellt werden, um die @charset-Regel zu decodieren,
wodurch wiederum die genaue Zeichencodierung festgelegt wird.
4.4.1 Verweise auf Zeichen, die nicht in einer Zeichencodierung
dargestellt sind
Ein Stylesheet kann auf Zeichen verweisen, die nicht in der aktuellen Zeichencodierung dar-
gestellt werden k=nnen. Diese Zeichen m ssen als durch Escape gekennzeichnete Verweise auf
ISO 10646-Zeichen geschrieben werden. Diese Escapes dienen demselben Zweck wie numeri-
sche Zeichenverweise in HTML- oder XML-Dokumenten (siehe [HTML40], Kapitel 5 und 25).
Die Zeichen-Escape-Mechanismen sollten verwendet werden, wenn nur ein paar wenige Zei-
chen auf diese Weise dargestellt werden sollen. Wenn f r einen Großteil eines Dokuments
eine Escape-Kennzeichnung erforderlich ist, sollten die Autoren es mit einer geeigneteren
Codierung darstellen (z. B. wenn das Dokument sehr viele griechische Zeichen enth@lt, k=nn-
ten Autoren "ISO-8859-7" oder "UTF-8" verwenden).
Zwischengeschaltete Prozessoren, die eine andere Zeichencodierung verwenden, k=nnen diese
Cascading Style Sheets, Level 2
mit Escape gekennzeichneten Folgen in Bytefolgen dieser Codierung bersetzen. Sie d rfen jedoch
keine Escape-Folgen ver@ndern, die die spezielle Bedeutung eines ASCII-Zeichens aufheben.
Konforme Benutzerprogramme m ssen alle Zeichen in allen von ihnen erkannten Zeichencodie-
rungen auf Unicode abbilden (oder sie m ssen sich zumindest verhalten, als ob sie das t@ten).
Ein Dokument beispielsweise, das als ISO-8859-1 (Latin-1) bertragen wird, darf keine direkten
griechischen Buchstaben enthalten: "Koupos" (griechisch: "kouros") muss geschrieben werden
als "\3BA\3BF\3C5\3C1\3BF\3C2".
Hinweis: In HTML 4.0 werden numerische Zeichenverweise in „style“-Attributwerten inter-
pretiert, nicht aber im Inhalt des STYLE-Elements. Aufgrund dieser Asymmetrie empfehlen wir
Autoren, den CSS-Zeichen-Escape-Mechanismus statt numerischer Zeichenverweise sowohl
f r das „style“-Attribut als auch f r das STYLE-Element zu verwenden. Beispielsweise empfeh-
len wir
<SPAN style="voice-family: D\FC rst">...</SPAN>
statt
<SPAN style="voice-family: Dürst">...</SPAN>
CSS-Dokumentdarstellung < 579 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
5 Selektoren
5.1 Mustervergleich
In CSS legen die Regeln f r den Mustervergleich fest, welche Stilregeln auf die Elemente im
Dokumentbaum angewendet werden. Diese Muster, die so genannten Selektoren, k=nnen von
einfachen Elementnamen bis hin zu umfassenden Kontextmustern reichen. Wenn alle Bedin-
gungen eines Musters f r ein bestimmtes Element zutreffen, stimmt der Selektor mit dem Ele-
ment berein.
Anmerkung der bersetzer: CSS bestehen (einfach ausgedr ckt) aus Anweisun-
gen, die eine linke und eine rechte Seite haben:
was { wie }
Das was beschreibt welche Elemente gemeint sind. Das wie beschreibt wie sie dar-
gestellt werden. In diesem Kapitel geht es um das was, die so genannten Selektoren. Bei
der Darstellung einer Webseite mit CSS sucht der Web-Browser zu jedem Element
den passenden Selektor. Wenn er einen findet, wendet er das wie darauf an.
Die nachfolgenden Abschnitte beschreiben die Selektoren zum Teil sehr formal. Das gilt
besonders f r den Abschnitt ber die Selektorsyntax. Sp@tere Teile sind leichter ver-
st@ndlich. Es wird empfohlen, den Beispielen besondere Aufmerksamkeit zu schenken.
Sie tragen am besten zum Verst@ndnis bei.
Ob f r die Elementnamen einer Dokumentsprache die Groß-/Kleinschreibung ber cksichtigt
wird, ist von der Dokumentsprache abh@ngig. In HTML beispielsweise wird in Dokumentnamen
die Groß-/Kleinschreibung nicht ber cksichtigt, in XML dagegen sehr wohl.
Cascading Style Sheets, Level 2
Anmerkung der bersetzer: Wie schon erw@hnt: Die Ber cksichtigung der
Groß/Kleinschreibung in XML wirkt sich auch auf XHTML aus.
Die folgende Tabelle bietet einen berblick ber die Syntax f r CSS-Selektoren:
Muster Beschreibung Beschrieben in Abschnitt
* Stimmt mit jedem Element berein. Universeller Selektor
E Stimmt mit jedem E-Element berein Typselektoren
(d. h. ein Element des Typs E).
EF Stimmt mit jedem F-Element berein, das Selektoren f r Nachfahren
ein Nachfahre eines E-Elements ist.
E>F Stimmt mit allen F-Elementen berein, Kindselektoren
die Kindelemente eines Elements E sind.
< 580 > Selektoren
Page size: 168,00 x 240,00 mm
E:first- Stimmt mit Element E berein, wenn E Die Pseudoklasse :first-child
child das erste Kindelement des bergeord-
neten Elements ist.
E:link Stimmt mit dem Element E berein, wenn Die Link-Pseudoklassen
E:visited E der Quellanker eines Hyperlinks ist,
dessen Ziel noch nicht besucht wurde
(:link), oder dessen Ziel bereits besucht
wurde (:visited).
E:active Stimmt w@hrend bestimmter Benutzer- Die Dynamic-Pseudoklassen
E:hover aktionen mit E berein.
E:focus
E:lang(c) Stimmt mit einem Element des Typs E Die Sprach-Pseudo-Klasse
berein, wenn dieses sich in der :lang
(menschlichen) Sprache c befindet (die
Dokumentsprache gibt an, wie die
Sprache ermittelt wird).
E+F Stimmt mit jedem F-Element berein, Benachbarte Selektoren
dem unmittelbar ein Element E voraus-
geht.
E[foo] Stimmt mit jedem E-Element berein, Attribut-Selektoren
dessen Attribut „foo“ gesetzt ist (ganz
gleich, welchen Wert es hat).
E[foo= Stimmt mit jedem E-Element berein, Attribut-Selektoren
"warning"] dessen Attribut „foo“ genau den Wert
von „warning“ hat.
E[foo~= Stimmt mit jedem E-Element berein, Attribut-Selektoren
Cascading Style Sheets, Level 2
"warning"] dessen Attribut „foo“ eine Liste von
durch Kommas voneinander getrennten
Werten enth@lt, und einer dieser Werte
gleich „warning“ ist.
E[lang|= Stimmt mit jedem E-Element berein, Attribut-Selektoren
"en"] dessen Attribut „lang“ eine Liste mit
durch Trennstriche voneinander getrenn-
ten Werten enth@lt, die (von links) mit
„en“ beginnen.
[Link]- Nur HTML. Dasselbe wie DIV- Klassen-Selektoren
ning [class~="warning"].
E#myid Stimmt mit jedem E-Element berein, ID-Selektoren
dessen ID gleich „myid“ ist.
Mustervergleich < 581 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
5.2 Selektorsyntax
Ein einfacher Selektor ist entweder ein Typselektor oder ein universeller Selektor, unmittelbar
gefolgt von null oder mehr Attribut-Selektoren, ID-Selektoren oder Pseudo-Klassen in beliebi-
ger Reihenfolge. Der einfache Selektor bringt eine bereinstimmung, wenn alle seine Kom-
ponenten bereinstimmen.
Ein Selektor ist eine Verkettung aus einem oder mehreren einfachen Selektoren, durch Kombina-
torzeichen voneinander getrennt. Kombinatorzeichen sind: Leerraum, „>“ und „+“. Leerraum kann
zwischen einem Kombinatorzeichen und den umgebenden einfachen Selektoren stehen.
Die Elemente des Dokumentbaums, die mit einem Selektor bereinstimmen, werden als Sub-
jekte des Selektors bezeichnet. Ein Selektor, der aus einem einzigen einfachen Selektor besteht,
stimmt mit jedem Element berein, das seine Anforderungen erf llt. Das Vorschalten eines ein-
fachen Selektors und eines Kombinatorzeichens vor eine Kette bewirkt zus@tzliche berein-
stimmungsbeschr@nkungen, so dass die Subjekte eines Selektors immer eine Untermenge der
Elemente sind, die mit dem ganz rechts stehenden einfachen Selektor bereinstimmen.
Ein Pseudo-Element kann an den letzten einfachen Selektor in einer Kette angeh@ngt werden.
In diesem Fall gilt die Stilinformation f r eine Unterkomponente eines jeden Subjekts.
5.2.1 Gruppierung
Wenn mehrere Selektoren dieselben Deklarationen haben, k=nnen sie in einer Liste gruppiert
werden, deren Eintr@ge durch Kommas voneinander getrennt sind.
Beispiel
In diesem Beispiel fassen wir drei Regeln mit identischen Deklarationen zu einer ein-
zigen Regel zusammen. Damit gilt:
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
Cascading Style Sheets, Level 2
H3 { font-family: sans-serif }
ist @quivalent zu:
H1, H2, H3 { font-family: sans-serif }
CSS unterst tzt außerdem weitere „abk rzende“ Mechanismen, unter anderem Mehrfach-
deklarationen und zusammenfassende Eigenschaften.
5.3 Universeller Selektor
Der universelle Selektor, auch als „*“ angegeben, stimmt mit dem Namen jedes Elementtyps
berein. Er stimmt mit jedem einzelnen Element im Dokumentbaum berein.
Falls es sich beim universellen Selektor nicht um die einzige Komponente in einem einfachen
Selektor handelt, kann der „*“ weggelassen werden. Beispiel:
·· *[LANG=fr] und [LANG=fr] sind @quivalent.
*.warning und .warning sind @quivalent.
· *#myid und #myid sind @quivalent.
< 582 > Selektoren
Page size: 168,00 x 240,00 mm
5.4 Typselektoren
Ein Typselektor stimmt mit dem Namen eines Elementtyps der Dokumentsprache berein. Ein
Typselektor stimmt mit jeder Instanz des Elementtyps im Dokumentbaum berein.
Beispiel
Die folgende Regel stimmt mit allen H1-Elementen im Dokumentbaum berein:
H1 { font-family: sans-serif }
5.5 Selektoren f-r Nachfahren
Manchmal wollen Autoren, dass Selektoren mit einem Element bereinstimmen, das ein Nach-
fahre eines anderen Elements im Dokumentbaum darstellt (z. B. „Stimme mit den EM-Elemen-
ten berein, die in einem H1-Element enthalten sind"). Selektoren f r Nachfahren dr cken eine
solche Beziehung in einem Muster aus. Ein Selektor f r Nachfahren besteht aus zwei oder mehr
Selektoren, die durch Leerraum voneinander getrennt sind. Ein Nachfahren-Selektor der Form
„A B“ erzeugt eine bereinstimmung, wenn ein Element B eine beliebiger Nachfahre eines Vor-
fahrenelements A ist.
Beispiel
Betrachten Sie beispielsweise die folgenden Regeln:
H1 { color: red }
EM { color: red }
Obwohl diese Regeln beabsichtigen, den Text zus@tzlich zu betonen, indem sie die Textfarbe
@ndern, geht der Effekt in einem Fall wie dem folgenden verloren:
Cascading Style Sheets, Level 2
<H1>Diese dberschrift ist <EM>sehr</EM> wichtig</H1>
Wir ber cksichtigen diesen Fall, indem wir die obigen Regeln durch eine Regel erg@nzen, die
die Textfarbe auf blau setzt, wenn irgendwo in einem H1-Element ein EM auftritt:
H1 { color: red }
EM { color: red }
H1 EM { color: blue }
Die dritte Regel bringt eine bereinstimmung mit dem EM im folgenden Ausschnitt:
<H1>Diese <SPAN class="myclass">dberschrift
ist <EM>sehr</EM> wichtig</SPAN></H1>
Der folgende Selektor:
DIV * P
Typselektoren < 583 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
stimmt mit einem P-Element berein, das ein Nachkomme zweiter Generation oder sp@ter
eines DIV-Elements ist. Beachten Sie den Leerraum auf jeder Seite des „*“.
Der Selektor in der folgenden Regel, die abgeleitete und Attributselektoren kombiniert, stimmt
mit jedem Element berein, f r das (1) das Attribut „href“ gesetzt ist, und das sich (2) in einem
P befindet, das sich wiederum in einem DIV befindet:
DIV P *[href]
Anmerkung der bersetzer: Bei den Nachfahren ist wichtig, dass sie beliebig tief
in den bergeordneten Elementen verschachtelt sein k=nnen. Wie man nur direkte
Nachfahren anspricht, erkl@rt der n@chste Abschnitt.
5.6 Kind-Selektoren
Ein Kind-Selektor erzeugt eine bereinstimmung, wenn ein Element ein direkt untergeordnetes
Element eines anderen Elements ist. Ein Kind-Selektor besteht aus einem oder mehreren Selek-
toren, die durch „>“ voneinander getrennt sind.
Beispiel
Die folgende Regel bestimmt den Stil aller P-Elemente, die Kindelemente von BODY
sind:
BODY > P { line-height: 1.3 }
Das folgende Beispiel kombiniert Nachfahren-Selektoren und Nachfahren-Selektoren:
Cascading Style Sheets, Level 2
DIV OL>LI P
Es stimmt mit einem P-Element berein, das ein Nachfahre von einem LI ist; das LI-Element muss
ein Kind-Element eines OL-Elements sein; das OL-Element muss ein Nachfahre eines DIV sein.
Beachten Sie, dass der optionale Leerraum um das Kombinatorzeichen „>“ weggelassen wurde.
Weitere Informationen ber die Auswahl des ersten untergeordneten Elements eines Elements
finden Sie im Abschnitt ber die Pseudoklasse :first-child sp@ter in diesem Kapitel.
5.7 Selektoren f-r benachbarte Elemente
Selektoren f r benachbarte Elemente haben die folgende Syntax: E1 + E2. Dabei ist E2 das Sub-
jekt des Selektors. Der Selektor erzeugt eine bereinstimmung, wenn E1 und E2 dasselbe
bergeordnete Element im Dokumentbaum haben und E1 E2 unmittelbar vorausgeht.
In einigen Kontexten erzeugen benachbarte Elemente Formatierungsobjekte, deren Darstel-
lung automatisch verarbeitet wird (z. B. das Zusammenfallen vertikaler R@nder zwischen
benachbarten Boxen). Der Selektor „+“ erlaubt Autoren, zus@tzliche Stile f r benachbarte Ele-
mente anzugeben.
< 584 > Selektoren
Page size: 168,00 x 240,00 mm
Beispiel
Die folgende Regel gibt demnach an, dass ein P-Element nicht einger ckt werden soll,
wenn es unmittelbar einem MATH-Element folgt:
MATH + P { text-indent: 0 }
Das n@chste Beispiel reduziert den vertikalen Abstand zwischen einem H1- und einem unmit-
telbar darauffolgenden H2-Element:
H1 + H2 { margin-top: -5mm }
Die folgende Regel ist der aus dem vorhergehenden Beispiel @hnlich, f gt aber einen Attribut-
Selektor hinzu. Die spezielle Formatierung findet damit nur dann statt, wenn H1 die Klasse
class="opener" hat:
[Link] + H2 { margin-top: -5mm }
5.8 Attribut-Selektoren
CSS2 erlaubt Autoren, Regeln anzugeben, die mit im Quelldokument definierten Attributen
bereinstimmen.
5.8.1 Attribute und Attributwerte vergleichen
Attributwerte k=nnen auf viererlei Arten eine bereinstimmung erzielen:
[att]
Erzielt eine bereinstimmung, wenn das Element das Attribut „att“ gesetzt hat, egal mit
welchem Wert.
Cascading Style Sheets, Level 2
[att=val]
Erzielt eine bereinstimmung, wenn das Attribut „att“ des Elements genau den Wert „val“
hat.
[att~=val]
Erzielt eine bereinstimmung, wenn es sich beim Wert des Attributs „att“ um eine Liste
mit durch Leerzeichen voneinander getrennten „W=rtern“ handelt, von denen eines genau
mit „val“ bereinstimmt. Falls dieser Selektor verwendet wird, d rfen die W=rter im Wert
keine Leerzeichen enthalten (weil sie durch Leerzeichen voneinander getrennt sind).
[att|=val]
Erzielt eine bereinstimmung, wenn der Wert des Attributs „att“ f r das Element eine
Liste von durch Trennstriche voneinander getrennten „W=rtern“ ist, beginnend mit „val“.
Der Vergleich beginnt immer am Anfang des Attributwerts. Er ist haupts@chlich daf r vor-
gesehen, Sprach-Teilcode- bereinstimmungen zu erlauben (z. B. das Attribut „lang“ in
HTML), wie in RFC 1766 ([RFC1766]) beschrieben.
Attribut-Selektoren < 585 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Anmerkung der bersetzer: Der letzte Fall bezieht sich auf die Angabe von Spra-
chen. Sprachen werden in der Form de-DE, de-CH, en-US (hier Angaben der Sprachen
f r Deutschland, Schweiz und USA) usw. bezeichnet.
Attributwerte m ssen Bezeichner oder Zeichenketten sein. Ob f r Attributnamen und Werte
in Selektoren die Groß-/Kleinschreibung ber cksichtigt wird, ist von der Dokumentsprache
abh@ngig.
Beispiel
Der folgende Attribut-Selektor beispielsweise stimmt mit allen H1-Elementen berein,
die das Attribut „title“ angeben, unabh@ngig davon, welchen Wert es enth@lt:
H1[title] { color: blue; }
Im folgenden Beispiel stimmt der Selektor mit allen SPAN-Elementen berein, deren
„class“-Attribut genau den Wert „example“ hat:
SPAN[class=example] { color: blue; }
Mehrere Attribut-Selektoren k=nnen genutzt werden, um auf mehrere Attributwerte eines
Elements zu verweisen, oder auch mehrfach auf dasselbe Attribut.
Beispiel
Hier stimmt der Selektor mit allen SPAN-Elementen berein, deren „hello“-Attribut
genau den Wert „Cleveland“ hat, und deren „goodbye“-Attribut genau den Wert
„Columbus“ hat:
Cascading Style Sheets, Level 2
SPAN[hello="Cleveland"][goodbye="Columbus"]
{ color: blue; }
Die folgenden Selektoren zeigen die Unterschiede zwischen „=“ und „~=“. Der erste Selektor
beispielsweise erzielt eine bereinstimmung mit dem Wert „copyright copyleft copyeditor“ f r
das Attribut „rel“. Der zweite Selektor erzielt nur eine bereinstimmung, wenn das „href“-
Attribut den Wert „[Link] hat.
A[rel~="copyright"]
A[href="[Link]
Die folgende Regel verbirgt alle Werte, f r die der Wert des Attributs „lang“ gleich „fr“ ist
(d. h. die Sprache ist Franz=sisch).
*[LANG=fr] { display : none }
< 586 > Selektoren
Page size: 168,00 x 240,00 mm
Die folgende Regel erzielt eine bereinstimmung f r Werte des Attributs „lang“, das mit „en“
beginnt, inklusive „en“, „en-US“ und „en-cockney“:
*[LANG|="en"] { color : red }
Analog dazu erlauben die folgenden Regeln f r ein akustisches Stylesheet, dass ein Skript laut
mit unterschiedlichen Stimmen f r jede Rolle gelesen wird:
DIALOGUE[character=romeo]
{ voice-family: "Lawrence Olivier", charles, male }
DIALOGUE[character=juliet]
{ voice-family: "Vivien Leigh", victoria, female }
5.8.2 Standardattributwerte in DTDs
Der Vergleich erfolgt f r Attributwerte im Dokumentbaum. F r andere Dokumentsprachen als
HTML k=nnen Standardattributwerte in einer DTD oder an anderer Stelle definiert werden.
Stylesheets sollten so entworfen werden, dass sie auch dann funktionieren, wenn die Standard-
werte nicht im Dokumentbaum enthalten sind.
Anmerkung der bersetzer: Mittlerweile wird CSS auch zur Formatierung von
beliebigen XML-Sprachen benutzt. Zum Beispiel setzt der Editor XMetal CSS f r die
Bildschirmdarstellung ein. Der hier gegebene Hinweis, an Vorgabewerte in einer DTD
zu denken, ist also heute noch sinnvoller als zur Zeit, zu der die CSS-Spezifikation
geschrieben wurde.
Cascading Style Sheets, Level 2
Beispiel
Betrachten Sie beispielsweise ein EXAMPLE-Element mit einem Attribut „notation“, das
den Standardwert „decimal“ hat. Das DTD-Fragment k=nnte wie folgt aussehen:
<!ATTLIST EXAMPLE notation (decimal,octal) "decimal">
Wenn das Stylesheet die folgenden Regeln enth@lt:
EXAMPLE[notation=decimal] {
/*... Standardeigenschaftseinstellungen ...*/ }
EXAMPLE[notation=octal] { /*... andere
Einstellungen...*/ }
und man will alle F@lle auffangen, in denen dieses Attribut standardm@ßig und nicht explizit
gesetzt ist, k=nnte man die folgende Regel einf gen:
EXAMPLE { /*... Standardeigenschaftseinstellungen...*/ }
Attribut-Selektoren < 587 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Weil dieser Selektor weniger spezifisch ist als ein Attribut-Selektor, wird er nur f r den Stan-
dardfall verwendet. Es muss darauf geachtet werden, dass alle anderen Attributwerte, die nicht
denselben Stil wie der Standard erhalten sollen, explizit abgedeckt werden.
5.8.3 Klassen-Selektoren
F r Stylesheets, die in Kombination mit HTML eingesetzt werden, k=nnen Autoren die Punkt-
notation (.) als Alternative zur „~=„-Notation verwenden, wenn mit dem „class“-Attribut ver-
glichen wird. F r HTML haben also „[Link]“ und „DIV[class~=value]“ dieselbe Bedeutung.
Der Attributwert muss dem „.“ unmittelbar folgen.
Beispiel
Beispielsweise k=nnen wir folgendermaßen allen Elementen mit class~="pastoral" eine
Stilinformation zuweisen:
*.pastoral { color: green } /* alle Elemente mit
class~=pastoral */
oder einfach
.pastoral { color: green } /* alle Elemente mit
class~=pastoral */
Die folgende Regel weist nur H1-Elementen mit class~="pastoral" einen Stil zu:
[Link] { color: green } /* H1-Elemente mit
class~=pastoral */
Mit diesen Regeln w rde die erste folgende H1-Instanz nicht mit gr nem Text dargestellt, die
zweite dagegen sehr wohl:
Cascading Style Sheets, Level 2
<H1>Nicht grUn</H1>
<H1 class="pastoral">Sehr grUn</H1>
Um eine bereinstimmung mit einer Untermenge der „class“-Werte zu erzielen, muss jedem
Wert ein „.“ vorausgehen, in beliebiger Reihenfolge.
Beispiel
Die folgende Regel beispielsweise erzielt eine bereinstimmung mit einem beliebigen
P-Element, dessen „class“-Attribut eine Liste mit durch Leerzeichen voneinander abge-
trennten Werten zugewiesen wurde, die „pastoral“ und „marine“ enthalten:
[Link] { color: green }
Diese Regel erzielt eine bereinstimmung, wenn class="pastoral blue aqua marine" ist, aber
nicht f r class="pastoral blue".
< 588 > Selektoren
Page size: 168,00 x 240,00 mm
Hinweis: CSS stattet das „class“-Attribut mit so viel Leistungsf@higkeit aus, dass Autoren ganz
bequem ihre eigene „Dokumentsprache“ entwickeln k=nnten, die auf Elementen basiert, die
fast keine zugeh=rigen Darstellung besitzen (wie beispielsweise DIV und SPAN in HTML), und
die Stilinformation ber das „class“-Attribut zuweisen. Autoren sollten diese Vorgehensweise
jedoch vermeiden, weil die strukturellen Elemente einer Dokumentsprache h@ufig bekannte
und anerkannte Bedeutungen haben, vom Autor definierte Klassen dagegen m=glicherweise
nicht. n
Anmerkung der bersetzer: Es ist durchaus m=glich, nur mit einem einzigen Ele-
menttyp, etwa p auszukommen. In der Form <p class="vorwort">... <p class="kapitel">
usw. k=nnten dann die Elemente beginnen. Ihre Darstellung w rde vollst@ndig ber CSS
gesteuert.
Diese Verwendung von HTML kann wohl mit Recht als unsinnig bezeichnet werden, da
HTML keine Rolle mehr spielt. Hier bietet es sich an, auf XML umzusteigen, einen eige-
nen Dokumenttyp zu definieren und die neuen Elementtypen in einer eigenen DTD zu
deklarieren. In der Folge w rden die Elemente dann etwa so beginnen: <vorwort> ...
<kapitel>...
Die Modularisierung von XHTML erlaubt auch, eigene Elementtypen mit vorhandenen
XHTML-Modulen zu kombinieren.
5.9 ID-Selektoren
Dokumentsprachen k=nnen Attribute enthalten, die als vom Typ ID deklariert sind. Was Attri-
bute vom Typ ID so besonders macht, ist die Tatsache, dass keine zwei solchen Attribute den-
selben Wert haben k=nnen; unabh@ngig davon, um welche Dokumentsprache es sich handelt –
ein ID-Attribut kann genutzt werden, um sein Element eindeutig zu identifizieren. In HTML
Cascading Style Sheets, Level 2
werden alle ID-Attribute als „id“ bezeichnet; XML-Applikationen benennen ID-Attribute m=gli-
cherweise anders, aber es gelten dieselben Beschr@nkungen.
Das ID-Attribut einer Dokumentsprache erlaubt Autoren, einer Elementinstanz im Dokument-
baum eine ID zuzuweisen. Die ID-Selektoren von CSS erzielen dieser ID entsprechend eine
bereinstimmung f r eine Elementinstanz. Ein ID-Selektor in CSS enth@lt ein „#“ gefolgt von
dem ID-Wert.
Beispiel
Der folgende ID-Selektor erzielt eine bereinstimmung mit dem H1-Element, dessen
ID-Attribut den Wert „Kapitel1“ hat:
H1#Kapitel1 { text-align: center }
ID-Selektoren < 589 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Im folgenden Beispiel erzeugt die Stilregel eine bereinstimmung mit dem Element, das den ID-
Wert „z98y“ hat. Die Regel erzeugt damit eine bereinstimmung f r das P-Element:
<HEAD>
<TITLE>dbereinstimmung mit P</TITLE>
<STYLE type="text/css">
*#z98y { letter-spacing: 0.3em }
</STYLE>
</HEAD>
<BODY>
<P id=z98y>Breiter Text</P>
</BODY>
Im n@chsten Beispiel erzeugt die Stilregel jedoch nur eine bereinstimmung f r ein H1-Element,
das den ID-Wert „z98y“ hat. Die Regel erzeugt in diesem Beispiel keine bereinstimmung mit
dem P-Element:
<HEAD>
<TITLE>dbereinstimmung nur mit H1</TITLE>
<STYLE type="text/css">
H1#z98y { letter-spacing: 0.5em }
</STYLE>
</HEAD>
<BODY>
<P id=z98y>Breiter Text</P>
</BODY>
ID-Selektoren haben eine h=here Spezifit@t als Attribut-Selektoren. In HTML beispielsweise ist
der Selektor #p123 spezifischer als [ID=p123], was die Kaskade betrifft.
In XML 1.0 [XML10] ist die Information dar ber, welches Attribut die ID eines Elements ent-
h@lt, in einer DTD enthalten. Beim Parsen von XML lesen Benutzerprogramme nicht immer die
Cascading Style Sheets, Level 2
DTD und wissen damit m=glicherweise nicht, um welches Element es sich bei der DTD han-
delt. Wenn ein Stylesheet-Designer weiß oder vermutet, dass dies der Fall ist, sollte er statt-
dessen normale Attribut-Selektoren verwenden: [name=p371] statt #p371. Die kaskadierende
Reihenfolge normaler Attribut-Selektoren unterscheidet sich jedoch von ID-Selektoren. Es
kann erforderlich sein, den Deklarationen eine „!important“-Priorit@t hinzuzuf gen: [na-
me=p371] {color: red ! important}. Nat rlich haben Elemente in XML 1.0-Dokumenten ohne
eine DTD berhaupt keine IDs. n
5.10 Pseudo-Elemente und Pseudo-Klassen
In CSS2 wird der Stil normalerweise Elementen abh@ngig von ihrer Position im Dokumentbaum
zugeordnet. Dieses einfache Modell ist f r viele F@lle ausreichend, aber einige gebr@uchliche
Publikationsszenarien k=nnen durch die Struktur des Dokumentbaums m=glicherweise nicht
realisiert werden. In HTML 4.0 beispielsweise (siehe [HTML40]) verweist kein Element auf die
erste Zeile eines Absatzes, und deshalb kann auch kein einfacher CSS-Selektor darauf verwei-
sen.
CSS f hrt das Konzept der Pseudo-Elemente und Pseudo-Klassen ein, um eine Formatierung
abh@ngig von Informationen zu erlauben, die außerhalb des Dokumentbaums liegen.
< 590 > Selektoren
Page size: 168,00 x 240,00 mm
· Pseudo-Elemente erzeugen Abstraktionen zum Dokumentbaum, die ber die von der
Dokumentsprache spezifizierten hinausgehen. Beispielsweise unterst tzen Dokumentspra-
chen keinen Mechanismus, um auf den ersten Buchstaben oder die erste Zeile eines Ele-
mentinhalts zuzugreifen. CSS-Pseudo-Elemente erlauben es Stylesheet-Entwicklern, auf
diese anderweitig nicht verf gbare Information zu verweisen. Pseudo-Elemente k=nnen
außerdem eine M=glichkeit f r Stylesheet-Entwickler darstellen, Inhalt Stil zuzuweisen, der
im Quelldokument nicht existiert (z. B. die Pseudo-Elemente :before und :after erm=glichen
erzeugten Inhalt).
· Pseudo-Klassen klassifizieren Elemente nach Charakteristika neben ihrem Namen, Attribu-
ten oder Inhalten; im Allgemeinen solche Charakteristika, die nicht vom Dokumentbaum
abgeleitet werden k=nnen. Pseudo-Klassen k=nnen dynamisch sein, das heißt, ein Element
kann eine Pseudo-Klasse erhalten oder verlieren, w@hrend der Benutzer mit dem Doku-
ment arbeitet. Die Ausnahme dazu ist ':first-child', das vom Dokumentbaum abgeleitet wer-
den kann. Die Pseudo-Klasse ':lang' kann in einigen F@llen vom Dokumentbaum abgeleitet
werden.
Weder Pseudo-Elemente noch Pseudo-Klassen erscheinen in der Dokumentquelle oder im
Dokumentbaum.
Pseudo-Klassen k=nnen berall in Selektoren auftreten, w@hrend Pseudo-Elemente nur nach
dem Subjekt des Selektors auftreten k=nnen.
F r die Namen von Pseudo-Elementen und Pseudo-Klassen wird die Groß-/Kleinschreibung
nicht ber cksichtigt.
Einige Pseudo-Klassen schließen sich wechselseitig aus, w@hrend andere gleichzeitig auf das-
selbe Element angewendet werden k=nnen. Falls Regeln einen Konflikt erzeugen, bestimmt die
normale Kaskadenreihenfolge das Ergebnis.
Konforme HTML-Benutzerprogramme d rfen alle Regeln mit :first-line oder :first-letter im
Selektor ignorieren oder alternativ nur eine Untermenge der Eigenschaften dieser Pseudo-Ele-
mente unterst tzen.
Cascading Style Sheets, Level 2
5.11 Pseudo-Klassen
5.11.1 Die Pseudo-Klasse :first-child
Die Pseudo-Klasse :first-child erzielt eine bereinstimmung mit einem Element, welches das
erste Kindelement eines anderen Elements ist.
Beispiel
Im folgenden Beispiel erzeugt der Selektor eine bereinstimmung mit jedem P-Element,
welches das erste Kindelement eines DIV-Elements ist. Die Regel unterdr ckt die Ein-
r ckung f r den ersten Absatz eines DIV:
DIV > P:first-child { text-indent: 0 }
Pseudo-Klassen < 591 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Dieser Selektor w rde mit dem P innerhalb des DIV des folgenden Ausschnitts bereinstim-
men:
<P> Das letzte P vor dem Hinweis.
<DIV class="note">
<P> Das erste P im Hinweis.
</DIV>
aber nicht mit dem zweiten P im folgenden Ausschnitt:
<P> Das letzte P vor dem Hinweis.
<DIV class="note">
<H2>Hinweis</H2>
<P> Das erste P in dem Hinweis.
</DIV>
Die folgende Regel setzt die Schriftgewichtung f r jedes EM-Element, das irgendein Nachfahre
eines P-Elements ist, das ein erstes untergeordnetes Element ist, auf 'bold':
P:first-child EM { font-weight : bold }
Beachten Sie, dass anonyme Boxen nicht Teil des Dokumentbaums sind und deshalb nicht
ber cksichtigt werden, wenn das erste untergeordnete Element berechnet wird.
Beispiel
Beispielsweise ist das EM in
<P>abc <EM>default</EM>
das erste untergeordnete Element von P.
Die beiden folgenden Selektoren sind @quivalent:
Cascading Style Sheets, Level 2
* > A:first-child /* A ist das erste untergeorndete
Element eines beliebigen Elements */
A:first-child /* Wie oben */
5.11.2 Die Link-Pseudo-Klassen :link und :visited
Benutzerprogramme zeigen normalerweise nicht besuchte Links anders an als bereits besuchte.
CSS unterst tzt die Pseudo-Klassen ':link' und ':visited', um sie voneinander zu unterscheiden:
·· Die Pseudo-Klasse :link gilt f r Links, die noch nicht besucht wurden.
Die Pseudo-Klasse :visited gilt f r einen Link, nachdem er vom Benutzer besucht wurde.
Hinweis: Nach einer bestimmten Zeit k=nnen Benutzerprogramme einen bereits besuchten
Link wieder in den unbesuchten Status versetzen, ':link'. n
< 592 > Selektoren
Page size: 168,00 x 240,00 mm
Anmerkung der bersetzer: Die meisten Browser versetzen einen Link nicht
willk rlich in den Zustand „unbesucht“. In der Regel kann der Benutzer selbst bestim-
men, wann dies geschehen soll. Im Mozilla sieht der entsprechende Dialog zum Beispiel
wie folgt aus:
Die beiden Status schließen sich wechselseitig aus.
Die Dokumentsprache legt fest, welche Elemente Hyperlink-Quellanker sind. In HTML 4.0 bei-
Cascading Style Sheets, Level 2
spielsweise beziehen sich die Link-Pseudo-Klassen auf A-Elemente mit einem „href“-Attribut.
Die beiden folgenden CSS2-Deklarationen haben also eine @hnliche Wirkung:
A:link { color: red }
:link { color: red }
Beispiel
Wenn der folgende Link
<A class="external"
href="[Link] link</A>
besucht wurde, bewirkt die folgende Regel
[Link]:visited { color: blue }
dass er blau dargestellt wird.
Pseudo-Klassen < 593 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
5.11.3 Die dynamischen Pseudo-Klassen :hover, :active und :focus
Interaktive Benutzerprogramme @ndern manchmal die Darstellung, um damit auf Aktionen der
Benutzer zu reagieren. CSS unterst tzt drei Pseudo-Klassen f r allgemeine F@lle:
· Die Pseudo-Klasse :hover wird angewendet, wenn der Benutzer ein Element zwar markiert
(mit irgendeinem Zeigeger@t), es aber nicht aktiviert. Beispielsweise k=nnte ein Benutzer-
programm diese Pseudo-Klasse anwenden, wenn der Cursor (Mauszeiger) ber eine von
einem Element erzeugte Box geschoben wird. Benutzerprogramme, die keine interaktiven
Medien unterst tzen, unterst tzen auch diese Pseudo-Klasse nicht. Einige konforme Benut-
zerprogramme, die interaktive Medien unterst tzen sind m=glicherweise ebenfalls nicht in
der Lage, diese Pseudo-Klasse zu unterst tzen (z. B. ein Stiftger@t).
· Die Pseudo-Klasse :active gilt, w@hrend ein Element vom Benutzer aktiviert wird. Beispiels-
weise k=nnte das zwischen den Zeitpunkten sein, wo der Benutzer die Maustaste dr ckt
und sie wieder losl@sst.
· Die Pseudo-Klasse :focus gilt, w@hrend ein Element den Fokus hat (es akzeptiert Tastatur-
ereignisse oder andere Arten der Texteingabe).
Diese Pseudo-Klassen schließen sich nicht wechselseitig aus. Ein Element kann mit mehreren
davon gleichzeitig bereinstimmen.
CSS definiert nicht, welche Elemente sich in den oben beschriebenen Status befinden k=nnen,
oder wie man in einen der Status gelangt oder ihn verl@sst. Mit Hilfe von Skripting kann
bestimmt werden, ob Elemente auf Benutzerereignisse reagieren oder nicht, und unterschiedli-
che Ger@te und Benutzerprogramme k=nnen unterschiedliche Methoden aufweisen, wie auf
Elemente gezeigt wird bzw. wie diese aktiviert werden.
Benutzerprogramme m ssen bei berg@ngen zwischen den einzelnen Pseudo-Klassen ein aktu-
ell angezeigtes Dokument nicht unbedingt neu aufbauen. Beispielsweise k=nnte ein Stylesheet
angeben, dass die 'font-size' eines :active-Links gr=ßer sein soll als die eines nicht aktiven Links.
Weil das jedoch zur Folge haben kann, dass die Buchstaben ihre Position ver@ndern, wenn der
Benutzer den Link ausw@hlt, kann das Benutzerprogramm die entsprechende Stilregel ignorie-
Cascading Style Sheets, Level 2
ren.
Beispiel
A:link { color: red } /* nicht besuchte Links */
A:visited { color: blue } /* besuchte Links */
A:hover { color: yellow } /* Benutzer selektiert */
A:active { color: lime } /* Aktive Links */
Beachten Sie, dass die Regel A:hover nach den Regeln f r A:link und A:visited platziert werden
muss, weil die kaskadierenden Regeln sonst die 'color'-Eigenschaft der Regel f r A:hover ver-
bergen. Weil A:active hinter A:hover platziert ist, wird analog dazu die aktive Farbe (lime) ange-
wendet, wenn der Benutzer das A-Element markiert und aktiviert.
Ein Beispiel f r die Kombination dynamischer Pseudo-Klassen:
A:focus { background: yellow }
A:focus:hover { background: white }
Der letzte Selektor erzielt bereinstimmungen mit A-Elementen, die sich in den Pseudo-Klas-
sen :focus und :hover befinden.
< 594 > Selektoren
Page size: 168,00 x 240,00 mm
Weitere Informationen ber die Darstellung von Fokusumrissen finden Sie im Abschnitt ber
dynamische fokussierte Umrisse.
Hinweis: In CSS1 war die Pseudo-Klasse ':active' wechselseitig ausschließend zu ':link' und ':vi-
sited'. Das ist jetzt nicht mehr der Fall. Ein Element kann sowohl ':visited' als auch ':active' (oder
':link' und ':active' sein), und die normalen Kaskadenregeln bestimmen, welche Eigenschaften
gelten. n
5.11.4 Die Sprach-Pseudo-Klasse :lang
Wenn die Dokumentsprache angibt, wie die menschliche Sprache eines Elements ermittelt
wird, ist es m=glich, Selektoren in CSS zu schreiben, die eine bereinstimmung f r ein Element
abh@ngig von seiner Sprache erzielen. In HTML [HTML40] beispielsweise wird die Sprache
durch eine Kombination des Attributs „lang“, das META-Element und m=glicherweise Pro-
tokollinformationen (wie beispielsweise HTTP-Header) ermittelt. XML verwendet das Attribut
xml:lang, und es kann andere von der Dokumentsprache abh@ngige Methoden geben, um die
Sprache zu ermitteln.
Die Pseudo-Klasse ':lang(C)' erzielt eine bereinstimmung, wenn das Element in der Sprache C
geschrieben ist. Hier ist C ein Sprachcode, wie in HTML 4.0 [HTML40] und RFC 1766
[RFC1766] angegeben. Er wird genau so verglichen wie f r den '|='-Operator.
Beispiel
Die folgenden Regeln setzen die Anf hrungszeichen f r ein HTML-Dokument, das ent-
weder in Franz=sisch oder in Deutsch verfasst ist:
HTML:lang(fr) { quotes: '\( ' ' \;' }
HTML:lang(de) { quotes: '\;' '\(' '\2039' '\203A' }
:lang(fr) > Q { quotes: '\( ' ' \;' }
:lang(de) > Q { quotes: '\;' '\(' '\2039' '\203A' }
Cascading Style Sheets, Level 2
Das zweite Regelpaar setzt die 'quotes'-Eigenschaft f r Q-Elemente entsprechend der Sprache
seines bergeordneten Elements. Das geschieht, weil die Auswahl der Anf hrungszeichen nor-
malerweise auf dem Element basiert, das das Anf hrungszeichen umschließt, und nicht auf dem
eigentlichen Zitat: wie hier das franz=sische Wort, „t l‘improvisite“ inmitten eines deutschen
Texts deutsche Anf hrungszeichen verwendet.
5.12 Pseudo-Elemente
5.12.1 Das Pseudo-Element :first-line
Das Pseudo-Element :first-line wendet spezielle Stile auf die erste formatierte Zeile eines
Absatzes an. Ein Beispiel:
P:first-line { text-transform: uppercase }
Die obige Regel bedeutet, „tausche die Buchstaben der ersten Zeile jedes Absatzes in Groß-
buchstaben“. Der Selektor „P:first-line“ erzielt keine bereinstimmung mit einem realen
Pseudo-Elemente < 595 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
HTML-Element. Sie erzielt eine bereinstimmung mit einem Pseudo-Element, das konforme
Benutzerprogramme am Anfang jedes Absatzes einf gen.
Beachten Sie, dass die L@nge der ersten Zeile von verschiedenen Faktoren abh@ngig ist, unter
anderem der Seitenbreite, der Schriftgr=ße usw. Damit muss ein gew=hnlicher HTML-Absatz,
wie beispielsweise
<P>Dies ist ein relativ langer
HTML-Absatz, der in mehrere Zeilen
umbrochen wird. Die erste Zeile wird
durch eine fiktive Tag-Folge
identifiziert. Die anderen Zeilen
werden wie normale Zeilen im Absatz
behandelt.</P>
dessen Zeilen wie folgt umbrochen werden
DIES IST EIN RELATIV LANGER HTML-ABSATZ,
der in mehrere Zeilen umbrochen wird. Die
erste Zeile wird durch eine fiktive Tag-Folge
identifiziert. Die anderen Zeilen werden wie
normale Zeilen im Absatz behandelt.
wie folgt von Benutzerprogrammen „umgeschrieben“ werden, um die fiktive Tag-Folge f r
:first-line einzuf gen. Diese fiktive Tag-Folge hilft zu zeigen, wie Eigenschaften vererbt werden.
<P><P:first-line> Dies ist ein relativ langer HTML-
Absatz, </P:first-line> der in mehrere Zeilen umbrochen
wird. Die erste Zeile wird durch eine fiktive Tag-Folge
identifiziert. Die anderen Zeilen werden wie
normale Zeilen im Absatz behandelt.</P>
Wenn ein Pseudo-Element ein reales Element durchbricht, kann der gew nschte Effekt h@ufig
Cascading Style Sheets, Level 2
durch eine fiktive Tag-Folge beschrieben werden, die das Element schließt und dann erneut =ff-
net. Wenn wir also den obigen Absatz mit einem SPAN-Element versehen:
<P><SPAN class="test"> Dies ist ein relativ langer
HTML-Absatz, der in mehrere Zeilen umbrochen
wird.</SPAN> Die erste Zeile wird durch eine
fiktive Tag-Folge identifziert. Die anderen Zeilen
werden wienormale Zeilen im Absatz behandelt.</P>
k=nnte das Benutzerprogramm geeignete Start- und Ende-Tags f r SPAN erzeugen, wenn es
die fiktive Tag-Folge f r :first-line einf gt.
<P><P:first-line><SPAN class="test">Dies ist ein
relativ langer HTML-Absatz,</SPAN></P:first-line><SPAN
class="test"> der in mehrere Zeilen umbrochen
wird.</SPAN> Die erste Zeile wird durch eine fiktive
Tag-Folge identifziert. Die anderen Zeilen werden wie
normale Zeilen im Absatz behandelt.</P>
Das Pseudo-Element :first-line kann nur einem Element auf Blockebene zugeordnet werden.
< 596 > Selektoren
Page size: 168,00 x 240,00 mm
Das Pseudo-Element :first-line ist @hnlich einem Element auf Inline-Ebene, aber mit einigen Ein-
schr@nkungen. Nur die folgenden Eigenschaften gelten f r ein :first-line-Pseudo-Element:
Schrifteigenschaften, Farbeigenschaften, Hintergrundeigenschaften, 'word-spacing', 'letter-spa-
cing', 'text-decoration', 'vertical-align', 'text-transform', 'line-height', 'text-shadow' und 'clear' .
Anmerkung der bersetzer: Folgendes ist eine Erg@nzung aus den CSS2-Errata:
Im Fall, dass eine bestimmte erste Zeile sowohl die erste Zeile eines Block-Elements A
als auch die erste Zeil des Vorfahren B von A ist, sieht die fiktive Tag-Folge so aus:
<B>...<A>...<B:first-line><A:first-line>
This is the first line</A:first-line></B:first-line>
Alle fiktiven Tags f r die erste Zeile befinden sich innerhalb des kleinsten, umgebenden
Block-Elements. Des Weiteren ist die Verschachtelungsreihenfolge der fiktiven Tags
A:first-line und B-first-line die gleiche wie die der Elemente A und B.
Die „erste formatierte Zeile“ eines Elements auf Blockebene ist die erste Zeile im Ele-
mentfluss, das heißt, gleitende oder absolut positionierte Elemente werden diesbez g-
lich ignoriert.
Zum Beispiel wirkt sich in
<div>
<p style="float: left">Floating paragraph...</p>
<p>First line starts here...</p>
</div>
der Selektor 'div:first-line' auf die erste Zeile des zweiten p aus, weil das erste p aus
dem Fluss genommen ist (ein gleitendes Element).
5.12.2 Das Pseudo-Element :first-letter
Cascading Style Sheets, Level 2
Das Pseudo-Element :first-letter kann f r Kapit@lchen am Anfang oder Großbuchstaben, die
sich ber die Zeile hinaus nach unten erstrecken, verwendet werden. Beides sind gebr@uchliche
typographische Effekte. Diese Art Anfangsbuchstabe ist @hnlich einem Element auf Inline-Ebene,
wenn seine 'float'-Eigenschaft gleich 'none' ist, andernfalls ist es @hnlich einem Floating-Element.
Die folgenden Eigenschaften gelten f r das Pseudo-Element :first-letter: Schrifteigenschaften,
Farbeigenschaften, Hintergrundeigenschaften, 'text-decoration', 'vertical-align' (nur, wenn 'float'
gleich 'none' ist), 'text-transform', 'line-height', Randeigenschaften, Auff lleigenschaften, Rah-
meneigenschaften, 'float', 'text-shadow' und 'clear'.
Beispiel
Das folgende CSS2 erzeugt ein Kapit@lchen als Anfangsbuchstaben, der sich ber zwei
Zeilen nach unten erstreckt:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>Anfangsbuchstabe, der sich Uber die Zeile nach unten erstreckt</TITLE>
<STYLE type="text/css">
P { font-size: 12pt; line-height: 14pt }
P:first-letter { font-size: 200%; font-style: italic;
Pseudo-Elemente < 597 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
font-weight: bold; float: left }
SPAN { text-transform: uppercase }
</STYLE>
</HEAD>
<BODY>
<P><SPAN>Die ersten</SPAN> paar W^rter eines Artikels in der
Wochenzeitschrift.</P>
</BODY>
</HTML>
Dieses Beispiel k=nnte wie folgt formatiert werden:
Die fiktive Tag-Folge sieht wie folgt aus:
<P>
<SPAN>
<P:first-letter>
D
</P:first-letter>ie ersten
</SPAN>
paar W^rter eines Artikels in der Wochenzeitschrift.
</P>
Beachten Sie, dass die Pseudo-Element-Tags f r :first-letter an den Inhalt (d. h. den Anfangs-
Cascading Style Sheets, Level 2
buchstaben) angrenzen, w@hrend das Start-Tag f r das Pseudo-Element :first-line unmittelbar
hinter dem Start-Tag des Elements eingef gt wird, dem es zugeordnet ist.
Anmerkung der bersetzer: Die obige Abbildung zeigt die Darstellung des Bei-
spiels im Mozilla 1.1.
Um eine Formatierung mit traditionellen Kapit@lchen ber Zeilen nach unten zu erzielen, k=n-
nen Benutzerprogramme Schriftgr=ßen ann@hern, beispielsweise zur Ausrichtung von Grund-
linien. Außerdem kann der Glyphenumriss f r die Formatierung ber cksichtigt werden.
Die Interpunktion (also die Zeichen, die in Unicode [UNICODE] in den Interpunktionsklassen
„open“ (Ps), „close“ (Pe) und „other“ (Po) definiert sind), die dem ersten Buchstaben voraus-
geht, sollte ber cksichtigt werden, beispielsweise wie folgt:
< 598 > Selektoren
Page size: 168,00 x 240,00 mm
Das Pseudo-Element :first-letter erzielt eine bereinstimmung nur mit Teilen der Elemente auf
Blockebene.
Anmerkung der bersetzer: F r die oben gezeigte Abbildung wurden die glei-
chen Formatierungsregeln benutzt, wie f r das vorherige Beispiel. Die relevante HTML-
Zeile sieht wie folgt aus:
<p>"Lieber einen Spatz in der Hand als eine Taube auf dem Dach", sagt ein
altes Sprichwort</p>
Auf den ersten Blick funktioniert die Ber cksichtigung von Interpunktionszeichen gut.
Ersetzt man jedoch die englischen Anf hrungszeichen durch andere, sieht das Ergebnis
wie folgt aus:
Die Zeile
<p>\;Lieber einen Spatz in der Hand als eine Taube auf dem Dach\(, sagt ein
altes Sprichwort</p>
produziert im Mozilla 1.1 die nachfolgende Darstellung.
Cascading Style Sheets, Level 2
Hier hat also die Erkennung des Anf hrungszeichens nicht funktioniert. Dabei blieb es
auch nach dem Umstieg auf XHTML und ordentlicher Deklarierung sowohl der Zei-
chenkodierung als auch der Sprache.
Einige Sprachen haben m=glicherweise spezifische Regeln, wie bestimmte Buchstabenkombina-
tionen zu behandeln sind. Im Niederl@ndischen beispielsweise sollten bei der Buchstabenkom-
bination „ij“ am Anfang eines Wortes innerhalb des Pseudo-Eements :first-letter beide Buchsta-
ben ber cksichtigt werden.
Pseudo-Elemente < 599 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Beispiel
Das folgende Beispiel zeigt, wie berlappende Pseudo-Elemente zusammenarbeiten
k=nnen. Der erste Buchstabe jedes P-Elements wird gr n mit einer Schriftgr=ße von
'24pt' dargestellt. Die restliche erste formatierte Zeile ist 'blue', w@hrend der restliche
Absatz 'red' ist.
P { color: red; font-size: 12pt }
P:first-letter { color: green; font-size: 200% }
P:first-line { color: blue }
<P>Text, der in zwei Zeilen angezeigt wird</P>
Angenommen, vor dem Wort „Zeilen“ erfolgt ein Zeilenumbruch, dann k=nnte die fiktive Tag-
Folge f r diesen Abschnitt wie folgt aussehen:
<P>
<P:first-line>
<P:first-letter>
T
</P:first-letter>ext, der in zwei
</P:first-line>
Zeilen angezeigt wird
</P>
Beachten Sie, dass sich das Element :first-letter innerhalb des Elements :first-line befindet.
Eigenschaften, die f r :first-line gesetzt werden, werden von :first-letter geerbt, aber ber-
schrieben, wenn dieselbe Eigenschaft f r :first-letter gesetzt ist.
5.12.3 Die Pseudo-Elemente :before und :after
Die Pseudo-Elemente ':before' und ':after' k=nnen genutzt werden, um erzeugten Inhalt vor
oder hinter dem Inhalt eines Elements einzuf gen. Sie werden im Abschnitt ber erzeugten
Cascading Style Sheets, Level 2
Text erkl@rt.
H1:before {content: counter(chapno, upper-roman) ". "}
Wenn die Pseudo-Elemente :first-letter und :first-line mit :before und :after kombiniert wer-
den, beziehen sie sich auf den ersten Buchstaben oder die erste Zeile des Elements, inklusive
des eingef gten Texts.
Beispiel
[Link]:before {content: "Special! "}
[Link]:first-letter {color: #ffd800}
Damit wird das „S“ von „Special!“ in Gold dargestellt.
< 600 > Selektoren
Page size: 168,00 x 240,00 mm
6 Eigenschaftswerte zuweisen,
Kaskaden und Vererbung
6.1 Spezifizierte, berechnete und [Link] Werte
Nachdem ein Benutzerprogramm ein Dokument geparst und einen Dokumentbaum aufgebaut
hat, muss es f r jedes Element in dem Baum jeder Eigenschaft einen Wert zuweisen, die sich
auf den Ziel-Medientyp bezieht.
Der endg ltige Wert einer Eigenschaft ist das Ergebnis einer dreistufigen Berechnung: Der
Wert wird ber die Spezifizierung ermittelt (der „spezifizierte Wert“), dann gegebenenfalls in
einen absoluten Wert aufgel=st (den „berechneten Wert“) und schließlich entsprechend der
Einschr@nkungen der lokalen Umgebung umgewandelt (der „tats@chliche Wert“).
6.1.1 Spezifizierte Werte
Benutzerprogramme m ssen einer Eigenschaft zun@chst einen spezifizierten Wert zuweisen,
basierend auf den folgenden Mechanismen (in der Priorit@t ihrer Reihenfolge):
1. Falls die Kaskade einen Wert ergibt, wird dieser verwendet.
2. Wird die Eigenschaft dagegen geerbt, wird der Wert des bergeordneten Elements ver-
wendet, im allgemeinen der berechnete Wert.
3. Andernfalls wird der Ausgangswert der Eigenschaft verwendet. Der Ausgangswert einer
Eigenschaft ist in der Eigenschaftsdefinition festgelegt.
Weil die Wurzel des Dokumentbaums kein bergeordnetes Element hat, kann sie keine Werte
von einem bergeordneten Element verwenden; in diesem Fall wird gegebenenfalls der Aus-
gangswert verwendet.
Cascading Style Sheets, Level 2
Anmerkung der bersetzer: Da der Begriff der Kaskade erst sp@ter erkl@rt wird,
soll noch eine andere Umschreibung erkl@ren, was hier gemeint ist: Der Wert, den eine
Eigenschaft bekommt (z. B. die Eigenschaft Schriftgr=ße), wird bestimmt durch die
Angabe im Stylesheet (1); gibt es f r ein Element keinen Wert, wird der Wert des ers-
ten bergeordneten Elements benutzt, f r den ein Wert angegeben wurde (2); falls auch
dort kein Wert gefunden wird, gilt der Wert, der in dieser Spezifikation festgelegt wird
(3).
6.1.2 Berechnete Werte
Angegebene Werte k=nnen absolut sein (das heißt, sie werden nicht relativ zu einem anderen
Wert angegeben, wie beispielsweise in 'red' oder '2mm') oder relativ sein (das heißt, sie sind
relativ zu anderen Werten spezifiziert, wie beispielsweise 'auto', '2em' und '12%'). F r absolute
Werte ist keine Verarbeitung erforderlich, um den berechneten Wert zu ermitteln.
Eigenschaftswerte zuweisen, Kaskaden und Vererbung < 601 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Relative Werte dagegen m ssen in berechnete Werte umgewandelt werden: Prozentwerte
m ssen mit einem Referenzwert multipliziert werden (wobei jede Eigenschaft genau definiert,
worum es sich dabei handelt), Werte mit relativen Einheiten (em, ex, x), m ssen absolut
gemacht werden, indem sie anhand der entsprechenden Schrift- oder Pixelgr=ße berechnet
werden, 'auto'-Werte m ssen berechnet werden, indem die f r jede Eigenschaft angegebenen
Formeln ausgewertet werden, bestimmte Schl sselw=rter ('smaller', 'bolder', 'inherit') m ssen
durch ihre entsprechenden Definitionen ersetzt werden.
In den meisten F@llen erben Elemente berechnete Werte. Es gibt jedoch einige Eigenschaften,
deren spezifizierte Werte geerbt werden k=nnen (z. B. der Zahlenwert f r die Eigenschaft 'line-
height'). Wenn untergeordnete Elemente den berechneten Wert nicht erben, dann ist dies in
der Eigenschaftsdefinition beschrieben.
6.1.3 [Link] Werte
Ein berechneter Wert kann im Prinzip sofort verwendet werden, aber m=glicherweise kann ein
Benutzerprogramm den Wert in einer bestimmten Umgebung nicht nutzen. Beispielsweise kann
es sein, dass ein Benutzerprogramm Rahmen nur mit ganzzahligen Pixelbreiten darstellen kann
und deshalb einen ann@hernden Wert f r die berechnete Breite verwenden muss. Der tats@ch-
liche Wert ist der berechnete Wert, nachdem die Ann@herung darauf angewendet wurde.
6.2 Vererbung
Einige Werte werden von den untergeordneten Elementen eines Elements im Dokumentbaum
geerbt. Jede Eigenschaft definiert, ob sie geerbt wird oder nicht.
Angenommen, es gibt ein H1-Element mit einem darin enthaltenen Betonungselement (EM):
<H1>Die dberschrift <EM>ist</EM> wichtig!</H1>
Cascading Style Sheets, Level 2
Wurde dem EM-Element keine Farbe zugeordnet, erbt das betonte „ist“ die Farbe des berge-
ordneten Elements, wenn also H1 die Farbe blau hat, ist das EM-Element auch blau.
Um eine „Standard“-Stileigenschaft f r ein Dokument einzurichten, k=nnen die Autoren die
Eigenschaft in der Wurzel des Dokumentbaums festlegen. In HTML beispielsweise k=nnen die
HTML- oder BODY-Elemente diese Funktion bernehmen. Beachten Sie, dass das auch dann
funktioniert, wenn der Autor das BODY-Tag in der HTML-Quelle wegl@sst, weil der HTML-
Parser das fehlende Tag einf gt.
Anmerkung der bersetzer: Das Weglassen von Start- oder End-Tags (oder von
beiden) ist eine Eigenschaft, die HTML dank seiner SGML-Abstammung besitzt; dort
heißt die M=glichkeit „Tag-Minimierung“. Die Tag-Minimierung ist wohldefiniert und in
der HTML-DTD festgehalten. In der Praxis ist es oft vorgekommen, dass Autoren
irgendwelche Tags weggelassen haben. Da die bekannten Web-Browser kein wirkliches
Parsing „gegen die DTD“ machen, tolerieren sie fast jeden Fehler; der Qualit@t des im
Web zu findenden HTML hat das nicht gedient.
Seit XML und damit auch XHTML geh=rt die Tag-Minimierung der Vergangenheit an:
Bei XHTML m ssen alle Tags angegeben werden.
< 602 > Eigenschaftswerte zuweisen, Kaskaden und Vererbung
Page size: 168,00 x 240,00 mm
Weil beispielsweise die Eigenschaft 'color' geerbt ist, erben alle Ableitungen des BODY-Ele-
ments die Farbe 'black':
BODY { color: black; }
Angegebene Prozentwerte werden nicht vererbt, berechnete Werte dagegen schon.
Betrachten Sie beispielsweise das folgende Stylesheet:
BODY { font-size: 10pt }
H1 { font-size: 120% }
und diesen Ausschnitt aus einem Dokument:
<BODY>
<H1>Eine <EM>große</EM> dberschrift</H1>
</BODY>
Die Eigenschaft 'font-size' f r das H1-Element hat den berechneten Wert '12 pt' (120% von 10
pt, dem Wert des bergeordneten Elements). Weil der berechnete Wert von 'font-size' geerbt
ist, hat das EM-Element ebenfalls den berechneten Wert '12pt'. Falls dem Benutzerprogramm
die Schrift nicht in12pt zur Verf gung steht, k=nnte der tats@chliche Wert sowohl f r H1 als
auch f r EM beispielsweise '11pt' sein.
Anmerkung der bersetzer: W rde statt des berechneten Werts doch der
angegebene Prozentwert vererbt, h@tte das EM-Element ebenfalls den Wert 120%.
Diese 120% beziehen sich auf die aktuelle Schriftgr=ße, das sind hier 12pt. Folglich
w rde die Schriftgr=ße des EM-Inhalts bei 1,2 · 12pt = 14,4pt liegen. Der Inhalt von ein-
gebetteten Elementen w rde also fortlaufend gr=ßer dargestellt. Es macht daher nur
Sinn, den berechneten absoluten Wert zu vererben.
Cascading Style Sheets, Level 2
6.2.1 Der Wert 'inherit'
Jede Eigenschaft kann außerdem einen angegebenen Wert von 'inherit' haben, das heißt, f r ein
bestimmtes Element verwendet die Eigenschaft denselben berechneten Wert wie die Eigen-
schaft f r das bergeordnete Element des Elements. Der geerbte Wert, der normalerweise
nur als Fallback-Wert verwendet wird, kann erzwungen werden, indem 'inherit' explizit gesetzt
wird.
Anmerkung der bersetzer: In den Errata ist zu lesen: „Der Wert 'inherit' sorgt
daf r, dass der Eigenschaftswert vererbt wird. Dies gilt auch f r Eigenschaften, deren
Werte normalerweise nicht vererbt werden.“
Vererbung < 603 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Beispiel
Im nachfolgenden Beispiel sind die Eigenschaften 'color' und 'background' auf das
BODY-Element gesetzt. F r alle anderen Elemente wird der Wert von 'color' geerbt
und der Hintergrund ist transparent. Sind diese Regeln Teile des Stylesheets des Benut-
zers, wird im gesamten Dokument schwarzer Text auf weißem Hintergrund erzwun-
gen.
BODY {
color: black !important;
background: white !important;
}
* {
color: inherit !important;
background: transparent;
}
6.3 Die @import-Regel
Die '@import'-Regel erlaubt den Benutzern, Formatierungsregeln aus anderen Stylesheets zu
importieren. Alle @import-Regeln m ssen allen anderen Regelmengen im Stylesheet voraus-
gehen. Dem Schl sselwort '@import' muss der URI des einzubindenden Stylesheets folgen.
Auch eine Zeichenkette ist erlaubt; sie wird interpretiert, als w@re sie in url(...) eingeschlossen.
Die nachfolgenden Zeilen sind @quivalent und demonstrieren beide '@import'-Syntaxformen
(eine mit „url()“, die andere mit einer Zeichenkette):
@import "[Link]";
@import url("[Link]");
Damit Benutzerprogramme vermeiden k=nnen, Ressourcen f r nicht unterst tzte Medien-
typen zu laden, k=nnen Autoren medienabh@ngige @import-Regeln angeben. Diese bedingten
Cascading Style Sheets, Level 2
Importe listen hinter dem URI die durch Kommas voneinander getrennten Medientypen auf.
Die nachfolgenden Regeln haben dieselbe Wirkung, als w@re das importierte Stylesheet in eine
@media-Regel f r dasselbe Medium eingepackt, sie ersparen dem Benutzerprogramm jedoch
einen sinnlosen Download.
@import url("[Link]") print;
@import url("[Link]") projection, tv;
Wenn berhaupt keine Medientypen angegeben sind, ist der Import unbedingt. Die Angabe von
'all' f r das Medium hat dieselbe Wirkung.
< 604 > Eigenschaftswerte zuweisen, Kaskaden und Vererbung
Page size: 168,00 x 240,00 mm
6.4 Die Kaskade
Stylesheets k=nnen drei verschiedene Urspr nge haben: Autor, Benutzer und Benutzerpro-
gramm.
Autor
Der Autor gibt Stylesheets f r ein Quelldokument gem@ß den Konventionen der Doku-
mentsprache an. In HTML beispielsweise k=nnen Stylesheets in das Dokument aufgenom-
men oder extern verkn pft werden.
Benutzer
Der Benutzer kann Stilinformationen f r ein bestimmtes Dokument angeben. Beispiels-
weise kann der Benutzer eine Datei angeben, die ein Stylesheet enth@lt, oder das Benutzer-
programm kann eine Schnittstelle bereitstellen, die ein Benutzer-Stylesheet erzeugt (oder
sich so verh@lt, als t@te sie das).
Benutzerprogramm
Konforme Benutzerprogramme m ssen vor allen anderen Stylesheets f r ein Dokument
ein Standard-Stylesheet anwenden (oder sich so verhalten, als ob sie das t@ten). Das Stan-
dard-Stylesheet eines Benutzerprogramms sollte die Elemente der Dokumentsprache so
pr@sentieren, dass sie den allgemeinen Darstellungserwartungen f r die Dokumentsprache
entsprechen (z. B. wird das EM-Element in HTML bei visuellen Browsern unter Verwen-
dung einer kursiven Schrift dargestellt). Ein empfohlenes Standard-Stylesheet f r HTML
4.0-Dokumente finden Sie unter „Ein Beispiel-Stylesheet f r HTML 4.0“ (Anhang A).
Beachten Sie, dass sich das Standard-Stylesheet @ndern kann, wenn der Benutzer die Sys-
temeinstellungen ver@ndert (z. B. die Systemfarben) Aufgrund der Einschr@nkungen der
internen Implementierung des Benutzerprogramms ist es jedoch unter Umst@nden nicht
m=glich, die Werte im Standard-Stylesheet zu @ndern.
Stylesheets aus diesen drei Urspr ngen berlappen sich im G ltigkeitsbereich und arbeiten
Cascading Style Sheets, Level 2
gem@ß der Kaskade zusammen.
Die CSS-Kaskade ordnet jeder Stilregel eine Gewichtung zu. Gelten mehrere Regeln, setzt sich
diejenige mit der h=chsten Gewichtung durch.
Standardm@ßig haben Regeln in Autoren-Stylesheets mehr Gewicht als Regeln in Benutzer-
Stylesheets. Priorit@t haben jedoch immer „!important“-Regeln. Alle Benutzerregeln und Auto-
renregeln haben mehr Gewicht als die Regeln im Standard-Stylesheet des Benutzerprogramms.
Importierte Stylesheets sind ebenfalls kaskadenartig angeordnet, und ihre Gewichtung ist von
ihrer Import-Reihenfolge abh@ngig. Regeln, die in einem bestimmten Stylesheet angegeben sind,
berschreiben Regeln des gleichen Gewichts, die aus anderen Stylesheets importiert werden.
Importierte Stylesheets k=nnen wiederum selbst importieren und andere Stylesheets ber-
schreiben, was rekursiv erfolgt, und wof r dieselben Priorit@tsregeln gelten.
6.4.1 Kaskaden-Reihenfolge
Um den Wert f r eine Element/Eigenschaft-Kombination zu ermitteln, wenden die Benutzer-
programme die folgende Sortierreihenfolge an:
1. Es werden alle Deklarationen ermittelt, die sich auf das betreffende Element und die Eigen-
schaft f r den Ziel-Medientyp beziehen. Deklarationen werden angewendet, wenn der ent-
sprechenden Selektor mit dem betreffenden Element bereinstimmt.
Die Kaskade < 605 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
2. Prim@r werden die Deklarationen nach Gewichtung und Ursprung sortiert: F r normale
Deklarationen berschreiben Autor-Stylesheets die Benutzer-Stylesheets, die wiederum
das Standard-Stylesheet berschreiben. F r „!important“-Deklarationen berschreiben
Benutzer-Stylesheets Autor-Stylesheets, die wiederum das Standard-Stylesheet berschrei-
ben. Eine „!important“-Deklaration berschreibt normale Deklarationen. Ein importiertes
Stylesheet hat denselben Ursprung wie das Stylesheet, von dem es importiert wurde.
3. Die zweite Sortierung erfolgt nach der Spezifit@t des Selektors: Spezifischere Selektoren
berschreiben allgemeinere Selektoren. Pseudo-Elemente und Pseudo-Klassen werden als
normale Elemente bzw. Klassen betrachtet.
4. Schließlich werden sie nach der vorgegebenen Reihenfolge sortiert: Haben zwei Regeln die-
selbe Gewichtung, denselben Ursprung und dieselbe Spezifit@t, erh@lt die jeweils zuletzt
angegebene den Vorrang. Regeln in importierten Stylesheets werden als vor allen anderen
Regeln im eigentlichen Stylesheet befindlich betrachtet.
Neben der Einstellung „!important“ f r einzelne Deklarationen erteilt diese Strategie den Style-
sheets des Autors eine h=here Gewichtung als denen des Lesers. Deshalb ist es wichtig, dass
das Benutzerprogramm dem Benutzer die M=glichkeit gibt, die Beeinflussung durch ein
bestimmtes Stylesheet zu deaktivieren, beispielsweise in einem Pulldown-Men .
6.4.2 !important-Regeln
CSS versucht, einen Leistungsausgleich zwischen Stylesheets des Autors und des Benutzers
herzustellen. Standardm@ßig berschreiben die Regeln im Stylesheet eines Autors diejenigen
aus dem Stylesheet eines Benutzers (siehe Kaskadenregel 3).
Des Ausgleichs halber erh@lt jedoch eine „!important“-Deklaration (die Schl sselw=rter „!“
und „important“ folgen der Deklaration) Priorit@t gegen ber einer normalen Deklaration.
Sowohl Autor- als auch Benutzer-Stylesheets k=nnen „!important“-Deklarationen enthalten,
und die „!important“-Regeln des Benutzers berschreiben die „!important“-Regeln des Autors.
Dieses Funktionsmerkmal von CSS verbessert den Zugriff auf Dokumente, indem es Benutzern
Cascading Style Sheets, Level 2
mit speziellen Anforderungen (große Schriften, Farbkombinationen usw.) die Kontrolle ber
die Darstellung erteilt.
Hinweis: Dies ist eine semantische Onderung gegen ber CSS1. In CSS1 hatten die „!impor-
tant“-Regeln des Autors Priorit@t gegen ber den „!important“-Regeln des Benutzers. n
Anmerkung der bersetzer: Die Festlegung der Semantik in der oben beschrie-
benen Form ist sinnvoll: Beispielsweise k=nnte ein Benutzer mit Sehschw@chen die
Schriftgr=ße auf einen sehr großen Wert setzen, damit er den Text berhaupt lesen
kann. H@tte das Stylesheet des Autors trotz einer !important-Regel des Benutzers Vor-
rang, so w@re eine Seite in diesem Fall gar nicht mehr zu gebrauchen.
Autoren sollten deshalb die Formatierung ihrer Seiten sehr flexibel zum Beispiel mit
relativen CSS-Werten steuern. Es ist niemals ausgeschlossen, dass Einstellungen des
Benutzers diejenigen des Autors berschreiben. Auch wenn es hier um CSS2 geht und
derzeit die Browser noch keine vollst@ndige Unterst tzung anbieten, hat diese Empfeh-
lung bestand. Denn tats@chlich k=nnen Benutzer ja schon seit langem in ihren Browsern
einstellen, ob Schriftangaben des Autors ber cksichtigt werden sollen oder nicht.
Ebenso kann das automatische Laden von Bildern unterdr ckt werden usw.
< 606 > Eigenschaftswerte zuweisen, Kaskaden und Vererbung
Page size: 168,00 x 240,00 mm
Im Internet Explorer kann man dar ber hinaus ein pers=nliches Stylesheet (Benutzer-
Stylesheet) angeben, das f r die Darstellung von Web-Seiten verwendet werden soll:
Die Deklaration einer zusammenfassenden Eigenschaft (z. B. 'background') als „!important“ ist
@quivalent zur Deklaration aller ihrer untergeordneten Eigenschaften als „!important“.
Beispiel
Im folgenden Beispiel zeigt die erste Regel im Stylesheet des Benutzers eine „!impor-
tant“-Deklaration, die die entsprechende Deklaration im Stylesheet des Autors ber-
schreibt. Die zweite Deklaration setzt sich ebenfalls durch, weil sie als „!important“
markiert ist. Die dritte Regel im Stylesheet des Benutzers jedoch ist nicht „!important“
und wird deshalb durch die zweite Regel im Stylesheet des Autors berschrieben (die
Cascading Style Sheets, Level 2
den Stil auf eine zusammenfassende Eigenschaft setzt). Dar ber hinaus ist die dritte
Regel des Autors der zweiten Regel des Autors unterlegen, weil die zweite Regel als
„!important“ gekennzeichnet ist. Das zeigt, dass „!important“-Deklarationen auch inner-
halb von Autor-Stylesheets eine Funktion haben.
/* Aus dem Stylesheet des Benutzers */
P { text-indent: 1em ! important }
P { font-style: italic ! important }
P { font-size: 18pt }
/* Aus dem Stylesheet des Autors */
P { text-indent: 1.5em !important }
P { font: 12pt sans-serif !important }
P { font-size: 24pt }
6.4.3 Berechnung der Spezifit.t eines Selektors
Die Spezifit@t eines Selektors wird wie folgt berechnet:
·· Z@hlen Sie die Anzahl der ID-Attribute im Selektor (= a)
Z@hlen Sie die Anzahl der anderen Attribute und Pseudo-Klassen im Selektor (= b)
Die Kaskade < 607 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
·· Z@hlen Sie die Anzahl der Elementnamen im Selektor (= c)
Pseudo-Elemente werden ignoriert.
Durch die Verkn pfung der drei Zahlen a, b und c (in einem Zahlensystem mit einer großen
Basis) ergibt sich die Spezifit@t.
Beispiel
Einige Beispiele:
* {} /* a=0 b=0 c=0 -> Spezifit]t = 0 */
LI {} /* a=0 b=0 c=1 -> Spezifit]t = 1 */
UL LI {} /* a=0 b=0 c=2 -> Spezifit]t = 2 */
UL OL+LI {} /* a=0 b=0 c=3 -> Spezifit]t = 3 */
H1 + *[REL=up]{} /* a=0 b=1 c=1 -> Spezifit]t = 11 */
UL OL [Link] {} /* a=0 b=1 c=3 -> Spezifit]t = 13 */
[Link] {} /* a=0 b=2 c=1 -> Spezifit]t = 21 */
#x34y {} /* a=1 b=0 c=0 -> Spezifit]t = 100 */
In HTML sind die Werte eines „style“-Attributs f r ein Element Stylesheet-Regeln. Diese
Regeln haben keine Selektoren, aber f r die Ausf hrung von Schritt 3 des Kaskadenalgorithmus
werden sie behandelt, als h@tten sie einen ID-Selektor (Spezifit@t: a=1, b=0, c=0). F r die Aus-
f hrung von Schritt 4 werden sie behandelt, als st nden sie hinter allen anderen Regeln.
Beispiel
<HEAD>
<STYLE type="text/css">
#x97z { color: blue }
</STYLE>
</HEAD>
<BODY>
Cascading Style Sheets, Level 2
<P ID=x97z style="color: red">
</BODY>
Im obigen Beispiel w@re die Farbe des P-Elements rot. Obwohl die Spezifit@t f r beide Deklara-
tionen dieselbe ist, berschreibt die Deklaration im „style“-Attribut diejenige im STYLE-Ele-
ment, und zwar aufgrund von Kaskadenregel 4.
Anmerkung der bersetzer: Die Errata erg@nzen folgende Erkl@rung: „Die Spezi-
fit@t wird ausschließlich auf Basis der Gestalt des Selektors bestimmt. Beispielsweise
wird ein Selektor der Form [id=p33] als Attributselektor gewertet (a=0, b=1, c=0),
selbst wenn das id-Attribut in der DTD den Typ ID zugewiesen bekam.“
Des Weiteren erkl@ren die CSS2-Errata aber auch den gesamten Abschnitt f r ung ltig
und ersetzen ihn durch den nachfolgend angegebenen Text.
< 608 > Eigenschaftswerte zuweisen, Kaskaden und Vererbung
Page size: 168,00 x 240,00 mm
Die Spezifit@t eines Selektors wird wie folgt berechnet:
· Z@hle 1, falls der Selektor ein 'style'-Attribut statt eines Selektors ist, sonst 0 (=a).
(In HTML sind die style-Attribute eines Elements Stylesheet-Regeln. Diese Regeln haben
keine Selektoren, so dass a=1, b=0, c=0 und d=0.)
·· Z@hle die Anzahl der ID-Attribute im Selektor (=b).
Z@hle die Anzahl anderer Attribute und Pseudoklassen im Selektor (=c).
·· Z@hle die Anzahl der Element im Selektor (=d).
Ignoriere Pseudoelemente
Durch die Verkn pfung der vier Zahlen a, b, c und d (in einem Zahlensystem mit einer großen
Basis) ergibt sich die Spezifit@t.
Beispiel
Einige Beispiele, nach steigender Spezifit@t geordnet:
* {} /* a=0 b=0 c=0 d=0 -> Spezifit]t = 0,0,0,0 */
LI {} /* a=0 b=0 c=0 d=1 -> Spezifit]t = 0,0,0,1 */
UL LI {} /* a=0 b=0 c=0 d=2 -> Spezifit]t = 0,0,0,2 */
UL OL+LI {} /* a=0 b=0 c=0 d=3 -> Spezifit]t = 0,0,0,3 */
H1 + *[REL=up]{} /* a=0 b=0 c=1 d=1 -> Spezifit]t = 0,0,1,1 */
UL OL [Link] {} /* a=0 b=0 c=1 d=3 -> Spezifit]t = 0,0,1,3 */
[Link] {} /* a=0 b=0 c=2 d=1 -> Spezifit]t = 0,0,2,1 */
#x34y {} /* a=0 b=1 c=0 d=0 -> Spezifit]t = 0,1,0,0 */
style="" /* a=1 b=0 c=0 d=0 -> Spezifit]t = 1,0,0,0 */
<HEAD>
<TITLE>Specificity Example</TITLE>
<STYLE type="text/css">
p#x97z { color: red }
</STYLE>
Cascading Style Sheets, Level 2
</HEAD>
<BODY>
<P ID=x97z style="color: green">
</BODY>
Im obigen Beispiel w@re die Farbe des P-Elements gr n. Die Deklaration im style-Attribut hat
eine h=here Spezifit@t und berschreibt die Deklaration im STYLE-Element aufgrund der Kaska-
denregel 3.
6.4.4 Priorit.t von Darstellungsanweisungen, die nicht Teil von CSS sind
Das Benutzerprogramm kann festlegen, dass Darstellungsanweisungen aus anderen Quellen als
Stylesheets ber cksichtigt werden sollen, beispielsweise das FONT-Element oder das
„align“-Attribut in HTML. In diesem Fall muss die Darstellungsanweisung, die nicht aus CSS
stammt, in die entsprechenden CSS-Regeln bersetzt werden, und zwar mit einer Spezifit@t
gleich 0. Man geht davon aus, dass sich die Regeln ganz am Anfang des Autor-Stylesheets befin-
den, und sie k=nnen von nachfolgenden Stylesheet-Regeln berschrieben werden.
Die Kaskade < 609 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Hinweis: In einer bergangsphase wird es durch diese Vorgehensweise einfacher, stilistische
Attribute in Kombination mit Stylesheets einzusetzen. n
Hinweis: In CSS1 erhielten die Darstellungsanweisungen, die nicht aus CSS stammten, die Spe-
zifit@t 1, nicht 0. Diese Onderung erfolgte aufgrund der Einf hrung des universellen Selektors,
der die Spezifit@t 0 hat. n
7 Medientypen
7.1 Einf-hrung in Medientypen
Eines der wichtigsten Funktionsmerkmale von Stylesheets ist, dass sie angeben, wie ein Doku-
ment auf unterschiedlichen Medien ausgegeben wird: auf dem Bildschirm, auf Papier, mit einem
Sprachsynthesizer, mit einem Braille-Ger@t usw.
Bestimmte CSS-Eigenschaften sind nur f r bestimmte Medien vorgesehen (z. B. die 'cue-befo-
re'-Eigenschaft f r akustische Benutzerprogramme). Manchmal k=nnen Stylesheets f r unter-
schiedliche Medientypen dieselbe Eigenschaft einsetzen, allerdings unterschiedliche Werte
daf r fordern. Beispielsweise ist die Eigenschaft 'font-size' sowohl f r Bildschirm- als auch f r
Druckmedien sinnvoll. Die beiden Medien sind jedoch unterschiedlich genug, um unterschiedli-
che Werte f r die gemeinsame Eigenschaft zu fordern; ein Dokument ben=tigt auf einem Com-
puterbildschirm normalerweise eine gr=ßere Schrift als auf Papier. Die Erfahrung hat außerdem
gezeigt, dass serifenlose Schriften auf dem Bildschirm einfacher zu lesen sind, w@hrend Serifen-
schriften auf Papier besser lesbar sind. Aus diesen Gr nden ist es notwendig, auszudr cken,
dass sich ein Stylesheet – oder ein Teil eines Stylesheets – auf bestimmte Medientypen bezieht.
7.2 Angabe [Link] Stylesheets
Cascading Style Sheets, Level 2
Momentan gibt es zwei M=glichkeiten, Medienabh@ngigkeiten f r Stylesheets anzugeben:
· Die Angabe des Zielmediums in einem Stylesheet mit Hilfe der At-Regeln @media oder
@import.
@import url("[Link]") aural;
@media print {
/* Stylesheet fUr den Druck steht hier */
}
· Die Angabe des Zielmediums innerhalb der Dokumentsprache. In HTML 4.0 ([HTML40])
beispielsweise gibt das „media“-Attribut f r das LINK-Element das Zielmedium eines exter-
nen Stylesheets an:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>Link zu einem Zielmedium</TITLE>
<LINK rel="stylesheet" type="text/css"
< 610 > Medientypen
Page size: 168,00 x 240,00 mm
media="print, handheld" href="[Link]">
</HEAD>
<BODY>
<P>Der Rumpf...
</BODY>
</HTML>
Die @import-Regel ist im Kapitel 6 ber die Kaskadierung beschrieben.
7.2.1 Die @media-Regel
Eine @media-Regel gibt durch Kommas voneinander getrennt die Ziel-Medientypen einer
Menge von Regeln (in geschweifte Klammern eingeschlossen) an. Das @media-Konstrukt
gestattet den Gebrauch von Stylesheet-Regeln f r verschiedene Medien in ein und demselben
Stylesheet:
@media print {
BODY { font-size: 10pt }
}
@media screen {
BODY { font-size: 12pt }
}
@media screen, print {
BODY { line-height: 1.2 }
}
7.3 Erkannte Medientypen
Ein CSS-Medientyp gibt eine Menge von CSS-Eigenschaften an. Ein Benutzerprogramm, das
angibt, einen Medientyp dem Namen nach zu unterst tzen, muss alle Eigenschaften implemen-
Cascading Style Sheets, Level 2
tieren, die sich auf diesen Medientyp beziehen.
Die f r CSS-Medientypen gew@hlten Namen reflektieren Zielger@te, f r die die betreffenden
Eigenschaften Sinn machen. In der folgenden Liste der CSS-Medientypen sind die Beschreibun-
gen in Klammern nicht normativ. Sie sollen ihnen nur einen Hinweis darauf geben, auf welches
Ger@t sich der Medientyp beziehen soll.
all
F r alle Ger@te geeignet.
aural
F r Sprachsynthesizer vorgesehen. Weitere Informationen finden Sie im Abschnitt ber
akustische Stylesheets.
braille
F r Braille-Ger@te mit taktilem Feedback vorgesehen.
embossed
F r Braille-Seitendrucker vorgesehen.
handheld
F r Handheld-Ger@te vorgesehen (normalerweise mit kleinem Schwarzweißbildschirm und
begrenzter Bandbreite).
Erkannte Medientypen < 611 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
print
F r ausgedrucktes, undurchsichtiges Material vorgesehen, ebenso wie f r Dokumente, die
im Druckvorschaumodus auf dem Bildschirm angezeigt werden. Weitere Informationen
ber Formatierungsaspekte, die spezifisch f r Druckmedien sind, finden Sie im Abschnitt
ber Seitenmedien.
projection
F r projizierte Pr@sentationen vorgesehen, wie zum Beispiel Projektoren oder den Aus-
druck auf Folien. Weitere Informationen ber Formatierungsaspekte, die spezifisch f r
Druckmedien sind, finden Sie im Abschnitt ber Seitenmedien.
screen
Haupts@chliche f r Computer-Farbbildschirme vorgesehen.
tty
F r Medien vorgesehen, die ein festes Zeichenraster verwenden, wie beispielsweise Fern-
schreiber, Terminals oder portable Ger@te mit begrenzten Anzeigem=glichkeiten. Autoren
sollten keine Pixeleinheiten verwenden, wenn sie den Medientyp „tty“ einsetzen.
tv
F r fernsehartige Ger@te vorgesehen (geringe Aufl=sung, Farbe, begrenzt rollbare Bildschir-
me, mit Sound).
Bei der Angabe der Medientypnamen wird die Groß-/Kleinschreibung nicht ber cksichtigt.
Weil sich die Technologien so schnell @ndern, gibt CSS2 keine definitive Liste der Medientypen
an, die als Werte f r @media verwendet werden k=nnten.
Hinweis: Zuk nftige Versionen von CSS werden diese Liste m=glicherweise erweitern. Die
Autoren sollten sich nicht auf Medientypnamen verlassen, die noch nicht von einer CSS-Spezifi-
kation definiert sind. n
Anmerkung der bersetzer: Der Opera-Browser versteht den Medientypnamen
Cascading Style Sheets, Level 2
„projection“ und erlaubt es damit, HTML-Seiten f r Vortr@ge im Stil von MS Power-
Point zu verwenden.
7.3.1 Mediengruppen
Jede CSS-Eigenschaftsdefinition gibt die Medientypen an, f r die die Eigenschaft durch ein kon-
formes Benutzerprogramm implementiert werden muss. Weil sich die Eigenschaften im All-
gemeinen auf mehrere Medien beziehen, gibt der Abschnitt „Anwendung auf Medien“ Medien-
gruppen statt einzelner Medientypen an. Jede Eigenschaft gilt f r alle Medientypen in den in
ihrer Definition aufgelisteten Mediengruppen.
CSS2 definiert die folgenden Mediengruppen:
· continuous oder paged (endlos oder seitenorientiert). „Both“ bedeutet, dass die betref-
fende Eigenschaft f r beide Mediengruppen gilt.
·· visual, aural oder tactile (visuell, akustisch und taktil).
grid (f r Ger@te mit einem Zeichenraster) oder bitmap. „Both“ bedeutet, dass die betref-
fende Eigenschaft f r beide Mediengruppen gilt.
< 612 > Medientypen
Page size: 168,00 x 240,00 mm
· interactive (f r Ger@te, die eine Interaktion mit dem Benutzer erlauben) oder static (f r
solche, die keine Interaktion zulassen). „Both“ bedeutet, dass die betreffende Eigenschaft
f r beide Mediengruppen gilt.
· all (beinhaltet alle Medientypen).
Die folgende Tabelle zeigt die Beziehungen zwischen Mediengruppen und Medientypen:
Beziehung zwischen Mediengruppen und Medientypen
Medien- Mediengruppen
typen
continuous/ visual/aural/ grid/ interactive/
paged tactile bitmap static
aural continuous aural N/A both
braille continuous tactile grid both
emboss paged tactile grid both
handheld both visual both both
print paged visual bitmap static
projection paged visual bitmap static
screen continuous visual bitmap both
tty continuous visual grid both
tv both visual, aural bitmap both
Cascading Style Sheets, Level 2
8 Das Box-Modell
Das Box-Modell von CSS beschreibt die rechteckigen K@sten, die f r die Elemente eines Doku-
mentbaums erzeugt werden, und die gem@ß dem visuellen Formatierungsmodell ausgelegt wer-
den. Die Seiten-Box ist eine spezielle Box, die detailliert im Abschnitt ber Seitenmedien
besprochen wird.
8.1 Maße der Boxen
Jede Box hat einen Inhaltsbereich (content) (z. B. Text, ein Bild usw.) und optional Polsterung
(padding), Rahmen (border) sowie Randbereiche (margin); die Gr=ße der einzelnen Bereiche
wird durch die nachfolgend definierten Eigenschaften angegeben. Die folgende Zeichnung zeigt,
in welchem Zusammenhang diese Bereiche stehen und welche Terminologie verwendet wird,
um auf Teile von Rand, Rahmen und Polsterung zu verweisen:
Das Box-Modell < 613 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Top
TM Margin (Transparent)
TB Border
TP Padding
Left LM LB LP Content RP RB RM Right
BP
BB
BM
Bottom
Margin edge
Border edge
Padding edge
Content edge
Rand, Rahmen und Polsterung k=nnen in linke (left), rechte (right), obere (top) und untere
(bottom) Segmente unterteilt werden (z. B. in der Zeichnung „LM“ f r „Left Margin“, „RP“ f r
„Right Padding“, „TB“ f r „Top Border“ usw.).
Der Abschluss jedes der vier Bereiche (Inhalt, Polsterung, Rahmen und Rand) wird auch als
„Kante“ bezeichnet, jede Box hat also vier Kanten:
Inhaltskante oder innere Kante (content edge)
Die Inhaltskante umschließt den dargestellten Inhalt des Elements.
Kante der Polsterung (padding edge)
Die Kante der Polsterung umschließt die Polsterung der Box. Hat die Polsterung die Breite
Cascading Style Sheets, Level 2
0, f@llt die Kante der Polsterung mit der Inhaltskante zusammen.
Rahmenkante (border edge)
Die Rahmenkante umschließt den Rahmen der Box. Hat der Rahmen die Breite 0, f@llt die
Rahmenkante mit der Kante der Polsterung zusammen.
Randkante oder .ußere Kante (margin edge)
Die Randkante umschließt den Rand der Box. Hat der Rand die Breite 0, f@llt die Randkante
mit der Rahmenkante zusammen.
Jede Kante kann in eine linke, rechte, untere und obere Kante zerlegt werden.
Die Ausmaße des Inhaltsbereichs einer Box – die Inhaltsbreite und Inhaltsh he – sind von mehre-
ren Faktoren abh@ngig: ob f r das Element, das die Box erzeugt, die Eigenschaften 'width' oder
'height' gesetzt sind, ob die Box Text oder andere Boxen enth@lt, ob es sich bei der Box um
eine Tabelle handelt usw. Die H=he und die Breite von Boxen werden im Kapitel ber die
Details zu visuellen Formatmodellen beschrieben.
Die Box-Breite ist die Summe der linken und rechten R@nder, Rahmen und Polsterung sowie der
Inhaltsbreite. Die H he ergibt sich aus den unteren und oberen R@ndern, Rahmen und Pols-
terung sowie der Inhaltsh=he.
< 614 > Das Box-Modell
Page size: 168,00 x 240,00 mm
Der Hintergrundstil von Inhalt, Polsterung und Rahmen einer Box wird durch die Eigenschaft
'background' des erzeugenden Elements bestimmt. R@nder haben immer einen transparenten
Hintergrund.
8.2 Beispiele f-r [Link], Polsterung und Rahmen
Dieses Beispiel zeigt, wie R@nder, Polsterung und Rahmen zusammenspielen. Nachfolgend
sehen Sie das HTML-Dokument f r dieses Beispiel:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>Beispiele fUr R]nder, Polsterung und Rahmen</TITLE>
<STYLE type="text/css">
UL {
background: #ffc500;
margin: 12px 12px 12px 12px;
padding: 3px 3px 3px 3px;
/* Keine Rahmen gesetzt */
}
LI {
color: white; /* Textfarbe weiß */
background: #8181ff; /* Inhalt, Polsterung ist blau */
margin: 12px 12px 12px 12px;
padding: 12px 0px 12px 12px; /* Achtung: 0px Polsterung rechts */
list-style: none /* kein Symbol vor einem Listenelement */
/* Keine Rahmen festgelegt */
}
[Link] {
border-style: dashed;
border-width: medium; /* Rahmenbreite fUr alle Seiten */
border-color: lightgreen;
Cascading Style Sheets, Level 2
}
</STYLE>
</HEAD>
<BODY>
<UL>
<LI>First element of list
<LI class="withborder">Second element of list is longer to illustrate
wrapping.
</UL>
</BODY>
</HTML>
Daraus ergibt sich ein Dokumentbaum u. a. mit einem UL-Element, das zwei untergeordnete LI-
Elemente aufweist.
Die erste der nachfolgenden Abbildungen zeigt die Ausgabe dieses Beispiels. Die zweite Abbil-
dung zeigt die Beziehung zwischen den R@ndern, der Polsterung und den Rahmen des UL-Ele-
ments sowie die seiner untergeordneten LI-Elemente.
Beispiele f#r R,nder, Polsterung und Rahmen < 615 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
First element of list
Second element of list
is longer to illustrate
wrapping
Content width of LI
First element of list
LI padding
Collapsed margin is
max(12px, 12px)=12px
Second element of list
is longer to illustrate
wrapping
LI padding
LI margins
UL padding
UL margins
Content width of UL
Cascading Style Sheets, Level 2
Box width of UL
Beachten Sie die Folgendes:
· Die Inhaltsbreite f r jede LI-Box wird von oben nach unten berechnet; der umschließende
Block f r jede LI-Box wird durch das UL-Element eingerichtet.
· Die H=he jeder LI-Box wird durch ihre Inhaltsh=he festgelegt, plus der oberen und unteren
Polsterung, Rahmen und R@nder. Beachten Sie, dass die vertikalen R@nder zwischen den LI-
Boxen zusammenfallen .
· Die rechte Polsterung der LI-Boxen wurde auf die Breite 0 gesetzt (die 'padding'-Eigen-
schaft). Der Effekt wird in der zweiten Abbildung deutlich.
· Die R@nder der LI-Boxen sind transparent – R@nder sind immer transparent –, so dass die
Hintergrundfarbe (#ffc500) der UL-Polsterung- und Inhaltsbereiche durch sie durchscheint.
· Das zweite LI-Element gibt einen gestrichelten Rahmen an (die 'border-style'-Eigenschaft).
< 616 > Das Box-Modell
Page size: 168,00 x 240,00 mm
8.3 Randeigenschaften: 'margin-top', 'margin-right',
'margin-bottom', 'margin-left' und 'margin'
Die Randeigenschaften legen die Breite des Randbereichs einer Box fest. Die zusammenfas-
sende Eigenschaft 'margin' setzt den Rand f r alle vier Seiten, w@hrend die anderen Randeigen-
schaften jeweils nur den Rand f r die betreffende Seite setzen.
Die in diesem Abschnitt definierten Eigenschaften beziehen sich auf den Wertetyp
<margin-width>, der einen der folgenden Werte annehmen kann:
<length>
Gibt eine feste Breite an.
<percentage>
Der Prozentsatz wird relativ zur Breite des umschließenden Blocks der erzeugenden Box
berechnet. Das gilt f r 'margin-top' und 'margin-bottom', außer im Seitenkontext, wo sich
Prozentwerte auf die H=he des Seitenrahmens beziehen.
auto
Weitere Informationen ber die Verhaltensweise finden Sie im Abschnitt 10.3 ber die
Berechnung von Breiten und R,ndern.
Negative Werte f r Randeigenschaften sind erlaubt, aber es kann von der jeweiligen Implemen-
tierung abh@ngige Obergrenzen geben.
'margin-top', 'margin-right', 'margin-bottom', 'margin-left'
Wert: <margin-width> | inherit
Ausgangswert: 0
Angewendet auf: Alle Elemente
Cascading Style Sheets, Level 2
Vererbt: Nein
Prozents,tze: Beziehen sich auf die Breite des umschließenden Blocks.
Medium: Visual
Diese Eigenschaften legen den oberen, rechten, unteren und linken Rand einer Box fest.
Beispiel
H1 { margin-top: 2em }
Randeigenschaften < 617 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
'margin'
Wert: <margin-width>{1,4} | inherit
Ausgangswert: F r zusammenfassende Eigenschaften nicht definiert.
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozents,tze: Beziehen sich auf die Breite des umschließenden Blocks.
Medium: Visual
Die Eigenschaft 'margin' ist eine zusammenfassende Eigenschaft f r die Zuordnung der Einstel-
lungen f r 'margin-top', 'margin-right', 'margin-bottom' und 'margin-left' an einer einzigen Stelle
im Stylesheet.
Falls nur ein Wert angegeben ist, gilt dieser f r alle Seiten. Sind zwei Werte angegeben, werden
der obere und der untere Rand auf den ersten Wert, der rechte und der linke Rand auf den
zweiten Wert gesetzt. Sind drei Werte angegeben, wird der obere Rand auf den ersten Wert,
der linke und der rechte Rand auf den zweiten Wert und der untere Rand auf den dritten Wert
gesetzt. Sind alle vier Werte angegeben, beziehen sie sich auf den oberen, rechten, unteren
bzw. linken Rand.
Beispiel
BODY { margin: 2em } /* alle R]nder auf 2em gesetzt */
BODY { margin: 1em 2em } /* top & bottom = 1em, right & left = 2em */
BODY { margin: 1em 2em 3em } /* top=1em, right=2em, bottom=3em, left=2em */
Die letzte Regel des obigen Beispiels ist @quivalent zum nachfolgenden Beispiel:
Cascading Style Sheets, Level 2
BODY {
margin-top: 1em;
margin-right: 2em;
margin-bottom: 3em;
margin-left: 2em; /* von der entgegengesetzten Seite (rechts) kopiert */
}
8.3.1 Zusammenfallende [Link]
In dieser Spezifikation bedeutet der Ausdruck zusammenfallende R,nder, dass benachbarte R@n-
der (die durch keine Polsterungs- oder Rahmenbereiche voneinander getrennt sind) von zwei
oder mehr Boxen (die nebeneinander liegen oder verschachtelt sein k=nnen) so zusammenfal-
len k=nnen, dass sie einen einzigen Rand bilden.
In CSS2 kann es nicht vorkommen, dass horizontale R@nder zusammenfallen.
< 618 > Das Box-Modell
Page size: 168,00 x 240,00 mm
Vertikale R@nder k=nnen zwischen bestimmten Boxen zusammenfallen:
· Zwei oder mehr benachbarte R@nder von Block-Boxen im normalen Darstellungsfluss fallen
zusammen. Die resultierende Randbreite ist das Maximum der benachbarten Randbreiten.
Bei negativen R@ndern wird das absolute Maximum der negativen benachbarten R@nder von
dem Maximum der positiven benachbarten R@nder abgezogen. Gibt es keine positiven R@n-
der, wird das absolute Maximum der negativen benachbarten R@nder von 0 abgezogen.
·· Vertikale R@nder zwischen einer Floating-Box und einer anderen Box fallen nicht zusammen.
R@nder von absolut und relativ positionierten Boxen fallen nicht zusammen.
Betrachten Sie bitte die Beispiele fr R,nder, Polsterung und Rahmen in Abschnitt 8.2. Dort finden
Sie auch eine Darstellung zusammenfallender R@nder.
8.4 Polstereigenschaften: 'padding-top', 'padding-right',
'padding-bottom', 'padding-left' und 'padding'
Die Polsterungseigenschaften geben die Breite des Polsterbereichs einer Box an. Die zusammen-
fassende Eigenschaft 'padding' setzt die Polsterung f r alle vier Seiten, w@hrend die anderen
Polsterungseigenschaften nur die Polsterung f r ihre jeweilige Seite festlegen.
Die in diesem Abschnitt definierten Eigenschaften beziehen sich auf den Wertetyp
<padding-width>, der einen der folgenden Werte annehmen kann:
<length>
Gibt eine feste Breite an.
<percentage>
Der Prozentsatz wird relativ zur Breite des umschließenden Blocks der erzeugenden Box
berechnet, sogar f r 'padding-top' und 'padding-bottom'.
Anders als die Randeigenschaften k=nnen die Werte f r die Polsterung nicht negativ sein. Wie
Cascading Style Sheets, Level 2
bei den Randeigenschaften beziehen sich die Prozentwerte f r die Polsterungseigenschaften auf
die Breite des umschließenden Blocks der erzeugenden Box.
'padding-top', 'padding-right', 'padding-bottom', 'padding-left'
Wert: <padding-width> | inherit
Ausgangswert: 0
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozents,tze: Beziehen sich auf die Breite des umschließenden Blocks
Medium: Visual
Diese Eigenschaften setzen die obere, rechte, untere und linke Polsterung einer Box.
Beispiel
BLOCKQUOTE { padding-top: 0.3em }
Polstereigenschaften < 619 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
'padding'
Wert: <padding-width>{1,4} | inherit
Ausgangswert: 0
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozents,tze: Beziehen sich auf die Breite des umschließenden Blocks
Medium: Visual
Die Eigenschaft 'padding' ist eine zusammenfassende Eigenschaft f r die Einstellung von 'pad-
ding-top', 'padding-right', 'padding-bottom' und 'padding-left' an einer einzigen Stelle im Style-
sheet.
Ist nur ein einziger Wert angegeben, gilt er f r alle Seiten. Sind zwei Werte angegeben, werden
die untere und die obere Polsterung auf den ersten Wert, die rechte und die linke Polsterung
auf den zweiten Wert gesetzt. Sind drei Werte angegeben, wird die obere Polsterung auf den
ersten Wert, die linke und die rechte Polsterung auf den zweiten Wert, und die untere Pols-
terung auf den dritten Wert gesetzt. Sind vier Werte angegeben, gelten sie f r die obere, rech-
te, untere bzw. linke Polsterung.
Die Oberfl@chenfarbe oder das Bild des Polsterbereichs werden mit der Eigenschaft 'back-
ground' angegeben:
Beispiel
H1 {
background: white;
padding: 1em 2em;
}
Cascading Style Sheets, Level 2
Das obige Beispiel gibt eine vertikale Polsterung ('padding-top' und 'padding-bottom') von '1em'
sowie eine horizontale Polsterung ('padding-right' und 'padding-left') von '2em' an. Die Einheit
'em' ist relativ zur Schriftgr=ße des Elements: '1em' entspricht der Gr=ße der verwendeten
Schrift.
Anmerkung der bersetzer: CSS-Errata: Die in diesem Abschnitt beschriebenen
Eigenschaften sind nicht g ltig f r: Tabellenzeilen, Zeilengruppen, Kopfgruppen, Fuß-
gruppen, Spalten und Spaltengruppen.
In HTML sind dies die Elemente tr, mit tbody gruppierte tr, thead, tfoot, col, colgroup.
< 620 > Das Box-Modell
Page size: 168,00 x 240,00 mm
8.5 Rahmeneigenschaften (border)
Die Rahmeneigenschaften geben die Breite, die Farbe und den Stil des Rahmenbereichs einer
Box an. Diese Eigenschaften gelten f r alle Elemente.
Insbesondere f r HTML k=nnen Benutzerprogramme Rahmen f r bestimmte Elemente (z. B.
Schaltfl@chen, Men s usw.) anders darstellen als f r „normale“ Elemente. n
8.5.1 Rahmenbreite: 'border-top-width', 'border-right-width',
'border-bottom-width', 'border-left-width' und 'border-width'
Die Eigenschaften f r die Rahmenbreite geben die Breite des Rahmenbereichs an. Die in diesem
Abschnitt definierten Eigenschaften beziehen sich auf den Wertetyp <border-width>, der
einen der folgenden Werte annehmen kann:
thin
Ein d nner Rahmen
medium
Ein mittlerer Rahmen
thick
Ein dicker Rahmen
<length>
Die Rahmendicke hat einen expliziten Wert. Explizite Rahmenbreiten k=nnen nicht negativ
sein.
Die Interpretation der ersten drei Werte ist vom Benutzerprogramm abh@ngig. Es m ssen
jedoch die folgenden Beziehungen gelten:
'thin' <= 'medium' <= 'thick'
Dar ber hinaus m ssen diese Breiten innerhalb eines Dokuments konstant sein.
Cascading Style Sheets, Level 2
'border-top-width', 'border-right-width', 'border-bottom-width',
'border-left-width'
Wert: <border-width> | inherit
Ausgangswert: medium
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozentwerte: N/A
Medium: Visual
Diese Eigenschaften legen die Breite des oberen, rechten, unteren und linken Rahmens einer
Box fest.
Rahmeneigenschaften (border) < 621 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
'border-width'
Wert: <border-width>{1,4} | inherit
Ausgangswert: Siehe einzelne Eigenschaften
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozentwerte: N/A
Medium: Visual
Diese Eigenschaft ist eine zusammenfassende Eigenschaft f r die Einstellung von 'border-top-
width', 'border-right-width', 'border-bottom-width' und 'border-left-width' an einer einzigen
Stelle im Stylesheet.
Ist nur ein Wert angegeben, gilt er f r alle Seiten. Sind zwei Werte angegeben, werden der
untere und der obere Rahmen auf den ersten Wert, der rechte und der linke Rahmen auf den
zweiten Wert gesetzt. Sind drei Werte angegeben, wird der obere Rahmen auf den ersten
Wert, der linke und der rechte Rahmen auf den zweiten Wert, und der untere Rahmen auf
den dritten Wert gesetzt. Sind vier Werte angegeben, gelten sie f r den oberen, rechten, unte-
ren bzw. linken Rahmen.
Beispiel
In den nachfolgenden Beispielen zeigen die Kommentare die resultierenden Breiten f r
den oberen, rechten, unteren und linken Rahmen an:
H1 { border-width: thin } /* dUnn dUnn dUnn dUnn */
H1 { border-width: thin thick } /* dUnn dick dUnn dick */
H1 { border-width: thin thick medium } /* dUnn dick mittel dick */
Cascading Style Sheets, Level 2
8.5.2 Rahmenfarbe: 'border-top-color', 'border-right-color',
'border-bottom-color', 'border-left-color' und 'border-color'
Die Eigenschaften f r die Rahmenfarbe geben die Farbe f r den Rahmen einer Box an.
Anmerkung der bersetzer: In der nachfolgenden bersicht befindet sich ein
Fehler bei der Angabe des Wertebereichs f r 'border-top-color', 'border-right-color',
'border-bottom-color', 'border-left-color': Es ist auch 'transparent' erlaubt, so dass der
Wert korrekt lautet:
<color> | transparent | inherit
< 622 > Das Box-Modell
Page size: 168,00 x 240,00 mm
'border-top-color', 'border-right-color', 'border-bottom-color',
'border-left-color'
Wert: <color> | inherit
Ausgangswert: Der Wert der 'color'-Eigenschaft.
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozentwerte: N/A
Medium: Visual
'border-color'
Wert: <color>{1,4} | transparent | inherit
Ausgangswert: Siehe einzelne Eigenschaften
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozentwerte: N/A
Medium: Visual
Anmerkung der bersetzer: F r 'border-color' muss der Wert korrekt wie folgt
lauten:
[ <color> | transparent ]{1,4} | inherit
Cascading Style Sheets, Level 2
Die Eigenschaft 'border-color' legt die Farbe der vier Rahmen fest. Die Werte haben die folgen-
den Bedeutungen:
<color>
Gibt einen Farbwert an.
transparent
Der Rahmen ist transparent (kann aber eine Breite haben).
Die Eigenschaft 'border-color' kann einen bis vier Werte haben, und die Werte werden f r die
verschiedenen Seiten wie f r 'border-width' gesetzt.
Wenn die Rahmenfarbe eines Elements nicht mit einer Rahmeneigenschaft angegeben wird,
m ssen Benutzerprogramme den Wert der 'color'-Eigenschaft des Elements als berechneten
Wert der Rahmenfarbe verwenden.
Rahmeneigenschaften (border) < 623 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Beispiel
In diesem Beispiel ist der Rahmen eine durchgezogene schwarze Linie.
P {
color: black;
background: white;
border: solid;
}
8.5.3 Rahmenstil: 'border-top-style', 'border-right-style',
'border-bottom-style', 'border-left-style' und 'border-style'
Die Rahmenstileigenschaften geben den Linienstil f r den Rahmen einer Box an (durchgezogen,
doppelt, gestrichelt usw.). Die in diesem Abschnitt definierten Eigenschaften beziehen sich auf
den Wertetyp <border-style>, der einen der folgenden Werte annehmen kann:
none
Kein Rahmen. Dieser Wert erzwingt, dass der berechnete Wert von 'border-width' gleich
'0' ist.
hidden (versteckt)
Wie 'none', außer in Hinblick auf Rahmenkonfliktaufl=sung f r Tabellenelemente.
dotted
Der Rahmen wird als punktierte Linie dargestellt.
dashed
Der Rahmen wird als gestrichelte Linie dargestellt.
solid
Der Rahmen wird als durchgezogene Linie dargestellt.
double
Der Rahmen besteht aus zwei durchgezogenen Linien. Die Summe der beiden Linien und
Cascading Style Sheets, Level 2
der Abstand zwischen ihnen ist gleich dem Wert von 'border-width'.
groove (Rille)
Der Rahmen sieht aus, als w@re er in die Zeichenfl@che eingemeißelt.
ridge (Grat)
Das Gegenteil von 'groove': der Rahmen sieht aus, als k@me er aus der Zeichenfl@che her-
vor.
inset
Der Rahmen bewirkt, dass die gesamte Box aussieht, als w@re sie in die Zeichenfl@che ein-
gebettet.
outset
Das Gegenteil von 'inset': Der Rahmen bewirkt, dass die gesamte Box aussieht, als k@me sie
aus der Zeichenfl@che heraus.
Alle Rahmen werden auf dem Hintergrund der Box gezeichnet. Die Farbe f r Rahmen, die mit
den Werten 'groove', 'ridge', 'inset' und 'outset' gezeichnet werden, sind von der Eigenschaft
'color' des Elements abh@ngig.
< 624 > Das Box-Modell
Page size: 168,00 x 240,00 mm
Anmerkung der bersetzer: Die CSS2-Errata korrigieren den vorhergehenden
Satz wie folgt:
„Die Farbe f r Rahmen, die mit den Werten 'groove', 'ridge', 'inset' und 'outset' gezeich-
net werden, sollte auf der Eigenschaft 'border-color' des Elements basieren. Benutzer-
programme k=nnen einen eigenen Algorithmus w@hlen, mit dem sie die tats@chlichen
Farben ermitteln. Wenn 'border-color' zum Beispiel den Wert 'silver' hat, kann ein
Benutzerprogramm Farbabstufungen von Weiß bis Dunkelgrau w@hlen, um einen abge-
schr@gten Rahmen darzustellen.“
Konforme HTML-Benutzerprogramme d rfen 'dotted', 'dashed', 'double', 'groove', 'ridge', 'inset'
und 'outset' als 'solid' interpretieren.
'border-top-style', 'border-right-style', 'border-bottom-style',
'border-left-style'
Wert: <border-style> | inherit
Ausgangswert: Keiner
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozents,tze: N/A
Medium: Visual
'border-style'
Cascading Style Sheets, Level 2
Wert: <border-style>{1,4} | inherit
Ausgangswert: Siehe einzelne Eigenschaften
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozents,tze: N/A
Medium: Visual
Die Eigenschaft 'border-style' legt den Stil der vier Rahmen fest. Sie kann einen von vier Wer-
ten annehmen, und die Werte werden auf die verschiedenen Seiten, wie oben, gezeigt f r 'bor-
der-width' angewendet.
Beispiel
#xy34 { border-style: solid dotted }
Rahmeneigenschaften (border) < 625 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
In diesem Beispiel sind die horizontalen Rahmen 'solid' (durchgezogen), die vertikalen Rahmen
sind 'dotted' (punktiert).
Weil der Ausgangswert der Rahmenstile 'none' ist, sind keine Rahmen sichtbar, wenn der Rah-
menstil nicht explizit festgelegt wird.
8.5.4 Zusammenfassende Rahmeneigenschaften: 'border-top',
border-bottom', 'border-right', 'border-left' und 'border'
'border-top', border-bottom', 'border-right', 'border-left'
Wert: [<'border-top-width'> | | <'border-style'> | | <color> ] | inherit
Ausgangswert: Siehe einzelne Eigenschaften.
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozents,tze: N/A
Medium: Visual
Dies ist eine zusammenfassende Eigenschaft f r die Einstellung von Breite, Stil und Farbe des
oberen, rechten, unteren und linken Rahmen einer Box.
Anmerkung der bersetzer: In der obigen bersicht und in der nachfolgenden
bersicht der Rahmeneigenschaften sind die Angaben f r Wert fehlerhaft. Sie m ssen in
beiden F@llen lauten:
[ <border-width> || <border-style> || [<color> | transparent] | inherit
Cascading Style Sheets, Level 2
Beispiel
H1 { border-bottom: thick solid red }
Die oben gezeigte Regel setzt die Breite, den Stil und die Farbe des Rahmens unterhalb des
H1-Elements. Weggelassene Werte werden auf ihre Ausgangswerte gesetzt. Weil die nachfol-
gende Regel keine Rahmenfarbe angibt, erh@lt der Rahmen die in der 'color'-Eigenschaft fest-
gelegte Farbe:
H1 { border-bottom: thick solid }
< 626 > Das Box-Modell
Page size: 168,00 x 240,00 mm
'border'
Wert: [<'border-width'> | | <'border-style'> | | <color> ] | inherit
Ausgangswert: Siehe einzelne Eigenschaften.
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozents,tze: N/A
Medium: Visual
Die Eigenschaft 'border' ist eine zusammenfassende Eigenschaft, mit der dieselbe Breite, die-
selbe Farbe und derselbe Stil f r alle vier Rahmen einer Box festgelegt werden. Anders als die
zusammenfassenden Eigenschaften 'margin' und 'padding', kann die Eigenschaft 'border' keine
unterschiedlichen Werte f r die vier Rahmen festlegen. Dazu m ssen eine oder mehrere der
anderen Rahmeneigenschaften verwendet werden.
Beispiel
Beispielsweise ist die erste nachfolgende Regel @quivalent zu den vier anschließend
gezeigten Regeln:
P { border: solid red }
P {
border-top: solid red;
border-right: solid red;
border-bottom: solid red;
border-left: solid red
}
Weil die Eigenschaften in gewissem Ausmaß eine berlappende Funktionalit@t aufweisen, ist die
Cascading Style Sheets, Level 2
Reihenfolge von Bedeutung, in der die Regeln angegeben werden.
Beispiel
Betrachten Sie das folgende Beispiel:
BLOCKQUOTE {
border-color: red;
border-left: double;
color: black
}
In diesem Beispiel ist die Farbe des linken Rahmens schwarz, w@hrend die anderen Rahmen rot
sind. Das liegt daran, dass 'border-left' die Breite, den Stil und die Farbe festgelegt hat. Weil der
Farbwert durch die Eigenschaft 'border-left' nicht angegeben ist, wird er aus der Eigenschaft
'color' bernommen. Die Tatsache, dass die Eigenschaft 'color' nach der Eigenschaft 'border-
left' gesetzt wird, ist nicht relevant.
Rahmeneigenschaften (border) < 627 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
9 Visuelles Formatierungsmodell
9.1 Einf-hrung in das visuelle Formatierungsmodell
Dieses und das n@chste Kapitel beschreiben das visuelle Formatierungsmodell: wie Benutzer-
programme den Dokumentbaum f r visuelle Medien verarbeiten.
Beim visuellen Formatierungsmodell erzeugt jedes Element im Dokumentbaum gem@ß dem
Box-Modell null oder mehr Boxen. Das Layout dieser Boxen wird bestimmt durch:
·· Gr=ße und Typ der Box
Positionierungsschema (normaler Fluss, Floating und absolute Positionierung)
·· Beziehungen zwischen Elementen im Dokumentbaum
Externe Information (z. B. Viewport-Gr=ße, eigene Gr=ße von Bildern usw.)
Die in diesem und dem n@chsten Kapitel definierten Eigenschaften beziehen sich sowohl auf
Endlosmedien als auch auf Seitenmedien. Die Bedeutung der Randeigenschaften variiert jedoch
bei Anwendung auf Seitenmedien (weitere Informationen finden Sie bei der Beschreibung des
Seitenmodells, Kapitel 13).
Das visuelle Formatierungsmodell spezifiziert nicht alle Aspekte der Formatierung (z. B. keinen
Algorithmus f r den Buchstabenabstand). Konforme Benutzerprogramme k=nnen f r die von
dieser Spezifikation nicht abgedeckten Aspekte unterschiedliche Verhaltensweisen zeigen.
9.1.1 Der Viewport
Benutzerprogramme f r Endlosmedien bieten den Benutzern normalerweise einen Viewport
(ein Fenster oder einen anderen Anzeigebereich auf dem Bildschirm), durch den die Benutzer
ein Dokument betrachten k=nnen. Benutzerprogramme @ndern das Layout des Dokuments
m=glicherweise, wenn der Viewport eine neue Gr=ße erh@lt (siehe umschließender Ausgangs-
block, unten). Ist der Viewport kleiner als der umschließende Ausgangsblock des Dokuments,
Cascading Style Sheets, Level 2
sollte das Benutzerprogramm einen Mechanismus zum Bl@ttern bereitstellen. Es gibt h=chstens
einen Viewport pro Zeichenfl@che, aber die Benutzerprogramme k=nnen mehrere Zeichenfl@-
chen anzeigen (und damit unterschiedliche Ansichten desselben Dokuments bieten).
9.1.2 Umschließende BlUcke
In CSS2 werden viele Positionen und Gr=ßen von Boxen relativ zu den Kanten einer rechtecki-
gen Box berechnet, dem so genannten umschließenden Block. Im Allgemeinen dienen erzeugte
Boxen als umschließende Boxen f r abgeleitete Boxen; wir sagen, eine Box „richtet den
umschließenden Block f r ihre Nachkommen ein“. Die Formulierung „der umschließende Block
einer Box“ bedeutet „der umschließende Block, in dem sich die Box befindet“, und bezeichnet
nicht den Block, den eine Box erzeugt.
Jede Box erh@lt eine Position relativ zu ihrem umschließenden Block, ist jedoch nicht auf diesen
umschließenden Block begrenzt; sie kann berlaufen.
Die Wurzel (Root) des Dokumentbaums erzeugt eine Box, die als umschließender Ausgangsblock
f r ein nachfolgendes Layout dient.
< 628 > Visuelles Formatierungsmodell
Page size: 168,00 x 240,00 mm
Die Breite des anf@nglichen umschließenden Blocks kann mit Hilfe der 'width'-Eigenschaft f r
das Wurzelelement angegeben werden. Hat diese Eigenschaft den Wert 'auto', gibt das Benut-
zerprogramm die Ausgangsbreite vor (zum Beispiel verwendet er dazu die aktuelle Breite des
Viewports).
Die H=he des umschließenden Ausgangsblocks kann mit der 'height'-Eigenschaft f r das Wur-
zelelement angegeben werden. Hat diese Eigenschaft den Wert 'auto', vergr=ßert sich die H=he
des umschließenden Blocks, um dem Dokumentinhalt zu gen gen.
Der umschließende Ausgangsblock kann nicht positioniert oder gefloatet werden (das heißt,
Benutzerprogramme ignorieren die 'position'- und 'float'-Eigenschaften f r das Wurzelele-
ment).
Detaillierte Informationen dar ber, wie die Gr=ße des umschließenden Blocks berechnet wird,
sind im n@chsten Kapitel zu finden.
9.2 Kontrolle -ber das Erstellen von Boxen
Die folgenden Abschnitte beschreiben, welche Box-Typen in CSS2 erzeugt werden k=nnen.
Der Typ einer Box beeinflusst teilweise ihr Verhalten im visuellen Formatierungsmodell. Die
nachfolgend beschriebene 'display'-Eigenschaft gibt den Box-Typ an.
9.2.1 Elemente auf Blockebene und Block-Boxen
Elemente auf Blockebene sind die Elemente des Quelldokuments, die visuell als Bl=cke (z. B.
Abs@tze) formatiert sind. Verschiedene Werte der 'display'-Eigenschaft machen ein Element zu
einem Element auf Blockebene: 'block', 'list-item', 'compact' und 'run-in' (teilweise; siehe Com-
pact- und Run-in-Boxen) sowie 'table'.
Elemente auf Blockebene erzeugen eine Hauptblock-Box, die nur Block-Boxen enth@lt. Die Haupt-
block-Box richtet den umschließenden Block f r abgeleitete Boxen und erzeugten Inhalt ein
und stellt außerdem die in jedem Positionierungsschema beteiligte Box dar. Hauptblock-Boxen
Cascading Style Sheets, Level 2
werden im Blockformatierungskontext ber cksichtigt.
Einige Elemente auf Blockebene erzeugen zus@tzliche Boxen außerhalb der Haupt-Box: 'list-
item'-Elemente und solche mit Markierungen (siehe Abschnitt 12.6.1). Diese zus@tzlichen
Boxen werden relativ zur Haupt-Box positioniert.
Anonyme Block-Boxen
In einem Dokument wie dem Folgenden
<DIV>
Some Text
<P>More Text</P>
</DIV>
(und vorausgesetzt, f r DIV und P ist 'display: block' vorgegeben), scheint DIV sowohl Inline-In-
halt als auch Blockinhalt zu haben. Um die Definition der Formatierung zu vereinfachen, setzen
wir voraus, dass es einen anonymen Block um „Some Text“ herum gibt.
Kontrolle #ber das Erstellen von Boxen < 629 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
DIV box
anonymous box
Some text
More text
P box
Abbildung 9.1: Diese Skizze f r das obige Beispiel zeigt drei Boxen, von denen eine anonym ist.
Mit anderen Worten: wenn eine Block-Box (wie beispielsweise die oben f r DIV erzeugte) eine
weitere Block-Box enth@lt (wie oben beispielsweise P), erzwingen wir, dass sie nur Block-Boxen
enth@lt, indem wir alle Inline-Boxen in eine anonyme Block-Box einh llen.
Beispiel
Dieses Modell w rde f r das folgende Beispiel gelten, wenn die folgenden Regeln:
/* Hinweis: HTML-Benutzerprogramme berUcksichtigen diese
Regeln m^glicherweise nicht */
BODY { display: inline }
P { display: block }
auf das folgende HTML-Dokument angewendet werden:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HEAD>
Cascading Style Sheets, Level 2
<TITLE>Anonymer Text, unterbrochen durch einen Block</TITLE>
</HEAD>
<BODY>
Dies ist anonymer Text vor dem P. <!- - S1 - ->
<P>Dies ist der Inhalt von P.</>
Dies ist anonymer Text nach dem P. <!- - S2 - ->
</BODY>
Das BODY-Element enth@lt ein St ck (S1) anonymen Text, gefolgt von einem Element auf
Blockebene, gefolgt von einem weiteren St ck (S2) anonymem Text. Daraus resultieren eine
anonyme Block-Box f r BODY, die eine anonyme Block-Box um S1 herum enth@lt, die P-Block-
Box sowie eine weitere anonyme Block Box um S2 herum.
Die Eigenschaften anonymer Boxen werden von der umschließenden nicht anonymen Box
geerbt (in diesem Beispiel ist das die Box f r DIV). Nicht vererbte Eigenschaften haben ihren
Ausgangswert. Beispielsweise wird die Schrift der anonymen Box von DIV geerbt, die R@nder
dagegen sind 0.
< 630 > Visuelles Formatierungsmodell
Page size: 168,00 x 240,00 mm
9.2.2 Inzeilige Elemente und inzeilige Boxen (Elemente auf
Inline-Ebene und Inline-Boxen)
Inzeilige Elemente sind die Elemente des Quelldokuments, die keine neuen Inhaltsbl=cke bilden;
der Inhalt ist auf Zeilen verteilt (z. B. betonte Teile eines Texts innerhalb eines Abschnittes,
inzeilige Bilder usw.). Verschiedene Werte der 'display'-Eigenschaft machen ein Element inzeilig:
'inline', 'inline-table', 'compact' und 'run-in' (teilweise; lesen Sie dazu auch im Abschnitt ber
Compact- und Run-in-Boxen nach). Inzeilige Elemente erzeugen inzeilige Boxen.
Inzeilige Boxen k=nnen an mehreren Formatierungskontexten beteiligt sein:
· Innerhalb einer Block-Box befinden sich inzeilige Boxen in einem inzeiligen Formatierungskon-
text.
·· Eine kompakte inzeilige Box erh@lt eine Position im Rand einer Block-Box.
Markierungs-Boxen erhalten immer Positionen außerhalb einer Block-Box.
Anmerkung der bersetzer: Hier wurde der englische Begriff „inline“ mit „inzei-
lig“ bersetzt, was im Deutschen eine daf r bliche bersetzung ist. Dennoch kann „inli-
ne“ nicht durchg@ngig bersetzt werden. berall dort, wo die entsprechende Angabe in
einem CSS auftaucht, muss nat rlich „inline“ stehen. Aus diesem Grund tauchen beide
Worte hier und im Folgenden gemischtsprachig auf; und deshalb wurden bereits in der
berschrift beide Formen genannt.
Anonyme Inline-Boxen
In einem Dokument wie dem Folgenden
<P>Irgendein <EM>betonter</EM> Text</P>
Cascading Style Sheets, Level 2
erzeugt P eine Block-Box mit mehreren darin enthaltenen Inline-Boxen. Die Box f r eine „Be-
tonung“ ist eine inzeilige Box, die von einem inzeiligen Element (EM) erzeugt wurde, aber die
anderen Boxen („Irgendein“ und „Text“) sind inzeilige Boxen, die von einem Element auf Block-
ebene erzeugt wurden (P). Die letzteren werden auch als anonyme Inline-Boxen bezeichnet,
weil ihnen kein entsprechendes Element auf Inline-Ebene zugeordnet ist.
Solche anonyme Inline-Boxen erben vererbbare Eigenschaften von ihrer bergeordneten
Block-Box. Nicht vererbte Eigenschaften behalten ihren Ausgangswert. In unserem Beispiel
wird die Farbe der anonymen Ausgangsboxen von P geerbt, der Hintergrund jedoch ist trans-
parent.
Geht aus dem Kontext hervor, welcher Typ anonymer Box gemeint ist, werden sowohl ano-
nyme Inline-Boxen als auch anonyme Block-Boxen in dieser Spezifikation einfach als anonyme
Boxen bezeichnet.
Bei der Formatierung von Tabellen gibt es noch mehr Typen von anonymen Boxen.
Kontrolle #ber das Erstellen von Boxen < 631 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
9.2.3 Kompakte Boxen (Compact-Box)
Eine kompakte Box verh@lt sich wie folgt:
· Folgt der Compact-Box eine Block-Box (die nicht gefloatet und nicht absolut positioniert
ist), wird die Compact-Box wie eine einzeilige Inline-Box formatiert. Die resultierende Box-
Breite wird mit einem der Seitenr@nder der Block-Box verglichen (links oder rechts). Die
Auswahl von linkem oder rechtem Rand wird durch die 'direction' bestimmt, die f r das
Element angegeben ist, das den umschließenden Block f r die Compact-Box und die fol-
gende Box erzeugt. Ist die Breite der Inline-Box kleiner oder gleich dem Rand, erh@lt die
Inline-Box eine Position im Rand, wie nachfolgend beschrieben.
· Andernfalls wird die Compact-Box zu einer Block-Box.
Anmerkung der bersetzer: Hier sei darauf hingewiesen, dass der Rand keine
Linie, sondern eine Fl@che ist. Deshalb k=nnen Boxen im Rand platziert werden.
Die Compact-Box erh@lt wie folgt eine Position im Rand: Sie liegt außerhalb (links oder rechts)
der ersten Zeilen-Box des Blocks, wird aber in der Berechnung der H=he dieser Zeilen-Box
ber cksichtigt. Die 'vertical-align'-Eigenschaft der Compact-Box bestimmt die vertikale Position
der Compact-Box relativ zu dieser Zeilen-Box. Die horizontale Position der Compact-Box ist
immer der Rand der Block-Box.
Ein Element, das nicht innerhalb einer Zeile formatiert werden kann, kann nicht im Rand des
folgenden Blocks platziert werden. Beispielsweise wird ein 'compact'-Element in HTML, das ein
BR-Element enth@lt, immer als Block-Box formatiert (die Standardformatierung f r BR voraus-
gesetzt, die einen Zeilenumbruch einf gt). F r die Platzierung von mehrzeiligem Text im Rand
ist die 'float'-Eigenschaft h@ufig besser geeignet.
Cascading Style Sheets, Level 2
Beispiel
Das folgende Beispiel zeigt eine Compact-Box:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>A compact box example</TITLE>
<STYLE type="text/css">
DT { display: compact }
DD { margin-left: 4em }
</STYLE>
</HEAD>
<BODY>
<DL>
<DT>Kurz
<DD><P>Beschreibung steht hier
<DT>Zu lang fUr den Rand
<DD><P> Beschreibung steht hier
</DL>
</BODY>
</HTML>
< 632 > Visuelles Formatierungsmodell
Page size: 168,00 x 240,00 mm
Dieses Beispiel k=nnte wie folgt formatiert werden:
Kurz Beschreibung steht hier
Zu lang fBr den Rand
Beschreibung steht hier
Die 'text-align'-Eigenschaft kann verwendet werden, um das Kompaktelement innerhalb des
Randes auszurichten: an der linken Kante des Randes ('left'), an der rechten Kante des Randes
('right') oder zentriert im Rand ('center'). Der Wert 'justify' findet keine Anwendung und wird
als 'left' oder 'right' interpretiert, abh@ngig von der 'direction' des Elements auf Blockebene, in
dessen Rand das Kompaktelement formatiert wird ('left', wenn die Schreibrichtung 'ltr' ist,
'right', wenn sie 'rtl' ist.)
Weitere Informationen, wie Kompaktboxen mit erzeugtem Inhalt zusammenspielen, finden Sie
im Abschnitt ber erzeugten Inhalt (12.3).
9.2.4 Run-in-Boxen
Eine Run-in-Box verh@lt sich wie folgt:
· Wenn der Run-in-Box eine Block-Box (die nicht gefloatet und nicht absolut positioniert ist)
folgt, wird die Run-in-Box zur ersten Inline-Box der Block-Box.
· Andernfalls wird die Run-in-Box zu einer Block-Box.
Beispiel
Eine 'run-in'-Box ist praktisch f r Run-in- berschriften, wie etwa im folgenden Beispiel
gezeigt:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
Cascading Style Sheets, Level 2
<TITLE>A run-in box example</TITLE>
<STYLE type="text/css">
H3 { display: run-in }
</STYLE>
</HEAD>
<BODY>
<H3>A run-in heading.</H3>
<P>And a paragraph of text that
follows it.
</BODY>
</HTML>
Dieses Beispiel k=nnte wie folgt formatiert werden:
A run-in heading. And a
paragraph of text that
follows it.
Die Eigenschaften erbt das Run-in-Element von seinen bergeordneten Elementen im Doku-
mentbaum, nicht von der Block-Box, deren visueller Teil es wird.
Kontrolle #ber das Erstellen von Boxen < 633 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Weitere Informationen dar ber, wie Run-in-Boxen mit erzeugtem Inhalt zusammenspielen, fin-
den Sie im Abschnitt ber erzeugten Inhalt (12.3).
9.2.5 Die 'display'-Eigenschaft
'display'
Wert inline | block | list-item | run-in | compact | marker | table |
inline-table | table-row-group | table-header-group | table-
footer-group | table-row | table-column-group | table-column |
table-cell | table-caption | none | inherit
Ausgangswert: Inline
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozentwerte: N/A
Medium: All
Die Werte dieser Eigenschaft haben die folgenden Bedeutungen:
block
Dieser Wert veranlasst ein Element, eine Hauptblock-Box zu erzeugen.
inline
Dieser Wert veranlasst ein Element, eine oder mehrere Inline-Boxen zu erzeugen.
list-item
Dieser Wert veranlasst ein Element (z. B. LI in HTML), eine Hauptblock-Box und eine inzei-
lige Listenelement-Box zu erzeugen. Weitere Informationen ber Listen und Beispiele f r
Cascading Style Sheets, Level 2
die Listenformatierung finden Sie im Abschnitt ber Listen.
marker
Dieser Wert deklariert erzeugten Inhalt vor oder hinter einer Box als Markierung. Dieser
Wert sollte nur in Kombination mit den Pseudo-Elementen :before und :after verwendet
werden, die Elementen auf Blockebene zugeordnet sind. In anderen F@llen wird dieser
Wert als 'inline' interpretiert. Weitere Informationen finden Sie im Abschnitt ber Markie-
rungen (12.6.1).
none
Dieser Wert veranlasst ein Element, keine Boxen in der Formatierungsstruktur zu erzeu-
gen (das heißt, das Element hat keinen Einfluss auf das Layout). Abgeleitete Elemente erzeu-
gen ebenfalls keine Boxen; dieses Verhalten kann nicht -berschrieben werden, indem
die 'display'-Eigenschaft der abgeleiteten Elemente auf einen anderen Wert gesetzt wird.
Beachten Sie bitte, dass mit 'display' gleich 'none' keine unsichtbare Box erzeugt wird; es
wird berhaupt keine Box erzeugt. CSS beinhaltet Mechanismen, die es einem Element
erm=glichen, Boxen in der Formatierungsstruktur zu erzeugen, die die Formatierung beein-
flussen, aber selbst nicht sichtbar sind. Weitere Informationen finden Sie im Abschnitt ber
die Sichtbarkeit (11.2).
< 634 > Visuelles Formatierungsmodell
Page size: 168,00 x 240,00 mm
run-in und compact
Diese Werte erzeugen Block- oder Inline-Boxen, abh@ngig vom Kontext. Eigenschaften
beziehen sich auf Run-in- und Compact-Boxen abh@ngig von ihrem endg ltigen Status
(Inline-Ebene oder Blockebene). Beispielsweise wird die 'white-space'-Eigenschaft nur ange-
wendet, wenn die Box eine Block-Box ist.
table, inline-table, table-row-group, table-column, table-column-group, table-hea-
der-group, table-footer-group, table-row, table-cell, table-caption
Diese Werte veranlassen eine Element, sich wie ein Tabellenelement zu verhalten (den Ein-
schr@nkungen unterliegend, die im Kapitel 17 ber Tabellen beschrieben sind).
Beachten Sie, dass der Ausgangswert von 'display' zwar 'inline' ist, die Regeln im Standard-Sty-
lesheet des Benutzerprogramms diesen Wert jedoch berschreiben k=nnen. Betrachten Sie
dazu auch das Beispiel-Stylesheet f r HTML 4.0 im Anhang.
Beispiel
Hier einige Beispiele f r die 'display'-Eigenschaft:
P { display: block }
EM { display: inline }
LI { display: list-item }
IMG { display: none } /* Keine Bilder anzeigen */
Konforme HTML-Benutzerprogramme d rfen die 'display'-Eigenschaft ignorieren.
9.3 Positionierungsschemata
In CSS2 kann eine Box gem@ß den drei folgenden Positionierungsschemata ausgelegt werden:
Normaler Fluss
Cascading Style Sheets, Level 2
In CSS2 beinhaltet der normale Fluss die Blockformatierung von Block-Boxen, die inzeilige
Formatierung von Inline-Boxen, die relative Positionierung von Block- oder Inline-Boxen,
und die Positionierung von Compact- und Run-in-Boxen.
Floats
Im Float-Modell wird eine Box zun@chst gem@ß dem normalen Fluss ausgelegt, dann aus
dem Fluss entfernt und so weit wie m=glich nach links oder rechts verschoben. Weiterer
Inhalt kann entlang der Seite eines Floats fließen.
Absolute Positionierung
Beim absoluten Positionierungsmodell wird eine Box vollst@ndig aus dem normalen Fluss
entfernt (sie hat keinen Einfluss auf sp@tere gleichrangige Elemente), und es wird ihr eine
Position relativ zum umschließenden Block zugewiesen.
Hinweis: Die Positionierungsschemata von CSS2 helfen den Autoren, einen besseren Zugriff
auf ihre Dokumente zu realisieren, indem sie ihnen erlauben, Markup-Tricks zu vermeiden
(zum Beispiel unsichtbare Bilder), die f r Layout-Effekte verwendet werden. n
Positionierungsschemata < 635 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
9.3.1 Auswahl eines Positionierungsschemas: 'position'-Eigenschaft
Die Eigenschaften 'position' und 'float' legen fest, welcher der Positionierungsalgorithmen von
CSS2 f r die Berechnung der Position einer Box verwendet wird.
'position'
Wert static | relative | absolute | fixed | inherit
Ausgangswert: Static
Angewendet auf: Alle Elemente, aber nicht auf erzeugten Inhalt
Vererbt: Nein
Prozentwerte: N/A
Medium: Visual
Die Werte dieser Eigenschaft haben die folgenden Bedeutungen:
static
Bei der Box handelt es sich um eine normale Box gem@ß dem normalen Fluss. Die Eigen-
schaften 'left' und 'top' finden keine Anwendung.
relative
Die Position der Box wird gem@ß dem normalen Fluss berechnet (man spricht auch von
der Position im normalen Fluss). Anschließend wird die Box relativ zu ihrer normalen Posi-
tion verschoben. Wird eine Box B relativ positioniert, wird die Position der nachfolgenden
Box so berechnet, als w@re B nicht verschoben worden.
absolute
Die Position (und m=glicherweise Gr=ße) der Box wird mit Hilfe der Eigenschaften 'left',
Cascading Style Sheets, Level 2
'right', 'top' und 'bottom' angegeben. Diese Eigenschaften geben Abst@nde relativ zum
umschließenden Block der Box an. Absolut positionierte Boxen werden aus dem normalen
Fluss entfernt. Das bedeutet, sie haben keinen Einfluss auf das Layout sp@terer gleichrangi-
ger Elemente. Obwohl absolut positionierte Boxen R@nder haben, fallen sie nicht mit ande-
ren R@ndern zusammen.
fixed
Die Position der Box wird gem@ß des 'absolute'-Modells berechnet, aber dar ber hinaus ist
die Box feststehend hinsichtlich einer bestimmten Referenz. Bei Endlosmedien ist die Box
feststehend relativ zu dem Viewport (und bewegt sich beim Bl@ttern nicht). Bei Seiten-
medien ist die Box feststehend relativ zur Seite, auch wenn diese Seite durch einen
Viewport betrachtet wird (beispielsweise bei einer Druckvorschau). Autoren wollen 'fixed'
m=glicherweise von einem Medium unabh@ngig angeben. Beispielsweise k=nnte ein Autor
beabsichtigen, dass eine Box oben im Viewport auf dem Bildschirm bleibt, aber nicht oben
auf jeder gedruckten Seite. Die beiden Spezifikationen k=nnen mit Hilfe einer @media-
Regel voneinander getrennt werden, beispielsweise wie folgt:
< 636 > Visuelles Formatierungsmodell
Page size: 168,00 x 240,00 mm
@media screen {
H1#first { position: fixed }
}
@media print {
H1#first { position: static }
}
9.3.2 [Link] : 'top', 'right', 'bottom', 'left'
Ein Element ist positioniert, wenn seine 'position'-Eigenschaft einen anderen Wert als 'static' hat.
Positionierte Elemente erzeugen positionierte Boxen, die gem@ß vier Eigenschaften ausgelegt
werden:
'top'
Wert <length> | <percentage> | auto | inherit
Ausgangswert: Auto
Angewendet auf: Positionierte Elemente
Vererbt: Nein
Prozentwerte: Beziehen sich auf die H=he des umschließenden Blocks
Medium: Visual
Diese Eigenschaft gibt an, wie weit die oberste Inhaltskante einer Box unter die oberste Kante
des umschließenden Blocks der Box verschoben wird.
'right'
Cascading Style Sheets, Level 2
Wert <length> | <percentage> | auto | inherit
Ausgangswert: Auto
Angewendet auf: Positionierte Elemente
Vererbt: Nein
Prozentwerte: Beziehen sich auf die H=he des umschließenden Blocks
Medium: Visual
Diese Eigenschaft gibt an, wie weit die rechte Inhaltskante einer Box links neben die rechte
Kante des umschließenden Blocks der Box verschoben wird.
Positionierungsschemata < 637 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
'bottom'
Wert <length> | <percentage> | auto | inherit
Ausgangswert: Auto
Angewendet auf: Positionierte Elemente
Vererbt: Nein
Prozentwerte: Beziehen sich auf die H=he des umschließenden Blocks
Medium: Visual
Diese Eigenschaft gibt an, wie weit die unterste Inhaltskante einer Box ber die unterste Kante
des umschließenden Blocks der Box verschoben wird.
'left'
Wert <length> | <percentage> | auto | inherit
Ausgangswert: auto
Angewendet auf: Positionierte Elemente
Vererbt: Nein
Prozentwerte: Beziehen sich auf die H=he des umschließenden Blocks
Medium: Visual
Diese Eigenschaft gibt an, wie weit die linke Inhaltskante einer Box nach rechts neben die linke
Kante des umschließenden Blocks der Box verschoben wird.
Die Werte f r die vier Eigenschaften haben die folgenden Bedeutungen:
Cascading Style Sheets, Level 2
<length>
Der Abstand ist ein feststehender Abstand von der Referenzkante.
<percentage>
Der Abstand ist ein Prozentwert der Breite (f r 'left' und 'right') oder H=he (f r 'top' und
'bottom') des umschließenden Blocks. F r 'top' und 'bottom' wird der Prozentwert als
'auto' interpretiert, wenn die H=he des umschließenden Blocks nicht explizit angegeben ist
(das heißt, sie ist von der Inhaltsh=he abh@ngig).
auto
Die Wirkung dieses Werts ist davon abh@ngig, welche „verwandten“ Eigenschaften eben-
falls den Wert 'auto' haben. Weitere Informationen finden Sie in den Abschnitten ber
Breite und H=he absolut positionierter, nicht ersetzter Elemente (10.3.7, 10.6.4 und 9.6).
F r absolut positionierte Boxen beziehen sich die Abst@nde auf den umschließenden Block der
Box. F r relativ positionierte Boxen beziehen sich die Offsets auf die @ußeren Kanten der
eigentlichen Box (d. h. die Box erh@lt eine Position im normalen Fluss, und wird dann gem@ß
dieser Eigenschaften von dieser Position aus verschoben).
< 638 > Visuelles Formatierungsmodell
Page size: 168,00 x 240,00 mm
9.4 Normaler Fluss
Boxen im normalen Fluss geh=ren zu einem Formatierungskontext, der entweder „Block“ oder
„Inline“ (inzeilig) sein kann; aber nicht beides zugleich. Block-Boxen befinden sich in einem
Block- Formatierungskontext. Inzeilige Boxen befinden sich in einem Inline- Formatierungskon-
text.
9.4.1 Block-Formatierungskontext
In einem Blockformatierungskontext werden Boxen nacheinander angelegt, vertikal, beginnend
oben in einem umschließenden Block. Der vertikale Abstand zwischen zwei gleichrangigen
Boxen wird durch die 'margin'-Eigenschaften bestimmt. Vertikale R@nder zwischen benachbar-
ten Block-Boxen in einem Blockformatierungskontext fallen zusammen.
In einem Blockformatierungskontext ber hrt jede linke @ußere Kante die linke Kante des
umschließenden Blocks (f r die Formatierung von rechts nach links ber hren sich die rechten
Kanten). Das gilt selbst dann, wenn Floats vorliegen (obwohl der Inhaltsbereich einer Box auf-
grund der Floats m=glicherweise schrumpft).
Informationen ber Seitenumbr che in Seitenmedien finden Sie im Abschnitt ber erlaubte Sei-
tenumbr che (13.3.4).
9.4.2 Inline-Formatierungskontext
In einem Inline-Formatierungskontext werden Boxen horizontal ausgelegt, hintereinander,
beginnend oben in einem umschließenden Block. Horizontale R@nder, Rahmen und Auff llung
werden zwischen diesen Boxen respektiert. Die Boxen k=nnen auf unterschiedliche Weise ver-
tikal ausgerichtet werden: ihre oberen oder unteren Kanten k=nnen ausgerichtet werden, oder
die Grundlinien des Texts in ihnen k=nnen ausgerichtet werden. Der rechteckige Bereich, der
die Boxen einer Zeile enth@lt, wird Zeilen-Box genannt.
Cascading Style Sheets, Level 2
Die Breite einer Zeilen-Box wird durch einen umgebenden Block bestimmt. Die H=he einer
Zeilen-Box wird durch die Regeln bestimmt, die im Abschnitt 10.8 ber Zeilenh=henberech-
nungen angegeben sind. Eine Zeilen-Box ist immer groß genug f r alle Boxen, die sie enth@lt.
Sie kann jedoch gr=ßer sein, als die gr=ßte Box, die sie enth@lt (zum Beispiel falls die Boxen
nach den Grundlinien ausgerichtet sind). Ist die H=he einer Box B kleiner als die H=he der Zei-
len-Box, in der sie enthalten ist, wird die vertikale Ausrichtung von B innerhalb der Zeilen-Box
durch die 'vertical-align'-Eigenschaft bestimmt.
Passen mehrere inzeilige Boxen nicht horizontal in eine einzelne Zeilen-Box, werden sie ber
zwei oder mehr vertikal hintereinandergeschaltete Zeilen-Boxen verteilt. Ein Absatz ist also ein
vertikaler Stapel von Zeilen-Boxen. Zeilen-Boxen werden ohne vertikale Abtrennung gestapelt
und berlappen sich nie.
Im Allgemeinen ber hrt die linke Kante einer Zeilen-Box die linke Kante ihres umschließenden
Blocks, und die rechte Kante ber hrt die rechte Kante ihres umschließenden Blocks. Floating-
Boxen dagegen k=nnen zwischen der Kante des umschließenden Blocks und der Kante der
Zeilen-Box liegen. Obwohl also Zeilen-Boxen im selben Inline-Formatierungskontext also im
Allgemeinen dieselbe Breite haben (die des umschließenden Blocks), k=nnen sie in der Breite
variieren, wenn der verf gbare horizontale Platz aufgrund von Floats reduziert wird. Zeilen-Bo-
xen im selben Inline-Formatierungskontext variieren in der Regel in der H=he (zum Beispiel
k=nnte eine Zeile ein großes Bild enthalten, w@hrend andere nur Text enthalten).
Normaler Fluss < 639 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Ist die Gesamtbreite der inzeiligen Boxen in einer Zeile kleiner als die Breite der Zeilen-Box,
die sie enth@lt, wird ihre horizontale Verteilung innerhalb der Zeilen-Box durch die 'text-
align'-Eigenschaft bestimmt. Hat diese Eigenschaft den Wert 'justify', kann das Benutzerpro-
gramm die inzeiligen Boxen auch strecken.
Weil eine inzeilige Box die Breite einer Zeilen-Box nicht berschreiten kann, werden lange
inzeilige Boxen in mehrere Boxen zerlegt und dann ber mehrere Zeilen-Boxen verteilt. Wenn
eine inzeilige Box aufgeteilt wird, haben R@nder, Rahmen und Auff llung keine sichtbare Wir-
kung, wo die Aufteilung stattfindet. Die Formatierung von R@ndern, Rahmen und Auff llung ist
m=glicherweise nicht vollst@ndig definiert, wenn die Aufteilung innerhalb einer bidirektionalen
Einbettung stattfindet.
Inzeilige Boxen k=nnen aufgrund einer bidirektionalen Textverarbeitung auch innerhalb dersel-
ben Zeilenbox aufgeteilt werden.
Beispiel
Nachfolgend sehen Sie ein Beispiel f r eine inzeilige Box. Der folgende Absatz (erzeugt
durch das HTML-Blockebenenelement P) enth@lt anonymen Text, unterbrochen durch
die Elemente EM und STRONG:
<P>Mehrere <EM>betonte W^rter</EM> findet man
<STRONG>in diesem einzigen</STRONG> Satz, mein Lieber.</P>
Das P-Element erzeugt eine Block-Box, die f nf inzeilige Boxen enth@lt, von denen drei anonym
sind:
·· Anonym: „Mehrere“
EM: „betonte W=rter“
·· Anonym: „findet man“
STRONG: „in diesem einzigen“
· Anonym: „Satz, mein Lieber.“
Cascading Style Sheets, Level 2
Um den Absatz zu formatieren, ordnet das Benutzerprogramm die f nf Boxen in Zeilen-Boxen
an. In diesem Beispiel richtet die Box, die f r das P-Element erzeugt wird, den umschließenden
Block f r die Zeilen-Boxen ein. Ist der umschließende Block breit genug, passen alle inzeiligen
Boxen in eine einzige Box:
Mehrere betonte W rter findet man in diesem einzigen Satz, mein Lieber.
Andernfalls werden die Inline-Boxen getrennt und ber mehrere Zeilen-Boxen verteilt. Der
obige Abschnitte k=nnte wie folgt aufgeteilt werden:
Mehrere betonte W rter findet man
in diesem einzigen Satz, mein Lieber.
Oder so:
Mehrere betonte
W rter findet man in diesem einzigen
Satz, mein Lieber.
Im obigen Beispiel wurde die EM-Box in zwei EM-Boxen unterteilt (nennen wir sie „split1“ und
„split2“). R@nder, Rahmen, Auff llung oder Textausschm ckung haben keinen sichtbaren Effekt
nach split1 oder vor split2.
< 640 > Visuelles Formatierungsmodell
Page size: 168,00 x 240,00 mm
Beispiel
Betrachten Sie das folgende Beispiel:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>Beispiel fUr Inline-Fluss Uber mehrere Zeilen</TITLE>
<STYLE type="text/css">
EM {
padding: 2px;
margin: 1em;
border-width: medium;
border-style: dashed;
line-height: 2.4em;
}
</STYLE>
</HEAD>
<BODY>
<P>Several <EM>emphasized words</EM> appear here.</P>
</BODY>
</HTML>
Abh@ngig von der Breite von P k=nnen die Boxen wie folgt verteilt werden:
Line height 2.4em
Several emphasized
words appear here.
Width of paragraph
··
Cascading Style Sheets, Level 2
Der Rand wird vor „emphasized“ und hinter „words“ eingef gt.
Die Auff llung wird vor, oberhalb und unterhalb von „emphasized“ und hinter, oberhalb
und unterhalb von „words“ eingef gt. In jedem Fall wird auf drei Seiten ein gestrichelter
Rahmen angezeigt.
9.4.3 Relative Positionierung
Nachdem eine Box einem normalen Fluss entsprechend ausgerichtet wurde, kann sie relativ zu
ihrer Position verschoben werden. Man spricht auch von einer relativen Positionierung. Ver-
schiebt man eine Box (B1) auf diese Weise, hat das keine Auswirkung auf die nachfolgende Box
(B2): B2 erh@lt eine Position, als w@re B1 nicht verschoben, und B2 wird nicht neu positioniert,
nachdem B1 verschoben wurde. Das bedeutet gleichzeitig, dass sich die Boxen aufgrund der
relativen Positionierung berlappen k=nnen.
Relativ positionierte Boxen behalten ihre normale Flussgr=ße bei, inklusive der Zeilenumbr -
che und dem Platz, der urspr nglich f r sie reserviert wurde. Eine relativ positionierte Box
richtet einen neuen umschließenden Block f r untergeordnete Elemente und positionierte
abgeleitete Elemente im normalen Fluss ein.
Eine relativ positionierte Box wird erzeugt, wenn die 'position'-Eigenschaft f r ein Element den Wert
'relative' hat. Der Offset wird durch die Eigenschaften 'top', 'bottom', 'left' und 'right' angegeben.
Normaler Fluss < 641 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Eine dynamische Bewegung relativ positionierter Boxen kann in Skripting-Umgebungen Anima-
tionseffekte erzielen (siehe auch Eigenschaft 'visibility', 11.2). Die relative Positionierung kann
auch als allgemeine Form der Hochstellung und Tiefstellung verwendet werden, nur dass die
Zeilenh=he nicht automatisch angepasst wird, um die Positionierung zu ber cksichtigen. Wei-
tere Informationen finden Sie im Abschnitt ber die Berechnung der Zeilenh=he (11.8).
Beispiele f r die relative Positionierung finden Sei im Abschnitt ber den Vergleich von norma-
lem Fluss, Floats und absoluter Positionierung (9.8).
9.5 Floats
Ein Float ist eine Box, die in der aktuellen Zeile nach links oder rechts verschoben wird. Das
interessanteste Merkmal eines Floats (oder „Floated-“ oder „Floating“-Box) ist, dass Inhalt an
seiner Seite vorbeifließen kann (oder dass dies durch die 'clear'-Eigenschaft unterbunden wer-
den kann). Inhalt fließt an der rechten Seite einer links-floated Box vorbei, und links von einer
rechts-floated Box. Nachfolgend finden Sie eine Einf hrung in die Float-Positionierung und den
Inhaltsfluss; die genauen Regeln zum Float-Verhalten finden Sie in der Beschreibung der
'float'-Eigenschaft.
Eine Floating-Box muss eine explizite Breite haben (die ber die 'width'-Eigenschaft zugewiesen
wird oder bei der es sich im Fall von ersetzten Elementen um eine eigene Breite handelt). Eine
Floating-Box wird zu einer Block-Box, die nach links oder rechts verschoben wird, bis ihre
@ußere Kante die Kante des umschließenden Blocks oder die @ußere Kante eines anderen Flo-
ats ber hrt. Die obere Kante der Floating-Box wird an der oberen Kante der aktuellen Zeilen-
Box (oder der unteren Kante des vorhergehenden Blocks, falls es keine Zeilen-Box gibt) aus-
gerichtet. Falls nicht gen gend horizontaler Platz in der aktuellen Zeile f r den Float vorhanden
ist, wird er Zeile f r Zeile nach unten verschoben, bis eine Zeile gen gend Platz daf r bietet.
Weil sich ein Float nicht im Fluss befindet, fließen nicht-positionierte Block-Boxen, die vor und
nach der Floating-Box erzeugt werden, vertikal vorbei, als w rde der Float gar nicht existieren.
Zeilen-Boxen jedoch, die neben dem Float erzeugt werden, werden gek rzt, um Platz f r die
Cascading Style Sheets, Level 2
Floating-Box zu schaffen. Der Inhalt in der aktuellen Zeile vor einer Floating-Box wird in der
ersten verf gbaren Zeile auf der anderen Seite des Floats neu angeordnet.
Mehrere Floats k=nnen benachbart sein, und dieses Modell gilt auch f r benachbarte Floats
innerhalb derselben Zeile.
Beispiel
Die folgende Regel bewirkt, dass alle IMG-Boxen mit class="icon" links vorbeifließen
(der linke Rand wird auf '0' gesetzt).
[Link] {
float: left;
margin-left: 0;
}
Betrachten Sie die folgende HTML-Datei und das Stylesheet:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>Float example</TITLE>
< 642 > Visuelles Formatierungsmodell
Page size: 168,00 x 240,00 mm
<STYLE type="text/css">
IMG { float: left }
BODY, P, IMG { margin: 2em }
</STYLE>
</HEAD>
<BODY>
<P><IMG src=[Link] alt="This image will illustrate floats">
Some sample text that has no other...
</BODY>
</HTML>
Die IMG-Box wird nach links verschoben. Der nachfolgende Inhalt wird rechts vom Float forma-
tiert, in derselben Zeile wie der Float beginnend. Die Zeilen-Boxen rechts vom Float werden
durch das Vorhandensein des Floats gek rzt, nehmen aber nach dem Float ihre „normale“ Breite
wieder an (das ist die Breite des durch das P-Element eingerichteten umschließenden Blocks).
Die Formatierung w@re genau dieselbe, h@tte das Dokument wie folgt ausgesehen:
Cascading Style Sheets, Level 2
<BODY>
<P>Some sample text
<IMG src=[Link] alt="This image will illustrate floats">
that has no other...
</BODY>
weil der Inhalt links vom Float durch den Float verdr@ngt wird und auf dessen rechten Seite
entlang verl@uft.
Die R@nder der Floating-Boxen fallen niemals mit R@ndern benachbarter Boxen zusammen. Im
vorigen Beispiel fallen also die vertikalen R@nder zwischen P-Box und der Floating-IMG-Box
nicht zusammen.
Ein Float kann andere Boxen im normalen Fluss berlappen (z. B. wenn eine Box im normalen
Fluss neben einem Float negative R@nder hat). berlappt eine inzeilige Box einen Float, werden
der Inhalt, der Hintergrund und die Rahmen der inzeiligen Box vor dem Float dargestellt. ber-
lappt eine Block-Box, werden der Hintergrund und die Rahmen der Block-Box hinter dem
Float dargestellt und sind nur dann sichtbar, wenn die Box transparent ist. Der Inhalt der Block-
Box wird vor dem Float dargestellt.
Nachfolgend sehen Sie eine weitere Darstellung, die zeigt, was passiert, wenn ein Float die Rah-
men von Elementen im normalen Fluss berlappt.
Floats < 643 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
image margin paragraph margin
paragraph border
paragraph padding
Some sample text in the first paragraph. It has a floating
image that was right about here (X) in the
source. However, the image is so large that
it extends below the text of this paragraph.
The second paragraph is therefore also
affected. Any inline boxes in it are "pushed
aside," as they are forbidden from coming
inside the area delimited by the floating image’s margins.
Note that the paragraph boxes are still rectangular, but
their borders and backgrounds are "clipped" or interrupted
by the floating image.
Abbildung 9.2: Ein Floating-Bild verdeckt die Rahmen von Block-Boxen, wenn eine berlappung
stattfindet.
Das folgende Beispiel zeigt die Verwendung der 'clear'-Eigenschaft, um zu verhindern, dass
Inhalt neben einem Float vorbeifließt.
Beispiel
Nehmen wir die folgende Regel an:
P { clear: left }
Damit k=nnte die Formatierung wie folgt aussehen:
Cascading Style Sheets, Level 2
image margin paragraph margin
paragraph border
paragraph padding
Some sample text in the first paragraph. It has a floating
image that was right about here (X) in the
source. However, the image is so large that
it extends below the text of this paragraph.
This paragraph has its ’clear’ propery set to ’left,’ so
that it will be forced to be below any left−floating images.
This is done by increasing its top margin.
Abbildung 9.3: Beide Abs@tzen haben 'clear: left' gesetzt, so dass der zweite Absatz auf eine
Position unterhalb des Floats nach unten geschoben wird – sein oberer Rand wird erweitert,
um dies zu bewerkstelligen (siehe auch den Abschnitt ber die 'clear'-Eigenschaft).
< 644 > Visuelles Formatierungsmodell
Page size: 168,00 x 240,00 mm
9.5.1 Positionierung des Floats: die 'float'-Eigenschaft
'float'
Wert left | right | none | inherit
Ausgangswert: none
Angewendet auf: Alle Elemente außer positionierte Elemente und erzeugter Inhalt
Vererbt: Nein
Prozentwerte: N/A
Medium: Visual
Diese Eigenschaft gibt an, ob eine Box nach links, rechts oder berhaupt nicht gleiten soll. Sie
kann f r alle Elemente gesetzt werden, die Boxen erzeugen, die nicht absolut positioniert sind.
Die Werte dieser Eigenschaft haben die folgenden Bedeutungen:
left
Das Element erzeugt eine Block-Box, die nach links gleitet. Der Inhalt fließt an der rechten
Seite der Box vorbei, beginnend oben (der 'clear'-Eigenschaft unterliegend). Die 'display'-
Eigenschaft wird ignoriert, es sei denn, sie hat den Wert 'none'.
right
Wie 'left', außer dass der Inhalt an der linken Seite der Box vorbeifließt, beginnend von
oben.
none
Die Box gleitet nicht.
Nachfolgend die genauen Regeln, die das Verhalten von Floats steuern:
Cascading Style Sheets, Level 2
1. Die linke @ußere Kante einer Links-Floating-Box darf sich nicht links von der linken Kante
ihres umschließenden Blocks befinden. Analog gilt die Regel f r Rechts-Floating-Elemente.
2. Ist die aktuelle Box links-floating und es gibt noch weitere Links-Floating-Boxen, die von
Elementen an fr herer Stelle des Quelldokuments erzeugt wurden, dann muss f r jede die-
ser fr heren Boxen entweder die linke @ußere Kante der aktuellen Box rechts von der
rechten @ußeren Kante der fr heren Box liegen, oder ihre obere Kante muss tiefer als die
untere Kante der fr heren Box liegen. Analoge Regeln gelten f r Rechts-Floating-Boxen.
3. Die rechte @ußere Kante einer Links-Floating-Box darf nicht rechts von der linken @ußeren
Kante einer Rechts-Floating-Box liegen, die sich rechts von ihr befindet. Analoge Regeln gel-
ten f r Rechts-Floating-Elemente.
4. Die @ußere obere Kante einer Floating-Box darf nicht h=her sein als die oberste Kante des
umschließenden Blocks.
5. Die @ußere obere Kante einer Floating-Box darf nicht h=her als die @ußere obere Kante
einer Block- oder Floating-Box liegen, die von einem fr heren Element im Quelldokument
erzeugt wurde.
6. Die @ußere obere Kante der Floating-Box eines Elements darf nicht h=her liegen als die
obere Kante einer Zeilen-Box, die eine Box enth@lt, die von einem fr heren Element im
Quelldokument erzeugt wurde.
Floats < 645 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
7. Eine Links-Floating-Box, zu deren Linken sich eine weitere Links-Floating-Box befindet, darf
ihre rechte @ußere Kante nicht rechts von der rechten Kante ihres umschließenden Blocks
haben. (Locker ausgedr ckt: Ein linker Float darf nicht an der rechten Kante herausragen,
es sei denn, er befindet sich schon so weit links wie m=glich.) Eine analoge Regel gilt f r
Rechts-Floating-Elemente.
8. Eine Floating-Box muss so hoch wie m=glich platziert werden.
9. Eine Links-Floating-Box muss so weit wie m=glich links, eine Rechts-Floating-Box so weit
wie m=glich rechts liegen. Eine h=here Position wird gegen ber einer weiter links/rechts
liegenden bevorzugt.
9.5.2 Steuerung des Flusses neben Floats: die 'clear'-Eigenschaft
'clear'
Wert none | left | right | both | inherit
Ausgangswert: none
Angewendet auf: Elemente auf Blockebene
Vererbt: Nein
Prozentwerte: N/A
Medium: Visual
Diese Eigenschaft gibt an, welche Seiten der Boxen eines Elements nicht neben einer vorher-
gehenden Floating-Box stehen d rfen. (Es kann sein, dass das eigentliche Element Floating-Ab-
leitungen hat; auf diese Nachkommen hat 'clear' keine Auswirkungen.)
Diese Eigenschaft kann f r Elemente auf Blockebene (auch Floats) angegeben werden. F r
Compact- und Run-in-Boxen bezieht sich diese Eigenschaft auf die letzte Block-Box, zu der die
Cascading Style Sheets, Level 2
Compact- oder Run-in-Box geh=rt.
Die Werte haben die folgenden Bedeutungen, wenn sie auf Nicht-Floating-Block-Boxen ange-
wendet werden:
left
Der obere Rand der erzeugten Box wird so weit vergr=ßert, dass sich die obere Rahmen-
kante unterhalb der unteren @ußeren Kante aller Links-Floating-Boxen befindet, die aus fr -
heren Elementen des Quelldokuments resultieren.
right
Der obere Rand der erzeugten Box wird so weit vergr=ßert, dass die obere Rahmenkante
unterhalb der unteren @ußeren Kante aller Rechts-Floating-Boxen liegt, die aus fr heren
Elementen des Quelldokuments resultieren.
both
Die erzeugte Box wird an eine Position unterhalb aller Floating-Boxen fr herer Elemente
des Quelldokuments geschoben.
none
Es gibt keine Beschr@nkungen f r die Position der Box relativ zu Floats.
< 646 > Visuelles Formatierungsmodell
Page size: 168,00 x 240,00 mm
Wenn die Eigenschaft f r Floating-Elemente gesetzt wird, f hrt das zu einer Onderung der Posi-
tionierungsregeln f r den Float. Eine zus@tzliche Bedingung (#10) wird eingef gt:
· Die obere @ußere Kante des Float muss sich unterhalb der unteren @ußeren Kante aller fr -
heren Links-Floating-Boxen befinden (f r 'clear: left') oder unterhalb aller Rechts-Floating-
Boxen (f r 'clear: right') oder beides ('clear: both') liegen.
9.6 Absolute Positionierung
Im Modell der absoluten Positionierung wird eine Box explizit relativ zu ihrem umschließenden
Block verschoben. Sie wird v=llig aus dem normalen Fluss entfernt (sie hat keinen Einfluss auf
sp@tere gleichrangige Elemente). Eine absolut positionierte Box richtet einen neuen umschlie-
ßenden Block f r untergeordnete Elemente im normalen Fluss und f r positionierte Nachkom-
men ein. Der Inhalt eines absolut positionierten Elements fließt jedoch nicht um andere Boxen
herum. Sie k=nnen den Inhalt einer anderen Box verdecken oder nicht, abh@ngig von den Sta-
pelebenen der berlappenden Boxen.
Wenn in dieser Spezifikation von einem absolut positionierten Element (oder seiner Box) gespro-
chen wird, bedeutet das, dass die 'position'-Eigenschaft des Elements den Wert 'absolute' oder
'fixed' hat.
9.6.1 Feste Positionierung
Die feste Positionierung ist eine Unterkategorie der absoluten Positionierung. Der einzige
Unterschied ist, dass der umschließende Block f r eine fest positionierte Box von dem
Viewport eingerichtet wird. Bei Endlosmedien werden feste Boxen nicht verschoben, wenn das
Dokument weitergebl@ttert wird. In dieser Hinsicht sind sie mit festen Hintergrundbildern ver-
gleichbar. Bei Seitenmedien werden Boxen mit festen Positionen auf jeder Seite wiederholt.
Das ist praktisch, um beispielsweise eine Signatur unten auf jeder Seite zu platzieren.
Cascading Style Sheets, Level 2
Beispiel
Autoren k=nnen die feste Positionierung verwenden, um Frame-@hnliche Pr@senta-
tionen zu erzeugen. Betrachten Sie das folgende Frame-Layout:
100%
header 15%
s
i
d
e main "the rest"
b
a
r
10em
footer 100px
Absolute Positionierung < 647 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Das k=nnte mit dem folgenden HTML-Dokument und diesen Stilregeln erzielt werden:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>A frame document with CSS2</TITLE>
<STYLE type="text/css">
BODY { height: 8.5in } /* Required for percentage heights below */
#header {
position: fixed;
width: 100%;
height: 15%;
top: 0;
right: 0;
bottom: auto;
left: 0;
}
#sidebar {
position: fixed;
width: 10em;
height: auto;
top: 15%;
right: auto;
bottom: 100px;
left: 0;
}
#main {
position: fixed;
width: auto;
height: auto;
top: 15%;
right: 0;
bottom: 100px;
left: 10em;
Cascading Style Sheets, Level 2
}
#footer {
position: fixed;
width: 100%;
height: 100px;
top: auto;
right: 0;
bottom: 0;
left: 0;
}
</STYLE>
</HEAD>
<BODY>
<DIV id="header"> ... </DIV>
<DIV id="sidebar"> ... </DIV>
<DIV id="main"> ... </DIV>
<DIV id="footer"> ... </DIV>
</BODY>
</HTML>
< 648 > Visuelles Formatierungsmodell
Page size: 168,00 x 240,00 mm
9.7 Beziehungen zwischen 'display', 'position' und 'float'
Die drei Eigenschaften, die das Erstellen und das Layout von Boxen beeinflussen – 'display',
'position' und 'float' – arbeiten wie folgt zusammen:
1. Wenn 'display' den Wert 'none' hat, m ssen Benutzerprogramme 'position' und 'float' igno-
rieren. In diesem Fall erzeugt das Element keine Box.
2. Andernfalls, wenn 'position' den Wert 'absolute' oder 'fixed' hat, werden 'display' auf 'block'
und 'float' auf 'none' gesetzt. Die Position der Box wird durch die Eigenschaften 'top', 'right',
'bottom' und 'left' und den umschließenden Block der Box bestimmt.
3. Andernfalls, wenn 'float' einen anderen Wert als 'none' hat, wird 'display' auf 'block' gesetzt
und die Box gleitet.
4. Andernfalls werden die restlichen 'display'-Eigenschaften wie angegeben angewendet.
Hinweis: CSS2 gibt kein Layoutverhalten vor, wenn die Werte f r diese Eigenschaften durch
Skripte ge@ndert werden. Was passiert beispielsweise, wenn ein Element mit 'width: auto' neu
positioniert wird? Wird der Inhalt neu dargestellt, oder wird die urspr ngliche Formatierung
beibehalten? Im Rahmen dieses Dokuments gibt es keine Antwort darauf, und in diesem Verhal-
ten werden sich fr he Implementierungen von CSS2 wahrscheinlich voneinander unterschei-
den. n
9.8 Vergleich von normalem Fluss, Floats und absoluter
Positionierung
Um die Unterschiede zwischen normalem Fluss, relativer Positionierung, Floats und absoluter
Positionierung zu beschreiben, zeigen wir hier mehrere Beispiele, die auf dem folgenden
HTML-Ausschnitt basieren:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
Cascading Style Sheets, Level 2
<HTML>
<HEAD>
<TITLE>Comparison of positioning schemes</TITLE>
</HEAD>
<BODY>
<P>Beginning of body contents.
<SPAN id="outer"> Start of outer contents.
<SPAN id="inner"> Inner contents.</SPAN>
End of outer contents.</SPAN>
End of body contents.
</P>
</BODY>
</HTML>
In diesem Dokument gehen wir von den folgenden Regeln aus:
BODY { display: block; line-height: 200%;
width: 400px; height: 400px }
P { display: block }
SPAN { display: inline }
Beziehungen zwischen 'display', 'position' und 'float' < 649 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Die endg ltigen Positionen von Boxen, die durch @ußere und innere Elemente erzeugt werden,
variieren in jedem Beispiel. Die Zahlen links von jeder Abbildung geben die Position der Zeilen
(die der Verst@ndlichkeit halber doppelten Zeilenabstand besitzen) f r den normalen Fluss an.
(Hinweis: die Abbildungen verwenden unterschiedliche horizontale und vertikale Maßst@be.)
9.8.1 Normaler Fluss
Betrachten Sie die folgenden CSS-Deklarationen f r outer und inner, die den normalen Fluss der
Boxen nicht ver@ndern:
#outer { color: red }
#inner { color: blue }
Das P-Element enth@lt den gesamten Inline-Inhalt: anonymen Inline-Text und zwei SPAN-Ele-
mente. Aus diesem Grund wird der gesamte Inhalt in einem Inline-Formatierungskontext aus-
gelegt, und zwar innerhalb eines von dem P-Element eingerichteten umschließenden Blocks,
woraus sich etwa Folgendes ergibt:
Cascading Style Sheets, Level 2
9.8.2 Relative Positionierung
Um die Auswirkungen der relativen Positionierung zu beobachten, geben wir Folgendes an:
#outer { position: relative; top: -12px; color: red }
#inner { position: relative; top: 12px; color: blue }
< 650 > Visuelles Formatierungsmodell
Page size: 168,00 x 240,00 mm
Text fließt normalerweise bis zum outer-Element. Der outer-Text fließt dann an seine normale
Flussposition und in seiner normalen Gr=ße an das Ende von Zeile 1. Anschließend werden die
Inline-Boxen, die den Text enthalten ( ber drei Zeilen verteilt) alle zusammen um '-12px' (nach
oben) verschoben.
Der Inhalt von inner, als untergeordnetes Element von outer, w rde normalerweise unmittelbar
hinter die W=rter „of outer contents“ (in Zeile 15) fließen. Die inner-Inhalte werden jedoch
selbst relativ zum outer-Inhalt um '12px' (nach unten) verschoben, zur ck an ihre urspr ngliche
Position in Zeile 2.
Beachten Sie, dass der Inhalt nach outer nicht von der relativen Positionierung von outer beein-
flusst wird.
Cascading Style Sheets, Level 2
Beachten Sie auch, dass sich der Text von outer und der Rumpftext berlappt h@tten, w@re der
Abstand von outer gleich '-24px' gewesen.
9.8.3 Eine Box floaten
Betrachten Sie jetzt, was passiert, wenn der Text des Elements inner mit Hilfe der folgenden
Regeln nach rechts gleitet:
#outer { color: red }
#inner { float: right; width: 130px; color: blue }
Text fließt normalerweise bis zur inner-Box, die aus dem Fluss genommen und an den rechten
Rand verschoben wird (ihre 'width'-Eigenschaft wurde explizit zugewiesen). Zeilen-Boxen links
von dem Float werden gek rzt, und der verbleibende Text des Dokuments fließt in sie hinein.
Normaler Fluss, Floats und absolute Positionierung < 651 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Um die Wirkung der 'clear'-Eigenschaft zu demonstrieren, f gen wir dem Beispiel ein gleichran-
giges Element hinzu:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>Comparison of positioning schemes II</TITLE>
</HEAD>
<BODY>
Cascading Style Sheets, Level 2
<P>Beginning of body contents.
<SPAN id=outer> Start of outer contents.
<SPAN id=inner> Inner contents.</SPAN>
<SPAN id=sibling> Sibling contents.</SPAN>
End of outer contents.</SPAN>
End of body contents.
</P>
</BODY>
</HTML>
Die folgenden Regeln
#inner { float: right; width: 130px; color: blue }
#sibling { color: red }
bewirken, dass die inner-Box wie zuvor rechts vorbeifließt und dass der restliche Text des
Dokuments in den freien Platz einfließt:
< 652 > Visuelles Formatierungsmodell
Page size: 168,00 x 240,00 mm
Wird die 'clear'-Eigenschaft des gleichrangigen Elements jedoch auf 'right' gesetzt (das heißt, die
erzeugte Box f r das gleichrangige Element akzeptiert keine Position neben Floating-Boxen
rechts von ihm), beginnt der Inhalt des gleichrangigen Elements, unter diesen Float zu fließen:
#inner { float: right; width: 130px; color: blue }
#sibling { clear: right; color: red }
Cascading Style Sheets, Level 2
Normaler Fluss, Floats und absolute Positionierung < 653 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
9.8.4 Absolute Positionierung
Schließlich betrachten wir die Auswirkung einer absoluten Positionierung. Betrachten Sie die
folgenden CSS-Deklarationen f r outer und inner:
#outer {
position: absolute;
top: 200px; left: 200px;
width: 200px;
color: red;
}
#inner { color: blue }
Sie bewirken, dass die obere Kante der outer-Box relativ zu ihrem umschließenden Block posi-
tioniert wird. Der umschließende Block f r eine positionierte Box wird durch den n@chsten
positionierten Vorfahren eingerichtet (oder, falls es keinen solchen gibt, durch den umschlie-
ßenden Ausgangsblock, wie in unserem Beispiel gezeigt). Die obere Seite der outer-Box liegt
'200px' unterhalb der oberen Kante des umschließenden Blocks, und die linke Seite liegt
'200px' von der linken Seite entfernt. Die untergeordnete Box von outer fließt normalerweise
relativ zu ihrem bergeordneten Element.
(0,0) Document Window (0, 400)
1 Beginning of body contents. End of
24 px
2 body contents.
4
Cascading Style Sheets, Level 2
(200, 200)
5 Start of outer
6 contents. Inner
7 contents. End of
8 outer contents.
(400, 0) (400, 400)
Das folgende Beispiel zeigt eine absolut positionierte Box, die ein untergeordnetes Element
einer relativ positionierten Box ist. Obwohl die bergeordnete outer-Box nicht wirklich ver-
schoben wird, bedeutet es, dass diese Box als umschließender Block f r positionierte Nach-
kommen dienen kann, wenn ihre 'position'-Eigenschaft auf 'relative' gesetzt wird. Weil die
outer-Box eine inzeilige Box ist, die ber mehrere Zeilen verteilt wird, dienen die oberen und
linken Kanten der ersten inzeiligen Box (in der nachfolgenden Abbildung durch dicke gestri-
chelte Linien dargestellt) als Referenzpunkte f r die Abst@nde von 'top' und 'left'.
< 654 > Visuelles Formatierungsmodell
Page size: 168,00 x 240,00 mm
#outer {
position: relative;
color: red
}
#inner {
position: absolute;
top: 200px; left: -100px;
height: 130px; width: 130px;
color: blue;
}
Daraus ergibt sich etwa Folgendes:
Cascading Style Sheets, Level 2
Wenn wir die outer-Box nicht positionieren:
#outer { color: red }
#inner {
position: absolute;
top: 200px; left: -100px;
height: 130px; width: 130px;
color: blue;
}
wird der umschließende Block f r inner zum umschließenden Ausgangsblock (in unserem Bei-
spiel). Die folgende Abbildung zeigt, wo die inner-Box in diesem Fall angeordnet w rde.
Normaler Fluss, Floats und absolute Positionierung < 655 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Die relative und absolute Positionierung kann verwendet werden, um Onderungskennzeichen
zu implementieren, wie im folgenden Beispiel gezeigt. Das folgende Dokument:
<P style="position: relative; margin-right: 10px; left: 10px;">
I used two red hyphens to serve as a change bar. They
will "float" to the left of the line containing THIS
<SPAN style="position: absolute; top: auto; left: -1em; color: red;">- -</SPAN>
word.</P>
k=nnte etwa Folgendes erzeugen:
Cascading Style Sheets, Level 2
Zun@chst fließt der Absatz (die Seiten seines umschließenden Blocks werden in der Abbildung
gezeigt) normal. Anschließend wird er um '10px' von der linken Kante des umschließenden
Blocks verschoben (deshalb wurde ein rechter Rand von '10px' reserviert, weil ein Offset vor-
hergesehen wurde). Die beiden Trennstriche, die als Onderungskennzeichner dienen, werden
aus dem Fluss genommen und in der aktuellen Zeile positioniert (aufgrund von 'top: auto'),
'-1em' von der linken Kante des umschließenden Blocks entfernt (eingerichtet durch das P an
seiner endg ltigen Position). Das Ergebnis ist, dass die Onderungskennzeichner links in die aktu-
elle Zeile zu „fließen“ scheinen.
< 656 > Visuelles Formatierungsmodell
Page size: 168,00 x 240,00 mm
9.9 Ebenen (Layer)
In den folgenden Abschnitten bedeutet der Ausdruck „vor“ dass sich etwas n@her beim Benut-
zer befindet, wenn dieser den Bildschirm betrachtet.
In CSS2 hat jede Box eine Position in drei Dimensionen. Neben ihren horizontalen und vertika-
len Positionen liegen Boxen entlang einer „Z-Achse“ und sind bereinander formatiert. Z-Ach-
sen-Positionen sind vor allem relevant, wenn sich Boxen visuell berlappen. Dieser Abschnitt
beschreibt, wie Boxen entlang der Z-Achse positioniert werden.
Jede Box geh=rt zu einem Stapelkontext. Jede Box in einem bestimmten Stapelkontext hat eine
ganzzahlige Stapelebene, die ihre Position auf der Z-Achse relativ zu anderen Boxen im selben
Stapelkontext angibt. Boxen mit h=heren Stapelebenen werden immer vor Boxen mit niedrige-
ren Stapelebenen positioniert. Boxen k=nnen negative Stapelebenen haben. Boxen mit dersel-
ben Stapelebene in einem Stapelkontext werden von unten nach oben der Reihenfolge im
Dokumentbaum entsprechend gestapelt.
Das Wurzelelement erzeugt einen Wurzelstapelkontext, aber andere Elemente k=nnen lokale
Stapelkontexte einrichten. Stapelkontexte werden vererbt. Ein lokaler Stapelkontext ist atomar;
Boxen aus anderen Stapelkontexten d rfen nicht zwischen seine Boxen gelangen.
Ein Element, das einen lokalen Stapelkontext einrichtet, erzeugt eine Box, die zwei Stapelebe-
nen hat: eine f r den Stapelkontext, den es erzeugt (immer '0'), und eine f r den Stapelkontext,
zu dem es geh=rt (durch die 'z-index'-Eigenschaft angegeben).
Die Box eines Elements hat dieselbe Stapelebene wie die Box des bergeordneten Elements, es
sei denn, in der 'z-index'-Eigenschaft ist eine andere Stapelebene angegeben.
9.9.1 Angabe der Stapelebene: die 'z-index'-Eigenschaft
'z-index'
Wert auto | <integer> | inherit
Cascading Style Sheets, Level 2
Ausgangswert: auto
Angewendet auf: Positionierte Elemente
Vererbt: Nein
Prozentwerte: N/A
Medium: Visual
F r eine positionierte Box gibt die 'z-index'-Eigenschaft Folgendes an:
1. Die Stapelebene der Box im aktuellen Stapelkontext.
2. Ob die Box einen lokalen Stapelkontext einrichtet.
Die Werte haben die folgenden Bedeutungen:
<integer>
Diese ganze Zahl ist die Stapelebene der erzeugten Box im aktuellen Stapelkontext. Außer-
dem richtet die Box einen lokalen Stapelkontext ein, indem ihre Stapelebene gleich '0' ist.
auto
Die Stapelebene der erzeugten Box im aktuellen Stapelkontext ist dieselbe wie die der Box
seines bergeordneten Elements. Die Box richtet keinen neuen lokalen Stapelkontext ein.
Ebenen (Layer) < 657 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Beispiel
Im folgenden Beispiel sind die Stapelebenen (angegeben durch ihre „id“-Attribute)
„text2“=0, „image“=1, „text3“=2 und „text1“=3. Die Stapelebene „text2“ wurde von
der Wurzel-Box geerbt. Die anderen sind mit der 'z-index'-Eigenschaft spezifiziert.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>Positionierung in Z-Reihenfolge</TITLE>
<STYLE type="text/css">
.pile {
position: absolute;
left: 2in;
top: 2in;
width: 3in;
height: 3in;
}
</STYLE>
</HEAD>
<BODY>
<P>
<IMG id="image" class="pile"
src="[Link]" alt="A butterfly image"
style="z-index: 1">
<DIV id="text1" class="pile"
style="z-index: 3">
Dieser Text Uberlagert das Schmetterlingsbild.
</DIV>
<DIV id="text2">
Dieser Text befindet sich unterhalb von allem.
</DIV>
<DIV id="text3" class="pile"
style="z-index: 2">
Cascading Style Sheets, Level 2
Dieser Text liegt unter text1, Uberlagert aber das Schmetterlingsbild.
</DIV>
</BODY>
</HTML>
Dieses Biespiel demonstriert das Konzept der Transparenz. Standardm@ßig verh@lt sich eine
Box so, dass dahinterliegende Boxen durch die transparenten Bereiche in ihrem Inhalt sichtbar
sind. Im Beispiel berlagert jede Box transparent die darunterliegende Box. Dieses Verhalten
kann mit Hilfe einer der existierenden Hintergrundeigenschaften berschrieben werden.
9.10 Textrichtung: die Eigenschaften 'direction' und
'unicode-bidi'
In manchen Schriften werden die Buchstaben von rechts nach links geschrieben. In manchen
Dokumenten, insbesondere solchen, die in Arabisch oder Hebr@isch geschrieben sind, sowie in
einigen gemischtsprachigen Kontexten kann Text innerhalb eines einzigen (visuell angezeigten)
Blockes mit unterschiedlichen Richtungen vorliegen. Dieses Ph@nomen wird auch als Bidirek-
tionalit,t bezeichnet, kurz „bidi“.
< 658 > Visuelles Formatierungsmodell
Page size: 168,00 x 240,00 mm
Der Unicode-Standard ([UNICODE], Abschnitt 3.11) definiert einen komplexen Algorithmus,
mit dem die korrekte Richtung von Text bestimmt wird. Der Algorithmus besteht aus einem
impliziten Teil, der auf Zeicheneigenschaften basiert, und expliziten Steuerelementen f r das
Einbetten und berschreiben. CSS2 verwendet diesen Algorithmus, um eine korrekte bidirek-
tionale Darstellung zu erzielen. Die Eigenschaften 'direction' und 'unicode-bidi' erm=glichen
den Autoren die Angabe, wie Elemente und Attribute einer Dokumentsprache auf diesen Algo-
rithmus abgebildet werden sollen.
Enth@lt ein Dokument Zeichen, die von rechts nach links geschrieben werden, und das Benutzer-
programm zeigt diese Zeichen an (mit geeigneten Glyphen, und nicht beliebigen Ersatzdarstellun-
gen, wie beispielsweise Fragezeichen, Hex-Code, ein schwarzes Quadrat usw.), muss er den
Algorithmus f r die Bidirektionalit@t anwenden. Diese scheinbar einseitige Forderung reflektiert
die Tatsache, dass zwar nicht jedes hebr@ische oder arabische Dokument Text in gemischten
Richtungen enth@lt, diese Dokumente aber eher dazu tendieren, Text zu enthalten, der von links
nach rechts geschrieben wird (z. B. Zahlen oder anderssprachigen Text), als es umgekehrt f r
Dokumente gilt, die in von links nach rechts verlaufenden Sprachen verfasst sind.
Weil die Richtung eines Textes von der Struktur und der Semantik der Dokumentsprache
abh@ngig ist, sollten diese Eigenschaften haupts@chlich von den Entwicklern von DTDs (Doku-
menttypdefinitionen) oder Autoren spezieller Dokumente verwendet werden. Wenn ein Stan-
dard-Stylesheet diese Eigenschaften angibt, sollten Autoren und Benutzer keine Regeln einf h-
ren, die sie berschreiben. Eine typische Ausnahme w@re das berschreiben von bidi-Verhalten
in einem Benutzerprogramm, wenn dieser Jiddisch (normalerweise in hebr@ischen Buchstaben
geschrieben) auf Anforderung des Benutzers hin in lateinische Buchstaben umschreibt.
Die HTML 4.0-Spezifikation ([HTML40], Abschnitt 8.2) definiert bidirektionales Verhalten f r
HTML-Elemente. Konforme HTML-Benutzerprogramme k=nnen deshalb die Eigenschaften 'di-
rection' und 'unicode-bidi' in Autoren- und Benutzer-Stylesheets ignorieren. Die Style-
sheet-Regeln, die das in [HTML40] spezifizierte Verhalten erzielen, sind im Beispiel-Stylesheet
gezeigt (Anhang A). Die HTML 4.0-Spezifikation enth@lt weitere Informationen ber Aspekte
der Bidirektionalit@t.
Cascading Style Sheets, Level 2
'direction'
Wert ltr | rtl | inherit
Ausgangswert: Ltr
Angewendet auf: Alle Elemente, siehe Text
Vererbt: Ja
Prozentwerte: N/A
Medium: Visual
Diese Eigenschaft gibt die grundlegende Schreibrichtung sowie die Richtung von Einbettungen
und berschreibungen (siehe 'unicode-bidi') f r den Unicode-Bidirektionalit@tsalgorithmus an.
Dar ber hinaus gibt er die Richtung von Tabellenspalten, die Richtung von horizontalem ber-
lauf sowie die Positionierung einer unvollst@ndigen letzten Zeile in einem Block mit 'text-align:
justify' an.
Die Eigenschaften 'direction' und 'unicode-bidi' < 659 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Werte f r diese Eigenschaft haben die folgenden Bedeutungen:
ltr
Richtung links nach rechts (left to right)
rtl
Richtung rechts nach links (right to left)
Damit die 'direction'-Eigenschaft Wirkung in Elementen auf Inline-Ebene zeigt, m ssen die
Werte der 'unicode-bidi'-Eigenschaft gleich 'embed' oder 'override' sein.
Hinweis: Die 'direction'-Eigenschaft wird, wenn sie f r Tabellenspaltenelemente angegeben ist,
nicht von Zellen in der Spalte geerbt, weil es im Dokumentbaum keine Spalten gibt. Damit kann
CSS nicht einfach die Attributvererbungsregeln f r „dir“ nachbilden, die in [HTML40] Abschnitt
[Link] beschrieben sind. n
'unicode-bidi'
Wert Normal | embed | bidi-override | inherit
Ausgangswert: Normal
Angewendet auf: Alle Elemente, siehe Text
Vererbt: Nein
Prozentwerte: N/A
Medium: Visual
Werte f r diese Eigenschaft haben die folgenden Bedeutungen:
Cascading Style Sheets, Level 2
normal
Das Element er=ffnet keine zus@tzliche Einbettungsebene f r den Bidirektionalit@tsalgorith-
mus. F r Elemente auf Inline-Ebene funktioniert die implizite Neuanordnung ber Element-
grenzen hinweg.
embed
Befindet sich das Element auf Inline-Ebene, er=ffnet dieser Wert eine zus@tzliche Einbet-
tungsebene f r den Bidirektionalit@tsalgorithmus. Die Richtung dieser Einbettungsebene
wird durch die 'direction'-Eigenschaft vorgegeben. Innerhalb des Elements erfolgt die Neu-
anordnung implizit. Das entspricht dem Hinzuf gen von LRE (U+202A; f r 'direction: ltr')
oder RLE (U+202B; f r 'direction: rtl') am Anfang des Elements und einer PFD (U+202C)
am Ende des Elements.
bidi-override
Handelt es sich um ein Element auf Inline-Ebene oder um ein Element auf Blockebene, das
Elemente auf Inline-Ebene enth@lt, wird ein berschreiben veranlasst. Das bedeutet, dass
innerhalb des Elements die Neuanordnung streng in Folge nach der 'direction'-Eigenschaft
< 660 > Visuelles Formatierungsmodell
Page size: 168,00 x 240,00 mm
erfolgt; der implizite Teil des Bidirektionalit@tsalgorithmus wird dabei ignoriert. Das ent-
spricht einem Hinzuf gen einer LRO (U+202D; f r 'direction: ltr') oder RLO (U+202E; f r
'direction: rtl) am Anfang des Elements und einer PDF (U+202C) am Ende des Elements.
Die endg ltige Reihenfolge der Zeichen in jedem Element auf Blockebene ist dieselbe, als
w@ren
·· die bidi-Steuercodes, wie oben beschrieben, eingef gt,
die Auszeichnungen entfernt und
· als w@re die resultierende Zeichenfolge an eine Implementierung des Unicode- Bidirek-
tionalit@tsalgorithmus f r reinen Text weitergereicht, die dieselben Zeilenumbr che wie
der formatierte Text erzeugt.
In diesem Ablauf werden nicht-textuelle Entities wie etwa Bilder als neutrale Zeichen behan-
delt, es sei denn, ihre 'unicode-bidi'-Eigenschaft hat einen anderen Wert als 'normal'. In diesem
Fall werden sie als Zeichen in der f r das Element angegebenen 'direction' behandelt.
Bitte beachten Sie: Um in der Lage zu sein, inzeilige Boxen in eine einheitliche Richtung fließen
zu lassen (entweder alle links-nach-rechts oder alle rechts-nach-links), m ssen weitere inzeilige
Boxen (einschließlich anonymer inzeiliger Boxen) erzeugt werden, und einige inzeilige Boxen
m ssen geteilt und neu angeordnet werden, bevor der Fluss bestimmt wird.
Da der Unicode-Algorithmus auf maximal 15 Verschachtelungsebenen beschr@nkt ist, sollte
man darauf achten, 'unicode-bidi' mit einem anderen Wert als 'normal' nicht zu verwenden, falls
es nicht notwendig ist. Insbesondere sollte der Wert 'inherit' mit h=chster Vorsicht eingesetzt
werden. F r Elemente, die im Allgemeinen f r die Anzeige als Block bestimmt sind, wird die
Einstellung 'unicode-bidi: embed' bevorzugt, um das Element zusammenzuhalten, falls die Dar-
stellung auf inzeilig ge@ndert wird (siehe Beispiel unten).
Das folgende Beispiel zeigt ein XML-Dokument mit bidirektionalem Text. Es veranschaulicht
ein wichtiges Entwurfsprinzip: DTD-Designer sollten bidi sowohl bei der Sprache (Elemente
und Attribute) als auch bei zugeh=rigen Stylesheets ber cksichtigen. Stylesheets sollten so ent-
worfen sein, dass bidi-Regeln von anderen Formatierungsregeln getrennt sind. Die bidi-Regeln
Cascading Style Sheets, Level 2
sollten nicht von anderen Stylesheets berschrieben werden, so dass das bidi-Verhalten des
Dokuments oder der DTD erhalten bleibt.
Beispiel
In diesem Beispiel stehen kleine Buchstaben f r links-nach-rechts-Zeichen und große
Buchstaben f r rechts-nach-links-Zeichen:
<HEBREW>
<PAR>HEBREW1 HEBREW2 english3 HEBREW4 HEBREW5</PAR>
<PAR>HEBREW6 <EMPH>HEBREW7</EMPH> HEBREW8</PAR>
</HEBREW>
<ENGLISH>
<PAR>english9 english10 english11 HEBREW12 HEBREW13</PAR>
<PAR>english14 english15 english16</PAR>
<PAR>english17 <HE-QUO>HEBREW18 english19 HEBREW20</HE-QUO></PAR>
</ENGLISH>
Da dies XML ist, ist das Stylesheet f r die Einstellung der Schreibrichtung verantwortlich. Hier
ist das Stylesheet:
Die Eigenschaften 'direction' und 'unicode-bidi' < 661 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
/* Rules for bidi */
HEBREW, HE-QUO {direction: rtl; unicode-bidi: embed}
ENGLISH {direction: ltr; unicode-bidi: embed}
/* Rules for presentation */
HEBREW, ENGLISH, PAR {display: block}
EMPH {font-weight: bold}
Das HEBREW-Element ist ein Block mit einer Grundrichtung von rechts nach links. Das ENG-
LISH-Element ist ein Block mit einer Grundrichtung von links nach rechts. Die PARs sind Bl=-
cke, die ihre Grundrichtung von ihren Eltern erben. Folglich werden die beiden ersten PARs
von oben rechts beginnend gelesen, die letzten drei werden von oben links beginnend gelesen.
Beachten Sie, dass die Namen HEBREW und ENGLISH f r die Elemente nur zur Veranschauli-
chung gew@hlt wurden. Im Allgemeinen sollten Elementnamen die Struktur widerspiegeln und
keinen Bezug zur Sprache enthalten.
Das EMPH-Element ist ein inzeiliges Element und, da der Wert f r 'unicode-bidi' 'normal' (Aus-
gangswert) ist, hat es keine Auswirkung auf die Anordnung des Textes. Andererseits erzeugt
das HE-QUO-Element eine Einbettung.
Die Formatierung dieses Texte kann wie folgt aussehen, falls die Zeilenl@nge zu lang ist:
5WERBEH 4WERBEH english3 2WERBEH 1WERBEH
8WERBEH 7WERBEH 6WERBEH
english9 english10 english11 13WERBEH 12WERBEH
english14 english15 english16
english17 20WERBEH english19 18WERBEH
Beachten Sie, dass die HE-QUO-Einbettung daf r sorgt, dass HEBREW18 rechts von english19
steht.
Falls Zeilen umgebrochen werden m ssen, kann es etwa wie folgt aussehen:
2WERBEH 1WERBEH
-EH 4WERBEH english3
Cascading Style Sheets, Level 2
5WERB
-EH 7WERBEH 6WERBEH
8WERB
english9 english10 en-
glish11 12WERBEH
13WERBEH
english14 english15
english16
english17 18WERBEH
20WERBEH english19
Da HEBREW18 vor english19 gelesen werden muss, steht es in der Zeil ber english19. Nur
der Umbruch der langen Zeile der fr heren Formatierung h@tte nicht funktioniert.
Beachten Sie auch, dass die erste Silbe von english19 in die n@chste Zeile h@tte passen k=nnen,
aber die Trennung von links-nach-rechts-W=rtern in einem rechts-nach-links-Kontext (und
umgekehrt) wird normalerweise unterdr ckt, um die Darstellung eines Trennstrichs in der
Mitte der Zeile zu vermeiden.
< 662 > Visuelles Formatierungsmodell
Page size: 168,00 x 240,00 mm
10 Details zum visuellen
Formatierungsmodell
10.1 Definition des „umschließenden Blocks“
Die Position und die Gr=ße der Boxen eines Elements werden manchmal relativ zu einem
bestimmten Rechteck berechnet, dem umschließenden Block („containing block“) des Elements.
Der umschließende Block eines Elements ist wie folgt definiert:
1. Der umschließende Block (auch als umschließender Ausgangsblock bezeichnet), in dem sich
das Wurzelelement befindet, wird vom Benutzerprogramm ausgew@hlt.
2. F r andere Elemente wird der umschließende Block durch die Inhaltskante der n@chsten
benachbarten Box auf Blockebene gebildet, es sei denn, das Element ist absolut positio-
niert.
3. Ist f r das Element 'position: fixed' gesetzt, wird der umschließende Block durch den
Viewport eingerichtet.
4. Ist f r das Element 'position: absolute' gesetzt, wird der umschließende Block durch den
n@chsten Vorfahren mit einer anderen 'position' als 'static' eingerichtet, und zwar wie folgt:
· Falls es einen Vorfahren auf Blockebene gibt, wird der umschließende Block durch die
Polsterungskante (padding) des Vorfahren gebildet.
· Falls der Vorfahre auf Inline-Ebene liegt, ist der umschließende Block von der 'directi-
on'-Eigenschaft des Vorfahren abh@ngig.
· Falls die 'direction' gleich 'ltr' ist, sind die obere und linke Kante des umschließenden
Blocks gleich der oberen und linken Inhaltskante der ersten durch den Vorfahren
erzeugten Box, und die untere und die rechte Kante sind die untere und rechte
Inhaltskante der letzten Box des Vorfahren.
· Falls 'direction' gleich 'rtl' ist, sind die obere und rechte Kante gleich der oberen und
rechten Kante der ersten von dem Vorfahren erzeugten Box, und die untere und
Cascading Style Sheets, Level 2
linke Kante sind die untere und linke Inhaltskante der letzten Box des Vorfahren.
Falls es keinen solchen Vorfahren gibt, richtet die Inhaltskante der Box des Wurzelele-
ments den umschließenden Block ein.
Beispiel
Ohne Positionierung werden die umschließenden Bl=cke im folgenden Dokument wie
nachfolgend eingerichtet.
<HTML>
<HEAD>
<TITLE>Demonstration umschließender Bl^cke</TITLE>
</HEAD>
<BODY id="body">
<DIV id="div1">
<P id="p1">Dieser Text befindet sich im ersten Absatz...</P>
<P id="p2">Dies ist Text <EM id="em1"> im
<STRONG id="strong1">zweiten</STRONG> Absatz.</EM></P>
</DIV>
</BODY>
</HTML>
Details zum visuellen Formatierungsmodell < 663 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
F-r eine Box, wird der umschließende Block
die erzeugt wurde von eingerichtet von
body umschließender Ausgangsblock
(vom Benutzerprogramm abh@ngig)
div1 body
p1 div1
p2 div1
em1 P2
strong1 P2
Wenn wir „div1“ positionieren:
#div1 { position: absolute; left: 50px; top: 50px }
ist sein umschließender Block nicht mehr „body“; er wird zum anf@nglichen umschließenden
Block (weil es keine anderen positionierten Vorfahren-Boxen gibt).
Wenn wir „em1“ ebenfalls positionieren:
#div1 { position: absolute; left: 50px; top: 50px }
#em1 { position: absolute; left: 100px; top: 100px }
sieht die Tabelle der umschließenden Bl=cke wie folgt aus:
F-r eine Box, wird der umschließende Block
die erzeugt wurde von eingerichtet von
body umschließender Ausgangsblock
Cascading Style Sheets, Level 2
div1 umschließender Ausgangsblock
p1 div1
p2 div1
em1 div1
strong1 em1
Durch die Positionierung von „em1“ wird sein umschließender Block die am n@chsten posi-
tionierte Vorfahren-Box (also jene, die durch „div1“ erzeugt wurde).
< 664 > Details zum visuellen Formatierungsmodell
Page size: 168,00 x 240,00 mm
10.2 Inhaltsbreite: die 'width'-Eigenschaft
'width'
Wert: <length> | <percentage> | auto | inherit
Ausgangswert: Auto
Angewendet auf: Alle Elemente, außer auf nicht-ersetzte Inline-Elemente,
Tabellenzeilen und Zeilengruppen
Vererbt: Nein
Prozentwerte: Beziehen sich auf die Breite des umschließenden Blocks
Medium: Visual
Diese Eigenschaft gibt die Inhaltsbreite von Boxen an, die auf Blockebene erzeugt wurden,
sowie die Inhaltsbreite von ersetzten Elementen.
Diese Eigenschaft gilt nicht f r nicht ersetzte Elemente auf Inline-Ebene. Die Breite der Boxen
f r ein nicht ersetztes inzeiliges Element ist die des in ihnen dargestellten Inhalts (vor jedem
relativen Offset von untergeordneten Elementen). Beachten Sie, dass Inline-Boxen in Zeilen-
Boxen einfließen. Die Breite von Zeilen-Boxen wird durch ihren umschließenden Block vor-
gegeben, ist aber bei Vorhandensein von Floats m=glicherweise gek rzt.
Ein ersetztes Element hat eine eigene Box-Breite, die vom Benutzerprogramm skaliert werden
kann, wenn diese Eigenschaft einen anderen Wert als 'auto' hat.
Die Werte haben die folgenden Bedeutungen:
<length>
Gibt eine feste Breite an.
<percentage>
Cascading Style Sheets, Level 2
Gibt eine prozentuale Breite an. Der Prozentwert wird relativ zur Breite des umschließen-
den Blocks der erzeugten Box berechnet.
auto
Die Breite ist von den Werten anderer Eigenschaften abh@ngig. Weitere Informationen fin-
den Sie in den nachfolgenden Abschnitten.
Negative Werte f r 'width' sind nicht erlaubt.
Beispiel
Die folgende Regel beispielsweise legt die Inhaltsbreite von Abs@tzen mit 100 Pixel fest:
P { width: 100px }
Inhaltsbreite: die 'width'-Eigenschaft < 665 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
10.3 Breiten und [Link] berechnen
Die berechneten Werte der Eigenschaften 'width', 'margin-left', 'margin-right', 'left' und 'right'
eines Elements sind vom Typ der erzeugten Box und voneinander abh@ngig. Im Prinzip sind die
berechneten Werte dieselben wie die angegebenen Werte, wenn 'auto' durch einen geeigneten
Wert ersetzt wird, aber es gibt Ausnahmen. Die folgenden Situationen m ssen unterschieden
werden:
1. Inline, nicht-ersetzte Elemente
2. Inline, ersetzte Elemente
3. Blockebene, nicht-ersetzte Elemente im normalen Fluss
4. Blockebene, ersetzte Elemente im normalen Fluss
5. Floating, nicht-ersetzte Elemente
6. Floating, ersetzte Elemente
7. Absolut positioniert, nicht-ersetzte Elemente
8. Absolut positioniert, ersetzte Elemente
Die Punkte 1-6 beinhalten eine relative Positionierung.
10.3.1 Inline, nicht-ersetzte Elemente
Die 'width'-Eigenschaft wird nicht angewendet. Wird f r 'left', 'right', 'margin-left' oder 'margin-
right' der Wert 'auto' angegeben, wird daraus ein berechneter Wert von '0'.
10.3.2 Inline, ersetzte Elemente
Wird f r 'left', 'right', 'margin-left' oder 'margin-right' der Wert 'auto' angegeben, wird daraus
der berechnete Wert '0'. Wird f r 'width' der Wert 'auto' angegeben, wird die eigene Breite
des Elements als berechneter Wert angenommen.
Cascading Style Sheets, Level 2
10.3.3 Blockebene, nicht-ersetzte Elemente im normalen Fluss
Werden 'left' oder 'right' als 'auto' angegeben, ist ihr berechneter Wert gleich 0. Zwischen den
anderen Eigenschaften m ssen die folgenden Bedingungen gelten:
'margin-left' + 'border-left-width' + 'padding-left' + 'width' + 'padding-right' + 'border-right-
width' + 'margin-right' = Breite des umschließenden Blocks
(Ist der Rahmenstil gleich 'none', verwenden Sie '0' als Rahmenbreite.) Ist f r alle oben auf-
gef hrten Werte ein anderer Wert als 'auto' angegeben, sagt man, die Werte sind „ berspezifi-
ziert“ und einer der berechneten Werte muss sich von dem angegebenen Wert unterscheiden.
Hat die 'direction'-Eigenschaft den Wert 'ltr', wird der angegebene Wert von 'margin-right'
ignoriert, und der Wert wird berechnet, so dass die Gleichung stimmt. Ist der Wert von
'direction' gleich 'ltr', findet dies stattdessen auf 'margin-left' Anwendung.
Ist genau ein Wert als 'auto' angegeben, folgt sein berechneter Wert aus der Gleichung.
Ist 'width' auf 'auto' gesetzt, werden alle anderen 'auto'-Werte zu '0', und 'width' folgt aus der
resultierenden Gleichung.
Sind sowohl 'margin-left' als auch 'margin-right' gleich 'auto', dann sind ihre berechneten Werte
gleich.
< 666 > Details zum visuellen Formatierungsmodell
Page size: 168,00 x 240,00 mm
10.3.4 Blockebene, ersetzte Elemente im normalen Fluss
Sind 'left' oder 'right' gleich 'auto', ist ihr berechneter Wert gleich 0. Ist 'width' als 'auto' angege-
ben, ist sein Wert die eigene Breite des Elements. Ist einer der R@nder als 'auto' angegeben,
wird sein berechneter Wert durch die obigen Bedingungen festgelegt. Sind dar ber hinaus
beide R@nder gleich 'auto', sind ihre berechneten Werte gleich.
10.3.5 Floating, nicht-ersetzte Elemente
Sind 'left', 'right', 'width', 'margin-left' oder 'margin-right' als 'auto' angegeben, ist ihr berech-
neter Wert gleich '0'.
10.3.6 Floating, ersetzte Elemente
Sind 'left', 'right', 'width', 'margin-left' oder 'margin-right' als 'auto' angegeben, ist ihr berech-
neter Wert gleich '0'. Ist 'width' gleich 'auto', ist sein Wert die eigene Breite des Elements.
10.3.7 Absolute Positionierung, nicht-ersetzte Elemente
Die Bedingung, die die Berechnung f r diese Elemente festlegt, ist die folgende:
'left' + 'margin-left' + 'border-left-width' + 'padding-left' + 'width' + 'padding-right' + 'border-
right-width' + 'margin-right' + 'right' = Breite des umschließenden Blocks
(Ist der Rahmenstil gleich 'none', verwenden Sie '0' als Rahmenbreite.) Die L=sung f r diese
Bedingung wird gefunden, indem einige Ersetzungen in der folgenden Reihenfolge vorgenom-
men werden:
1. Wenn 'left' den Wert 'auto' hat, w@hrend 'direction' gleich 'ltr' ist, ersetzen Sie 'auto' durch
den Abstand von der linken Kante des umschließenden Blocks zur linken Randkante einer
hypothetischen Box, die die erste Box des Elements w@re, wenn dessen 'position'-Eigen-
schaft gleich 'static' w@re. (Statt jedoch diese Box tats@chlich zu berechnen, steht es den
Cascading Style Sheets, Level 2
Benutzerprogrammen frei, eine Sch@tzung der wahrscheinlichen Position vorzunehmen.)
Der Wert ist negativ, wenn sich die hypothetische Box links vom umschließenden Block
befindet.
2. Wenn 'right' den Wert 'auto' hat und 'direction' gleich 'rtl' ist, ersetzen Sie 'auto' durch den
Abstand von der rechten Kante des umschließenden Blocks zur rechten Randkante dersel-
ben hypothetischen Box wie oben. Der Wert ist positiv, wenn sich die hypothetische Box
links von der Kante des umschließenden Blocks befindet.
3. Ist 'width' gleich 'auto', ersetzen Sie jedes weitere 'auto' f r 'left' oder 'right' durch '0'.
4. Sind 'left', 'right' oder 'width' (immer noch) 'auto', ersetzen Sie jedes 'auto' f r 'margin-left'
oder 'margin-right' durch '0'.
5. Sind jetzt 'margin-left' und 'margin-right' immer noch 'auto', l=sen Sie die Gleichung unter
der zus@tzlichen Bedingung, dass die beiden R@nder denselben Wert erhalten m ssen.
6. Ist an dieser Stelle nur noch ein 'auto' brig, l=sen Sie die Gleichung f r diesen Wert auf.
7. Sind die Werte an dieser Stelle berspezifiziert, ignorieren Sie den Wert f r 'left' (falls
'direction' gleich 'rtl') oder 'right' (falls 'direction' gleich 'ltr' ist) und l=sen f r diesen Wert
auf.
Breiten und R,nder berechnen < 667 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
10.3.8 Absolute Positionierung, ersetzte Elemente
Diese Situation ist vergleichbar der vorherigen, außer dass das Element eine eigene Breite hat.
Die Abfolge der Ersetzungen ist jetzt:
1. Ist 'width' gleich 'auto', ersetzen Sie die eigene Breite des Elements.
2. Wenn 'left' den Wert 'auto' hat, w@hrend 'direction' gleich 'ltr' ist, ersetzen Sie 'auto' durch
den Abstand von der linken Kante des umschließenden Blocks zur linken Randkante einer
hypothetischen Box, die die erste Box des Elements w@re, wenn dessen 'position'-Eigen-
schaft gleich 'static' w@re. (Statt jedoch diese Box tats@chlich zu berechnen, steht es den
Benutzerprogrammen frei, eine Sch@tzung an der wahrscheinlichen Position vorzunehmen.)
Der Wert ist negativ, wenn sich die hypothetische Box links vom umschließenden Block
befindet.
3. Wenn 'rigth' den Wert 'auto' hat und 'direction' gleich 'rtl' ist, ersetzen Sie 'auto' durch den
Abstand von der rechten Kante des umschließenden Blocks zur rechten Randkante dersel-
ben hypothetischen Box wie oben. Der Wert ist positiv, wenn sich die hypothetische Box
links von der Kante des umschließenden Blocks befindet.
4. Sind 'left' oder 'right' gleich 'auto' , ersetzen Sie jedes 'auto' f r 'margin-left' oder 'margin-
right' durch '0'.
5. Sind an dieser Stelle sowohl 'margin-left' als auch 'margin-right' immer noch 'auto', l=sen Sie
die Gleichung unter der zus@tzlichen Bedingung, dass die beiden R@nder denselben Wert
erhalten m ssen.
6. Ist an dieser Stelle nur noch ein 'auto' brig, l=schen Sie die Gleichung f r diesen Wert.
7. Sie die Werte an dieser Stelle berspezifiziert, ignorieren Sie den Wert f r 'left' (falls
'direction' gleich 'rtl' ist) oder 'right' (falls 'direction' gleich 'ltr' ist) und l=sen f r diesen
Wert.
10.4 Minimale und maximale Breiten: 'min-width' und
'max-width'
Cascading Style Sheets, Level 2
'min-width'
Wert: <length> | <percentage> | inherit
Ausgangswert: Vom Benutzerprogramm abh@ngig
Angewendet auf: Alle Elemente, außer auf nicht-ersetzte Inline-Elemente und
Tabellenelemente
Vererbt: Nein
Prozentwerte: Beziehen sich auf die Breite des umschließenden Blocks
Medium: Visual
< 668 > Details zum visuellen Formatierungsmodell
Page size: 168,00 x 240,00 mm
'max-width'
Wert: <length> | <percentage> | none | inherit
Ausgangswert: Vom Benutzerprogramm abh@ngig
Angewendet auf: Alle Elemente, außer auf nicht-ersetzte Inline-Elemente und
Tabellenelemente
Vererbt: Nein
Prozentwerte: Beziehen sich auf die Breite des umschließenden Blocks
Medium: Visual
Diese beiden Eigenschaften erlauben es Autoren, Box-Breiten auf einen bestimmten Bereich
einzugrenzen. Die Werte haben die folgenden Bedeutungen:
<length>
Gibt eine feste minimale oder maximale berechnete Breite an.
<percentage>
Gibt einen Prozentwert f r die Ermittlung des berechneten Werts an. Der Prozentwert
wird relativ zur Breite des umschließenden Blocks der erzeugten Box berechnet.
none
(Nur f r 'max-width') Es gibt keine Beschr@nkung f r die Breite der Box.
Der folgende Algorithmus beschreibt, wie die beiden Eigenschaften den berechneten Wert der
'width'-Eigenschaft beeinflussen:
1. Die Breite wird nach den unter „Berechnung von Breiten und R@ndern“ beschriebenen
Regeln berechnet (ohne 'min-width' und 'max-width').
2. Ist der berechnete Wert von 'min-width' gr=ßer als der Wert von 'max-width', wird 'max-
Cascading Style Sheets, Level 2
width' auf den Wert von 'min-width' gesetzt.
3. Ist die berechnete Breite gr=ßer als 'max-width', werden die obigen Regeln erneut ange-
wendet, aber jetzt wird der Wert von 'max-width' als der f r 'width' angegebene Wert ver-
wendet.
4. Ist der berechnete Wert kleiner als 'min-width', werden die obigen Regeln erneut angewen-
det, aber jetzt wird der Wert von 'min-width' als der f r 'width' angegebene Wert verwen-
[Link] Benutzerprogramm kann einen nicht negativen Mindestwert f r die 'min-width'-Ei-
genschaft angeben, der von Element zu Element variieren und sogar von anderen Eigen-
schaften abh@ngig sein kann. Geht 'min-width' unter diesen Grenzwert, entweder, weil es
explizit gesetzt wurde, oder weil es 'auto' war und die nachfolgenden Regeln es zu klein
gemacht h@tten, kann das Benutzerprogramm den Mindestwert als den berechneten Wert
verwenden.
Minimale und maximale Breiten < 669 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
10.5 InhaltshUhe : die 'height'-Eigenschaft
'height'
Wert: <length> | <percentage> | auto | inherit
Ausgangswert: Auto
Angewendet auf: Alle Elemente, außer auf nicht-ersetzte Inline-Elemente,
Tabellenspalten und Spaltengruppen
Vererbt: Nein
Prozentwerte: Siehe Text
Medium: Visual
Diese Eigenschaft gibt die Inhaltsh=he von Boxen an, die auf Blockebene erzeugt wurden, sowie
von ersetzten [Link] Eigenschaft bezieht sich nicht auf nicht ersetzte inzeilige Ele-
mente. Die H=he der Boxen eines nicht-ersetzten Inline-Elements wird durch den (m=glicher-
weise geerbten) 'line-height'-Wert des Elements [Link] Werte haben die folgenden
Bedeutungen:
<length>
Gibt eine feste H=he an.
<percentage>
Gibt eine prozentuale H=he an. Der Prozentwert wird relativ zur H=he des umschließen-
den Blocks der erzeugten Box berechnet. Wird die H=he des umschließenden Blocks nicht
explizit angegeben (das heißt, ist sie demnach von der Inhaltsh=he abh@ngig), wird der Wert
als 'auto' interpretiert.
auto
Cascading Style Sheets, Level 2
Die H=he ist von den Werten anderer Eigenschaften abh@ngig. Weitere Informationen fin-
den Sie im nachfolgenden Text.
Negative Werte f r 'height' sind nicht erlaubt.
Beispiel
Die folgende Regel beispielsweise legt die H=he von Abs@tzen auf 100 Pixel fest:
P { height: 100px }
Abs@tze, f r die eine H=he von mehr als 100 Pixel erforderlich ist, erzeugen gem@ß der 'over-
flow'-Eigenschaft einen berlauf.
< 670 > Details zum visuellen Formatierungsmodell
Page size: 168,00 x 240,00 mm
10.6 HUhen und [Link] berechnen
Zur Berechnung der Werte f r 'top', 'margin-top', 'height', 'margin-bottom' und 'bottom' muss
zwischen den verschiedenen Box-Typen unterschieden werden:
1. Inline, nicht-ersetzte Elemente
2. Inline, ersetzte Elemente
3. Blockebene, nicht-ersetzte Elemente im normalen Fluss
4. Blockebene, ersetzte Elemente im normalen Fluss
5. Floating, nicht-ersetzte Elemente
6. Floating, ersetzte Elemente
7. Absolut positioniert, nicht-ersetzte Elemente
8. Absolut positioniert, ersetzte Elemente
Die Punkte 1-6 beinhalten eine relative Positionierung.
10.6.1 Inline, nicht-ersetzte Elemente
Wird f r 'top', 'bottom', 'margin-top' oder 'margin-bottom' der Wert 'auto' angegeben, wird
daraus ein berechneter Wert von '0'. Die 'height'-Eigenschaft wird nicht angewendet, aber die
H=he der Box wird durch die 'line-height'-Eigenschaft angegeben.
10.6.2 Inline, ersetzte Elemente, Blockebene, ersetzte Elemente im
normalen Fluss, und Floating, ersetzte Elemente
Wird f r 'top', 'bottom', 'margin-top' oder 'margin-bottom' der Wert 'auto' angegeben, wird
daraus der berechnete Wert '0'. Ist 'height' gleich 'auto', ist der berechnete Wert die eigene
H=he.
10.6.3 Blockebene, nicht ersetzte Elemente im normalen Fluss, und
Cascading Style Sheets, Level 2
Floating, nicht ersetzte Elemente
Sind 'top', 'bottom', 'margin-top' oder 'margin-bottom' gleich 'auto', ist ihr berechneter Wert 0.
Ist 'height' gleich 'auto', ist die H=he davon abh@ngig, ob das Element untergeordnete Elemente
auf Blockebene hat. Wenn es nur untergeordnete inzeilige Elemente hat, reicht die H=he von
der obersten Kante der obersten Zeilen-Box bis zur untersten Kante der untersten Zeilen-
Box. Hat es untergeordnete Elemente auf Blockebene, ist sie der Abstand zwischen der obers-
ten Rahmenkante der Box des obersten untergeordneten Elements auf Blockebene bis zur
untersten Rahmenkante der Box des untersten untergeordneten Elements auf Blockebene.
Nur untergeordnete Elemente im normalen Fluss werden ber cksichtigt (das heißt, Floating-
Boxen und absolut positionierte Boxen werden ignoriert, und relativ positionierte Boxen wer-
den ohne ihren Offset betrachtet.) Beachten Sie, dass die Box des untergeordneten Elements
eine anonyme Box sein kann.
HFhen und R,nder berechnen < 671 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
10.6.4 Absolute Positionierung, nicht-ersetzte Elemente
F r absolut positionierte Elemente m ssen die vertikalen Ausmaße die folgende Bedingung
erf llen:
'top' + 'margin-top'+ 'border-top-width' + 'padding-top' + 'height' + 'padding-bottom' + 'bor-
der-bottom-width' + 'margin-bottom' + 'bottom' = H=he des umschließenden Blocks
(Ist der Rahmenstil gleich 'none', verwenden Sie '0' als Rahmenbreite.) Die L=sung f r diese
Bedingung wird durch mehrere Ersetzungen in der folgenden Reihenfolge erzielt:
1. Hat 'top' den Wert 'auto', ersetzen Sie es durch den Abstand von der oberen Kante des
umschließenden Blocks zur oberen Randkante einer hypothetischen Box, die die erste Box
des Elements w@re, wenn seine 'position'-Eigenschaft 'static' w@re. (Statt jedoch diese Box
zu berechnen, k=nnen die Benutzerprogramme ihre wahrscheinliche Position auch sch@t-
zen.) Der Wert ist negativ, wenn sich die hypothetische Box oberhalb des umschließenden
Blocks befindet.
2. Sind sowohl 'height' als auch 'bottom' gleich 'auto', ersetzen Sie 'bottom' durch '0'.
3. Sind 'bottom' oder 'height' (immer noch) 'auto', ersetzen Sie jedes 'auto' f r 'margin-top'
oder 'margin-bottom' durch '0'.
4. Sind an dieser Stelle 'margin-top' und 'margin-bottom' immer noch 'auto', l=sen Sie die Glei-
chung unter der zus@tzlichen Bedingung, dass die beiden R@nder gleiche Werte erhalten
m ssen.
5. Ist an dieser Stelle nur noch ein 'auto' brig, l=sen Sie die Gleichung f r diesen Wert.
6. Sind an dieser Stelle die Werte berspezifiziert, ignorieren Sie den Wert f r 'bottom' und
l=sen Sie die Gleichung f r diesen Wert.
10.6.5 Absolute Positionierung, ersetzte Elemente
Diese Situation ist vergleichbar der vorherigen, außer dass das Element eine eigene H=he hat.
Die Abfolge der Ersetzungen sieht jetzt wie folgt aus:
1. Wenn 'height' gleich 'auto' ist, setzen Sie statt dessen die eigene H=he des Elements ein.
Cascading Style Sheets, Level 2
2. Hat 'top' den Wert 'auto', ersetzen Sie es durch den Abstand von der oberen Kante des
umschließenden Blocks zur oberen Randkante einer hypothetischen Box, die die erste Box
des Elements w@re, wenn seine 'position'-Eigenschaft 'static' w@re. (Statt jedoch diese Box
zu berechnen, k=nnen die Benutzerprogramme ihre wahrscheinliche Position auch sch@t-
zen.) Der Wert ist negativ, wenn sich die hypothetische Box oberhalb des umschließenden
Blocks befindet.
3. Ist 'bottom' gleich 'auto', ersetzen Sie jedes 'auto' f r 'margin-top' oder 'margin-bottom'
durch '0'.
4. Sind an dieser Stelle 'margin-top' und 'margin-bottom' immer noch 'auto', l=sen Sie die Glei-
chung unter der zus@tzlichen Bedingung, dass die beiden R@nder gleiche Werte erhalten
m ssen.
5. Ist an dieser Stelle nur noch ein 'auto' brig, l=sen Sie die Gleichung f r diesen Wert.
6. Sind an dieser Stelle die Werte berspezifiziert, ignorieren Sie den Wert f r 'bottom' und
l=sen Sie die Gleichung f r diesen Wert.
< 672 > Details zum visuellen Formatierungsmodell
Page size: 168,00 x 240,00 mm
10.7 Mindest- und MaximalhUhen: 'min-height' und
'max-height'
Manchmal ist es sinnvoll, die H=he von Elementen auf einen bestimmten Bereich zu begrenzen.
Zwei Eigenschaften realisieren diese Funktionalit@t:
'min-height'
Wert: <length> | <percentage> | inherit
Ausgangswert: 0
Angewendet auf: Alle Elemente, außer auf nicht-ersetzte Inline-Elemente und
Tabellenelemente
Vererbt: Nein
Prozentwerte: Beziehen sich auf die H=he des umschließenden Blocks
Medium: Visual
'max-height'
Wert: <length> | <percentage> | none | inherit
Ausgangswert: none
Angewendet auf: Alle Elemente, außer auf nicht-ersetzte Inline-Elemente und
Tabellenelemente
Vererbt: Nein
Prozentwerte: Beziehen sich auf die H=he des umschließenden Blocks
Cascading Style Sheets, Level 2
Medium: Visual
Diese beiden Eigenschaften gestatten es Autoren, Box-H=hen auf einen bestimmten Bereich zu
begrenzen. Werte haben die folgenden Bedeutungen:
<length>
Gibt eine minimale oder maximale berechnete H=he an.
<percentage>
Gibt einen Prozentwert f r die Ermittlung des berechneten Werts an. Der Prozentwert
wird relativ zur H=he des umschließenden Blocks der erzeugten Box berechnet. Ist die
H=he des umschließenden Blocks nicht explizit angegeben (das heißt, sie ist von der Inhalt-
sh=he abh@ngig), wird der Prozentwert als 'auto' interpretiert.
none
(Nur f r 'max-height'). Es gibt keine Begrenzung f r die H=he der Box.
Mindest- und MaximalhFhen < 673 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Der folgende Algorithmus beschreibt, wie diese beiden Eigenschaften den berechneten Wert
der 'height'-Eigenschaft beeinflussen:
1. Die H=he wird gem@ß den Regeln aus dem obigen Abschnitt 10.6, „H=hen und R@nder
berechnen“, berechnet (ohne 'min-height' und 'max-height').
2. Ist der berechnete Wert von 'min-height' gr=ßer als der Wert von 'max-height', wird 'max-
height' auf den Wert von 'min-height' gesetzt.
3. Ist die berechnete H=he gr=ßer als 'max-height', werden die obigen Regeln erneut ange-
wendet, aber jetzt unter Verwendung des Wertes von 'max-height' als vorgegebenen Wert
f r 'height'.
4. Ist der berechnete Wert kleiner als 'min-height', werden die obigen Regeln erneut ange-
wendet, aber jetzt unter Verwendung des Werts von 'min-height' vorgegebenen Wert f r
'height'.
10.8 ZeilenhUhenberechnungen: die Eigenschaften
'line-height' und 'vertical-align'
Wie im Abschnitt ber Inline-Formatierungskontexte (9.4.2) beschrieben, f hren Benutzerpro-
gramme Inline-Boxen zu einem vertikalen Stapel aus Zeilen-Boxen zusammen. Die H=he einer
Zeilen-Box wird wie folgt ermittelt:
1. Die H=he jeder Inline-Box in der Zeilen-Box wird berechnet (siehe Abschnitt 10.6, „H=hen
und R@nder berechnen“, und die Beschreibung der 'line-height'-Eigenschaft).
2. Die Inline-Boxen werden vertikal gem@ß ihrer 'vertical-align'-Eigenschaft ausgerichtet.
3. Die H=he der Zeilen-Box ist der Abstand zwischen der oberen Kante der obersten Box
und der unteren Kante der untersten Box.
Leere inzeilige Elemente erzeugen leere Inline-Boxen, aber diese Boxen haben dennoch R@n-
der, Auff llung, Rahmen und eine Zeilenh=he und beeinflussen damit diese Berechnungen
genauso wie Elemente mit Inhalt.
Cascading Style Sheets, Level 2
Beachten Sie, dass die Zeilen-Box genau die H=he der h=chsten Box hat, wenn alle Boxen in
der Zeilen-Box ihrer unteren Kante nach ausgerichtet sind. Sind die Boxen dagegen entlang
einer gemeinsamen Grundlinie ausgerichtet, kann es sein, dass die obere und untere Kante der
Zeilen-Box die untere und obere Kante der h=chsten Box nicht ber hren.
10.8.1 Durchschuss und Halb-Durchschuss
Weil sich die H=he einer inzeiligen Box von der Schriftgr=ße des Texts in der Box unterschei-
den kann (z. B. 'line-height' > 1em), kann es Platz oberhalb und unterhalb der dargestellten Gly-
phen geben. Die Differenz zwischen der Schriftgr=ße und dem berechneten Wert von 'line-
height' wird auch als Durchschuss bezeichnet. Die H@lfte des Durchschusses wird als Halb-
Durchschuss bezeichnet.
Benutzerprogramme zentrieren Glyphen vertikal in einer Inline-Box und f gen einen Halb-
Durchschuss oben und unten ein. Ist ein Textst ck beispielsweise '12pt' hoch und der 'line-
height' ist '14pt', sollten 2pt zus@tzlicher Platz hinzugef gt werden: 1pt oberhalb und 1 pt unter-
halb der Buchstaben. (Das gilt auch f r leere Boxen, so als ob die leere Box einen unendlich
schmalen Buchstaben enthalten w rde.)
< 674 > Details zum visuellen Formatierungsmodell
Page size: 168,00 x 240,00 mm
Ist der Wert von 'line-height' kleiner als die Schriftgr=ße, ist die H=he der endg ltigen Inline-
Box kleiner als die Schriftgr=ße und die dargestellten Glypen „laufen aus der Box heraus“.
Ber hrt eine solche Box die Kante einer Zeilen-Box, fließen die dargestellten Glyphen auch in
die benachbarte Zeilen-Box ein.
Obwohl R@nder, Rahmen und Auff llung nicht-ersetzter Elemente f r die H=henberechnung
der Inline-Box (und damit die Berechnung der Zeilen-Box) nicht ber cksichtigt werden, wer-
den sie dennoch um die Inline-Boxen herum dargestellt. Das bedeutet, wenn die H=he einer
Zeilen-Box kleiner als die @ußeren Kanten der darin enthaltenen Boxen sind, k=nnen Hinter-
gr nde und Farben von Auff llung und Rahmen in benachbarte Zeilen-Boxen „einfließen“. In
diesem Fall k=nnen die Benutzerprogramme die Zeilen-Box jedoch nutzen, um die Rahmen-
und Auff llbereiche „abzuschneiden“ (das heißt, sie nicht darzustellen).
'line-height'
Wert: normal | <number> | <length> | <percentage> | inherit
Ausgangswert: Normal
Angewendet auf: Alle Elemente
Vererbt: Ja
Prozentwerte: Beziehen sich auf die Schriftgr=ße des eigentlichen Elements
Medium: Visual
Ist die Eigenschaft f r ein Element auf Blockebene gesetzt, dessen Inhalt sich aus Elementen auf
Inline-Ebene zusammensetzt, gibt sie die minimale H=he jeder erzeugten Inline-Box an.
Ist die Eigenschaft f r ein Element auf Inline-Ebene gesetzt, gibt sie die genaue H=he jeder Box
an, die von dem Element erzeugt wird. (Außer f r ersetzte Inline-Elemente, bei denen die H=he
der Box durch die 'height'-Eigenschaft angegeben wird.)
Cascading Style Sheets, Level 2
Die Werte f r diese Eigenschaft haben die folgenden Bedeutungen:
normal
Weist Benutzerprogramme an, den berechneten Wert auf einen „sinnvollen“ Wert abh@n-
gig von der Schriftgr=ße des Elements zu setzen. Der Wert hat dieselbe Bedeutung wie
<number>. Wir empfehlen einen berechneten Wert zwischen 1.0 und 1.2 f r 'normal'.
<length>
Die Box-H=he wird auf diese L@nge gesetzt. Negative Werte sind nicht erlaubt.
<number>
Der berechnete Wert der Eigenschaft ist diese Zahl multipliziert mit der Schriftgr=ße des
Elements. Negative Werte sind nicht erlaubt. Die Zahl, nicht der berechnete Wert, wird
vererbt.
<percentage>
Der berechnete Wert der Eigenschaft ist dieser Prozentwert multipliziert mit der berech-
neten Schriftgr=ße des Elements. Negative Werte sind nicht erlaubt.
ZeilenhFhenberechnungen < 675 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Beispiel
Die drei Regeln im folgenden Beispiel erzeugen dieselbe Zeilenh=he:
DIV { line-height: 1.2; font-size: 10pt } /* Zahl */
DIV { line-height: 1.2em; font-size: 10pt } /* L]nge */
DIV { line-height: 120%; font-size: 10pt } /* Prozentwert */
Enth@lt ein Element Text, der in mehreren Schriften dargestellt wird, sollten die Benutzerpro-
gramme den 'line-height'-Wert anhand der gr=ßten Schriftgr=ße ermitteln.
Allgemein gilt, wenn es nur einen Wert von 'line-height' f r alle Inline-Boxen in einem Absatz
(und keine hohen Bilder) gibt, stellt die obige Aussage sicher, dass Grundlinien aufeinander fol-
gender Zeilen genau 'line-height' voneinander entfernt sind. Das ist wichtig, wenn Spalten mit
Text in unterschiedlichen Schriften ausgerichtet werden m ssen, beispielsweise in einer Tabel-
le.
Beachten Sie, dass ersetzte Elemente eine 'font-size'- und eine 'line-height'-Eigenschaft haben,
selbst wenn sie nicht direkt verwendet werden, um die H=he der Box zu ermitteln. Die 'font-
size' wird jedoch verwendet, um die Einheiten 'em' und 'ex' zu definieren, und die 'line-
height'-Eigenschaft spielt eine Rolle in der 'vertical-align'-Eigenschaft.
'vertical-align'
Wert: baseline | sub | super | top | text-top | middle | bottom |
text-bottom | <percentage> <length> | inherit
Ausgangswert: Baseline
Angewendet auf: Elemente auf Inline-Ebene und 'table-cell'-Elemente
Vererbt: Nein
Prozentwerte: Beziehen sich auf die 'line-height' des eigentlichen Elements
Cascading Style Sheets, Level 2
Medium: Visual
Diese Eigenschaft beeinflusst die vertikale Positionierung innerhalb einer Zeilen-Box der von
einem Element auf Inline-Ebene erzeugten Boxen. Die folgenden Werte haben nur eine Bedeu-
tung f r ein bergeordnetes Element auf Inline-Ebene oder ein bergeordnetes Elemente auf
Blockebene, wenn dieses Element anonyme Inline-Boxen erzeugt; sie haben keine Wirkung,
wenn es keine solchen bergeordnete Elemente gibt.
Hinweis: Werte dieser Eigenschaft haben etwas unterschiedliche Bedeutungen im Kontext
von Tabellen. Weitere Informationen finden Sie im Abschnitt ber Algorithmen zur Ermittlung
der Tabellenh=he. n
baseline
Richtet die Grundlinie der Box an der Grundlinie der bergeordneten Box aus. Hat die
Box keine Grundlinie, wird die untere Kante der Box an der Grundlinie der Box des ber-
geordneten Elements ausgerichtet.
middle
Richtet den vertikalen Mittelpunkt der Box an der Grundlinie der bergeordneten Box plus
der halben x-H=he des bergeordneten Elements aus.
< 676 > Details zum visuellen Formatierungsmodell
Page size: 168,00 x 240,00 mm
sub
Senkt die Grundlinie der Box f r die richtige Position von Tiefstellungen der Box des ber-
geordneten Elements ab. (Dieser Wert hat keine Wirkung f r die Schriftgr=ße des Ele-
menttexts.)
super
Hebt die Grundlinie der Box f r die richtige Position von Hochstellungen der Box des ber-
geordneten Elements an. (Dieser Wert hat keine Wirkung auf die Schriftgr=ße des Ele-
menttexts.)
text-top
Richtet die obere Kante der Box an der oberen Kante der Schrift des bergeordneten Ele-
ments.
text-bottom
Richtet die untere Kante der Box an der unteren Kante der Schrift des bergeordneten
Elements aus.
<percentage>
Hebt (positiver Wert) oder senkt (negativer Wert) die Box um diesen Abstand. Der Wert
'0cm' hat dieselbe Bedeutung wie 'baseline'.
Die restlichen Werte beziehen sich auf die Zeilen-Box, in der die erzeugte Box erscheint:
top
Richtet die obere Kante der Box an der oberen Kante der Zeilen-Box aus.
bottom
Richtet die obere Kante der Box an der oberen Kante der Zeilen-Box aus.
11 Visuelle Effekte
Cascading Style Sheets, Level 2
11.1 berlauf und Abschneiden
Im Allgemeinen wird der Inhalt einer Block-Box auf die Inhaltskanten der Box begrenzt. In
bestimmten F@llen kann es einen Hberlauf einer Box geben, das heißt, ihr Inhalt liegt teilweise
oder ganz außerhalb der Box, z. B.:
· Eine Zeile kann nicht umbrochen werden, so dass die Zeilen-Box breiter als die Block-Box
ist.
· Eine Box auf Blockebene ist zu breit f r den umschließenden Block. Das kann passieren,
wenn die 'width'-Eigenschaft eines Elements einen Wert hat, der bewirkt, dass die erzeugte
Block-Box ber die Seiten des umschließenden Blocks hinausragt.
· Die H=he eines Elements berschreitet die dem umschließenden Block explizit zugeord-
nete H=he (das heißt, die H=he des umschließenden Blocks wird durch die 'height'-Eigen-
schaft festgelegt, nicht durch die Inhaltsh=he).
· Eine eingebette Box ist derart absolut positioniert, dass Teile außerhalb der umgebenden
Box liegen.
· Eine eingebette Box hat negative R@nder, was dazu f hrt, dass Teile außerhalb der umge-
benden Box liegen.
Visuelle Effekte < 677 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Immer wenn ein berlauf stattfindet, gibt die 'overflow'-Eigenschaft an, wie (und ob) eine Box
abgeschnitten wird. Die 'clip'-Eigenschaft gibt die Gr=ße und den Umriss des Abschneide-
bereichs an. Die Angabe eines kleinen Abschneidebereichs kann das Abschneiden eines andern-
falls sichtbaren Inhalts bewirken.
11.1.1 berlauf: die 'overflow'-Eigenschaft
'overflow'
Wert: visible | hidden | scroll | auto | inherit
Ausgangswert: Visible
Angewendet auf: Elemente auf Blockebene und ersetzte Elemente
Vererbt: Nein
Prozentwerte: N/A
Medium: Visual
Diese Eigenschaft gibt an, ob der Inhalt eines Elements auf Blockebene abgeschnitten wird,
wenn er ber die Box des Elements (die als umschließender Block f r den Inhalt dient) hinaus-
geht. Die Werte haben die folgenden Bedeutungen:
visible
Dieser Wert zeigt an, dass Inhalt nicht abgeschnitten wird, das heißt, er kann außerhalb der
Block-Box angezeigt werden.
hidden
Dieser Wert gibt an, dass der Inhalt abgeschnitten wird und kein Mechanismus zum Scrol-
ling bereitgestellt werden soll, um den Inhalt außerhalb des Abschneidebereichs anzuzeigen;
Cascading Style Sheets, Level 2
die Benutzer haben keinen Zugriff auf den abgeschnittenen Inhalt. Die Gr=ße und die Form
des Abschneidebereichs wird durch die Gr=ße und die Form des 'clip'-Bereichs angegeben.
scroll
Dieser Wert gibt an, dass der Inhalt abgeschnitten wird und dass, wenn das Benutzerpro-
gramm Mechanismen zum Scrolling verwendet, die auf dem Bildschirm sichtbar sind (wie
beispielsweise eine Bildlaufleiste oder einen Panner), dieser Mechanismus f r eine Box
angezeigt werden soll, unabh@ngig davon, ob ihr Inhalt abgeschnitten wird. Damit vermeidet
man Probleme mit Bildlaufleisten, die in einer dynamischen Umgebung erscheinen und ver-
schwinden. Wird dieser Wert angegeben und das Zielmedium ist 'print', sollte berlaufen-
der Inhalt gedruckt werden.
auto
Das Verhalten des Werts 'auto' ist vom Benutzerprogramm abh@ngig, sollte aber veranlas-
sen, dass f r berlaufende Boxen ein Mechanismus zum Scrolling bereitgestellt wird.
Selbst wenn 'overflow' auf 'visible' gesetzt ist, kann Inhalt durch die systemeigene Betriebs-
umgebung auf das Dokumentfenster eines Benutzerprogramms zugeschnitten werden.
< 678 > Visuelle Effekte
Page size: 168,00 x 240,00 mm
Beispiel
Betrachten Sie das folgende Beispiel eines Block-Zitats (BLOCKQUOTE), das zu groß
f r seinen umschließenden Block (der durch ein DIV eingerichtet wird) ist. Hier das
Quelldokument:
<DIV class="container">
<BLOCKQUOTE>
<P>I didn't like the play, but then I saw
it under adverse conditions - the curtain was up.
<DIV class="attributed-to">- Groucho Marx</DIV>
</BLOCKQUOTE>
</DIV>
Nachfolgend das Stylesheet, das die Gr=ße und den Stil der erzeugten Boxen steuert:
[Link] { width : 100px; height: 100px;
border: thin solid red;
}
BLOCKQUOTE { width : 125px; height : 100px;
margin-top: 50px; margin-left: 50px;
border: thin dashed black
}
[Link]-to { text-align : right; }
Der Ausgangswert von 'overflow' ist 'visible', deshalb w rde das BLOCKQUOTE ohne
Abschneiden formatiert, etwa wie folgt:
I didn’t like the play,
but then I saw it
Cascading Style Sheets, Level 2
under adverse
conditions − the
DIV curtain was up.
− Groucho Marx
BLOCKQUOTE
Wird dagegen 'overflow' f r das DIV-Element auf 'hidden' gesetzt, wird das BLOCKQUOTE
auf den umschließenden Block zugeschnitten:
I didn’t li
but then
under ad
condition
berlauf und Abschneiden < 679 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Der Wert von 'scroll' teilt den Benutzerprogrammen, die einen sichtbaren Mechanismus zum
Scrolling unterst tzen, mit, dass sie diesen auch anzeigen sollten, so dass Benutzer auf den
zugeschnittenen Inhalt zugreifen k=nnen.
11.1.2 Abschneiden : die 'clip'-Eigenschaft
Ein Abschneidebereich (clipping region) definiert, welcher Teil des dargestellten Inhalts eines Ele-
ments sichtbar ist. Standardm@ßig hat der Abschneidebereich dieselbe Gr=ße und dieselbe
Form wie die Element-Boxen. Der Abschneidebereich kann jedoch durch die 'clip'-Eigenschaft
abge@ndert werden.
'clip'
Wert: <shape> | auto | inherit
Ausgangswert: Auto
Angewendet auf: Elemente auf Blockebene und ersetzte Elemente
Vererbt: Nein
Prozentwerte: N/A
Medium: Visual
Die 'clip'-Eigenschaft bezieht sich auf Elemente, deren 'overflow'-Eigenschaft einen anderen
Wert als 'visible' hat. Die Werte k=nnen die folgenden Bedeutungen haben:
auto
Der Abschneidebereich hat dieselbe Gr=ße und Position wie die Element-Boxen.
<shape>
In CSS2 ist der einzig g ltige <shape>-Wert rect(<top> <right> <bottom> <left>), wobei
Cascading Style Sheets, Level 2
<top>, <bottom>, <right> und <left> die Abst@nde von den jeweiligen Seiten der Box
angeben.
<top>, <right>, <bottom> und <left> k=nnen einen <length>-Wert oder 'auto' annehmen.
Negative L@ngen sind erlaubt. Der Wert 'auto' bedeutet, dass eine vorgegebene Kante des
Abschneidebereichs dieselbe ist wie die Kante der erzeugten Box des Elements (das heißt,
'auto' bedeutet dasselbe wie '0').
Wenn Koordinaten auf Pixelkoordinaten gerundet werden, sollte darauf geachtet werden,
dass keine Pixel sichtbar bleiben, wenn <left> + <right> gleich der Breite des Elements sind
(oder <top> + <bottom> gleich der H=he des Elements), und dass andererseits keine Pixel
verborgen bleiben, wenn diese Werte 0 sind.
Anmerkung der bersetzer: Der einzig g ltige Wert f r <shape> hat gem@ß
CSS-Errata die Form rect(<top>, <right>, <bottom>, <left>). Beachten Sie die Kom-
mata!
Die Errata gestatten einem Benutzerprogramm sowohl die Erkennung von Leeraum als
auch von Kommata zum Trennen der Parameter von rect().
Eine weitere sehr interessante Bemerkung in den Errata ist Folgende:
< 680 > Visuelle Effekte
Page size: 168,00 x 240,00 mm
„W@hrend CSS2 festlegt, dass die Werte von rect() Abst@nde von den jeweiligen Seiten
der Box angeben, interpretieren aktuelle Implementierungen alle vier Werte bez glich
den oberen und linken Seiten. Die Arbeitsgruppe schl@gt vor, CSS2 so zu revidieren,
dass die Spezifikation mit der g@ngigen Praxis bereinstimmt.“
Die Vorfahren des Elements k=nnen ebenfalls Abschneidebereiche haben (falls ihre 'over-
flow'-Eigenschaft nicht 'visible' ist); dargestellt wird die Schnittmenge aus den verschiedenen
Zuschneidebereichen.
berschreitet der Abschneidebereich die Grenzen des Dokumentfensters des Benutzerpro-
gramms, kann der Inhalt durch die systemeigene Betriebssystemumgebung auf dieses Fenster
zugeschnitten werden.
Beispiel
Die beiden folgenden Regeln:
P { clip: rect(5px, 10px, 10px, 5px); }
P { clip: rect(5px, -5px, 10px, 5px); }
erzeugen die rechteckigen Abschneidebereiche, die in den folgenden Abbildungen durch die
gestrichelten Linien gekennzeichnet sind:
(0, 0) (50, 0)
Cascading Style Sheets, Level 2
clip region
(0, 55)
P’s block box
(0, 0) (50, 0)
clip region
(0, 55)
P’s block box
berlauf und Abschneiden < 681 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Hinweis: In CSS2 sind alle Abschneidebereiche rechteckig. Wir erwarten zuk nftige Erwei-
terungen, die auch ein anderes als ein rechteckiges Zuschneiden erlauben. n
11.2 Sichtbarkeit: die 'visibility'-Eigenschaft
'visibility'
Wert: visible | hidden | collapse | inherit
Ausgangswert: Inherit
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozentwerte: N/A
Medium: Visual
Anmerkung der bersetzer: Die CSS2-Errata @ndern den Ausgangswert und den
Vererbt-Wert wie folgt:
Ausgangswert: visible
Vererbt: ja
Die Bedeutung ist die gleiche wie zuvor, jedoch vermeidet sie den undefinierten
Zustand des Wurzelelements, der zu Problemen bei einigen DOM-Implementierungen
f hrte.
Die 'visibility'-Eigenschaft gibt an, ob die durch ein Element erzeugten Boxen angezeigt werden.
Cascading Style Sheets, Level 2
Unsichtbare Boxen haben weiterhin Einfluss auf das Layout (um das Erzeugen von Boxen v=llig
zu unterdr cken, setzen Sie die 'display'-Eigenschaft auf 'none'). Die Werte haben die folgenden
Bedeutungen:
visible
Die erzeugte Box ist sichtbar.
hidden
Die erzeugte Box ist unsichtbar (v=llig transparent), beeinflusst aber das Layout.
collapse
Lesen Sie bitte den Abschnitt 17.5.5 ber dynamische Zeilen- und Spalteneffekte in Tabel-
len. Wird 'collapse' f r andere Elemente als Zeilen oder Spalten angewendet, hat es die-
selbe Bedeutung wie 'hidden'.
Diese Eigenschaft kann in Kombination mit Skripts verwendet werden, um dynamische Effekte
zu erzeugen.
< 682 > Visuelle Effekte
Page size: 168,00 x 240,00 mm
Beispiel
Im folgenden Beispiel wird durch Anklicken einer Schaltfl@che auf dem Formular eine
benutzerdefinierte Skriptfunktion aufgerufen, die veranlasst, dass die betreffende Box
sichtbar wird, die andere verborgen. Weil diese Boxen dieselbe Gr=ße und Position
haben, ersetzen sie sich letztlich wechselseitig. (Der Skriptcode ist in einer hypotheti-
schen Skriptsprache formuliert. Er kann einen beliebigen Effekt in einem CSS-f@higen
Benutzerprogramm haben, muss aber nicht.)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<STYLE type="text/css">
<!- -
#container1 { position: absolute;
top: 2in; left: 2in; width: 2in }
#container2 { position: absolute;
top: 2in; left: 2in; width: 2in;
visibility: hidden; }
- ->
</STYLE>
</HEAD>
<BODY>
<P>W]hlen Sie einen Verd]chtigen:</P>
<DIV id="container1">
<IMG alt="Al Capone"
width="100" height="100"
src="[Link]">
<P>Name: Al Capone</P>
<P>Residence: Chicago</P>
</DIV>
<DIV id="container2">
<IMG alt="Lucky Luciano"
width="100" height="100"
Cascading Style Sheets, Level 2
src="[Link]">
<P>Name: Lucky Luciano</P>
<P>Residence: New York</P>
</DIV>
<FORM method="post"
action="[Link]
<P>
<INPUT name="Capone" type="button"
value="Capone"
onclick='show("container1");hide("container2")'>
<INPUT name="Luciano" type="button"
value="Luciano"
onclick='show("container2");hide("container1")'>
</FORM>
</BODY>
</HTML>
Sichtbarkeit: die 'visibility'-Eigenschaft < 683 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
12 Erzeugter Inhalt, automatische
Nummerierung und Listen
In einigen F@llen wollen Autoren, dass Benutzerprogramme Inhalt darstellen, der nicht aus dem
Dokumentbaum stammt. Ein bekanntes Beispiel daf r ist eine nummerierte Liste; der Autor
will die Nummern nicht explizit auflisten, sondern das Benutzerprogramm soll sie automatisch
erzeugen. Analog dazu k=nnte es beispielsweise vorkommen, dass das Benutzerprogramm das
Wort „Abbildung“ vor einer Bildunterschrift einf gt, oder die W=rter „Kapitel 7“ vor dem
Titel des siebten Kapitels. Insbesondere f r Audio oder Braille sollten die Benutzerprogramme
in der Lage sein, diese Zeichenketten einzuf gen.
In CSS2 kann Inhalt mit Hilfe mehrerer Mechanismen erzeugt werden:
·· Die 'content'-Eigenschaft, in Kombination mit den Pseudoelementen :before und :after.
Die akustischen Eigenschaften 'cue-before' und 'cue-after' (lesen Sie dazu das Kapitel 19
ber akustische Stylesheets). Wenn die Eigenschaft 'content' mit den akustischen Eigen-
schaften kombiniert wird, werden sie in der folgenden Reihenfolge dargestellt: :before, 'cue-
before', ('pause-before'), dem Elementinhalt, ('pause-after'), 'cue-after' und :after.
· Elemente mit dem Wert 'list-item' f r die 'display'-Eigenschaft.
Nachfolgend beschreiben wir die Mechanismen der 'content'-Eigenschaft.
12.1 Die Pseudoelemente :before und :after
Autoren geben den Stil und die Position erzeugten Inhalts mit Hilfe der Pseudoelemente :be-
fore und :after an. Wie ihre Namen schon sagen, geben die Pseudoelemente :before und :after
die Position von Inhalt vor und hinter dem Dokumentbauminhalt eines Elements an. Die 'con-
tent'-Eigenschaft gibt in Kombination mit diesen Pseudoelementen an, was eingef gt wird.
Cascading Style Sheets, Level 2
Beispiel
Die folgende Regel beispielsweise f gt die Zeichenkette „Hinweis:“ vor dem Inhalt jedes
P-Elements ein, dessen „class“-Attribut den Wert „note“ hat:
[Link]:before { content: "Hinweis: " }
Die Formatierungsobjekte (zum Beispiel Boxen), die von einem Element erzeugt werden, ent-
halten den automatisch erzeugten Inhalt. Wenn man beispielsweise das obige Stylesheet wie
folgt ab@ndert:
[Link]:before { content: "Note: " }
[Link] { border: solid green }
wird ein durchgezogener gr ner Rahmen um den gesamten Absatz angezeigt, inklusive der ers-
ten Zeichenkette.
Die Pseudoelemente :before und :after erben alle vererbbaren Eigenschaften von dem Element
im Dokumentbaum, dem sie zugeordnet sind.
< 684 > Erzeugter Inhalt, automatische Nummerierung, Listen
Page size: 168,00 x 240,00 mm
Beispiel
Beispielsweise f gen die folgenden Regeln ein =ffnendes Anf hrungszeichen vor jedem
Q-Element ein. Die Farbe des Anf hrungszeichens ist rot, aber die Schrift ist dieselbe
wie die Schrift des restlichen Q-Elements:
Q:before {
content: open-quote;
color: red
}
In der Deklaration der Pseudoelemente :before oder :after nehmen nicht geerbte Eigenschaften
ihren Ausgangswert an.
Beispiel
Weil also beispielsweise der Ausgangswert der Eigenschaft 'display' gleich 'inline' ist,
wird das Anf hrungszeichen im vorigen Beispiel als inzeilige Box eingef gt (also auf der-
selben Zeile wie der anf@ngliche Textinhalt des Elements). Das n@chste Beispiel setzt die
'display'-Eigenschaft explizit auf 'block', so dass der eingef gte Text zu einem Block
wird.
BODY:after {
content: "Das Ende";
display: block;
margin-top: 2em;
text-align: center;
}
Beachten Sie, dass ein akustisches Benutzerprogramm nach der Darstellung des restlichen
BODY-Elements die W=rter „Das Ende“ aussprechen w rde.
Benutzerprogramme m ssen die folgenden Eigenschaften f r die Pseudoelemente :before und
Cascading Style Sheets, Level 2
:after ignorieren: 'position', 'float', Listeneigenschaften und Tabelleneigenschaften.
Die Pseudoelemente :before und :after erlauben, dass die 'display'-Eigenschaft die folgenden
Werte annimmt:
· Wenn das Subjekt (siehe Abschnitt 5.2) des Selektors ein Blocklevel-Element ist, sind die
erlaubten Werte 'none', 'inline', 'block' und 'marker'. Wenn der Wert von 'display' einen
andern Wert hat, verh@lt sich das Pseudoelement so, als w@re der Wert gleich 'block'.
· Wenn das Subjekt des Selektors ein Inline-Level-Element ist, sind die erlaubten Werte 'no-
ne' und 'inline'. Wenn der Wert von 'display' einen anderen Wert hat, verh@lt sich das Pseu-
doelement so, als w@re der Wert gleich 'inline'.
Hinweis: In zuk nftigen Versionen von CSS sind m=glicherweise auch andere Werte
erlaubt. n
Erzeugter Inhalt, automatische Nummerierung, Listen < 685 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
12.2 Die 'content'-Eigenschaft
'content'
Wert: [<string> | <uri> | <counter> | attr(X) | open-quote |
close-quote | no-open-quote | no-close-quote]+ | inherit
Ausgangswert Leerer String
Angewendet auf: 'display : marker' und die Pseudoelemente :before und :after
Vererbt: Nein
Prozentwerte: N/A
Medium: All
Diese Eigenschaft wird f r die Pseudoelemente :before und :after verwendet, um Inhalt in
einem Dokument zu erzeugen. Die Werte haben die folgenden Bedeutungen:
<string>
Textinhalt (lesen Sie dazu den Abschnitt 4.3.10 ber Zeichenketten).
<uri>
Der Wert ist ein URI, der eine externe Ressource angibt. Wenn ein Benutzerprogramm
die Ressource aufgrund der von ihm unterst tzen Medientypen nicht unterst tzen kann,
muss es sie ignorieren.
Hinweis: CSS2 bietet keinen Mechanismus, um die Gr=ße des eingebetteten Objekts zu @ndern
oder um eine Textbeschreibung bereitzustellen, wie etwa die Attribute „alt“ oder „longdesc“
f r Bilder in HTML. Das kann sich jedoch in zuk nftigen Versionen von CSS @ndern. n
Cascading Style Sheets, Level 2
<counter>
Z@hler k=nnen mit zwei verschiedenen Funktionen angegeben werden: 'counter()' oder
'counters()'. Die erste Funktion hat zwei Formen: 'counter(name)' oder 'counter(name,
style)'. Der erzeugte Text ist der Wert des benannten Z@hlers an dieser Stelle in der For-
matierungsstruktur; er wird im angegebenen Stil formatiert (standardm@ßig 'decimal'). Die
zweite Funktion hat ebenfalls zwei Formen: 'counter(name, string)' oder 'counter(name,
string, style)'. Der erzeugte Text ist der Wert aller Z@hler mit dem betreffenden Namen an
dieser Stelle der Formatierungsstruktur, abgetrennt durch den angegebenen String. Die
Z@hler werden in dem angegeben Stil dargestellt (standardm@ßig 'decimal'). Weitere Infor-
mationen finden Sie im Abschnitt 12.5 ber automatische Z@hler und Nummerierung.
open-quote und close-quote
Diese Werte werden durch die geeignete Zeichenkette aus der Eigenschaft 'quotes' ersetzt.
no-open-quote und no-close-quote
F gt nichts ein (die leere Zeichenkette), inkrementiert (bzw. dekrementiert) aber die Ver-
schachtelungsebene f r Anf hrungszeichen.
< 686 > Erzeugter Inhalt, automatische Nummerierung, Listen
Page size: 168,00 x 240,00 mm
attr(X)
Diese Funktion gibt den Wert des Attributs X f r das Subjekt des Selektors als Zeichen-
kette zur ck. Die Zeichenkette wird vom CSS-Prozessor nicht geparst. Wenn das Subjekt
des Selektors kein Attribut X hat, wird eine leere Zeichenkette zur ckgegeben. Ob bei den
Attributnamen die Groß-/Kleinschreibung ber cksichtigt wird, ist von der Dokumentspra-
che abh@ngig.
Hinweis. In CSS2 ist es nicht m=glich, auf Attributwerte f r andere Elemente des Selektors
zuzugreifen. n
Die 'display'-Eigenschaft steuert, ob der Inhalt in einem Block, einer Inline- oder Markierungs-
Box angezeigt wird.
Autoren sollten 'content'-Deklarationen in @media-Regeln platzieren, wenn der Inhalt vom
Medium abh@ngig ist. Beispielsweise k=nnte literaler Text f r jede Mediengruppe verwendet
werden, w@hrend Bilder sich nur auf visuelle und Bitmap-Mediengruppen beziehen und Sound-
dateien nur auf die akustische Mediengruppe.
Beispiel
Die folgende Regel bewirkt, dass eine Sounddatei am Ende eines Zitats abgespielt wird
(weitere Mechanismen finden Sie im Abschnitt 19 ber akustische Stylesheets):
@media aural {
BLOCKQUOTE:after { content: url("[Link]") }
}
Die n@chste Regel f gt den Text des HTML-Attributs „alt“ vor dem Bild ein. Wenn das Bild
nicht angezeigt wird, sieht der Leser statt dessen den „alt“-Text.
IMG:before { content: attr(alt) }
Cascading Style Sheets, Level 2
Autoren k=nnen Neuezeilezeichen in den erzeugten Inhalt einf gen, indem sie die Escape-Folge
„\A“ in einen der Strings hinter der 'content'-Eigenschaft einf gen. Damit wird ein erzwungener
Zeilenumbruch eingef gt, @hnlich dem BR-Element in HTML. Weitere Informationen ber die
Escape-Folge „\A“ finden Sie in „Zeichenketten“ (4.3.10) und „Zeichen und Groß-/Kleinschrei-
bung“ (4.1.3).
Beispiel
H1:before {
display: block;
text-align: center;
content: "chapter\A hoofdstuk\A chapitre"
}
Erzeugter Inhalt ver@ndert den Dokumentbaum nicht. Insbesondere wird er nicht an den
Dokumentsprachprozessor zur ckgemeldet (z. B. f r ein erneutes Parsing).
Hinweis: In zuk nftigen Versionen von CSS kann es sein, dass die 'content'-Eigenschaft zus@tz-
liche Werte akzeptiert, so dass der Stil von Bereichen des erzeugten Inhalts variiert wird, aber
in CSS2 hat der gesamte Inhalt der Pseudoelemente :before und :after denselben Stil. n
Die 'content'-Eigenschaft < 687 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
12.3 Zusammenspiel von :before und :after mit den
Elementen 'compact' und 'run-in'
Die folgenden F@lle k=nnen auftreten:
1. Ein 'run-in'- oder 'compact'-Element hat ein :before-Pseudoelement des Typs
'inline': Das Pseudoelement wird ber cksichtigt, wenn die Gr=ße der Element-Box berech-
net wird (f r 'compact'), und innerhalb derselben Block-Box wie das Element dargestellt.
2. Ein 'run-in'- oder 'compact'-Element hat ein :after-Pseudoelement des Typs
'inline': Die Regeln des vorhergehenden Punktes werden angewendet.
3. Ein 'run-in'- oder 'compact'-Element hat ein :before-Pseudoelement des Typs
'block': Das Pseudoelement wird als Block oberhalb des Elements formatiert und bei der
Berechnung der Elementgr=ße (f r 'compact') nicht ber cksichtigt.
4. Ein 'run-in-'- oder 'compact'-Element hat ein :after-Pseudoelement des Typs
'block': Sowohl das Element als auch sein :after-Pseudoelement werden als Block-Box for-
matiert. Das Element ist nicht als Inline-Box in seinem eigenen :after-Pseudoelement forma-
tiert.
5. Das Element, das einem 'run-in'- oder 'compact'-Element folgt, hat ein :before-
Pseudoelement des Typs 'block': Die Entscheidung, wie das 'run-in'/'compact'-Element
formatiert wird, wird abh@ngig von der Block-Box getroffen, die aus dem :before-Pseudo-
element resultiert.
6. Das Element, das einem 'run-in'- oder 'compact'-Element folgt, hat ein :before-
Pseudoelement des Typs 'inline': Die Entscheidung, wie das 'run-in'/'compact'-Element
formatiert wird, ist vom 'display'-Wert des Elements abh@ngig, dem das :before zugeordnet
ist.
Beispiel
Nachfolgend sehen Sie ein Beispiel f r einen 'run-in'-Header mit einem :after-Pseudoele-
Cascading Style Sheets, Level 2
ment gefolgt von einem Absatz mit einem :before-Pseudoelement. Alle Pseudoelemente
dieses Beispiels sind inline (das ist der Standard). Wenn das nachfolgende Stylesheet
H3 { display: run-in }
H3:after { content: ": " }
P:before { content: "... " }
auf dieses Quelldokument angewendet wird
<H3>Zentauren</H3>
<P>haben Hufe
<P>Haben einen Schwanz
sieht die visuelle Formatierung wie folgt aus:
Zentauren: ... haben Hufe
... haben einen Schwanz
< 688 > Erzeugter Inhalt, automatische Nummerierung, Listen
Page size: 168,00 x 240,00 mm
12.4 Anf-hrungszeichen
In CSS2 k=nnen Autoren in einer den Stil ber cksichtigenden und kontextabh@ngigen Weise
angeben, wie die Benutzerprogramme Anf hrungszeichen darstellen sollen. Die Eigenschaft
'quotes' gibt Paare von Anf hrungszeichen f r jede Ebene der eingebetteten Zitate an. Die
'content'-Eigenschaft bietet Zugriff auf diese Anf hrungszeichen und bewirkt, dass sie vor und
hinter einem Zitat eingef gt werden.
12.4.1 Anf-hrungszeichen mit der 'quotes'-Eigenschaft angeben
'quotes'
Wert: [<string> <string>]+ | none | inherit
Ausgangswert: Vom Benutzerprogramm abh@ngig
Angewendet auf: Alle Elemente
Geerbt: Ja
Prozentwerte: N/A
Medium: Visual
Diese Eigenschaft gibt die Anf hrungszeichen f r eine beliebige Anzahl eingebetteter Zitate an.
Die Werte haben die folgenden Bedeutungen:
none
Die Werte 'open-quote' und 'close-quote' der 'content'-Eigenschaft erzeugen keine Anf h-
rungsstriche.
[<string> <string>]+
Cascading Style Sheets, Level 2
Werte f r die 'open-quote'- und 'close-quote'-Werte der 'content'-Eigenschaft werden die-
ser Liste mit Anf hrungszeichenpaaren (=ffnende und schließende) entnommen. Das erste
Paar (ganz links) stellt die @ußerste Zitatebene dar, das zweite Paar die erste Einbettungs-
ebene usw. Das Benutzerprogramm muss abh@ngig von der Einbettungsebene das geeignete
Anf hrungszeichenpaar verwenden.
Beispiel
Wendet man beispielsweise das folgende Stylesheet
/* Gibt AnfUhrungszeichenpaare fUr zwei Ebenen in zwei Sprachen an */
Q:lang(en) { quotes: '"' '"' "'" "'" }
Q:lang(no) { quotes: "\(" "\(" "<" ">" }
/* AnfUhrungszeichen vor und nach Q-Elementinhalt einfUgen */
Q:before { content: open-quote }
Q:after { content: close-quote }
Anf#hrungszeichen < 689 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
auf das folgende HTML-Fragment an
<HTML lang="en">
<HEAD>
<TITLE>Quotes</TITLE>
</HEAD>
<BODY>
<P><Q>Quote me!</Q>
</BODY>
</HTML>
erh@lt man
"Quote me!"
w@hrend dieses HTML
<HTML lang="no">
<HEAD>
<TITLE>Quotes</TITLE>
</HEAD>
<BODY>
<P><Q>Trøndere grcter ncr <Q>Vinsjan pc kaia</Q> blir deklamert.</Q>
</BODY>
</HTML>
Folgendes erzeugen w rde:
\(Trøndere grcter ncr <Vinsjan pc kaia> blir deklamert.\(
Hinweis: W@hrend die durch die 'quotes' in den vorigen Beispielen angegebenen Anf hrungs-
zeichen alle bequem auf den Computertastaturen liegen, w rde ein wirklich hochqualitativer
Cascading Style Sheets, Level 2
Schriftsatz andere ISO 10646-Zeichen erfordern. Die folgende informelle Tabelle listet einige
der ISO 10646-Anf hrungszeichen auf: n
Ange- ISO Beschreibung
[Link] 10646-Code
Darstellung (hex)
" 0022 ANF HRUNGSZEICHEN [das doppelte ASCII-
Anf hrungszeichen]
' 0027 APOSTROPH [das einfache ASCII-Anf hrungs-
zeichen]
< 2039 EINZELNES ANF HRUNGSZEICHEN SPITZE
KLAMMER NACH LINKS
> 203A EINZELNES ANF HRUNGSZEICHEN SPITZE
KLAMMER NACH RECHTS
“ 00AB ANF HRUNGSZEICHEN DOPPELTE SPITZE
KLAMMER NACH LINKS
< 690 > Erzeugter Inhalt, automatische Nummerierung, Listen
Page size: 168,00 x 240,00 mm
„ 00BB ANF HRUNGSZEICHEN DOPPELTE SPITZE
KLAMMER NACH RECHTS
` 2018 LINKES EINFACHES ANF HRUNGSZEICHEN
[einfach oben 6]
' 2019 RECHTES EINFACHES ANF HRUNGS-
ZEICHEN [einfach oben 9]
`` 201C LINKES DOPPELTES ANF HRUNGSZEICHEN
[doppelt oben 6]
'' 201D RECHTES DOPPELTES ANF HRUNGS-
ZEICHEN [doppelt oben 9]
,, 201E DOPPELTES UNTERES ANF HRUNGS-
ZEICHEN [doppelt unten 9]
Anmerkung der bersetzer: In den Entity-Mengen von XHTML sind f r einige
Anf hrungszeichen auch Zeichen-Entities definiert. F r die blichen deutschen Anf h-
rungszeichen sind diese beiden die beste N@herung:
<!ENTITY rdquo "”"> <!- - right double quotation mark,
U+201D ISOnum - ->
<!ENTITY bdquo "„"> <!- - double low-9 quotation mark,
U+201E NEW - ->
Es handelt sich dabei um die in der Tabelle schon genannten Zeichen an den Positionen
201E (links) und 201D (rechts). Da die beiden Zeichen f r XHTML definiert sind,
besteht eine gute Chance, dass die aktuellen Browser diese Zeichen auch kennen. Ver-
suche best@tigen dies. Allerdings wird das rechte Anf hrungszeichen nicht ganz genau
Cascading Style Sheets, Level 2
nach den deutschen Konventionen dargestellt. Die folgende Abbildung zeigt die kor-
rekte Darstellung (erzeugt mit Word).
Der HTML-Code „ Zitat ” f hrt im Browser (hier: Mozilla) jedoch zu fol-
gender Darstellung.
12.4.2 Anf-hrungszeichen mit der 'content'-Eigenschaft einf-gen
Mit den 'open-quote'-Werten der 'content'-Eigenschaft werden Anf hrungszeichen an den
geeigneten Stellen in einem Dokument eingef gt. Jedes Auftreten von 'open-quote' oder 'close-
quote' wird durch einen Wert von 'quotes' ersetzt, abh@ngig von der Verschachtelungstiefe.
Anf#hrungszeichen < 691 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
'open-quote' bezieht sich auf das erste Anf hrungszeichen eines Paares, 'close-quote' auf das
zweite. Welches Anf hrungszeichenpaar verwendet wird, ist von der Verschachtelungstiefe
der Anf hrungszeichen abh@ngig: Die Anzahl der Auftreten von 'open-quote' wird im gesamten
erzeugten Text vor dem aktuellen Auftreten gez@hlt, minus der Anzahl des Auftretens von 'clo-
se-quote'. Ist die Tiefe gleich 0, wird das erste Paar verwendet, ist die Tiefe 1, wird das zweite
Paar verwendet usw. Ist die Tiefe gr=ßer als die Anzahl der Paare, wird das letzte Paar fortlau-
fend wiederholt.
Beachten Sie, dass diese Anf hrungszeichentiefe unabh@ngig von der Verschachtelung des
Quelldokuments oder der Formatierungsstruktur ist.
Einige typographische Stile fordern, dass =ffnende Anf hrungszeichen vor jedem Absatz eines
Zitats wiederholt werden, das sich ber mehrere Abs@tze erstreckt, aber nur der letzte Absatz
endet mit einem schließenden Anf hrungszeichen. In CSS kann das erzielt werden, indem
schließende „Phantom“-Anf hrungszeichen gesetzt werden. Das Schl sselwort 'no-close-quo-
te' dekrementiert die Zitatebene, f gt aber kein Anf hrungszeichen ein.
Beispiel
Das folgende Stylesheet setzt =ffnende Anf hrungszeichen f r jeden Absatz in einem
BLOCKQUOTE und f gt am Ende ein einzelnes schließendes Anf hrungszeichen ein:
BLOCKQUOTE P:before { content: open-quote }
BLOCKQUOTE P:after { content: no-close-quote }
BLOCKQUOTE [Link]:after { content: close-quote }
Das basiert auf dem letzten Absatz, der mit der Klasse „last“ markiert wurde, weil es keine
Selektoren gibt, die mit dem letzten untergeordneten Element eines Elements bereinstimmen
k=nnen.
Aus Symmetriegr nden gibt es auch das Schl sselwort 'no-open-quote', das nichts einf gt, son-
dern die Anf hrungszeichentiefe um eins inkrementiert.
Cascading Style Sheets, Level 2
Hinweis: Wenn ein Zitat in einer anderen Sprache vorliegt als der umschließende Text, ist es
blich, den Text mit Anf hrungszeichen der Sprache des umschließenden Texts auszuzeichnen,
nicht mit den Anf hrungszeichen der Sprache des Zitats. n
Ein Beispiel f r Franz=sisch innerhalb von Englisch:
The device of the order of the garter is "Honi soit qui mal y pense."
Englisch innerhalb von Franz=sisch:
Il disait: »Il faut mettre l'action en <fast forward>.«
Beispiel
Ein Stylesheet wie das Folgende setzt die 'quotes'-Eigenschaft so, dass 'open-quote' und
'close-quote' korrekt f r alle Elemente funktionieren. Diese Regeln gelten f r Doku-
mente, die nur Englisch, Franz=sisch oder beides enthalten. F r jede zus@tzliche Sprache
wird eine weitere Regel ben=tigt. Beachten Sie die Verwendung des untergeordneten
Kombinatorzeichens („>“), um Anf hrungszeichen f r Elemente abh@ngig von der Spra-
che des umschließenden Texts zu setzen:
< 692 > Erzeugter Inhalt, automatische Nummerierung, Listen
Page size: 168,00 x 240,00 mm
[LANG|=fr] > * { quotes: "«" "»" "\2039" "\203A" }
[LANG|=en] > * { quotes: "\201C" "\201D" "\2018" "\2019" }
Die Anf hrungszeichen f r das Englische sind hier in einer Form gezeigt, die die meisten Leute
ber die Tastatur eingeben k=nnen. Wenn Sie sie direkt eingeben k=nnen, sehen sie wie folgt aus:
[LANG|=fr] > * { quotes: "«" "»" "<" ">" }
[LANG|=en] > * { quotes: "“" "”" "‘" "’" }
12.5 Automatische [Link] und Nummerierung
Die automatische Nummerierung in CSS2 wird durch zwei Eigenschaften gesteuert, 'counter-
increment' und 'counter-reset'. Die Z@hler, die durch diese Eigenschaften definiert sind, werden
in Kombination mit den Funktionen counter() und counters() der Eigenschaft 'content' verwen-
det.
'counter-reset'
Wert: [<identifier> <integer>]+ | none | inherit
Ausgangswert: None
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozentwerte: N/A
Medium: All
'counter-increment'
Cascading Style Sheets, Level 2
Wert: [<identifier> <integer>]+ | none | inherit
Ausgangswert: None
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozentwerte: N/A
Medium: All
Die Eigenschaft 'counter-increment' akzeptiert einen oder mehrere Namen von Z@hlern (IDs),
jeweils optional gefolgt von einer ganzen Zahl. Die ganze Zahl gibt an, um wie viel der Z@hler
bei jedem Auftreten des Elements inkrementiert wird. Das Standardinkrement ist 1. Null und
negative ganze Zahlen sind erlaubt.
Automatische Z,hler und Nummerierung < 693 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Die Eigenschaft 'counter-reset' enth@lt außerdem eine Liste eines oder mehrerer Namen von
Z@hlern, jeweils optional gefolgt von einer ganzen Zahl. Die ganze Zahl gibt den Wert an, auf
den der Z@hler bei jedem Auftreten des Elements gesetzt wird. Der Standardwert ist 0.
Wenn 'counter-increment' auf einen Z@hler verweist, der sich nicht im G ltigkeitsbereich
(siehe unten) eines 'counter-reset' befindet, wird angenommen, dass der Z@hler vom Wurzele-
lement auf 0 zur ckgesetzt wurde.
Beispiel
Dieses Beispiel zeigt eine M=glichkeit, Kapitel und Abschnitte mit „Kapitel 1“, „1.1“,
„1.2“ usw. zu nummerieren.
H1:before {
content: "Kapitel " counter(chapter) ". ";
counter-increment: chapter; /* 1 zu chapter addieren */
counter-reset: section; /* section auf 0 setzen */
}
H2:before {
content: counter(chapter) "." counter(section) " ";
counter-increment: section;
}
Wenn ein Element einen Z@hler inkrementiert/zur cksetzt und ihn auch verwendet (in der
'content'-Eigenschaft seines :before- oder :after-Pseudoelements), wird der Z@hler nach dem
Inkrementieren/Zur cksetzen verwendet.
Wenn ein Element einen Z@hler sowohl zur cksetzt als auch inkrementiert, wird der Z@hler
zuerst zur ckgesetzt und dann inkrementiert.
Die Eigenschaft 'counter-reset' folgt den Kaskadierungsregeln. Aufgrund der Kaskadierung setzt
das folgende Stylesheet
H1 { counter-reset: section -1 }
Cascading Style Sheets, Level 2
H1 { counter-reset: imagenum 99 }
nur 'imagenum' zur ck. Um beide Z@hler zur ckzusetzen, m ssen sie zusammen angegeben
werden:
H1 { counter-reset: section -1 imagenum 99 }
12.5.2 Verschachtelte [Link] und G-ltigkeitsbereich
Z@hler sind „selbst-verschachtelnd“, in der Hinsicht, dass eine Wiederverwendung eines Z@h-
lers in einem untergeordneten Elements automatisch eine neue Instanz des Z@hlers erzeugt.
Das ist wichtig f r Situationen wie beispielsweise Listen in HTML, wo Elemente in beliebiger
Tiefe innerhalb sich selbst verschachtelt werden k=nnen. Es w@re unm=glich, f r jede Ebene
eindeutig benannte Z@hler zu definieren.
< 694 > Erzeugter Inhalt, automatische Nummerierung, Listen
Page size: 168,00 x 240,00 mm
Beispiel
Folgendes gen gt also, um verschachtelte Listenelemente zu nummerieren. Das Ergeb-
nis kommt jenem sehr nahe, wenn man 'display:list-item' und 'list-style: inside' f r das
LI-Element setzt:
OL { counter-reset: item }
LI { display: block }
LI:before { content: counter(item) ". "; counter-increment: item }
Die Selbstverschachtelung basiert auf dem Prinzip, dass jedes Element, das einen 'counter-reset'
f r einen Z@hler X hat, einen neuen Z@hler X erzeugt, dessen Gltigkeitsbereich das Element ist,
seine vorhergehenden gleichrangigen Elemente und alle Ableitungen des Elements und seiner
vorhergehenden gleichrangigen Elemente.
In dem obigen Beispiel erzeugt ein OL einen Z@hler, und alle untergeordneten Elemente des
OL beziehen sich auf diesen Z@hler.
Beispiel
Wenn wir die n-te Instanz des Z@hlers „item“ als item[n] bezeichnen und den Anfang
und das Ende eines G ltigkeitsbereiches mit „(“ und „)“, verwendet das folgende
HTML-Fragment die angegebenen Z@hler. (Wir setzen dabei das Stylesheet aus dem
obigen Beispiel voraus.)
<OL> <!- - (set item[0] to 0 - ->
<LI>item <!- - increment item[0] (= 1) - ->
<LI>item <!- - increment item[0] (= 2) - ->
<OL> <!- - (set item[1] to 0 - ->
<LI>item <!- - increment item[1] (= 1) - ->
<LI>item <!- - increment item[1] (= 2) - ->
<LI>item <!- - increment item[1] (= 3) - ->
<OL> <!- - (set item[2] to 0 - ->
<LI>item <!- - increment item[2] (= 1) - ->
Cascading Style Sheets, Level 2
</OL> <!- - ) - ->
<OL> <!- - (set item[3] to 0 - ->
<LI> <!- - increment item[3] (= 1) - ->
</OL> <!- - ) - ->
<LI>item <!- - increment item[1] (= 4) - ->
</OL> <!- - ) - ->
<LI>item <!- - increment item[0] (= 3) - ->
<LI>item <!- - increment item[0] (= 4) - ->
</OL> <!- - ) - ->
<OL> <!- - (reset item[4] to 0 - ->
<LI>item <!- - increment item[4] (= 1) - ->
<LI>item <!- - increment item[4] (= 2) - ->
</OL> <!- - ) - ->
Die Funktion 'counters()' erzeugt einen String, der sich aus den Werten aller Z@hler mit dem-
selben Namen zusammensetzt, getrennt durch einen vorgegebenen String.
Automatische Z,hler und Nummerierung < 695 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Beispiel
Das folgende Stylesheet nummeriert verschachtelte Listenelemente als „1“, „1.1“,
„1.1.1“ usw.
OL { counter-reset: item }
LI { display: block }
LI:before { content: counters(item, "."); counter-increment: item }
12.5.3 [Link]
Standardm@ßig werden Z@hler mit Dezimalzahlen formatiert, aber alle Stile, die f r die Eigen-
schaft 'list-style-type' zur Verf gung stehen, stehen auch f r Z@hler zur Verf gung. Die Nota-
tion sieht wie folgt aus:
counter(name)
das ist der Standardstil; oder:
counter(name, 'list-style-type')
Alle Stile sind erlaubt, unter anderem 'disc', 'circle', 'square' und 'none'.
H1:before { content: counter(chno, upper-latin) ". " }
H2:before { content: counter(section, upper-roman) " - " }
BLOCKQUOTE:after { content: " [" counter(bq, hebrew) "]" }
[Link]:before { content: counter(notecntr, disc) " " }
P:before { content: counter(p, none) }
12.5.4 [Link] in Elementen mit 'display:none'
Cascading Style Sheets, Level 2
Ein Element, das nicht angezeigt wird ('display' ist auf 'none' gesetzt), kann einen Z@hler nicht
inkrementieren oder zur cksetzen.
Beispiel
Beispielsweise inkrementieren nach dem folgenden Stylesheet H2s mit der Klasse
„secret“ 'count2' nicht.
[Link] {counter-increment: count2; display: none}
Elemente, deren 'visibility' auf 'hidden' gesetzt ist, inkrementieren die Z@hler dagegen sehr
wohl.
< 696 > Erzeugter Inhalt, automatische Nummerierung, Listen
Page size: 168,00 x 240,00 mm
12.6 Markierungen (Marker) und Listen
Die meisten Elemente auf Blockebene in CSS erzeugen eine Hauptblock-Box. In diesem
Abschnitt beschreiben wir zwei CSS-Mechanismen, die bewirken, dass ein Element zwei Bl=cke
erzeugt: eine Hauptblock-Box (f r den Inhalt eines Elements) und eine separate Markierungs-
Box (f r Dekorationen, wie beispielsweise einen Punkt, ein Bild oder eine Nummer). Die Mar-
kierungs-Box kann innerhalb oder außerhalb der Haupt-Box platziert werden. Anders als :befo-
re- und :after-Inhalt beeinflusst die Markierungs-Box die Position der Haupt-Box nicht, egal
welches Positionierungsschema verwendet wird.
Der allgemeinere der beiden Mechanismen ist neu in CSS2 und wird auch als Markierungen
(Marker) bezeichnet. Der einschr@nkendere Mechanismus beinhaltet die Listeneigenschaften
von CSS1. Mit Listeneigenschaften k=nnen Autoren schnelle Ergebnisse f r viele gebr@uchliche
geordnete und nicht geordnete Listenszenarien erzielen. Markierungen bieten Autoren jedoch
eine pr@zise Kontrolle ber den Inhalt und die Position der Markierung. Markierungen k=nnen
in Kombination mit Z@hlern verwendet werden, um neue Listenstile zu erzeugen, um Randbe-
merkungen zu nummerieren und f r vieles andere mehr.
Beispiel
Das folgende Beispiel etwa zeigt, wie Markierungen dazu verwendet werden, um Punkte
hinter jeder Nummer einer geordneten Liste einzuf gen. Diese HTML-Datei und das
Stylesheet
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>Creating a list with markers</TITLE>
<STYLE type="text/css">
LI:before {
display: marker;
content: counter(mycounter, lower-roman) ".";
Cascading Style Sheets, Level 2
counter-increment: mycounter;
}
</STYLE>
</HEAD>
<BODY>
<OL>
<LI> Das erste Element.
<LI> Das zweite Element.
<LI> Das dritte Element.
</OL>
</BODY>
</HTML>
sollte etwa Folgendes erzeugen:
i. Das erste Element.
ii. Das zweite Element.
iii. Das dritte Element.
Markierungen (Marker) und Listen < 697 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Mit abgeleiteten Selektoren und untergeordneten Selektoren (siehe Abschnitte 5.5 und 5.6) ist
es m=glich, unterschiedliche Markierungstypen anzugeben, abh@ngig von der Tiefe der eingebet-
teten Listen.
12.6.1 Markierungen: die Eigenschaft 'marker-offset'
Markierungen werden erzeugt, indem die 'display'-Eigenschaft innerhalb eines :before- oder :af-
ter-Pseudoelements auf 'marker' gesetzt wird. W@hrend der :before- und :after-Inhalt 'block'
und 'inline' Teil der von dem Element erzeugten Haupt-Box ist, wird 'marker'-Inhalt in einer
unabh@ngigen Markierungs-Box außerhalb der Haupt-Box formatiert. Markierungs-Boxen wer-
den als einzelne Zeile formatiert (das heißt als Zeilen-Box), weshalb sie nicht so flexibel wie
Floats sind. Die Markeriungs-Box wird nur erzeugt, wenn die 'content'-Eigenschaft f r das Pseu-
doelement tats@chlich Inhalt erzeugt.
Markierungs-Boxen haben Polsterungen (padding) und Rahmen (border), aber keine R@nder
(margin).
F r das :before-Pseudoelement wird die Grundlinie des Texts in der Markierungs-Box vertikal
an der Grundlinie des Texts in der ersten Zeile des Inhalts der Haupt-Box ausgerichtet. Enth@lt
die Haupt-Box keinen Text, wird die obere @ußere Kante der Markierungs-Box an der oberen
@ußeren Kante der Haupt-Box ausgerichtet. F r das :after-Pseudoelement wird die Grundlinie
des Texts in der Markierungs-Box vertikal an der Grundlinie des Texts in der letzten Inhalts-
zeile der Inhalts-Box ausgerichtet. Enth@lt die Haupt-Box keinen Text, wird die untere @ußere
Kante der Markierungs-Box an der unteren @ußeren Kante der Haupt-Box ausgerichtet.
Die H=he einer Markierungs-Box wird durch die Eigenschaft 'line-height' festgelegt. Die :befo-
re- (:after-) Markierungs-Box wird in der H=henberechnung der ersten (letzten) Zeilen-Box
der Haupt-Box ber cksichtigt. Markierungen werden also an der ersten und letzten Zeile eines
Elementinhalts ausgerichtet, selbst wenn sich die Markierungs-Boxen in unterschiedlichen Zei-
len-Boxen befinden. Falls es in einer Haupt-Box keine erste oder letzte Zeilen-Box gibt, richtet
die Markierungs-Box selbst eine Zeilen-Box ein.
Cascading Style Sheets, Level 2
Die vertikale Ausrichtung einer Markierungs-Box innerhalb ihrer Zeilen-Box wird mit Hilfe der
Eigenschaft 'vertical-align' festgelegt.
Ist der Wert der 'width'-Eigenschaft gleich 'auto', dann ist die Inhaltsbreite der Markierungs-
Box gleich der des Inhalts, andernfalls ist sie gleich dem Wert von 'width'. F r Werte von
'width' kleiner als die Inhaltsbreite gibt die 'overflow'-Eigenschaft das berlaufverhalten an.
Markierungs-Boxen k=nnen Haupt-Boxen berlappen. F r Werte von 'width' gr=ßer der
Inhaltsbreite gibt die Eigenschaft 'text-align' die horizontale Ausrichtung des Inhalts in der Mar-
kierungs-Box an.
Die Eigenschaft 'marker-offset' gibt den horizontalen Offset zwischen einer Markierungs-Box
und der zugeh=rigen Haupt-Box an. Der Abstand wird zwischen ihren am n@chsten beieinander
liegenden Rahmenkanten gemessen. Hinweis: Wenn eine Markierung rechts eines Floats in
einem von links nach rechts formatierenden Kontext verl@uft, fließt die Haupt-Box an der rech-
ten Seite des Floats vorbei, w@hrend die Markierungs-Box links vom Float erscheint. Weil die
linke Rahmenkante der Haupt-Box links von dem Float liegt (lesen Sie dazu die Beschreibung
von Floats) und die Markierungs-Boxen außerhalb der Rahmenkante der Haupt-Box liegen, liegt
die Markierung ebenfalls links von dem Float. Ein analoges Verhalten ergibt sich f r die Forma-
tierung von rechts nach links, wenn eine Markierung links von einem Float vorbeil@uft.
< 698 > Erzeugter Inhalt, automatische Nummerierung, Listen
Page size: 168,00 x 240,00 mm
Wenn die Eigenschaft 'display' den Wert 'marker' f r den von einem Element mit 'display:
list-item' erzeugten Inhalt hat, ersetzt eine f r ':before' erzeugte Markierungs-Box die normale
Listenelementmarkierung.
Beispiel
Im folgenden Beispiel wird der Inhalt innerhalb einer Markierungs-Box einer festen
Breite zentriert. Das folgende Dokument
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>Inhaltsausrichtung in der Markierungs-Box</TITLE>
<STYLE type="text/css">
LI:before {
display: marker;
content: "(" counter(counter) ")";
counter-increment: counter;
width: 6em;
text-align: center;
}
</STYLE>
</HEAD>
<BODY>
<OL>
<LI> Das erste Element.
<LI> Das zweite Element.
<LI> Das dritte Element.
</OL>
</BODY>
</HTML>
sollte etwa Folgendes erzeugen:
Cascading Style Sheets, Level 2
(1) Das erste
Element.
(2) Das zweite
Element.
(3) Das dritte
Element.
Das n@chste Beispiel erzeugt Markierungen vor und nach den Listeneintr@gen.
Beispiel
Das Dokument
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>Markers before and after list items</TITLE>
Markierungen (Marker) und Listen < 699 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<STYLE type="text/css">
@media screen, print {
LI:before {
display: marker;
content: url("[Link]");}
LI:after {
display: marker;
content: url("[Link]");
}
}
</STYLE>
</HEAD>
<BODY>
<UL>
<LI>first list item comes first
<LI>second list item comes second
</UL>
</BODY>
</HTML>
sollte ungef@hr Folgendes erzeugen (hier ersetzen ASCII-Kunstwerke die Smiley-GIFs):
:-) first list item
comes first :-(
:-) second list item
comes second :-(
Das folgende Beispiel verwendet Markierungen, um Bemerkungen zu nummerieren.
Beispiel
Das Dokument
Cascading Style Sheets, Level 2
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>Markers to create numbered notes4>/TITLE>
<STYLE type="text/css">
P { margin-left: 12 em; }
@media screen, print {
[Link]:before {
display: marker;
content: url("[Link]")
"Note " counter(note-counter) ":";
counter-increment: note-counter;
text-align: left;
width: 10em;
}
}
</STYLE>
</HEAD>
< 700 > Erzeugter Inhalt, automatische Nummerierung, Listen
Page size: 168,00 x 240,00 mm
<BODY>
<P>This is the first paragraph in this document.</P>
<P CLASS="Note">This is a very short document.</P>
<P>This is the end.</P>
</BODY>
</HTML>
sollte ungef@hr Folgendes produzieren:
This is the first paragraph
in this document.
Note 1: This is a very short
document.
This is the end.
'marker-offset'
Wert: <length> | auto | inherit
Ausgangswert: Auto
Angewendet auf: Elemente mit 'display: marker'
Vererbt: Nein
Prozentwerte: N/A
Medium: Visual
Diese Eigenschaft gibt den Abstand zwischen der n@chstliegenden Rahmenkanten einer Markie-
rungs-Box und der zugeh=rigen Haupt-Box an. Der Abstand kann entweder benutzerspezifisch
Cascading Style Sheets, Level 2
(<length>) oder vom Benutzerprogramm ('auto') gew@hlt sein. L@ngen k=nnen negativ sein,
aber es gibt von der Implementierung abh@ngige Obergrenzen.
Beispiel
Das folgende Beispiel zeigt, wie Markierungen dazu verwendet werden k=nnen, um
Punkte nach jedem nummerierten Listenelement einzuf gen. Das nachfolgende HTML-
Programm und Stylesheet
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<TITLE>Markierungsbeispiel 5</TITLE>
<STYLE type="text/css">
P { margin-left: 8em } /* Platz fUr Z]hler schaffen */
LI:before {
display: marker;
marker-offset: 3em;
content: counter(mycounter, lower-roman) ".";
Markierungen (Marker) und Listen < 701 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
counter-increment: mycounter;
}
</STYLE>
</HEAD>
<BODY>
<P> Ein langer vorhergehender Absatz....
<OL>
<LI> Das erste Element.
<LI> Das zweite Element.
<LI> Das dritte Element.
</OL>
<P> Ein langer nachfolgender Absatz...
</BODY>
</HTML>
sollte etwa Folgendes erzeugen:
Ein langer vorhergehender
Absatz ...
i. Das erste Element.
ii. Das zweite Element.
iii. Das dritte Element.
Ein langer nachfolgender
Absatz ...
12.6.2 Listen: die Eigenschaften 'list-style-type', 'list-style-image',
'list-style-position' und 'list-style'
Die Listeneigenschaften erlauben eine grundlegende visuelle Formatierung von Listen. Wie bei
allgemeineren Markierungen erzeugt ein Element mit 'display: list-item' eine Haupt-Box f r den
Elementinhalt und eine optionale Markierungs-Box. Die anderen Listeneigenschaften erlauben
Cascading Style Sheets, Level 2
den Autoren, den Markierungstyp anzugeben (Bild, Glyphen oder Nummer) sowie die Position
relativ zur Haupt-Box (außerhalb davon oder innerhalb davon vor dem Inhalt). Sie erlauben es
den Autoren jedoch nicht, unterschiedliche Stile (Farben, Schriften, Ausrichtung und so weiter)
f r die Listenmarkierung anzugeben oder ihre Position relativ zur Haupt-Box anzupassen.
Wird dar ber hinaus eine Markierung M (erzeugt mit 'display: marker') f r ein durch die Listen-
eigenschaften erzeugtes Listenelement verwendet, ersetzt M die Standard-Listenelementmar-
kierung.
< 702 > Erzeugter Inhalt, automatische Nummerierung, Listen
Page size: 168,00 x 240,00 mm
'list-style-type'
Wert: disc | circle | square | decimal | decimal-leading-zero | lower-
roman | upper-roman | lower-greek | lower-alpha | lower-latin |
upper-alpha | upper-latin | hebrew | armenian | georgian |
cjk-ideographic | hiragana | katakana | hiragana-iroha |
katakana-iroha | none | inherit
Ausgangswert: Disc
Angewendet auf: Elemente mit ''display: list-item'
Vererbt: Ja
Prozentwerte: N/A
Medium: Visual
Diese Eigenschaft gibt das Erscheinungsbild der Listenelementmarkierung an, wenn 'list-style-
image' den Wert 'none' hat oder wenn das Bild, auf das die URI verweist, nicht angezeigt wer-
den kann. Der Wert 'none' spezifiziert keine Markierung, andernfalls gibt es drei Typen von
Markierungen: Glyphen, Nummerierungssysteme und alphabetische Systeme. Hinweis: Num-
merierte Listen verbessern den Zugriff auf ein Dokument, weil es damit einfacher wird, sich
innerhalb von Listen zu orientieren.
Glyphen werden mit disc, circle und square angegeben. Die genaue Darstellung ist vom
Benutzerprogramm abh@ngig.
Nummerierungssysteme werden wie folgt spezifiziert:
decimal
Dezimalzahlen, beginnend mit 1.
decimal-leading-zero
Cascading Style Sheets, Level 2
Dezimalzahlen, denen, wenn sie einstellig sind, eine Null vorangestellt wird (z. B. 01, 02, 03,
..., 98, 99).
lower-roman
Kleine r=mische Zahlen (i, ii, iii, iv, v usw.)
upper-roman
Große r=mische Zahlen (I, II, III, IV, V usw.)
hebrew
Traditionelle hebr@ische Nummerierung (Alef, Bet, ... Tet Vav, Tet Zayin, ... Yod Tet, Kaf ...).
georgian
Traditionelle georgianische Nummerierung (an, ban, gan, ..., he, tan, in, in-an, ...).
armenian
Traditionelle armenische Nummerierung.
cjk-ideoraphic
Einfache ideographische Nummern.
hiragana
a, i, u, e, o, ka, ki, ...
katakana
A, I, U, E, O, KA, KI, ...
Markierungen (Marker) und Listen < 703 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
hiragana-iroha
i, ro, ha, ni, ho, he, to, ...
katakana-iroha
I, RO, HA, NI, HO, HE, TO, ...
Ein Benutzerprogramm, das ein Nummerierungssymbol nicht erkennt, sollte 'decimal' verwen-
den.
Hinweis: Dieses Dokument gibt keinen genauen Mechanismus f r die einzelnen Nummerie-
rungssymbole an (z. B. wie r=mische Nummern berechnet werden). Eine zuk nftige W3C-Spe-
zifikation enth@lt m=glicherweise weitere Informationen zu diesem Thema. n
Alphabetische Systeme werden wie folgt spezifiziert:
lower latin oder lower-alpha
ASCII-Kleinbuchstaben (a, b, c, ..., z).
upper-latin oder upper-alpha
ASCII-Großbuchstaben (A, B, C, ..., Z)
lower-greek
Kleine klassische griechische Buchstaben, Alpha, Beta, Gamma, ...(a, b, g, ...)
Diese Spezifikation definiert nicht, wie alphabetische Systeme am Ende des Alphabets fort-
gesetzt werden. Nach 26 Listenelementen ist beispielsweise die Darstellung von 'lower-latin'
nicht definiert. F r lange Listen empfehlen wir den Autoren deshalb, echte Nummern anzuge-
ben.
Beispiel
Das folgende HTML-Dokument
Cascading Style Sheets, Level 2
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>Nummerierung mit kleinen lateinischen Zahlen</TITLE>
<STYLE type="text/css">
OL { list-style-type: lower-roman }
</STYLE>
</HEAD>
<BODY>
<OL>
<LI> Erstes Element.
<LI> Zweites Element.
<LI> Drittes Element.
</OL>
</BODY>
</HTML>
k=nnte etwa Folgendes erzeugen:
i Erstes Element.
ii Zweites Element.
iii Drittes Element.
< 704 > Erzeugter Inhalt, automatische Nummerierung, Listen
Page size: 168,00 x 240,00 mm
Beachten Sie, dass die Ausrichtung dieser Listenmarkierungen (hier rechts ausgerichtet) vom
Benutzerprogramm abh@ngig ist.
Zuk nftige Versionen von CSS stellen m=glicherweise vollst@ndigere Mechanismen f r interna-
tionale Nummerierungssysteme bereit. n
'list-style-image'
Wert: <uri> | none | inherit
Ausgangswert: None
Angewendet auf: Elemente mit ''display: list-item'
Vererbt: Ja
Prozentwerte: N/A
Medium: Visual
Diese Eigenschaft legt das Bild fest, das als Listenelementmarkierung verwendet wird. Wenn
das Bild zur Verf gung steht, ersetzt es die Markierung, die mit der Markierung 'list-style-type'
festgelegt wurde.
Beispiel
Das folgende Beispiel setzt die Markierung am Anfang jedes Listenelements auf das Bild
„[Link]“.
UL { list-style-image: url("[Link] }
Cascading Style Sheets, Level 2
'list-style-position'
Wert: inside | outside | inherit
Ausgangswert: Outside
Angewendet auf: Elemente mit ''display: list-item'
Vererbt: Ja
Prozentwerte: N/A
Medium: Visual
Diese Eigenschaft gibt die Position der Markierungs-Box in der Hauptblock-Box an. Die Werte
haben die folgenden Bedeutungen:
Markierungen (Marker) und Listen < 705 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
outside
Die Markierungs-Box liegt außerhalb der Hauptblock-Box. Hinweis: CSS1 hat die genaue
Position der Markierungs-Box nicht angegeben, und aus Kompatibilit@tsgr nden bleibt CSS2
@hnlich mehrdeutig. Um eine genauere Kontrolle ber die Markierungs-Boxen zu gewinnen,
verwenden Sie bitte Markierungen.
inside
Die Markierungs-Box ist die erste inzeilige Box in der Hauptblock-Box, welcher der Ele-
mentinhalt folgt.
Beispiel
<HTML>
<HEAD>
<TITLE>Comparison of inside/outside position</TITLE>
<STYLE type="text/css">
UL { list-style: outside }
[Link] { list-style: inside }
</STYLE>
</HEAD>
<BODY>
<UL>
<LI>first list item comes first
<LI>second list item comes second
</UL>
<UL class="compact">
<LI>first list item comes first
<LI>second list item comes second
</UL>
</BODY>
</HTML>
Das obige Beispiel k=nnte wie folgt formatiert werden:
Cascading Style Sheets, Level 2
< 706 > Erzeugter Inhalt, automatische Nummerierung, Listen
Page size: 168,00 x 240,00 mm
In einem Text, der von rechts nach links verl@uft, befinden sich die Markierungen auf der rech-
ten Seite des Rahmens.
'list-style'
Wert: [<'list-style-type'> | | <'list-style-position'> | | <'list-style-image'> ] |
Ausgangswert: F r zusammenfassende Eigenschaften nicht definiert.
Angewendet auf: Elemente mit ''display: list-item'
Vererbt: Ja
Prozentwerte: N/A
Medium: Visual
Die Eigenschaft 'list-style' ist eine zusammenfassende Notation, mit der die drei Eigenschaften
'list-style-type', 'list-style-image' und 'list-style-position' an einer einzigen Stelle im Stylesheet
festgelegt werden.
Beispiel
UL { list-style: upper-roman inside } /* Jede UL */
UL UL { list-style: circle outside } /* Jeder UL-Nachfahre einer UL */
Obwohl Autoren die 'list-style'-Information direkt f r Listenelemente angeben k=nnen (z. B. LI
in HTML), sollte das mit Vorsicht erfolgen. Die folgenden Regeln sehen ganz @hnlich aus, aber
die erste deklariert einen abgeleiteten Selektor, die zweite dagegen einen (spezifischeren)
untergeordneten Selektor.
Cascading Style Sheets, Level 2
Beispiel
[Link] LI { list-style: lower-alpha } /* Jeder LI-Nachfahre einer OL */
[Link] > LI { list-style: lower-alpha } /* Jedes LI-Kind einer OL */
Autoren, die nur den abgeleiteten Selektor verwenden, erzielen damit vielleicht nicht die
erwarteten Ergebnisse. Betrachten Sie die folgenden Regeln:
<HTML>
<HEAD>
<TITLE>WARNUNG: Unerwartete Ergebnisse aufgrund der Kaskade</TITLE>
<STYLE type="text/css">
[Link] LI { list-style: lower-alpha }
UL LI { list-style: disc }
</STYLE>
</HEAD>
<BODY>
<OL class="alpha">
<LI>level 1
<UL>
<LI>level 2
</UL>
Markierungen (Marker) und Listen < 707 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
</OL>
</BODY>
</HTML>
Die gew nschte Darstellung h@tte Listenelemente der Ebene 1 mit 'lower-alpha'-Beschrifungen und
Elemente der Ebene 2 mit 'disc'-Beschriftungen. Die kaskadierende Reihenfolge bewirkt, dass die
erste Stilregel (die spezifische Klasseninformationen enth@lt) die zweite verdeckt. Die folgenden
Regeln l=sen dieses Problem, indem sie statt dessen den untergeordneten Selektor verwenden:
[Link] > LI { list-style: lower-alpha }
UL LI { list-style: disc }
Eine weitere L=sung best nde darin, die 'list-style'-Information nur f r die Listentypelemente anzugeben:
[Link] { list-style: lower-alpha }
UL { list-style: disc }
Vererbung bertr@gt die 'list-style'-Werte von den OL- und UL-Elementen an die LI-Elemente.
Das ist die empfohlene Vorgehensweise zur Angabe der Listenstilinformation.
Ein URI-Wert kann mit einem beliebigen anderen Wert kombiniert werden, wie beispielsweise in:
UL { list-style: url("[Link] disc }
Im obigen Beispiel wird 'disc' verwendet, wenn das Bild nicht zur Verf gung steht.
Der Wert 'none' f r die 'list-style'-Eigenschaft setzt sowohl 'list-style-type' als auch 'list-style-
image' auf 'none':
UL { list-style: none }
Das Ergebnis ist, dass keine Markierung f r die Listenelemente angezeigt wird.
Cascading Style Sheets, Level 2
13 Seitenmedien
13.1 Einf-hrung in Seitenmedien
Seitenmedien (Paged Media; zum Beispiel Papier, Folien, Seiten, die auf Computerbildschirmen
angezeigt werden und so weiter) unterscheiden sich von Endlosmedien, weil der Inhalt des
Dokuments auf eine oder mehrere einzelne Seiten verteilt ist. Um Seitenumbr che zu verarbei-
ten, erweitert CSS2 das visuelle Formatierungsmodell wie folgt:
1. Die Seiten-Box erweitert das Box-Modell, so dass Autoren die Gr=ße einer Seite, ihre R@n-
der usw. angeben k=nnen.
2. Das Seitenmodell erweitert das visuelle Formatierungsmodell, um Seitenumbr che zu
ber cksichtigen.
Das CSS2-Seitenmodell gibt an, wie ein Dokument innerhalb eines rechteckigen Bereichs – der
Seiten-Box – formatiert wird, der eine feste Breite und H=he aufweist. Die Seiten-Box ent-
spricht nicht unbedingt einem realen Blatt, auf dem das Dokument schließlich ausgegeben wird
< 708 > Seitenmedien
Page size: 168,00 x 240,00 mm
(Papier, Folie, Bildschirm usw.). Das CSS-Seitenmodell spezifiziert die Formatierung in der Sei-
ten-Box, aber das Benutzerprogramm ist daf r verantwortlich, die Seiten-Box auf das Blatt zu
bertragen. Einige bertragungsm=glichkeiten seien an dieser Stelle genannt:
·· bertragung einer Seiten-Box auf ein Blatt (zum Beispiel einseitiger Druck).
bertragung von zwei Seiten-Boxen auf Vorder- und R ckseite desselben Blatts (zum Bei-
spiel doppelseitiger Druck).
·· bertragung von N (kleinen) Seiten-Boxen auf ein Blatt (auch als „n-up“ bezeichnet).
bertragung einer (großen) Seiten-Box auf N x M Bl@tter (auch als „tiling“ bezeichnet).
· Anlegen von Signaturen. Eine Signatur ist eine Gruppe von Seiten, die auf ein Blatt aus-
gedruckt werden, die, wenn das Blatt gefaltet und wie ein Buch geschnitten wird, in der
richtigen Reihenfolge erscheinen.
·· Ausdruck eines Dokuments in mehrere Ausgabesch@chte.
Ausgabe in eine Datei.
Obwohl CSS2 nicht angibt, wie die Benutzerprogramme Seiten-Boxen bertragen, enth@lt es
bestimmte Mechanismen, die den Benutzerprogrammen Informationen ber die Gr=ße und die
Ausrichtung des Zielblatts mitteilen.
13.2 Seiten-Boxen: die @page -Regel
Die Seiten-Box ist ein rechteckiger Bereich, der aus zwei Einzelbereichen besteht:
· Dem Seitenbereich. Der Seitenbereich beinhaltet die Boxen, die auf dieser Seite angelegt
sind. Die Kanten des Seitenbereichs dienen als erster umschließender Block f r Layout, das
zwischen Seitenumbr chen stattfindet.
· Der Randbereich, der den Seitenbereich umgibt.
Hinweis: In CSS2 beziehen sich die Rahmeneigenschaften und die Auff llungseigenschaften nicht
auf Seiten, was jedoch in Zukunft m=glicherweise der Fall sein wird. n
Cascading Style Sheets, Level 2
Autoren geben die Gr=ße, die Ausrichtung, die R@nder usw. einer Seiten-Box innerhalb einer
@page-Regel an. Eine @page-Regel besteht aus dem Schl sselwort "@page", einem Seiten-
selektor (ohne dazwischenliegende Leerzeichen, gefolgt von einer optionalen Seiten-Pseudo-
klasse) und einem Deklarationsblock (der sich im so genannten Seitenkontext befindet).
Der Seitenselektor gibt an, f r welche Seiten die Deklaration angewendet werden soll. In CSS2
k=nnen Seitenselektoren die erste Seite, alle linken Seiten, alle rechten Seiten oder eine Seite
mit einem bestimmten Namen ansprechen.
Die Gr=ße der Seiten-Box wird mit der Eigenschaft 'size' festgelegt. Die Gr=ße des Seiten-
bereichs ist die Gr=ße der Seiten-Box minus dem Randbereich.
Beispiel
Die folgende @page-Regel beispielsweise setzt die Gr=ße der Seiten-Box auf 8,5 x 11
Zoll und erzeugt '2cm' Rand auf allen Seiten zwischen der Kante der Seiten-Box und
dem Seitenbereich:
@page { size 8.5in 11in; margin: 2cm }
Seiten-Boxen: die @page -Regel < 709 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Die Eigenschaft 'marks' in einer @page-Regel gibt Schnitt- und Kreuzmarkierungen f r die Sei-
ten-Box an.
13.2.1 [Link]
Die Randeigenschaften ('margin-top', 'margin-right', 'margin-bottom', 'margin-left' und 'margin')
gelten innerhalb des Seitenkontexts. Die folgende Abbildung zeigt die Beziehungen zwischen
dem Blatt, der Seiten-Box und den Seitenr@ndern:
Cascading Style Sheets, Level 2
Der berechnete Wert der Box-R@nder oben und unten auf dem Seitenbereich betr@gt '0'.
Der Seitenkontext besitzt kein Konzept f r Schriften, deshalb sind die Einheiten 'em' und 'ex'
nicht erlaubt. Prozentwerte f r die Randeigenschaften sind relativ zur Gr=ße der Seiten-Box;
f r linke und rechte R@nder beziehen sie sich auf die Breite der Seiten-Box, w@hrend sie sich
f r obere und untere R@nder auf die H=he der Seiten-Box beziehen. Alle anderen Einheiten,
die den betreffenden CSS2-Eigenschaften zugeordnet sind, sind erlaubt.
Negative Randwerte (entweder auf der Seiten-Box oder f r Elemente) oder die absolute Posi-
tionierung von Inhalt k=nnen dazu f hren, dass Inhalt außerhalb der Seiten-Box angeordnet ist,
aber dieser Inhalt kann „zugeschnitten“ werden – vom Benutzerprogramm, dem Drucker oder
letztlich dem Papierschneider.
< 710 > Seitenmedien
Page size: 168,00 x 240,00 mm
13.2.2 SeitengrUße : die Eigenschaft 'size'
'size'
Wert: <length>{1,2} | auto | portrait | landscape | inherit
Ausgangswert: Auto
Angewendet auf: den Seitenkontext
Vererbt: N/A
Prozentwerte: N/A
Medium: Visual, Paged
Diese Eigenschaft gibt die Gr=ße und die Ausrichtung einer Seiten-Box an.
Die Gr=ße einer Seiten-Box kann entweder „absolut“ (mit fester Gr=ße) oder „relativ“ (ska-
lierbar, das heißt in die verf gbare Blattgr=ße eingepasst) sein. Relative Seiten-Boxen erlauben
den Benutzerprogrammen, ein Dokument zu skalieren, und verwenden die Zielgr=ße optimal.
Drei Werte f r die 'size'-Eigenschaft erzeugen eine relative Seiten-Box:
auto
Die Seiten-Box wird auf die Gr=ße und die Ausrichtung des Zielblatts gesetzt.
landscape
berschreibt die Zielausrichtung. Die Seiten-Box hat dieselbe Gr=ße wie das Ziel, und die
l@ngeren Seiten sind horizontal ausgerichtet.
portrait
berschreibt die Zielausrichtung. Die Seiten-Box hat dieselbe Gr=ße wie das Ziel, und die
k rzeren Seiten sind horizontal ausgerichtet.
Cascading Style Sheets, Level 2
Beispiel
Im folgenden Beispiel werden die @ußeren Kanten der Seiten-Box am Ziel ausgerichtet.
Der Prozentwert der 'margin'-Eigenschaft ist relativ zur Zielgr=ße, wenn also das Ziel-
blatt 21,0 cm x 29,7 cm groß ist (A4), sind die R@nder 2,10 cm und 2,97 cm.
@page {
size: auto; /* auto is the initial value */
margin: 10%;
}
L@ngenwerte f r die 'size'-Eigenschaft erzeugen eine absolute Seiten-Box. Wird nur ein L@ngen-
wert angegeben, legt er sowohl die Breite als auch die H=he der Seiten-Box fest (das heißt bei
der Box handelt es sich um ein Quadrat). Weil es sich bei der Seiten-Box um einen umschlie-
ßenden Anfangsblock handelt, sind Prozentwerte f r die 'size'-Eigenschaft nicht erlaubt.
Beispiel
@page {
size: 8.5in 11in; /* width height */
}
Seiten-Boxen: die @page -Regel < 711 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Das obige Beispiel setzt die Breite der Seiten-Box auf 8,5 Zoll, die H=he auf 11 Zoll. Die Seiten-
Box in diesem Beispiel ben=tigt eine Zielblattgr=ße von 8,5" x 11" oder gr=ßer.
Benutzerprogramme k=nnen den Benutzern erlauben, die bertragung der Seiten-Box auf das
Blatt zu steuern (zum Beispiel eine Drehung einer absoluten Seiten-Box, die ausgedruckt wird).
Darstellung von Seiten-Boxen, die nicht auf ein Zielblatt passen
Falls eine Seiten-Box nicht auf das Zielblatt passt, kann das Benutzerprogramm die folgenden
Maßnahmen treffen:
·· Drehen der Seiten-Box um 90v, vorausgesetzt, die Seiten-Box passt dann.
Skalieren der Seite, so dass sie auf das Ziel passt.
Bevor das Benutzerprogramm diese Operationen ausf hrt, sollte es sich mit dem Benutzer
abstimmen.
Positionierung der Seiten-Box auf dem Blatt
Wenn die Seiten-Box kleiner als die Zielgr=ße ist, kann das Benutzerprogramm sie irgendwo
auf dem Blatt platzieren. Es wird jedoch empfohlen, dass die Seiten-Box auf dem Blatt zentriert
wird, weil damit doppelseitige Seiten ausgerichtet werden und ein versehentlicher Informa-
tionsverlust vermieden wird, wenn nahe der Kante eines Blatts gedruckt wird.
13.2.3 Schnittmarkierungen: die 'marks'-Eigenschaft
'marks'
Wert: [ crop | | cross ] | none | inherit
Ausgangswert: None
Angewendet auf: Seitenkontext
Cascading Style Sheets, Level 2
Vererbt: N/A
Prozentwerte: N/A
Medium: Visual, Paged
Bei einem hochqualitativen Druck werden die Markierungen h@ufig außerhalb der Seiten-Box
angegeben. Diese Eigenschaft gibt an, ob Kreuzmarkierungen (Cross) oder Schnittmarkierun-
gen (Crop) oder beides außerhalb der Kanten der Seiten-Box ausgegeben werden sollen.
Schnittmarkierungen zeigen, wo die Seite geschnitten werden soll. Kreuzmarkierungen (auch als
Register- oder Registrierungsmarkierungen bezeichnet) werden f r die Ausrichtung von Bl@t-
tern verwendet.
Markierungen sind nur auf absoluten Seiten-Boxen sichtbar (siehe auch 'size'-Eigenschaft). In
relativen Seiten-Boxen wird die Seiten-Box am Ziel ausgerichtet und die Markierungen befin-
den sich außerhalb des druckbaren Bereichs.
Die Gr=ße, der Stil und die Position der Kreuzmarkierungen ist vom Benutzerprogramm
abh@ngig.
< 712 > Seitenmedien
Page size: 168,00 x 240,00 mm
13.2.4 Linke, rechte und erste Seiten
Beim Ausdruck von doppelseitigen Dokumenten sollten sich die Seiten-Boxen auf linken und
rechten Seiten unterscheiden. Das kann durch zwei CSS-Pseudoklassen ausgedr ckt werden,
die im Seitenkontext definiert werden k=nnen.
Alle Seiten werden automatisch vom Benutzerprogramm in die Pseudoklassen :left oder :right
eingeordnet.
@page :left {
margin-left: 4cm;
margin-right: 3cm;
}
@page :right {
margin-left: 3cm;
margin-right: 4cm;
}
Wurden f r linke und rechte Seiten unterschiedliche Deklarationen angegeben, muss das
Benutzerprogramm diese ber cksichtigen, selbst wenn es die Seiten-Boxen nicht auf linke und
rechte Bl@tter bertr@gt (z. B. auf einen Drucker, der nur einen einseitigen Druck unterst tzt).
Mit der Pseudoklasse :first k=nnen Autoren den Stil f r die erste Seite festlegen:
@page { margin: 2cm } /* Alle R]nder sind auf 2cm gesetzt */
@page :first {
margin-top: 10cm /* Oberer Rand der ersten Seite: 10cm */
}
Ob es sich bei der ersten Seite eines Dokuments um :left oder :right handelt, ist von der
Hauptschreibrichtung des Dokuments abh@ngig und liegt außerhalb des G ltigkeitsbereichs die-
ser Spezifikation. Um jedoch zu erzwingen, dass eine erste Seite :left oder :right ist, k=nnen
Autoren einen Seitenumbruch vor der ersten erzeugten Box einf gen (in HTML z. B. w rde
Cascading Style Sheets, Level 2
dies f r das BODY-Element angegeben).
Eigenschaften, die in einer @page-Regel f r :left (oder :right) angegeben sind, berschreiben
diejenigen aus einer @page-Regel, die keine Pseudoklasse angegeben hat. Eigenschaften, die in
einer @page-Regel f r :first angegeben sind, berschreiben solche aus @page-Regeln f r :left
(oder :right).
Hinweis: Zus@tzliche Deklarationen in den Pseudoklassen :left oder :right haben keine Auswir-
kung darauf, ob das Dokument doppel- oder einseitig aus dem Drucker kommt (was nicht im
Rahmen dieser Spezifikation liegt).
Zuk nftige Versionen von CSS enthalten m=glicherweise andere Seiten-Pseudoklassen. n
13.2.5 Inhalt außerhalb der Seiten-Box
Bei der Formatierung von Inhalt im Seitenmodell kann Inhalt auch außerhalb der Seiten-Box
erscheinen. Beispielsweise k=nnte ein Element, dessen 'white-space'-Eigenschaft den Wert 'pre'
hat, eine Box erzeugen, die breiter als die Seiten-Box ist. Werden die Boxen außerdem absolut
positioniert, k=nnte das zu „unpraktischen“ Positionen f hren. Beispielsweise k=nnten Bilder
an der Kante der Seiten-Box oder 100.000 cm unterhalb der Seiten-Box platziert werden.
Seiten-Boxen: die @page -Regel < 713 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Die exakte Formatierung solcher Elemente kann im Rahmen dieser Spezifikation nicht fest-
gelegt werden. Wir empfehlen jedoch, dass sich Autoren und Benutzerprogramme an die fol-
genden allgemeinen Konzepte halten, die sich auf Inhalt außerhalb der Seiten-Box beziehen:
· Inhalt sollte auch etwas ber die Seiten-Box hinaus erlaubt werden, so dass die Seiten „aus-
laufen“.
· Benutzerprogramme sollten vermeiden, eine große Anzahl leerer Seiten-Boxen zu erzeu-
gen, um die Positionierung von Elementen zu ber cksichtigen (Sie wollen z. B. nicht 100
leere Seiten ausdrucken). Beachten Sie jedoch, dass es erforderlich sein k=nnte, eine kleine
Anzahl leerer Seiten-Boxen zu erzeugen, um die 'left'- und 'right'-Werte f r 'page-break-be-
fore' und 'page-break-after' zu ber cksichtigen.
· Autoren sollten keine Elemente an unpraktischen Positionen positionieren, nur um zu ver-
meiden, sie darzustellen. Stattdessen: Um das Erstellen von Boxen vollst@ndig zu unterdr -
cken, setzen Sie die 'display'-Eigenschaft auf 'none'. Um eine Box unsichtbar zu machen, ver-
wenden Sie die 'visibility'-Eigenschaft.
· Benutzerprogramme k=nnen Boxen, die sich außerhalb der Seiten-Box befinden, unter-
schiedlich verarbeiten, sie beispielsweise verwerfen oder Seiten-Boxen am Ende des Doku-
ments daf r erzeugen.
13.3 Seitenumbr-che
Die folgenden Abschnitte erkl@ren die Seitenformatierung in CSS. F nf Eigenschaften geben an,
ob das Benutzerprogramm Seitenumbr che vornehmen darf oder soll, und auf welcher Seite
(links oder rechts) der nachfolgende Inhalt fortgesetzt werden soll. Jeder Seitenumbruch been-
det das Layout in der aktuellen Seiten-Box und bewirkt, dass verbleibende Teile des Doku-
mentbaums in einer neuen Seiten-Box angelegt werden.
13.3.1 Umbruch vor/nach Elementen: 'page-break-before',
'page-break-after', 'page-break-inside'
Cascading Style Sheets, Level 2
'page-break-before'
Wert: auto | always | avoid | left | right | inherit
Ausgangswert: Auto
Angewendet auf: Elemente auf Blockebene
Vererbt: Nein
Prozentwerte: N/A
Medium: Visual, Paged
< 714 > Seitenmedien
Page size: 168,00 x 240,00 mm
'page-break-after'
Wert: auto | always | avoid | left | right | inherit
Ausgangswert: Auto
Angewendet auf: Elemente auf Blockeben
Vererbt: Nein
Prozentwerte: N/A
Medium: Visual, Paged
'page-break-inside'
Wert: avoid | auto | inherit
Ausgangswert: Auto
Angewendet auf: Elemente auf Blockebene
Vererbt: Ja
Prozentwerte: N/A
Medium: Visual, Paged
Die Werte f r diese Eigenschaften haben die folgenen Bedeutungen:
auto
Ein Seitenumbruch vor (nach, innerhalb) der erzeugten Box wird weder erzwungen noch
verboten.
always
Cascading Style Sheets, Level 2
Vor (hinter) der erzeugten Box wird immer ein Seitenumbruch erzwungen.
avoid
Ein Seitenumbruch vor (nach, innerhalb) der erzeugten Box wird vermieden.
left
Vor (nach) der erzeugten Box werden ein oder zwei Seitenumbr che erzwungen, so dass
die n@chste Seite als linke Seite formatiert wird.
right
Vor (nach) der erzeugten Box werden ein oder zwei Seitenumbr che erzwungen, so dass
die n@chste Seite als rechte Seite formatiert wird.
Eine m=gliche Seitenumbruchposition wird normalerweise von der 'page-break-inside'-Eigen-
schaft des bergeordneten Elements, der 'page-break-after'-Eigenschaft des vorhergehenden
Elements und der 'page-break-before'-Eigenschaft des nachfolgenden Elements beeinflusst.
Wenn diese Eigenschaften andere Werte als 'auto' haben, haben die Werte 'always', 'left' und
'right' Priorit@t gegen ber 'avoid'. Weitere Informationen ber die genauen Regeln, wie diese
Eigenschaften einen Seitenumbruch erzwingen oder unterdr cken finden Sie im Abschnitt ber
erlaubte Seitenumbr che (13.3.4).
Seitenumbr#che < 715 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
13.3.2 Benannte Seiten verwenden: 'page'
'page'
Wert: <identifier> | auto
Ausgangswert: Auto
Angewendet auf: Elemente auf Blockebene
Vererbt: Ja
Prozentwerte: N/A
Medium: Visual, Paged
Die 'page'-Eigenschaft kann dazu verwendet werden, einen bestimmten Seitentyp anzugeben,
auf dem ein Element angezeigt werden soll.
Beispiel
Dieses Beispiel platziert alle Tabellen auf einer rechten horizontalen Seite (namens
"rotated"):
@page rotated {size: landscape}
TABLE {page: rotated; page-break-before: right}
Die 'page'-Eigenschaft funktioniert wie folgt: Wenn eine Block-Box mit Inline-Inhalt eine 'pa-
ge'-Eigenschaft hat, die sich von der der vorherigen Block-Box mit Inline-Inhalt unterscheidet,
werden ein oder zwei Seitenumbr che zwischen ihnen eingef gt, und die Boxen hinter dem
Umbruch werden auf einer Seiten-Box des angegebenen Typs dargestellt. Weitere Informa-
tionen finden Sie im Abschnitt „Erzwungene Seitenumbr che“, sp@ter in diesem Kapitel.
Cascading Style Sheets, Level 2
Beispiel
In diesem Beispiel werden die beiden Tabellen auf horizontal ausgerichteten Seiten dar-
gestellt (falls sie Platz haben, auf derselben Seite), und der Seitentyp „narrow“ wird
berhaupt nicht verwendet, obwohl er f r DIV gesetzt wurde:
@page narrow {size: 9cm 18cm}
@page rotated {size: landscape}
DIV {page: narrow}
TABLE {page: rotated}
mit diesem Dokument:
<DIV>
<TABLE>...</TABLE>
<TABLE>...</TABLE>
</DIV>
< 716 > Seitenmedien
Page size: 168,00 x 240,00 mm
13.3.3 Umbr-che innerhalb von Elementen: 'Waisen', 'Witwen'
'orphans' (Waisen)
Wert: <integer> | inherit
Ausgangswert: 2
Angewendet auf: Elemente auf Blockebene
Vererbt: Ja
Prozentwerte: N/A
Medium: Visual, Paged
'widows' (Witwen)
Wert: <integer> | inherit
Ausgangswert: 2
Angewendet auf: Elemente auf Blockebene
Vererbt: Ja
Prozentwerte: N/A
Medium: Visual, Paged
Die 'orphans'-Eigenschaft („Waisen“, auch „Schusterjungen“ genannt) gibt an, wie viele Zeilen
eines Abschnitts mindestens unten auf einer Seite noch angezeigt werden m ssen. Die
'widows'-Eigenschaft („Witwen“, auch „Hurenkinder“ genannt) gibt an, wie viele Zeilen eines
Abschnitts oben auf einer Seite mindestens noch angezeigt werden m ssen. Beispiele daf r, wie
Cascading Style Sheets, Level 2
sie verwendet werden, um Seitenumbr che zu steuern, finden Sie nachfolgend.
Weitere Informationen ber die Absatzformatierung finden Sie im Abschnitt ber Zeilen-
Boxen (9.4.2).
13.3.4 Erlaubte Seitenumbr-che
Im normalen Verlauf erfolgen Seitenumbr che an den folgenden Positionen:
1. Im vertikalen Rand zwischen Block-Boxen. Wenn hier ein Seitenumbruch erfolgt, werden
die berechneten Werte der relevanten 'margin-top'- und 'margin-bottom'-Eigenschaften auf
'0' gesetzt.
2. Zwischen Zeilen-Boxen innerhalb einer Block-Box.
Seitenumbr#che < 717 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Diese Zeilenumbr che unterliegen den folgenden Regeln:
Regel A
Ein Umbruch an der Stelle (1) ist erlaubt, wenn die Eigenschaften 'page-break-after' und
'page-break-before' aller Elemente, die Boxen erzeugen, die auf diesen Rand treffen, dies
erlauben, das heißt, wenn mindestens eine den Wert 'always', 'left' oder 'right' hat oder
wenn alle davon auf 'auto' gesetzt sind.
Regel B
Sind alle Eigenschaften 'auto' und der n@chste gemeinsame Vorfahre aller Elemente hat den
'page-break-inside'-Wert 'avoid', ist ein Umbruch hier nicht erlaubt.
Regel C
Ein Umbruch an der Stelle (2) ist nur dann erlaubt, wenn die Anzahl der Zeilen-Boxen zwi-
schen dem Umbruch und dem Anfang der umschließenden Block-Box gleich dem Wert von
'orphans' oder h=her ist und die Anzahl der Zeilen-Boxen zwischen dem Umbruch und
dem Ende der Box gleich dem Wert von 'widows' oder h=her ist.
Regel D
Dar ber hinaus ist ein Umbruch an der Stelle (2) nur dann erlaubt, wenn die 'page-break-
inside'-Eigenschaft gleich 'auto' ist.
Falls die obigen Regeln nicht gen gend Umbr che zulassen, um zu verhindern, dass der Inhalt in
den Seiten-Boxen berl@uft, werden die Regeln B und D verworfen, um zus@tzliche Umbr che
zu finden.
Wenn das immer noch nicht zu ausreichend vielen Umbr chen f hrt, werden auch die Regeln
A und C verworfen, um noch mehr Umbr che zu finden.
Seitenumbr che k=nnen nicht in absolut positionierten Boxen auftreten.
13.3.5 Erzwungene Seitenumbr-che
Cascading Style Sheets, Level 2
Ein Seitenumbruch muss an der Stelle (1) erfolgen, wenn unter den 'page-break-after'- und 'pa-
ge-break-before'-Eigenschaften aller Elemente, die Boxen erzeugen, die diesen Rand ber hren,
es mindestens eine gibt, die den Wert 'always', 'left' oder 'right' hat.
13.3.6 „Beste“ Seitenumbr-che
CSS2 definiert nicht, welcher Seitenumbruch aus einer Menge von erlaubten Seitenumbr chen
verwendet werden muss; CSS2 verbietet einem Benutzerprogramm nicht, an jedem m=glichen
Umbruchpunkt einen Umbruch einzuf gen, und auch nicht, berhaupt keine Umbr che zu ver-
wenden. CSS2 empfiehlt jedoch, dass Benutzerprogramme die folgende Heuristik befolgen
(wobei erkannt werden soll, dass sie manchmal widerspr chlich sind):
·· So wenig wie m=glich umbrechen.
Alle Seiten, die keinen erzwungenen Seitenumbruch haben, sollten mit ungef@hr der glei-
chen H=he erscheinen.
·· Vermeiden von Umbr chen in Bl=cken, die einen Rahmen haben.
Vermeiden von Umbr chen innerhalb einer Tabelle.
· Vermeiden von Umbr chen innerhalb eines Floating-Elements.
< 718 > Seitenmedien
Page size: 168,00 x 240,00 mm
Beispiel
Angenommen, ein Stylesheet enth@lt 'orphans: 4', 'widows: 2', und unten auf der aktuel-
len Seite stehen 20 Zeilen (Zeilen-Boxen) zur Verf gung:
· Wenn ein Absatz am Ende der aktuellen Seite 20 Zeilen oder weniger enth@lt, sollte
er auf der aktuellen Seite platziert werden.
· Enth@lt der Absatz 21 oder 22 Zeilen, darf der zweite Teil des Absatzes die durch
'widows' vorgegebene Beschr@nkung nicht verletzen, deshalb muss der zweite Teil
genau zwei Zeilen umfassen.
· Enth@lt der Absatz 23 Zeilen oder mehr, sollte der erste Teil 20 Zeilen und der
zweite Teil die restlichen Zeilen enthalten.
Angenommen, 'orphans' ist '10', 'widows' ist '20', und unten auf der aktuellen Seite ste-
hen 8 Zeilen zur Verf gung:
· Enth@lt ein Absatz am Ende der aktuellen Seite 8 Zeilen oder weniger, sollte er auf
der aktuellen Seite platziert werden.
· Enth@lt der Absatz 9 oder mehr Zeilen, darf er nicht geteilt werden (das w rde der
'orphan'-Beschr@nkung widersprechen), deshalb sollte er als Block auf die n@chste
Seite verschoben werden.
13.4 Kaskade im Seitenkontext
Deklarationen im Seitenkontext gehorchen der Kaskade wie normale CSS2-Deklarationen.
Beispiel
Betrachten Sie folgendes Beispiel:
@page {
margin-left: 3cm;
Cascading Style Sheets, Level 2
}
@page :left {
margin-left: 4cm;
}
Weil der Pseudoklassen-Selektor spezifischer ist, ist der linke Rand auf linken Seiten '4cm', und
alle anderen Seiten (d. h. die rechten Seiten) haben einen linken Rand von '3cm'.
14 Farben und Hintergrund
CSS-Eigenschaften gestatten es den Autoren, die Vordergrundfarbe sowie den Hintergrund f r
ein Element festzulegen. Beim Hintergrund kann es sich um Farben oder Bilder handeln. Hinter-
grundeigenschaften erlauben den Autoren, ein Hintergrundbild zu positionieren, es zu wieder-
holen und zu deklarieren, ob es in Hinblick auf den Viewport feststehend sein soll, oder ob es
zusammen mit dem Dokument weitergebl@ttert werden soll.
Eine Beschreibung der Syntax f r g ltige Farbewerte finden Sie im Abschnitt ber Farbeinheiten
(4.3.6).
Kaskade im Seitenkontext < 719 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
14.1 Vordergrundfarbe : die 'color'-Eigenschaft
'color'
Wert: <color> | inherit
Ausgangswert: Vom Benutzerprogramm abh@ngig.
Angewendet auf: Alle Elemente
Vererbt: Ja
Prozents,tze: N/A
Medium: Visual
Diese Eigenschaft beschreibt die Vordergrundfarbe des Textinhalts eines Elements. Es gibt
unterschiedliche M=glichkeiten, rot festzulegen:
EM { color: red } /* vordefinierter Farbname */
EM { color: rgb(255,0,0) } /* RGB-Bereich 0-255 */
14.2 Der Hintergrund
Autoren k=nnen den Hintergrund eines Elements (das heißt, die Oberfl@che, auf der es dar-
gestellt wird) entweder als Farbe oder als Bild festlegen. Beim Box-Modell bezieht sich der „Hin-
tergrund“ auf den Hintergrund der Inhalts- und Polsterbereiche (padding). Rahmenfarben und
-stile werden mit Hilfe der Rahmeneigenschaften festgelegt. R@nder sind immer transparent, so
dass der Hintergrund der bergeordneten Box immer durchscheint.
Hintergrundeigenschaften werden nicht vererbt, aber der Hintergrund der bergeordneten
Box scheint standardm@ßig durch, weil 'background-color' den Ausgangswert 'transparent' hat.
Cascading Style Sheets, Level 2
Der Hintergrund der Box, die vom Wurzelelement erzeugt wurde, bedeckt die gesamte Zei-
chenfl@che.
F r HTML-Dokumente empfehlen wir jedoch, dass die Autoren den Hintergrund f r das
BODY-Element und nicht f r das HTML-Element angeben. Benutzerprogramme sollten beim
Einf gen des Hintergrunds die folgenden Priorit@tsregeln beachten: Wenn der Wert der 'back-
ground'-Eigenschaft f r das HTML-Element nicht 'transparent' ist, wird er verwendet, andern-
falls wird der Wert der 'background'-Eigenschaft f r das BODY-Element verwendet. Ist der
resultierende Wert 'transparent', ist die Darstellung nicht definiert.
Beispiel
Gem@ß diesen Regeln hat die Zeichenfl@che f r das folgende HTML-Dokument einen
marmorierten Hintergrund:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>Einstellen des Hintergrunds fUr die Zeichenfl]che</TITLE>
<STYLE type="text/css">
BODY { background: url("[Link] }
</STYLE>
< 720 > Farben und Hintergrund
Page size: 168,00 x 240,00 mm
</HEAD>
<BODY>
<P>Mein Hintergrund ist Marmor.</P>
</BODY>
</HTML>
14.2.1 Hintergrundeigenschaften : 'background-color',
'background-image', 'background-repeat',
'background-attachment', 'background-position' und
'background'
'background-color'
Wert: <color> | transparent | inherit
Ausgangswert: Transparent
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozents,tze: N/A
Medium: Visual
Diese Eigenschaft legt die Hintergrundfarbe eines Elements fest, entweder als <color>-Wert,
oder mit dem Schl sselwort 'transparent', so dass die darunter liegenden Farben durchschei-
nen.
Beispiel
H1 { background-color: #F00 }
Cascading Style Sheets, Level 2
'background-image'
Wert: <uri> | none |inherit
Ausgangswert: None
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozents,tze: N/A
Medium: Visual
Diese Eigenschaft legt das Hintergrundbild eines Elements fest. Beim Festlegen eines Hinter-
grundbildes sollten die Autoren auch eine Hintergrundfarbe angeben, die verwendet wird,
wenn das Bild nicht zur Verf gung steht. Wenn das Bild zur Verf gung steht, wird es auf der
vorgegebenen Hintergrundfarbe dargestellt. (Die Farbe wird also in den transparenten Berei-
chen des Bildes sichtbar.)
Der Hintergrund < 721 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Wert f r diese Eigenschaft sind entweder <uri>, womit das Bild angegeben wird, oder 'none',
wenn kein Bild verwendet wird.
Beispiel
BODY { background-image: url("[Link]") }
P { background-image: none }
'background-repeat'
Wert: repeat | repeat-x | repeat-y | no-repeat | inherit (siehe 6.2.1)
Ausgangswert: Repeat
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozentwerte: N/A
Medium: Visual
Wenn ein Hintergrundbild angegeben ist, gibt diese Eigenschaft an, ob und wie es wiederholt
(kachelartig angeordnet) werden soll. Die kachelartige Anordnung erstreckt sich ber die
Inhalts- und Polsterbereiche einer Box. Die Werte haben die folgenden Bedeutungen:
repeat
Das Bild wird sowohl horizontal als auch vertikal wiederholt.
repeat-x
Das Bild wird nur horizontal wiederholt.
repeat-y
Cascading Style Sheets, Level 2
Das Bild wird nur vertikal wiederholt.
no-repeat
Das Bild wird nicht wiederholt: Es wird nur einmal angezeigt.
Beispiel
BODY {
background: white url("[Link]");
background-repeat: repeat-y;
background-position: center;
}
< 722 > Farben und Hintergrund
Page size: 168,00 x 240,00 mm
body text body text body text body text body
text body text body text.
body text body text body text body text
body text
body text body text body text body text body
text body text body text body text body text
body text body text
center image
body text body text body text body text body
text body text body text.
body text body text body text body text
body text
body text body text body text body text body
text body text body text body text body text
body text body text
body text body text body text body text body
text body text body text.
body text body text body text body text
body text
body text body text body text body text body
text body text body text body text body text
body text body text
Abbildung 14.1: Eine Kopie des Hintergrundbildes ist zentriert, die anderen werden unterhalb
und oberhalb angeordnet, so dass ein vertikales Band hinter dem Element entsteht.
'background-attachment'
Wert: scroll | fixed | inherit
Cascading Style Sheets, Level 2
Ausgangswert: Scroll
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozentwerte: N/A
Medium: Visual
Wenn ein Hintergrundbild angegeben ist, legt diese Eigenschaft fest, ob es in Hinblick auf den
Viewport feststehend ('fixed') ist, oder ob es zusammen mit dem Dokument weitergebl@ttert
wird ('scroll').
Selbst ein feststehendes Bild ist immer noch nur dann sichtbar, wenn es sich dabei um den Hin-
tergrund oder die Polsterung des Elements handelt. Wenn das Bild also nicht kachelartig ange-
ordnet ist ('background-repeat: repeat'), ist es m=glicherweise nicht sichtbar.
Der Hintergrund < 723 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Beispiel
Dieses Beispiel erzeugt ein vertikales Endlosband, das beim Weiterbl@ttern des Ele-
ments am Viewport „festgemacht“ zu sein scheint.
BODY {
background: red url("[Link]");
background-repeat: repeat-y;
background-attachment: fixed;
}
Benutzerprogramme behandeln 'fixed' m=glicherweise wie 'scroll'. Es ist jedoch zu empfehlen,
dass sie 'fixed' korrekt interpretieren, zumindest f r HTML- und BODY-Elemente, weil es f r
einen Autor keine M=glichkeit gibt, nur f r solche Browser ein Bild bereitzustellen, die 'fixed'
unterst tzen. Weitere Informationen finden Sie im Abschnitt 3.2 ber Konformit@t.
'background-position'
Wert: [[<percentage> | <length> ]{1,2} | [[top | center | bottom] ||
[left | center | right ]]] | inherit
Ausgangswert: 0% 0%
Angewendet auf: Elemente auf Blockebene und ersetzte Elemente.
Vererbt: Nein
Prozentwerte: Bezieht sich auf die Gr=ße der eigentlichen Box.
Medium: Visual
Wenn ein Hintergrundbild angegeben wurde, legt diese Eigenschaft seine Ausgangsposition fest.
Die Werte haben die folgenden Bedeutungen:
Cascading Style Sheets, Level 2
<percentage> <percentage>
Mit einem Wertepaar von '0% 0%' ist die obere linke Ecke des Bildes an der oberen linken
Ecke der Polsterungskante der Box ausgerichtet. Ein Wertepaar von '100% 100%' platziert
die untere rechte Ecke des Bildes in der unteren rechten Ecke des Polsterbereichs. Mit
einem Wertepaar von '14% 84%' wird der Punkt 14% nach rechts und 84% nach unten im
Auff llbereich platziert.
<length> <length>
Mit einem Wertepaar von '2cm 2cm' wird die obere linke Ecke des Bildes 2cm rechts und
2cm unterhalb der oberen linken Ecke des Auff llbereichs platziert.
top left und left top
Entspricht '0% 0%'.
top, top center und center top
Entspricht '50% 0%'.
right top und top right
Entspricht '100% 0%'.
left, left center und center left
Entspricht '0% 50%'.
< 724 > Farben und Hintergrund
Page size: 168,00 x 240,00 mm
center und center center
Entspricht '50% 50%'.
right, right center und center right
Entspricht '100% 50%'.
bottom left und left bottom
Entspricht '0% 100'.
bottom, bottom center und center bottom
Entspricht '50% 100%'.
bottom right und right bottom
Entspricht '100% 100%'.
Wenn nur ein Prozent- oder L@ngenwert angegeben ist, setzt dieser nur die horizontale Position,
und die vertikale Position liegt bei 50%. Sind zwei Werte angegeben, bestimmt der erste die hori-
zontale Position. Kombinationen aus L@ngen- und Prozentwerten sind ebenso erlaubt (zum Bei-
spiel '50% 2cm') wie negative Positionen. Schl sselw=rter d rfen nicht mit Prozentwerten oder
L@ngenwerten kombiniert werden (alle m=glichen Kombinationen sehen Sie oben).
Beispiel
BODY { background: url("[Link]") right top } /* 100% 0% */
BODY { background: url("[Link]") top center } /* 50% 0% */
BODY { background: url("[Link]") center } /* 50% 50% */
BODY { background: url("[Link]") bottom } /* 50% 100% */
Wenn das Hintergrundbild am Viewport fixiert ist (siehe Eigenschaft 'background-attachment'),
wird das Bild relativ zum Viewport und nicht zum Auff llbereich des Elements platziert. Ein Beispiel:
Beispiel
Cascading Style Sheets, Level 2
BODY {
background-image: url("[Link]");
background-attachment: fixed;
background-position: 100% 100%;
background-repeat: no-repeat;
}
In diesem Beispiel wird das (einzelne) Bild in der unteren rechten Ecke des Viewports platziert.
'background'
Wert: [<'background-color'> || <'background-image'> || <'background-repeat'> ||
<'background-attachment'> || <'background-position'>] | inherit
Ausgangswert: F r zusammenfassende Eigenschaften nicht definiert.
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozentwerte: F r 'background-position' erlaubt.
Medium: Visual
Der Hintergrund < 725 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Die Eigenschaft 'background' ist eine zusammenfassende Eigenschaft f r die Einstellung der ein-
zelnen Hintergrundeigenschaften ('background-color', 'background-image', 'background-repeat',
'background-attachment' und 'background-position') an einer einzigen Stelle im Stylesheet.
Die Eigenschaft 'background' setzt zun@chst die einzelnen Hintergrundeigenschaften auf ihre
Ausgangswerte und weist ihnen dann die explizit in der Deklaration angegebene Werte zu.
Beispiel
In der ersten Regel des folgenden Beispiels wurde nur ein Wert f r 'background-color'
angegeben, und die anderen einzelnen Eigenschaften werden auf ihren Ausgangswert
gesetzt. In der zweiten Regel wurden alle einzelnen Eigenschaften angegeben.
BODY { background: red }
P { background: url("[Link]") gray 50% repeat fixed }
14.3 Gammakorrektur
Anmerkung: Informationen ber Gamma-Aspekte finden Sie im Gamma-Tutorial der PNG-Spezifi-
kation ([PNG10]). n
Bei der Berechnung der Gammakorrektur k=nnen Benutzerprogramme, die Ausgaben auf
einem CRT-Bildschirm vornehmen, von einem idealen CRT-Bildschirm ausgehen und alle Aus-
wirkungen auf scheinbares Gamma ignorieren, die durch Dithering entstehen. Der daraus abge-
leitete minimale Aufwand, der erforderlich ist, damit sie auf den jeweiligen Plattformen funk-
tionieren, ist unten angegeben.
Anmerkung der bersetzer: CRT ist die Abk rzung f r „Cathode Ray Tube“,
also Kathodenstrahlr=hre. Gemeint sind damit herk=mliche Monitore (oder auch Fern-
seher) im Gegensatz zu LCDs oder TFT-Bildschirmen.
Cascading Style Sheets, Level 2
Bei der Gamma-Korrektur geht es darum, Licht-Intensit@ten „korrekt“ darzustellen.
Dabei spielt eine Eigenschaft des menschlichen Auges eine wichtige Rolle: Das Auge rea-
giert sensibel auf Intensit@tsverh,ltnisse, statt auf absolute Intensit@tswerte. Das ist die
Ursache daf r, dass Intensit@tswerte logaithmisch und nicht linear ber den Werte-
bereich verteilt werden. Es ist nun nicht so einfach, die Intensit@ten auf einem CRT-Bild-
schirm anzuzeigen. Abh@ngig ist dieser Vorgang auch von der Phosphorart, die im Moni-
tor zum Einsatz kommt. Die Intensit@t des Lichts, das eine Phosphorart aussendet,
h@ngt von der Anzahl N der Elektronen im Strahl wie folgt ab:
I = kNg
Dabei sind k und g Konstanten. Der g-Wert liegt blicherweise zwischen 2,2 und 2,5.
In der Praxis gibt es noch ein paar weitere Umformungen dieser Gleichung, die hier
nicht weiter ausgef hrt werden sollen. Wesentlich ist, dass am Ende einige Konstanten
eine Rolle spielen, die vom Monitortyp abh@ngen. Letzlich m sste man also eine Tabelle
mit den Werten f r jeden Monitortyp haben und k=nnte dann die entsprechenden
Umrechnungen durchf hren. Der allgemeine Einsatz einer solchen Tabelle wird Gam-
ma-Korrektur genannt; eher willk rlich nach dem – nat rlich austauschbaren – g in der
Gleichung benannt.
Die obigen Ausf hrungen stammen sinngem@ß aus dem Buch von Foley, van Dam [Link].
„Computer Graphics – Principles and Practice“, Zweite Auflage, Addison-Wesley.
< 726 > Farben und Hintergrund
Page size: 168,00 x 240,00 mm
PC unter MS-Windows
Nichts zu tun
Unix mit X11
Nichts zu tun
Mac mit QuickDraw
Anwendung von Gamma 1,45 [ICC32] (ColorSync-f@hige Applikationen k=nnen ColorSync
einfach das sRGB ICC-Profil bergeben, um eine korrekte Farbkorrektur vorzunehmen).
SGI mit X
Anwendung des Gammawerts aus /etc/config/[Link] (der Standardwert ist
1,70; Applikationen unter Irix 6.2 oder h=her k=nnen dem Farbverwaltungssystem einfach
das sRGB ICC-Profil bergeben).
NeXT unter NeXTStep
Anwendung von Gamma 2,22.
„Anwendung von Gamma“ bedeutet, dass R, G und B jeweils in R'=Rgamma, G'=Ggamma,
B'=Bgamma umgewandelt werden, bevor sie dem Betriebssystem bergeben werden.
Das ist ganz einfach, indem man sich einmal pro Browseraufruf eine Nachschlagetabelle mit 256
Elementen erstellt:
for i := 0 to 255 do
raw := i / 255.0;
corr := pow(raw, gamma);
table[i] := trunc (0.5 + corr * 255.0)
end
Damit vermeidet man transzendentale Mathematik f r jedes Farbattribut, und schon gar pro
Pixel.
Cascading Style Sheets, Level 2
15 Schriften
15.1 Einf-hrung
Wenn der Text eines Dokuments visuell dargestellt werden soll, m ssen die einzelnen Zeichen
(abstrakte Informationselemente) auf abstrakte Glyphen abgebildet werden. Ein oder mehr Zei-
chen k=nnen durch ein oder mehr abstrakte Glyphen in m=glicherweise kontextabh@ngiger
Weise dargestellt werden. Ein Glyph ist die tats@chliche k nstlerische Darstellung eines abstrak-
ten Glyphen in einem typografischen Stil in Form von Umrissen oder Bitmaps, die auf den Bild-
schirm oder Papier gezeichnet werden. Eine Schrift (Font) besteht aus einem Satz von Glyphen,
die alle demselben grundlegenden Motiv in Hinblick auf Entwurf, Gr=ße, Erscheinungsbild und
anderen dem gesamten Satz zugeordneten Attributen entsprechen, sowie eine Zuordnung der
Zeichen zu abstrakten Glyphen.
Schriften < 727 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Anmerkung der bersetzer: Der englische Begriff „Font“ wurde hier mit
„Schrift“ bersetzt. An einigen Stellen kann dies zu Missverst@ndnissen und Verwechs-
lungen mit verwandten Begriffen f hren. An solchen Stellen steht der englische Original-
begriff in Klammern hinter dem deutschen Begriff, so wie im vorhergehenden Absatz.
Ein visuelles Benutzerprogramm muss vor der Darstellung eines Zeichens die folgenden
Aspekte ber cksichtigen:
·· Wurde f r dieses Zeichen (direkt oder per Vererbung) eine Schrift angegeben?
Steht dem Benutzerprogramm diese Schrift zur Verf gung?
· Ist dies der Fall, auf welche(n) Glyphen wird dieses Zeichen bzw. diese Zeichenfolge abge-
bildet?
· Was ist zu tun, wenn dies nicht der Fall ist? Sollte stattdessen eine andere Schrift verwendet
werden? Kann die Schrift nachgebildet werden? Kann sie aus dem Web geladen werden?
Sowohl in CSS1 als auch in CSS2 geben Autoren die Charakteristik einer Schrift unter Verwen-
dung mehrerer Schrifteigenschaften an.
Wie das Benutzerprogramm diese Eigenschaften verarbeitet, wenn es keine entsprechende
Schrift auf dem Client gibt, wurde von CSS1 auf CSS2 erweitert. In CSS1 wurde vorausgesetzt,
dass auf dem Client-System alle Schriften vorhanden seien, und sie wurden nur dem Namen
nach identifiziert. Alternative Schriften konnten ber die Eigenschaften angegeben werden, aber
dar ber hinaus hatten die Benutzerprogramme keine M=glichkeit, dem Benutzer außer generi-
schen Standardschriften andere Schriften vorzuschlagen (selbst stilistisch @hnliche Schriften, die
dem Benutzerprogramm zur Verf gung standen).
In CSS2 hat sich dies alles ver@ndert, und es gibt sehr viel mehr Freiheiten f r:
·· Stylesheet-Autoren, um die Schriften zu beschreiben, die verwendet werden sollen
Benutzerprogramme bei der Auswahl einer Schrift, wenn die von einem Autor angefor-
derte Schrift nicht unmittelbar zur Verf gung steht
Cascading Style Sheets, Level 2
CSS2 verbessert die client-seitige Schrift bereinstimmung, erm=glicht eine Schriftsynthese und
eine progressive Darstellung und erlaubt, dass Schriften ber das Web heruntergeladen wer-
den. Diese verbesserten M=glichkeiten werden auch als „WebFonts“ bezeichnet.
Im CSS2-Schriftmodell hat wie in CSS1 jedes Benutzerprogramm eine „Schriftdatenbank“ zur
Verf gung. CSS1 hat auf diese Datenbank verwiesen, gab aber keine Details an, was darin ent-
halten war. CSS2 definiert die Information in dieser Datenbank und erlaubt es den Autoren
von Stylesheets, sie zu erweitern. Wird ein Benutzerprogramm aufgefordert, ein Zeichen in
einer bestimmten Schrift darzustellen, identifiziert das Benutzerprogramm zun@chst die Schrift
in der Datenbank, die mit der angegebenen Schrift am besten bereinstimmt (gem@ß dem
Schriftvergleichsalgorithmus). Nachdem es eine Schrift gefunden hat, l@dt es die Schriftdaten
lokal oder aus dem Web und kann die Zeichen unter Verwendung dieser Glyphen anzeigen.
Wegen dieses Modells haben wir die Spezifikation in zwei Teile unterteilt. Der erste besch@ftigt
sich mit dem Mechanismus zur Angabe der Schrift, mit Hilfe dessen die Autoren festlegen k=n-
nen, welche Schrift sie in ihren Dokumenten verwenden wollen. Der zweite betrifft den Schrift-
auswahlmechanismus, mittels dessen das Benutzerprogramm des Clients eine Schrift identifi-
ziert und l@dt, die der Spezifikation des Autors am besten entspricht.
< 728 > Schriften
Page size: 168,00 x 240,00 mm
Wie das Benutzerprogramm die Schriftdatenbank anlegt, kann im Rahmen dieser Spezifikation
nicht beschrieben werden, weil die Implementierung der Datenbank von verschiedenen Fak-
toren abh@ngig ist, wie beispielsweise dem Betriebssystem, dem Fenstersystem und dem Client.
15.2 Schriftspezifikation
Die erste Phase des CSS-Schriftmechanismus besch@ftigt sich damit, wie Stylesheet-Autoren
festlegen, welche Schriften von einem Benutzerprogramm verwendet werden sollten. Zun@chst
scheint es, dass die offensichtlichste Methode zur Angabe einer Schrift w@re, ihren Namen
anzugeben, einen einzelnen String, der in verschiedene Teile unterteilt ist, zum Beispiel „BT
Swiss 721 Heavy Italic“.
Leider gibt es keine wohldefinierte und universell akzeptierte Taxonomie f r die Klassifizierung
von Schriften abh@ngig von ihren Namen, und Begriffe, die f r einen Schriftfamiliennamen gel-
ten, sind f r andere m=glicherweise nicht geeignet. Beispielsweise wird der Begriff 'italic' (kur-
siv) im Allgemeinen verwendet, um kursiven Text zu beschreiben, aber kursiver Text kann
auch als Oblique, Slanted, Incline, Cursive oder Kursiv bezeichnet werden. Analog enthalten
Schriftnamen h@ufig Begriffe, die die „Gewichtung“ einer Schrift angeben. Die wichtigste Auf-
gabe dieser Namen ist es, Schriften unterschiedlicher Strichst@rke innerhalb einer einzelnen
Schriftfamilie voneinander zu unterscheiden. Es gibt keine allgemein akzeptierte, universelle
Bedeutung dieser Gewichtungsbezeichnungen, und ihre Verwendung variiert stark. Eine Schrift,
die Sie als „Bold“ (fett) bezeichnen w rden, k=nnte auch die Attribute Regular, Roman, Book,
Medium, Semi- oder Demi-Bold, Bold oder Black erhalten, abh@ngig davon, wie schwarz die „nor-
male“ Schrift innerhalb ihres Designs erscheint.
Dieses Fehlen einer systematischen Benennung macht es im Allgemeinen unm=glich, einen
abgewandelten Schriftnamen zu erzeugen, der sich in bestimmter Hinsicht vom Standardnamen
unterscheidet, beispielsweise durch eine fettere Darstellung.
Aufgrund dessen verwendet CSS ein anderes Modell. Schriften werden nicht ber einen
bestimmten Schriftnamen angefordert, sondern durch die Festlegung mehrerer Schrifteigen-
Cascading Style Sheets, Level 2
schaften. Diese Eigenschaftsnamen bilden die Grundlage f r den Schriftauswahlmechanismus
des Benutzerprogramms. Die Schrifteigenschaften k=nnen einzeln abge@ndert werden, bei-
spielsweise, um eine Schrift fetter zu machen; die neue Menge der Schrifteigenschaftsnamen
wird dann dazu verwendet, um erneut eine Auswahl aus der Schriftdatenbank zu treffen. Das
Ergebnis ist eine gesteigerte Regelm@ßigkeit f r Stylesheet-Autoren und -Implementierer und
außerdem eine verbesserte Robustheit.
Anmerkung der bersetzer: Der Abschnitt 15.2 ist innerhalb dieses Kapitels f r
den Stylesheet-Autor, der Formatierungen f r Web-Seiten festlegen m=chte, der wich-
tigste Abschnitt. Die darauffolgenden Abschnitte erfordern einerseits ein geh=riges Maß
an typographischen Kenntnissen ber Schriften, andererseits kann man sich nicht auf
die Unterst tzung der fortgeschrittenen Features durch Web-Browser verlassen. In
der blichen Praxis ist deshalb dieser Abschnitt maßgeblich.
Schriftspezifikation < 729 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
15.2.1 Eigenschaften f-r die Schriftspezifikation
CSS2 spezifiziert Schriften abh@ngig von den folgenden Eigenschaften:
Schriftfamilie (Font family)
Die Schriftfamilie gibt an, welche Schriftfamilie f r die Darstellung des Texts verwendet
werden soll. Eine Schriftfamilie ist eine Gruppe von Schriften, die darauf ausgelegt sind, dass
sie kombiniert werden k=nnen und die vom Design her ahnlich sind. Ein Mitglied der Familie
kann kursiv sein, ein anderes fett, ein wieder anderes komprimiert, oder vielleicht verwen-
det es Kapit@lchen. Schriftfamiliennamen sind beispielsweise „Helvetica“, „New Century
Schoolbook“ oder „Kyokasho ICA L“. Schriftfamiliennamen sind nicht auf lateinische Zei-
chen begrenzt. Schriftfamilien k=nnen in unterschiedliche Kategorien eingeteilt werden: mit
oder ohne Serifen, mit Zeichen, die proportional oder nicht proportional angeordnet sind,
Schriften, die an eine Handschrift erinnern, Fantasieschriften usw.
Schriftstil (Font style)
Der Schriftstil gibt an, ob der Text normal, kursiv oder geneigt dargestellt werden soll.
Italic (kursiv) ist eine kursivere Variante der normalen Schrift, aber nicht so kursiv wie eine
Schreibschrift. Oblique ist eine geneigte Form der normalen Schrift und wird h@ufiger als
begleitende Variante f r serifenlose Schriften verwendet. Diese Definition vermeidet, dass
leicht geneigte normale Schriften als oblique bezeichnet werden oder normale griechische
Schriften als kursiv.
Schriftvariante (Font variant)
Die Schriftvariante gibt an, ob der Text unter Verwendung der normalen Glyphen f r Klein-
buchstaben oder mit Kapit@lchen-Glyphen f r Kleinbuchstaben dargestellt werden soll. Eine
Schrift enth@lt m=glicherweise nur normale Glyphen oder nur Kapit@lchen oder beide
Arten von Glyphen; diese Eigenschaft wird genutzt, um eine geeignete Schrift anzufordern,
und, falls die Schrift beide Varianten enth@lt, die geeigneten Glyphen.
Schriftgewichtung (Font weight)
Die Schriftgewichtung bezieht sich darauf, wie fett oder wie d nn die f r die Darstellung
Cascading Style Sheets, Level 2
des Texts verwendeten Glyphen relativ zu anderen Schriften derselben Schriftfamilie sind.
Schriftdehnung (Font stretch)
Die Schriftdehnung gibt an, wie stark die f r die Darstellung des Texts verwendeten Gly-
phen zusammengeschoben oder auseinandergezogen werden, relativ zu anderen Schriften
derselben Schriftfamilie.
SchriftgrUße (Font size)
Die Schriftgr=ße bezieht sich auf die Gr=ße der Schrift von Grundlinie zu Grundlinie, wenn
sie durchgezogen dargestellt ist (in CSS-Terminologie ist dies der Fall, wenn die Eigenschaf-
ten 'font-size' und 'line-height' denselben Wert haben).
F r alle Eigenschaften außer 'font-size' beziehen sich 'em'- und 'ex'-L@ngenwerte auf die Schrift-
gr=ße des aktuellen Elements. F r 'font-size' beziehen sich diese L@ngeneinheiten auf die Schrift-
gr=ße des bergeordneten Elements. Weitere Informationen finden Sie im Abschnitt ber L@n-
geneinheiten.
Die CSS-Schrifteigenschaften werden verwendet, um das gew nschte Erscheinungsbild von
Text im Dokument zu beschreiben. Die Schriftdeskriptoren dagegen werden verwendet, um
die Charakteristiken von Schriften zu beschreiben, so dass eine geeignete Schrift gew@hlt wer-
den kann, um das gew nschte Erscheinungsbild zu erzeugen. Weitere Informationen ber die
Klassifizierung von Schriften finden Sie im Abschnitt ber Schriftdeskriptoren.
< 730 > Schriften
Page size: 168,00 x 240,00 mm
15.2.2 Schriftfamilie: die Eigenschaft 'font-family'
'font-family'
Wert: [[<family-name> | <generic-family>,]* [<family-name> |
<generic-family>] | inherit
Ausgangswert: Vom Benutzerprogramm abh@ngig
Angewendet auf: Alle Elemente
Vererbt: Ja
Prozentwerte: N/A
Medium: Visual
Diese Eigenschaft gibt eine Liste mit bevorzugten Familiennamen und/oder generischen Famili-
ennamen an. Es k=nnen verschiedene Probleme auftreten, etwa dass eine einzige Schrift m=gli-
cherweise nicht gen gend Glyphen enth@lt, um alle Zeichen in einem Dokument darzustellen,
oder dass nicht alle Schriften auf allen Systemen zur Verf gung stehen. Um mit solchen Prob-
lemen umgehen zu k=nnen, erlaubt diese Eigenschaft den Autoren, eine Liste mit Schriften
anzugeben, alle mit demselben Stil und derselben Gr=ße, die nacheinander ausprobiert werden,
um zu berpr fen, ob sie eine Glyphe f r ein bestimmtes Zeichen enthalten. Diese Liste wird
auch als Schriftmenge (Font set) bezeichnet.
Beispiel
F r Text beispielsweise, der deutsche W=rter kombiniert mit mathematischen Sym-
bolen enth@lt, k=nnte es sein, dass eine Schriftmenge mit zwei Schriften ben=tigt wird,
eine mit lateinischen Buchstaben und Ziffern, die andere mit mathematischen Symbolen.
Nachfolgend sehen Sie ein Beispiel f r eine Schriftmenge, die f r einen Text geeignet ist,
Cascading Style Sheets, Level 2
von dem man erwartet, dass er Text mit lateinischen Buchstaben, japanischen Zeichen
sowie mathematischen Symbolen enth@lt:
BODY { font-family: Baskerville, "Heisi Mincho W3", Symbol, serif }
Die in der Schrift „Baskerville“ verf gbaren Glyphen (diese Schrift deckt nur lateinische Buch-
staben ab) werden dieser Schrift entnommen, japanische Buchstaben werden aus „Heisi Mincho
W3“ entnommen, und die mathematischen Symbol-Glyphen stammen aus „Symbol“. Alle ande-
ren stammen aus der generischen Schriftfamilie 'serif'.
Die generische Schriftfamilie wird verwendet, wenn eine oder mehrere der anderen Schriften
in einem Schriftsatz nicht zur Verf gung stehen. Obwohl viele Schriften den Glyph f r ein „feh-
lendes Zeichen“ bereitstellen, in der Regel ein kleines, nicht ausgef lltes Rechteck, sollte dieses,
wie der Name sagt, nicht als bereinstimmung betrachtet werden, außer in der letzten aus-
gewerteten Schrift in einem Schriftsatz.
Schriftspezifikation < 731 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Es gibt zwei Arten von Schriftfamiliennamen:
<family-name>
Der Name der gew@hlten Schriftfamilie. Im vorigen Beispiel waren „Baskerville“, „Heisi
Mincho W3“ und „Symbol“ Schriftfamilien. Schriftfamiliennamen, in denen Leeraum enthal-
ten ist, sollten in Anf hrungszeichen gesetzt werden. Werden die Anf hrungszeichen weg-
gelassen, werden alle Leeraumzeichen vor und hinter dem Schriftnamen ignoriert, und eine
beliebige Folge von Leeraumzeichen innerhalb des Schriftnamens wird in ein einzelnes Leer-
zeichen umgewandelt.
<generic-family>
Die nachfolgenden generischen Familien sind definiert: 'serif', 'sans-serif', 'cursive', 'fantasy'
und 'monospace'. Eine Beschreibung dieser Familien finden Sie im Abschnitt ber generi-
sche Schriftfamilien (15.2.6). Die Namen generischer Schriftfamilien sind Schl sselw=rter
und m ssten deshalb nicht in Anf hrungszeichen stehen.
Den Autoren ist zu empfehlen, dass sie mindestens eine generische Schriftfamilie als letzte
Alternative angeben, um eine gesteigerte Robustheit zu gew@hrleisten.
Beispiel
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>Font test</TITLE>
<STYLE type="text/css">
BODY { font-family: "new century schoolbook", serif }
</STYLE>
</HEAD>
<BODY>
<H1 style="font-family: 'Meine eigene Schrift', fantasy">Test</H1>
Cascading Style Sheets, Level 2
<P>Was ist los, Doc?
</BODY>
</HTML>
Anmerkung der bersetzer: Hier sei darauf hingewiesen, dass nicht nur die
Schriften, die auf unterschiedlichen Systemen installiert sind, voneinander abweichen
k=nnen, auch kann eine Schrift unter verschiedenen Namen bekannt sein. Das Problem
wird in sp@teren Abschnitten dieses Kapitels thematisiert. Die oben benutzte New Cen-
tury Schoolbook kann zum Beispiel auch kurz „NewCent“ heißen; gegebenenfalls auch
abh@ngig von Systembeschr@nkungen wie maximalen Dateinamenl@ngen. Gerade vor
diesem Hintergrund ist die Empfehlung, eine generische Schriftfamilie anzugeben, nur zu
unterstreichen.
Die umfangreichere Selektorsyntax von CSS2 kann genutzt werden, um eine sprachabh@ngige
Typographie zu realisieren. Beispielsweise sind einige chinesische und japanische Zeichen unter
demselben Unicode-Codepunkt zusammengefasst, obwohl die abstrakten Glyphen in den bei-
den Sprachen nicht gleich sind:
< 732 > Schriften
Page size: 168,00 x 240,00 mm
*:lang(ja-jp) { font: 900 14pt/16pt "Heisei Mincho W9", serif }
*:lang(zh-tw) { font: 800 14pt/16.5pt "Li Sung", serif }
Damit werden alle Elemente ausgew@hlt, die in der betreffenden Sprache enthalten sind – Japa-
nisch oder traditionelles Chinesisch –, und eine geeignete Schrift wird angefordert.
15.2.3 Schriftstile: die Eigenschaften 'font-style', 'font-variant',
'font-weight' und 'font-stretch'
'font-style'
Wert: normal | italic | oblique | inherit
Ausgangswert: Normal
Angewendet auf: Alle Elemente
Vererbt Ja
Prozents,tze N/A
Medium: Visual
Die Eigenschaft 'font-style' fordert normale (manchmal auch als „roman“ oder „upright“
bezeichnet), kursive und geneigte Darstellungen innerhalb einer Schriftfamilie an. Die Werte
haben die folgenden Bedeutungen:
normal
Gibt eine Schrift an, die in der Schriftdatenbank des Benutzerprogramms als 'normal' klassi-
fiziert ist.
oblique
Cascading Style Sheets, Level 2
Gibt eine Schrift an, die in der Schriftdatenbank des Benutzerprogramms als 'oblique' klassi-
fiziert ist. Schriften mit den W=rtern Oblique, Slanted oder Incline in ihren Namen werden
in der Schriftdatenbank h@ufig als 'oblique' bezeichnet. Eine in der Schriftdatenbank des
Benutzerprogramms als 'oblique' bezeichnete Schrift kann durch das elektronische „Nei-
gen“ einer normalen Schrift entstanden sein.
italic
Gibt eine Schrift an, die in der Schriftdatenbank des Benutzerprogramms als 'italic' klassifi-
ziert ist, oder, falls diese nicht verf gbar ist, eine, die als 'oblique' gekennzeichnet ist. Schrif-
ten mit Italic, Cursive oder Kursiv in ihren Namen werden normalerweise als 'italic' gekenn-
zeichnet.
Beispiel
In diesem Beispiel wird normaler Text in einem H1-, H2- oder H3-Element in kursiver
Schrift dargestellt. Betonter Text (EM) in einem H1-Element dagegen erscheint in nor-
maler Schrift.
H1, H2, H3 { font-style: italic }
H1 EM { font-style: normal }
Schriftspezifikation < 733 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
'font-variant'
Wert : normal | small-caps | inherit
Ausgangswert: Normal
Angewendet auf: Alle Elemente
Vererbt: Ja
Prozentwerte: N/A
Medium: Visual
In einer Schrift mit Kapit@lchen sehen die Glyphen f r die Kleinbuchstaben @hnlich wie die f r
die Großbuchstaben aus, aber sie sind etwas kleiner und haben etwas andere Proportionen.
Die Eigenschaft 'font-variant' fordert eine Schrift f r Situationen an, in denen zwischen Groß-
und Kleinschreibung unterschieden wird, wie beispielsweise bei der lateinischen Schrift. Diese
Eigenschaft hat keine sichtbaren Effekte in Dokumenten, in denen es keine Groß- und Klein-
schreibung gibt, wie bei den meisten Schreibsystemen der Welt. Die Werte haben die folgen-
den Bedeutungen:
normal
Gibt eine Schrift an, die nicht als Kapit@lchenschrift gekennzeichnet ist.
small-caps
Gibt eine Schrift an, die als Kapit@lchenschrift gekennzeichnet ist. Steht keine eigene Kapi-
t@lchenschrift zur Verf gung, sollten die Benutzerprogramme eine Kapit@lchenschrift simu-
lieren, indem sie beispielsweise eine normale Schrift verwenden und die Kleinbuchstaben
durch verkleinerte Großbuchstaben ersetzen. Als letzten Ausweg k=nnen nicht verklei-
nerte Großbuchstaben-Glyphen in einer normalen Schrift die Glyphen in einer Kapit@lchen-
schrift ersetzen, so dass der Text aussieht, als sei er nur in Großbuchstaben geschrieben.
Cascading Style Sheets, Level 2
Beispiel
Das nachfolgende Beispiel erzeugt ein H3-Element in Kapit@lchen mit betonten W=r-
tern (EM) in geneigten Kapit@lchen:
H3 { font-variant: small-caps }
EM { font-style: oblique }
Wenn diese Eigenschaft bewirkt, dass Text in Großbuchstaben umgewandelt wird, gelten die-
selben Betrachtungen wie f r 'text-transform'.
< 734 > Schriften
Page size: 168,00 x 240,00 mm
'font-weight'
Wert: normal | bold | bolder | lighter |100 | 200 | 300 | 400 | 500 | 600
| 700 | 800 | 900 | inherit
Ausgangswert: Normal
Angewendet auf: Alle Elemente
Vererbt: Ja
Prozentwerte: N/A
Medium: Visual
Die Eigenschaft 'font-weight' gibt die Gewichtung der Schrift an. Die Werte haben die folgen-
den Bedeutungen:
100 bis 900
Diese Werte bilden eine sortierte Abfolge, wobei jede Zahl eine Gewichtung angibt, die
mindestens so dunkel wie ihre Vorg@ngerin ist.
normal
Wie '400'.
bold
Wie '700'.
bolder
Gibt die n@chste Gewichtung an, die einer Schrift zugeordnet ist, die dunkler als die geerbte
ist. Falls es keine solche Gewichtung gibt, wird einfach der n@chstdunklere numerische
Wert angenommen (und die Schrift bleibt unver@ndert), es sei denn, der geerbte Wert war
'900', dann ist die resultierende Gewichtung ebenfalls '900'.
lighter
Cascading Style Sheets, Level 2
Gibt die n@chste Gewichtung an, die einer Schrift zugeordnet ist, die heller als die geerbte
ist. Falls es keine solche Gewichtung gibt, wird einfach der n@chst hellere numerische Wert
verwendet (und die Schrift bleibt unver@ndert), es sei denn, der geerbte Wert war '100',
dann ist die resultierende Gewichtung ebenfalls '100'.
Beispiel
P { font-weight: normal } /* 400 */
H1 { font-weight: 700 } /* fett */
BODY { font-weight: 400 }
STRONG { font-weight: bolder } /* 500 falls verfUgbar */
Untergeordnete Elemente erben den berechneten Wert der Gewichtung.
Schriftspezifikation < 735 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
'font-stretch'
Wert normal | wider | narrower | ultra-condensed | extra-condensed
| condensed | semi-condensed | semi-expanded | extra-
expanded | ultra-expanded | inherit
Ausgangswert Normal
Angewendet auf: Alle Elemente
Vererbt: Ja
Prozentwerte: N/A
Medium: Visual
Die Eigenschaft 'font-stretch' w@hlt eine normale, komprimierte oder gedehnte Darstellung aus
einer Schriftfamilie. Absolute Schl sselwortwerte haben die folgende Reihenfolge, von der
komprimiertesten bis hin zur am weitesten gedehnten Schrift:
1. ultra-condensed
2. extra-condensed
3. condensed
4. semi-condensed
5. normal
6. semi-expanded
7. expanded
8. extra-expanded
9. ultra-expanded
Das relative Schl sselwort 'wider' setzt den Wert auf den n@chstweiter gedehnten Wert ober-
halb des geerbten Werts (wobei bei 'ultra-expanded' keine weitere Steigerung m=glich ist); das
relative Schl sselwort 'narrower' setzt den Wert auf den n@chstst@rker komprimierten Wert
Cascading Style Sheets, Level 2
unterhalb des geerbten Werts (wobei unterhalb 'ultra-condensed' keine weitere Komprimie-
rung erfolgt).
15.2.4 SchriftgrUße: die Eigenschaften 'font-size' und 'font-size-adjust'
'font-size'
Wert: <absolute-size> | <relative-size> | <length> | <percentage> | inherit
Ausgangswert: Medium
Angewendet auf: Alle Elemente
Vererbt: Ja, der berechnete Wert ist geerbt
Prozentwerte: Bezieht sich auf die Schriftgr=ße des bergeordneten Elements
Medium Visual
< 736 > Schriften
Page size: 168,00 x 240,00 mm
Diese Eigenschaft beschreibt die Gr=ße der Schrift bei der Darstellung in voller Zeilenh=he.
Die Werte haben die folgenden Bedeutungen:
<absolute-size>
Ein <absolute-size>-Schl sselwort bezieht sich auf einen Eintrag in einer Tabelle mit Schriftgr=-
ßen, die vom Benutzerprogramm berechnet und verwaltet werden. M=gliche Werte sind:
[xx-small | x-small | small | medium | large | x-large | xx-large]
Auf einem Computerbildschirm wird ein Skalierungsfaktor von 1.2 zwischen benachbarten
Indizes empfohlen; wenn die Schrift 'medium' 12pt groß ist, k=nnte die Schrift 'large' 14.4pt
groß sein. Unterschiedliche Medien brauchen m=glicherweise unterschiedliche Skalierungs-
faktoren. Außerdem sollte das Benutzerprogramm bei der Berechnung der Tabelle die
Qualit@t und die Verf gbarkeit von Schriften ber cksichtigen. Die Tabelle kann sich zwi-
schen einzelnen Schriftfamilien unterscheiden.
Hinweis: In CSS1 lag der empfohlene Skalierungsfaktor zwischen benachbarten Indizes bei 1,5,
was sich der Erfahrung der Benutzer nach als zu groß erwies. n
<relative-size>
Ein <relative-size>-Schl sselwort wird als relativ zur Tabelle der Schriftgr=ßen und der
Schriftgr=ße des bergeordneten Elements interpretiert. M=gliche Werte sind:
[larger | smaller]
Hat das bergeordnete Element beispielsweise die Schriftgr=ße 'medium', macht der Wert
'larger' die Schriftgr=ße des aktuellen Elements 'large'. Liegt die Gr=ße eines bergeord-
neten Elements nicht nahe an einem Tabelleneintrag, steht es dem Benutzerprogramm frei,
zwischen Tabelleneintr@gen zu interpolieren und auf den n@chsten aufzurunden. Das Benut-
zerprogramm muss m=glicherweise Tabellenwerte extrapolieren, wenn die numerischen
Werte ber die Schl sselw=rter hinausgehen.
<length>
Ein L@ngenwert gibt eine absolute Schriftgr=ße an (die von der Schrifttabelle des Benutzer-
Cascading Style Sheets, Level 2
programms unabh@ngig ist). Negative L@ngen sind nicht erlaubt.
<percentage>
Ein Prozentwert gibt eine absolute Schriftgr=ße relativ zur Schriftgr=ße des bergeord-
neten Elements an. Die Verwendung von Prozentwerten oder Werten in 'em's f hrt zu
robusteren und kaskadierbareren Stylesheets.
Der tats@chliche Wert dieser Eigenschaft kann sich von dem berechneten Wert aufgrund eines
numerischen Wertes von 'font-size-adjust' und der Unverf gbarkeit mancher Schriftgr=ßen
unterscheiden.
Untergeordnete Werte erben den berechneten 'font-size'-Wert (andernfalls w@re der Effekt
von 'font-size-adjust' vermischt).
Beispiel
P { font-size: 12pt; }
BLOCKQUOTE { font-size: larger }
EM { font-size: 150% }
EM { font-size: 1.5em }
Schriftspezifikation < 737 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
'font-size-adjust'
Wert: <number> | none | inherit
Ausgangswert: None
Angewendet auf: Alle Elemente
Vererbt: Ja
Prozentwerte: N/A
Medium: Visual
In Schriften mit Groß-/Kleinschreibung sind die subjektive sichtbare Gr=ße und Lesbarkeit
einer Schrift weniger von ihrem 'font-size'-Wert abh@ngig, als vielmehr vom Wert ihrer
'x-height', oder, was praktischer ist, vom Verh@ltnis dieser beiden Werte, dem so genannten
Aspektwert (Schriftgr=ße dividiert durch x-height). Je h=her der Aspektwert ist, desto wahr-
scheinlicher ist es, dass eine Schrift bei kleineren Gr=ßen leserlich ist. Umgekehrt gilt, dass
Schriften mit einem kleinen Aspektwert schneller unterhalb einer vorgegebenen Schwellwert-
gr=ße unleserlich werden als Schriften mit einem h=heren Aspektwert. Eine einfache Schrifter-
setzung, die sich nur nach der Schriftgr=ße richtet, k=nnte also zu unleserlichen Zeichen f h-
ren.
Die bekannte Schrift Verdana beispielsweise hat einen Aspektwert von 0,58; wenn die Schrift-
gr=ße von Verdana 100 Einheiten entspricht, dann entspricht ihre x-height 58 Einheiten. Im
Vergleich dazu hat Times New Roman einen Aspektwert von 0,46. Verdana bleibt deshalb ten-
denziell bei kleineren Gr=ßen besser lesbar als Times New Roman. Im Gegenzug dazu
erscheint Verdana h@ufig als „zu groß“, wenn sie anstelle von Times New Roman in einer zuvor
festgelegten Gr=ße eingesetzt wird.
Diese Eigenschaft erlaubt den Autoren, einen Aspektwert f r ein Element anzugeben, der die
x-height der Schrift der ersten Wahl in der Ersatzschrift beibeh@lt. Die Werte haben die folgen-
Cascading Style Sheets, Level 2
den Bedeutungen:
none
Beh@lt die x-height der Schrift nicht bei.
<number>
Gibt den Aspektwert an. Die Zahl bezieht sich auf den Aspektwert der Schrift der ersten
Wahl. Der Skalierfaktor f r verf gbare Schriften wird gem@ß der folgenden Formel berech-
net:
y(a/a') = c
Wobei Folgendes gilt:
y = 'font-size' oder Schrift der ersten Wahl
a' = Aspektwert der verfUgbaren Schrift
c = 'font-size', die auf die verfUgbare Schrift angewendet wird
Steht beispielsweise 14px Verdana (mit einem Aspektwert von 0,58) nicht zur Verf gung
und die verf gbare Schrift hat den Aspektwert 0,46, w@re die Schriftgr=ße des Ersatzes
14 & (0,58/0,46) = 17,65px.
< 738 > Schriften
Page size: 168,00 x 240,00 mm
Anpassungen der Schriftgr=ße finden statt, wenn der tats@chliche Wert von 'font-size' berech-
net wird. Weil die Vererbung auf dem berechneten Wert basiert, erben die untergeordneten
Elemente nicht angepasste Werte.
Das erste der nachfolgenden Bilder zeigt mehrere Schriften, dargestellt in einer gebr@uchlichen
Schriftgr=ße (11 pt bei 72 ppi), zusammen mit ihren Aspektwerten. Beachten Sie, dass die
Schriften mit h=heren Aspektwerten gr=ßer erscheinen als die mit kleineren. Schriften mit sehr
kleinen Aspektwerten sind in der gezeigten Gr=ße unleserlich.
Cascading Style Sheets, Level 2
Schriftspezifikation < 739 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Das n@chste Bild zeigt die Ergebnisse von 'font-size-adjust', wobei Verdana als „erste Wahl“ gilt,
zusammen mit dem angewendeten Skalierfaktor. Weil sie angepasst sind, sind die sichtbaren
Schriften ann@hernd linear ber die verschiedenen Schriften, obwohl die tats@chlichen (em-)
Gr=ßen um mehr als 100% variieren. Beachten Sie, dass 'font-size-adjust' dazu tendiert, auch
die horizontale Zeilenmetrik zu stabilisieren.
Cascading Style Sheets, Level 2
< 740 > Schriften
Page size: 168,00 x 240,00 mm
15.2.5 Zusammenfassende Schrift-Eigenschaft: die Eigenschaft 'font'
'font'
Wert: [[<'font-style'> | | <'font-variant'> | | <'font-weight'> ]?
<'font-size'> [/ <'line-height'> ]? <'font-family'> ] | caption | icon
| menu | message-box | small-caption | status-bar | inherit
Ausgangswert: Siehe einzelne Eigenschaften
Angewendet auf: Alle Elemente
Vererbt: Ja
Prozentwerte Erlaubt f r 'font-size' und 'line-height'
Medium Visual
Die Eigenschaft 'font' ist, von nachfolgend beschriebenen Ausnahmen abgesehen, eine zusam-
menfassende Eigenschaft f r die Einstellung von 'font-style', 'font-variant', 'font-weight', 'font-
size', 'line-height' und 'font-family' an einer gemeinsamen Stelle im Stylesheet. Die Syntax dieser
Eigenschaft basiert auf einer traditionellen typografischen zusammenfassenden Notation, um
mehrere Eigenschaften f r Schriften zu setzen.
Alle auf die Schrift bezogenen Eigenschaften werden zun@chst auf ihre Ausgangswerte zur ck-
gesetzt, auch die im vorigen Abschnitt aufgelisteten sowie 'font-stretch' und 'font-size-adjust'.
Anschließend erhalten Eigenschaften, denen in der zusammenfassenden Eigenschaft 'font' expli-
zit Werte zugeordnet sind, genau diese Werte. Eine Definition der erlaubten und der Aus-
gangswerte finden Sie in den zuvor definierten Eigenschaften. Aus Gr nden der Abw@rtskom-
patibilit@t ist es nicht m=glich, 'font-stretch' und 'font-size-adjust' unter Verwendung von 'font'
auf andere als ihre Ausgangswerte zu setzen; stattdessen setzen Sie daf r die separaten Eigen-
schaften.
Cascading Style Sheets, Level 2
Beispiel
P { font: 12pt/14pt sans-serif }
P { font: 80% sans-serif }
P { font: x-large/110% "new century schoolbook", serif }
P { font: bold italic large Palatino, serif }
P { font: normal small-caps 120%/120% fantasy }
P { font: oblique 12pt "Helvetica Nue", serif; font-stretch: condensed }
In der zweiten Regel bezieht sich der Prozentwert f r die Schriftgr=ße ('80%') auf die Schrift-
gr=ße des bergeordneten Elements. In der dritten Regel bezieht sich der Prozentwert f r die
Zeilenh=he ('110%') auf die Schriftgr=ße des eigentlichen Elements.
Die ersten drei Regeln treffen keine expliziten Angaben f r 'font-variant' und 'font-weight', des-
halb erhalten diese Eigenschaften ihre Ausgangswerte ('normal'). Beachten Sie, dass der Schrift-
familienname „new century schoolbook“, der Leerzeichen enth@lt, in Anf hrungszeichen einge-
schlossen ist. Die vierte Regel setzt 'font-weight' auf 'bold', 'font-style' auf 'italic' und 'font-
variant' implizit auf 'normal'.
Schriftspezifikation < 741 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Die f nfte Regel setzt 'font-variant' ('small-caps'), 'font-size' (120% der Schriftgr=ße des berge-
ordneten Elements), 'line-height' (120% der Schriftgr=ße) und die 'font-family' ('fantasy'). Es
folgt, dass sich das Schl sselwort 'normal' auf die beiden restlichen Eigenschaften bezieht, 'font-
style' und 'font-weight'.
Die sechste Regel setzt 'font-style', 'font-size' und 'font-family', die anderen Schrifteigenschaften
werden auf ihre Ausgangswerte gesetzt. Anschließend setzt sie 'font-stretch' auf 'condensed',
weil diese Eigenschaft nicht mit Hilfe der zusammenfassenden Eigenschaft 'font' auf diesen Wert
gesetzt werden kann.
Die nachfolgenden Werte beziehen sich auf Systemschriften:
caption
Die f r Steuerelemente mit Beschriftungen verwendete Schrift (z. B. Schaltfl@chen, Drop-
down-Steuerelemente usw.).
icon
Die f r die Beschriftung von Icons verwendete Schrift.
menu
Die in Men s verwendete Schrift (z. B. Dropdown-Men s oder Men listen).
message-box
Die in Dialogfeldern verwendete Schrift.
small-caption
Die f r die Beschriftung kleiner Steuerelemente verwendete Schrift.
status-bar
Die f r Fensterstatusleisten verwendete Schrift.
Anmerkung der bersetzer: Mit diesen Werten ist es m=glich, f r Teile einer
Webseite die gleichen Schriften zu verwenden, wie sie f r das Fenstersystem (etwa
Windows oder X) benutzt werden, das auf dem Rechner des Betrachters l@uft. Beach-
Cascading Style Sheets, Level 2
ten Sie in diesem Zusammenhang auch Kapitel 18.
Systemschriften k=nnen nur als Ganzes gesetzt werden; das bedeutet, die Schriftfamilie, Gr=ße,
Gewichtung, Stil usw. werden gleichzeitig gesetzt. Diese Werte k=nnen gegebenenfalls einzeln
ver@ndert werden. Gibt es auf einer bestimmten Plattform keine Schrift mit den vorgegebenen
Charakteristika, sollte das Benutzerprogramm entweder intelligent ersetzen (z. B. k=nnte f r
die 'small-caption'-Schrift eine kleinere Version der 'caption'-Schrift verwendet werden) oder
aber seine Standardschrift verwenden. Wie f r regul@re Schriften gilt auch f r eine System-
schrift, dass, wenn eine der einzelnen Eigenschaften nicht Teil der verf gbaren Benutzereinstel-
lungen des Betriebssystems sind, diese Eigenschaften auf ihre Ausgangswerte gesetzt werden
sollten.
Deshalb ist diese Eigenschaft „fast“ eine zusammenfassende Eigenschaft: Systemschriften k=n-
nen nur mit dieser Eigenschaft angegeben werden, nicht mit 'font-family' selbst, deshalb erlaubt
'font' den Autoren, mehr als die Summe seiner enthaltenen Eigenschaften zu setzen. Die einzel-
nen Eigenschaften wie beispielsweise 'font-weight' erhalten dennoch Werte, die aus der Sys-
temschrift stammen und unabh@ngig variiert werden k=nnen.
< 742 > Schriften
Page size: 168,00 x 240,00 mm
Beispiel
BUTTON { font: 300 italic 1.3em/1.7em "FB Armada", sans-serif }
BUTTON P { font: menu }
BUTTON P EM { font-weight: bolder }
Wenn die f r Dropdown-Men s verwendete Schrift auf einem bestimmten System beispiels-
weise 9 Punkt Charcoal ist, mit einer Gewichtung von 600, w rden die P-Elemente, die Ablei-
tungen von BUTTON sind, so dargestellt, als g@lte die folgende Regel:
BUTTON P { font: 600 9pt Charcoal }
Weil die zusammenfassende Eigenschaft 'font' jede Eigenschaft, der nicht explizit ein Wert
zugewiesen wird, auf ihren Ausgangswert zur cksetzt, hat das denselben Effekt wie die folgende
Deklaration:
BUTTON P {
font-style: normal;
font-variant: normal;
font-weight: 600;
font-size: 9pt;
line-height: normal;
font-family: Charcoal
}
15.2.6 Generische Schriftfamilien
Generische Schriftfamilien sind ein R ckgriffsmechanismus. Sie sind eine M=glichkeit, wenigs-
tens einen Teil der Absichten des Stylesheet-Autors zu realisieren, falls im schlimmsten Fall
keine der angegebenen Schriften ausgew@hlt werden kann. Einer optimalen typografischen
Steuerung halber sollten in Stylesheets bestimmte benannte Schriften verwendet werden.
Cascading Style Sheets, Level 2
Alle f nf generischen Schriftfamilien sind so definiert, dass es sie in allen CSS-Implementierun-
gen gibt (sie m ssen nicht unbedingt auf f nf verschiedene existierende Schriften abgebildet
werden). Benutzerprogramme sollten sinnvolle Standardauswahlen f r die generischen Schrift-
familien bereitstellen, die die Charakteristika jeder Familie so gut wie m=glich ausdr cken,
innerhalb der Grenzen, die die zugrunde liegende Technologie aufweist.
Den Benutzerprogrammen wird nahe gelegt, den Benutzern zu erlauben, alternative Auswahlen
f r die generischen Schriften festzulegen.
serif
Glyphen von Serifen-Schriften, wie der Begriff in CSS verwendet wird, haben Abschlussstriche,
ausgestellte oder spitz zulaufende Enden oder tats@chlich Serifen-Endungen (inklusive Slab
Serifs). Serifen-Schriften sind normalerweise proportional. H@ufig weisen sie eine gr=ßere
Variation zwischen dicken und d nnen Strichen als Schriften aus der generischen Schriftfamilie
'sans-serif' (serifenlos) auf. CSS verwendet den Begriff 'serif' f r eine Schrift einer beliebigen
Sprachschrift (script), obwohl andere Namen vertrauter f r bestimmte Sprachschriften (script)
sein k=nnen, wie beispielsweise Mincho (Japanisch), Sung oder Song (Chinesisch), Totum oder
Kodig (Koreanisch). Jede auf diese Weise beschriebene Schrift kann verwendet werden, um die
generische 'serif'-Familie darzustellen.
Schriftspezifikation < 743 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Beispiele f r Schriften, die dieser Beschreibung entsprechen, sind unter anderem:
Lateinische Schriften Times New Roman, Bodoni, Garamond, Minion Web, ITC
Stone Serif, MS Georgia, Bitstram, Cyberbit
Griechische Schriften Bitstream Cyberbit
Kyrillische Schriften Adobe Minion Cyrillic, Excelcior Cyrillic Upright, Monotype
Albion 70, Bitstream Cyberbit, ER Bukinst
Hebr@ische Schriften New Peninim, Raanana, Bitstream Cyberbit
Japanische Schriften Ryumin Light-KL, Kyokasho ICA, Futo Min A101
Arabische Schriften Bitstream Cyberbit
Cherokee-Schriften Lo Cicero Cherokee
sans-serif
Glyphen in serifenlosen Schriften, wie der Begriff in CSS verwendet wird, haben Strichenden,
die gerade sind – ohne spitzes Zulaufen, vertikale Abschlussstriche oder andere Verzierungen.
Serifenlose Schriften sind in der Regel proportional. H@ufig weisen sie im Vergleich mit Schrif-
ten aus der 'serif'-Familie geringere Abweichungen zwischen dicken und d nnen Strichen auf.
CSS verwendet den Begriff 'sans-serif', um auf eine Schrift f r eine beliebige Sprachschrift
(script) zu verweisen, obwohl f r bestimmte Sprachschriften (script) andere Namen m=glicher-
weise gebr@uchlicher sind, wie beispielsweise Gothic (Japanisch), Kai (Chinesisch) oder Pathang
(Koreanisch). Jede auf diese Weise beschriebene Schrift kann verwendet werden, um die gene-
rische 'sans-serif'-Familie darzustellen.
Beispiele f r Schriften, die dieser Beschreibung entsprechen, sind unter anderem:
Lateinische Schriften MS Trebuchet, ITC Avant Garde Gothic, MS Arial, MS
Verdana, Univers, Futura, ITC Stone Sans, Gill Sans,
Akzidenz Grotesk, Helvetica
Cascading Style Sheets, Level 2
Griechische Schriften Attika, Typiko New Era, MS Tahoma, Monotype Gill Sans
571, Helvetica Greek
Kyrillische Schriften Helvetica Cyrillic, ER Univers, Lucida Sans Unicode, Bastion
Hebr@ische Schriften Arial Hebrew, MS Tahoma
Japanische Schriften Shin Go, Heisei Kaku Gothic W5
Arabische Schriften MS Tahoma
cursive
Glyphen in kursiven Schriften, wie der Begriff in CSS verwendet wird, haben im Allgemeinen
entweder verbindende Striche oder andere kursive Charakteristika, die ber diejenigen von
geneigten Schriften hinausgehen. Die Glyphen sind teilweise oder vollst@ndig verbunden, und
das Ergebnis sieht mehr wie eine Handschrift oder eine Pinselschrift aus, als wie ein gedrucktes
Buchstabenwerk. Schriften f r einige Sprachschriften (script), wie beispielsweise Arabisch, sind
fast immer kursiv. CSS verwendet den Begriff 'cursive' f r eine Schrift f r Sprachschriften
(script), obwohl in Schriftnamen auch andere Namen verwendet werden wie beispielsweise
Chancery, Brush, Swing oder Script.
< 744 > Schriften
Page size: 168,00 x 240,00 mm
Beispiele f r Schriften, die dieser Beschreibung entsprechen, sind unter anderem:
Lateinische Schriften Caflisch Script, Adobe Poetica, Sanvito, Ex Ponto, Snell
Roundhand, Zapf-Chancery
Kyrillische Schriften ER Architekt
Hebr@ische Schriften Corsiva
Arabische Schriften DecoType Naskh, Monotype Urdu 507
fantasy
Fantasy-Schriften, wie sie in CSS verwendet werden, sind haupts@chlich dekorativ, enthalten
aber immer noch Zeichendarstellungen (im Gegensatz zu Pi- oder Picture-Schriften, die keine
Buchstaben darstellen). Beispiele sind unter anderem:
Lateinische Schriften Alpha Geometrique, Critter, Cottonwood, FB Reactor,
Studz
monospace
Das einzige Kriterium f r eine Monospace-Schrift ist, dass alle Glyphen dieselbe feste Breite
aufweisen. (Das kann dazu f hren, dass einige Schriften, wie beispielsweise Arabisch, eher selt-
sam aussehen.) Der Effekt ist ein Schriftbild @hnlich dem einer manuellen Schreibmaschine.
Diese Schrift wird h@ufig verwendet, um Beispiele f r Computercode darzustellen.
Beispiele f r Schriften, die dieser Beschreibung entsprechen, sind unter anderem:
Lateinische Schriften Courier, MS Courier New, Prestige, Everson Mono
Griechische Schriften MS Courier New, Everson Mono
Kyrillische Schriften ER Kurier, Everson Mono
Japanische Schriften Osaka Monospaced
Cascading Style Sheets, Level 2
Cherokee-Schriften Everson Mono
15.3 Schriftauswahl
Die zweite Phase des CSS2-Schriftmechanismus betrifft die Schriftauswahl, die ein Benutzer-
programm abh@ngig von den vom Autor angegebenen Schrifteigenschaften, verf gbaren Schrif-
ten und so weiter trifft. Die Details f r den Schriftvergleichalgorithmus finden Sie im Folgenden
beschrieben.
Es gibt vier m=gliche Aktionen f r die Schriftauswahl: Namensvergleich, intelligenter Vergleich,
Synthese und Download.
Schriftnamensvergleich
In diesem Fall verwendet das Benutzerprogramm eine bereits existierende, verf gbare Schrift,
die denselben Familiennamen wie die angeforderte Schrift hat. (Beachten Sie, dass das Erschei-
nungsbild und die Metrik m=glicherweise nicht bereinstimmen, wenn die Schrift, die der Autor
Schriftauswahl < 745 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
des Dokuments verwendet hat, und die Schrift auf dem Client-System aus unterschiedlichen
Quellen stammen.) Die Vergleichsinformation ist auf die CSS-Schrifteigenschaften beschr@nkt,
inklusive des Familiennamens. Dies ist die einzige Methode, die in CSS1 verwendet wird.
Intelligenter Schriftvergleich
In diesem Fall verwendet das Benutzerprogramm eine existierende, verf gbare Schrift, die die
beste bereinstimmung mit dem Erscheinungsbild der angeforderten Schrift ergibt. (Beachten
Sie, dass die Metrik m=glicherweise nicht genau bereinstimmt.) Die Vergleichsinformation
enth@lt Informationen ber die Art der Schrift (Text oder Symbol), die Art der Serifen, die
Gewichtung, die Buchstabenh=he, die x-H=he, Steigung, Gef@lle, Neigung usw.
Schriftsynthese
In diesem Fall erzeugt das Benutzerprogramm eine Schrift, die nicht nur ein ganz @hnliches
Erscheinungsbild aufweist, sondern auch in der Metrik mit der angeforderten Schrift berein-
stimmt. Die Syntheseinformation beinhaltet die Vergleichsinformationen und fordert normaler-
weise genauere Werte f r die Parameter, als f r andere Vergleichsschemata verwendet wer-
den. Insbesondere fordert die Synthese eine exakte Breitenmetrik und einen exakten Ersatz
von Zeichen durch Glyphen sowie Positionsinformationen, wenn alle Layouteigenschaften der
angegebenen Schrift beibehalten werden sollen.
Schrift-Download
Schließlich kann das Benutzerprogramm eine Schrift ber das Web laden. Das entspricht in
etwa dem Prozess, der abl@uft, wenn Bilder, Sounds oder Applets ber das Web geladen wer-
den, um sie im aktuellen Dokument anzuzeigen. Es kann hier deshalb ebenso zu gewissen Ver-
z=gerungen kommen, bevor die Seite angezeigt wird.
Die progressive Darstellung ist eine Kombination aus Download und einer der anderen Metho-
den; sie stellt tempor@r eine Ersatzschrift bereit (wozu der Namensvergleich, intelligenter Ver-
gleich oder Synthese verwendet werden), so dass der Inhalt bereits gelesen werden kann, w@h-
Cascading Style Sheets, Level 2
rend die gew nschte Schrift heruntergeladen wird. Nachdem die ben=tigte Schrift erfolgreich
heruntergeladen wurde, ersetzt sie die tempor@re Schrift, hoffentlich ohne dass eine Neudar-
stellung der Seite erforderlich wird.
Hinweis: F r die progressive Darstellung wird Metrikinformation ber die Schrift ben=tigt, um
einen erneuten Layout-Aufbau des Inhalts zu vermeiden, wenn die gew nschte Schrift geladen
und dargestellt wurde. Diese Metrikinformation ist ausreichend umfassend, so dass sie norma-
lerweise nur h=chstens einmal pro Schrift in einem Dokument angegeben werden muss. n
15.3.1 Schriftbeschreibungen und @font-face
Die Schriftbeschreibung stellt die Br cke zwischen der Schriftspezifikation eines Autors und
den Schriftdaten dar. Das sind die Daten, die f r die Formatierung von Text und die Darstellung
der abstrakten Glyphen, auf die die Zeichen abgebildet werden, ben=tigt werden. Schriften
werden anhand von Stylesheet-Eigenschaften beschrieben.
Die Schriftbeschreibung wird der Schriftdatenbank hinzugef gt und dann verwendet, um die
relevanten Schriftdaten auszuw@hlen. Die Schriftbeschreibung enth@lt Deskriptoren, wie bei-
spielsweise die Position der Schriftdaten im Web oder Charakteristika dieser Schriftdaten. Die
< 746 > Schriften
Page size: 168,00 x 240,00 mm
Schriftdeskriptoren werden dar ber hinaus ben=tigt, um die Stylesheet-Schrifteigenschaften
mit bestimmten Schriftdaten zu vergleichen. Der Detailgrad einer Schriftbeschreibung kann
variieren, von einfach nur dem Namen der Schrift bis hin zu einer Liste mit den Breiten jeder
einzelnen Glyphe.
Schriftdeskriptoren k=nnen in drei Kategorien eingeordnet werden:
1. solche, die die Verkn pfung zwischen der CSS-Nutzung der Schrift und der Schriftbeschrei-
bung darstellen (sie haben dieselben Namen wie die entsprechenden CSS-Schrifteigenschaf-
ten)
2. der URI f r die Position der Schriftdaten (im Web)
3. solche, die die Schrift weiter charakterisieren, um eine Verkn pfung zwischen der Schrift-
beschreibung und den Schriftdaten bereitzustellen
Alle Schriftbeschreibungen werden ber die At-Regel @font-face angegeben. Die allgemeine
Form sieht wie folgt aus:
@font-face {<font-description> }
Dabei hat <font-description> die folgende Form:
descriptor: wert;
descriptor: wert;
[...]
descriptor: wert;
Jede @font-face-Regel gibt einen Wert f r jeden Schriftdeskriptor an, entweder implizit oder
explizit. Die nicht explizit angegebenen Werte nehmen in der Regel den f r jeden Deskriptor
in dieser Spezifikation angegebenen Ausgangswert an. Diese Deskriptoren gelten ausschließlich
innerhalb des Kontexts der @font-face-Regel, in der sie definiert sind, und sind nicht auf Ele-
mente der Dokumentsprache anzuwenden. Es gibt also kein Konzept, das beschreibt, auf wel-
che Elemente sich der Deskriptor bezieht, oder das festlegt, ob die Werte von den untergeord-
Cascading Style Sheets, Level 2
neten Elementen geerbt werden.
Die verf gbaren Schriftdeskriptoren sind in sp@teren Abschnitten dieser Spezifikation beschrie-
ben.
Beispiel
Beispielsweise ist nachfolgend die Schrift 'Robson Celtic' definiert und wird in einem
Stylesheet, das in einem HTML-Dokument enthalten ist, verwendet.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>Font test</TITLE>
<STYLE TYPE="text/css" MEDIA="screen, print">
@font-face {
font-family: "Robson Celtic";
src: url("[Link]
}
H1 { font-family: "Robson Celtic", serif }
</STYLE>
</HEAD>
<BODY>
Schriftauswahl < 747 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<H1> Diese dberschrift wird in Robson Celtic dargestellt</H1>
</BODY>
</HTML>
Das Stylesheet (im STYLE-Element) enth@lt eine CSS-Regel, die f r alle H1-Elemente festlegt,
dass sie die Schriftfamilie 'Robson Celtic' verwenden.
Eine CSS1-Implementierung sucht client-seitig nach einer Schrift, deren Familienname und
andere Eigenschaften mit denen von 'Robson Celtic' bereinstimmen. Wenn sie keine entspre-
chende Schrift findet, verwendet sie die f r den Benutzerprogramm spezifische Fallback-Seri-
fenschrift (die definitionsgem@ß existiert).
Ein Benutzerprogramm, das CSS2 implementiert, wertet bei der Suche nach einer Schrift-
beschreibung, die 'Robson Celtic' definiert, zun@chst die @font-face-Regeln aus. Dieses Beispiel
enth@lt eine bereinstimmende Regel. Obwohl diese Regel nicht viele Schriftdaten enth@lt, hat
sie einen URI, unter dem die Schrift f r die Darstellung in diesem Dokument geladen werden
kann. Anderen Applikationen sollten die heruntergeladenen Schriften nicht zur Verf gung
gestellt werden. Wird keine bereinstimmende @font-face gefunden, wendet das Benutzer-
programm denselben Vergleich wie ein Benutzerprogramm an, das CSS1 implementiert hat.
Beachten Sie, dass wenn die Schrift 'Robson Celtic' auf dem Client-System installiert gewesen
w,re, das Benutzerprogramm veranlasst worden w@re, f r die installierte Kopie einen Eintrag in
der Schriftdatenbank vorzunehmen, wie im Abschnitt ber den Algorithmus zum Schriftver-
gleich beschrieben (15.5). Die installierte Kopie h@tte im obigen Beispiel vor der heruntergela-
denen Schrift eine bereinstimmung erzeugt.
CSS1-Implementierungen, die die @font-face-Regel nicht verstehen, treffen auf die =ffnende
geschweifte Klammer und ignorieren alles weitere bis zur bereinstimmenden schließenden
geschweiften Klammer. Diese At-Regel ist konform zu der CSS-Forderung, dass ein aufw@rts-
kompatibles Parsing m=glich sein soll. Die Parser k=nnen diese Regeln ignorieren, ohne einen
Fehler zu melden.
Legt man die Schriftdeskriptoren separat von den Schriftdaten ab, hat das außer der Schriftaus-
wahl und/oder dem Schriftersatz noch weitere Vorteile. Der Schutz der Daten sowie die Repli-
Cascading Style Sheets, Level 2
kationsbeschr@nkungen f r die Schriftdeskriptoren k=nnen sehr viel schw@cher als f r die
vollst@ndigen Schriftdaten sein. Damit k=nnte es m=glich sein, die Schriftdefinition lokal zu
installieren, oder sie zumindest in einem lokalen Cache abzulegen, wenn sie in einem allgemein
zug@nglichen Stylesheet auftritt; daf r ist es nicht erforderlich, mehr als einmal pro angegebener
Schrift auf die vollst@ndige Schriftdefinition ber das Web zuzugreifen.
Wird ein Schrift-Deskriptor dupliziert, dominiert der zuletzt aufgetretene Deskriptor und der
Rest muss ignoriert werden.
Außerdem m ssen alle Deskriptoren ignoriert werden, die vom Benutzerprogramm nicht
erkannt werden oder keinen Sinn f r ihn ergeben. Zuk nftige Versionen von CSS erlauben
m=glicherweise zus@tzliche Deskriptoren, um den Ersatz, den Vergleich oder die Synthese von
Schriften noch besser durchf hren zu k=nnen.
< 748 > Schriften
Page size: 168,00 x 240,00 mm
15.3.2 Deskriptoren f-r die Auswahl einer Schrift: 'font-family',
'font-style', 'font-variant', 'font-weight', 'font-stretch' und
'font-size'
Die folgenden Deskriptoren haben dieselben Namen wie die entsprechenden CSS2-Schrift-
eigenschaften und nehmen einen einzelnen Wert oder eine Liste mit durch Kommas voneinan-
der getrennten Werten an.
Die Werte innerhalb dieser Liste sind dieselben wie die f r die entsprechende CSS2-Eigen-
schaft, außer wenn explizit anders angegeben. Gibt es einen einzelnen Wert, muss eine genaue
bereinstimmung mit diesem Wert vorliegen. Gibt es eine Liste, kann eine beliebiges Listenele-
ment eine bereinstimmung erzeugen. Wird der Deskriptor aus @font-face weggelassen, wird
der Ausgangswert f r den Deskriptor verwendet.
'font-family' (Deskriptor)
Wert: [<family-name> | <generic-family>] [, [<family-name> |
<generic-family>]]*
Ausgangwert: Vom Benutzerprogramm abh@ngig
Medium: Visual
Dies ist der Deskriptor f r den Schriftfamiliennamen einer Schrift. Er nimmt dieselben Werte
wie die Eigenschaft 'font-family' an.
'font-style' (Deskriptor)
Wert: All | [ normal | italic | oblique ] [, normal | italic | oblique]]*
Ausgangswert : All
Cascading Style Sheets, Level 2
Medium : Visual
Dies ist der Deskriptor f r den Stil einer Schrift. Er nimmt dieselben Werte an wie die Eigen-
schaft 'font-style', außer wenn eine Liste erlaubt ist, deren Werte durch Kommas voneinander
getrennt sind.
'font-variant' (Deskriptor)
Wert: [normal | small-caps][,[normal | small-caps]]*
Ausgangswert: Normal
Medium: Visual
Damit gibt CSS an, ob diese Schrift die Kapit@lchen-Variante einer Schrift ist. Sie nimmt diesel-
ben Werte wie die Eigenschaft 'font-variant' an, außer dass eine Liste mit Werten erlaubt ist,
die durch Kommas voneinander getrennt sind.
Schriftauswahl < 749 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Hinweis: Kyrillische Proymo-Schriften k=nnen mit einer 'font-variant' von Kapit@lchen
bezeichnet werden, was eine bessere Konsistenz mit lateinischen Schriften ergibt (und die
zugeh=rige kursive Schrift wird aus demselben Grund mit einem 'font-style' italic beschrif-
tet). n
'font-weight' (Deskriptor)
Wert: all | [normal | bold |100 | 200 | 300 |400 | 500 | 600 | 700 | 800 |
900] [, [normal | bold | 100 | 200 | 300 | 400 | 500 | 600 | 700 |
800 | 900]]*
Ausgangswert: All
Medium: Visual
Dies ist der Deskriptor f r die Gewichtung einer Schrift relativ zu anderen in derselben Schrift-
familie. Er verwendet dieselben Werte wie die Eigenschaft 'font-weight', mit drei Ausnahmen:
1. Relative Schl sselw=rter (bolder, lighter) sind nicht erlaubt.
2. Eine Liste mit durch Kommas voneinander getrennten Werten ist erlaubt f r Schriften, die
mehrere Gewichtungen enthalten.
3. Das zus@tzliche Schl sselwort 'all' ist erlaubt, das heißt, die Schrift erzeugt eine berein-
stimmung f r alle m=glichen Werte; entweder weil sie mehrere Gewichtungen enth@lt oder
weil die Schrift nur eine einzige Gewichtung hat.
'font-stretch' (Deskriptor)
Wert all | [normal | ulstra-condensed | extra-condensed | condensed |
semi-condensed | semi-expanded | expanded | extra-expanded |
Cascading Style Sheets, Level 2
ultra-expanded][, [normal | ultra-condensed | extra-condensed
| condensed | semi-condensed | semi-expanded | expanded |
extra-expanded | ultra-expanded]]*
Ausgangswert: Normal
Medium: Visual
Damit gibt CSS die komprimierte oder gedehnte Schriftform relativ zu anderen Schriften der-
selben Schriftfamilie an. Sie nimmt dieselben Werte an wie die Eigenschaft 'font-stretch', nur
dass hier gilt:
·· Relative Schl sselw=rter (wider, narrower) sind nicht erlaubt.
Eine Liste mit durch Kommas voneinander getrennten Werten ist erlaubt.
· Das Schl sselwort 'all' ist erlaubt.
< 750 > Schriften
Page size: 168,00 x 240,00 mm
'font-size' (Deskriptor)
Wert: all | <length> [, <length>]*
Ausgangswert: All
Medium: Visual
Dies ist der Deskriptor f r die durch diese Schrift unterst tzten Gr=ßen. Es sind nur absolute
L@ngeneinheiten erlaubt, im Gegensatz zur Eigenschaft 'font-size', die sowohl relative als auch
absolute L@ngen und Gr=ßen erlaubt. Eine Liste mit durch Kommas voneinander getrennten
absoluten L@ngen ist erlaubt.
Der Ausgangswert 'all' ist f r die meisten skalierbaren Schriften geeignet, deshalb ist dieser
Deskriptor haupts@chlich f r die Verwendung in einer @font-face f r Bitmap-Schriften oder
skalierbare Schriften geeignet, die darauf ausgelegt sind, in einem begrenzten Bereich von
Schriftgr=ßen gerastert zu werden.
15.3.3 Deskriptoren f-r die Schriftdatenqualifizierung :
'unicode-range'
Der folgende Deskriptor ist optional innerhalb einer Schriftdefinition, wird aber verwendet,
um eine berpr fung oder einen Download einer Schrift zu vermeiden, die nicht ausreichend
viele Glyphen umfasst, um ein bestimmtes Zeichen darzustellen.
'unicode-range' (Deskriptor)
Wert: <urange> [, <urange>]*
Ausgangswert: U+0-7FFFFFFF
Medium: Visual
Cascading Style Sheets, Level 2
Dies ist der Deskriptor f r den Bereich der ISO 10646-Zeichen, die diese Schrift abdeckt.
Die Werte von <urange> werden als hexadezimale Zahlen mit dem Pr@fix „U+“ angegeben, die
den Zeichencodepositionen in ISO 10646 entsprechen ([ISO10646]).
Beispielsweise ist U+05D1 das ISO 10646-Zeichen 'Hebr@ischer Buchstabe bet'. F r Werte
außerhalb der BMP (Basic Multilingual Plane) werden zus@tzliche f hrende Ziffern eingef hrt,
die der Ebenennummer entsprechen. Beispielsweise ist U+A1234 das Zeichen auf Ebene 10 an
der hexadezimalen Codeposition 1234. Zum Zeitpunkt der Drucklegung dieses Buches gab es
keine Zeichen außerhalb der BMP. F hrende Nullen (z. B. 0000004D) sind g ltig aber nicht
erforderlich.
Der Ausgangswert dieses Deskriptors deckt nicht nur die gesamte BMP (Basic Multilingual Pla-
ne) ab, die als U+0-FFFF ausgedr ckt wird, sondern auch das gesamte Repertoire von ISO
10646. Damit besagt der Ausgangswert, dass die Schrift Glyphen f r Zeichen irgendwo in ISO
10646 haben kann. Die Angabe eines Wertes f r 'unicode-range' stellt Informationen bereit,
die die Suche effizient machen, indem ein begrenzter Bereich deklariert wird, in dem die Schrift
Glyphen f r Zeichen haben kann. Die Schrift muss nicht außerhalb dieses Bereichs nach Zei-
chen durchsucht werden.
Schriftauswahl < 751 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Werte k=nnen mit einer beliebigen Anzahl an Stellen angegeben werden. F r einzelne Zahlen
steht das Zeichen '?' f r einen beliebigen Wert, wodurch ein Bereich an Zeichenpositionen
abgedeckt wird. Die Verwendung einer einzelnen Zahl bedeutet also:
Unicode-Bereich: U+20A7
keine Wildcards – es handelt sich um eine einzelne Zeichenposition (das spanische W@h-
rungssymbol f r die Peseta)
Unicode-Bereich: U+215?
eine Wildcard, deckt den Bereich 2150 bis 215F ab (die Br che)
Unicode-Bereich: U+00??
zwei Wildcards, deckt den Bereich 0000 bis 00FF (Latin-1) ab
Unicode-Bereich: U+E??
zwei Wildcards, deckt den Bereich 0E00 bis 0EFF (das Lao-Skript) ab
Ein Zahlenpaar in diesem Format kann mit dem Trennstrich kombiniert werden, um gr=ßere
Bereiche abzudecken. Beispiel:
Unicode-Bereich: U+AC00-D7FF
der Bereich deckt AC00 bis D7FF ab (der Hangul Syllables-Bereich)
Es k=nnen mehrere, durch Kommas voneinander getrennte, nicht fortlaufende Bereiche ange-
geben werden. Wie in allen Listen in CSS, deren Werte durch Kommas voneinander getrennt
sind, wird Whitespace vor und nach einem Komma ignoriert. Beispiel:
Unicode-Bereich: U+370-3FF, U+1F??
Deckt den Bereich 0370 bis 03FF (Modern Greek) und 1F00 bis 1FFF (Ancient polytonic
Greek) ab.
Unicode-Bereich: U+3000-303F, U+3100-312F, U+32??, U+33??, U+4E00-9FFF,
Cascading Style Sheets, Level 2
U+F9000-FAFF, U+FE30-FE4F
In Hinblick auf die Komplexit@t vermutlich der schlimmste Fall, gibt aber sehr pr@zise an,
dass diese (extrem umfangreiche) Schrift nur Chinesische Zeichen aus ISO 10646 enth@lt,
ohne irgendwelche Zeichen, die eindeutig japanisch oder koreanisch sind. Der Bereich
erstreckt sich von 3000 bis 303F (CJK-Symbole und Interpunktion) plus 3100 bis 312F (Bo-
pomofo) plus 3200 bis 32FF (inklusive CJK-Buchstaben und Monate) plus 3300 bis 33FF
(CJK-Kompatibilit@tszone) plus 4E00 bis 9FFF (vereinheitlichte CJK-Ideographien) plus F900
bis FAFF (CJK-Kompatibilit@ts-Ideographien) plus FE30 bis FE4F (CJK-Kompatibilit@tsfor-
men).
Eine angenehmere Darstellung f r eine typische chinesische Schrift w@re:
Unicode-Bereich: U+3000-33FF, U+4E00-9FFF
Unicode-Bereich: U+11E00-121FF
Diese Schrift deckt eine vorgeschlagene Registrierung f r Aztekische Piktogramme ab, n@m-
lich den Bereich von 1E00 bis 21FF in Ebene 1.
Unicode-Bereich: U+1A00-1A1F
Diese Schrift deckt eine vorgeschlagene Registrierung f r Irish Ogham ab, n@mlich den
Bereich 1A00 bis 1A1F.
< 752 > Schriften
Page size: 168,00 x 240,00 mm
15.3.4 Deskriptor f-r numerische Werte: 'units-per-em'
Der folgende Deskriptor gibt die Anzahl der „Einheiten“ pro em an; diese Einheiten k=nnen
von verschiedenen anderen Deskriptoren genutzt werden, um verschiedene L@ngen auszudr -
cken, 'units-per-em' ist also erforderlich, wenn andere Deskriptoren davon abh@ngig sind.
'units-per-em' (Deskriptor)
Wert: <number>
Ausgangswert: Nicht definiert
Medium: Visual
Dies ist der Deskriptor f r die Anzahl der Koordinateneinheiten im em-Quadrat, die Gr=ße
des Entwurfsrasters, auf dem die Glyphen angelegt wurden.
15.3.5 Deskriptor f-r den Verweis: 'src'
Dieser Deskriptor ist erforderlich, um auf tats@chliche Schriftdaten zu verweisen, egal ob
herunterzuladen oder lokal installiert.
'src' (Deskriptor)
Wert: [<uri> [format(<string> [, <string>]*)] | <font-face-name>] [,
<uri> [format(<string> [, <string>]*)] | <font-face-name>]*
Ausgangswert: Nicht definiert
Medium: Visual
Cascading Style Sheets, Level 2
Dies ist eine nach Priorit@ten geordnete Liste externer Referenzen und/oder lokal installierter
Schriftnamen, die durch Kommas voneinander getrennt sind. Die externe Referenz verweist
auf die Schriftdaten im Web. Das ist erforderlich, wenn die Web-Schrift heruntergeladen wer-
den soll. Die Schriftressource kann eine Untermenge der Quellschrift sein, beispielsweise kann
sie nur die Glyphen enthalten, die f r die aktuelle Seite oder f r eine Menge von Seiten ben=tigt
werden.
Die externe Referenz besteht aus einem URI, gefolgt von einem optionalen Hinweis auf das
Format der Schriftressource, die unter diesem URI zu finden ist; diese Information sollte von
den Clients verwendet werden, um zu vermeiden, dass Links auf Schriften in Formaten verfolgt
werden, die nicht genutzt werden k=nnen. Wie bei jedem Hypertext-Verweis kann es auch
noch andere Formate geben, aber der Client weiß besser, was wahrscheinlich vorhanden ist,
und das ist besser, als zu versuchen, Dateinamenerweiterungen in URIs auszuprobieren.
Der Formathinweis enth@lt eine Liste mit Formatstrings, die durch Kommas voneinander
getrennt sind und die wohlbekannte Schriftformate angeben. Das Benutzerprogramm erkennt
den Namen von Schriftformaten, die es unterst tzt, und vermeidet das Herunterladen von
Schriften in Formaten, die es nicht erkennt.
Schriftauswahl < 753 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Nachfolgend sehen Sie eine erste Liste mit Formatstrings, die durch diese Spezifikation definiert
sind und Formate darstellen, die sehr wahrscheinlich von Implementierungen auf verschiedenen
Plattformen verwendet werden:
String Schriftformat Beispiele f-r
[Link]
Erweiterungen
„truedoc-pfr“ TrueDoc Portable Font Resource .pfr
„embedded-opentype“ Embedded OpenType .eot
„type-1“ PostScript Type 1 .pfb, .pfa
„truetype“ TrueType .ttf
„opentype“ OpenType, inclusive TrueType .ttf
Open
„truetype-gx“ TrueType mit GX-Erweiterungen
„speedo“ Speedo
„intellifont“ Intellifont
Wie andere URIs in CSS kann der URI partiell sein; in diesem Fall wird er relativ zur Position
des Stylesheets aufgel=st, das das @font-face enth@lt.
Der lokal installierte <font-face-name> ist der vollst@ndige Schriftname, der in Anf hrungs-
zeichen gesetzt werden muss, weil er beliebige Zeichen enthalten kann, unter anderem Leer-
zeichen und Interpunktionszeichen. Zudem muss er in „local(“ und „)“eingeschlossen sein.
Beispiel
src: url("[Link]
Cascading Style Sheets, Level 2
Ein vollst@ndiger URI, und es stehen keine Informationen ber die dort verf gbaren
Schriftformate zur Verf gung
src: local("BT Century 751 No. 2 Semi Bold Italic")
Verweist auf eine bestimmte Schriftform einer lokal installierten Schrift
src: url("../fonts/bar") format("truedoc-pfr")
Ein partieller URI, f r den es eine Schrift im TrueDoc-Format gibt
src: url("[Link] format("opentype", "intellifont")
Ein vollst@ndiger URI, in diesem Fall f r ein (serverseitiges) Skript, das zwei verschie-
dene Formate erzeugen kann – OpenType und Intellifont
src: local("T-26 Typeka Mix"), url("[Link] format("type-1")
Es sind zwei Alternativen angegeben: erstens eine lokal installierte Schrift und zwei-
tens eine herunterladbare Schrift, die im Type 1-Format zur Verf gung steht.
Der Zugriff auf lokal installierte Schriften erfolgt ber den <font-face-name>. Der Schriftname
ist nicht wirklich eindeutig, und er ist auch nicht wirklich unabh@ngig von der Plattform oder
vom Schriftformat, aber momentan stellt er die beste M=glichkeit dar, lokal installierte Schrift-
daten zu identifizieren. Das kann erfolgen, indem der Bereich der ISO 10646-Zeichenposi-
tionen angegeben wird, f r die die Schrift Glyphen unterst tzt (siehe 'unicode-range').
< 754 > Schriften
Page size: 168,00 x 240,00 mm
15.3.6 Deskriptoren f-r den Vergleich: 'panose-1', 'stemv', 'stemh',
'slope', 'cap-height', 'x-height', 'ascent' und 'descent'
Diese Deskriptoren sind optional f r eine CSS2-Definition, k=nnen aber f r einen intelligenten
Schriftvergleich oder eine Schriftgr=ßenanpassung verwendet werden, wenn der Autor dies
w nscht.
'panose-1' (Deskriptor)
Wert: [<integer>]{10}
Ausgangswert: 0000000000
Medium: visual
Dieser Deskriptor f r die Panose-1-Nummer besteht aus zehn dezimalen Integern, die durch
Whitespace voneinander getrennt sind. Eine Liste mit durch Kommas voneinander getrennten
Werten ist f r diesen Deskriptor nicht erlaubt, weil es erforderlich sein kann, dass f r das Pano-
se-1-System ein Wertebereich verglichen wird. Der Ausgangswert ist Null, das heißt, „alle“ f r
jede PANOSE-Stelle; alle Schriften stimmen mit der Panose-Nummer berein, wenn dieser
Wert verwendet wird. Die Verwendung des Panose-1-Deskriptors ist f r lateinische Schriften
sehr zu empfehlen. Weitere Informationen finden Sie in Anhang C.
'stemv' (Deskriptor)
Wert: [<integer>]{10}
Ausgangswert: 0000000000
Medium: Visual
Cascading Style Sheets, Level 2
Dies ist der Deskriptor f r die vertikale Strichbreite der Schrift. Falls dieser Wert nicht defi-
niert ist, wird der Deskriptor f r den Vergleich nicht herangezogen. Wird dieser Deskriptor
verwendet, muss auch der Deskriptor 'units-per-em' verwendet werden.
'stemh' (Deskriptor)
Wert: <number>
Ausgangswert: Nicht definiert
Medium: Visual
Dies ist der Deskriptor f r die horizontale Strichbreite der Schrift. Falls dieser Wert nicht defi-
niert ist, wird der Deskriptor nicht f r den Vergleich verwendet. Wird dieser Deskriptor ver-
wendet, muss auch der Deskriptor 'units-per-em' verwendet werden.
Schriftauswahl < 755 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
'slope' (Deskriptor)
Wert: <number>
Ausgangswert: Nicht definiert
Medium: Visual
Dies ist der Deskriptor f r den vertikalen Strichwinkel der Schrift.
'cap-height' (Deskriptor)
Wert: <number>
Ausgangswert: Nicht definiert
Medium: Visual
Dies ist der Deskriptor f r der H=he von Großbuchstaben-Glyphen der Schrift. Falls der Wert
nicht definiert ist, wird der Deskriptor nicht f r den Vergleich verwendet. Wird dieser
Deskriptor verwendet, muss auch der Deskriptor 'units-per-em' verwendet werden.
'x-height' (Deskriptor)
Wert: <number>
Ausgangswert: Nicht definiert
Medium: Visual
Dies ist der Deskriptor f r die H=he von Kleinbuchstaben-Glyphen der Schrift. Falls der Wert
Cascading Style Sheets, Level 2
nicht definiert ist, wird der Deskriptor nicht f r den Vergleich verwendet. Wird dieser
Deskriptor verwendet, muss auch der Deskriptor 'units-per-em' verwendet werden. Dieser
Deskriptor kann sehr praktisch sein, wenn die Eigenschaft 'font-size-adjust' verwendet wird,
weil f r die Berechnung des z-Werts der in Frage kommenden Schriften sowohl die Schrift-
gr=ße als auch die x-H=he erforderlich ist; deshalb ist zu empfehlen, diesen Deskriptor zu ver-
wenden.
'ascent' (Deskriptor)
Wert: <number>
Ausgangswert: Nicht definiert
Medium: Visual
Dies ist der Deskriptor f r die maximale H=he der Schrift ohne Ber cksichtigung der Akzente.
Falls der Wert nicht definiert ist, wird der Deskriptor nicht f r den Vergleich verwendet. Wird
dieser Deskriptor verwendet, muss auch der Deskriptor 'units-per-em' verwendet werden.
< 756 > Schriften
Page size: 168,00 x 240,00 mm
'descent' (Deskriptor)
Wert: <number>
Ausgangswert: Nicht definiert
Medium: Visual
Dies ist der Deskriptor f r die maximale Tiefe der Schrift ohne Ber cksichtigung der Akzente.
Falls der Wert nicht definiert ist, wird der Deskriptor nicht f r den Vergleich verwendet. Wird
dieser Deskriptor verwendet, muss auch der Deskriptor 'units-per-em' verwendet werden.
15.3.7 Deskriptoren f-r die Synthese: 'widths', 'bbox' und
'definition-src'
Die Synthese einer Schrift bedeutet, dass zumindest die Breitenmaße der angegebenen Schrift
zur Deckung gebracht werden. F r die Synthese muss also diese Maßinformation zur Verf gung
stehen. Analog dazu ben=tigt auch die progressive Darstellung die Breitenmaße, um zu vermei-
den, dass der Inhalt neu angeordnet werden muss, nachdem die tats@chliche Schrift geladen
wurde. Obwohl die nachfolgenden Deskriptoren optional f r eine CSS2-Definition sind, wer-
den einige davon ben=tigt, wenn der Autor eine Synthese (oder eine progressive Darstellung
ohne Neuanordnung des Inhalts) w nscht. Sobald die tats@chliche Schrift zur Verf gung steht,
sollte die Ersatzschrift dagegen ausgetauscht werden. Jeder dieser vorhandenen Deskriptoren
wird verwendet, um eine bessere oder schnellere Ann@herung an die gew nschte Schrift zu
erreichen.
Von diesen Deskriptoren sind die wichtigsten 'widths' und 'bbox', die verwendet werden, um
eine Neuanordnung des Texts zu verhindern, wenn die tats@chliche Schrift zur Verf gung steht.
Dar ber hinaus k=nnen diese Deskriptoren in der Menge der f r den Vergleich verwendeten
Deskriptoren verwendet werden, um eine bessere Synthese der tats@chlichen Schriftdarstel-
Cascading Style Sheets, Level 2
lung zu erzielen.
'widths' (Deskriptor)
Wert: [<urange>]? [<number>]+ [,[<urange>]? <number>]+]
Ausgangswert: Nicht definiert
Medium: Visual
Dies ist der Deskriptor f r die Glyphen-Breiten. Der Wert ist eine Liste mit durch Kommas
voneinander getrennten <urange>-Werten, jeweils gefolgt von einer oder mehreren Glyphen-
Breiten. Wird dieser Deskriptor verwendet, muss auch der Deskriptor 'units-per-em' verwen-
det werden.
Wenn <urange> weggelassen wird, wird ein Bereich von U+0-7FFFFFFF angenommen, der alle
Zeichen und ihre Glyphen abdeckt. Falls nicht gen gend Glyphen-Breiten zur Verf gung stehen,
wird der letzte in der Liste repliziert, um diese U-Range abzudecken. Falls zu viele Breiten ange-
geben sind, werden die berfl ssigen ignoriert.
Schriftauswahl < 757 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Beispiel
widths: U+4E00-4E1F 1736 1874 1692
widths: U+1A?? 1490, U+215? 1473 1838 1927 1684 1356 1792
1815 1848 1870 1492 1715 1745 1584 1992 1978 1770
Im ersten Beispiel ist ein Bereich von 32 Zeichen vorgegeben, von 4E00 bis 4E1F. Der Glyph,
der dem ersten Zeichen entspricht (4E00), hat eine Breite von 1736, der zweite hat eine Breite
von 1874, und der dritte von 1692. Weil nicht gen gend Breiten bereitgestellt wurden, wird
die letzte Breite repliziert, um den restlichen angegebenen Bereich abzudecken. Das zweite
Beispiel setzt eine einzige Breite, 1490, f r den gesamten Bereich von 256 Glyphen und dann
explizite Breiten f r einen Bereich von 16 Glyphen.
Dieser Deskriptor kann nicht mehrere Glyphen beschreiben, die einem einzelnen Zeichen oder
Ligaturen mehrerer Zeichen entsprechen. Damit kann dieser Deskriptor nur f r Schriften
(scripts) verwendet werden, die keine kontextabh@ngigen Formen oder verpflichtende Liga-
turen aufweisen. Dennoch ist er in diesen Situationen praktisch. Schriften (scripts), die eine 1:n-
oder n:n-Abbildung von Zeichen auf Glyphen verlangen, k=nnen momentan diesen Deskriptor
nicht verwenden, um eine Schriftsynthese zu aktivieren, obwohl sie dennoch Schriften herun-
terladen oder einen intelligenten Vergleich durchf hren k=nnen.
'bbox' (Deskriptor)
Wert: <number>, <number>, <number>, <number>
Ausgangswert: Nicht definiert
Medium: Visual
Dies ist der Deskriptor f r die maximal umschließende Box der Schrift. Der Wert ist eine Liste
mit durch Kommas voneinander getrennten genau vier Zahlen, die in ihrer Reihenfolge die
Cascading Style Sheets, Level 2
Koordinaten unten links x, unten links y, oben rechts x und oben rechts y der umschließenden
Box f r die gesamte Schrift angeben.
'definition-src' (Deskriptor)
Wert: <uri>
Ausgangswert: Nicht definiert
Medium: Visual
Die Schriftdeskriptoren k=nnen entweder innerhalb der Schriftdefinition im Stylesheet angege-
ben werden, oder in einer separaten Schriftdefinitionsressource, die durch einen URI festgelegt
wird. Der letztere Ansatz kann den Netzwerkverkehr reduzieren, wenn mehrere Stylesheets
auf dieselben Schriften verweisen.
< 758 > Schriften
Page size: 168,00 x 240,00 mm
15.3.8 Deskriptoren f-r die Ausrichtung : 'baseline', 'centerline',
'mathline' und 'topline'
Diese optionalen Deskriptoren werden verwendet, um Ausf hrungen unterschiedlicher Schrif-
ten (scripts) aneinander auszurichten.
'baseline' (Deskriptor)
Wert: <number
Ausgangswert: 0
Medium: Visual
Dies ist der Deskriptor f r die untere Grundlinie einer Schrift. Falls dieser Deskriptor einen
anderen als den Standardwert (ungleich Null) erh@lt, muss auch der Deskriptor 'units-per-em'
verwendet werden.
'centerline' (Deskriptor)
Wert: <number
Ausgangswert: Nicht definiert
Medium: Visual
Dies ist der Deskriptor f r die zentrale Grundlinie einer Schrift. Falls der Wert nicht definiert
ist, kann der Benutzerprogramm verschiedene Heuristiken anwenden, wie beispielsweise den
Mittelwert der ascent- und descent-Werte.
Cascading Style Sheets, Level 2
'mathline' (Deskriptor)
Wert: <number>
Ausgangswert: Nicht definiert
Medium: Visual
Dies ist der Deskriptor f r die mathematische Grundlinie einer Schrift. Falls er nicht definiert
ist, kann das Benutzerprogramm die zentrale Grundlinie verwenden. Wird dieser Deskriptor
verwendet, muss auch der Deskriptor 'units-per-em' verwendet werden.
'topline' (Deskriptor)
Wert: <number>
Ausgangswert: Nicht definiert
Medium: Visual
Schriftauswahl < 759 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Dies ist der Deskriptor f r die obere Grundlinie der Schrift. Falls er nicht definiert ist, kann das
Benutzerprogramm einen Ann@herungswert verwenden, wie beispielsweise ascent. Falls dieser
Deskriptor verwendet wird, muss auch der Deskriptor 'units-per-em' verwendet werden.
15.3.9 Beispiele
Die folgende Liste an Schriften sei gegeben:
Swiss 721 light light & light italic
Swiss 721 roman, bold, italic, bold italic
Swiss 721 medium medium & medium italic
Swiss 721 heavy heavy & heavy italic
Swiss 721 black black, black italic, & black #2
Swiss 721 Condensed roman, bold, italic, bold italic
Swiss 721 Expanded roman, bold, italic, bold italic
Beispiel
Die folgenden Schriftbeschreibungen k=nnten verwendet werden, um sie f r den
Download zur Verf gung zu stellen.
@font-face {
font-family: "Swiss 721";
src: url("[Link]"); /* Swiss 721 light */
font-style: normal, italic;
font-weight: 200;
}
@font-face {
font-family: "Swiss 721";
Cascading Style Sheets, Level 2
src: url("[Link]"); /* Die regul]re Swiss 721 */
}
@font-face {
font-family: "Swiss 721";
src: url("[Link]"); /* Swiss 721 medium */
font-style: normal, italic;
font-weight: 500;
}
@font-face {
font-family: "Swiss 721";
src: url("[Link]"); /* Swiss 721 heavy */
font-style: normal, italic;
font-weight: 700;
}
@font-face {
font-family: "Swiss 721";
src: url("[Link]"); /* Swiss 721 black */
font-style: normal, italic;
font-weight: 800,900; /* Beachten Sie das interessante Problem, dass
die 900 italic nicht existiert */
}
@font-face {
font-family: "Swiss 721";
< 760 > Schriften
Page size: 168,00 x 240,00 mm
src: url([Link]); /* Komprimierte Swiss 721 */
font-stretch: condensed;
}
@font-face {
font-family: "Swiss 721";
src: url([Link]); /* Gestreckte Swiss 721 */
font-stretch: expanded;
}
15.4 Schriftcharakteristika
15.4.1 Einleitung
In diesem Abschnitt sind die Schriftcharakteristika aufgelistet, die sich als praktisch f r den
client-seitigen Schriftvergleich, Synthese und Download f r heterogene Plattformen, die auf das
Web zugreifen, erwiesen haben. Die Daten m ssen f r jedes Medium geeignet sein, das Schrif-
ten aus dem Web nutzen muss, und zwar ber einen anderen Weg als das physische Einbetten
der Schriftdaten in das Medium.
Diese Charakteristika werden herangezogen, um Schriften zu beschreiben. Sie sind nicht spezi-
fisch f r CSS oder Stylesheets. In CSS wird jede Charakteristik durch einen Schrift-Deskriptor
ausgedr ckt. Diese Charakteristika k=nnten auch auf VRML-Knoten oder CGM Application
Structures oder Java API oder alternative Stylesheet-Sprachen abgebildet werden. Schriften, die
von einem Medium geladen und in einem Proxy-Cache gespeichert wurden, k=nnten von einem
anderen Medium wiederverwendet werden, wodurch Download-Zeit und Netzwerkband-
breite eingespart wird, vorausgesetzt, dass durchg@ngig ein allgemeines System von Schrift-
charakteristika verwendet wird.
Nachfolgend sehen Sie eine unvollst@ndige Liste mit Beispielen f r solche Medien:
2D-Vektorformate
··
Cascading Style Sheets, Level 2
Computer Graphics Metafile
Simple Vector Format
3D-Grafikformat
··VRML
3DMF
Objekt-einbettende Technologien
··Java
Active-X
·Obliq
15.4.2 [Link] Schriftname
Dies ist der vollst@ndige Name einer bestimmten Schrift oder Schriftfamilie. Normalerweise
enth@lt er eine Vielzahl nicht standardisierter Textbezeichner oder Ausschmckungen, die an
den Schriftfamiliennamen angef gt sind. Er kann auch einen Gießereinamen oder eine Abk r-
zung davon enthalten, h@ufig dem Schriftfamiliennamen vorangestellt. Er wird nur verwendet,
Schriftcharakteristika < 761 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
um auf lokal installierte Schriften zu verweisen, weil sich das Format des ausf hrlichen Namens
zwischen den verschiedenen Plattformen erheblich unterscheiden kann. Er muss in Anf hrungs-
zeichen stehen.
Beispielsweise k=nnen sich der Schriftfamilienname der TrueType-Schrift und der PostScript-
Name hinsichtlich der Verwendung von Leerzeichen, Interpunktionszeichen und in der Abk r-
zung bestimmter W=rter unterscheiden (z. B. um verschiedene Beschr@nkungen f r die L@nge
von Namen auf dem System- oder Druckerinterpreter zu ber cksichtigen). Beispielsweise sind
in einem PostScript-Namen keine Leerzeichen erlaubt, in vollst@ndigen Schriftnamen dagegen
sind sie gebr@uchlich. Die TrueType-Namenstabelle kann auch den PostScript-Namen enthal-
ten, der keine Leerzeichen enth@lt.
Der Name der Schriftdefinition ist wichtig, weil es sich dabei um die Verkn pfung zu den lokal
installierten Schriften handelt. Es ist wichtig, dass der Name robust ist, sowohl in Hinblick auf
Plattform- als auch auf Applikationsunabh@ngigkeit. Aus diesem Grund sollte ein Name verwen-
det werden, der nicht f r bestimmte Applikationen oder Sprachen spezifisch ist.
Die ideale L=sung w@re, einen Namen zu verwenden, der alle Schriftdatenmengen eindeutig
identifiziert. Einen solchen Namen gibt es in der aktuellen Praxis f r Schriftdaten nicht. Schrif-
ten mit demselben Schriftnamen k=nnen ber mehrere Deskriptoren variieren. Einige dieser
Deskriptoren, wie beispielsweise verschiedene Glyphen-S@tze in der Schrift, k=nnen irrelevant
sein, wenn die betreffenden Glyphen in der Schrift enthalten sind. Andere Deskriptoren, wie
beispielsweise verschiedene Breitenmaße, machen Schriften desselben Namens inkompatibel.
Es scheint nicht m=glich zu sein, eine Regel zu definieren, die die Inkompatibilit@ten immer
erkennt und die Verwendung einer perfekt passenden lokalen Kopie der Schriftdaten eines
bestimmten Namens nicht verhindert. Deshalb wird nur der Bereich der ISO 10646-Zeichen
verwendet, um bereinstimmungen f r den Schriftnamen zu qualifizieren.
Weil es ein prim@res Ziel f r den Schriftnamen in der Schriftdefinition ist, einem Benutzerpro-
gramm die Entscheidung zu berlassen, ob es eine lokale Kopie der angegebenen Schriftdaten
gibt, muss es sich dabei um einen Namen handeln, der in allen legitimen Kopien der Schrift-
daten enthalten ist. Andernfalls k=nnte aufgrund fehlender bereinstimmungen in der lokalen
Cascading Style Sheets, Level 2
Kopie unn=tiger Netzverkehr erzeugt werden.
15.4.3 Koordinaten-Einheiten im em-Quadrat
Bestimmte Werte wie beispielsweise Breitenmaße werden in Einheiten ausgedr ckt, die in
Relation zu einem abstrakten Quadrat stehen, dessen H=he die beabsichtigte Distanz zwischen
den Zeilen derselben Typengr=ße ist. Dieses Quadrat wird auch als das em-Quadrat bezeichnet.
Es handelt sich dabei um das Entwurfsraster, auf dem die Glyphen-Umrisse definiert sind. Der
Wert dieses Deskriptors gibt an, in wie viele Einheiten das em-Quadrat unterteilt ist.
Gebr@uchliche Werte sind zum Beispiel 250 (Intellifont), 1000 (Type 1) und 2048 (TrueType,
TrueType GX und OpenType).
Wenn dieser Wert nicht angegeben ist, wird es unm=glich, zu erkennen, was ein Schriftmaß
bedeutet. Beispielsweise hat eine Schrift Kleinbuchstaben-Glyphen der H=he 450, eine andere
hat kleinere der H=he 890! Bei den Zahlen handelt es sich um Bruchteile; die erste Schrift hat
450/1000, die zweite 890/2048, was tats@chlich kleiner ist.
< 762 > Schriften
Page size: 168,00 x 240,00 mm
15.4.4 Zentrale Grundlinie
Dies gibt die Position im em-Quadrat auf der zentralen Grundlinie an. Die zentrale Grundlinie
wird von ideographischen Schriften (scripts) f r die Ausrichtung verwendet, so wie die untere
Grundlinie f r lateinische, griechische und kyrillische Schriften (scripts).
15.4.5 Schriftcodierung
Jeder Schrift ist explizit oder implizit eine Tabelle zugeordnet, die Schriftcodierungstabelle, die
angibt, welche Zeichen die einzelnen Glyphen darstellen. Diese Tabelle wird auch als Kodie-
rungsvektor bezeichnet.
Viele Schriften enthalten mehrere Glyphen f r dasselbe Zeichen. Welche dieser Glyphen ver-
wendet werden sollte, ist entweder von den Sprachregeln oder den Vorlieben des Entwicklers
abh@ngig.
Im Arabischen beispielsweise haben alle Buchstaben vier (oder zwei) verschiedene Formen,
abh@ngig davon, ob der Buchstabe am Wortanfang, in der Mitte, am Ende oder isoliert verwen-
det wird. Es handelt sich in allen F@llen um denselben Buchstaben, deshalb gibt es nur ein Zei-
chen im Quelldokument, aber beim Ausdruck sieht er jedes Mal anders aus.
Außerdem gibt es Schriften, die es dem Grafikdesigner berlassen, unter verschiedenen bereit-
gestellten alternativen Umrissen zu w@hlen. Leider stellt CSS2 noch keine M=glichkeit bereit,
diese Alternativen auszuw@hlen. Momentan wird immer der Standardumriss aus diesen Schrif-
ten ausgew@hlt.
15.4.6 Schriftfamilienname
Gibt den Familiennamenanteil des Schriftnamens an. Beispielsweise ist der Familienname f r
Helvetica-Bold gleich Helvetica, und der Familienname von ITC Stone Serif Semibold Italic ist
ITC Stone Serif. Einige Systeme behandeln die Ausschm ckungen, die sich auf komprimierte
oder gedehnte Schriften beziehen, so, als handele es sich dabei um einen Teil des Familien-
Cascading Style Sheets, Level 2
namens.
15.4.7 Glyphenbreite
Dies ist eine Liste mit Breiten (im Entwurfsraster) f r den Glyphen, die jedem einzelnen Zei-
chen entsprechen. Die Liste ist nach ISO 10646-Codepunkten sortiert. Breiten k=nnen nicht
sinnvoll angegeben werden, wenn mehr als ein Glyph auf dasselbe Zeichen abgebildet wird oder
es zwingend vorgeschriebene Ligaturen gibt.
15.4.8 Horizontale Strichbreite
Dieser Wert bezieht sich auf den dominanten Strich der Schrift. Es kann zwei oder mehr ent-
worfene Breiten geben. Beispielsweise unterscheidet sich der vertikale Hauptstrich von
Roman-Zeichen von den d nnen Strichen der serifen-behafteten „M“ und „N“, und außerdem
kann es unterschiedliche Breiten f r Großbuchstaben- und Kleinbuchstabenzeichen innerhalb
derselben Schrift geben. Außerdem k=nnen alle Striche, entweder dem Entwurf entsprechend
oder aufgrund eines Fehlers, etwas unterschiedliche Breiten haben.
Schriftcharakteristika < 763 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
15.4.9 HUhe von Großbuchstaben-Glyphen
Dieses Maß stellt die y-Koordinate des oberen Abschlusses von flachen Großbuchstaben in
lateinischen, griechischen und kyrillischen Scripts dar, gemessen von der Grundlinie aus. Dieser
Deskriptor ist nicht unbedingt praktisch f r Schriften, die keine Glyphen aus diesen Scripts ent-
halten.
15.4.10 HUhe von Kleinbuchstaben-Glyphen
Dieses Maß stellt die y-Koordinate des oberen Abschlusses von nicht mit Akzenten versehe-
nen, nicht aufsteigenden Kleinbuchstaben in lateinischen, griechischen und kyrillischen Schriften
(scripts) dar, gemessen von der Grundlinie aus. Buchstaben mit flachem oberen Abschluss wer-
den verwendet, wobei alle optischen Korrekturzonen ignoriert werden. Dies wird manchmal
als Verh@ltnis zwischen Kleinbuchstaben- und Großbuchstabenh=hen verwendet, um Schrift-
familien vergleichen zu k=nnen.
Dieser Deskriptor ist nicht sinnvoll f r Schriften, die keine Glyphen aus diesen Scripts enthal-
ten. Weil die H=he von Kleinbuchstaben und Großbuchstaben h@ufig als Verh@ltnis f r den
Vergleich verschiedener Schriften verwendet wird, kann es sinnvoll sein, sowohl die Kleinbuch-
staben- als auch die Großbuchstabenh=he f r Scripts ohne Klein/Großschreibung wie beispiels-
Cascading Style Sheets, Level 2
weise Hebr@isch auf denselben Wert zu setzen, w@hrend f r einen gemischten Text aus lateini-
schem und hebr@ischem Text die hebr@ischen Zeichen normalerweise auf eine H=he zwischen
den Großbuchstaben- und Kleinbuchstabenh=hen der lateinischen Schrift gesetzt werden.
15.4.11 Untere Grundlinie
Gibt die Position des em-Quadrats der unteren Grundlinie an. Die untere Grundlinie wird von
lateinischen, griechischen und kyrillischen Schriften (scripts) f r die Ausrichtung verwendet, so
wie die obere Grundlinie f r von Sanskrit abgeleitete Schriften (scripts) verwendet wird.
< 764 > Schriften
Page size: 168,00 x 240,00 mm
15.4.12 Mathematische Grundlinie
Gibt die Position im em-Quadrat der mathematischen Grundlinie an. Die mathematische
Grundlinie wird f r die Ausrichtung mathematischer Symbole verwendet, so wie die untere
Grundlinie f r lateinische, griechische und kyrillische Schriften (scripts) verwendet wird.
15.4.13 Maximale umschließende Box
Die maximale umschließende Box ist das kleinste Rechteck, das den Umriss umschließt, der
entsteht, wenn alle Glyphen der Schrift mit ihren Urspr ngen am selben Punkt angelegt und
dann gezeichnet werden.
15.4.14 Maximale nicht-akzentuierte HUhe
Dieses Maß f r das em-Quadrat verl@uft von der Grundlinie zum h=chsten Punkt, die jeder ein-
zelne Glyph erreichen kann, ohne Akzente oder diakritische Markierungen.
15.4.15 Maximale nicht-akzentuierte Tiefe
Dieses Maß f r das em-Quadrat verl@uft von der Grundlinie zum niedrigsten Punkt, den ein
Cascading Style Sheets, Level 2
Glyph erreichen kann, ausschließlich aller Akzente oder diakritischen Markierungen.
15.4.16 Panose-1-Zahl
Panose-1 ist eine Klassifizierungs- und Vergleichstechnologie f r TrueType-Schriften nach dem
Industriestandard. Das PANOSE-System besteht aus einer Menge von zehn Zahlen, die die
Schl sselattribute einer lateinischen Schrift kategorisieren, eine Klassifizierungsprozedur zum
Erstellen dieser Zahlen und einer Mapper-Software, die die n@chstm=gliche Schrift ermittelt,
die zu einer vorgegebenen Menge an Schriftformen passt. Das System k nnte mit einigen Ab@n-
Schriftcharakteristika < 765 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
derungen auch f r Griechisch und Kyrillisch verwendet werden, es ist jedoch nicht f r Schriften
(scripts) ohne Klein-/Großschreibung und ideographische Schriften (scripts; Hebr@isch, Arme-
nisch, Arabisch, Chinesisch/Japanisch/Koreanisch) geeignet.
15.4.17 Bereich der ISO 10646-Zeichen
Zeigt das Glyphen-Repertoire der Schrift bez glich ISO 10646 (Unicode) an. Weil dieses
schwach besetzt ist (die meisten Schriften decken nicht das gesamte ISO 10646 ab), listet dieser
Deskriptor Bl=cke oder Bereiche auf, die eine teilweise bereinstimmung aufweisen (es wird
keine Garantie f r eine komplette Abdeckung gegeben), und wird verwendet, um ungeeignete
Schriften auszuschließen (solche, die die erforderlichen Glyphen nicht enthalten). Er bietet kei-
nen Hinweis darauf, dass die Schrift definitiv die erforderlichen Glyphen enth@lt, sondern nur,
ob es sinnvoll ist, sie herunterzuladen, und sie einzusehen. Weitere Hinweise auf informative
Dokumente finden Sie in [ISO10646].
Diese Methode ist erweiterbar auf zuk nftige Reservierungen von Zeichen in Unicode, ohne
die Syntax zu @ndern und ohne existierenden Inhalt ung ltig zu machen.
Schriftformate, die diese Information nicht enthalten, weder explizit noch indirekt, k=nnen
diese Charakteristik dennoch verwenden, aber der Wert muss vom Dokument- oder Style-
sheet-Autor bereitgestellt werden.
Es gibt noch andere Klassifizierungen in Schriften (scripts) wie beispielsweise das Monotype-
System (siehe [MONOTYPE]) und ein vorgeschlagenes ISO-Skriptsystem. Sie sind noch nicht
erweiterbar.
Aufgrund dessen wird in dieser Spezifikation die Klassifizierung von Glyphen-Repertoires nach
dem Bereich der ISO 10646-Zeichen verwendet, die durch eine bestimmte Schrift dargestellt
werden k=nnen. Dieses System ist erweiterbar, so dass es jede zuk nftige Reservierung ab-
decken kann.
15.4.18 Obere Grundlinie
Cascading Style Sheets, Level 2
Gibt die Position im em-Quadrat der oberen Grundlinie an. Die obere Grundlinie wird von
Sanskrit abgeleiteten Schriften (scripts) f r die Ausrichtung verwendet, so wie die untere
Grundlinie f r lateinische, griechische und kyrillische Schriften (scripts) verwendet wird.
15.4.19 Vertikale Strichbreite
Dies ist die Breite der vertikalen (oder ann@hernd vertikalen) Striche f r Glyphen. Diese Infor-
mation wird h@ufig nur als Hinweis bereitgestellt und steht in einigen Schriftformaten nicht f r
den direkten Zugriff zur Verf gung. Dieses Maß sollte f r den dominanten vertikalen Strich in
der Schrift verwendet werden, weil es unterschiedliche Gruppierungen vertikaler Striche geben
k=nnte (zum Beispiel einen Hauptstrich und einen helleren Strich, wie beispielsweise f r ein
großes M oder N).
15.4.20 Vertikaler Strichwinkel
Dies ist der Winkel der dominanten vertikalen Striche der Schrift, angegeben in Grad im
Gegenuhrzeigersinn von der Vertikalen. Der Wert ist negativ f r Schriften, die nach rechts
geneigt sind, wie es bei fast allen kursiven Schriften der Fall ist. Dieser Deskriptor kann auch
< 766 > Schriften
Page size: 168,00 x 240,00 mm
f r geneigte Schriften, schr@ge Schriften, Handschriften und im Allgemeinen f r alle Schriften,
deren vertikalen Striche nicht genau vertikal sind, verwendet werden. Ein Wert ungleich Null
weist nicht unbedingt auf eine kursive Schrift hin.
15.5 Algorithmus zum Schriftvergleich
Diese Spezifikation erweitert den in der CSS1-Spezifikation enthaltenen Algorithmus. Dieser
Algorithmus reduziert sich auf den Algorithmus aus der CSS1-Spezifikation, wenn die Autor-
und die Leser-Stylesheets keine @font-face-Regeln enthalten.
Der Vergleich von Deskriptoren mit Schriftarten muss sorgf@ltig erfolgen. Die Deskriptoren
werden in genau definierter Reihenfolge betrachtet, um sicherzustellen, dass die Ergebnisse die-
ses Vergleichsprozesses so konsistent wie m=glich ber die verschiedenen Benutzerpro-
gramme hinweg sind (vorausgesetzt, jedem von ihnen wird dieselbe Bibliothek mit Schriftarten
und Schriftdeskriptoren pr@sentiert). Dieser Algorithmus kann optimiert werden, voraus-
gesetzt, eine Implementierung verh@lt sich so, als w@re der Algorithmus exakt befolgt worden.
1. Das Benutzerprogramm erzeugt eine Datenbank relevanter Schriftartendeskriptoren aller
Schriften, die es kennt (oder es greift darauf zu). Falls es zwei Schriften mit genau denselben
Deskriptoren gibt, wird eine davon ignoriert. Das Benutzerprogramm erkennt eine Schrift,
wenn:
·· sie lokal installiert wurde,
sie unter Verwendung einer @font-face-Regel in einem der Stylesheets deklariert wur-
de, das mit dem aktuellen Dokument verkn pft ist oder darin enthalten ist,
· sie im Standard-Stylesheet des Benutzerprogramms verwendet wird, das es konzeptuell
in allen Benutzerprogramme gibt, und von dem angenommen wird, dass es vollst@ndige
@font-face-Regeln f r alle Schriften enth@lt, die das Benutzerprogramm f r die Stan-
darddarstellung verwendet, sowie @font-face-Regeln f r die f nf speziellen generischen
Schriftfamilien (siehe 'font-family'), die in CSS2 definiert sind.
2. In einem bestimmten Element und f r jedes Zeichen in diesem Element setzt das Benutzer-
Cascading Style Sheets, Level 2
programm die Schrifteigenschaften zusammen, die auf dieses Element anzuwenden sind.
Unter Verwendung der vollst@ndigen Eigenschaftenmenge verwendet das Benutzerpro-
gramm den Deskriptor 'font-family', um versuchsweise eine Schriftfamilie auszuw@hlen. Der
Vergleich mit einem bereinstimmenden Familiennamen ist also erfolgreich, bevor der Ver-
gleich mit einem anderen Deskriptor erfolgt. Die restlichen Eigenschaften werden mit der
Familie verglichen, gem@ß den Vergleichskriterien, die zusammen mit jedem Deskriptor
angegeben sind. Falls es auch bereinstimmungen f r alle restlichen Eigenschaften gibt, ist
dies die passende Schriftart f r das betreffende Element.
3. Falls es keine bereinstimmende Schriftart innerhalb der in Schritt 2 verarbeiteten 'font-fa-
mily' gibt, k=nnen Benutzerprogramme, die einen intelligenten Vergleich implementieren, wei-
termachen, indem sie weitere Deskriptoren auswerten wie beispielsweise x-H=he, Gly-
phenbreiten und Panose-1, um eine andere vorl@ufige Schriftfamilie zu finden. Falls es ber-
einstimmungen f r alle restlichen Deskriptoren gibt, ist das die geeignete Schriftart f r das
betreffende Element. Der 'font-family'-Deskriptor, der sich in den CSS2-Eigenschaften
widerspiegelt, ist die Schriftfamilie, die angefordert wurde, und nicht der Name, den die
intelligent verglichene Schrift aufweist. Benutzerprogramme, die keinen intelligenten Ver-
gleich implementieren, werden diese Schritt abbrechen.
Algorithmus zum Schriftvergleich < 767 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
4. Falls es keine bereinstimmende Schriftart f r die in Schritt 3 verarbeitete 'font-family' gibt,
k=nnen Benutzerprogramme, die das Herunterladen von Schriften implementieren fortfahren. Sie
k=nnen den Deskriptor 'src' der in Schritt 2 oder 3 identifizierten Schriftart auswerten, um
eine verf gbare Netzressource zu finden, die das korrekte Format hat. Falls es bereinstim-
mungen f r alle restlichen Deskriptoren gibt, ist das die passende Schriftart f r das betref-
fende Element, und das Benutzerprogramm kann versuchen, diese Schriftressource herunter-
zuladen. Das Benutzerprogramm kann diesen Download entweder blockieren, oder mit dem
n@chsten Schritt fortfahren, w@hrend die Schriften heruntergeladen werden. Benutzerpro-
gramme, die das Herunterladen von Schriften nicht implementieren, oder die nicht an ein
Netzwerk angeschlossen sind oder wo die Benutzereinstellungen das Herunterladen von
Schriften verhindern, oder wo die angeforderte Ressource aus irgendeinem Grund nicht zur
Verf gung steht, oder wo die heruntergeladene Schrift aus irgendeinem Grund nicht verwen-
det werden kann, verhalten sich so, als w@re dieser Schritt fehlgeschlagen.
5. Falls es keine bereinstimmende Schriftart innerhalb der in Schritt 3 verarbeiteten 'font-fa-
mily' gibt, k=nnen Benutzerprogramme, die die Schriftsynthese implementieren, weiterma-
chen und andere Deskriptoren auswerten wie beispielsweise die 'x-height', Glyphenbreite
und 'panose-1', um eine vorl@ufige Schriftfamilie f r die Synthese zu finden. Wenn es ber-
einstimmungen f r alle restlichen Deskriptoren gibt, ist das die geeignete Schriftart f r das
betreffende Element, und die Synthese der Schrift kann beginnen. Benutzerprogramme, die
keine Schriftsynthese implementieren, verhalten sich so, als w@re dieser Schritt fehlgeschla-
gen.
6. Wenn die Schritte 3, 4 und 5 alle fehlschlagen und es eine n@chste alternative 'font-family' in
der Schriftmenge gibt, erfolgt eine Wiederholung ab Schritt 2 mit der n@chsten alternativen
'font-family'.
7. Wenn es eine bereinstimmende Schriftart gibt, diese aber keine Glyphen f r die aktuellen
Zeichen enth@lt, und wenn es eine n@chste alternative 'font-family' in den Schriftmengen
gibt, erfolgt eine Wiederholung ab Schritt 2 mit der n@chsten alternativen 'font-family'. Der
'unicode-range'-Deskriptor kann verwendet werden, um schnell Schriftarten auszuschlie-
Cascading Style Sheets, Level 2
ßen, die nicht die korrekten Glyphen enthalten. Wenn der 'unicode-range'-Deskriptor
anzeigt, dass eine Schrift Glyphen im korrekten Bereich enth@lt, kann sie vom Benutzerpro-
gramm daraufhin ausgewertet werden, ob sie den ben=tigten Glyphen enth@lt.
8. Falls es keine Schrift innerhalb der in 2 ausgew@hlten Familie gibt, wird der geerbte oder
vom Benutzerprogramm abh@ngige 'font-family'-Wert verwendet, und es erfolgt eine Wie-
derholung ab Schritt 2, unter Verwendung der besten bereinstimmung, die mit Hilfe die-
ser Schrift erzielt werden kann. Wenn ein bestimmtes Zeichen mit dieser Schrift nicht
angezeigt werden kann, sollte das Benutzerprogramm darauf hinweisen, dass ein Zeichen
nicht angezeigt wird (z. B. mit dem Glyphen f r „fehlendes Zeichen“).
9. Benutzerprogramme, die eine progressive Darstellung implementieren und ausstehende
Schrift-Downloads haben, verwenden die heruntergeladene Schrift als Schriftfamilie. Wenn
in der heruntergeladenen Schrift einige Glyphen fehlen, die die vor bergehende progressive
Schrift enthielt, wird die heruntergeladene Schrift f r dieses Zeichen nicht verwendet, und
es wird weiterhin die tempor@re Schrift verwendet.
Hinweis: Der obige Algorithmus kann optimiert werden, um zu vermeiden, dass f r jedes Zei-
chen die CSS2-Eigenschaften erneut eingesehen werden m ssen. n
< 768 > Schriften
Page size: 168,00 x 240,00 mm
Die Pro-Deskriptor-Vergleichsregeln aus Schritt (2) sehen wie folgt aus:
1. 'font-style' wird als Erstes ausprobiert. 'italic' ist erf llt, wenn es entweder eine Schrift in
der Schriftdatenbank des Benutzerprogramms gibt, die mit dem CSS-Schl sselwort 'italic'
(bevorzugt) oder 'oblique' versehen ist. Andernfalls m ssen die Werte genau bereinstim-
men, sonst schl@gt 'font-style' fehl.
2. 'font-variant' wird als N@chstes ausprobiert. 'normal' bringt eine bereinstimmung mit
einer Schrift, die nicht als 'small-caps' gekennzeichnet ist; 'small-caps' stimmt mit einer
Schrift berein (1), die als 'small-caps' gekennzeichnet ist, mit einer Schrift (2), in der die
Kapit@lchen synthetisiert sind, oder mit einer Schrift (3), in der alle Kleinbuchstaben durch
Großbuchstaben ersetzt sind. Eine Kapit@lchen-Schrift kann synthetisiert werden, indem
alle Großbuchstaben aus einer normalen Schrift elektronisch skaliert werden.
3. 'font-weight' wird als N@chstes verglichen und schl@gt niemals fehl. (Siehe 'font-weight'
unten.)
4. 'font-size' muss innerhalb eines vom Benutzerprogramm angegebenen Toleranzmaßes ber-
einstimmen. (Normalerweise werden Gr=ßen f r skalierbare Schriften auf das n@chste
ganze Pixel aufgerundet, w@hrend die Toleranz f r Bitmap-Schriften mindestens 20% betra-
gen k=nnte.) Weitere Berechnungen, z. B. durch 'em'-Werte in anderen Eigenschaften,
basieren auf dem verwendeten 'font-size'-Wert, nicht auf dem angegebenen.
15.5.1 Schriftgewichtungswerte auf Schriftnamen abbilden
Die 'font-weight'-Eigenschaftswerte werden auf einer numerischen Skala dargestellt, wobei der
Wert '400' (oder 'normal') der normalen Textdarstellung f r diese Familie entspricht. Der die-
ser Schrift zugeordnete Gewichtungsname ist normalerweise Book, Regular, Roman, Normal
oder manchmal auch Medium. Die Zuordnung anderer Gewichtungen innerhalb einer Familie
f r die numerischen Gewichtungswerte soll nur die Reihenfolge der Gewichtungen innerhalb
dieser Familie beibehalten. Die Benutzerprogramme m ssen Namen Werte zuordnen, und
zwar so, dass die visuelle Reihenfolge beibehalten wird; eine Schrift, die auf einen Wert abgebil-
Cascading Style Sheets, Level 2
det wird, darf nicht heller sein als Schriften, die auf kleinere Werte abgebildet werden. Es gibt
keine Garantien, wie ein Benutzerprogramm Schriften innerhalb einer Familie auf Gewichtungs-
werte abbildet. Die folgende Heuristik zeigt, wie die Zuweisung normalerweise erfolgt:
· Falls die Schriftfamilie bereits eine numerische Skala mit neun Werten verwendet (wie z. B.
OpenType), sollten die Schriftgewichtungen direkt abgebildet werden.
· Falls es sowohl eine mit Medium als auch eine mit Book, Regular, Roman oder Normal
bezeichnete Schrift gibt, wird die Medium-Schrift normalerweise '500' zugeordnet.
·· Die Schrift mit der Bezeichnung 'Bold' entspricht h@ufig dem Gewichtungswert '700'.
Falls es weniger als 9 Gewichtungen in der Familie gibt, sieht der Standardalgorithmus f r
das Ausf llen der „L=cher“ wie folgt aus. Wenn '500' nichts zugewiesen ist, wird ihm die-
selbe Schrift wie '400' zugewiesen. Bleibt einer der Werte '600', '700', '800' oder '900' nicht
belegt, wird ihnen dieselbe Schrift wie dem n@chst dunkleren Schl sselwort zugewiesen,
falls es einen solchen gibt, andernfalls die n@chst hellere Schrift. Falls '300', '200' oder '100'
unbelegt sind, werden sie dem n@chst helleren zugeordneten Schl sselwort zugewiesen,
falls es ein solches gibt, andernfalls das n@chst dunklere.
Es gibt keine Garantie, dass es eine dunklere Schrift f r jeden der 'font-weight'-Werte gibt; bei-
spielsweise kann es sein, dass einige Schriften nur eine normale und eine fette Darstellung auf-
weisen, w@hrend andere acht verschiedene Darstellungen kennen.
Algorithmus zum Schriftvergleich < 769 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Die beiden folgenden Beispiele zeigen typische Zuordnungen.
Beispiel
Angenommen, in der Familie „Rattlesnake“ gibt es vier Gewichtungen, von der hellsten
bis zur dunkelsten: Regular, Medium, Bold, Heavy.
Erstes Beispiel f r die Zuordnung der Schriftgewichtung:
Verf-gbare Schriften Zuordnungen LUcher ausf-llen
„Rattlesnake Regular“ 400 100, 200, 300
„Rattlesnake Medium“ 500
„Rattlesnake Bold“ 700 600
„Rattlesnake Heavy“ 800 900
Angenommen, es gibt sechs Gewichtungen in der Familie „Ice Prawn“: Book, Medium,
Bold, Heavy, Black, ExtraBlack. Beachten Sie, dass das Benutzerprogramm in diesem
Beispiel entschieden hat, „Ice Prawn ExtraBlack“ keinen numerischen Wert zuzuwei-
sen.
Zweites Beispiel f r die Zuordnung der Schriftgewichtung:
Verf-gbare Schriften Zuordnungen LUcher f-llen
„Ice Prawn Book“ 400 100, 200, 300
„Ice Prawn Medium“ 500
„Ice Prawn Bold“ 700 600
„Ice Prawn Heavy“ 800
„Ice Prawn Black“ 900
Cascading Style Sheets, Level 2
„Ice Prawn ExtraBlack“ (keine)
15.5.2 Beispiele f-r den Schriftvergleich
Das folgende Beispiel definiert eine bestimmte Schrift, Alabama Italic. Eine Panose-Schrift-
beschreibung und einen Quell-URI f r das Laden einer TrueType-Server-Schrift sind ebenfalls
bereitgestellt. Deskriptoren f r die Schriftgewichtung und den Schriftstil liegen vor, um die
Schrift zu beschreiben. Die Deklaration besagt, dass die Gewichtung auch mit allen Anforde-
rungen im Bereich zwischen 300 und 500 bereinstimmt. Die Schriftfamilie ist Alabama, der
ausf hrliche Schriftname ist Alabama Italic.
@font-face {
src: local("Alabama Italic"),
url([Link] format("truetype");
panose-1: 2 4 5 2 5 4 5 9 3 3;
font-family: Alabama, serif;
< 770 > Schriften
Page size: 168,00 x 240,00 mm
font-weight: 300, 400, 500;
font-style: italic, oblique;
}
Das folgende Beispiel gruppiert drei physische Schriften zu einer virtuellen Schrift mit erweiter-
ter Abdeckung. In jedem Fall wird im src-Deskriptor der ausf hrliche Schriftname angegeben,
um zu erm=glichen, dass lokal installierte Versionen bevorzugt verwendet werden, falls sie zur
Verf gung stehen. Eine vierte Regel verweist auf eine Schrift mit derselben Abdeckung, die
jedoch innerhalb einer einzigen Ressource enthalten ist.
@font-face {
font-family: Excelsior;
src: local("Excelsior Roman"), url("[Link] format("intellifont");
unicode-range: U+??; /* Latin-1 */
}
@font-face {
font-family: Excelsior;
src: local("Excelsior EastA Roman"), url("[Link] format("intellifont");
unicode-range: U+100-220; /* Latin Extended A and B */
}
@font-face {
font-family: Excelsior;
src: local("Excelsior Cyrillic Upright"), url("[Link]
format("intellifont");
unicode-range: U+4??; /* Cyrillic */
}
@font-face {
font-family: Excelsior;
src: url("[Link] format("truedoc");
unicode-range: U+??,U+100-220,U+4??;
}
Das n@chste Beispiel k=nnte man im Standard-Stylesheet des Benutzerprogramms finden. Es
Cascading Style Sheets, Level 2
implementiert die generische CSS2-Schriftfamilie serif, indem es sie auf eine Vielzahl von seri-
fen-behafteten Schriften abbildet, die auf verschiedenen Plattformen existieren k=nnen. Es wer-
den keine Maße angegeben, weil diese zwischen den m=glichen Alternativen variieren.
@font-face {
src: local("Palatino"),
local("Times New Roman"),
local("New York"),
local("Utopia"),
url("[Link]
font-family: serif;
font-weight: 100, 200, 300, 400, 500;
font-style: normal;
font-variant: normal;
font-size: all
}
Algorithmus zum Schriftvergleich < 771 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
16 Text
Die in den folgenden Abschnitten definierten Eigenschaften beeinflussen die visuelle Darstellung
von Zeichen, Leerzeichen, W=rtern und Abs@tzen.
16.1 Einr-ckung: die 'text-indent'-Eigenschaft
'text-indent'
Wert: <length> | <percentage | inherit
Ausgangswert: 0
Angewendet auf: Elemente auf Blockebene
Vererbt: Ja
Prozentwerte: Beziehen sich auf die Breite des umschließenden Blocks
Medium: Visual
Diese Eigenschaft gibt die Einr ckung der ersten Textzeile in einem Block an. Genauer gesagt,
sie gibt die Einr ckung der ersten Box an, die in die erste Zeilen-Box des Blocks einfließt. Die
Box wird relativ zur linken Kante der Zeilenbox einger ckt (f r ein Rechts-nach-Links-Layout
relativ zur rechten Kante). Benutzerprogramme sollten diese Einr ckung als Leerzeichen dar-
stellen.
Die Werte haben die folgenden Bedeutungen:
<length>
Die Einr ckung erfolgt um einen feststehenden Betrag.
Cascading Style Sheets, Level 2
<percentage>
Die Einr ckung erfolgt um einen Prozentsatz der Breite des umschließenden Blocks.
Der Wert 'text-indent' kann negativ sein, aber es gibt von der Implementierung abh@ngige
Grenzen.
Beispiel
Das folgende Beispiel bewirkt eine Texteinr ckung um '3em'.
P { text-indent: 3em }
Anmerkung der bersetzer: Wendet man das obige Beispiel auf die HTML-Fas-
sung dieses Textes an, erh@lt man f r einen Textabschnitt weiter unten in diesem Kapi-
tel etwa folgende Darstellung:
< 772 > Text
Page size: 168,00 x 240,00 mm
Cascading Style Sheets, Level 2
16.2 Ausrichtung: die 'text-align'-Eigenschaft
'text-align'
Wert: left | right | center | justify | <string> | inherit
Ausgangswert: Vom Benutzerprogramm und der Schreibrichtung abh@ngig
Angewendet auf: Elemente auf Blockebene
Vererbt: Ja
Prozentwerte: N/A
Medium: Visual
Ausrichtung: die 'text-align'-Eigenschaft < 773 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Diese Eigenschaft beschreibt, wie Inline-Inhalt eines Blocks ausgerichtet wird. Die Werte haben
die folgenden Bedeutungen:
left, right, center und justify
Richtet einen Text linksb ndig, rechtsb ndig, zentriert bzw. beidseitig aus.
<string>
Gibt einen String an, nach dem die Zellen einer Tabelle ausgerichtet werden (detaillierte
Informationen und ein Beispiel finden Sie im Abschnitt 17.5.4 ber die horizontale Ausrich-
tung in einer Spalte). Dieser Wert gilt nur f r Tabellenzellen. Wird er f r andere Elemente
gesetzt, wird er wie 'left' oder 'right' behandelt, abh@ngig davon, ob 'direction' 'ltr' oder 'rtl'
ist.
Ein Textblock ist ein Stapel aus Zeilen-Boxen. F r 'left', 'right' und 'center' gibt diese Eigenschaft
an, wie die inzeiligen Boxen innerhalb jeder Zeilen-Box entlang der linken oder rechten Seiten
der Zeilen-Box ausgerichtet sind; die Ausrichtung erfolgt nicht relativ zum Viewport. Im Fall
von 'justify' kann das Benutzerprogramm die inzeiligen Boxen zus@tzlich strecken, um sie an
ihren Positionen auszurichten. (Weitere Informationen finden Sie auch unter 'letter-spacing'
und 'word-spacing', siehe weiter unten).
Beispiel
Beachten Sie, dass 'text-align' in diesem Beispiel vererbt ist, und deshalb f r alle Ele-
mente auf Blockebene innerhalb des DIV-Elements mit 'class=center' der Inline-Inhalt
zentriert ist.
[Link] { text-align: center }
Hinweis: Welcher Algorithmus f r die eigentliche Ausrichtung verwendet wird, ist vom Benut-
zerprogramm und der geschriebenen Sprache abh@ngig.
Konforme Benutzerprogramme d rfen den Wert 'justify' als 'left' oder 'right' interpretieren,
Cascading Style Sheets, Level 2
abh@ngig davon, ob die Standardschreibrichtung des Elements von links nach rechts oder von
rechts nach links ist. n
16.3 Ausschm-ckung
16.3.1 Unterstreichen , berstreichen , Durchstreichen und Blinken:
die 'text-decoration'-Eigenschaft
'text-decoration'
Wert: None | [underline | | overline | | line-through | | blink ] | inherit
Ausgangswert: None
Angewendet auf: Alle Elemente
Vererbt: Nein (siehe Text)
Prozentwerte: N/A
Medium: Visual
< 774 > Text
Page size: 168,00 x 240,00 mm
Diese Eigenschaft beschreibt Ausschm ckungen, die dem Text eines Elements hinzugef gt wer-
den. Wird die Eigenschaft f r ein Element auf Blockebene angegeben, beeinflusst sie alle Ablei-
tungen des Elements auf Inline-Ebene. Wird sie f r ein Element auf Inline-Ebene angegeben
(oder betrifft sie dieses), beeinflusst sie auch alle von dem Element erzeugten Boxen. Hat das
Element keinen Inhalt oder keinen Textinhalt (z. B. das IMG-Element in HTML), m ssen Benut-
zerprogramme diese Eigenschaft ignorieren .
Die Werte haben die folgenden Bedeutungen:
none
Erzeugt keine Textausschm ckung.
underline
Jede Textzeile ist unterstrichen.
overline
Jede Textzeile hat eine berstreichung.
line-through
Jede Textzeile ist mittig durchgestrichen.
blink
Der Text blinkt (er wechselt zwischen sichtbar und unsichtbar). Konforme Benutzerpro-
gramme m ssen diesen Wert nicht unterst tzen.
Die f r die Textausschm ckung ben=tigten Farben sollen vom Wert der 'color'-Eigenschaft
abgeleitet werden.
Die Eigenschaft wird nicht vererbt, aber die abgeleiteten Boxen einer Block-Box sollten mit
derselben Ausschm ckung formatiert werden (z. B. sollten sie alle unterstrichen dargestellt
sein). Die Farbe der Ausschm ckungen sollte immer dieselbe bleiben, selbst wenn die abgelei-
teten Elemente andere 'color'-Werte haben.
Beispiel
Cascading Style Sheets, Level 2
Im folgenden Beispiel f r HTML wird der Textinhalt aller A-Elemente, die als Hyperlinks
dienen, unterstrichen dargestellt:
A[href] { text-decoration: underline }
16.3.2 Textschatten: die 'text-shadow'-Eigenschaft
'text-shadow'
Wert: none | [<color | | <length> <length> <length>?,]* [<color> | |
<length> <length> <length>?] | inherit
Ausgangswert: None
Angewendet auf: Alle Elemente
Vererbt: Nein (siehe Text)
Prozentwerte: N/A
Medium: Visual
Ausschm#ckung < 775 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Diese Eigenschaft nimmt eine Liste durch Kommas voneinander getrennter Schatteneffekte
entgegen, die auf den Text des Elements angewendet werden. Die Schatteneffekte werden in
der angegebenen Reihenfolge angewendet und k=nnen sich somit berlagern, aber sie ber-
lagern niemals den eigentlichen Text. Schatteneffekte ver@ndern die Gr=ße einer Box nicht,
k=nnen sich aber ber ihre Grenzen hinaus erstrecken. Die Stapelebene der Schatteneffekte ist
dieselbe wie f r das eigentliche Element.
Jeder Schatteneffekt muss einen Abstand f r den Schatten und kann optional einen berblend-
radius und eine Schattenfarbe angeben.
Ein Schattenabstand wird mit zwei <length>-Werten angegeben, die den Abstand vom Text
spezifizieren. Der erste L@ngenwert bestimmt den horizontalen Abstand zur rechten Textseite.
Ein negativer Wert f r die horizontale L@nge platziert den Schatten links vom Text. Der zweite
L@ngenwert gibt den vertikalen Abstand unterhalb des Texts an. Ein negativer Wert f r die ver-
tikale L@nge platziert den Schatten oberhalb des Textes.
Optional kann nach dem Schattenabstand ein berblendradius angegeben werden. Der ber-
blendradius ist ein L@ngenwert, der die Grenzen des berblendeffekts bestimmt. Der genaue
Algorithmus f r die Berechnung des berblendeffekts ist nicht vorgegeben.
Optional kann vor oder hinter den L@ngenwerten des Schatteneffekts ein Farbwert angegeben
werden. Der Farbwert wird als Grundlage f r den Schatteneffekt verwendet. Wird keine Farbe
angegeben, wird stattdessen auf den Wert der 'color'-Eigenschaft zur ckgegriffen.
Textschatten k=nnen in Kombination mit den Pseudo-Elementen :first-letter und :first-line ver-
wendet werden.
Beispiel
Das folgende Beispiel setzt einen Textschatten rechts und unterhalb des Elementtexts.
Weil keine Farbe angegeben wurde, hat der Schatten dieselbe Farbe wie das eigentliche
Element, und weil kein berblendradius angegeben ist, wird der Textschatten langsam
ausgeblendet:
Cascading Style Sheets, Level 2
H1 { text-shadow: 0.2em 0.2em }
Das n@chste Beispiel platziert einen Schatten rechts und unterhalb des Elementtexts. Der
Schatten hat eine 5px breiten berblendradius und ist rot.
H2 { text-shadow: 3px 3px 5px red }
Das n@chste Beispiel gibt eine Liste mit Schatteneffekten an. Der erste Schatten liegt rechts und
unterhalb des Elementtexts und ist rot ohne berblendung. Der zweite Schatten berlagert
den ersten Schatteneffekt, er ist gelb, wird langsam ausgeblendet und links und unterhalb des
Texts platziert. Der dritte Schatteneffekt wird rechts und oberhalb des Texts platziert. Weil
f r den dritten Schatteneffekt keine Schattenfarbe angegeben ist, wird der Wert der 'color'-
Eigenschaft des Elements verwendet:
H2 { text-shadow: 3px 3px red, yellow -3px 3px 2px, 3px -3px }
< 776 > Text
Page size: 168,00 x 240,00 mm
Betrachten Sie das folgende Beispiel:
[Link] {
background: white;
color: white;
text-shadow: black 0px 0px 5px;
}
Hier haben die 'background'- und 'color'-Eigenschaften denselben Wert, und die 'text-
shadow'-Eigenschaft wird verwendet, um einen „Sonnenfinsterniseffekt“ zu erzeugen:
Hinweis: Diese Eigenschaft ist in CSS1 nicht definiert. Einige Schatteneffekte (wie beispiels-
weise der aus dem letzten Beispiel) zeigt diesen Text in Benutzerprogrammen, die nur CSS1
unterst tzen, m=glicherweise unsichtbar an. n
16.4 Buchstaben- und [Link]: die 'letter-spacing'-
und 'word-spacing'-Eigenschaften
'letter-spacing'
Wert: normal | <length> | inherit
Ausgangswert: Normal
Angewendet auf: Alle Elemente
Vererbt: Ja
Cascading Style Sheets, Level 2
Prozentwerte: N/A
Medium: Visual
Diese Eigenschaft gibt das Abstandsverhalten zwischen Textzeichen an. Die Werte haben die
folgenden Bedeutungen:
normal
Der Abstand ist der normale Abstand f r die aktuelle Schrift. Dieser Wert erlaubt, dass das
Benutzerprogramm den Abstand zwischen Zeichen @ndert, um Text auszurichten.
<length>
Dieser Wert gibt den Abstand zwischen den Zeichen zus,tzlich zu dem Standardabstand
zwischen Zeichen an. Werte k=nnen negativ sein, aber es kann von der jeweiligen Imple-
mentierung abh@ngige Grenzen geben. Benutzerprogramme d rfen den Leeraum zwischen
den Buchstaben nicht weiter vergr=ßern oder verkleinern, um Text auszurichten.
Buchstaben- und Wortabst,nde < 777 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Algorithmen f r die Zeichenabst@nde sind vom Benutzerprogramm abh@ngig. Die Zeichen-
abst@nde k=nnen auch durch die Ausrichtung beeinflusst werden (siehe auch die Beschreibung
der 'text-align'-Eigenschaft oben).
Beispiel
In diesem Beispiel wird der Abstand zwischen Zeichen in BLOCKQUOTE-Elementen
um '0,1 em' vergr=ßert:
BLOCKQUOTE { letter-spacing: 0.1em }
Im folgenden Beispiel ist es dem Benutzerprogramm nicht erlaubt, den Abstand zwischen den
Zeichen zu ver@ndern:
BLOCKQUOTE { letter-spacing: 0cm } /* Wie '0' */
Anmerkung der bersetzer: Die Formatierungsanweisung
[Link] { font-family: monospace;
font-weight: bolder;
letter-spacing: 1em; }
l@sst die HTML-Zeile
<span class="gesperrt">Im Namen des Volkes</span>
wie folgt erscheinen:
Cascading Style Sheets, Level 2
Wenn der resultierende Abstand zwischen zwei Zeichen nicht derselbe wie der Standard-
abstand ist, sollten die Benutzerprogramme keine Ligaturen verwenden.
Konforme Benutzerprogramme k=nnten den Wert der 'letter-spacing'-Eigenschaft als 'normal'
interpretieren.
'word-spacing'
Wert: normal | <length> | inherit
Ausgangswert: Normal
Angewendet auf: Alle Elemente
Vererbt: Ja
Prozentwerte: N/A
Medium: Visual
< 778 > Text
Page size: 168,00 x 240,00 mm
Diese Eigenschaft gibt das Abstandsverhalten zwischen W=rtern an. Die Werte haben die fol-
genden Bedeutungen:
normal
Der normale Abstand zwischen W=rtern, wie durch die aktuelle Schrift und/oder das
Benutzerprogramm definiert.
<length>
Dieser Wert gibt den Abstand zwischen W=rtern zus,tzlich zum Standardabstand zwischen
W=rtern an. Die Werte k=nnen negativ sein, aber m=glicherweise gibt es von der Imple-
mentierung abh@ngige Obergrenzen.
Algorithmen f r den Wortabstand sind vom Benutzerprogramm abh@ngig. Der Wortabstand
wird außerdem durch die Ausrichtung beeinflusst (siehe auch die Informationen zur 'text-
align'-Eigenschaft).
Beispiel
In diesem Beispiel wird der Wortabstand zwischen jedem Wort in H1-Elementen um
'1em' erh=ht.
H1 { word-spacing: 1em }
Konforme Benutzerprogramme k=nnen den Wert der 'word-spacing'-Eigenschaft als 'normal'
interpretieren.
16.5 Großschreibung: die 'text-transform'-Eigenschaft
'text-transform'
Cascading Style Sheets, Level 2
Wert: capitalize | uppercase | lowercase | none | inherit
Ausgangswert: None
Angewendet auf: Alle Elemente
Vererbt: Ja
Prozentwerte: N/A
Medium: Visual
Diese Eigenschaft steuert die Effekte zur Großschreibung von Text. Die Werte haben die fol-
genden Bedeutungen:
capitalize
Schreibt das erste Zeichen eines jeden Wortes in Großbuchstaben.
uppercase
Wandelt alle Zeichen eines jeden Wortes in Großbuchstaben um.
Großschreibung: die 'text-transform'-Eigenschaft < 779 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
lowercase
Wandelt alle Zeichen eines jeden Wortes in Kleinbuchstaben um.
none
Keine Effekte zur Großschreibung.
Die eigentliche Umwandlung ist f r jeden dieser F@lle von der geschriebenen Sprache abh@ngig.
M=glichkeiten, die Sprache eines Elements festzustellen, finden Sie in RFC 2070 ([RFC2070]).
Konforme Benutzerprogramme k=nnen den Wert von 'text-transform' f r Zeichen, die nicht
aus dem Latin-1-Repertoire stammen auf 'none' setzen, ebenso f r Elemente in Sprachen, f r
die sich die Umwandlung von der in den Fallumwandlungstabellen von ISO 10646 ([ISO10646])
unterscheidet.
Beispiel
In diesem Beispiel wird der gesamte Text in einem H1-Element in Großbuchstaben
umgewandelt.
H1 { text-transform: uppercase }
16.6 Leerraum: die 'white-space'-Eigenschaft
'white-space'
Wert: normal | pre | nowrap | inherit
Ausgangswert: Normal
Angewendet auf: Elemente auf Blockebene
Vererbt: Ja
Prozentwerte: N/A
Cascading Style Sheets, Level 2
Medium: Visual
Diese Eigenschaft deklariert, wie Leerraum innerhalb des Elements behandelt wird. Die Werte
haben die folgenden Bedeutungen:
normal
Dieser Wert weist Benutzerprogramme an, Leerraum-Folgen zu komprimieren und bei
Bedarf Zeilen zu umbrechen, um Zeilen-Boxen zu f llen. Es k=nnen zus@tzliche Zeilen-
umbr che erzeugt werden, wenn „\A“ in erzeugtem Inhalt (z. B. f r das BR-Element in
HTML) auftritt.
pre
Dieser Wert verhindert, dass Benutzerprogramme Leerraum-Folgen komprimieren. Zeilen
werden nur an Neuezeile-Zeichen der Quelle umbrochen, oder wenn im erzeugten Inhalt „\A“
auftritt.
nowrap
Dieser Wert komprimiert Leerraum wie f r 'normal', unterdr ckt aber Zeilenumbr che
innerhalb von Text, außer diejenigen, die durch „\A“ in erzeugtem Inhalt erzeugt werden
(z. B. f r das BR-Element in HTML).
< 780 > Text
Page size: 168,00 x 240,00 mm
Beispiel
Die folgenden Beispiele zeigen, welches Leerraum-Verhalten von den PRE- und P-Ele-
menten erwartet wird, und zudem das "nowrap"-Attribut in HTML.
PRE { white-space: pre }
P { white-space: normal }
TD[nowrap] { white-space: nowrap }
Konforme Benutzerprogramme k=nnen die 'white-space'-Eigenschaft in Autor- und Benutzer-
Stylesheets ignorieren, m ssen aber einen Wert daf r im Standard-Stylesheet angeben.
17 Tabellen
17.1 Einf-hrung in Tabellen
Tabellen stellen eine Beziehung zwischen Daten her. Autoren geben diese Beziehungen in der
Dokumentsprache an und legen ihre Darstellung mit CSS fest, und zwar auf zwei Arten: visuell
und akustisch.
Autoren k=nnen die visuelle Formatierung einer Tabelle als regelm@ßiges Zellraster angeben.
Zeilen und Spalten aus Zellen k=nnen in Zeilengruppen und Spaltengruppen eingeteilt werden.
Zeilen, Spalten, Zeilengruppen, Spaltengruppen und Zellen k=nnen Rahmen haben (es gibt zwei
Rahmenmodelle in CSS2). Autoren k=nnen ihre Daten vertikal oder horizontal in einer Zelle
und die Daten in allen Zellen einer Zeile oder Spalte ausrichten.
Außerdem k=nnen Autoren die akustische Darstellung einer Tabelle festlegen: wie berschrif-
ten und Daten gesprochen werden. In der Dokumentsprache k=nnen Autoren Zellen und Zell-
gruppen beschriften, so dass bei einer akustischen Ausgabe Zellen berschriften vor Zellen-
Cascading Style Sheets, Level 2
daten gesprochen werden. Damit wird die Tabelle letztlich „serialisiert“: Benutzer, die die
Tabelle akustisch wahrnehmen, h=ren eine Folge von berschriften, denen die Daten folgen.
Beispiel
Nachfolgend sehen Sie eine einfache dreizeilige, dreispaltige Tabelle, die in HTML 4.0
beschrieben ist:
<TABLE>
<CAPTION>Dies ist eine einfache 3x3-Tabelle</CAPTION>
<TR id="row1">
<TH>dberschrift 1 <TD>Zelle 1 <TD>Zelle 2
<TR id="row2">
<TH>dberschrift 2 <TD>Zelle 3 <TD>Zelle 4
<TR id="row3">
<TH>dberschrift 3 <TD>Zelle 5 <TD>Zelle 6
</TABLE>
Tabellen < 781 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Dieser Code erzeugt eine Tabelle (das TABLE-Element), drei Zeilen (die TR-Elemente), drei
berschriftszellen (die TH-Elemente) und sechs Datenzellen (die TD-Elemente). Beachten Sie,
dass die drei Spalten dieses Beispiels implizit angegeben sind: Es gibt so viele Spalten in der
Tabelle, wie von berschrift und Datenzellen ben=tigt werden.
Die folgende CSS-Regel zentriert den Text horizontal in den berschriftszellen und stellt die
Daten fett ausgezeichnet dar:
TH { text-align: center; font-weight: bold }
Die n@chste Regel richtet den Text der berschriftszellen an ihrer Grundlinie aus und zentriert
den Text vertikal in jeder Datenzelle:
TH { vertical-align: baseline }
TD { vertical-align: middle }
Die n@chste Regel gibt an, dass die oberste Zeile von einem 3px breiten durchgezogenen
blauen Rahmen umgeben ist, und dass alle anderen Zeilen von einem 1px breiten durchgezoge-
nen schwarzen Rahmen umgeben sind.
TABLE { border-collapse: collapse }
TR#row1 { border-top: 3px solid blue }
TR#row2 { border-top: 1px solid black }
TR#row3 { border-top: 1px solid black }
Beachten Sie jedoch, dass sich die Rahmen um die Zeilen herum dort berlappen, wo die Zeilen
zusammentreffen. Welche Farbe (schwarz oder blau) und welche St@rke (1px oder 3px) erh@lt
der Rahmen zwischen Zeile 1 (row1) und Zeile 2 (row2)? Wir werden im Abschnitt ber die
Konfliktaufl=sung bei Rahmen noch einmal darauf zur ckkommen.
Die folgende Regel schreibt die Tabellen berschrift ber die Tabelle:
Cascading Style Sheets, Level 2
CAPTION { caption-side: top }
Die nachfolgende Regel schließlich gibt an, dass jede Datenzeile bei der akustischen Darstellung
als „ berschrift, Daten, Daten“ gelesen wird.
TH { speak-header: once }
Die erste Zeile beispielsweise w rde als „ berschrift1 Zelle1 Zelle2“ gelesen. Mit der folgen-
den Regel hingegen:
TH { speak-header: always }
w rde sie wie „ berschrift1 Zelle1 berschrift1 Zelle2“ gesprochen.
Das obige Beispiel zeigt, wie CSS mit HTML 4.0-Elementen umgeht; in HTML 4.0 ist die Seman-
tik der verschiedenen Tabellenelemente (TABLE, CAPTION, THEAD, TBODY, TFOOT, COL,
COLGROUP, TH und TD) wohldefiniert. In anderen Dokumentsprachen (wie beispielsweise
XML-Anwendungen) gibt es m=glicherweise keine vordefinierten Tabellenelemente. CSS2
erlaubt es deshalb den Autoren, Elemente aus der Dokumentsprache mit Hilfe der 'display'-Ei-
< 782 > Tabellen
Page size: 168,00 x 240,00 mm
genschaft auf Tabellenelemente „abzubilden“. Die nachfolgende Regel beispielsweise bewirkt,
dass sich das FOO-Element wie ein TABLE-Element aus HTML und das BAR-Element wie ein
CAPTION-Element verh@lt:
FOO { display : table }
BAR { display : table-caption }
Im folgenden Abschnitt beschreiben wir die verschiedenen Tabellenelemente. In dieser Spezifi-
kation bezieht sich der Begriff Tabelle auf jedes Element, das f r das Anlegen einer Tabelle
genutzt wird. Ein „internes“ Tabellenelement ist ein Element, das eine Zeile, Zeilengruppe,
Spalte, Spaltengruppe oder Zelle erzeugt.
Anmerkung der bersetzer: Das folgende Beispiel zeigt eine Tabelle eines XML-
Dokumenttyps, der nicht die bekannten HTML- oder CALS-Tabellen verwendet. Es
handelt sich um die Tabelle der ersten Fußball-Bundesliga. Zu sehen ist der Stand nach
einem Spieltag in der Saison 2002/2003. Zur Beschreibung der Daten werden Element-
typnamen verwendet, die beschreiben, worum es sich bei den Daten handelt: verein,
tore, punkte.
<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="[Link]" type="text/css"?>
<!DOCTYPE liga [
<!ELEMENT liga (pos+) >
<!ELEMENT pos (verein, punkte, tore) >
<!ELEMENT verein (#PCDATA) >
<!ELEMENT punkte (#PCDATA) >
<!ELEMENT tore (#PCDATA) >
]>
<liga>
<pos>
Cascading Style Sheets, Level 2
<verein>Bayern MUnchen</verein>
<punkte>29</punkte>
<tore>29:14</tore>
</pos>
<pos>
<verein>Borussia Dortmund</verein>
<punkte>24</punkte>
<tore>19:9</tore>
</pos>
<pos>
<verein>Werder Bremen</verein>
<punkte>23</punkte>
<tore>27:25</tore>
</pos>
<pos>
<verein>1. FC Schalke 04</verein>
<punkte>22</punkte>
<tore>16:11</tore>
</pos>
<pos>
<verein>Hertha BSC Berlin</verein>
<punkte>22</punkte>
<tore>16:12</tore>
Einf#hrung in Tabellen < 783 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
</pos>
<pos>
<verein>VfB Stuttgart</verein>
<punkte>21</punkte>
<tore>21:15</tore>
</pos>
<pos>
<verein>VfL Bochum</verein>
<punkte>20</punkte>
<tore>27:21</tore>
</pos>
<pos>
<verein>1860 MUnchen</verein>
<punkte>20</punkte>
<tore>18:15</tore>
</pos>
<pos>
<verein>VfL Wolfsburg</verein>
<punkte>19</punkte>
<tore>15:16</tore>
</pos>
<pos>
<verein>Hamburger SV</verein>
<punkte>19</punkte>
<tore>16:19</tore>
</pos>
<pos>
<verein>Bayer Leverkusen</verein>
<punkte>16</punkte>
<tore>17:20</tore>
</pos>
<pos>
<verein>1. FC NUrnberg</verein>
Cascading Style Sheets, Level 2
<punkte>16</punkte>
<tore>16:21</tore>
</pos>
<pos>
<verein>Borussia M^nchengladbach</verein>
<punkte>15</punkte>
<tore>16:12</tore>
</pos>
<pos>
<verein>Hansa Rostock</verein>
<punkte>15</punkte>
<tore>15:14</tore>
</pos>
<pos>
<verein>Hannover 96</verein>
<punkte>15</punkte>
<tore>22:27</tore>
</pos>
<pos>
<verein>Armenia Bielefeld</verein>
<punkte>14</punkte>
<tore>13:22</tore>
< 784 > Tabellen
Page size: 168,00 x 240,00 mm
</pos>
<pos>
<verein>Energie Cottbus</verein>
<punkte>8</punkte>
<tore>7:27</tore>
</pos>
<pos>
<verein>FC Kaiserslautern</verein>
<punkte>7</punkte>
<tore>12:22</tore>
</pos>
</liga>
In der zweiten Zeile verweist die Verarbeitungsanweisung xml-stylesheet auf die
externe CSS-Datei [Link]. Erst die CSS-Anweisungen sorgen f r die tabellarische Dar-
stellung der Daten. Nachfolgend nun die CSS-Datei:
liga { display: table;
margin: 5em;
border-collapse: separate;
border: 4px solid black;
border-spacing: 3px;
}
pos { display: table-row;
padding: 2px;
}
verein { display: table-cell;
font-weight: bolder;
padding: 1em;
background: lightgray;
}
Cascading Style Sheets, Level 2
punkte { display: table-cell;
padding: 1em;
background: lightblue;
}
tore { display: table-cell;
padding: 1em;
background: lightgreen;
}
Einf#hrung in Tabellen < 785 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Mozilla 1.1 stellt dieses Beispiel wie in der Abbildung zu sehen dar.
Cascading Style Sheets, Level 2
Im weiteren Verlauf des Kapitels werden die einzelnen CSS-Anweisungen, die f r die
Darstellung als Tabelle verantwortlich sind, detailliert erkl@rt.
< 786 > Tabellen
Page size: 168,00 x 240,00 mm
17.2 Das CSS-Tabellenmodell
Das CSS-Tabellenmodell basiert auf dem Tabellenmodell von HTML 4.0, wobei die Struktur
einer Tabelle eng mit dem visuellen Layout der Tabelle verkn pft ist. In diesem Modell besteht
die Tabelle aus einer optionalen berschrift und einer beliebigen Anzahl von Zellzeilen. Das
Tabellenmodell wird auch als „zeilenorientiert“ bezeichnet, weil die Autoren in der Dokument-
sprache explizit Zeilen angeben, keine Spalten. Spalten werden abgeleitet, nachdem alle Zeilen
angegeben wurden – die erste Zelle jeder Zeile geh=rt zur ersten Spalte, die zweite zur zwei-
ten Spalte usw. Zeilen und Spalten k=nnen strukturiert gruppiert werden, und diese Gruppie-
rung wird in der Darstellung ber cksichtigt (z. B. kann um eine bestimmte Zeilengruppe ein
Rahmen gezogen werden).
Das Tabellenmodell besteht also aus Tabellen, berschriften, Zeilen, Zeilengruppen, Spalten,
Spaltengruppen und Zellen.
F r das CSS-Modell ist es nicht erforderlich, dass die Dokumentsprache Elemente enth@lt, die
diesen Komponenten entsprechen. F r Dokumentsprachen (wie beispielsweise XML-Anwendun-
gen), die keine vordefinierten Tabellenelemente haben, m ssen Autoren die Elemente aus der
Dokumentsprache auf Tabellenelemente abbilden; das geschieht mit Hilfe der 'display'-Eigen-
schaft. Die folgenden 'display'-Werte weisen einem beliebigen Element Tabellensemantik zu:
table (in HTML: table)
Gibt an, dass ein Element eine Tabelle auf Blockebene definiert: Es handelt sich um einen
rechteckigen Block, der Teil eines Bockformatierungskontexts (9.4.1) ist.
inline-table (in HTML: table)
Gibt an, dass ein Element eine Tabelle auf Inline-Ebene definiert: Es handelt sich um einen
rechteckigen Block, der Teil eines Inline-Formatierungskontexts (9.4.2) ist.
table-row (in HTML: tr)
Gibt an, dass ein Element eine Zeile mit Zellen ist.
table-row-group (in HTML: tbody)
Cascading Style Sheets, Level 2
Gibt an, dass ein Element eine oder mehrere Zeilen gruppiert.
table-header-group (in HTML: thead)
Wie 'table-row-group', aber f r die visuelle Formatierung; die Zeilengruppe wird immer
vor allen anderen Zeilen und Zeilengruppen und nach allen nach oben ausgelagerten ber-
schriften angezeigt. Druck-Benutzerprogramme k=nnen Kopfzeilen auf jeder Zeile wieder-
holen, ber die sich eine Tabelle erstreckt.
table-footer-group (in HTML: tfoot)
Wie 'table-row-group', aber f r die visuelle Formatierung; die Zeilengruppe wird immer
nach allen anderen Zeilen und Zeilengruppen und vor nach unten ausgelagerten berschrif-
ten angezeigt. Druck-Benutzerprogramme k=nnen Fußzeilen auf jeder Seite wiederholen,
ber die sich eine Tabelle erstreckt.
table-column (in HTML: col)
Gibt an, dass ein Element eine Spalte beschreibt.
table-column-group (in HTML: colgroup)
Gibt an, dass ein Element eine oder mehrere Spalten gruppiert.
table-cell (in HTML: td, th)
Gibt an, dass ein Element eine Tabellenzelle darstellt.
table-caption (in HTML: caption)
Gibt eine berschrift f r die Tabelle an.
Das CSS-Tabellenmodell < 787 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Elemente, f r die 'display' auf 'table-column' oder 'table-column-group' gesetzt ist, werden nicht
dargestellt (so, als w@re 'display' auf 'none' gesetzt), aber sie sind praktisch, weil sie m=glicher-
weise Attribute haben, die einen bestimmten Stil f r die Spalten vorgeben, die sie darstellen.
Das Standard-Stylesheet f r HTML 4.0 im Anhang zeigt die Verwendung dieser Werte f r
HTML 4.0:
TABLE { display: table }
TR { display: table-row }
THEAD { display: table-header-group }
TBODY { display: table-row-group }
TFOOT { display: table-footer-group }
COL { display: table-column }
COLGROUP { display: table-column-group }
TD, TH { display: table-cell }
CAPTION { display: table-caption }
Benutzerprogramme k=nnen diese 'display'-Eigenschaftswerte f r HTML-Dokumente ignorie-
ren, weil die Autoren das erwartete Verhalten eines Elements nicht ver@ndern sollten.
17.2.1 Anonyme Tabellenobjekte
Andere Dokumentsprachen als HTML enthalten m=glicherweise nicht alle Elemente aus dem
CSS2-Tabellenmodell. In diesen F@llen m ssen die „fehlenden“ Elemente vorausgesetzt werden,
damit das Tabellenmodell funktioniert. Die fehlenden Elemente erzeugen anonyme Objekte
(z. B. anonyme Boxen im visuellen Tabellenlayout), die den folgenden Regeln entsprechen:
1. Jedes Tabellenelement erzeugt automatisch anonyme Tabellenobjekte um sich selbst
herum, die aus mindestens drei verschachtelten Objekten bestehen, die einem 'table'/'in-
line-table'-Element, einem 'table-row'-Element und einem 'table-cell'-Element entsprechen.
2. Wenn das bergeordnete P eines 'table-cell'-Elements T keine 'table-row' ist, wird ein
Objekt, das einer 'table-row' entspricht, zwischen P und T erzeugt. Dieses Objekt erstreckt
Cascading Style Sheets, Level 2
sich ber alle nachfolgenden gleichrangigen 'table-cell'-Elemente (im Dokumentbaum) von
T.
3. Wenn das bergeordnete P eines 'table-row'-Elements T kein 'table'-, 'inline-table'- oder
'table-row-group'-Element ist, wird ein Element, das einem 'table'-Element entspricht, zwi-
schen P und T erzeugt. Dieses Objekt erstreckt sich ber alle gleichrangigen Elemente (im
Dokumentbaum) von T, f r die ein bergeordnetes 'table'-Element ben=tigt wird: 'table-
row', 'table-row-group', 'table-header-group', 'table-footer-group', 'table-column', 'table-
column-group' und 'caption'.
4. Wenn ein bergeordnetes P eines 'table-row-group'- (oder 'table-header-group'- oder
'table-footer-group'-) Elements T kein 'table' oder 'inline-table' ist, wird ein Element ent-
sprechend einem 'table'-Objekt zwischen P und T erzeugt. Dieses Objekt erstreckt sich
ber alle gleichrangigen Elemente (im Dokumentbaum) von T, f r die ein bergeordnetes
'table'-Element ben=tigt wird: 'table-row', 'table-row-group', 'table-header-group', 'table-
footer-group', 'table-column', 'table-column-group' und 'caption'.
5. Wenn ein untergeordnetes T eines 'table-row'-Elements P kein 'table-cell'-Element ist, wird
zwischen P und T ein Objekt erzeugt, das einem 'table-cell'-Element entspricht. Dieses
Objekt erstreckt sich ber alle nachfolgenden gleichrangigen Elemente von T, bei denen es
sich nicht um 'table-cell'-Elemente handelt.
< 788 > Tabellen
Page size: 168,00 x 240,00 mm
Beispiel
In diesem XML-Beispiel wird angenommen, dass ein 'table' Element das HBOX-Element
enth@lt:
<HBOX>
<VBOX>George</VBOX>
<VBOX>4287</VBOX>
<VBOX>1998</VBOX>
</HBOX>
weil das zugeh=rige Stylesheet wie folgt aussieht:
HBOX { display: table-row }
VBOX { display: table-cell }
In diesem Beispiel werden drei 'table-cell'-Elemente angenommen, die den Text in den ROWs
enthalten. Beachten Sie, dass der Text weiter in anonyme Inline-Boxen eingekapselt ist, wie im
Abschnitt ber das visuelle Formatierungsmodell erkl@rt:
<STACK>
<ROW>This is the <D>top</D> row.</ROW>
<ROW>This is the <D>middle</D> row.</ROW>
<ROW>This is the <D>bottom</D> row.</ROW>
</STACK>
Das Stylesheet ist:
STACK { display: inline-table }
ROW { display: table-row }
D { display: inline; font-weight: bolder }
Cascading Style Sheets, Level 2
HTML-Benutzerprogramme m ssen keine anonymen Objekte gem@ß den obigen Regeln erzeu-
gen.
17.3 Spaltenselektoren
Tabellenzellen k=nnen zu zwei Kontexten geh=ren: Zeilen und Spalten. Im Quelldokument sind
Zellen jedoch Ableitungen von Zeilen, nie von Spalten. Trotzdem k=nnen einige Aspekte von
Zellen beeinflusst werden, indem man Eigenschaften f r Spalten setzt.
Die folgenden Eigenschaften gelten f r Spalten- und Spaltengruppenelemente:
'border'
Die verschiedenen Rahmeneigenschaften gelten f r Spalten nur dann, wenn 'border-collap-
se' f r das Tabellenelement auf 'collapse' gesetzt ist. In diesem Fall werden Rahmen, die f r
Spalten und Spaltengruppen gesetzt sind, in den Algorithmus zur Konfliktaufl=sung (17.6.2)
eingegeben, der den Rahmenstil an jeder Zellkante festlegt.
Spaltenselektoren < 789 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
'background'
Die Hintergrundeigenschaften setzen den Hintergrund f r Zellen in der Spalte, aber nur,
wenn sowohl die Zelle als auch die Zeile transparente Hintergr nde haben. Weitere Infor-
mationen finden Sie im Abschnitt 17.5.1 ber Tabellenebenen und Transparenz.
'width'
Die 'width'-Eigenschaft gibt die Mindestbreite f r die Spalte vor.
'visibility'
Wenn die 'visibility' einer Spalte auf 'collapse' gesetzt ist, werden keine Zellen der Spalte
dargestellt, und Zellen, die sich in andere Spalten erstrecken, werden abgeschnitten. Dar -
ber hinaus wird die Breite der Tabelle um die Breite der Spalte verringert, die diese Spalte
eingenommen h@tte. Weitere Informationen finden Sie im Abschnitt „Dynamische Effekte“,
sp@ter in diesem Kapitel. Andere Werte f r 'visibility' zeigen keine Wirkung.
Beispiel
Nachfolgend finden Sie einige Beispiele f r Stilregeln, die Eigenschaften f r Spalten set-
zen. Die beiden ersten Regeln implementieren zusammen das „rules“-Attribut von
HTML 4.0 mit einem Wert „cols“. Die dritte Regel macht die Spalte „totals“ blau, die
beiden letzten Regeln zeigen, wie man einer Spalte mit Hilfe des Algorithmus f r ein
fixes Layout eine feste Gr=ße zuweist.
COL { border-style: none solid }
TABLE { border-style: hidden }
[Link] { background: blue }
TABLE { table-layout: fixed }
[Link] { width: 5em }
17.4 Tabellen im visuellen Formatierungsmodell
Im visuellen Formatierungsmodell kann sich eine Tabelle wie ein Element auf Blockebene oder
Cascading Style Sheets, Level 2
ein ersetztes Element auf Inline-Ebene verhalten. Tabellen haben Inhalt, Polsterung, Rahmen
und R@nder.
In beiden F@llen erzeugt das Tabellenelement eine anonyme Box, die sowohl die eigentliche
Tabellen-Box als auch die Box f r die berschrift (falls vorhanden) enth@lt. Die Boxen f r
Tabelle und berschrift behalten ihre eigenen Inhalts-, Polsterungs-, Rand- und Rahmenberei-
che, und die Gr=ße der rechteckigen anonymen Box ist die kleinste Gr=ße, die erforderlich ist,
um beides aufzunehmen. Vertikale R@nder fallen zusammen, wenn sich die Tabellen-Box und
die berschrifts-Box ber hren. Eine Neupositionierung der Tabelle muss die gesamte anonyme
Box verschieben, nicht nur die Tabellen-Box, damit die berschrift der Tabelle folgt.
< 790 > Tabellen
Page size: 168,00 x 240,00 mm
caption’s margin
caption caption caption caption caption
} collapsed mar
table’s margin
Abbildung 17.1: Skizze einer Tabelle mit einer dar ber liegenden berschrift; der untere Rand
der berschrift f@llt mit dem oberen Rand der Tabelle zusammen.
17.4.1 Positionierung und Ausrichtung von berschriften
'caption-side'
Wert: top | bottom | left | right | inherit
Ausgangswert: top
Angewendet auf: 'table-caption'-Elemente
Vererbt: Ja
Cascading Style Sheets, Level 2
Prozentwerte: N/A
Medium: Visual
Diese Eigenschaft gibt die Position der berschrifts-Box relativ zur Tabellen-Box an. Die
Werte haben die folgenden Bedeutungen:
top
Positioniert die berschrifts-Box oberhalb der Tabellen-Box.
bottom
Positioniert die berschrifts-Box unterhalb der Tabellen-Box.
left
Positioniert die berschrifts-Box links von der Tabellen-Box.
right
Positioniert die berschrifts-Box rechts von der Tabellen-Box.
Tabellen im visuellen Formatierungsmodell < 791 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
berschriften oberhalb oder unterhalb eines 'table'-Elements werden fast so formatiert, als
handle es sich dabei um ein Blockelement vor oder nach der Tabelle, außer dass (1) sie nicht
vererbbare Eigenschaften von der Tabelle erben und (2) nicht als Block-Box betrachtet werden,
was 'compact'- oder 'run-in'-Elemente betrifft, die der Tabelle m=glicherweise vorausgehen.
Eine berschrift, die sich oberhalb oder unterhalb einer Tabellen-Box befindet, verh@lt sich
ebenfalls wie eine Block-Box f r Breitenberechnungen; die Breite wird relativ zur Breite des
umschließenden Blocks der Tabellen-Box berechnet.
F r eine berschrift, die sich rechts oder links von einer Tabellen-Box befindet, setzt dagegen
ein anderer Wert als 'auto' f r 'width' die Breite explizit; 'auto' weist das Benutzerprogramm
an, eine „sinnvolle Breite“ zu w@hlen. Das reicht von „der schmalsten m=glichen Box“ bis hin
zu „eine einzelne Zeile“, wir empfehlen also, dass die Autoren f r die Breite einer linken und
rechten berschrift nicht 'auto' angeben.
Um den berschriftsinhalt horizontal innerhalb der berschrifts-Box auszurichten, verwenden
Sie die 'text-align'-Eigenschaft. F r die vertikale Ausrichtung einer linken oder rechten ber-
schrifts-Box relativ zur Tabellen-Box ist die 'vertical-align'-Eigenschaft zust@ndig. Die einzigen
sinnvollen Werte sind in diesem Fall 'top', 'middle' und 'bottom'. Alle anderen Werte werden
genau wie 'top' behandelt.
Beispiel
In diesem Beispiel platziert die 'caption-side'-Eigenschaft berschriften unterhalb von
Tabellen. Die berschrift ist so breit wie das bergeordnete Element der Tabelle, und
der berschriftstext ist linksb ndig ausgerichtet.
CAPTION { caption-side: bottom;
width: auto;
text-align: left }
Das folgende Beispiel zeigt, wie man eine berschrift im linken Rand platziert. Die eigentliche
Tabelle ist zentriert, weil ihre linken und rechten R@nder auf 'auto' gesetzt wurden, und die
Cascading Style Sheets, Level 2
gesamte Box mit Tabelle und berschrift wird in den linken Rand verschoben, und zwar um
dieselbe Breite wie die berschrift.
BODY {
margin-left: 8em
}
TABLE {
margin-left: auto;
margin-right: auto
}
CAPTION {
caption-side: left;
margin-left: -8em;
width: 8em;
text-align: right;
vertical-align: bottom
}
< 792 > Tabellen
Page size: 168,00 x 240,00 mm
Angenommen, die Breite der Tabelle w@re kleiner als die verf gbare Breite, dann s@he die For-
matierung wie folgt aus:
current margins
text text text previous paragraph text text above the table text text
more text text text normal paragraph text text etc. etc.
header header header
cell cell cell
cell cell cell
Table 72. This cell cell cell
is the caption. It cell cell cell
is right aligned. cell cell cell
Also aligned at the
bottom cell cell cell
Abbildung 17.2: Skizze, die eine zentrierte Tabelle zeigt, wobei die berschrift in den linken
Rand hinausragt, weil eine negative 'margin-left'-Eigenschaft angegeben wurde.
17.5 Visuelles Layout von Tabelleninhalt
Wie andere Elemente der Dokumentsprache auch erzeugen interne Tabellenelemente recht-
eckige Boxen mit Inhalt, Polsterung und Rahmen. Sie haben jedoch keine R@nder.
Das visuelle Layout dieser Boxen wird durch ein rechteckiges unregelm@ßige Raster aus Zeilen
und Spalten festgelegt. Jede Box belegt eine ganze Zahl an Rasterzellen, die nach den folgenden
Cascading Style Sheets, Level 2
Regeln ermittelt werden. Diese Regeln gelten nicht f r HTML 4.0 oder fr here HTML-Ver-
sionen; HTML weist eigene Beschr@nkungen f r Zeilen- und Spaltenbereiche auf.
1. Jede Zeilen-Box belegt eine Zeile Rasterzellen. Insgesamt f llen die Zeilen-Boxen die
Tabelle von oben nach unten in der Reihenfolge, in der sie im Quelldokument auftreten
(das heißt, die Tabelle belegt genau so viele Rasterzeilen, wie es Zeilenelemente gibt).
2. Eine Zeilengruppe belegt dieselben Rasterzellen wie die Zeilen, die sie enth@lt.
3. Eine Spalten-Box belegt eine oder mehrere Spalten an Rasterzellen. Spalten-Boxen werden
nebeneinander in der Reihenfolge, in der sie auftreten, angeordnet. Die erste Spalten-Box
kann sich links oder rechts befinden, abh@ngig vom Wert der 'direction'-Eigenschaft der
Tabelle.
4. Eine Spaltengruppen-Box belegt dieselben Rasterzellen wie die Spalten, die sie enth@lt.
5. Zellen k=nnen sich ber mehrere Zeilen oder Spalten erstrecken. (Obwohl CSS2 nicht
definiert, wie die Anzahl der abgedeckten Zeilen oder Spalten ermittelt wird, hat ein Benut-
zerprogramm m=glicherweise ein spezielles Wissen ber das Quelldokument; eine zuk nf-
tige Version von CSS unterst tzt vielleicht eine M=glichkeit, dieses Wissen in CSS-Syntax
auszudr cken.) Jede Zelle ist also eine rechteckige Box, ein oder mehr Rasterzellen breit
und hoch. Die oberste Zeile dieses Rechtecks befindet sich in der Zeile, die durch das ber-
geordnete Element der Zelle angegeben wurde. Das Rechteck muss sich so weit wie m=g-
Visuelles Layout von Tabelleninhalt < 793 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
lich links befinden, aber es darf sich nicht mit anderen Zell-Boxen berlappen. Zudem muss
es rechts von allen Zellen derselben Zeile stehen, die im Quelldokument vorher vorkom-
men. (Diese Beschr@nkung gilt, wenn die 'direction'-Eigenschaft der Tabelle gleich 'ltr' ist;
wenn die 'direction' 'rtl' ist, vertauschen Sie im vorigen Satz „links“ und „rechts“).
6. Eine Zellen-Box kann nicht ber die letzte Zeilen-Box einer Tabellen- oder Zeilengruppe
hinausgehen; Benutzerprogramme m ssen sie k rzen, bis sie passt.
Hinweis: Tabellenzellen k=nnen relativ und absolut positioniert werden, das ist jedoch nicht zu
empfehlen: die Positionierung und das Floating entfernen eine Box aus dem Fluss und beeinflus-
sen die Tabellenausrichtung. n
Beispiel
Hier zwei Beispiele. Das erste soll in einem HTML-Dokument auftreten:
<TABLE>
<TR><TD>1 <TD rowspan="2">2 <TD>3 <TD>4
<TR><TD colspan="2">5
</TABLE>
<TABLE>
<ROW><CELL>1 <CELL rowspan="2">2 <CELL>3 <CELL>4
<ROW><CELL colspan="2">5
</TABLE>
Die zweite Tabelle ist formatiert, wie in der Abbildung rechts gezeigt; die Darstellung der
HTML-Tabelle ist von HTML explizit nicht definiert, und CSS versucht nicht, sie zu definieren.
Benutzerprogramme k=nnen sie nach Belieben darstellen, z. B. wie in der Abbildung links
gezeigt.
Cascading Style Sheets, Level 2
1 2 3 4 1 2 3 4
5 5
Abbildung 17.3: Links sehen Sie eine m=gliche Darstellung einer fehlerhaften HTML 4.0-Tabelle;
rechts sehen Sie die einzig m=gliche Formatierung einer @hnlichen Tabelle, die nicht in HTML
formuliert ist.
17.5.1 Tabellenebenen und Transparenz
Um den Hintergrund jeder Tabellenzelle zu ermitteln, kann man sich die verschiedenen Tabel-
lenelemente als sechs bereinander geschichtete Ebenen vorstellen. Der Hintergrund, der f r
ein Element in einer der Ebenen gesetzt wird, ist nur sichtbar, wenn die dar ber liegenden Ebe-
nen einen transparenten Hintergrund haben.
< 794 > Tabellen
Page size: 168,00 x 240,00 mm
cells
rows
row groups
columns
column groups
table
Abbildung 17.4: Schema der Tabellenebenen
1. Unterste Ebene ist eine einzelne Ebene, die die eigentliche Tabellen-Box darstellt. Wie alle
Boxen kann sie transparent sein.
2. Die n@chste Ebene enth@lt die Spaltengruppen. Die Spaltengruppen sind so groß wie die
Tabelle, aber sie m ssen nicht die gesamte Tabelle horizontal abdecken.
3. ber den Spaltengruppen gibt es die Bereiche, die die Spalten-Boxen darstellen. Wie Spal-
tengruppen sind Spalten so hoch wie die Tabelle, m ssen aber nicht die gesamte Tabelle
horizontal abdecken.
4. Es folgt die Ebene, die die Zeilengruppen enth@lt. Jede Zeilengruppe ist so breit wie die
Cascading Style Sheets, Level 2
Tabelle. Zusammen decken die Zeilengruppen die gesamte Tabelle von oben bis unten ab.
5. Die vorletzte Ebene enth@lt die Zeilen. Die Zeilen decken ebenfalls die gesamte Tabelle ab.
6. Die oberste Ebene enth@lt die eigentlichen Zellen. Wie die Abbildung zeigt, enthalten zwar
alle Zeilen dieselbe Anzahl an Zellen, aber m=glicherweise haben nicht alle Zellen einen
angegebenen Inhalt. Diese „leeren“ Zellen sind transparent, so dass die unteren Ebenen
durchscheinen.
Beispiel
Im folgenden Beispiel enth@lt die erste Zeile vier Zellen, die zweite Zeile dagegen keine
Zellen, deshalb scheint der Tabellenhintergrund durch, außer wenn sich eine Zelle von
der ersten Zeile in diese Zeile weitererstreckt. Der nachfolgende HTML-Code und die
Stilregeln:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<STYLE type="text/css">
TABLE { background: #ff0; border-collapse: collapse }
TD { background: red; border: double black }
Visuelles Layout von Tabelleninhalt < 795 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
</STYLE>
</HEAD>
<BODY>
<P>
<TABLE>
<TR>
<TD> 1
<TD rowspan="2"> 2
<TD> 3
<TD> 4
</TR>
<TR><TD></TD></TR>
</TABLE>
</BODY>
</HTML>
k=nnten wie folgt formatiert werden:
1 2 3 4
Abbildung 17.5: Tabelle mit drei leeren Zellen in der unteren Zeile
17.5.2 Algorithmen f-r die Tabellenbreite: die
'table-layout'-Eigenschaft
Cascading Style Sheets, Level 2
CSS definiert kein „optimales“ Layout f r Tabellen, weil es in vielen F@llen Geschmackssache
ist, was optimal ist. CSS definiert des Weiteren keine Beschr@nkungen, die die Benutzerpro-
gramme beim Anlegen einer Tabelle ber cksichtigen m ssen. Benutzerprogramme k=nnen
beliebige Algorithmen verwenden, und es steht ihnen frei, Darstellungsgeschwindigkeit einer
genaue Darstellung vorzuziehen, außer wenn der „Algorithmus f r ein festes Layout“ (fixed)
ausgew@hlt wird.
'table-layout'
Wert: auto | fixed | inherit
Ausgangswert: auto
Angewendet auf: 'table'- und 'inline-table'-Elemente
Vererbt: Nein
Prozentwerte: N/A
Medium: Visual
< 796 > Tabellen
Page size: 168,00 x 240,00 mm
Die 'table-layout'-Eigenschaft steuert den Algorithmus f r das Anlegen der Zellen, Zeilen und
Spalten der Tabelle. Die Werte haben die folgenden Bedeutungen:
fixed
Verwendet den Algorithmus f r ein festes Tabellen-Layout
auto
Verwendet einen beliebigen Algorithmus f r ein automatisches Tabellenlayout
Die beiden Algorithmen sind nachfolgend beschrieben.
Festes Tabellenlayout
Bei diesem (schnellen) Algorithmus ist das horizontale Layout der Tabelle nicht vom Inhalt der
Zellen, sondern nur von der Breite der Tabelle, der Breite der Spalten sowie den Rahmen oder
Zellauff llungen abh@ngig.
Die Tabellenbreite kann explizit mit der 'width'-Eigenschaft angegeben werden. Der Wert 'au-
to' (sowohl f r 'display: table' als auch f r 'display: inline-table') bedeutet, dass der Algorithmus
f r das automatische Tabellenlayout verwendet wird.
Beim Algorithmus f r ein festes Tabellenlayout wird die Breite jeder Spalte wie folgt ermittelt:
1. Ein Spaltenelement mit einem anderen Wert als 'auto' f r die 'width'-Eigenschaft legt die
Breite f r diese Spalte fest.
2. Andernfalls legt eine Zelle in der ersten Zeile mit einem anderen Wert als 'auto' f r die
'width'-Eigenschaft die Breite f r diese Spalte fest. Wenn sich die Zelle ber mehrere Spal-
ten erstreckt, wird die Breite ber die Spalten aufgeteilt.
3. Der restliche horizontale Tabellenraum wird auf alle restlichen Spalten aufgeteilt (abz glich
der Rahmen oder Zellauff llungen).
Die Breite einer Tabelle ist dann der gr=ßere Wert aus dem Wert der 'width'-Eigenschaft f r
das Tabellenelement und der Summe der Spaltenbreiten (plus Zellauff llung oder Rahmen). Ist
die Tabelle breiter als die Summe der Spaltenbreiten, sollte der zus@tzliche Platz gleichm@ßig
Cascading Style Sheets, Level 2
auf die Spalten verteilt werden.
Auf diese Weise kann das Benutzerprogramm beginnen, die Tabelle darzustellen, nachdem es
die gesamte erste Zeile erhalten hat. Zellen in nachfolgenden Zeilen haben keine Auswirkung
auf die Spaltenbreiten. Alle Zellen, deren Inhalt gr=ßer als die Tabellenbreite ist, entscheiden
anhand des Wertes der 'overflow'-Eigenschaft, ob der berlaufenden Inhalt abgeschnitten wer-
den soll.
Automatisches Tabellenlayout
Bei diesem Algorithmus (der im Allgemeinen mehr als zwei Durchg@nge ben=tigt), wird die
Tabellenbreite durch die Breite ihrer Spalten (und dazwischenliegenden Rahmen) festgelegt.
Dieser Algorithmus reflektiert das Verhalten mehrerer bekannter HTML-Benutzerprogramme
zum Zeitpunkt der Drucklegung dieser Spezifikation. Benutzerprogramme m ssen diesen Algo-
rithmus nicht implementieren, um das Tabellenlayout im Falle von 'table-layout' gleich 'auto' zu
implementieren; sie k=nnen einen beliebigen anderen Algorithmus verwenden.
Dieser Algorithmus kann ineffizient sein, weil er einerseits fordert, dass das Benutzerprogramm
Zugriff auf den gesamten Tabelleninhalt hat, bevor das endg ltige Layout festgelegt werden
kann, und weil andererseits daf r mehrere Durchg@nge erforderlich sein k=nnen.
Visuelles Layout von Tabelleninhalt < 797 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Die Spaltenbreiten werden wie folgt ermittelt:
1. Berechnung der Mindestinhaltsbreite (MIB) jeder Zelle: Der formatierte Inhalt kann sich
ber mehrere Zeilen erstrecken, darf jedoch nicht ber die Zell-Box hinausgehen. Ist die
angegebene 'width' (W) der Zelle gr=ßer als MIB, ist W die Mindestzellbreite. Der Wert
'auto' bedeutet, dass MIB die Mindestzellbreite darstellt.
Außerdem kann die „maximale“ Zellbreite f r jede Zelle berechnet werden: Anschließend
kann der Inhalt formatiert werden, ohne andere Zeilen umzubrechen, mit Ausnahme jener
Zeilen, f r die explizite Zeilenumbr che auftreten.
2. F r jede Spalte kann eine maximale und minimale Spaltenbreite aus den Zellen ermittelt
werden, die sich nur ber diese Spalte erstrecken. Das Minimum ist das, das von der Zelle
mit der gr=ßten minimalen Zellenbreite (oder Spaltenbreite, abh@ngig davon, was von bei-
den gr=ßer ist) ben=tigt wird. Das Maximum ist das, das von der Zelle mit der gr=ßten
maximalen Zellbreite (oder der Spaltenbreite, abh@ngig davon, was von beiden gr=ßer ist)
ben=tigt wird.
3. F r jede Zelle, die sich ber mehr als eine Spalte erstreckt, wird die Mindestbreite der Spal-
ten erh=ht, ber die sie sich erstreckt, so dass sie zusammen mindestens so breit sind wie
die Zelle. Dasselbe erfolgt f r die maximalen Breiten. Wenn m=glich, sollten alle abgedeck-
ten Spalten um denselben Betrag verbreitert werden.
Damit erh@lt man eine maximale und minimale Breite f r jede Spalte. Die Spaltenbreiten beein-
flussen die endg ltige Tabellenbreite wie folgt:
1. Wenn die 'width'-Eigenschaft des 'table'- oder 'inline-table'-Elements einen vorgegebenen
Wert (W) hat, der ungleich 'auto' ist, dann ist der berechnete Wert der Eigenschaft der
gr=ßere Wert von W und der Mindestbreite, die alle Spalten brauchen, plus der Zellab-
st@nde oder Rahmen (MIN). Ist W gr=ßer MIN, sollte die zus@tzliche Breite ber die Spal-
ten verteilt werden.
2. Hat das 'table'- oder 'inline-table'-Element die Eigenschaft 'width: auto', ist die berechnete
Tabellenbreite der gr=ßere Wert aus der Breite des die Tabelle umschließenden Blocks
und MIN. Ist die maximale Breite, die f r die Spalten plus Zellauff llung oder Rahmen
Cascading Style Sheets, Level 2
(MAX) erforderlich ist, kleiner als die des umschließenden Blocks, wird MAX verwendet.
Ein Prozentwert f r eine Spaltenbreite ist relativ zur Tabellenbreite. Hat die Tabelle die Eigen-
schaft 'width: auto', stellt ein Prozentwert eine Beschr@nkung f r die Spaltenbreite dar, die ein
Benutzerprogramm einhalten sollte. (Offensichtlich ist das nicht immer m=glich: Ist die Spalten-
breite gleich '110%', kann die Beschr@nkung nicht mehr eingehalten werden.)
Hinweis: In diesem Algorithmus werden Zeilen (und Zeilengruppen) und Spalten (und Spalten-
gruppen) durch die Gr=ße der enthaltenen Zellen beschr@nkt und beschr@nken diese. Durch
die Festlegung der Breite einer Spalte kann die H=he einer Zeile indirekt beeinflusst werden
und umgekehrt. n
17.5.3 Algorithmen f-r die TabellenhUhe
Die H=he einer Tabelle wird durch die 'height'-Eigenschaft f r das 'table'- oder 'inline-table'-Ele-
ment festgelegt. Der Wert 'auto' bedeutet, dass die H=he gleich der Summe der Zeilenh=hen
plus aller Zellenabst@nde oder Rahmen ist. Jeder andere Wert gibt die H=he explizit an; die
Tabelle kann also h=her oder niedriger als die H=he ihrer Zeilen sein. CSS2 gibt nichts f r die
Darstellung vor, wenn sich die angegebene Tabellenh=he von der Inhaltsh=he unterscheidet,
< 798 > Tabellen
Page size: 168,00 x 240,00 mm
insbesondere, ob die Inhaltsh=he die angegebene H=he berschreiben soll; ist dies nicht der
Fall, wie soll dann der zus@tzliche Platz ber die Zeilen verteilt werden, der sich aus einer H=he
geringer als die angegebene Tabellenh=he ergibt; oder soll das Benutzerprogramm, falls die
Inhaltsh=he die angegebene Tabellenh=he berschreitet, einen Mechanismus bereitstellen, mit
dem der Inhalt weitergebl@ttert werden kann?
Hinweis: Zuk nftige Versionen von CSS werden diese Problematik vielleicht genauer behan-
deln. n
Die H=he der Box eines 'table-row'-Elements wird berechnet, nachdem dem Benutzerpro-
gramm alle Zellen der Zeile zur Verf gung stehen: Es ist der Maximalwert aus der angegebenen
H=he der Zeile ('height') und der Mindesth=he (MIN), die f r die Zellen erforderlich ist. Ein
'height'-Wert von 'auto' f r eine 'table-row' bedeutet, die berechnete Zeilenh=he ist MIN. MIN
ist von der Zell-Box-H=he und der Zell-Box-Ausrichtung abh@ngig (@hnlich wie die Berechnung
einer Zeilen-Box-H=he). CSS2 definiert nicht, worauf sich Prozentwerte von 'height' beziehen,
wenn sie f r Tabellenzeilen und Zeilengruppen angegeben werden.
In CSS2 ist die H=he einer Zell-Box der Maximalwert aus der 'height'-Eigenschaft der Tabellen-
zelle und der f r den Inhalt erforderlichen Mindesth=he (MIN). Der Wert 'auto' f r 'height'
impliziert einen berechneten Wert von MIN. CSS2 definiert nicht, worauf sich Prozentwerte
von 'height' beziehen, wenn sie f r Tabellenzellen angegeben sind.
CSS2 gibt nicht an, wie Tabellenzellen, die sich ber mehrere Zeilen erstrecken, die Zeilenh=-
henberechnungen beeinflussen. Es wird nur vorgegeben, dass die Summe der betreffenden Zei-
lenh=hen groß genug sein muss, um die Zelle aufzunehmen, die sich ber die Zeilen erstreckt.
Die 'vertical-align'-Eigenschaft jeder Tabellenzelle legt ihre Ausrichtung innerhalb der Zeile fest.
Der Inhalt jeder Zelle hat eine Grundlinie, ein Oben, eine Mitte und ein Unten, genau wie die
eigentliche Zeile auch. Im Kontext von Tabellen haben die Werte f r 'vertical-align' die folgen-
den Bedeutungen:
baseline
Cascading Style Sheets, Level 2
Die Grundlinie der Zelle erh@lt dieselbe H=he wie die Grundlinie der ersten der Zeilen,
ber die sie sich erstreckt (eine Definition der Grundlinien von Zellen und Zeilen finden Sie
nachfolgend).
top
Die obere Kante der Zell-Box wird an der oberen Kante der ersten Zeile ausgerichtet,
ber die sie sich erstreckt.
bottom
Die untere Kante der Zell-Box wird an der unteren Kante der letzten Zeile ausgerichtet,
ber die sie sich erstreckt.
middle
Der Mittelpunkt der Zelle wird an dem Mittelpunkt der Zeile ausgerichtet, ber die sie sich
erstreckt.
sub, super, text-top, text-bottom
Diese Werte gelten nicht f r Zellen; die Zelle wird in diesen F@llen an der Grundlinie aus-
gerichtet.
Visuelles Layout von Tabelleninhalt < 799 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Die Grundlinie einer Zelle ist die Grundlinie der ersten Zeilen-Box in der Zelle. Falls es keinen
Text gibt, ist die Grundlinie die Grundlinie des Objekts, das in der Zelle angezeigt wird, oder,
falls es kein solches gibt, die untere Kante der Zell-Box. Der maximale Abstand zwischen der
oberen Kante der Zell-Box und der Grundlinie ber alle Zellen, f r die 'vertical-align: baseline'
gilt, wird verwendet, um die Grundlinie der Zeile zu setzen. Hier ein Beispiel:
Beispiel
Abbildung 17.6: Skizze, die die Auswirkung verschiedener Werte von 'vertical-align' auf
Tabellenzellen verdeutlicht.
Die Zell-Boxen 1 und 2 werden an ihren Grundlinien ausgerichtet. Zell-Box 2 hat die
gr=ßte H=he ber der Grundlinie und legt damit die Grundlinie der Zeile fest. Beachten
Cascading Style Sheets, Level 2
Sie, dass die Zeile keine Grundlinie hat (oder braucht), wenn keine Zell-Box an ihrer
Grundlinie ausgerichtet ist.
Um mehrdeutige Situationen zu vermeiden, geht die Ausrichtung der Zellen in der nachstehen-
den Reihenfolge vor:
1. Zuerst werden die Zellen positioniert, die an ihrer Grundlinie ausgerichtet sind. Damit
wird die Grundlinie der Zeile eingerichtet. Anschließend werden die Zellen mit 'vertical-
align: top' positioniert.
2. Jetzt hat die Zeile eine obere Kante, m=glicherweise eine Grundlinie sowie eine provisori-
sche H=he, n@mlich den Abstand von der oberen Kante zu der untersten Kante der bisher
positionierten Zellen. (Weitere Bedingungen der Zellauff llung finden Sie nachfolgend.)
3. Falls eine der weiteren Zellen, die unten oder in der Mitte ausgerichtet sind, eine H=he hat,
die gr=ßer als die aktuelle H=he der Zeile ist, wird die Zeilenh=he auf das Maximum dieser
Zellen erh=ht, indem die Unterkante abgesenkt wird.
4. Schließlich werden die restlichen Zellen positioniert.
Zellboxen, die kleiner als die Zeilenh=he sind, erhalten eine zus@tzliche Polsterung oben oder
unten.
< 800 > Tabellen
Page size: 168,00 x 240,00 mm
17.5.4 Horizontale Ausrichtung in einer Spalte
Die horizontale Ausrichtung eines Zellinhalts innerhalb einer Zell-Box wird mit Hilfe der 'text-
align'-Eigenschaft angegeben.
Wenn die 'text-align'-Eigenschaft f r mehr als eine Zelle in einer Spalte auf einen Zeichenket-
tenwert gesetzt ist, wird der Inhalt dieser Zellen entlang einer vertikalen Achse ausgerichtet.
Der Anfang der Zeichenkette ber hrt diese Achse. Die Richtung der Zeichen bestimmt, ob die
Zeichenkette links oder rechts von der Achse liegt.
Die Ausrichtung des Texts auf diese Weise ist nur dann sinnvoll, wenn der Text in eine Zeile
passt. Das Ergebnis ist nicht definiert, wenn sich der Zellinhalt ber mehr als eine Zeile erstreckt.
Falls der Wert von 'text-align' f r eine Tabellenzelle eine Zeichenkette ist, die Zeichenkette
aber nicht im Zellinhalt auftritt, ber hrt das Ende des Zellinhalts die vertikale Achse der Aus-
richtung.
Beachten Sie, dass die Zeichenketten nicht f r alle Zellen gleich sein m ssen, obwohl dies nor-
malerweise der Fall ist.
CSS unterst tzt keine Methode, um den Abstand der vertikalen Ausrichtungsachse relativ zur
Kante einer Spalten-Box anzugeben.
Beispiel
Das folgende Stylesheet:
TD { text-align: "." }
TD:before { content: "$" }
bewirkt, dass die Spalte der Dollarwerte in der folgenden HTML-Tabelle:
<TABLE>
<COL width="40">
<TR> <TH>Ferngespr]che
<TR> <TD> 1.30
Cascading Style Sheets, Level 2
<TR> <TD> 2.50
<TR> <TD> 10.80
<TR> <TD> 111.01
<TR> <TD> 85.
<TR> <TD> 90
<TR> <TD> .05
<TR> <TD> .06
</TABLE>
entlang des Dezimalpunkts ausgerichtet werden. Spaßeshalber haben wir das Pseudo-Element
:before verwendet, um vor jeder Zahl ein Dollarzeichen einzuf gen. Die Tabelle k=nnte wie
folgt dargestellt werden:
Ferngespr]che
$1.30
$2.50
$10.80
$111.01
$85.
$90
$.05
$.06
Visuelles Layout von Tabelleninhalt < 801 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
17.5.5 Dynamische Zeilen- und Spalteneffekte
Die 'visibility'-Eigenschaft nimmt den Wert 'collapse' f r Zeilen-, Zeilengruppen-, Spalten- und
Spaltengruppenelemente an. Dieser Wert bewirkt, dass die ganze Zeile oder Spalte aus der
Anzeige entfernt und der Platz, der normalerweise von der Zeile oder Spalte belegt wird, f r
anderen Inhalt verf gbar gemacht wird. Die Unterdr ckung der Zeile oder Spalte wirkt sich
jedoch nicht anderweitig auf das Layout der Tabelle aus. Das erlaubt dynamische Effekte zum
Entfernen von Tabellenzeilen oder -spalten, ohne eine Neudarstellung der Tabelle zu erzwin-
gen, um die m=glichen Onderungen in Spaltenbeschr@nkungen zu ber cksichtigen.
17.6 Rahmen
Es gibt zwei verschiedene Modelle, um in CSS Rahmen f r Tabellenzellen zu setzen. Das eine
ist am besten f r so genannte trennende Rahmen um einzelne Zellen herum geeignet, das
andere f r Rahmen, die fortlaufend vom einen Ende der Tabelle zum anderen verlaufen. Mit
jedem dieser Modelle k=nnen viele Rahmenstile generiert werden, deshalb ist es h@ufig
Geschmackssache, welches von beiden verwendet wird.
'border-collapse'
Wert: collapse | separate | inherit
Ausgangswert: collapse
Angewendet auf: 'table'- und 'inline-table'-Elemente
Vererbt: Ja
Prozentwerte: N/A
Medium: Visual
Cascading Style Sheets, Level 2
Diese Eigenschaft legt das Rahmenmodell f r eine Tabelle fest. Der Wert 'separate' w@hlt das
Rahmenmodell mit trennenden Rahmen aus. Der Wert 'collapse' w@hlt das Modell mit zusam-
menfallenden Rahmen aus. Die Modelle sind nachfolgend beschrieben.
17.6.1 Das Modell mit trennenden Rahmen
'border-spacing'
Wert: <length> <length>? | inherit
Ausgangswert: 0
Angewendet auf: 'table'- und 'inline-table'-Elemente
Vererbt: Ja
Prozentwerte: N/A
Medium: Visual
< 802 > Tabellen
Page size: 168,00 x 240,00 mm
Die L@nge gibt den Abstand an, der benachbarte Zellrahmen voneinander trennt. Wird nur eine
L@nge angegeben, gibt sie sowohl den horizontalen als auch den vertikalen Abstand an. Werden
zwei L@ngen angegeben, bezieht sich die erste auf den horizontalen Abstand, die zweite auf den
vertikalen Abstand. L@ngen d rfen nicht negativ sein.
In diesem Modell hat jede Zelle einen eigenen Rahmen. Die 'border-spacing'-Eigenschaft gibt
den Abstand zwischen den Rahmen benachbarter Zellen an. Dieser Abstand wird mit dem Hin-
tergrund des Tabellenelements gef llt. Zeilen, Spalten, Zeilengruppen und Spaltengruppen k=n-
nen keine Rahmen haben (das heißt, Benutzerprogramme m ssen die Rahmeneigenschaften f r
diese Elemente ignorieren).
Beispiel
Die Tabelle in der nachfolgenden Abbildung k=nnte das Ergebnis etwa des folgenden
Stylesheets sein:
TABLE { border: outset 10pt;
border-collapse: separate;
border-spacing: 15pt }
TD { border: inset 5pt }
[Link] { border: inset 10pt } /* Die obere linke Zelle */
table width
table border
(outset)
vertical
cell−spacing
Cascading Style Sheets, Level 2
cell border
(inset)
cell width horizontal
cell−spacing
Abbildung 17.7: Eine Tabelle, deren 'border-spacing' auf einen L@ngenwert gesetzt ist. Beachten
Sie, dass jede Zelle einen eigenen Rahmen hat und die Tabelle einen separaten Rahmen hat.
Rahmen < 803 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Rahmen um leere Zellen: die Eigenschaft 'empty-cells'
'empty-cells'
Wert: show | hide | inherit
Ausgangswert: show
Angewendet auf: 'table-cell'-Elemente
Vererbt: Ja
Prozentwerte: N/A
Medium: Visual
Bei dem Modell der trennenden Rahmen steuert diese Eigenschaft die Darstellung von Rahmen
um Zellen, die keinen sichtbaren Inhalt haben. Leere Zellen und Zellen, deren 'visibility'-Eigen-
schaft auf 'hidden' gesetzt ist, werden so behandelt, als h@tten sie keinen sichtbaren Inhalt.
Sichtbarer Inhalt beinhaltet „ “ und anderen Leeraum außer ASCII Wagenr cklauf
(„\0D“), Zeilenvorschub („\0A“), Tabulator („\09“) und Leerzeichen („\20“).
Wenn diese Eigenschaft den Wert 'show' hat, werden Rahmen um leere Zellen (wie um nor-
male Zellen) gezogen.
Der Wert 'hide' bedeutet, dass um leere Zellen keine Rahmen gezogen werden. Haben dar ber
hinaus alle Zellen in einer Zeile den Wert 'hide' und keinen sichtbaren Inhalt, verh@lt sich die
gesamte Zeile so, als w@re 'dispay: none'.
Beispiel
Die folgende Regel bewirkt, dass Rahmen um alle Zellen gezogen werden:
TABLE { empty-cells: show }
Cascading Style Sheets, Level 2
17.6.2 Das Modell mit den zusammenfallenden Rahmen
Im Modell mit den zusammenfallenden Rahmen ist es m=glich, Rahmen anzugeben, die einen
Teil oder eine gesamte Zelle, Zeile, Zeilengruppe, Spalte und Spaltengruppe umrahmen. Auf
diese Weise k=nnen Rahmen f r das „rule“-Attribut angegeben werden.
Rahmen sind an den Rasterlinien zwischen den Zellen zentriert. Benutzerprogramme m ssen
eine konsistente Regel finden, um im Fall einer ungeraden Nummer diskreter Einheiten (Bild-
schirmpixel, Druckerpunkte) abzurunden.
Die folgende Skizze zeigt, wie die Breite der Tabelle, die Breite der Rahmen, die Auff llung und
die Zellbreite zusammenspielen. Ihre Beziehung wird durch die folgende Gleichung beschrie-
ben, die f r jede Zeile der Tabelle gilt:
Zeilenbreite = (0.5 * border-width0) + padding-left1 + width1 + padding-right1 + border-
width1 + padding-left2 + ... + padding-rightn + (0.5 * border-widthn)
Hier ist n die Anzahl der Zellen in der Zeile, und border-widthi bezieht sich auf den Rahmen
zwischen den Zellen i und i+1. Beachten Sie, dass f r die Tabellenbreite nur die H@lfte der bei-
den @ußeren Rahmen ber cksichtigt wird; die andere H@lfte dieser beiden Rahmen liegt im
Randbereich.
< 804 > Tabellen
Page size: 168,00 x 240,00 mm
border−width
border−width
border−width
border−width
padding
padding
padding
padding
padding
padding
cell
width width width
table width grid line
Abbildung 17.8: Schema, das die Breiten von Zellen und Rahmen und die Auff llung von Zellen
zeigt
Beachten Sie, dass die Breite der Tabelle in diesem Modell die H@lfte des Tabellenrahmens ent-
h@lt. Dar ber hinaus hat eine Tabelle in diesem Modell keine Auff llung (aber R@nder).
RahmenkonfliktauflUsung
Im Modell f r zusammenfallende Rahmen kann jede Kante jeder Zelle durch Rahmeneigenschaf-
ten f r eine Vielzahl von Elementen gesetzt werden, die diese Kanten treffen (Zellen, Zeilen,
Cascading Style Sheets, Level 2
Zeilengruppen, Spalten, Spaltengruppen und die eigentliche Tabelle), und diese Rahmen k=nnen
in Breite, Stil und Farbe variieren. Die Faustregel dabei ist, dass an jeder Kante der am besten
ins Auge fallende Rahmenstil verwendet wird. Sie gilt nur dann nicht, wenn irgendein Auftreten
des Stils 'hidden' den Rahmen unbedingt deaktiviert.
Die folgenden Regeln legen fest, welcher Rahmen im Falle eines Konflikts „gewinnt“:
1. Rahmen mit dem 'border-style' 'hidden' haben Priorit@t gegen ber allen anderen konflikt-
erzeugenden Rahmen. Jeder Rahmen mit diesem Wert unterdr ckt alle Rahmen an dieser
Position.
2. Rahmen mit dem Stil 'none' haben die geringste Priorit@t. Nur wenn die Rahmeneigenschaf-
ten aller Elemente, die sich an dieser Kante treffen, gleich 'none' sind, wird der Rahmen
weggelassen (aber beachten Sie, dass 'none' der Standardwert f r den Rahmenstil ist.)
3. Ist keiner der Stile gleich 'hidden' und mindestens einer davon ist nicht 'none', werden
schmale Rahmen zugunsten breiter Rahmen verworfen. Haben mehrere Rahmen dieselbe
'border-width', erhalten die Stile in dieser Reihenfolge Priorit@t: 'double', 'solid', 'dashed',
'dotted', 'ridge', 'outset', 'groove', und die niedrigste: 'inset'.
4. Unterscheiden sich die Rahmenstile nur in der Farbe, gewinnt der f r eine Zelle gesetzte
Stil gegen ber dem f r eine Zeile, der gegen ber dem f r eine Zeilengruppe, Spalte, Spal-
tengruppe und schließlich Tabelle gewinnt.
Rahmen < 805 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Beispiel
Das folgende Beispiel zeigt die Anwendung dieser Priorit@tsregeln. Das folgende Style-
sheet:
TABLE { border-collapse: collapse;
border: 5px solid yellow; }
*#col1 { border: 3px solid black; }
TD { border: 1px solid red; padding: 1em; }
[Link]-blue { border: 5px dashed blue; }
[Link]-green { border: 5px solid green; }
mit dieser HTML-Quelle:
<P>
<TABLE>
<COL id="col1"><COL id="col2"><COL id="col3">
<TR id="row1">
<TD> 1
<TD> 2
<TD> 3
</TR>
<TR id="row2">
<TD> 4
<TD class="solid-blue"> 5
<TD class="solid-green"> 6
</TR>
<TR id="row3">
<TD> 7
<TD> 8
<TD> 9
</TR>
<TR id="row4">
<TD> 10
Cascading Style Sheets, Level 2
<TD> 11
<TD> 12
</TR>
<TR id="row5">
<TD> 13
<TD> 14
<TD> 15
</TR>
</TABLE>
< 806 > Tabellen
Page size: 168,00 x 240,00 mm
w rde etwa Folgendes erzeugen:
Abbildung 17.9: Beispiel f r eine Tabelle mit zusammenfallenden Rahmen
Das n@chste Beispiel zeigt eine Tabelle mit horizontalen Linien zwischen den Zeilen. Der
oberste Rahmen der Tabelle ist auf 'hidden' gesetzt, um den obersten Rahmen der ersten Zeile
zu unterdr cken. Das implementiert das „rules“-Attribut von HTML 4.0 (rules=„rows“).
TABLE[rules=rows] TR { border-top: solid }
TABLE[rules=rows] { border-collapse: collapse;
border-top: hidden }
a b c
3 4 5
Cascading Style Sheets, Level 2
5 12 13
Abbildung 17.10: Tabelle mit horizontalen Linien zwischen den Zeilen
In diesem Fall kann derselbe Effekt auch erzielt werden, ohne einen 'hidden'-Rahmen f r TABLE
zu setzen, indem die erste Zeile separat adressiert wird. Welche Methode bevorzugt wird, ist
Geschmackssache.
TR:first-child { border-top: none }
TR { border-top: solid }
Abbildung 17.11: Tabelle, in der zwei interne Rahmen weggelassen wurden
Rahmen < 807 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
HTML-Quelle:
<TABLE style="border-collapse: collapse; border: solid;">
<TR><TD style="border-right: hidden; border-bottom: hidden">foo</TD>
<TD style="border: solid">bar</TD></TR>
<TR><TD style="border: none">foo</TD>
<TD style="border: solid">bar</TD></TR>
</TABLE>
17.6.3 Rahmenstile
Einige Werte von 'border-style' haben in Tabellen andere Bedeutungen als f r andere Elemen-
te. In der nachfolgenden Liste sind sie mit einem Stern markiert.
none
Kein Rahmen.
*hidden
Wie 'none', außer im Modell f r kollabierende Rahmen; verbietet alle anderen Rahmen
(siehe vorhergehenden Abschnitt ber Rahmenkonflikte).
dotted
Der Rahmen besteht aus einer Reihe von Punkten.
dashed
Der Rahmen ist eine Folge aus kurzen Liniensegmenten.
solid
Der Rahmen ist ein einzelnes Liniensegment.
double
Der Rahmen besteht aus zwei durchgezogenen Linien. Die Summe der beiden Linien und
der Platz zwischen ihnen ist gleich dem Wert von 'border-width'.
groove
Cascading Style Sheets, Level 2
Der Rahmen sieht aus, als w@re er in die Zeichenfl@che eingemeißelt.
ridge
Das Gegenteil von 'groove': der Rahmen sieht aus, als w rde er sich aus der Zeichenfl@che
erheben.
*inset
Im Modell f r trennende Rahmen bewirkt der Rahmen, dass die gesamte Box so aussieht,
als w@re sie in die Zeichenfl@che eingebettet. Im Modell f r zusammenfallenden Rahmen
bedeutet dieser Wert dasselbe wie 'groove'
*outset
Im Modell f r trennende Rahmen bewirkt dieser Rahmen, dass die gesamte Box so aussieht,
als w rde sie sich aus der Zeichenfl@che erheben. Im Modell f r zusammenfallende Rahmen
bedeutet dieser Wert dasselbe wie 'ridge'.
17.7 Akustische Darstellung von Tabellen
Wenn eine Tabelle von einem Sprachgenerator gesprochen wird, muss die Beziehung zwischen
den Datenzellen und den berschriftszellen anders ausgedr ckt werden als durch eine hori-
zontale oder vertikale Ausrichtung. Einige Sprach-Browser erlauben einem Benutzer m=gli-
< 808 > Tabellen
Page size: 168,00 x 240,00 mm
cherweise, sich im zweidimensionalen Raum zu bewegen, so dass sie die M=glichkeit erhalten,
die r@umlich dargestellten Relationen auszudr cken. Wenn dies nicht m=glich ist, muss das
Stylesheet angeben, an welchen Stellen die berschriften gesprochen werden:
17.7.1 berschriften aussprechen: die 'speak-header'-Eigenschaft
'speak-header'
Wert: once | always | inherit
Ausgangswert: show
Angewendet auf: Elemente, die Tabellen berschriftsinformationen haben
Vererbt: Ja
Prozentwerte: N/A
Medium: Aural
Diese Eigenschaft gibt an, ob Tabellen berschriften vor jeder Zelle gesprochen werden oder
nur vor einer Zelle, wenn diese einer anderen berschrift zuzuordnen ist als die vorher-
gehende Zelle. Die Werte haben die folgenden Bedeutungen:
once
Die berschrift wird einmal vor einer Folge von Zellen gesprochen.
always
Die berschrift wird vor jeder passenden Zelle gesprochen.
Jede Dokumentsprache kann unterschiedliche Mechanismen unterst tzen, die es Autoren
erlauben, berschriften anzugeben. In HTML 4.0 ([HTML40]) beispielsweise ist es m=glich,
Cascading Style Sheets, Level 2
berschriftsinformationen mit drei verschiedenen Attributen („headers“, „scope“ und „axis“)
anzulegen. Die Spezifikation bietet einen Algorithmus, mit dem berschriftsinformationen
ermittelt werden, falls diese Attribute nicht angegeben wurden.
Abbildung 17.12: Bild einer Tabelle mit berschriftszellen („San Jose“ und „Seattle“), die sich
nicht in derselben Spalte oder Zeile befinden wie die Daten, auf die sie sich beziehen
Akustische Darstellung von Tabellen < 809 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Beispiel
Dieses HTML-Beispiel zeigt das Geld, das f r Mahlzeiten, Hotels und Transport an zwei
Orten (San Jose und Seattle) an aufeinanderfolgenden Tagen ausgegeben wurde. Grund-
s@tzlich k=nnen Sie sich die Tabelle wie einen n-dimensionalen Raum vorstellen. Die
berschriften dieses Raums sind: Ort, Tag, Kategorie und Zwischensumme. Einige Zel-
len definieren Markierungen entlang einer Achse, w@hrend andere das Geld an den
Punkten innerhalb dieses Raums angeben. Die Quellcode f r diese Tabelle lautet:
<TABLE>
<CAPTION>Travel Expense Report</CAPTION>
<TR>
<TH></TH>
<TH>Meals</TH>
<TH>Hotels</TH>
<TH>Transport</TH>
<TH>subtotal</TH>
</TR>
<TR>
<TH id="san-jose" axis="san-jose">San Jose</TH>
</TR>
<TR>
<TH headers="san-jose">25-Aug-97</TH>
<TD>37.74</TD>
<TD>112.00</TD>
<TD>45.00</TD>
<TD></TD>
</TR>
<TR>
<TH headers="san-jose">26-Aug-97</TH>
<TD>27.28</TD>
<TD>112.00</TD>
<TD>45.00</TD>
<TD></TD>
Cascading Style Sheets, Level 2
</TR>
<TR>
<TH headers="san-jose">subtotal</TH>
<TD>65.02</TD>
<TD>224.00</TD>
<TD>90.00</TD>
<TD>379.02</TD>
</TR>
<TR>
<TH id="seattle" axis="seattle">Seattle</TH>
</TR>
<TR>
<TH headers="seattle">27-Aug-97</TH>
<TD>96.25</TD>
<TD>109.00</TD>
<TD>36.00</TD>
<TD></TD>
</TR>
<TR>
<TH headers="seattle">28-Aug-97</TH>
<TD>35.00</TD>
<TD>109.00</TD>
< 810 > Tabellen
Page size: 168,00 x 240,00 mm
<TD>36.00</TD>
<TD></TD>
</TR>
<TR>
<TH headers="seattle">subtotal</TH>
<TD>131.25</TD>
<TD>218.00</TD>
<TD>72.00</TD>
<TD>421.25</TD>
</TR>
<TR>
<TH>Totals</TH>
<TD>196.27</TD>
<TD>442.00</TD>
<TD>162.00</TD>
<TD>800.27</TD>
</TR>
</TABLE>
Durch diese Bereitstellung des Datenmodells machen es Autoren f r sprachf@hige Browser
m=glich, eine Tabelle auf die unterschiedlichsten Arten zu erkunden, z. B. k=nnte jede Zelle als
Liste gesprochen werden, wobei die betreffenden berschriften vor jeder Datenzelle wieder-
holt werden:
San Jose, 25-Aug-97, Meals: 37.74
San Jose, 25-Aug-97, Hotels: 112.00
San Jose, 25-Aug-97, Transport: 45.00
...
Der Browser k=nnte auch entscheiden, die berschriften nur dann zu sprechen, wenn sie sich
@ndern:
Cascading Style Sheets, Level 2
San Jose, 25-Aug-97, Meals: 37.74
Hotels: 112.00
Transport: 45.00
26-Aug-97, Meals: 27.28
Hotels: 112.00
...
Akustische Darstellung von Tabellen < 811 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
18 [Link]
18.1 Cursor: die 'cursor'-Eigenschaft
'cursor'
Wert: [[<uri>,]* [auto | crosshair | default | pointer | move | e-resize |
ne-resize | nw-resize | n-resize | se-resize | sw-resize | s-resize |
w-resize | text | wait | help ]] | inherit
Ausgangswert: auto
Angewendet auf: Alle Elemente
Vererbt: Ja
Prozentwerte: N/A
Medium: Visual, Interactive
Diese Eigenschaft gibt den Typ des Cursors an, der f r das Zeigeger@t angezeigt wird. Die
Werte haben die folgenden Bedeutungen:
auto
Das Benutzerprogramm ermittelt den anzuzeigenden Cursor abh@ngig vom aktuellen Kon-
text.
crosshair
Ein einfaches Fadenkreuz (z. B. kurze Liniensegmente, die an ein "+"-Zeichen erinnern).
default
Der von der Plattform abh@ngige Standard-Cursor. Wird h@ufig als Pfeil dargestellt.
Cascading Style Sheets, Level 2
pointer
Der Cursor ist ein Zeiger, der einen Link anzeigt.
move
Kennzeichnet, dass etwas verschoben werden soll.
e-resize, ne-resize, nw-resize, n-resize, se-resize, sw-resize, s-resize, w-resize
Gibt an, dass eine Fensterkante verschoben werden soll. Beispielsweise wird der 'se-re-
size'-Cursor verwendet, wenn das Verschieben in der rechten unteren Ecke der Box beginnt.
text
Gibt an, dass Text markiert werden kann. Wird h@ufig auch als I-Balken dargestellt.
wait
Zeigt an, dass das Programm besch@ftigt ist und der Benutzer warten soll. Wird h@ufig als
Uhr oder Sanduhr dargestellt.
help
Es steht Hilfe f r das Objekt unter dem Cursor zur Verf gung. Wird h@ufig auch als Frage-
zeichen oder Sprechblase dargestellt.
< 812 > Benutzeroberfl,che
Page size: 168,00 x 240,00 mm
<uri>
Das Benutzerprogramm l@dt den Cursor aus der durch den URI angegebene Ressource.
Wenn das Benutzerprogramm den ersten Cursor aus einer Liste mit Cursorn nicht ver-
arbeiten kann, sollte er versuchen, den zweiten zu verarbeiten usw. Wenn das Benutzer-
programm keine benutzerdefinierten Cursor verarbeiten kann, muss es den generischen
Cursor am Ende der Liste verwenden.
Beispiel
P { cursor : url("[Link]"), url("[Link]"), text; }
18.2 Benutzereinstellungen f-r Farben
CSS2 erm=glicht nicht nur, Text, Hintergr nden usw. vordefinierte Farbwerte zuzuweisen,
sondern erlaubt Autoren außerdem, Farben so anzugeben, dass sie in die graphische Umgebung
des Benutzers integriert werden. Stilregeln, die Benutzerpriorit@ten ber cksichtigen, bieten
deshalb die folgenden Vorteile:
1. Sie erzeugen Seiten, die in das vom Benutzer definierte Look&Feel passen.
2. Sie erzeugen Seiten, auf die ein besserer Zugriff m=glich ist, weil die aktuellen Benutzerein-
stellungen m=glicherweise eine Behinderung ber cksichtigen.
Die f r die Systemfarben definierte Wertemenge ist darauf ausgelegt, dass sie vollst@ndig ist.
F r Systeme, die ber keinen entsprechenden Wert verf gen, sollte der angegebene Wert auf
das n@chstliegende Systemattribut oder auf eine Standardfarbe abgebildet werden.
Die folgende Liste beschreibt zus@tzliche Werte f r farbbezogene CSS-Attribute und ihre all-
gemeine Bedeutung. Jede Farbeigenschaft (z. B. 'color' oder 'background-color') kann einen der
folgenden Namen annehmen. Obwohl sie die Groß-/Kleinschreibung nicht ber cksichtigen,
wird empfohlen, dass die nachfolgend gezeigte gemischte Schreibweise ber cksichtigt wird, um
Cascading Style Sheets, Level 2
die Namen besser lesbar zu machen.
ActiveBorder
Aktiver Fensterrahmen
ActiveCaption
Aktiver Fenstertitel
AppWorkspace
Hintergrundfarbe eines Multiple Document Interfaces
Background
Desktop-Hintergrund
ButtonFace
Schriftfarbe f r dreidimensionale Anzeigeelemente
ButtonHighlight
Helle Farbe f r dreidimensionale Anzeigeelemente
ButtonShadow
Schattenfarbe f r dreidimensionale Anzeigeelemente (f r Kanten, die von der Lichtquelle
weg zeigen)
ButtonText
Text auf Schaltfl@chen
Benutzereinstellungen f#r Farben < 813 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
CaptionText
Text in berschriften, Size Boxes und Pfeilfeld der Bildlaufleiste
GrayText
Grau unterlegter (deaktivierter) Text. Diese Farbe wird auf #000 gesetzt, wenn der aktu-
elle Anzeigetreiber keine durchg@ngige graue Farbe unterst tzt.
Highlight
Elemente, die in einem Steuerelement markiert sind
HighlightText
Text von Elementen, die in einem Steuerelement markiert sind
InactiveBorder
Nicht aktiver Fensterrahmen
InactiveCaption
Nicht aktiver Fenstertitel
InactiveCaptionText
Farbe des Texts in einem nicht aktiven Titel
InfoBackground
Hintergrundfarbe f r Tooltip-Steuerelemente
InfoText
Textfarbe f r Tooltip-Steuerelemente
Menu
Men hintergrund
MenuText
Text in Men s
Scrollbar
Grauer Bereich der Bildlaufleiste
ThreeDDarkShadow
Dunkler Schatten f r dreidimensionale Anzeigeelemente
ThreeDFace
Cascading Style Sheets, Level 2
Schriftfarbe f r dreidimensionale Anzeigeelemente
ThreeDHighlight
Farbe f r die Hervorhebung von dreidimensionalen Anzeigeelementen
ThreeDLightShadow
Helle Farbe f r dreidimensionale Anzeigeelemente (f r Kanten, die zur Lichtquelle hin zei-
gen)
ThreeDShadow
Dunkler Schatten f r dreidimensionale Anzeigeelemente
Window
Fensterhintergrund
WindowFrame
Fensterrahmen
WindowText
Text in Fenstern
< 814 > Benutzeroberfl,che
Page size: 168,00 x 240,00 mm
Beispiel
Um beispielsweise die Hintergrund- und Vordergrundfarben eines Absatzes auf die Vor-
dergrund- und Hintergrundfarben des Benutzerfensters zu setzen, schreiben Sie Folgen-
des:
P { color: WindowText; background-color: Window }
18.3 Benutzereinstellungen f-r Schriften
Wie Farben k=nnen Autoren auch Schriften so angeben, dass die Systemressourcen der Benut-
zer genutzt werden. Weitere Informationen finden Sie im Abschnitt ber die 'font'-Eigenschaft
(15.2.5).
18.4 Dynamische Einrahmungen: die 'outline'-Eigenschaft
Manchmal wollen Stylesheet-Autoren Einrahmungen f r visuelle Objekte erstellen wie bei-
spielsweise f r Schaltfl@chen, aktive Formularfelder, Bilder und so weiter, so dass sie hervor-
gehoben dargestellt werden. CSS2-Einrahmungen unterscheiden sich wie folgt von Rahmen:
1. Einrahmungen ben=tigen keinen Platz.
2. Einrahmungen m ssen nicht rechteckig sein.
Die Einrahmungs-Eigenschaften steuern den Stil dieser dynamischen Einrahmungen.
'outline'
Wert: [<'outline-color'> | | <'outline-style'> | | <'outline-width'> ] | inherit
Ausgangswert: Siehe einzelne Eigenschaften
Angewendet auf: Alle Elemente
Cascading Style Sheets, Level 2
Vererbt: Nein
Prozentwerte: N/A
Medium: Visual, Interactive
'outline-width'
Wert: <border-width> | inherit
Ausgangswert: medium
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozentwerte: N/A
Medium: Visual, interactive
Benutzereinstellungen f#r Schriften < 815 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
'outline-color'
Wert: <color> | invert | inherit
Ausgangswert: invert
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozentwerte: N/A
Medium: Visual, Interactive
Die durch die Einrahmungseigenschaften erzeugten Einrahmungen werden „ ber“ eine Box
gezeichnet, das heißt, die Einrahmung befindet sich immer oben und beeinflusst die Position
oder die Gr=ße der Box oder irgendwelcher anderer Boxen nicht. Die Anzeige oder das
Unterdr cken von Einrahmungen verursacht also kein Neuzeichnen.
Die Einrahmung wird unmittelbar außerhalb der Rahmenkante beginnend gezeichnet.
Einrahmungen m ssen nicht rechteckig sein. Ist das Element beispielsweise ber mehrere Zei-
len umbrochen, ist die Einrahmung der kleinste Umriss, der alle Boxen des Elements beinhaltet.
Im Gegensatz zu Rahmen ist die Einrahmung am Ende oder Anfang einer Zeilen-Box nicht
ge=ffnet, sondern immer vollst@ndig geschlossen.
Die 'outline-width'-Eigenschaft akzeptiert dieselben Werte wie 'border-width'.
Die 'outline-style'-Eigenschaft akzeptiert dieselben Werte wie 'border-style', nur dass 'hidden'
kein erlaubter Einrahmungsstil ist.
Die 'outline-color'-Eigenschaft akzeptiert alle Farben sowie das Schl sselwort 'invert'. 'invert'
nimmt eine Farbumkehrung der Pixel auf dem Bildschirm vor. Dies ist ein gebr@uchlicher Trick,
um sicherzustellen, dass der Fokusrahmen sichtbar ist, unabh@ngig von farbigem Hintergrund.
Die 'outline'-Eigenschaft ist eine zusammenfassende Eigenschaft und setzt 'outline-style', 'out-
line-width' und 'outline-color'.
Cascading Style Sheets, Level 2
Beachten Sie, dass die Einrahmung auf allen Seiten dieselbe ist. Im Gegensatz zu Rahmen gibt es
keine 'outline-top'- oder 'outline-left'-Eigenschaft. n
Diese Spezifikation definiert nicht, wie mehrere berlappende Einrahmungen oder wie Einrah-
mungen f r Boxen gezeichnet werden, die teilweise von anderen Elementen verdeckt sind.
Hinweis: Weil die Fokuseinrahmung keinen Einfluss auf die Formatierung hat (das heißt, es ist
kein Platz mehr daf r im Box-Modell), kann sie m=glicherweise andere Elemente auf der Seite
berlappen. n
Beispiel
Nachfolgend sehen Sie ein Beispiel, das eine dicke Einrahmung um ein BUTTON-Ele-
ment zeichnet:
BUTTON { outline-width : thick }
Mit Hilfe von Skriptprogrammen kann die Breite der Einrahmung dynamisch ver@ndert werden,
ohne ein Neuzeichnen zu verursachen.
< 816 > Benutzeroberfl,che
Page size: 168,00 x 240,00 mm
18.4.2 Einrahmungen und der Fokus
Graphische Benutzeroberfl@chen k=nnen Einrahmungen um Elemente verwenden, um dem
Benutzer damit anzuzeigen, welches Element auf der Seite den Fokus hat. Diese Einrahmungen
werden zus@tzlich zu irgendwelchen Rahmen angezeigt, und das Aktivieren oder Deaktivieren
der Einrahmungen sollte nicht bewirken, dass das Dokument neu gezeichnet werden muss.
Der Fokus ist erforderlich f r die Benutzerinteraktion in einem Dokument (z. B. f r die Eingabe
von Text, die Auswahl einer Schaltfl@che usw.). Benutzerprogramme, die die interaktive
Mediengruppe unterst tzen, m ssen beobachten, wo sich der Fokus befindet, und sie m ssen
außerdem den Fokus darstellen. Das kann auch mit Hilfe dynamischer Einrahmungen erfolgen,
in Kombination mit der Pseudo-Klasse :focus.
Beispiel
Um beispielsweise eine dicke schwarze Linie um ein Element zu zeichnen, wenn es den
Fokus hat, und eine dicke rote Linie, wenn es aktiv ist, k=nnen die folgenden Regeln
angewendet werden:
:focus { outline: thick solid black }
:active { outline: thick solid red }
18.5 VergrUßerung
Die CSS Working Group hat beschlossen, dass die Vergr=ßerung eines Dokuments oder von
Teilen eines Dokuments nicht ber Stylesheets festgelegt werden sollte. Benutzerprogramme
k=nnen eine solche Vergr=ßerung auf unterschiedliche Weise unterst tzen (z. B. gr=ßere Bil-
der, lautere Sounds usw.).
Wenn Benutzerprogramme eine Seite vergr=ßern, sollten sie die Beziehungen zwischen posi-
tionierten Elementen beibehalten. Ein Comic-Strip k=nnte beispielsweise aus Bildern mit ber-
Cascading Style Sheets, Level 2
lagerten Textelementen zusammengesetzt werden. Wenn diese Seite vergr=ßert wird, sollte ein
Benutzerprogramm den Text weiterhin innerhalb der Sprechblasen des Comic-Strips anzeigen.
19 Akustische Stylesheets
19.1 Einf-hrung in akustische Stylesheets (Aural
Stylesheets)
Die akustische Darstellung eines Dokuments, die von blinden Benutzern sowie Benutzern, die
keine visuelle Ausgabe nutzen k=nnen, bereits h@ufig eingesetzt wird, kombiniert Sprachsyn-
these und „akustische Icons“. H@ufig erfolgt diese akustische Darstellung durch die Konvertie-
rung des Dokuments in einfachen Text, der dann einer so genannten Bildschirmleser-Software
oder -Hardware bergeben wird, die einfach alle Zeichen auf dem Bildschirm liest. Das Ergeb-
nis ist eine weniger effektive Darstellung, als w rde die Dokumentstruktur beibehalten. Style-
VergrFßerung < 817 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
sheet-Eigenschaften f r eine akustische Darstellung k=nnen mit den visuellen Eigenschaften (ge-
mischte Medien) kombiniert oder als akustische Alternative zur visuellen Darstellung verwen-
det werden.
Neben den offensichtlichen Vorteilen, die sie in Hinblick auf den Zugriff bringen, gibt es noch
andere große M@rkte f r rein akustisch angebotene Informationen, wie beispielsweise f r Auto-
fahrer, industrielle und medizinische Dokumentationssysteme, Home-Entertainment, oder um
Benutzer zu unterst tzen, die gerade lesen lernen oder Probleme mit dem Lesen haben.
Bei der Verwendung akustischer Eigenschaften besteht die Zeichenfl@che aus einem dreidimen-
sionalen physischen Raum (Klangumgebung) und einem tempor@ren Raum (man kann Klang vor
w@hrend und nach anderen Kl@ngen spezifizieren). Dar ber hinaus erlauben die CSS-Eigen-
schaften den Autoren, die Qualit@t synthetisierter Sprache zu variieren (Sprachtyp, Frequenz,
Modulation usw.).
Beispiel
H1, H2, H3, H4, H5, H6 {
voice-family: paul;
stress: 20;
richness: 90;
cue-before: url("[Link]")
}
[Link] { azimuth: center-left }
[Link] { azimuth: right }
[Link] { volume: x-soft }
Damit wird der Sprachsynthesizer angewiesen, die berschriften in der Sprache (eine Art „Au-
dio-Schrift“) namens „paul“ zu sprechen, in einem flachen Ton, aber mit einer sehr umfangrei-
chen Stimme zu sprechen. Bevor die berschriften gesprochen werden, wird ein Sound-Sample
von dem angegebenen URL abgespielt. Abs@tze mit der Klasse „heidi“ sollen so erscheinen,
dass sie von vorne links kommen (falls das Soundsystem r@umliches Audio beherrscht), und
Cascading Style Sheets, Level 2
Abs@tze mit der Klasse „peter“ von rechts. Abs@tze mit der Klasse „ziege“ werden sehr weich
gesprochen.
19.2 Eigenschaften f-r die [Link] : 'volume'
'volume'
Wert: <number> | <percentage> | silent | x-soft | soft | medium | loud
| x-loud | inherit
Ausgangswert: medium
Angewendet auf: Alle Elemente
Vererbt: Ja
Prozentzahlen Beziehen sich auf den geerbten Wert
Medium Aural
< 818 > Akustische Stylesheets
Page size: 168,00 x 240,00 mm
'volume' bezieht sich auf die Medien-Lautst@rke der Wellenform. Mit anderen Worten, eine
hochmodulierte Stimme mit einer Lautst@rke von 50 k=nnte sehr viel h=here Spitzenwerte
haben. Die Gesamtwerte k=nnen sehr wahrscheinlich f r den Menschen annehmbar angepasst
werden, beispielsweise mit einer physischen Lautst@rkenregelung (die sowohl die 0- als auch
die 100-Werte proportional vergr=ßern w rde); diese Eigenschaft passt also den dynamischen
Bereich an.
Die Werte haben die folgende Bedeutung:
<number>
Eine beliebige Zahl zwischen '0'und '100'. '0' stellt die minimale h rbare Lautst@rke dar, '100'
die maximale ertr,gliche Lautst@rke.
<percentage>
Prozentwerte werden relativ zum geerbten Wert berechnet und dann auf den Bereich
zwischen '0'und '100' zugeschnitten.
silent
Es wird berhaupt nichts ausgegeben. Der Wert '0' hat nicht dieselbe Bedeutung wie
'silent'.
x-soft
Entspricht '0'.
soft
Entspricht '25'.
medium
Entspricht '50'.
loud
Entspricht '75'
x-loud
Entspricht '100'.
Cascading Style Sheets, Level 2
Die Benutzerprogramme sollen es dem Zuh=rer gestatten, die Werte f r '0' und '100' zu set-
zen. Es gibt keine allgemein verwendbare Einstellung; geeignete Werte sind von der verwende-
ten Ausr stung abh@ngig (Lautsprecher, Kopfh=rer), von der Umgebung (im Auto, Heimkino,
Bibliothek) und von den pers=nlichen Vorlieben. Einige Beispiele:
· Ein Browser f r den Einsatz im Auto verwendet eine Einstellung f r sehr viel Hintergrund-
l@rm. '0' entspricht in diesem Fall einer relativ hohen Lautst@rke, '100' einer sehr hohen
Lautst@rke. Die Sprache ist gegen ber dem Straßenl@rm gut verst@ndlich, aber der gesamte
dynamische Bereich ist komprimiert. Autos mit besserer Isolation k=nnten einen breiteren
dynamischen Bereich erlauben.
· Ein anderer Sprach-Browser k=nnte beispielsweise in einem Appartement verwendet wer-
den, sp@t nachts oder in einem gemeinsamen Studierzimmer. '0' wird dann mit einer sehr
geringen Lautst@rke festgelegt, '100' mit einer immer noch relativ geringen Lautst@rke. Wie
im ersten Beispiel gibt es einen geringen Anstieg; der dynamische Bereich ist reduziert. Die
tats@chlichen Lautst@rken sind hier jedoch gering, w@hrend sie im ersten Beispiel hoch
waren.
· In einem stillen und isolierten Haus gibt es ein teueres Hi-Fi-Heimkino. '0' wird auf relativ
leise, '100' auf relativ laut gestellt; es gibt einen breiten dynamischen Bereich.
Eigenschaften f#r die Lautst,rke : 'volume' < 819 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
In all diesen F@llen k=nnte dasselbe Autor-Stylesheet verwendet werden, indem die Einstellun-
gen f r '0' und '100' auf der Client-Seite festgelegt werden.
19.3 Spracheigenschaften: 'speak'
'speak'
Wert: normal | none | spell-out | inherit
Ausgangswert: Normal
Angewendet auf: Alle Elemente
Vererbt: Ja
Prozents,tze: N/A
Medium: Aural
Diese Eigenschaft gibt an, ob und wie Text akustisch dargestellt wird (etwa vergleichbar mit
der Eigenschaft 'display'). Die m=glichen Werte sind:
none
Unterdr ckt die akustische Darstellung, so dass keine Zeit f r die Darstellung dieses Ele-
ments aufgewendet werden muss. Beachten Sie jedoch, dass Ableitungen diesen Wert
berschreiben k=nnen und m=glicherweise gesprochen werden. (Um sicher zu gehen, dass
die Darstellung eines Elements und seiner Ableitungen unterdr ckt wird, verwenden Sie
die Eigenschaft 'display'.)
normal
Verwendet sprachabh@ngige Ausspracheregeln f r die Darstellung eines Elements und sei-
ner untergeordneten Elemente.
Cascading Style Sheets, Level 2
spell-out
Buchstabiert den Text (praktisch f r Akronyme und Abk rzungen).
Beachten Sie den Unterschied zwischen einem Element, dessen 'volume'-Eigenschaft den Wert
'silent' hat, und einem Element, dessen 'speak'-Eigenschaft den Wert 'none' hat. Das erstere
ben=tigt dieselbe Zeit, als w@re es ausgesprochen worden, inklusive der Pause vor und nach
dem Element, aber es wird keine h=rbare Ausgabe erzeugt. Das letztere ben=tigt keine Zeit
und wird nicht dargestellt (w@hrend seine Ableitungen sehr wohl dargestellt werden k=nnen).
< 820 > Akustische Stylesheets
Page size: 168,00 x 240,00 mm
19.4 Pausen-Eigenschaften: 'pause-before', 'pause-after'
und 'pause'
'pause-before'
Wert: <time> | <percentage> | inherit
Ausgangswert: Vom Benutzerprogramm abh@ngig
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozents,tze: Siehe Text.
Medium Aural
'pause-after'
Wert: <time> | <percentage> | inherit
Ausgangswert: Vom Benutzerprogramm abh@ngig
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozents,tze: Siehe Text.
Medium: Aural
Diese Eigenschaften geben eine Pause an, die vor (oder nach) dem Sprechen eines Element-
inhalts eingehalten werden soll. Die Werte haben die folgenden Bedeutungen:
Cascading Style Sheets, Level 2
<time>
Gibt die Pause in absoluten Zeiteinheiten an (Sekunden und Millisekunden).
<percentage>
Bezieht sich auf das Inverse des Werts der 'speech-rate'-Eigenschaft. Betr@gt die Sprech-
geschwindigkeit beispielsweise 120 W=rter pro Minute (das heißt ein Wort dauert eine
halbe Sekunde oder 500 ms), bedeutet eine 'pause-before' von 100% eine Pause von 500
ms, und eine 'pause-before' von 20% bedeutet 100 ms.
Die Pause wird zwischen dem Elementinhalt und dem Inhalt von 'cue-before' oder 'cue-after',
falls vorhanden, eingef gt.
Autoren sollten relative Einheiten verwenden, um angesichts großer Abweichungen der
Sprechgeschwindigkeiten robustere Stylesheets zu erstellen.
Pausen-Eigenschaften < 821 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
'pause'
Wert: [[<zeit> | <percentage>]{1,2}] | inherit
Ausgangswert: Vom Benutzerprogramm abh@ngig.
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozentsatz: Siehe Beschreibungen zu 'pause-before' und 'pause-after'.
Medium Aural
Die 'pause'-Eigenschaft ist eine Abk rzung f r die Einstellung von 'pause-before' und 'pause-
after'. Werden zwei Werte angegeben, ist der erste Wert 'pause-before', der zweite Wert ist
'pause-after'. Ist nur ein Wert angegeben, gilt er f r beide Eigenschaften.
Beispiel
H1 { pause: 20ms } /* pause-before: 20ms; pause-after: 20ms */
H2 { pause: 30ms 40ms } /* pause-before: 30ms; pause-after: 40ms */
H3 { pause-after: 10ms } /* pause-before: ?; pause-after: 10ms */
19.5 Cue-Eigenschaften: 'cue-before', 'cue-after' und 'cue'
'cue-before'
Wert: <uri> | none | inherit
Ausgangswert: none
Angewendet auf: Alle Elemente
Cascading Style Sheets, Level 2
Vererbt: Nein
Prozents,tze: N/A
Medium Aural
'cue-after'
Wert: <uri> | none | inherit
Ausgangswert: none
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozents,tze: N/A
Medium Aural
< 822 > Akustische Stylesheets
Page size: 168,00 x 240,00 mm
Akustische Icons stellen eine weitere M=glichkeit dar, semantische Elemente voneinander zu
unterscheiden. Kl@nge k=nnen vor und/oder nach dem Element abgespielt werden, um sie von-
einander abzugrenzen. Die Werte haben die folgenden Bedeutungen:
<uri>
Der URI gibt die Ressource f r ein akustisches Icon an. L=st sich der URI zu etwas anderem
auf als zu einer Audio-Datei, beispielsweise zu einem Bild, sollte die Ressource ignoriert
werden, und die Eigenschaft wird behandelt, als h@tte sie den Wert 'none'.
none
Es wurde kein akustisches Icon angegeben.
Beispiel
A {cue-before: url("[Link]"); cue-after: url("[Link]") }
H1 {cue-before: url("[Link]"); cue-after: url("[Link]") }
'cue'
Wert: [<'cue-before'> | | <'cue-after'>] | inherit
Ausgangswert: F r abk rzende Eigenschaften nicht definiert.
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozentsatz: N/A
Medium Aural
Cascading Style Sheets, Level 2
Die 'cue'-Eigenschaft ist eine Abk rzung f r die Einstellung von 'cue-before' und 'cue-after'.
Werden zwei Werte angegeben, bezieht sich der erste auf 'cue-before', der zweite auf 'cue-
after'. Wird nur ein Wert angegeben, gilt er f r beide Eigenschaften.
Beispiel
Die beiden folgenden Regeln sind @quivalent:
H1 {cue-before: url("[Link]"); cue-after: url("[Link]") }
H1 {cue: url("[Link]") }
Kann ein Benutzerprogramm ein akustisches Icon nicht darstellen (wenn es beispielsweise die
Umgebung des Benutzers nicht erlaubt), empfehlen wir, einen alternativen Hinweis zu erzeugen
(z. B. die Anzeige einer Warnung, die Ausgabe eines Warntons usw.).
Cue-Eigenschaften: 'cue-before', 'cue-after' und 'cue' < 823 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
19.6 Misch-Eigenschaften: 'play-during'
'play-during'
Wert: <uri> mix? repeat? | auto | none | inherit
Ausgangswert: auto
Angewendet auf: Alle Elemente
Vererbt: Nein
Prozents,tze: N/A
Medium: Aural
Ohnlich den Eigenschaften 'cue-before' und 'cue-after' gibt diese Eigenschaft einen Sound an,
der als Hintergrund abgespielt werden soll, w@hrend der Inhalt eines Elements gesprochen
wird. Die Werte haben die folgenden Bedeutungen:
<uri>
Der durch diesen <uri> angegebene Sound wird als Hintergrund abgespielt, w@hrend der
Inhalt des Elements gesprochen wird.
mix
Falls dieses Schl sselwort angegeben ist, bedeutet es, dass der Sound, der von der 'play-
during'-Eigenschaft des bergeordneten Elements geerbt wurde, weiterhin abgespielt der in
<uri> angegebene Sound damit gemischt wird. Ist 'mix' nicht angegeben, ersetzt der Hinter-
grundton des Elements den des bergeordneten Elements.
repeat
Falls dieses Schl sselwort angegeben ist, bedeutet es, dass der Sound wiederholt wird, falls
er zu kurz ist, um die Gesamtdauer des Elements abzudecken. Andernfalls wird der Sound
Cascading Style Sheets, Level 2
einmal abgespielt und dann beendet. Das ist vergleichbar mit der 'background-repeat'-
Eigenschaft. Ist der Sound zu lang f r das Element, wird er abgebrochen, nachdem das Ele-
ment gesprochen wurde.
auto
Der Sound des bergeordneten Elements wird weiterhin abgespielt (er wird nicht neu
gestartet, was der Fall w@re, w@re diese Eigenschaft vererbt worden).
none
Dieses Schl sselwort bedeutet Stille. Der Sound des bergeordneten Elements (falls vor-
handen) ist still, w@hrend das aktuelle gesprochen wird, und wird nach dem aktuellen Ele-
ment fortgesetzt.
Beispiel
[Link] { play-during: url("[Link]") }
BLOCKQUOTE Q { play-during: url("[Link]") mix }
[Link] { play-during: none }
< 824 > Akustische Stylesheets
Page size: 168,00 x 240,00 mm
19.7 [Link] Eigenschaften: 'azimuth' und 'elevation'
R@umliches Audio ist eine wichtige stilistische Eigenschaft f r die akustische Darstellung. Es bie-
tet eine nat rliche M=glichkeit, mehrere Stimmen voneinander zu unterscheiden, so wie im
richtigen Leben (die Menschen stehen nur selten alle am selben Punkt in einem Raum). Stereo-
Lautsprecher erzeugen Soundquellen von verschiedenen Seiten. Bi-akustische Kopfh=rer oder
die immer beliebter werdenden Heimkinos mit 5 Lautsprechern k=nnen vollst@ndigen Sur-
round-Sound erzeugen, und Einstellungen mit mehreren Lautsprechern k=nnen ein wirklich
dreidimensionales Klangbild erzeugen. VRML 2.0 beinhaltet ebenfalls r@umliches Audio, was
bedeutet, dass es mit der Zeit auch immer mehr Hardware f r r@umliches Audio im Verbrau-
cherpreisbereich geben wird.
'azimuth'
Wert <angle> | [[left-side | far-left | left | center-left | center |
center-right | right | far-right | right-side] | | behind] | leftwards |
rightwards | inherit
Ausgangswert: center
Angewendet auf: Alle Elemente
Vererbt: Ja
Prozents@tze: N/A
Medium: Aural
Die Werte haben die folgenden Bedeutungen:
<angle>
Cascading Style Sheets, Level 2
Die Position wird als Winkel im Bereich zwischen '-360deg' und '360deg' angegeben. Der
Wert '0deg' steht f r eine Ausrichtung unmittelbar vorne im Mittelpunkt der Klangszene.
'90deg' ist rechts, '180deg' hinten, und '270deg' (oder @quivalent dazu und gebr@uchlicher
'-90deg') ist links.
left-side
Wie '270deg'. Mit 'behind', '270deg'.
far-left
Wie '300deg'. Mit 'behind', '240deg'.
left
Wie '320deg'. Mit 'behind', '220deg'.
center-left
Wie '340deg'. Mit 'behind', '200deg'.
center
Wie '0deg'. Mit 'behind', '180deg'.
center-right
Wie '20deg'. Mit 'behind', '160deg'.
right
Wie '40deg'. Mit 'behind', '140deg'.
R,umliche Eigenschaften: 'azimuth' und 'elevation' < 825 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
far-right
Wie '60deg'. Mit 'behind', '120deg'.
right-side
Wie '90deg'. Mit 'behind', '90deg'.
leftwards
Verschiebt den Sound nach links, relativ zum aktuellen Winkel. Genauer gesagt, werden
dabei 20 Grad subtrahiert. Die Arithmetik wird als modulo 360 Grad ausgef hrt. Beachten
Sie, dass 'leftwards' genauer als „gedreht im Gegen-Uhrzeigersinn“ beschrieben wird, weil
dabei immer 20 Grad subtrahiert werden, selbst wenn der geerbte Azimuth bereits hinter
dem Zuh=rer liegt (in diesem Fall scheint der Sound nach rechts zu gehen).
rightwards
Verschiebt den Sound nach rechts, relativ zum aktuellen Winkel. Genauer gesagt, werden
20 Grad addiert. Die Arithmetik ist unter 'leftwards' beschrieben.
Diese Eigenschaft wird am wahrscheinlichsten implementiert, indem dasselbe Signal in unter-
schiedliche Kan@le mit unterschiedlichen Lautst@rken gemischt wird. Dabei k=nnten auch eine
Phasenverschiebung, eine digitale Verz=gerung oder andere, @hnliche Techniken verwendet
werden, um die Illusion einer Klangb hne zu erzielen. Welche Mittel genau eingesetzt werden,
um diesen Effekt zu erzielen, sowie die Anzahl der verwendeten Lautsprecher, sind vom Benut-
zerprogramm abh@ngig; diese Eigenschaft identifiziert nur das gew nschte Endergebnis.
Beispiel
H1 { azimuth: 30deg }
TD.a { azimuth: far-right } /* 60deg */
#12 { azimuth: behind far-right } /* 120deg */
[Link] { azimuth: behind } /* 180deg */
Wird ein r@umlicher Azimuth angegeben und das Ausgabeger@t kann keine Sounds hinter der
Cascading Style Sheets, Level 2
Position des Zuh=rers erzeugen, sollten die Benutzerprogramme Werte der r ckw@rtigen
Halbkugel in Werte der vorderen Halbkugel umwandeln. Eine Methode sieht wie folgt aus:
·· if 90deg < x <= 180deg then x := 180deg – x
if 180deg < x <= 270deg then x := 540deg – x
'elevation'
Wert: <angle> | below | level | above | higher | lower | inherit
Ausgangswert: level
Angewendet auf: Alle Elemente
Vererbt: Ja
Prozentwerte: N/A
Medium: Aural
< 826 > Akustische Stylesheets
Page size: 168,00 x 240,00 mm
Die Werte f r diese Eigenschaft haben die folgenden Bedeutungen:
<angle>
Gibt die Steigung als Winkel zwischen '-90deg' und '90deg' an. '0deg' bedeutet, auf dem vor-
deren Horizont, was in etwa derselben Ebene mit dem Zuh=rer entspricht. '90deg' bedeu-
tet direkt ber und '-90deg' bedeutet direkt unter dem Zuh=rer.
below
Wie '-90deg'.
level
Wie '0deg'.
above
Wie '90deg'.
higher
Addiert 10 Grad zur aktuellen Steigung.
Welche Mittel f r die Erzielung dieses Effekts eingesetzt werden und die Anzahl der verwende-
ten Lautsprecher, ist nicht definiert. Diese Eigenschaft definiert nur das gew nschte Endergeb-
nis.
Beispiel
H1 { elevation: above }
TR.a { elevation: 60deg }
TR.b { elevation: 30deg }
TR.c { elevation: level }
19.8 Eigenschaften zur Sprachcharakteristik:
'speech-rate', 'voice-family', 'pitch', 'pitch-range',
Cascading Style Sheets, Level 2
'stress' und 'richness'
'speech-rate'
Wert: <number> | x-slow | slow | medium | fast | x-fast | faster |
slower | inherit
Anfangswert: medium
Angewendet auf: Alle Elemente
Vererbt: Ja
Prozentzahlen: N/A
Medium: Aural
Diese Eigenschaft gibt die Sprechgeschwindigkeit an. Beachten Sie, dass sowohl absolute als
auch relative Schl sselwortwerte erlaubt sind (siehe auch 'font-size', 15.2.4). Die Werte haben
die folgende Bedeutung:
Eigenschaften zur Sprachcharakteristik < 827 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
<number>
Gibt die Sprechgeschwindigkeit in W=rtern pro Minute an, eine Maßzahl, die abh@ngig von
der jeweiligen Sprache variiert, aber dennoch von Sprachsynthesizern allgemein unterst tzt
wird.
x-slow
Entspricht 80 W=rtern pro Minute.
slow
Entspricht 120 W=rtern pro Minute.
medium
Entspricht 180 – 200 W=rtern pro Minute.
fast
Entspricht 300 W=rtern pro Minute.
x-fast
Entspricht 500 W=rtern pro Minute.
faster
Addiert 40 W=rter pro Minute zur aktuellen Sprechgeschwindigkeit.
slower
Subtrahiert 40 W=rter pro Minute von der aktuellen Sprechgeschwindigkeit.
'voice-family'
Wert: [[<specific-voice> | <generic-voice>],]* [<specific-voice> |
<generic-voice> | inherit
Ausgangswert Vom Benutzerprogramm abh@ngig
Angewendet auf: Alle Elemente
Vererbt: Ja
Cascading Style Sheets, Level 2
Prozents,tze N/A
Medium Aural
Der Wert ist eine durch Kommas getrennte, nach Priorit@t geordnete Liste mit Sprachfamilien-
namen (zu vergleichen mit 'font-family'). Die Werte haben die folgenden Bedeutungen:
<generic-voice>
Die Werte stellen Stimmfamilien dar. M=gliche Werte sind 'male', 'female' und 'child'
(m@nnlich, weiblich, Kind).
<specific-voice>
Bei den Werten handelt es sich um spezifische Instanzen (z. B. Schauspieler, Trinoide,
Carlos, Lani).
Beispiel
H1 { voice-family: announcer, male }
[Link] { voice-family: romeo, male }
[Link] { voice-family: juliet, female }
< 828 > Akustische Stylesheets
Page size: 168,00 x 240,00 mm
Die Namen bestimmter Stimmen k=nnen in Anf hrungszeichen eingeschlossen werden. Sie
m ssen in Anf hrungszeichen eingeschlossen werden, wenn W=rter, aus denen sich der Name
zusammensetzt, nicht den Syntaxregeln f r Bezeichner entsprechen. Außerdem wird empfoh-
len, dass bestimmte Stimmen in Anf hrungszeichen eingeschlossen werden, deren Namen sich
aus mehreren W=rtern zusammensetzen. Werden die Anf hrungszeichen weggelassen, wer-
den alle Leerraumzeichen vor und hinter dem Stimmnamen ignoriert und Folgen beliebig vieler
Leerraumzeichen innerhalb des Stimmnamens zu einem einzigen Leerzeichen umgewandelt.
'pitch'
Wert: <frequency> | x-low | low | medium | high | x-high | inherit
Ausgangswert: medium
Angewendet auf: Alle Elemente
Vererbt Ja
Prozents@tze N/A
Medium: Aural
Gibt die durchschnittliche Stimmung (eine Frequenz) der Sprechstimme an. Die durchschnitt-
liche Stimmung einer Stimme ist von der Stimmfamilie abh@ngig. Die durchschnittliche Stim-
mung f r eine m@nnliche Standardstimme beispielsweise liegt bei etwa 120 Hz, f r eine weib-
liche Stimme etwa bei 210 Hz.
Die Werte haben die folgenden Bedeutungen:
<frequency>
Gibt die durchschnittliche Stimmung der Sprechstimme in Hertz (Hz) an.
x-low, low, medium, high, x-high
Cascading Style Sheets, Level 2
Diese Werte sind keinen absoluten Frequenzen zugeordnet, weil sie von der Stimmfamilie
abh@ngig sind. Benutzerprogramme sollten diese Werte geeigneten Frequenzen zuordnen,
abh@ngig von der Stimmfamilie und der Benutzerumgebung. Die Benutzerprogramme m s-
sen diese Werte jedoch in der richtigen Reihenfolge zuordnen (d. h. 'x-low' ist eine nied-
rigere Frequenz als 'low' usw.).
'pitch-range'
Wert: <number> | inherit
Ausgangswert: 50
Angewendet auf: Alle Elemente
Vererbt: Ja
Prozents@tze: N/A
Medium: Aural
Eigenschaften zur Sprachcharakteristik < 829 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Gibt die Abweichung von der durchschnittlichen Stimmung an. Die wahrgenommene Stimmung
einer menschlichen Stimme wird durch die Grundfrequenz festgelegt und weist normalerweise
einen Wert von 120 Hz f r eine m@nnliche Stimme und 210 Hz f r eine weibliche Stimme auf;
diese Abweichungen vermitteln zus@tzliche Bedeutung und Betonung. Eine hoch animierte
Stimme, das heißt, eine Stimme, die stark abgewandelt ist, weist einen hohen Stimmungsbereich
auf. Diese Eigenschaft bestimmt den Bereich, ber den diese Variationen auftreten, das heißt,
wie stark die Grundfrequenz von der durchschnittlichen Stimmung abweichen darf.
Die Werte haben die folgenden Bedeutungen:
<number>
Ein Wert zwischen '0' und '100'. Ein Stimmungsbereich von '0' erzeugt eine flache, mono-
tone Stimme. Ein Stimmungsbereich von '50' erzeugt eine normale Variation. Stimmungs-
bereiche gr=ßer 50 erzeugen animierte Stimmen.
'stress'
Wert: <number> | inherit
Ausgangswert: 50
Angewendet auf: Alle Elemente
Vererbt: Ja
Prozents,tze: N/A
Medium: Aural
Gibt die H=he „lokaler Spitzen“ in der Intonationskontur einer Stimme an. Beispielsweise ist
Englisch eine betonte Sprache, und unterschiedliche Abschnitte eines Satzes erhalten eine pri-
m@re, sekund@re oder terti@re Betonung. Der Wert von 'stress' steuert die Abweichung, die
Cascading Style Sheets, Level 2
aus diesen Betonungszeichen resultiert. Diese Eigenschaft begleitet die Eigenschaft 'pitch-range'
und wird bereitgestellt, um den Entwicklern die M=glichkeit zu er=ffnen, professionelle akus-
tische Ausgabeger@te zu nutzen.
Die Werte haben die folgenden Bedeutungen:
<number>
Ein Wert zwischen '0' und '100'. Die Bedeutung dieses Werts ist von der gesprochenen
Sprache abh@ngig. Ein Wert von '50' beispielsweise f r eine standardm@ßige englisch spre-
chende M@nnerstimme (durchschnittliche Stimmung = 122 Hz), die mit normaler Intonation
und Betonung spricht, h@tte eine andere Bedeutung als der Wert '50' f r eine italienische
Stimme.
< 830 > Eigenschaften zur Sprachcharakteristik
Page size: 168,00 x 240,00 mm
'richness'
Wert: <number> | inherit
Ausgangswert: 50
Angewendet auf: Alle Elemente
Vererbt: Ja
Prozents@tze N/A
Medium: Aural
Gibt den Umfang der Sprechstimme an. Eine umfassende Stimme „tr@gt“ in einem großen
Raum, eine glatte Stimme nicht. (Der Begriff „glatt“ bezieht sich auf die Darstellung der Wellen-
form.)
Die Werte haben die folgenden Bedeutungen:
<number>
Ein Wert zwischen '0' und '100'. Je h=her dieser Wert ist, desto mehr tr@gt die Stimme. Ein
geringerer Wert erzeugt eine sanfte, honigs ße Stimme.
19.9 Spracheigenschaften: 'speak-punctuation' und
'speak-numeral'
Eine zus@tzliche Spracheigenschaft, speak-header, ist im Kapitel 17 ber Tabellen beschrieben.
'speak-punctuation'
Wert: code | none | inherit
Cascading Style Sheets, Level 2
Ausgangswert: none
Angewendet auf: Alle Elemente
Vererbt: Ja
Prozents,tze: N/A
Medium: Aural
Diese Eigenschaft legt fest, wie die Interpunktion ausgesprochen wird. Die Werte haben die fol-
genden Bedeutungen:
code
Die Interpunktion wie beispielsweise Semikolons, Klammern usw. werden w=rtlich aus-
gesprochen.
none
Die Interpunktion wird nicht gesprochen, sondern durch unterschiedliche nat rliche Pau-
sen dargestellt.
Spracheigenschaften < 831 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
'speak-numeral'
Wert: digits | continuous | inherit
Ausgangswert: continuous
Angewendet auf: Alle Elemente
Vererbt: Ja
Prozents,tze: N/A
Medium: Aural
Diese Eigenschaft steuert, wie Zahlen ausgesprochen werden. Die Werte haben die folgenden
Bedeutungen:
digits
Die Zahlen werden als einzelne Ziffern ausgesprochen. „237“ wird also als „Zwei Drei Sie-
ben“ ausgesprochen.
continuous
Die Zahl wird als vollst@ndige Zahl ausgesprochen. „237“ wird also als „Zweihundertsieben-
unddreißig“ ausgesprochen. Die Wortdarstellungen sind sprachabh@ngig.
A Ein Beispiel-Stylesheet f-r HTML 4.0
Dieser Anhang ist informell, nicht normativ.
Dieses Stylesheet beschreibt die typische Formatierung aller HTML 4.0-Elemente ([HTML40]),
Cascading Style Sheets, Level 2
basierend auf umfassenden Forschungen ber aktuelle Vorgehensweisen in Benutzerprogram-
men. Den Entwicklern wird empfohlen, es als Standard-Stylesheet in ihren Implementierungen
zu verwenden.
Die vollst@ndige Darstellung einiger HTML-Elemente kann in CSS2 nicht ausgedr ckt werden,
unter anderem handelt es sich dabei um ersetzte Elemente (IMG, OBJECT), Skripting-Elemente
(SCRIPT, APPLET), Formularsteuerungeselemente und Frame-Elemente.
ADDRESS,
BLOCKQUOTE,
BODY, DD, DIV,
DL, DT,
FIELDSET, FORM,
FRAME, FRAMESET,
H1, H2, H3, H4,
H5, H6, IFRAME,
NOFRAMES,
OBJECT, OL, P,
UL, APPLET,
CENTER, DIR,
HR, MENU, PRE { display: block }
LI { display: list-item }
< 832 > Ein Beispiel-Stylesheet f#r HTML 4.0
Page size: 168,00 x 240,00 mm
HEAD { display: none }
TABLE { display: table }
TR { display: table-row }
THEAD { display: table-header-group }
TBODY { display: table-row-group }
TFOOT { display: table-footer-group }
COL { display: table-column }
COLGROUP { display: table-column-group }
TD, TH { display: table-cell }
CAPTION { display: table-caption }
TH { font-weight: bolder; text-align: center }
CAPTION { text-align: center }
BODY { padding: 8px; line-height: 1.33 }
H1 { font-size: 2em; margin: .67em 0 }
H2 { font-size: 1.5em; margin: .83em 0 }
H3 { font-size: 1.17em; margin: 1em 0 }
H4, P,
BLOCKQUOTE, UL,
FIELDSET, FORM,
OL, DL, DIR,
MENU { margin: 1.33em 0 }
H5 { font-size: .83em; line-height: 1.17em; margin: 1.67em 0 }
H6 { font-size: .67em; margin: 2.33em 0 }
H1, H2, H3, H4,
H5, H6, B,
STRONG { font-weight: bolder }
BLOCKQUOTE { margin-left: 40px; margin-right: 40px }
I, CITE, EM,
VAR, ADDRESS { font-style: italic }
PRE, TT, CODE,
KBD, SAMP { font-family: monospace }
PRE { white-space: pre }
BIG { font-size: 1.17em }
SMALL, SUB, SUP { font-size: .83em }
Cascading Style Sheets, Level 2
SUB { vertical-align: sub }
SUP { vertical-align: super }
S, STRIKE, DEL { text-decoration: line-through }
HR { border: 1px inset }
OL, UL, DIR,
MENU, DD { margin-left: 40px }
OL { list-style-type: decimal }
OL UL, UL OL,
UL UL, OL OL { margin-top: 0; margin-bottom: 0 }
U, INS { text-decoration: underline }
CENTER { text-align: center }
BR:before { content: "\A" }
/* Formatierungsbeispiel fUr die ABR/ACRONYM-Elemente von HTML */
ABBR, ACRONYM { font-variant: small-caps; letter-spacing: 0.1em }
A[href] { text-decoration: underline }
:focus { outline: thin dotted invert }
/* Anfang bidirektionale Einstellungen (nicht ]ndern) */
BDO[DIR="ltr"] { direction: ltr; unicode-bidi: bidi-override }
BDO[DIR="rtl"] { direction: rtl; unicode-bidi: bidi-override }
*[DIR="ltr"] { direction: ltr; unicode-bidi: embed }
*[DIR="rtl"] { direction: rtl; unicode-bidi: embed }
Ein Beispiel-Stylesheet f#r HTML 4.0 < 833 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
/* Elemente auf Blockebene in HTML4 */
ADDRESS, BLOCKQUOTE, BODY, DD, DIV, DL, DT, FIELDSET,
FORM, FRAME, FRAMESET, H1, H2, H3, H4, H5, H6, IFRAME,
NOSCRIPT, NOFRAMES, OBJECT, OL, P, UL, APPLET, CENTER,
DIR, HR, MENU, PRE, LI, TABLE, TR, THEAD, TBODY, TFOOT,
COL, COLGROUP, TD, TH, CAPTION
{ unicode-bidi: embed }
/* Ende bidirektionale Einstellungen */
@media print {
@page { margin: 10% }
H1, H2, H3,
H4, H5, H6 { page-break-after: avoid; page-break-inside: avoid }
BLOCKQUOTE,
PRE { page-break-inside: avoid }
UL, OL, DL { page-break-before: avoid }
}
@media aural {
H1, H2, H3,
H4, H5, H6 { voice-family: paul, male; stress: 20; richness: 90 }
H1 { pitch: x-low; pitch-range: 90 }
H2 { pitch: x-low; pitch-range: 80 }
H3 { pitch: low; pitch-range: 70 }
H4 { pitch: medium; pitch-range: 60 }
H5 { pitch: medium; pitch-range: 50 }
H6 { pitch: medium; pitch-range: 40 }
LI, DT, DD { pitch: medium; richness: 60 }
DT { stress: 80 }
PRE, CODE, TT { pitch: medium; pitch-range: 0; stress: 0; richness: 80 }
EM { pitch: medium; pitch-range: 60; stress: 60; richness: 50 }
STRONG { pitch: medium; pitch-range: 60; stress: 90; richness: 90 }
DFN { pitch: high; pitch-range: 60; stress: 60 }
S, STRIKE { richness: 0 }
I { pitch: medium; pitch-range: 60; stress: 60; richness: 50 }
Cascading Style Sheets, Level 2
B { pitch: medium; pitch-range: 60; stress: 90; richness: 90 }
U { richness: 0 }
A:link { voice-family: harry, male }
A:visited { voice-family: betty, female }
A:active { voice-family: betty, female; pitch-range: 80; pitch: x-high }
}
B Xnderungen gegen-ber CSS1
Dieser Anhang ist informell, nicht normativ.
CSS2 baut auf CSS1 auf, und alle g ltigen CSS1-Stylesheets sind auch g ltige CSS2-Stylesheets.
Die Onderungen zwischen der CSS1-Spezifikation (siehe [CSS1]) und dieser Spezifikation k=n-
nen in drei Kategorien eingeteilt werden: neue Funktionen, aktualisierte Beschreibungen von
CSS1-Funktionen und Onderungen an CSS1.
< 834 > Bnderungen gegen#ber CSS1
Page size: 168,00 x 240,00 mm
B.1 Neue Funktionen
Neben den Funktionen von CSS1 unterst tzt CSS2:
·· Das Konzept der Medientypen.
Den 'inherit'-Wert f r alle Eigenschaften.
·· Seitenmedien.
Akustische Stylesheets.
· Mehrere Funktionsmerkmale im Bereich der Internationalisierung, unter anderem Stile f r
die Listennummerierung, Unterst tzung bidirektionaler Texte und Unterst tzung sprach-
abh@ngiger Anf hrungszeichen.
· Einen erweiterten Mechanismus zur Schriftauswahl, unter anderem mit intelligentem Ver-
gleich, Synthese und herunterladbaren Schriften. Dar ber hinaus wurde das Konzept von
Systemschriften eingef hrt ebenso wie eine neue Eigenschaft namens 'font-size-adjust'.
·· Tabellen, unter anderem mit neuen Werten f r 'display' und 'vertical-align'.
Relative und absolute Positionierung, inklusive feststehender Positionierung.
·· Neue Box-Typen (neben Block und Inline): Compact und Run-in.
Die M=glichkeit, den berlauf, das Abschneiden und die Sichtbarkeit von Inhalt im visuellen
Formatierungsmodell zu kontrollieren.
· Die M=glichkeit, minimale und maximale Breiten und H=hen im visuellen Formatierungs-
modell anzugeben.
· Einen erweiterten Selektor-Mechanismus, unter anderem mit untergeordneten Selektoren,
benachbarten Selektoren und Attribut-Selektoren.
··Erzeugten Inhalt, Z@hler und automatische Nummerierung sowie Markierungen.
Textschatten – durch die neue Eigenschaft 'text-shadow'.
··
Mehrere neue Pseudo-Klassen: :first-child, :hover, :focus und :lang.
Systemfarben und -schriften.
··
Cursor.
Dynamische Umrisse.
Cascading Style Sheets, Level 2
B.2 Aktualisierte Beschreibungen
Die CSS1-Spezifikation war kurz und pr@zise. Diese Spezifikation ist sehr viel umfassender und
besser lesbar. Ein Großteil des erg@nzten Inhalts beschreibt neuen Funktionsumfang, aber auch
die CSS1-Funktionsmerkmale sind hier ausf hrlicher beschrieben. Außer in einigen nachfolgend
beschriebenen F@llen bedeuten die umformulierten Beschreibungen keine Onderungen in Syn-
tax oder Semantik.
B.3 Semantische Xnderungen gegen-ber CSS1
Alle CSS1-Stylesheets sind g ltige CSS2-Stylesheets, aber es gibt einige F@lle, wo das CSS1-
Stylesheet eine andere Bedeutung erh@lt, wenn es als CSS2-Stylesheet interpretiert wird. Die
meisten Onderungen wurden aufgrund von Erfahrungen bei der Implementierung vorgenom-
men, die jetzt in die Spezifikation zur ckfließen, aber es gibt auch ein paar Maßnahmen zur Feh-
lerkorrektur.
Neue Funktionen < 835 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
· Die Bedeutung von „!important“ hat sich ge@ndert. In CSS1 hatte „!important“ im Style-
sheet eines Autors Priorit@t gegen ber „!important“ im Stylesheet eines Benutzers. Das
wurde in CSS2 umgekehrt.
· In CSS2 werden Farbwerte relativ zur Ger@te-Skala abgeschnitten, nicht relativ zur sRGB-
Skala, wie in CSS1.
· CSS1 sagte einfach aus, dass 'margin-right' ignoriert wird, wenn sowohl 'margin-left' als auch
'width' vorgegeben waren. In CSS2 ist es von der Schreibrichtung abh@ngig, ob 'margin-right'
oder 'margin-left' ignoriert wird.
· In CSS1 hatten mehrere Eigenschaften (z. B. 'padding') Werte, die sich auf die Breite des
bergeordneten Elements bezogen. Das war ein Fehler; der Wert sollte sich immer auf die
Breite eines Elements auf Blockebene beziehen, und diese Spezifikation reflektiert dies
durch Einf hrung des Begriffs „umschließender Block“.
·· Der Ausgangswert von 'display' ist in CSS2 'inline', nicht 'block' wie in CSS1.
In CSS1 wird die Eigenschaft 'clear' auf alle Elemente angewendet. Das war ein Fehler. In
CSS2 wird die Eigenschaft nur auf Elemente auf Blockebene angewendet.
· In CSS1 schlossen sich ':link', ':visited' und ':active' wechselseitig aus; in CSS1 kann ':active'
gleichzeitig mit ':link' oder ':visited' gesetzt werden.
· Der vorgeschlagene Skalierungsfaktor zwischen benachbarten 'font-size'-Indizies in der
Tabelle der Schriftgr=ßen wurde von 1.5 auf 1.2 reduziert.
·· Der berechnete Wert von 'font-size' wird vererbt, nicht der tats@chliche Wert.
Die CSS1-Beschreibung von 'inside' (f r 'list-style-position') erlaubte die Interpretation,
dass der linke Rand des Texts gemeint war, und nicht die Position der Kugel-Markierung. In
CSS2 wurde diese Interpretationsm=glichkeit entfernt.
· Lesen Sie bitte auch den normativen Abschnitt ber die Unterschiede zwischen der CSS1-
und dem CSS2-Tokenbildung.
Cascading Style Sheets, Level 2
C Hinweise zur Implementierung und
Performance von Schriften
Dieser Anhang ist informell, nicht normativ.
C.1 Glossar f-r Schriftbegriffe
DocLockZ
Die DocLockj-Technologie von Bitstream stellt sicher, dass TrueDoc PFRs nur auf der
Site verwendet werden k=nnen, f r die sie ver=ffentlicht wurden. Eine TrueDoc PFR, die
auf eine andere Site verschoben oder auf die von einer anderen Site aus verwiesen wird,
funktioniert nicht.
Digitale Signatur
Teil der Trust Management-Technologie; wird genutzt, um signierte Zusicherungen in Hin-
blick auf eine Ressource zu treffen.
< 836 > Bnderungen gegen#ber CSS1
Page size: 168,00 x 240,00 mm
Schrift-Caching
Das Schrift-Caching erlaubt, dass auf dem Client-System eine tempor@re Kopie von Schrif-
ten bereitgestellt wird. H@ufig werden sie zusammen mit anderen Elementen aus dem
Cache auf der Festplatte gespeichert, wie beispielsweise Grafik, insbesondere f r den User
Agent.
Schriftart (Font Face)
Ein „Handle“, der auf eine bestimmte Variante einer Schrift verweist, ohne dabei die Schrift-
gr=ße zu ber cksichtigen.
Schriftvergleich
Ein Prozess, unter Verwendung einer oder mehrerer Attribute der prim@ren Schrift eine
@hnliche Schrift auszuw@hlen. Gebr@uchliche Attribute sind unter anderem serif, sans-serif,
weight, cap height, x-height, spacing, language und posture. Der Schriftvergleich ist von dem
verwendeten Algorithmus und der zur Auswahl stehenden Schriften abh@ngig.
Glyphen-Darstellung Untereinstellung
Der Prozess, durch den unerw nschte Glyphen-Darstellungen (zusammen mit ihren
Nebeneffekten und Kerning-Informationen) aus einer Prim@rschrift entfernt werden, um
eine kleinere Schrift-Untermenge zu erzeugen, die ein bestimmtes Dokument oder meh-
rere Dokumente abdeckt. Das ist insbesondere ein Vorteil f r Dokumente, die ideographi-
sche Schriften (scripts) verwenden, bei denen der Glyphen-Vorrat der Grundschrift sehr
groß sein kann. Die Untereinstellung der Glyphen-Darstellung f r Dokumente, die Schriften
(scripts) einsetzen, f r die Ligaturen erforderlich sind, wie beispielsweise Arabisch, ist
schwierig, wenn man die Ligatur-Regeln des endg ltigen Anzeigesystems nicht kennt.
Intellifont
Die Intellifont-Technologie wurde von Agfa entwickelt und ist das systemeigene Format f r
Hewlett-Packard und andere Drucker, die die Sprache PCL5 verwendet. Außerdem stellt
es das systemeigene Schriftformat auf den Amiga-Computern dar.
Infinifont
Eine Schriftsynthesetechnik, die aus einer Panose-1-Zahl (und optional zus@tzlichen Schrift-
Cascading Style Sheets, Level 2
beschreibungsdaten) eine Ersatzschrift erzeugen kann, ohne aus einem einzelnen Master-
Umriss extrapolieren oder zwischen zwei oder mehr Umrissen interpolieren zu m ssen
(siehe [INFINIFONT]).
Italic
Eine Klasse von Buchstabenformen f r lateinische Schriften, die kursiver sind als „roman“
Buchstabenformen, aber weniger kursiv als Schreibschriften. H@ufig wird ein Schriftpaar
entwickelt, das in Kombination verwendet wird; die eine ist eine serifen-behaftete Roman,
die andere ist Italic. Andere Begriffe zur Beschreibung dieser Klasse von Buchstabenformen
sind cursive oder (f r kyrillische Schriften) kursiv. F r serifenlose Schriften ist die beglei-
tende Schriftart h@ufig eine geneigte oder oblique Variante statt einer eigenen Klasse von
Buchstabenformen.
Glossar f#r Schriftbegriffe < 837 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Kerning
Eine Ver@nderung des Abstands zwischen ausgew@hlten Glyphen-Darstellungen, die andern-
falls zu eng beisammen oder zu weit auseinander stehen w rden, um ein gleichm@ßigeres
Schriftbild zu erzielen.
Cascading Style Sheets, Level 2
Multiple Master Font
Ein Multiple Master Font enth@lt zwei Prim@rschriften, die mit Hilfe einer speziellen Darstel-
lungssoftware eingesetzt werden, um ein interpoliertes Ergebnis zu erzielen. Adobe Sys-
tems stellt einen Mechanismus bereit, der erlaubt, dass die Ausgabeschrift oder die inter-
polierte Ausgabeschrift mit Hilfe von Parametern gesteuert wird. Diese Parameter
beschreiben im Allgemeinen die Charakteristik einer Originalschrift, und das Multiple Mas-
ter-Ergebnis wird als „synthetisierte Schrift“ bezeichnet.
< 838 > Bnderungen gegen#ber CSS1
Page size: 168,00 x 240,00 mm
Open Type
Open Type ist eine Erweiterung des TrueType-Schriftformats, die zus@tzliche Informa-
tionen enth@lt, um zus@tzliche M=glichkeiten f r Schriften zu bieten, die eine hochqualitative
internationale Typographie unterst tzen. Open Type kann einem einzelnen Zeichen meh-
rere Glyphen-Darstellungen oder einer einzelnen Glyphendarstellung eine Zeichenkom-
bination (Ligaturbildung) zuordnen. Open Type beinhaltet zweidimensionale Informationen
zur Unterst tzung von Funktionsmerkmalen f r die komplexe Positionierung und Glyphen-
Zuordnung. True Type Open und Open Type enthalten explizite Schrift- und Sprachinfor-
mationen, so dass eine Textverarbeitung ihr Verhalten entsprechend anpassen kann (siehe
[OPENTYPE]).
Server Font
Eine Schriftressource, die sich auf dem Webserver befindet, auf den in der WebFont-Defi-
nition verwiesen wird. Das Benutzerprogramm kann diese Ressource f r die Darstellung
der Seite verwenden.
Speedo
Diese Schrifttechnologie wurde von Bitstream entwickelt und ist das systemeigene Schrift-
format f r Atari ST- und Falcon-Computer. Des weiteren wird sie von Computern unter
dem X Window-System verwendet.
TrueDoc
Diese Technologie wurde von Bitstream entwickelt, um plattformunabh@ngige, skalierbare
Schriftobjekte im Web erstellen, transportieren und darstellen zu k=nnen. Schriftobjekte
werden mit Hilfe des True Doc Character Shape Recorders (CSR) erstellt, und die Darstel-
lung erfolgt mit dem True Doc Character Shape Player (CSP). Die Technologie ist f r die
Anzeige und das Drucken im Web vorgesehen.
TrueDoc Portable Font Resource
Eine PFR ist ein plattformunabh@ngiges Schriftobjekt, das durch einen CSP erzeugt wird.
Die Eingabe kann TrueType oder Type 1 beliebiger Varianten unter Windows, Mac oder
Unix sein. TrueDoc Portable Font Resource bietet gute Komprimierungsverh@ltnisse und
Cascading Style Sheets, Level 2
ist plattformunabh@ngig, ist aber nicht ganz einfach zu installieren, weil es sich dabei nicht
um ein systemeigenes Schriftformat (TrueType oder Type 1) handelt.
TrueType
TrueType ist ein von Apple entwickeltes und von Microsoft in Lizenz genommenes Schrift-
format. TrueType ist das systemeigene Schriftformat f r Windows und Macintosh. Es ent-
h@lt eine hierarchische Menge von Tabellen und Glyphen-Darstellungen. Buchstaben k=n-
nen auf Zeichen- und Punktgr=ße-Basis dargestellt werden, wodurch sich eine ausgezeich-
nete Qualit@t f r die verschiedenen Bildschirmaufl=sungen ergibt. TrueType-Schriften f r
Windows und Mac weisen wenige Unterschiede auf, sind aber unterschiedlich genug, um
eine plattform bergreifende Verwendung zu verhindern.
TrueType Collection
Eine TTC ist eine Erweiterung des TrueType-Formats, die Tabellen beinhaltet, die erlauben,
dass mehrere TrueType-Schriften innerhalb einer einzigen TrueType-Schriftdatei enthalten
sind. TTC-Dateien sind momentan noch relativ selten.
TrueType GX Fonts
TrueType GX Fonts enthalten Erweiterungen f r das TrueType-Standardformat, die ver-
@nderbare Schriften erlauben, @hnlich den Multiple Master Fonts. Es kann mehrere Muta-
tionsachsen geben, wie beispielsweise Gewichtung, H=he oder Neigung. Die Achse kann
Implementierung und Performance von Schriften < 839 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
f r fast jeden Effekt definiert werden. Dar ber hinaus unterst tzt TrueType GX den Aus-
tausch alternativer Glyphen-Darstellungen f r Ligaturen, Kontextformen, Br che usw.
Momentan steht TrueType GX nur auf dem Mac zur Verf gung (siehe [TRUETYPEGX]).
URI-Bindung
Der Prozess, eine bestimmten Schriftressource auf die Nutzung auf einer vorgegebenen
Website zu beschr@nken. Dabei wird ein verschl sselter URI oder eine digital signierte
Nutzungszusicherung in die Schriftressource eingebettet.
C.2 Schriften finden
Es gibt viele verschiedene Schriftformate, die von vielen verschiedenen Plattformen genutzt
werden. Um ein bevorzugtes Schriftformat auszuw@hlen, wird eine transparente Inhaltsabstim-
mung vorgenommen (siehe [NEGOT]). Es ist immer erkennbar, wann eine Schrift dereferen-
ziert wird, weil der URI in der Schriftbeschreibung enthalten ist. Eine Implementierung weiß,
welche herunterladbaren Schriftformate sie unterst tzt, und kann damit den Formathinweis
nutzen, um zu vermeiden, dass Schriften in einem nicht unterst tzten Format heruntergeladen
werden.
C.3 Bedeutung der Panose-Zahlen
Cascading Style Sheets, Level 2
Die Zahlen f r die Familie, Serifenstil und Proportion werden von Windows95 f r die Schrift-
auswahl und den Schriftvergleich verwendet.
Die Bedeutung der zehn Zahlen und die erlaubten Werte (in Klammern angegeben) finden Sie
nachfolgend. Dabei sind die gebr@uchlichsten F@lle ber cksichtigt, mit „family“-Zahl gleich 2,
Text und Digit. (Falls die erste Zahl einen anderen Wert hat, haben die anderen neun Zahlen
andere Bedeutungen.) Weitere Informationen ber Panose-1 finden Sie in [PANOSE].
< 840 > Bnderungen gegen#ber CSS1
Page size: 168,00 x 240,00 mm
Family
·· Any (0)
No Fit (1)
·· [PANOSE] Latin Text and Display (2)
[PANOSE] Latin Script (3)
·· [PANOSE] Latin Decorative (4)
[PANOSE] Latin Pictorial (5)
Serif Style
·· Any (0)
No Fit (1)
·· Cove (2)
Obtuse Cove (3)
·· Square Cove (4)
Obtuse Square Cove (5)
·· Square (6)
Thin (7)
·· Bone (8)
Exaggerated (9)
·· Triangle (10)
Normal Sans (11)
·· Obtuse Sans (12)
Perp Sans (13)
·· Flared (14)
Rounded (15)
Weight
Cascading Style Sheets, Level 2
·· Any (0)
No Fit (1)
·· Very Light (2)[100]
Light (3) [200]
·· Thin (4) [300]
Book (5) [400] (wie CSS1 'normal' )
·· Medium (6) [500]
Demi (7) [600]
·· Bold (8) [700] (wie CSS1 'bold' )
Heavy (9) [800]
·· Black (10) [900]
Extra Black/Nord (11) [900] (erzwinge Abbildung auf CSS1 100-900 Skala)
Bedeutung der Panose-Zahlen < 841 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Proportion
·· Any (0)
No Fit (1)
·· Old Style (2)
Modern (3)
·· Even Width (4)
Expanded (5)
·· Condensed (6)
Very Expanded (7)
·· Very Condensed (8)
Monospaced (9)
Contrast
·· Any (0)
No Fit (1)
·· None (2)
Very Low (3)
·· Low (4)
Medium Low (5)
·· Medium (6)
Medium High (7)
·· High (8)
Very High (9)
Stroke Variation
·· Any (0)
Cascading Style Sheets, Level 2
No Fit (1)
·· No Variation (2)
Gradual/Diagonal (3)
·· Gradual/Transitional (4)
Gradual/Vertical (5)
·· Gradual/Horizontal (6)
Rapid/Vertical (7)
·· Rapid/Horizontal (8)
Instant/Horizontal (9)
· Instant/Vertical (10)
Arm Style
·· Any (0)
No Fit (1)
·· Straight Arms/Horizontal (2)
Straight Arms/Wedge (3)
·· Straight Arms/Vertical (4)
Straight Arms/Single Serif (5)
< 842 > Bnderungen gegen#ber CSS1
Page size: 168,00 x 240,00 mm
·· Straight Arms/Double Serif (6)
Non-Straight Arms/Horizontal (7)
·· Non-Straight Arms/Wedge (8)
Non-Straight Arms/Vertical (90)
·· Non-Straight Arms/Single Serif (10)
Non-Straight Arms/Double Serif (11)
Letterform
·· Any (0)
No Fit (1)
·· Normal/Contact (2)
Normal/Weighted (3)
·· Normal/Boxed (4)
Normal/Flattened (5)
·· Normal/Rounded (6)
Normal/Off Center (7)
·· Normal/Square (8)
Oblique/Contact (9)
·· Oblique/Weighted (10)
Oblique/Boxed (11)
·· Oblique/Flattened (12)
Oblique/Rounded (13)
·· Oblique/Off Center (14)
Oblique/Square (15)
Midline
·· Any (0)
Cascading Style Sheets, Level 2
No Fit (1)
·· Standard/Trimmed (2)
Standard/Pointed (3)
·· Standard/Serifed (4)
High/Trimmed (5)
·· High/Pointed (6)
High/Serifed (7)
·· Constant/Trimmed (8)
Constant/Pointed (9)
·· Constant/Serifed (10)
Low/Trimmed (11)
·· Low/Pointed (12)
Low/Serifed (13)
XHeight
·· Any (0)
No Fit (1)
· Constant/Small (2)
Bedeutung der Panose-Zahlen < 843 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
·· Constant/Standard (3)
Constant/Large (4)
·· Ducking/Small (5)
Ducking/Standard (6)
· Ducking/Large (7)
Panose-2 (siehe [PANOSE2]) ist eine Spezifikation f r eine umfassendere Technologie der
Schriftklassifizierung und -vergleich, die nicht auf lateinische Schriftarten begrenzt ist. Beispiels-
weise k=nnen die Serifen-Eigenschaften einer lateinischen Schriftform mit den Strichabschl s-
sen einer Kanji-Schrift verglichen werden.
Der Panose-2-Wert wird nicht in bekannten Schriftformaten gespeichert, kann aber gemessen
werden.
Cascading Style Sheets, Level 2
C.4 Ableitung von Unicode-Bereichen f-r TrueType
Diese Information steht in der Schrift zur Verf gung, indem die 'ulUnicodeRange'-Bits in der
'OS/2'-Tabelle (falls vorhanden) nachgeschlagen werden, die eine Bitfeld-Darstellung der Menge
enth@lt. Diese Tabelle ist in berarbeitung 1.66 der TrueType-Spezifikation von Microsoft defi-
niert. Betrachtet man diese Information als Ganzes, entspricht jedes Element einem Unicode
1.1-Zeichenblock, und wenn ein Element in dieser Menge vorhanden ist, bedeutet das, dass die
Schrift ein oder mehr Glyphen-Darstellungen besitzt, um mindestens ein Zeichen in diesem
Block darzustellen. Die Menge besteht aus 128 Elementen, wie nachfolgend beschrieben. Die
Reihenfolge entspricht dem Unicode 1.1-Standard. Diese Tabelle kann dazu verwendet werden,
um die Information in einer TrueType-Schrift in einen 'unicode-range'-CSS-Deskriptor umzu-
wandeln.
< 844 > Bnderungen gegen#ber CSS1
Page size: 168,00 x 240,00 mm
Block Add Block name Unicode-Bereich
0 1 Basic Latin U+0-7F
1 2 Latin-1 Supplement U+80-FF
2 4 Latin-1 Extended-A U+100-17F
3 8 Latin Extended-B U+180-24F
4 1 IPA Extensions U+250-2AF
5 2 Spacing Modifier Letters U+2B0-2FF
6 4 Combining Diacritical Marks U+300-36F
7 8 Greek U+370-3CF
8 1 Greek Symbols and Coptic U+3D0-3EF
9 2 Cyrillic U+400-4FF
10 4 Armenian U+530-58F
11 8 Hebrew U+590-5FF
12 1 Hebrew Extended-A ?? welche Bereiche ??
Hebrew Extended-B
13 2 Arabic U+600-69F
14 4 Arabic Extended U+670-6FF
Cascading Style Sheets, Level 2
15 8 Devanagari U+900-97F
16 1 Bengali U+980-9FF
17 2 Gurmukhi U+A00-A7F
18 4 Gujarati U+A80-AFF
19 8 Oriya U+B00-B7F
20 1 Tamil U+B80-BFF
21 2 Telugu U+C00-C7F
22 4 Kannada U+C80-CFF
23 8 Malayalam U+D00-D7F
24 1 Thai U+E00-E7F
25 2 Lao U+E80-EFF
Ableitung von Unicode-Bereichen f#r TrueType < 845 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
26 4 Georgian U+10A0-10EF
27 8 Georgian Extended U+10F0-10FF ??
28 1 Hangul Jamo U+1100-11FF
29 2 Latin Extended Additional -
30 4 Greek Extended U+1F00-1FFF
31 8 General Punctuation U+2000-206F
32 1 Superscripts and Subscripts -
33 2 Currency Symbols U+20A0-20CF
34 4 Combining Marks for Symbols U+20D0-20FF
35 8 Letterlike Symbols U+2100-214F
36 1 Number Forms U+2150-218F
37 2 Arrows U+2190-21FF
38 4 Mathematical Operators U+2200-22FF
39 8 Miscellaneous Technical U+2300-23FF
40 1 Control Pictures U+2400-243F
41 2 Optical Character Recognition U+2440-245F
42 4 Enclosed Alphanumerics U+2460-24FF
43 8 Box Drawing U+2500-257F
Cascading Style Sheets, Level 2
44 1 Block Elements U+2580-259F
45 2 Geometric Shapes U+25A0-25FF
46 4 Miscellaneous Symbols U+2600-26FF
47 8 Dingbats U+2700-27BF
48 1 CJK Symbols and Punctuation U+3000-303F
49 2 Hiragana U+3040-309F
50 4 Katakana U+30A0-30FF
51 8 Bopomofo U+3100-312F
52 1 Hangul Compatibility Jamo U+3130-318F
53 2 CJK Miscellaneous ??
54 4 Enclosed CJK Letters and Months U+3200-32FF
< 846 > Bnderungen gegen#ber CSS1
Page size: 168,00 x 240,00 mm
55 8 CJK compatibility U+3300-33FF
56 1 Hangul U+AC00-D7FF
59 8 CJK Unified Ideographs U+4E00-9FFF
60 1 Private Use Area U+E000-F8FF
61 2 CJK Compatibility Ideographs U+F900-FAFF
62 4 Alphabetic Presentation Forms U+FB00-FB4F
63 8 Arabic Presentation Forms-A U+FB50-FDFF
64 1 Combining Half Marks U+FE20-FE2F
65 2 CJK compatibility Forms U+FE30-FE4F
66 4 Small Form Variants U+FE50-FE6F
67 8 Arabic Presentation Forms-B U+FE70-FEFF
68 1 Halfwidth and Fullwidth Forms U+FF00-FFEF
69 2 Specials U+FFF0-FFFD
Das TrueType-Bitfeld-System weist das Problem auf, dass es an Unicode 1.1 gebunden ist und
nicht mit der Unicode-Erweiterung zurechtkommt. Beispielsweise kann es kein Tibetanisch und
auch keine anderen Schriften darstellen, die mit Unicode 2.0 oder sp@teren berarbeitungen
eingef gt wurden.
Cascading Style Sheets, Level 2
C.5 Automatische Deskriptor-Erstellung
Autorenwerkzeuge sollten es den Autoren von Stylesheets erlauben, Schriftdeskriptoren zu
erg@nzen und zu bearbeiten. In einigen F@llen k=nnen Autorenwerkzeuge helfen, indem sie lokal
installierte Schriften auswerten und automatisch Deskriptoren f r die Schriften erzeugen, auf
die im Stylesheet verwiesen wird. Diese Funktion kann auch von Werkzeugen ausgef hrt wer-
den, die Schriften f r den dynamischen Download umwandeln oder Untermengen daraus
ermitteln.
Die folgende Tabelle zeigt, wo diese Informationen f r gebr@uchliche Schriftformate gefunden
werden k=nnen.
Automatische Deskriptor-Erstellung < 847 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Deskriptor Type 1 TrueType und TrueType GX
OpenType [TRUETYPEGX]
'ascent' 'Ascender' in AFM/ 'Ascender' in 'horizontalBefore' in
PFM-Datei 'hhea'-Tabelle oder 'fmtx' table
(vorzugsweise) 's-
TypoAscender' in
'OS/2'-Tabelle
'baseline' bsln-Tabelle, siehe
Hinweis
'bbox' FontBBox, Schrift- 'xMin', 'xMax', 'yMin'
verzeichnis und 'yMax' Eintr@ge in
die 'head'-Tabelle
'cap-height' CapHeight in AFM/
PFM-Datei
'descent' 'Descender' in der
AFM/PFM -Datei.
'mathline' bsln-Tabelle
'font-family' FamilyName, fon- name-Tabelle
tinfo-Verzeichnis
'stemh' StdHW, private-
Verzeichnis der
AFM/PFM-Datei
'stemv' /StdVW, private- cvt-Tabelle
Verzeichnis
'topline' bsln-Tabelle
Cascading Style Sheets, Level 2
'unicode-ran- cmap-Datei OS/2-Tabelle, siehe
ge' Anhang C
'units-per-em' FontMatrix, unitsPerEm, head-
Schriftverzeichnis Tabelle
'widths' hmtx-Tabelle
D Die Grammatik von CSS2
Dieser Anhang ist normativ.
Die nachfolgende Grammatik definiert die Syntax von CSS1. Es handelt sich dabei jedoch in
gewisser Hinsicht um eine Obermenge von CSS2, weil diese Spezifikation zus@tzliche semanti-
sche Beschr@nkungen einf hrt, die nicht in dieser Grammatik ausgedr ckt sind. Ein konformes
Benutzerprogramm muss außerdem die Regeln zum vorw@rtskompatiblen Parsing, die Eigen-
< 848 > Die Grammatik von CSS2
Page size: 168,00 x 240,00 mm
schaft/Wert-Notation und die Einheitennotation ber cksichtigen. Dar ber hinaus kann die
Dokumentsprache Beschr@nkungen einf hren, z. B. legt HTML Beschr@nkungen zu den m=gli-
chen Werten des „class“-Attributs fest.
D.1 Grammatik
Die nachfolgende Grammatik ist LL(1) (beachten Sie jedoch, dass die meisten Benutzerpro-
gramme sie nicht direkt verwenden sollten, weil sie die Parsing-Konventionen nicht ausdr ckt,
sondern nur die CSS2-Syntax). Das Format der Produktionen ist f r die menschliche Wahrneh-
mung optimiert, und es wird eine Art abk rzende Notation jenseits von Yacc (siehe [YACC])
verwendet:
·· *: 0 oder mehrmals
+: einmal oder mehrmals
·· ?: 0 oder 1
|: trennt Alternativen
· [ ]: Gruppierung
Die Produktionen sind:
stylesheet
: [ CHARSET_SYM S* STRING S* ';' ]?
[S|CDO|CDC]* [ import [S|CDO|CDC]* ]*
[ [ ruleset | media | page | font_face ] [S|CDO|CDC]* ]*
;
import
: IMPORT_SYM S*
[STRING|URI] S* [ medium [ ',' S* medium]* ]? ';' S*
;
media
: MEDIA_SYM S* medium [ ',' S* medium ]* '{' S* ruleset* '}' S*
;
Cascading Style Sheets, Level 2
medium
: IDENT S*
;
page
: PAGE_SYM S* IDENT? pseudo_page? S*
'{' S* declaration [ ';' S* declaration ]* '}' S*
;
pseudo_page
: ':' IDENT
;
font_face
: FONT_FACE_SYM S*
'{' S* declaration [ ';' S* declaration ]* '}' S*
;
operator
: '/' S* | ',' S* | /* leer */
;
combinator
: '+' S* | '>' S* | /* leer */
;
unary_operator
: '-' | '+'
Grammatik < 849 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
;
property
: IDENT S*
;
ruleset
: selector [ ',' S* selector ]*
'{' S* declaration [ ';' S* declaration ]* '}' S*
;
selector
: simple_selector [ combinator simple_selector ]*
;
simple_selector
: element_name? [ HASH | class | attrib | pseudo ]* S*
;
class
: '.' IDENT
;
element_name
: IDENT | '*'
;
attrib
: '[' S* IDENT S* [ [ '=' | INCLUDES | DASHMATCH ] S*
[ IDENT | STRING ] S* ]? ']'
;
pseudo
: ':' [ IDENT | FUNCTION S* IDENT S* ')' ]
;
declaration
: property ':' S* expr prio?
| /* leer */
;
prio
: IMPORTANT_SYM S*
;
Cascading Style Sheets, Level 2
expr
: term [ operator term ]*
;
term
: unary_operator?
[ NUMBER S* | PERCENTAGE S* | LENGTH S* | EMS S* | EXS S* | ANGLE S* |
TIME S* | FREQ S* | function ]
| STRING S* | IDENT S* | URI S* | RGB S* | UNICODERANGE S* | hexcolor
;
function
: FUNCTION S* expr ')' S*
;
/*
* Es gibt eine Beschr]nkung bezUglich der
* Farbe, n]mlich, dass sie 3 oder
* 6 Hex-Ziffern (i.e., [0-9a-fA-F]) hinter
* dem "#" haben muss; e.g., "#000" ist OK,
* "#abcd" nicht
*/
hexcolor
: HASH S*
;
< 850 > Die Grammatik von CSS2
Page size: 168,00 x 240,00 mm
D.2 Lexikalischer Scanner
Nachfolgend sehen Sie den Tokenizer, geschrieben in Flex-Notation (siehe [FLEX]). Der Toke-
nizer ber cksichtigt keine Groß-/Kleinschreibung.
Die beiden Vorkommen von „\377“ stellen die h=chste Zeichennummer dar, mit der aktuelle
Versionen von Flex zurechtkommen (dezimal 255). Sie sollten als „\4177777“ (dezimal
1114111) gelesen werden, der h=chstm=gliche Codepunkt in Unicode/ISO-10646.
%option case-insensitive
h [0-9a-f]
nonascii [\200-\377]
unicode \\{h}{1,6}[ \t\r\n\f]?
escape {unicode}|\\[ -~\200-\377]
nmstart [a-z]|{nonascii}|{escape}
nmchar [a-z0-9-]|{nonascii}|{escape}
string1 \"([\t !#$%&(-~]|\\{nl}|\'|{nonascii}|{escape})*\"
string2 \'([\t !#$%&(-~]|\\{nl}|\"|{nonascii}|{escape})*\'
ident {nmstart}{nmchar}*
name {nmchar}+
num [0-9]+|[0-9]*"."[0-9]+
string {string1}|{string2}
url ([!#$%&*-~]|{nonascii}|{escape})*
w [ \t\r\n\f]*
nl \n|\r\n|\r|\f
range \?{1,6}|{h}(\?{0,5}|{h}(\?{0,4}|{h}(\?{0,3}|{h}(\?{0,2}|{h}(\??|{h})))))
%%
[ \t\r\n\f]+ {return S;}
\/\*[^*]*\*+([^/][^*]*\*+)*\/ /* Kommentare ignorieren */
"<!- -" {return CDO;}
"- ->" {return CDC;}
"~=" {return INCLUDES;}
"|=" {return DASHMATCH;}
{string} {return STRING;}
Cascading Style Sheets, Level 2
{ident} {return IDENT;}
"#"{name} {return HASH;}
"@import" {return IMPORT_SYM;}
"@page" {return PAGE_SYM;}
"@media" {return MEDIA_SYM;}
"@font-face" {return FONT_FACE_SYM;}
"@charset" {return CHARSET_SYM;}
"@"{ident} {return ATKEYWORD;}
"!{w}important" {return IMPORTANT_SYM;}
{num}em {return EMS;}
{num}ex {return EXS;}
{num}px {return LENGTH;}
{num}cm {return LENGTH;}
{num}mm {return LENGTH;}
{num}in {return LENGTH;}
{num}pt {return LENGTH;}
{num}pc {return LENGTH;}
{num}deg {return ANGLE;}
{num}rad {return ANGLE;}
{num}grad {return ANGLE;}
{num}ms {return TIME;}
{num}s {return TIME;}
Lexikalischer Scanner < 851 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
{num}Hz {return FREQ;}
{num}kHz {return FREQ;}
{num}{ident} {return DIMEN;}
{num}% {return PERCENTAGE;}
{num} {return NUMBER;}
"url("{w}{string}{w}")" {return URI;}
"url("{w}{url}{w}")" {return URI;}
{ident}"(" {return FUNCTION;}
U\+{range} {return UNICODERANGE;}
U\+{h}{1,6}-{h}{1,6} {return UNICODERANGE;}
. {return *yytext;}
D.3 Vergleich der Tokenbildung zwischen CSS1 und CSS2
Es gibt einige Unterschiede zwischen der Syntax, wie sie in der CSS1-Empfehlung ([CSS1])
angegeben ist, und der oben gezeigten. Diese Unterschiede sind gr=ßtenteils durch neue Token
in CSS2 bedingt, die es in CSS1 nicht gab. Andere Unterschiede sind entstanden, weil die Gram-
matik der besseren Lesbarkeit halber umformuliert wurde. Es gibt jedoch einige inkompatible
Onderungen, die in der CSS1-Syntax als Fehler erkannt wurden. Sie sind nachfolgend beschrie-
ben.
· CSS1-Stylesheets konnten nur in 1-Byte/Zeichen-Codierungen formuliert werden wie bei-
spielsweise ASCII und ISO-8859-1. CSS2 weist keine solche Beschr@nkung auf. In der Praxis
war es nicht schwierig, den CSS1-Tokenizer zu extrapolieren, und einige User Agents
haben auch 2-Byte-Codierungen akzeptiert.
· CSS1 erlaubte nur vier hexadezimale Ziffern hinter dem Backslash (\), um auf Unicode-Zei-
chen zu verweisen, CSS2 erlaubt sechs. Dar ber hinaus erlaubt CSS2, dass die Escape-Folge
durch ein Leerraumzeichen begrenzt wird. Gem@ß CSS1 z. B. umfasst der String „\abcdef“ 3
Cascading Style Sheets, Level 2
Buchstaben, (\abcd, e und f), gem@ß CSS2 nur einen (\abcdef).
· Das Tabulator-Zeichen (ASCII 9) war in Zeichenketten nicht erlaubt. Weil Zeichenketten
in CSS1 jedoch nur f r Schriftnamen und URLs verwendet wurden, war die einzige M=glich-
keit, wie dies zu Inkompatibilit@t zwischen CSS1 und CSS2 f hren konnte, dass ein Style-
sheet eine Schriftfamilie enthielt, in deren Namen ein Tabulatorzeichen enthalten war.
· Auf @hnliche Weise waren in CSS1 auch keine Neuezeile-Zeichen (Escape mit Backslash) in
Zeichenketten erlaubt.
· CSS2 parst eine Zahl unmittelbar gefolgt von einem Bezeichner als DIMEN-Token (d. h.
eine unbekannte Einheit), CSS1 parst sie als Zahl und Bezeichner. Das bedeutet, in CSS1
war die Deklaration 'font: 10pt/1.2serif' korrekt, ebenso wie 'font: 10pt/12pt serif'; in CSS2
muss vor „serif“ ein Leerzeichen angegeben werden. (Einige Benutzerprogramme haben
das erste Beispiel akzeptiert, nicht aber das zweite.)
· In CSS1 konnte ein Klassenname mit einer Ziffer beginnen („.55ft“), es sei denn, es handelte
sich dabei um eine Gr=ße („.55in“). In CSS2 werden solche Klassen als unbekannte Gr=ßen
geparst (um zuk nftige Erg@nzungen um neue Einheiten zu unterst tzen). Damit „.55ft“ eine
g ltige Klasse ist, muss in CSS2 die erste Ziffer als Escape gekennzeichnet werden („.\55ft“).
< 852 > Die Grammatik von CSS2
Page size: 168,00 x 240,00 mm
E Literaturhinweise
E.1 Normative Literaturhinweise
[COLORIMETRY]
„Colorimetry, Second Edition“, CIE Publication 15.2-1986, ISBN 3-900-734-00-3.
Verf gbar unter [Link]
[CSS1]
„Cascading Style Sheets, level 1“, H. W. Lie und B. Bos, 17. Dezember 1996.
Verf gbar unter [Link]
[FLEX]
„Flex: The Lexical Scanner Generator“, Version 2.3.7, ISBN 1882114213.
[HTML40]
„HTML 4.0 Specification“, D. Raggett, A. Le Hors, I. Jacobs, 8. Juli 1997.
Verf gbar unter [Link] Die Empfehlung definiert drei
Dokumenttypdefinitionen: Strict, Transitional und Frameset, die alle von der Spezifikation
aus erreichbar sind.
[IANA]
„Assigned Numbers“, STD 2, RFC 1700, USC/ISI, J. Reynolds und J. Postel, Oktober 1994.
Verf gbar unter [Link]
[ICC32]
„ICC Profile Format Specification, version 3.2“, 1995.
Verf gbar unter [Link]
[ISO8879]
ISO 8879:1986 „Information Processing – Text and Office Systems – Standard Generalized
Markup Language (SGML)“, ISO 8879:1986.
Eine Liste der SGML-Entities finden Sie unter [Link]
[ISO10646]
Cascading Style Sheets, Level 2
„Information Technology - Universal Multiple- Octet Coded Character Set (UCS) - Part 1:
Architecture and Basic Multilingual Plane“, ISO/IEC 10646-1:1993. Die aktuelle Spezifikation
ber cksichtigt auch die ersten f nf Nachtr@ge zu ISO/IEC 10646-1:1993. Praktische ber-
blicke ber die BMP- und Plane 1-Dokumente zeigen, welche Skripts sich innerhalb welcher
numerischer Bereiche befinden.
[PNG10]
„PNG (Portable Network Graphics) Specification, Version 1.0 specification“, T. Boutell
Hrsg., 1 Oktober 1996.
Verf gbar unter [Link]
[RFC1808]
„Relative Uniform Resource Locators“, R. Fielding, Juni 1995.
Verf gbar unter [Link]
[RFC2045]
„Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message
Bodies“, N. Freed und N. Borenstein, November 1996.
Verf gbar unter [Link] Beachten Sie, dass die RFCs
RFC1521, RFC1522, und RFC1590 nach diesem RFC veraltet sind.
Literaturhinweise < 853 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
[RFC2068]
„HTTP Version 1.1 „, R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen und T. Berners-Lee,
Januar 1997.
Verf gbar unter [Link]
[RFC2070]
„Internationalization of the HyperText Markup Language“, F. Yergeau, G. Nicol, G. Adams
und M. D rst, January 1997.
Verf gbar unter [Link]
[RFC2119]
„Key words for use in RFCs to Indicate Requirement Levels“, S. Bradner, M@rz 1997.
Verf gbar unter [Link]
[RFC2318]
„The text/css Media Type“, H. Lie, B. Bos, C. Lilley, M@rz 1998.
Verf gbar unter [Link]
[RFC1738]
„Uniform Resource Locators“, T. Berners-Lee, L. Masinter und M. McCahill, Dezember
1994.
Verf gbar unter [Link]
[SRGB]
„Proposal for a Standard Color Space for the Internet - sRGB“, M. Anderson, R. Motta,
S. Chandrasekar, M. Stokes.
Verf gbar unter [Link]
[UNICODE]
„The Unicode Standard: Version 2.0“, The Unicode Consortium, Addison-Wesley Devel-
opers Press, 1996. Zur Bidirektionalit@t lesen Sie auch die Korrekturen unter
[Link] Weitere Informationen finden Sie auf
der Homepage des Unicode Consortiums unter [Link] Die neueste Ver-
sion von Unicode. Weitere Informationen finden Sei auf der Homepage des Unicode Con-
Cascading Style Sheets, Level 2
sortiums unter [Link]
[URI]
„Uniform Resource Identifiers (URI): Generic Syntax and Semantics“, T. Berners-Lee, R.
Fielding, L. Masinter, 18. November 1997.
Verf gbar unter [Link]
Dies ist eine fortlaufende Arbeit, die voraussichtlich [RFC1738] und [RFC1808] aktualisieren
wird.
[XML10]
„Extensible Markup Language (XML) 1.0“ T. Bray, J. Paoli, C.M. Sperberg-McQueen, Hrsg.,
10. Februar 1998.
Verf gbar unter [Link]
[YACC]
„YACC - Yet another compiler compiler“, S. C. Johnson, Technical Report, Murray Hill,
1975.
< 854 > Literaturhinweise
Page size: 168,00 x 240,00 mm
E.2 Informelle Literaturhinweise
[CHARSETS]
Registrierte Zeichensatzwerte. Laden Sie sich eine Liste registrierter Zeichensatzwerte
herunter unter [Link]
[DOM]
„Document Object Model Specification“, L. Wood, A. Le Hors, 9. Oktober 1997.
Verf gbar unter [Link]
[ISO10179]
ISO/IEC 10179:1996 „Information technology – Processing languages – Document Style
Semantics and Specification Language (DSSSL)“
Verf gbar unter [Link]
[GAMMA]
„Gamma correction on the Macintosh Platform“, C. A. Poynton.
Verf gbar unter [Link]
[HTML32]
„HTML 3.2 Reference Specification“, Dave Raggett, 14. Januar 1997.
Verf gbar unter [Link]
[INFINIFONT]
Siehe [Link]
[ISO9899]
ISO/IEC 9899:1990 Programmiersprachen – C.
[MONOTYPE]
Siehe [Link]
[NEGOT]
„Transparent Content Negotiation in HTTP“, K. Holtman, A. Mutz, 9. M@rz 1997.
Verf gbar unter [Link]
[Link]
Cascading Style Sheets, Level 2
[OPENTYPE]
Siehe [Link]
[PANOSE]
Weitere Informationen ber die PANOSE-Klassifizierungsmetrik finden Sie unter
[Link] und in den folgenden Kapiteln: Latin Text, Latin
Script, Latin Decorative und Latin Pictorial. Panose-Nummern f r einige Schriften stehen
online zur Verf gung und k=nnen abgefragt werden.
[PANOSE2]
Siehe [Link] Panose-2 ist nicht auf lateinische Schriften
beschr@nkt.
[POSTSCRIPT]
„The PostScript Language Reference Manual“, Second Edition, Adobe Systems, Inc., Addi-
son-Wesley Publishing Co., Dezember 1990.
[RFC1630]
„Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names
and Addresses of Objects on the Network as used in the World-Wide Web“, T. Berners-
Lee, Juni 1994.
Verf gbar unter [Link]
Informelle Literaturhinweise < 855 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
[RFC1766]
„Tags for the Identification of Languages“, H. Alvestrand, M@rz 1995.
Verf gbar unter [Link]
[RFC1866]
„HyperText Markup Language 2.0“, T. Berners-Lee und D. Connolly, November 1995.
Verf gbar unter [Link]
[RFC1942]
„HTML Tables“, Dave Raggett, Mai 1996.
Verf gbar unter [Link]
[TRUETYPEGX]
Detaillierte Informationen ber TrueType GX von Apple Computer finden Sie unter
[Link] inklusive Beschreibungen der hinzugef gten
Tabellen und Schriftqualit@tspezifikationen.
[W3CSTYLE]
W3C-Ressource ber Web-Stylesheets. [Link]
[WAI-PAGEAUTH]
„WAI Accesibility Guidelines: Page Authoring“ f r den Entwurf zugreifbarer Dokumente
stehen zur Verf gung unter [Link]
Cascading Style Sheets, Level 2
< 856 > Literaturhinweise
F Eigenschaftsindex
Page size: 168,00 x 240,00 mm
Name Werte Ausgangs- Angewendet auf Vererbt: Prozentwerte Mediengruppen
wert (Standardwert: (Standardwert:
all): N/A)
'azimuth' <angle> | [[ left-side | far-left center Ja aural
| left | center-left | center |
center-right | right | far-right
| right-side ] || behind ] | left-
wards | rightwards | inherit
'background' ['background-color' || 'back- XX Nein Erlaubt f r 'back- visual
ground-image' || 'background- ground-position'
repeat' || 'background-attach-
ment' || 'background-positi-
on'] | inherit
'background- scroll | fixed | inherit scroll Nein visual
Eigenschaftsindex
attachment'
'background- <color> | transparent | inhe- transparent Nein visual
color' rit
'background- <uri> | none | inherit none Nein visual
image'
'background- [ [<percentage> | <length> 0% 0% Elemente auf no Beziehen sich auf visual
position' ]{1,2} | [ [top | center | bot- Blockebene und die Gr=ße der
tom] || [left | center | right] ] ersetzte Elemente eigentlichen Box
] | inherit
< 857 >
'background- repeat | repeat-x | repeat-y | repeat Nein visual
repeat' no-repeat | inherit
Cascading Style Sheets, Level 2
Cascading Style Sheets, Level 2
< 858 >
'border' [ 'border-width' || 'border- Siehe ein- Nein visual
<edition
[Link]>
Page size: 168,00 x 240,00 mm
style' || <color> ] | inherit zelne Eigen-
schaften
'border-collap- collapse | separate | inherit collapse 'table'- und 'inline- Ja visual
se' table'-Elemente
'border-color' <color>{1,4} | transparent | Siehe ein- Nein visual
Eigenschaftsindex
inherit zelne Eigen-
schaften
'border-spa- <length> <length>? | inherit 0 'table'- und 'inline- Ja visual
cing' table'-Elemente
'border-style' <border-style>{1,4} | inherit Siehe ein- Nein visual
zelne Eigen-
schaften
'border-top' [ 'border-top-width' || 'bor- Siehe ein- Nein visual
'border-right' der-style' || <color> ] | inhe- zelne Eigen-
'border-bot- rit schaften
tom' 'border-
left'
'border-top- <color> | inherit Der Wert Nein visual
color' 'border- der 'co-
right-color' lor'-Eigen-
'border-bot- schaft
tom-color'
'border-left-
color'
'border-top- <border-style> | inherit none Nein visual
Page size: 168,00 x 240,00 mm
style' 'border-
right-style'
'border-bot-
tom-style'
'border-left-
style'
'border-top- <border-width> | inherit medium Nein visual
width' 'bor-
der-right-
width' 'bor-
der-bottom-
width' 'bor-
der-left-width'
'border-width' <border-width>{1,4} | inherit Siehe ein- Nein visual
zelne Eigen-
schaften
Eigenschaftsindex
'bottom' <length> | <percentage> | auto Positionierte Ele- Nein Beziehen sich auf visual
auto | inherit mente die H=he des ent-
haltenden Blocks
'caption-side' top | bottom | left | right | top 'table-caption'-Ele- Ja visual
inherit mente
'clear' none | left | right | both | none Elemente auf Nein visual
inherit Blockebene
'clip' <shape> | auto | inherit auto Elemente auf Nein visual
Blockebene und
< 859 >
ersetzte Elemente
Cascading Style Sheets, Level 2
Cascading Style Sheets, Level 2
< 860 >
'color' <color> | inherit Vom Ja visual
<edition
[Link]>
Page size: 168,00 x 240,00 mm
Benutzer-
programm
abh@ngig
'content' [ <string> | <uri> | Leerer :before- und :after- Nein all
<counter> | attr(X) | open- String Pseudo-Elemente
Eigenschaftsindex
quote | close-quote | no-
open-quote | no-close-quote
]+ | inherit
'counter-in- [ <identifier> <integer>? ]+ | none Nein all
crement' none | inherit
'counter-reset' [ <identifier> <integer>? ]+ | none Nein all
none | inherit
'cue' [ 'cue-before' || 'cue-after' ] | XX Nein aural
inherit
'cue-after' <uri> | none | inherit none Nein aural
'cue-before' <uri> | none | inherit none Nein aural
'cursor' [ [<uri> ,]* [ auto | crosshair auto Ja visual, interactive
| default | pointer | move |
e-resize | ne-resize | nw-re-
size | n-resize | se-resize | sw-
resize | s-resize | w-resize|
text | wait | help ] ] | inherit
'direction' ltr | rtl | inherit ltr Alle Elemente; Ja visual
siehe Text
'display' inline | block | list-item | inline Nein all
Page size: 168,00 x 240,00 mm
run-in | compact | marker |
table | inline-table | table-
row-group | table-header-
group | table-footer-group |
table-row | table-column-
group | table-column | table-
cell | table-caption | none |
inherit
'elevation' <angle> | below | level | level Ja aural
above | higher | lower | inhe-
rit
'empty-cells' show | hide | inherit show 'table-cell'-Ele- Ja visual
mente
'float' left | right | none | inherit none Alle, außer positio- Nein visual
nierte Elemente
und erzeugter
Eigenschaftsindex
Inhalt
'font' [ [ 'font-style' || 'font-variant' Siehe ein- Ja Erlaubt f r 'font-si- visual
|| 'font-weight' ]? 'font-size' [ / zelne Eigen- ze' und 'line-height'
'line-height' ]? 'font-family' ] | schaften
caption | icon | menu | mes-
sage-box | small-caption | sta-
tus-bar | inherit
'font-family' [[ <family-name> | Vom Ja visual
<generic-family> ],]* Benutzer-
< 861 >
[<family-name> | programm
<generic-family>] | inherit abh@ngig
Cascading Style Sheets, Level 2
Cascading Style Sheets, Level 2
< 862 >
'font-size' <absolute-size> | medium Ja, der Beziehen sich auf visual
<edition
[Link]>
Page size: 168,00 x 240,00 mm
<relative-size> | <length> | berech- die Schriftgr=ße
<percentage> | inherit nete des bergeord-
Wert neten Elements
wird ver-
erbt
Eigenschaftsindex
'font-size-ad- <number> | none | inherit none Ja visual
just'
'font-stretch' normal | wider | narrower | normal Ja visual
ultra-condensed | extra-con-
densed | condensed | semi-
condensed | semi-expanded |
expanded | extra-expanded |
ultra-expanded | inherit
'font-style' normal | italic | oblique | inhe- normal Ja visual
rit
'font-variant' normal | small-caps | inherit normal Ja visual
'font-weight' normal | bold | bolder | normal Ja visual
lighter | 100 | 200 | 300 | 400
| 500 | 600 | 700 | 800 | 900 |
inherit
'height' <length> | <percentage> | auto Alle Elemente, Nein Siehe Text visual
auto | inherit außer nicht
ersetzte Inline-Ele-
mente, Tabellen-
spalten und Spal-
tengruppen
'left' <length> | <percentage> | auto Positionierte Ele- Nein Beziehen sich auf visual
Page size: 168,00 x 240,00 mm
auto | inherit mente die Breite des ent-
haltenden Blocks
'letter-spacing' normal | <length> | inherit normal Ja visual
'line-height' normal | <number> | normal Ja Beziehen sich auf visual
<length> | <percentage> | die Schriftgr=ße
inherit des eigentlichen
Elements
'list-style' [ 'list-style-type' || 'list-style- XX Elemente mit 'dis- Ja visual
position' || 'list-style-image' ] | play: list-item'
inherit
'list-style- <uri> | none | inherit none Elemente mit 'dis- Ja visual
image' play: list-item'
'list-style-posi- inside | outside | inherit outside Elemente mit 'dis- Ja visual
tion' play: list-item'
'list-style-type' disc | circle | square | decimal disc Elemente mit 'dis- Ja visual
Eigenschaftsindex
| decimal-leading-zero | play: list-item'
lower-roman | upper-roman |
lower-greek | lower-alpha |
lower-latin | upper-alpha |
upper-latin | hebrew | arme-
nian | georgian | cjk-ideogra-
phic | hiragana | katakana |
hiragana-iroha | katakana-
iroha | none | inherit
< 863 >
'margin' <margin-width>{1,4} | inherit XX Nein Beziehen sich auf visual
die Breite des ent-
haltenden Blocks
Cascading Style Sheets, Level 2
Cascading Style Sheets, Level 2
< 864 >
'margin-top' <margin-width> | inherit 0 Nein Beziehen sich auf visual
<edition
[Link]>
Page size: 168,00 x 240,00 mm
'margin-right' die Breite des ent-
'margin-bot- haltenden Blocks
tom' 'margin-
left'
'marker-offset' <length> | auto | inherit auto Elemente mit 'dis- Nein visual
Eigenschaftsindex
play: marker'
'marks' [ crop || cross ] | none | inhe- none Seitenkontext N/A visual, paged
rit
'max-height' <length> | <percentage> | none Alle Elemente, Nein Beziehen sich auf visual
none | inherit außer nicht die H=he des ent-
ersetzte Inline-Ele- haltenden Blocks
mente und Tabel-
lenelemente
'max-width' <length> | <percentage> | none Alle Elemente, no Beziehen sich auf visual
none | inherit außer nicht die Breite des ent-
ersetzte Inline-Ele- haltenden Blocks
mente und Tabel-
lenelemente
'min-height' <length> | <percentage> | 0 Alle Elemente, no Beziehen sich auf visual
inherit außer nicht die H=he des ent-
ersetzte Inline-Ele- haltenden Blocks
mente und Tabel-
lenelemente
'min-width' <length> | <percentage> | UA depen- Alle Elemente, no Beziehen sich auf visual
inherit dent außer nicht die Breite des ent-
ersetzte Inline-Ele- haltenden Blocks
mente und Tabel-
lenelemente
'orphans' <integer> | inherit 2 Elemente auf Ja visual, paged
Page size: 168,00 x 240,00 mm
Blockebene
'outline' [ 'outline-color' || 'outline- Siehe ein- Nein visual, interactive
style' || 'outline-width' ] | zelne Eigen-
inherit schaften
'outline-color' <color> | invert | inherit invert Nein visual, interactive
'outline-style' <border-style> | inherit none Nein visual, interactive
'outline-width' <border-width> | inherit medium Neine visual, interactive
'overflow' visible | hidden | scroll | auto visible Elemente auf Nein visual
| inherit Blockebene und
ersetzte Elemente
'padding' <padding-width>{1,4} | inhe- XX Nein Beziehen sich auf visual
rit die Breite des ent-
haltenden Blocks
'padding-top' <padding-width> | inherit 0 Nein Beziehen sich auf visual
Eigenschaftsindex
'padding-right' die Breite des ent-
'padding-bot- haltenden Blocks
tom' 'padding-
left'
'page' <identifier> | auto auto Elemente auf Ja visual, paged
Blockebene
'page-break-af- auto | always | avoid | left | auto Elemente auf Ja visual, paged
ter' right | inherit Blockebene
'page-break- auto | always | avoid | left | auto Elemente auf Nein visual, paged
< 865 >
before' right | inherit Blockebene
'page-break-in- avoid | auto | inherit auto Elemente auf Ja visual, paged
side' Blockebene
Cascading Style Sheets, Level 2
Cascading Style Sheets, Level 2
< 866 >
'pause' [ [<time> | Vom Nein Siehe Beschreibun- aural
<edition
[Link]>
Page size: 168,00 x 240,00 mm
<percentage>]{1,2} ] | inherit Benutzer- gen von 'pause-be-
programm fore' und 'pause-af-
abh@ngig ter'
'pause-after' <time> | <percentage> | Vom Nein Siehe Text aural
inherit Benutzer-
Eigenschaftsindex
programm
abh@ngig
'pause-before' <time> | <percentage> | Vom Nein Siehe Text aural
inherit Benutzer-
programm
abh@ngig
'pitch' <frequency> | x-low | low | medium Ja aural
medium | high | x-high | inhe-
rit
'pitch-range' <number> | inherit 50 Ja aural
'play-during' <uri> mix? repeat? | auto | auto Nein aural
none | inherit
'position' static | relative | absolute | static Alle Elemente, Nein visual
fixed | inherit außer auf erzeug-
ten Inhalt
'quotes' [<string> <string>]+ | none | Vom Ja visual
inherit Benutzer-
programm
abh@ngig
'richness' <number> | inherit 50 Ja aural
'right' <length> | <percentage> | auto Positionierte Ele- Nein Beziehen sich auf visual
Page size: 168,00 x 240,00 mm
auto | inherit mente die Breite des ent-
haltenden Blocks
'size' <length>{1,2} | auto | portrait auto Der Seitenkontext N/A visual, paged
| landscape | inherit
'speak' normal | none | spell-out | normal Ja aural
inherit
'speak-header' once | always | inherit once Elemente, die Ja aural
Tabellenkopf-infor-
mationen enthal-
ten
'speak-nume- digits | continuous | inherit continuous Ja aural
ral'
'speak- code | none | inherit none Ja aural
punctuation'
'speech-rate' <number> | x-slow | slow | medium Ja aural
Eigenschaftsindex
medium | fast | x-fast | faster |
slower | inherit
'stress' <number> | inherit 50 Ja aural
'table-layout' auto | fixed | inherit auto 'table'- und 'inline- Nein visual
table'-Elemente
'text-align' left | right | center | justify | Vom Elemente auf Ja visual
<string> | inherit Benutzer- Blockebene
programm
und der
< 867 >
Schreib-
richtung
abh@ngig
Cascading Style Sheets, Level 2
Cascading Style Sheets, Level 2
< 868 >
'text-decorati- none | [ underline || overline none Nein visual
<edition
[Link]>
Page size: 168,00 x 240,00 mm
on' || line-through || blink ] | inhe- (siehe
rit Text)
'text-indent' <length> | <percentage> | 0 Elemente auf Ja Beziehen sich auf visual
inherit Blockebene die Breite des ent-
haltenden Blocks
Eigenschaftsindex
'text-shadow' none | [<color> || <length> none Nein visual
<length> <length>? ,]* (siehe
[<color> || <length> Text)
<length> <length>?] | inherit
'text-trans- capitalize | uppercase | lower- none Ja visual
form' case | none | inherit
'top' <length> | <percentage> | auto Positionierte Ele- Nein Bezieht sich auf die visual
auto | inherit mente H=he des enthal-
tenden Blocks
'unicode-bidi' normal | embed | bidi-over- normal Alle Elemente; Nein visual
ride | inherit Ausnahme: siehe
Text
'vertical-align' baseline | sub | super | top | baseline Inline- und 'table- Nein Beziehen sich auf visual
text-top | middle | bottom | cell'-Elemente die 'line-height' des
text-bottom | <percentage> | eigentlichen Ele-
<length> | inherit ments
'visibility' visible | hidden | collapse | inherit Nein visual
inherit
'voice-family' [[<specific-voice> | Vom Ja aural
<generic-voice> ],]* Benutzer-
[<specific-voice> | programm
<generic-voice> ] | inherit abh@ngig
'volume' <number> | <percentage> | medium Ja Beziehen sich auf aural
Page size: 168,00 x 240,00 mm
silent | x-soft | soft | medium den geerbten
| loud | x-loud | inherit Wert
'white-space' normal | pre | nowrap | inhe- normal Elemente auf Ja visual
rit Blockebene
'widows' <integer> | inherit 2 Elemente auf Ja visual, paged
Blockebene
'width' <length> | <percentage> | auto Alle Elemente, Nein Beziehen sich auf visual
auto | inherit außer nicht die Breite des ent-
ersetzte Inline-Ele- haltenden Blocks
mente, Tabellen-
zeilen und Zeilen-
gruppen
'word-spacing' normal | <length> | inherit normal Ja visual
'z-index' auto | <integer> | inherit auto Positionierte Ele- Nein visual
mente
Eigenschaftsindex
< 869 >
Cascading Style Sheets, Level 2
Page size: 168,00 x 240,00 mm
<edition
[Link]>
G Deskriptor-Index
Name Werte Ausgangswert
'ascent' <number> nicht definiert
'baseline' <number> 0
'bbox' <number>, <number>, <number>, nicht definiert
<number>
'cap-height' <number> nicht definiert
'centerline' <number> nicht definiert
'definition-src' <uri> nicht definiert
'descent' <number> nicht definiert
'font-family' [ <family-name> | <generic-family> ] [, vom Benutzerprogramm
[<family-name> | <generic-family> ]]* abh@ngig
'font-size' all | <length> [, <length>]* alle
'font-stretch' all | [ normal | ultra-condensed | extra- normal
condensed | condensed | semi-condensed
| semi-expanded | expanded | extra-ex-
panded | ultra-expanded ] [, [ normal |
ultra-condensed | extra-condensed | con-
densed | semi-condensed | semi-expan-
ded | expanded | extra-expanded | ultra-
expanded] ]*
'font-style' all | [ normal | italic | oblique ] [, [normal | alle
Cascading Style Sheets, Level 2
italic | oblique] ]*
'font-variant' [normal | small-caps] [,[normal | small- normal
caps]]*
'font-weight' all | [normal | bold | 100 | 200 | 300 | 400 alle
| 500 | 600 | 700 | 800 | 900] [, [normal |
bold | 100 | 200 | 300 | 400 | 500 | 600 |
700 | 800 | 900]]*
'mathline' <number> nicht definiert
'panose-1' [<integer>]{10} 0000000000
'slope' <number> 0
'src' [ <uri> [format(<string> [, <string>]*)] | nicht definiert
<font-face-name> ] [, <uri> [for-
mat(<string> [, <string>]*)] |
<font-face-name> ]*
'stemh' <number> nicht definiert
'stemv' <number> nicht definiert
< 870 > Deskriptor-Index
Page size: 168,00 x 240,00 mm
'topline' <number> nicht definiert
'unicode-ran- <urange> [, <urange>]* U+0-7FFFFFFF
ge'
'units-per-em' <number> nicht definiert
'widths' [<urange> ]? [<number> ]+ [,[<urange> nicht definiert
]? <number> ]+]
'x-height' <number> nicht definiert
Cascading Style Sheets, Level 2
Deskriptor-Index < 871 >
Page size: 168,00 x 240,00 mm
Page size: 168,00 x 240,00 mm
Index
<frequency> 577
! <integer> 569
<length> 570
A
!important-Regeln 606 <number> 569 Abk>rzungen und Akronyme
#FIXED 58 <percentage> 573 117
#IMPLIED 58 <time> 577 Absatz, visuelle Darstellung
#REQUIRED 58 <uri> 574 127
%attrs; 60 6berlauf 677 Abschneiden, Tabellentext
%block; 56 6berschriften 145
%Character; 77 positionieren und Abschnittsnummern,
%Charset; 77 ausrichten 791 nummeriert 103
%Color; 75 verschachtelt 103 Absenden 260
%ContentType; 77 6berstreichen 774 Abstand, um Frame 248
%Datetime; 77 'width' 665 Abstraktes Modul 393, 402
%FrameTarget; 82 :active 594 Abw@rtskompatibilit@t 553
%inline; 56 :first 713 Adressierungsmodell 553
%LanguageCode; 77 :first-child 591 after 684
%Length; 76 :first-line 595 Akustische Stylesheets 817
%MediaDesc; 80 :focus 594, 817 Alternativer Text,
%MultiLength; 76 :hover 594 spezifizieren 216
%Pixels; 76 :left 713 Alternatives Stylesheet 225
%Script; 81 :right 713 andere 372
%Text; 74 @ 564 Anf>hrungszeichen, content
%URI; 74 @font-face 746 691
<angle> 577 @import 610 Anker 178
<color> 575 @import-Regel 604 ASCII-Zeichen im Namen
@media 610 186
@media-Regel 604, 611 Definition mit A 184
@page-Regel 709, 711, 713 durch ein Skript setzen
184
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Eindeutigkeit des Namens von Block-Level-Elementen implizite Verkn>pfung mit
186 231 Steuerelement 278
Erstellung mit dem von Objekten 215 Beschriftungen, und Fokus
id-Attribut 187 von Tabelleninhalt 161 279
Groß-/Kleinschreibung des Auszeichnen 49 Best@ndiges Stylesheets 226
Namens 186 Auszeichnungssprache 49 Bevorzugtes Stylesheet 225
mit A oder id 188 Autor 61, 557 Bidirektionalit@t 658–659
Namensraum 187 Autorenwerkzeug 61, 116 ausschalten 112
Nicht-ASCII-Zeichen in und Standard-Stylesheet- und Stylesheets 115
name 323 Sprache 221 und Zeichenkodierung 113
Syntax der Namen 186 azimuth 825 Unicode-Algorithmus 109
Zeichenreferenzen im Bild
Namen 188
Anweisungen 564
B Ausrichtung 215
Breite und HIhe 214
Applet, Einbinden 194 background 725 Einbinden 194
application/x-www-form-url- background-attachment 723 lange Beschreibung 197
encoded 262, 288 background-color 721 Leerraum um 215
ascent, Deskriptor 756 background-image 721 nicht direkt in Frame 255
At-Regeln 564 background-position 724 Rahmen um 215
Attribut 53, 369, 556 background-repeat 722 visuelles Rendern 214
#FIXED 58 Backslash 563 Bitmap 612
#IMPLIED 58 baseline, Deskriptor 759 Blinken 774
#REQUIRED 58 Basis-URI 192 Block, umschließender 628,
Anf>hrungszeichen 53 bbox, Deskriptor 758 663
Boolesches 60 before 684 Block-Boxen, anonyme 629
Deklaration in DTD 58 Beispiel-Stylesheet 832 Block-Level-Elemente,
Groß- und Kleinschreibung Benutzer 61, 557 Bidirektionalit@t 110
53 Benutzeroberfl@che 812, Blockebene 550, 629
Groß- und Kleinschreibung 814, 816 Blockelement 100
von Werten 58 Benutzerprogramm 62, 369, Blockelemente,
minimiertes boolesches 60 538, 549, 557 Bidirektionalit@t 100
Attribut-Selektoren 581, Behandlung von Imagemaps BODY, keiner in Frameset
585, 587 210 98
Attributminimierung 375 Fehlersituationen 321 Bogenmaß 577
Attributwerte, DTD 587 konformes 62 Boolesches Attribut 60
AuflIsung einer relativen URI Konformit@t in XHTML 1.1 minimiertes 60, 326
193 519 border 627
Aufw@rtskompatibilit@t 553 Script- und Style-Daten border-bottom 626
aural 611–612 behandeln 73 border-bottom-color 622
Ausgangsblock, Skript-Daten 300 border-bottom-style 625
umschließender 628 Style-Daten 229 border-bottom-width 621
Ausgangswert 542 XHTML-Familie, border-collapse 802
Ausrichtung 759, 773 Konformit@t 399 border-color 623
fließen 233 Beschriftung border-left 626
fließender Text 234 explizite Verkn>pfung mit border-left-color 622
horizontale 801 Steuerelement 278 border-left-style 625
von Bildern 215 border-left-width 621
< 874 > Index
Page size: 168,00 x 240,00 mm
border-right 626 centerline, Deskriptor 759 ID 73
border-right-color 622 CERN 44 IDREF 73
border-right-style 625 Checkbox 260 IDREFS 73
border-right-width 621 class-Attribut, Rolle 99 NAME 73
border-spacing 802 clear 646 NUMBER 73
border-style 625 client-seitige Image Map 208 Datenzelle, in Tabelle 156
border-top 626 Anlegen 211 Datum
border-top-color 622 clip 680 Format 77
border-top-style 625 cm 573 von eingef>gtem und
border-top-width 621 Code-Position 64 gelIschtem Text 128
bottom 638 Codierungsvektor 763 Deaktivierte Steuerelemente
Box col 787 284
HIhe 671 colgroup 787 nicht erfolgreich 286
Inhaltsbreite und -hIhe color 720 Definition, Konformit@t 397
614 compact 688 definition-src, Deskriptor
InhaltshIhe 670 containing block 663 758
Maße 613 content, Anf>hrungszeichen deg 577
Polsterungseigenschaften 691 Deklaration 549, 566
619 Content-Language-Header Deklarationsblock 566
R@nder 671 116 descent, Deskriptor 757
Rahmeneigenschaften 621 Content-Script-Type-Header direction 659
Rahmenfarbe 622 293 display 634
Rahmenstileigenschaften Content-Style-Type-Header document type declaration
624 220 84
Randeigenschaften 617 continuous 612 document type definition
Stapelebene 657 counter() 686 Beispiele konform zu 63
Box-Abst@nde 637 counter-increment 693 Kommentare in 55
Box-Breite 614 counter-reset 693 lesen 55
Box-HIhe 614 counters() 686 Documenttyp-Definition,
Box-Modell 613–614, 616, CSS-Dokumentdarstellung Transitional 305
618, 620, 622, 624, 626 578–579 Dokument 370
braille 611 CSS2-Verarbeitungsmodell dynamische Modifikation
Breite, maximal und minimal 551 durch Skripte 298
668 cue 823 einbinden 194, 208
Browser 549 cue-after 822 SGML-Validierung 302
Buchstabenabst@nde 777 cue-before 822 Wege einzubinden 256
Cursor 812 XHTML-Familie,
C Konformit@t 399
Canvas 552
D Dokumentbaum 556
Dokumentdarstellung
cap-height, Deskriptor 756 Darf 368 578–579
caption 787 dashed 624 Dokumentkonformit@t,
caption-side 791 Dateiauswahl 261 XHTML 1.1 518
cascading 228 Dateiauswahl-Steuerelement, Dokumenttyp, hybrider 393
cascading style sheets 228 6bertragung 286 Dokumenttyp-Definition 50
CDATA 59, 73 Datentyp DTD-Fragmente konform
Script- und Style-Daten 73 CDATA 73 zu 63
Index < 875 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Frameset 305 Typdeklaration 51, 56 Fluss, normaler 635, 639
Strict 305 Typen 51 Fokus 281, 283, 817
Dokumenttyp-Deklaration untergeordnetes 556 Beschriftung gibt an
Frameset-DTD 84 Unterst>tzung f>r Steuerelement 279
Strict-DTD 84 missbilligte 62 und Zugriffstaste 283
Transitional-DTD 84 Unterst>tzung f>r obsolete font 741
Dokumentzeichensatz 64 62 Font family 730
Squivalenz von ISO10646 vorhergehendes 557 Font set 731
und UNICODE 65 weglassen End-Tag 51 Font size 730
ISO10646 65, 302 weglassen Start-Tag 51 Font stretch 730
dotted 624 elevation 826 Font style 730
double 624 em 570 Font variant 730
DTD, Standardattributwerte em-Quadrat 762 Font weight 730
587 embossed 611 font-family, Deskriptor 749
Dublin Core 96 empty-cells 804 font-size, Deskriptor 751
Durchstreichen 774 End-Tag 51 font-size-adjust 738
optional 56 font-stretch, Deskriptor 750
E weglassen 51
End-Tags 375
font-style, Deskriptor 749
font-variant, Deskriptor 749
Effekte, visuelle 677 Entity-S@tze, URIs f>r HTML font-weight, Deskriptor 750
Eigenschaft 566 4.01 84 Formatierungsmodell 628
unbekannte 568 Entwurfskonzepte 553 Formatierungsstruktur 552
zusammenfassende 542 Ereignisse 294 Formular
Einbinden von 199 erfolgreiches Steuerelement >bertragene Werte 286
Eingebettete Ereignisse 294 286 6bertragung 285, 287, 289
Einr>ckung 772 Escape 563 6bertragungsmethode
Einrahmungen 815 ex 570 285
Element 370, 556 Beschriftungen 277
Blockelement 100
eindeutiger Identifikator
F Beschriftungen hinzuf>gen
277
98 family-name 732 Gruppieren von Steuerele-
End-Tag 51 Farbe 719 menten in 280
ersetztes 556 Hintergrund 231 Inhaltstyp f>r Kodierung
gleichrangiges 557 Farben 575 287
Groß- und Kleinschreibung Fehler inkrementelle Darstellung
52 Behandlung durch 336
Inhalt 556 Benutzerprogramme Kodieren der Daten 287
Inhaltsmodell 56 321 Methoden 287
inzeilig 100 Imagemap mit IMG in Steuerelement 258
leer 51, 56 BUTTON 270 Steuerelementtypen 260
MaximalhIhe 673 nicht verf>gbare Ressource Tabulator-Reihenfolge 282
MindesthIhe 673 188 Tabulatornavigation 282
nachfolgendes 557 STYLE im Dokumenttext verarbeiten 287
Referenzen von Skripts darstellen 222 Zur>cksetzen 259
294 Fehlerbedingungen 560 Formulardatensatz 287
Start-Tag 51 float 645 Kodieren 287
Floats 635, 642–643, 645 Fragmentbezeichner 43, 179
< 876 > Index
Page size: 168,00 x 240,00 mm
Frame Groß-/Kleinschreibung 375, HTML Working Group,
Abstand um 248 563 Mitglieder 41
Ausgangsinhalt 249 Attributwerte 72 HTML-Dokument 61
Einf>hrung 241 des Ankernamens 186 HTTP
eingebettet 256 Farbnamen 75 Content-Language-Header
lange Beschreibung 255 in numerischen 116
Liste reservierte Namen Zeichenreferenzen 70 Content-Script-Type-
von Ziel-Frames 82 Inhaltstypen 77 Header 293
Rahmen 248 Linktyp 78 Content-Style-Type-
URI-Probleme 253 Maßwerte 76 Header 220
Ziel 251, 253 Medien-Deskriptoren 81 Content-Type-Header 69
Zielalgorithmus 338 Script-Daten 81, 409 Default-Style-Header 227
Frameset Sprachcodes 77 GET und POST mit
alternativer 255 Style-Daten 82 Formularen 285
alternativer Inhalt 254 URIs 75 verwendet, um auf Style-
Daten teilen 246 von Zeichen-Entity- sheets zu verweisen 230
Festlegen des Layouts 243 Referenzen 71 Hybrider Dokumenttyp 393
Navigationsprobleme 253 Zeichenkodierungen 77 Hyperlink-Quellanker 593
verschachtelt 246 Großschreibung 779 Hz 577
Verwendung von groove 624
NOFRAMES 254
Frameset-Dokument 243
Grundlinie
mathematische 765
I
Frameset-DTD obere 766 ID 73
Definition 305 untere 764 id-Attribut 377
Deklaration 84 zentrale 763 gleicher Namensraum wie
Frequenzwerte 577 das name-Attribut 187
Funktionsmerkmale 370 H Rolle 98
id-Attribute 373
G handheld 611
Hauptblock-Box 629
ID-Selektoren 581, 589
IDREF 73
G>ltigkeitsbereich 694 height 670 Ignorieren 568
Gammakorrektur 726 hidden 624 Image 209, 211, 213
generic-family 732 Hintergrund 719–720 Image Map 208
GET, und Hintergrundbild 724 6berschneiden von
Formular>bertragung 285 Hintergrundeigenschaften Regionen 211
Glyphen 727 721 client-seitig 208
Glyphenbreite 763 Hintergrundfarbe 231 mit OBJECT 210
Grad 577 HTML 546 nicht gestattet f>r IMG in
Gradienten 577 allgemeine Regeln 48 BUTTON 270
Grammatik 848 als SGML-Anwendung 63 server-seitig 208
grid 612 Entwicklung von 44 server-seitige 214
Groß- und Kleinschreibung Kommentare 54 Zug@nglichkeit von 211
von Attributen values 58 Nicht-HTML-Daten 324 Imagemap 214
von Attributnamen 53 Version 2.0 44 Implementierung 370
von Elementnamen 52 Version 3.0 44 in 573
Version 3.2 45
Version HTML+ 44
Index < 877 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Inhalt 556 verwendet zum Verbergen reduzieren 116
erzeugter 684 von Stylesheet-Daten um Bilder und Objekte
Position 684 229 215
Inhaltsbreite 665 Zeichenreferenzen 70 um Tabelleninhalt 164
InhaltshIhe 670 Konforme vorformatiert in PRE 126
Inhaltsmodell 56 Benutzerprogramme 373 Zeichen 115
ausgeschlossene Elemente Konforme Dokumente 370 Leerraumzeichen 374
58 Konformit@t 62, 558 Leerzeichen 772
Syntax in DTD 57 Benutzerprogramm der left 638
Inhaltstyp XHTML-Familie 399 letter-spacing 777
application/x-www-form- Definition 397 line-height 675
urlencoded 288 Dokument der Linie
f>r Kodierung von XHTML-Familie 399 zwischen
Formulardaten 287 Modul der XHTML-Familie Block-Level-Elementen
multipart/form-data 288 398 240
text/html 63 XHTML Host Language zwischen Tabellenzellen
inherit 603 397 159
Inline-Box, anonyme 631 XHTML Integration Set Link
Inline-Formatierungskontext 398 benutzen, um eine
639 zu XHTML 1.1 518 Ressource zu erreichen
inline-table 787 Koordinaten 178
inset 624 von Formular>bertragung Definition 178
Integer 569 Klick 265 Element 547
interactive 613 von server-seitigen externe Stylesheets 190,
Internet Engineering Task Imagemaps 214 226
Force (IETF) 44 Kopfzelle medienabh@ngige
inzeiliges Element 100 Abk>rzung 166 Stylesheets 229
ISO 8879 37 in Tabelle 156 Semantik Ziel-Frame 253
Scope 166 Standardziel 253
K Kreuzmarkierungen 712 Titel 182
Typ 78, 548
Kann 368
Kaskade, Seitenkontext 719
L ung>ltige Verschachtelung
186
Kaskaden-Reihenfolge 605 L@ngen 570 vorw@rts und r>ckw@rts
Katalog f>r HTML 303 L@ngeneinheiten 190
kHz 577 absolute 573 Zeichenkodierung 182
Klassen-Selektoren 581, 588 relative 570 zur Definition von Bezie-
Kombinatorzeichen 582 lang-Attribut hungen benutzen 179
Kommentare 568 nicht f>r Richtung 109 Link-Pseudoklassen 581, 592
in DTD 55 wenn relevant 105 Linktyp
in HTML 54 Lange Bildbeschreibung, Rela- Groß-/Kleinschreibung 78
informelle 63 tion zu alt-Text 197 Liste bekannter 78
nicht darstellen 63 Lautst@rke 818–819 Profile f>r neue 80
verwendet zum Verbergen Leeraum 115 list-style 707
von Skript-Daten 300 Leere Elemente 376 list-style-image 705
Leeres Element 56 list-style-position 705
Leerraum 780 list-style-type 703
< 878 > Index
Page size: 168,00 x 240,00 mm
Liste 684, 697 Meta-Daten 90 im Kopf 199–200
Definitionsliste 134–135, Metadaten in HEAD 246
137 LINK vs META 92 Initialisierung 201
geordnet 132 Profil 95 Leerraum 215
nummerieren 134 scheme f>r 95 Mechanismus zur
Stylesheets 136 MIME-Typ 378 Darstellung 199
ungeordnet 132 min-height 673 Namensschemata 203
verschachteln 133 min-width 668 Ort Implementation und
visuelle Darstellung 136 MindesthIhe 673 Daten 199
Listeneigenschaften 702 Missbilligt 62 Rahmen 215
mm 573 Rangfolge des Renderns
M Modul der XHTML-Familie,
Konformit@t 398
von 200
Regeln f>r Einbindung 200
margin-bottom 617 Modularisierung von XHTML visuelles Rendern 214
margin-left 617 390 Objekt-Steuerelement 261,
margin-right 617 Modulbasiertes XHTML 516 286
margin-top 617 Modulimplementierungen Obsolet 62
Marker 697 393 Optional 368
marker-offset 701 ms 577 Orphans 717
Markierungen 697–698 multipart/form-data 262, 288 outline 815
marks 712 Muss 368 outline-color 816
mathline, Deskriptor 759 Mustervergleich 580 outline-width 815
max-height 673 outset 624
max-width 669
MaximalhIhe 673
N overflow 678
Medien-Deskriptor
Groß-/Kleinschreibung 81
Nachkomme 557
Nachrichteneinheit 63
P
List bekannter 80 NAME 73 padding 620
parsen 81 name-Attribut 377 padding-bottom 619
Medienabh@ngigkeit, von Namensraum 372 padding-left 619
Stylesheets 610 Namensraum f>r XTHML padding-right 619
Mediengruppen 612 371 padding-top 619
Medientyp 610, 378, 611 Namensregeln, XHTML Host page 716
Medium Language 401 page-break-after 715
externe Stylesheets 229 Nicht spezifiziert 368 page-break-before 714
verwendet mit Stylesheets NUMBER 73 paged 612
224 Numerische Zeichenreferenz panose-1, Deskriptor 755
Men> 261 70 Parameter-Entity
Darstellen von Nummerierung 684, 693 %attrs; 60
AuswahlmIglichkeiten %block; 56
273
Gruppieren von
O %Character; 77
%Charset; 77
AuswahlmIglichkeiten Objekt %Color; 75
271 Ausrichtung 215 %ContentType; 77
visuelle Darstellung von Breite und HIhe 214 %Datetime; 77
Gruppierungen 274 Deklaration 204 %FrameTarget; 82
Vorauswahlen 271 im Formular 261 %inline; 56
Index < 879 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
%LanguageCode; 77 Links 592 right 637
%Length; 76 Sprache 595 root-Element 556
%MediaDesc; 80 pt 573 run-in 688
%MultiLength; 76 px 570 Run-in-Box 633
%Pixels; 76
%Script; 81
%Text; 74
Q S
%URI; 74 Quelldokument 556 s 577
Parameter-Entity-Definition quotes 689 Schaltfl@che 260
55 Schatteneffekte 776
Parsing 370
Passworteingabe-Steuerele-
R scheme 95
Schl>sselwIrter 562
ment 265 R@nder 666–667 Schnittmarkierungen 712
pause 822 rad 577 Schreibgesch>tzte
pause-after 821 Radio-Button 260 Steuerelemente 285
pause-before 821 Rahmen 613, 802–803, 805, Schrift-Download 746
Pausen-Eigenschaften 821 807 Schriftart
pc 573 um Bild 215 mit 237, 239
pitch 829 um eine Tabelle 159 mit HTML 236
pitch-range 829 um einen Frame 248 Schriftauswahl 745, 747, 749,
Pixel 76 um Objekt 215 751, 753, 755, 757, 759
Platform for Internet Con- Rahmenbreite 621 Schriftbeschreibungen 746
tent Selection (PICS) 94 Rahmeneigenschaften, Schriftcharakteristika 761,
play-during 824 zusammenfassende 626 763, 765
Polsterung 613 Rahmenfarbe 622 Schriftcodierung 763
Polsterungseigenschaften Rahmenstile 808 Schriftcodierungstabelle 763
619 Rahmenstileigenschaften 624 Schriftdaten 746
Position 636 Rand 613 Schriftdatenbank 728
Positionierung Randeigenschaften 617 Schriftdatenqualifizierung
absolute 635, 647 Referenz, normative 37 751
relative 641 Regel 566 Schriftdehnung 730
Positionierungsschema, Regelmenge 566 Schriften 727
Auswahl 636 Registrierungsmarkierungen Schriftfamilie, generische 743
POST 712 Schriftfamilienname 763
f>r Nicht-ASCII-Formular- Relativer URI 43 Schriftgewichtung 730
daten 286 AuflIsung 43 SchriftgrIße 730, 736
Formular>bertragung 285 Relatives Maß 76 Schriftmenge 731
print 612 Rendering 370 Schriftmodell 728
Profile 95 Reserviert 368 Schriftname, vollst@ndiger
projection 612 Resource Description Frame- 761
Prozentwerte 573 work (RDF) 48, 90 Schriftnamensvergleich 745
Pseudo-Element 590, 595, richness 831 Schriftspezifikation,
597, 599–600 Richtung 143 Eigenschaften 730
Pseudo-Klassen 590–591, Vererbung f>r eingeschlos- Schriftstil 730, 733
593 sene Elemente 110 Schriftsynthese 746
Dynamic 581 von Text 108 Schriftvariante 730
dynamische 594 ridge 624
< 880 > Index
Page size: 168,00 x 240,00 mm
Schriftvergleich Deklaration 50, 304 slope, Deskriptor 756
Algorithmus 767, 769, 771 Deklaration von HTML 4 solid 624
intelligenter 746 303 Soll 368
Scope, von Tabellenkopfzelle Dokumenttyp-Definition Sollte 369
166 (DTD) 50 Spalte 781
screen 612 Dokumentvalidierung 302 Anzahl in einer Tabelle
Script, Daten 81 Dokumentzeichensatz 64 150
Seite Eigenschaften mit begrenz- Breite in einer Tabelle 151
benannte 716 ter Unterst>tzung 325 Spaltengruppe 147
linke, rechte, doppelseitig Einf>hrung 49 Spaltenselektoren 789
713 Elementtyp-Deklaration speak-header 809
Randbereich 709 51 speak-numeral 832
Seiten-Box 709 Katalog 303 speak-punctuation 831
Seitenbereich 709 Katalog f>r HTML 303 speech-rate 827
SeitengrIße 711 Zeilenumbruch 324 Spezifizit@t 609
Seitenkontext, Kaskade 719 SGML-Anwendung 37 Sprach-Pseudo-Klasse 595
Seitenmedien 708 Sicherheit Sprachcharakteristik 827
Seitenr@nder 710 Anmerkungen 339–339 Sprache
Seitenumbruch 714–715, von Passworteingabe- Code 105
717 Steuerelement 265 einer verlinkten Ressource
bester 718 Sichtbarkeit 682–683 182
erlaubter 717 Silbentrennung 124 Pseudo-Klasse 595
erzwungener 718 size 711 von Skripten 292
Selektor 566, 580 Skript von Text 104
abgeleitete 580 ausgef>hrt bei Eintreten Spracheigenschaften 820,
abgeleiteter 583 eines Ereignisses 291 831
Attribut 581 ausgef>hrt w@hrend des src, Deskriptor 753
benachbart gleichrangig Ladens 291 Standard
584 Einf>hrung 290 Skriptsprache 293
benachbarte 581 Implementierung 337 Stylesheet-Sprache 220
einfacher 582 Kommentare zum Zeichenkodierung 69
Gruppierung 582 Verbergen 300 Ziel-Frame 253
ID 581 Referenzen auf Standardattributwerte, DTD
Klassen 581 HTML-Elemente 294 587
Spezifizit@t 609 reservierte Syntax 337 Stapelebene 657
universeller 580, 582 verwendet zur Modifika- Start-Tag 51
untergeordnete 580 tion des Dokuments weglassen 51
untergeordneter 584 298 static 613
Selektorsyntax 582 Verwendung 290 stemh, Deskriptor 755
server-seitige Imagemap 208, wenn nicht unterst>tzt stemv, Deskriptor 755
214 299 Steuerelement
Klick-Koordinaten 214 zum Setzen eines Ankers deaktiviert 284
SGML benutzen 184 Ereignisse 296
Anmerkungen 325 Skriptsprache erfolgreich 286
Anmerkungen zur lokale Deklaration 293 schreibgesch>tzt 285
Implementierung 324 Spezifikation 292 Typen 260
Anwendung 50 Standard 293
Index < 881 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Steuerung 258 Stylesheet-Sprache, Standard Tabellenelemente 782
aktueller Wert 259 220 TabellenhIhe 798
Anfangswert 259 Such-Robot, helfen 329 Tabelleninhalt
Elementname 258 Suchmaschine visuelles 793, 795, 797,
Tabulatornavigation 282 helfen 93, 327 799, 801
Zugriffstaste 283 Links 191 visuelles Layout 793
Stilregeln 580 Syntax 560–561, 563, 565, Tabellenlayout
Streng konforme Dokumente 567 automatisches 797
371 festes 797
stress 830
Strichbreite
T Tabellenmodell 787
Tabellenobjekte, anonyme
horizontale 763 Tabelle 788
vertikale 766 6berschrift 144 table 787
Strichwinkel, vertikaler 766 Algorithmen zur Auffin- table-caption 787
Strict-DTD dung von table-cell 787
Definition 305 Kopfinformationen 172 table-column 787
Deklaration 84 Anzahl der Spalten 142, table-column-group 787
Strings 578 150 table-footer-group 787
Style, Element 547 Ausrichtung des Inhalts table-header-group 787
Stylesheet 547, 555 161 table-layout 796
akustisches 817 Breite von Spalten 151 table-row 787
alternativ 225 Datenzellen 156 table-row-group 787
Angabe einer externen inkrementelle Darstellung Tabulator-Reihenfolge 282
226 143, 331 Tabulatornavigation 282
Beispiel HTML 4.0 832 Kategorisieren von Zellen tactile 612
best@ndig 226 168 target Frame, Standard 253
bevorzugtes 225 Kopfzellen 156 tbody 787
Daten 82 Layout-Algorithmen 333 td 787
Einf>hrung 217 mehrere Zeilen/Spalten Text 772, 774, 776, 778, 780
einzeilig 221 157 Auszeichnungen f>r einge-
extern >ber Verweise 190 nicht visuelle Darstellung f>gten und gelIschten
externes 225, 227 165 128
g>ltiges 555 Rahmen und Linien 159 fließen 234
kaskadierend 228 Richtung 143 Richtung 108
Kommentare zum Spaltengruppe in 147 umbrechen 127
Verbergen 229 visuelle Formatierung 159 Umbruch im Absatz 127
medienabh@ngiges 610 Zeilengruppe 145 vorformatiert 126
Position 548 Zelldaten sprechen 172 zitierter 119
Regeln in HEAD 222 Zellr@nder 164 text-align 773
Specifikation von Zusammenfassung des text-decoration 774
bevorzugtem 227 Inhalts 144 text-indent 772
Typ 548 Tabellen 781, 783, 785 text-shadow 775
und Bidirektionalit@t 115 akustische 809 text-transform 779
verwendet mit DIV und nicht f>r Formatierungen text/html 63
SPAN 223 47 Texteingabe 261
Zielmedium 224 Tabellenbreite 796
Stylesheet-Regeln 547 Tabellenebenen 794
< 882 > Index
Page size: 168,00 x 240,00 mm
Texteingabe-Steuerelement Basis angeben 192 Wortabst@nde 777
einzeilig 265 Groß-/Kleinschreibung 75 Wortzwischenraum 116
mehrzeilig 276 Nicht-ASCII-Zeichen in
Textrichtung 658
Textschatten 775
Attributwerten 323
relativer 43
X
tfoot 787 Verwendung von in HTML x-height, Deskriptor 756
th 787 44 XHTML, Modularisierung
thead 787 URL, Relation zu URI 43 390
Titel URN 574 XHTML 1.1 516
eines Dokuments 88 User Agent 538, 557 Konformit@t zu 518
verf>gbar f>r den Benutzer UTF-1 68 XHTML Host Language
88 UTF-16 68 Konformit@t 397
verwendet, um Elemente Namensregeln 401
mit Kommentaren zu
versehen 89
V XHTML Integration Set,
Konformit@t 398
Token 561 Validierung 370 XHTML und MathML 372
top 637 Vererbung 602–603 XHTML-Module, abstrakte
topline, Deskriptor 759 VergrIßerung 817 410
tr 787 Verstecktes Steuerelement XML 549
Transitioal-DTD, Definition 261, 286
305
Transitional-DTD,
vertical-align 676
Verweis, Wiedergabe 184
Z
Deklaration 84 Viewport 628 Z@hler 575, 686
Transparenz 794 visibility 682 automatisch 693
tty 612 visual 612 verschachtelte 694
tv 612 voice-family 828 Z@hlerstil 696
Typselektor 580, 583 Vordergrundfarbe 720 z-index 657
Vorfahre 557 Zahlen, reelle 569
U Zeichen 563, 772
Umbruch, innerhalb von
W abstrakte 64
Behandlung von nicht
Elementen 717 Waisen 717 darstellbaren 72
Umflossene Objekte 233 WebFonts 728 bester Weg darzustellen
Unicode-Bidirektional-- Weiches Trennzeichen 124 105
Algorithmus 109 Werte 569, 571, 573, 575, nicht darstellbare 72
unicode-range, Deskriptor 577 Zugriffstaste 283
751 berechnete 601 Zeichen-Entity-Referenz 71
units-per-em, Deskriptor spezifizierte 601 Zeichenfl@che 552
753 tats@chliche 602 Zeichenkodierung 63, 65
Universal Character Set 65 white-space 780 f>r Formular>bertragung
Universal Resource Identifier widows 717 262
(siehe URI) 42 widths, Deskriptor 757 h@ufig verwendete 66
Unterst>tzt 369 Winkel 577 Namen 77
Unterstreichen 774 Witwen 717 Reihenfolge der Ermittlung
URI 574 Wohlgeformtheit 370, 374 im Benutzerprogramm
AuflIsung relativer 43, word-spacing 778 69
193 World Wide Web (Web) 41 Spezifikation 68
Index < 883 >
Page size: 168,00 x 240,00 mm
<edition
[Link]>
Standard 69 erzwungener 687 alternativer Objektinhalt
UTF-1 68 Textfluss 234 200
UTF-16 68 verhindern 124 alternativer Text 216
von Links 182 Zeit, Format 77 Features in HTML 4 46
w@hlen 65 Zeitwerte 577 lange Bildbeschreibung
Zeichenkodierung und Zellen 781 197
Bidirektionalit@t 113 Ziel-Frame lange Frame-Beschreibung
Zeichenreferenz 70 Algorithmus 338 255
f>r Richtung 114 angeben 251, 253 Stylesheets 218
Zeichenreferenzen 54 reservierte Namen 82 von Imagemaps 208, 211
Zeichenvorrat 64 Semantik 253 Zugriffstaste 283
Zeilen, Anzahl in Tabellen Ziel-Medientypen 611 Zugriffstaste 283
142 Zielmedium 610 Zur>cksetzen 260
Zeilen-Box 639 Zitat 119 eines Formulars 259
Zeilengruppe 145 Zitierter Text 119 Zusammenfassung,
ZeilenhIhe 674 Darstellung 119 Tabelleninhalt 144
Zeilenumbruch 123 Zug@nglichkeit
bidirektionaler Text 124 alternativer Fame-Inhalt
erzwingen 123 254
< 884 > Index
Copyright
Daten, Texte, Design und Grafiken dieses eBooks, sowie die eventuell angebotenen
eBook-Zusatzdaten sind urheberrechtlich geschützt.
Dieses eBook stellen wir lediglich als Einzelplatz-Lizenz zur Verfügung!
Jede andere Verwendung dieses eBooks und zugehöriger Materialien und
Informationen, einschliesslich der Reproduktion, der Weitergabe, des Weitervertriebs,
der Plazierung auf anderen Websites, der Veränderung und der Veröffentlichung bedarf
der schriftlichen Genehmigung des Verlags.
Bei Fragen zu diesem Thema wenden Sie sich bitte an:
[Link]
Zusatzdaten
Möglicherweise liegt dem gedruckten Buch eine CD-ROM mit Zusatzdaten bei. Die
Zurverfügungstellung dieser Daten auf der Website ist eine freiwillige Leistung des
Verlags. Der Rechtsweg ist ausgeschlossen.
Hinweis
Dieses und andere eBooks können Sie rund um die Uhr
und legal auf unserer Website
([Link]
herunterladen