Formationsflug
Viele Webpuristen mögen keine Frames, manche lehnen sogar Tabellen für die Gestaltung von Webseiten ab. Cascading Stylesheets versprechen Abhilfe und erlauben außer der Formatierung von HTML die von XML-Dokumenten.
- Stefan Mintert
Es hat zwar lange gedauert, bis vor allem Netscape und Microsoft die Spezifikation der Cascading Stylesheets (CSS) in ihren Browsern in nennenswertem Umfang berücksichtigt haben, aber mittlerweile (= nach sieben Jahren, was CSS1 angeht) steht es gut um Mozilla, IE und Opera. Da bietet es sich an, Frames und Tabellen über Bord zu werfen und nur noch CSS zu verwenden. Doch ganz so einfach sieht die Wirklichkeit nicht aus.
Frames sind für viele Benutzer ein Ärgernis. Ihre Nachteile sind hinlänglich bekannt. Dazu zählen, dass einzelne Seiten sich schlecht in die Bookmarks/Favoriten übernehmen lassen und beim Zugriff auf einzelne Seiten die umgebenden Frames fehlen. In der CSS2-Spezifikation schlägt das W3C vor, dass Webautoren die feste Positionierung mit CSS verwenden können, ‘um Frame-ähnliche Präsentationen zu erzeugen.’ Das dort angegebene Beispiel im Abschnitt 9.6.1 soll für einen Test herhalten (siehe Listing 1).
Listing 1: Frame-ähnlich
<!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; background: black color: white; }
#sidebar {
position: fixed; width: 10em; height: auto; top: 15%;
right: auto; bottom: 100px; left: 0; background: lightgrey; }
#main {
position: fixed; width: auto; height: auto; top: 15%;
right: 0; bottom: 100px; left: 10em; }
#footer {
position: fixed; width: 100%; height: 100px; top: auto;
right: 0; bottom: 0; left: 0; background: darkgrey; color:white; }
</style>
</head>
<body>
<div id="header"> ... </div>
<div id="sidebar"> ... </div>
<div id="main"> ... </div>
<div id="footer"> ... </div>
</body>
</html>
Listing 2: Festes Menü
<div class="endmatter">
<div class="banner">
<p>
<a rel=home class=home href="../../"><img alt="W3C" src="../../Icons/w3c_home"></a>
<a rel=bookmark href="../../Consortium/Activities">Activities</a>
<a rel=bookmark href="../../TR/">Tech. reports</a>
<a rel=index href="../../Help/siteindex">Site index</a>
<a rel=bookmark href="../../Consortium/Translation/">Translations</a>
<a rel=bookmark href="../../Status">Software</a>
<a rel=search href="http://search.w3.org/">Search</a>
<em>Nearby:</em>
<a rel=up href="../">Style</a>
</div>
</div>
Auf den ersten Blick sieht das Listing im Browser gut aus, wie die Abbildung 1 zeigt. Die Screenshots offenbaren das Dokument zunächst mit einer üblichen Schriftgröße (oben). Der Haupttext ist nicht vollständig zu lesen, Scrolling bewirkt aufgrund der fixed-Positionierung nichts. Vergrößert der Benutzer die Schriftgröße, ist die Seite gar nicht mehr zu gebrauchen. Der Verzicht auf die Hintergrundfarbe demonstriert, dass Textbereiche ineinander fließen. Dass andere Browser das Dokument anders (und nicht wie gewünscht) anzeigen, unterstreicht die Unbrauchbarkeit nur zusätzlich.
Navigation mit CSS einblenden
In vielen Fällen besteht die Motivation für ein Frameset darin, eine Navigation im Stil eines Inhaltsverzeichnisses permanent einzublenden. Wenn so das Ziel lautet, kann man versuchen, es auf direktem Wege mit CSS zu erreichen.
Ein schönes Beispiel liefert das W3C auf seiner CSS-Homepage (Abb. 2). Die Abbildung stellt die Seite nach der Umstellung auf den Stil ‘Blue Shadows’ dar. Bis vor kurzem war dies der voreingestellte Stil. Nun muss der Benutzer ihn in Mozilla und Opera selbst auswählen; der Internet Explorer erlaubt eine solche Auswahl nicht. Die Blue Shadows zeigen auf der rechten Seite ein Navigationsmenü, dessen Position beim Scrolling unverändert bleibt. Der Hintergrund ist halb durchscheinend, damit der überdeckte Bereich der Seite sichtbar bleibt. Alternativ hätte man den rechten Rand der Seite vergrößern können, damit das Menü niemals Text überdeckt.
Der HTML-Code erweist sich als unspektakulär. Die ‘Magie’ steckt in den CSS-Anweisungen. Listing 3 enthält einen Auszug aus dem Stylesheet von Bert Bos. Vollständig steht es unter www.w3.org/Style/banner.css zur Verfügung.
Listing 3: W3C-Stylesheet
/* Copyright © 2003 W3CÆ (MIT, ERCIM, Keio). All Rights Reserved.
See http://www.w3.org/Consortium/Legal/ipr-notice.html#Copyright
Author: Bert Bos <bert@w3.org> */
div.banner { margin: 0; font-size: 90% /*smaller*/;
font-weight: bold; line-height: 1.1;
text-align: center;
position: absolute; /* Fallback if 'fixed' is not supported */
top: 2em; left: auto; width: 8.5em; right: 2em; }
/* WinIE6 gets confused by 'fixed', so hide it.
Selector trick courtesy of Johannes Koch, see
http://pixels.pixelpark.com/~koch/hide_css_from_browsers/
*/
div.endmatter>div.banner {
position: fixed; /* Overrides 'absolute' above */ }
Wesentlich ist die Angabe position: fixed. Da das den Internet Explorer verwirrt, wie es in dem Kommentar heißt, muss ein kleiner Trick herhalten, damit er wenigstens position: absolute benutzt. Dadurch scrollt das Menü nicht mit. Offensichtlich sorgt ein Bug in der Kaskaden- oder Spezifizitätimplementierung dafür, dass die zutreffende Regel position: fixed beim IE keine Anwendung findet.
CSS versus Tabellen
In den vergangenen Jahren schwelte ein steter Glaubenskrieg zwischen den HTML-Puristen und denen, die sich dem Web aus dem Desktop Publishing oder Design näherten. Viele vermissten im Web den Komfort, den Publishing-Programme längst bieten: Die freie Positionierung von Bild und Text auf einer Seite. Diese Lücke füllen einige HTML-Editoren und gestatten einen Seitenaufbau gemäß ‘What you see is what you get’-Prinzip (WYSIWYG). Hinter den Kulissen derart geschaffener Seiten, das heißt im Quellcode, offenbart sich meist ein furchteinflößendes Gebilde aus unzähligen, ineinander geschachtelten Tabellen, die irgendwie dafür sorgen, dass Objekte dort stehen, wo sie das Drag & Drop hindirigiert hat. Spätestens wenn jemand die Seite mit einem anderen Browser, bei anderer Auflösung, einem anderen System oder sonstiger Änderung der Ausgangsparameter betrachtet, zeigt sich eins deutlich: HTML ist dafür nicht geschaffen.
Selbst ohne starres Tabellenlayout erweisen sich Seiten, die mit Tabellen entworfen sind, nicht immer als ohne Tücken. Viele Benutzer bemängeln das horizontale Scrolling, das notwendig ist, wenn eine Tabelle die verfügbare Breite überschreitet. Eine Mindestbreite vorauszusetzen, ist unter den heterogenen Randbedingungen im Web aber kaum möglich. Nicht jeder Benutzer möchte den vollen Bildschirm für den Browser verwenden, unterschiedliche Schriftgrößen füllen den Platz unterschiedlich aus und so weiter.
Zum Vergleich sei hier ein einfaches Layout mit Tabellen und mit CSS realisiert. Listing 4 ist der kommentierten Übersetzung der HTML-4.01-Spezifikation entnommen. Die HTML-Seite verlangt noch nach Positionierung mit CSS. Die Anweisungen in Listing 5 sorgen für ein dreispaltiges Layout.
Listing 4: Layout mit Tabelle und CSS
<table>
<tr id="kopf"><th colspan="3"><h1>Die Märchen der Gebrüder Grimm</h1></th></tr>
<tr><td id="navigation">
<p><a href="allerleirauh.html">Allerleirauh</a></p>
...
</td>
<td id="haupttext">
<h2>Dornröschen</h2>
<p>Vorzeiten war ein König und eine Königin...
</td>
<td id="hinweise">
<p><a href="http://www.example.com/maerchen.html">andere Märchen</a></p>
<p><a href="maerchenbuecher.html">Märchenbücher</a></p>
<p><a href="maerchenlinks.html">Märchenlinks</a></p>
<p><a href="impressum.html">Impressum</a></p>
<p><a href="kontakt.html">Kontakt</a></p>
</td></tr>
</table>
________________________________________________________________________________
<body>
<div id="kopf">
<h1>Die Märchen der Gebrüder Grimm</h1>
</div>
<div id="navigation">
<p><a href="allerleirauh.html">Allerleirauh</a></p>
...
</div>
<div id="haupttext">
<h2>Dornröschen</h2>
<p>Vorzeiten war ein König und eine Königin...
</div>
<div id="hinweise">
<p><a href="http://andereMaerchen.de/">andere Märchen</a></p>
<p><a href="maerchenbuecher.html">Märchenbücher</a></p>
<p><a href="maerchenlinks.html">Märchenlinks</a></p>
<p><a href="impressum.html">Impressum</a></p>
<p><a href="kontakt.html">Kontakt</a></p>
</div>
</body>
Listing 5: Stile für CSS oben
#kopf { width: 99%; 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%; }
Die Ansicht im Browser zeigt zwei fast identische Ansichten - ein Indiz für die gute Umsetzung der (schlichten) Tabelle mit CSS.
Ist nun die CSS-Lösung besser als die auf Tabellen basierende Seite? Bei den Tabellen tritt das besagte Problem auf, dass bei zu geringem Platz horizontales Scrolling nötig ist. Wie verhält sich die CSS-Lösung? Abbildung 4 zeigt die Antwort.
Unvollkommene gestalterische Kontrolle
Bei der mit CSS formatierten Seite gleitet die rechte Spalte in die nächste Zeile ganz nach links (float: left). Auch Stylesheets lösen die Darstellungsschwierigkeiten nicht vollständig.
Vielleicht ist es an der Zeit für einige grundsätzliche Betrachtungen. Worum es hier im Grunde immer wieder geht, ist der Wunsch, die volle gestalterische Kontrolle über die Seitenansicht auf der Clientseite zu haben. Das funktioniert durchaus - ein passendes Datenformat ist etwa PDF. Wenn solche Absichten, mit Tabellen realisiert, zu genannten unerwünschten Effekten führen, sind ‘natürlich’ die Tabellen schuld. Die Umstellung auf CSS im obigen Listing zeigt, dass das gewählte Mittel nicht verantwortlich für die Schwierigkeiten ist.
HTML-Tabellen sind ein gutes Werkzeug - zur Strukturierung von tabellarischen Daten. Und wer einen Blick in die aktuelle Version von CSS wirft, findet dort ein langes Kapitel über Tabellen. CSS2 beschreibt des Weiteren, wie man beliebig ausgezeichnete Daten als Tabelle deklariert (siehe unten). Dies allein sollte zeigen, dass die Aussage: ‘Nimm CSS statt Tabellen!’ ohne weiteres keine Berechtigung hat.
Cascading Style Sheets sind nicht als Ersatz für Tabellen gedacht, was sich unter anderem daran zeigt, dass CSS die Gestaltung von Tabellen steuern können. Ein Listing soll davon einen Eindruck vermitteln. Gegeben seien folgende Tabelle:
<table>
<tr><th>Ferngespräche</th></tr>
<tr><td> 1,30</td></tr>
<tr><td> 2,50</td></tr>
<tr><td> 10,80</td></tr>
<tr><td> 111,01</td></tr>
<tr><td> 85,</td></tr>
<tr><td> 90</td></tr>
<tr><td> ,05</td></tr>
<tr><td> ,06</td></tr>
</table>
und das zugehörige Stylesheet:
body { background: white; }
td { text-align: ",";
padding: 1em; }
th { padding: 1em; }
td:before {
content: "?"; }
table tr {
border-top: solid; }
table {
border-collapse: collapse;
border: dotted; }
Die Darstellung in den Browsern zeigt die per CSS veränderten Tabellenrahmen, wobei der Internet Explorer nur teilweise mitspielt. Alle drei Browser verweigern die Ausrichtung der Spalte am Dezimalkomma (siehe Abb. 5).
CSS formatieren Tabellen aus HTML und XML
Neben der Gestaltung von HTML-Tabellen gestatten es die CSS, Elemente als Tabelle zu deklarieren. Das Referenz-Stylesheet für HTML 4 nimmt beispielsweise die folgenden Einstellungen vor:
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 }
Natürlich ist es nicht notwendig, diese Anweisungen in Stylesheets für HTML einzufügen. Die Browser besitzen diese oder eine vergleichbare Implementierung für HTML-Tabellen; sie dürfen die CSS-Einstellungen in diesem Fall sogar ignorieren.
Handelt es sich nicht um HTML, sondern um XML, gibt es kein ‘normales’ (vordefiniertes) Verhalten der Browser mehr. Tabellarische Daten können auf eine Art und Weise strukturiert sein, die der Natur der Daten entgegenkommt. Als Beispiel diene hier eine der wichtigsten Leidenschaften des deutschen Mannes: der Fußball. Das Adrenalin des letzten Spiels ist noch nicht verflogen, da fällt der kollektive Blick von Fußballdeutschland auf die Tabelle - in diesem Fall der Bundesliga. Eine nahe liegende Strukturierung mit XML demonstriert Listing 6.
Listing 6: bundesliga.xml
<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="liga.css" type="text/css"?>
<!DOCTYPE liga [
<!ELEMENT liga (pos+) >
<!ELEMENT pos (verein, punkte, tore) >
<!ELEMENT verein (#PCDATA) >
<!ELEMENT punkte (#PCDATA) >
<!ELEMENT tore (#PCDATA) >
]>
<liga>
<pos>
<verein>Bayern München</verein>
<punkte>29</punkte>
<tore>29:14</tore>
</pos>
<!-- 16 weitere Vereine -->
<pos>
<verein>FC Kaiserslautern</verein>
<punkte>7</punkte>
<tore>12:22</tore>
</pos>
</liga>
Zweifellos ergibt es mehr Sinn, den Verein <verein> zu nennen statt <th>. Aber wie sag ichs dem Browser? Für diesen Fall sind die CSS-Eigenschaften aus dem vorangegangenen Listing nützlich. Denn es handelt sich hier zwar um eine Tabelle, aber noch weiß es der Browser nicht. Das ändert sich mit den CSS-Anweisungen aus Listing 7. Die Darstellung funktioniert ganz gut, mit marginalen Unterschieden zwischen Mozilla und Opera, allerdings mit künstlerischen Abweichungen beim Explorer.
Listing 7: Liga.css
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; }
punkte { display: table-cell;
padding: 1em; background: lightblue; }
tore { display: table-cell;
padding: 1em; background: lightgreen; }
Zu beachten ist im XML-Fall, wie ein Dokument mit dem gewünschten Stylesheet in Verbindung gebracht wird. Da es kein dediziertes Element - wie link im Falle von HTML - dafür gibt, geschieht die Verbindung anders: die Verarbeitungsanweisung <?xml-stylesheet href="liga.css" type="text/css"?> stellt die Verbindung gemäß der diesbezüglichen W3C-Spezifikation [1] her.
Ein weiterer Test mit einem anderen XML-Dokumenttyp sollte zeigen, was die Browser generell mit XML anfangen können. Als Test sollten jene W3C-Texte herhalten, die unter anderem in XML herausgegeben werden. Sie sind gemäß einer DTD (Dokumenttypdefinition) ausgezeichnet, die XMLSpec-DTD [2] heißt. Sie ist maßgeschneidert für die technischen Berichte des W3C und besitzt fast keine Gemeinsamkeiten mit HTML. Folglich kann ein Browser wenig mit den Auszeichnungen anfangen und benötigt unbedingt ein Stylesheet.
Einen Eindruck von den Auszeichnungen der XMLSpec-DTD gibt der Ausschnitt aus der deutschen Übersetzung von XML 1.0 in Listing 8.
Listing 8: XML-Spezifikation
...
<scrap lang="ebnf">
<head>Zeichendaten</head>
<prod id="NT-CharData">
<lhs>CharData</lhs>
<rhs>[^<&]* - ([^<&]* ']]>'
[^<&]*)</rhs>
</prod>
</scrap>
</div2>
<div2 id="sec-comments">
<head>Kommentare</head>
<p><termdef id="dt-comment"
term="Kommentar"><term>Kommentare</term> dürfen
innerhalb des Dokuments an beliebiger Stelle
außerhalb des übrigen <termref
def="dt-markup">Markup</termref>stehen. Darüber
hinaus dürfen sie innerhalb der
Dokumenttyp-Deklaration an den von der Grammatik
erlaubten Stellen stehen. Sie sind kein Bestandteil
der <termref def="dt-chardata">Zeichendaten</termref>
eines Dokuments. Ein XML-Prozessor kann, muss aber
nicht, der Anwendung eine Möglichkeit
einräumen, den Text eines Kommentars zu
lesen. <termref def="dt-compat">Zwecks
Kompatibilität</termref> darf die Zeichenkette
<quote><code>--</code></quote> (zwei Trennstriche)
nicht innerhalb eines Kommentars erscheinen.</termdef>
<phrase diff="add"><loc role="erratumref"
href="http://www.w3.org/XML/xml-19980210-errata#E63">
[E63]</loc> Parameter-Entity-Referenzen werden innerhalb
von Kommentaren nicht erkannt.</phrase></p>
<scrap lang="ebnf">
<head>Kommentare</head>
<prod id="NT-Comment">
<lhs>Comment</lhs>
<rhs>'<!--' ((
<nt def="NT-Char">Char</nt> - '-') | ('-'
(<nt def="NT-Char">Char</nt> - '-')))* '-->'</rhs>
</prod>
</scrap>
<p>Ein Beispiel für einen Kommentar:</p>
<eg><!&como; Deklaration für <head>
& <body> &comc;></eg> <p diff="add"><loc
role="erratumref"
href="http://www.w3.org/XML/xml-19980210-errata#E27">[E27]</loc>Beachten
Sie, dass die Grammatik nicht erlaubt, einen Kommentar
durch <code>---></code> zu beenden. Das folgende
Beispiel ist daher <emph>nicht</emph> wohlgeformt.</p>
<eg diff="add"><!-- B+, B, or B ---></eg>
...
Die publizierte HTML-Darstellung dieses Textes ist das Ergebnis einer Transformation von XMLSpec nach HTML. An die Stelle der Transformation tritt nun die Formatierung mit CSS. Folgende Zeile verbindet das Dokument mit dem Stylesheet: <?xml-stylesheet href="xmlspec.css" type="text/css"?> Für diesen Test sollte die Datei xmlspec.css eine Darstellung erreichen, die der Darstellung der HTML-Version mit dem üblichen W3C-Stylesheet für Recommendations nahe kommt. In weiten Teilen kann sich das Ergebnis sehen lassen. Einen Eindruck vermittelt Abbildung 7.
Die Formatierung der rechten Seite der Abbildung führt ein Ausschnitt aus xmlspec.css durch (siehe Listing 9). Einstellungen für Elemente höherer Ebene (etwa linke und rechte Ränder sowie der Hintergrund und die Schriften) sind hier nicht gezeigt.
Listing 9: xmlspec.css
div1 > head
{ color: #005A9C; background: white; font-size: 170%; }
div2 > head
{ color: #005A9C; background: white; font-size: 140%; }
loc[role="erratumref"], *[diff="del"] { display: none; }
scrap { display: table; font-family: monospace;
padding: 2%; background: #ccccff ;
border: solid #aaaaaa; padding: 2%; }
prod { display: table-row; margin-left:2em; }
scrap head
{ display: table-caption; margin-top;1em;
font: italic 100% sans-serif; }
lhs { display: table-cell; }
lhs:after { content: " "; }
rhs:before { content: " ::= "; }
rhs { display: table-cell; }
rhs + rhs:before { content: " "; }
nt { display: inline; }
eg { font-family: monospace; white-space: pre;
background-color: #d5dee3; border-top-width: 4px;
border-top-style: double; border-top-color: #d3d3d3;
border-bottom-width: 4px; border-bottom-style: double;
border-bottom-color: #d3d3d3;
padding: 4px; margin: 0em; }
term { font-weight: bolder; }
termdef:before { content: "[Definition: "; }
termdef:after { content: "] "; }
Auf den ersten Blick ist das Ergebnis zufrieden stellend. Es zeigen sich einige Schwächen, die auch die Formatierung von HTML-Dokumenten mit CSS betreffen. Es fehlen beispielsweise die Nummerierungen von Überschriften und Produktionsregeln (Element prod). Das Thema Nummerierung hat schon der erste Teil des Tutorials diskutiert. Solche Haken sind aber ‘lediglich’ durch die noch unvollständigen CSS-Implementierungen in den gängigen Browsern begründet. Schwer wiegender sind Mängel, die sich durch CSS prinzipiell nicht beheben lassen.
So erlaubt die XMLSpec-DTD eine Reihe von Elementen, die auf ein anderes Element innerhalb des Dokuments verweisen. An der Stelle des Auftretens einer solchen Referenz soll ein Stück Text erscheinen, das aus dem Inhalt des referenzierten Elements stammt. Man stelle sich die Referenz einer Überschrift vor. Eine Modellierung in XML könnte so aussehen: siehe <ref idref="id_der_ueberschrift">. Die CSS sehen nicht vor, den Inhalt der betreffenden Überschrift an der ref-Stelle einzufügen. Eine solche Operation bleibt der Transformation von XML-Dokumenten, etwa mit XSLT, vorbehalten.
CSS, XML und Hyperlinks
Zwei weitere, schwer wiegende Stolpersteine betreffen die Darstellung von Bildern sowie Hyperlinks in XML-Dokumenten. In Dokumenten der XMLSpec-DTD nehmen Hyperlinks beispielsweise folgende Gestalt an:
<loc href="http://www.w3.org/XML/1998/06/xmlspec-report-v21.htm">.
Es gibt keine Möglichkeit in CSS, etwa display: hyperlink oder Ähnliches zu definieren. Das Element bleibt deshalb in der Browseransicht ein inaktives. Gleiches gilt für Bilder in XML-Dokumenten. Sie lassen sich nicht im Browser darstellen. Auf Bilder und Hyperlinks in Web-Dokumenten zu verzichten, ist allerdings eine zu große Einschränkung. Fairerweise sei gesagt, dass XLink den hier den CSS vorgeworfenen Mangel behebt. Nach W3C-Lesart sind Hyperlinks - und dazu gehören im Dokument referenzierte Bilder - Aufgabe von XLink, nicht von CSS. Die Kombination von XML, CSS und XLink sollte daher den Webautor in die Lage versetzen, XML zum Browser zu schicken, zu formatieren und mit anderen Dokumenten zu verlinken. Sollte? Und was halten die Browser davon? Da muss ein Test her ...
Diesem Zweck dient das Listing eines unvollständigen Dokuments aus der XLink-Spezifikation, ergänzt um einige Zeilen, die es zu einer kompletten Instanz inklusive DTD mutieren lassen (siehe Listing 8).
Wesentlich ist in diesem Fall das Element des Typs studentlink. Solche Elemente sind vom XLink-Typ ‘simple’. Solche einfachen XLinks entsprechen am ehesten den a-Hyperlinks von HTML. Neben xlink:type ist xlink:href wichtig. Wie bei dem Elementtyp a von HTML, enthält xlink:href einen URI, der das Ziel des Hyperlinks referenziert. Für die Funktionsweise des Dokuments sollte das genügen, aber ein paar Verzierungen mit CSS machen den Text ansehnlicher und den Link blau und unterstrichen (Listing 11).
Listing 10: XLink-Beipiel
<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="xlinktest.css" type="text/css"?>
<!DOCTYPE doc [
<!ELEMENT doc (p+)>
<!ATTLIST doc xmlns:xlink CDATA #FIXED "http://www.w3.org/1999/xlink">
<!ELEMENT p (#PCDATA | studentlink)*>
<!ELEMENT studentlink ANY>
<!ATTLIST studentlink
xlink:type (simple) #FIXED "simple"
xlink:href CDATA #IMPLIED
xlink:role CDATA #FIXED "http://www.example.com/linkprops/student"
xlink:arcrole CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xlink:show (new
|replace
|embed
|other
|none) #IMPLIED
xlink:actuate (onLoad
|onRequest
|other
|none) #IMPLIED>
]>
<doc xmlns:xlink="http://www.w3.org/1999/xlink">
<p>... und
<studentlink xlink:type="simple"
xlink:href="http://www.example.com/students/pat.xml">Pat
Jones</studentlink> ist in der Studentenverbindung sehr beliebt.</p>
</doc>
Listing 11: CSS für XLink
doc { display: block; margin: 2em;
background: white; font-size: 18pt; }
p { display: block; }
studentlink { display: inline;
color: blue; text-decoration: underline; }
studentlink:hover { background: blue;
color: white; text-decoration: none; }
Darstellungstests mit den Browsern lassen einmal mehr Mozilla herausragen. Abbildung 8 zeigt das Dokument in Mozilla, und der Link funktioniert. In Opera ist die :hover-Regel zwar erfolgreich, das heißt bei Überfahren mit dem Mauszeiger ändern sich Farbe und Hintergrund, einen anklickbaren Link sucht man aber vergeblich. Der Internet Explorer 6 will nichts von all dem ‘wissen’.
Was die Kombination von XML und XSLT bietet, erreichen XML + CSS nicht. CSS können keinesfalls ein Ersatz für XSLT sein. Nur wenn deren Mächtigkeit nicht benötigt wird, sind CSS auf der Client-Seite vorzuziehen. Bei den Test war die Darstellung mit CSS erheblich schneller als eine Transformation mit XSLT. Einschränkend sei hier gesagt, dass Mozilla bekannt für eine langsame Transformation ist. Erst wenn mehr Browser XML und CSS unterstützen, lassen sich repräsentative Vergleiche anstellen. Dass die Darstellung mit CSS schneller bleiben wird als die Transformation mit XSLT (der oft noch CSS-formatiertes HTML nachfolgt), ist nicht gerade eine gewagte Erwartung.
Gelegentlich kann die zunehmende Unterstützung von XML und damit zusammenhängender Techniken zu nicht eindeutigen Situationen bei der Interpretation von Datentypen führen. So ist ein XHTML-Dokument auch ein XML-Dokument. Folglich sollte die Einbindung von externen Stylesheets sowohl per <link href="" type="text/css"> als auch per <?xml-stylesheet href="" type="text/css"?> möglich sein. Schwierig wird es mit internen Stylesheets, wenn das Dokument als XML zu interpretieren ist. Eine XML-Anwendung kennt die Bedeutung von <style>...<style> nicht.
Die Lösung ist einfach: Das style-Element bekommt eine ID, etwa <style id="internalstyle">...<style>, und die Verarbeitungsanweisung verweist mit einem fragmentarischen URI darauf: <?xml-stylesheet href="#internalstyle" type="text/css"?>
Ausblick
Im dritten Teil des Tutorials soll es darum gehen, wie das wachsende Interesse an Zugänglichkeit (Barrierefreiheit, Accessibility) mit CSS umgesetzt werden kann. Des Weiteren: Wie man in CSS Regeln für andere Ausgabemedien als den Bildschirm formulieren kann. Und schließlich folgt ein Ausblick auf CSS3, die neue Version der Cascading Style Sheets, die am Horizont erkennbar ist.
Stefan Mintert
ist XML-Berater und Herausgeber der bei Addison-Wesley erscheinenden edition W3C.de
Christine Kühnel hat bei den Tabellen viel geholfen.
Literatur
[1] Verknüpfen von Stylesheets mit XML-Dokumenten Version 1.0, Deutsche Übersetzung
[2] Eve Maler; XMLSpec-DTD
iX-TRACT
- CSS eignen sich für frame-lose Menüs, sind aber kein Ersatz für Frames
- Die mit Tabellen verbundenen Probleme werden mit CSS nicht gelöst
- Formatierung von XML mit CSS funktioniert gut, allerdings nur in wenigen Browsern. Dank XLink sind sogar Hyperlinks möglich.
(hb)
