vorheriges KapitelInhaltsverzeichnisStichwortverzeichnisFeedbacknächstes Kapitel


Woche 1

Tag 4

Einbindung von Scripten und Style Sheets in Webseiten

Sheets in Webseiten

Gestern haben Sie wichtige Grundlagen zum Erstellen einer Webseite kennen gelernt. Dazu zählen der Aufbau von Steueranweisungen in HTML und das Grundgerüst einer Webseite. Heute wollen wir zu der Integration von JavaScript in Webseiten kommen. Darüber hinaus sollen auch Referenzen auf Style Sheets zur Sprache kommen, denn dieser Vorgang läuft sowohl technisch als auch logisch ziemlich identisch ab. Es gibt bei beiden Vorgängen die Möglichkeit,

Wir werden in diesem Tagesabschnitt einige HTML-, Style-Sheet- und JavaScript-Anweisungen verwenden, die heute noch nicht näher besprochen werden. Das holen wir aber ab morgen und dann sukzessive nach. Wir benötigen diese Anweisungen nur, damit die Scripte und Style Sheets nicht in Verbindung mit einer leeren Webseite agieren und Sie die hier zu demonstrierenden Effekte nicht sehen können.

Die Einbindung von Scripten in eine Webseite

Im Prinzip ist es schon sehr lange möglich, in HTML Scripte zu integrieren. Aber erst seit HTML 3.2 können Scripte über standardisierte Wege in Webseiten eingebunden werden. Sie werden dazu entweder über genormte Schritte als Klartext direkt in HTML-Seiten notiert oder dort auf normierte Weise über eine externe Datei referenziert. Dazu gibt es im Wesentlichen den standardisierten HTML-Tag <SCRIPT>, der den Beginn eines Script-Containers definiert. Das Innere des Containers wird gegenüber dem HTML-Interpreter geschützt, während der Tag selbst samt seiner Attribute noch Bestandteil des HTML-Codes ist. Im Inneren des Containers wird bei einem entsprechend Script-fähigen Browser der Script-Interpreter aktiv.

Man kann sich das so vorstellen (ein Vergleich mit einer Firma): Wenn eine Webseite geladen wird, werden die jeweiligen Zeichen so lange von oben nach unten von der HTML-Abteilung bearbeitet, bis der <SCRIPT>-Tag entdeckt wird. Daraufhin wird der Fall an die zuständige Script-Abteilung weitergeleitet, die den Vorgang so lange bearbeitet, bis das Ende des <SCRIPT>-Containers erreicht wird. Anschließend übergibt die Script-Abteilung den Vorgang wieder an die HTML-Abteilung, welche den Hergang weiter bearbeitet.

Eine Script-Referenz kann im Prinzip an jeder Stelle in der Webseite notiert werden, so lange sie innerhalb des äußersten HTML-Containers - dem vom <HTML>-Tag gebildeten Block - steht. Am Beginn des Body-Teils der Seite, am Ende des Body, mitten drin oder gar zwischen Header und Body. Meist wird sie jedoch im Header der Seite oder direkt dahinter zu finden sein. Das hat mehrere Gründe. Einmal ist es bezüglich. einer Wartung leichter, wenn man die Informationen zusammen verwaltet, die logischen zusammengehören. Logisch gehören Scripte nicht zu den darstellbaren HTML- Elementen. Deshalb werden bei einer Platzierung im Header oder direkt dahinter Layout und Hintergrundaktionen besser getrennt. Nebenbei wird das Auffinden von Scripten erleichtert, wenn Code immer zentral außerhalb des meist recht umfangreichen Body notiert wird. Das entscheidende Argument ist jedoch der Ladevorgang für eine Webseite - von oben nach unten.

Um ein wenig vorzugreifen: Scriptschritte können direkt in den Scriptcontainern notiert werden. Solcher Code wird ausgeführt, wenn die entsprechenden Anweisungen beim Laden der Webseite vorgefunden werden. Der Code kann damit auch nur genau einmal ausgeführt werden. Anwendungen für eine solche Vorgehensweise sind hauptsächlich Initialisierungen oder dynamische Generierungen von statischen Webseiten.

Der andere Weg zur Notation von Scripten ist der, dass Anweisungen über Funktionen zusammengefasst und dann gemeinsam über einen Namen aufgerufen werden. (Es müssen nicht unbedingt mehrere Anweisungen zusammengefasst werden. Es kann auch nur eine Anweisung in einer Funktion notiert werden.) So als Funktion gekennzeichneter Code wird erst dann ausgeführt, wenn an irgendeiner anderen Stelle im HTML-Code der Name der Funktion aufgerufen wird. Funktionen sind im gesamten Dokument verfügbar und können bei Bedarf immer wieder aufgerufen werden.

Wenn nun eine JavaScript-Funktion beim Laden einer Webseite direkt am Anfang des Body benötigt und sie dort aufgerufen wird, ihre konkrete Programmierung aber erst am Ende der Webseite zu finden ist, kann es zu Problemen kommen. Besonders im Internet, wo die Übertragung einer Webseite immer wieder ins Stocken kommen kann. Deshalb notiert man die Programmierung einer Funktion besser vor deren Aufruf. (Obwohl es wirklich nicht zwingend ist. Wenn der Quelltext da ist, findet der Interpreter bei einem Aufruf auch im Quelltext weiter unten notierte Funktionen.)

Der <SCRIPT>-Tag kann ohne irgendwelche Attribute verwendet werden. Etwa so:

<SCRIPT>
  ... irgendwelche Script-Anweisungen
</SCRIPT>

In diesem Fall wird der HTML-Interpreter beim Antreffen des Beginn-Tags die Verantwortung an den Default-Scriptinterpreter des Browsers abgeben. In der Regel ist das ein JavaScript-Interpreter, aber darauf kann man sich nicht verlassen. Man sollte sich immer verdeutlichen, dass ein Browser verschiedenste Script- Interpreter aufrufen kann, sofern sie ihm zur Verfügung stehen. Um die verwendetet Scriptsprache explizit anzugeben, wird der <SCRIPT>-Tag um das Attribut language (Sprache) erweitert, welches bestimmt, um welche Scriptsprache es sich in dem nachfolgenden Container handelt.

Die Syntax

<SCRIPT language="JavaScript">

informiert den Browser, dass innerhalb des Containers ein JavaScript folgt. In einigen Browserversionen kann sogar der ursprüngliche Name von JavaScript - LiveScript - stehen. Dies ist aber selten sinnvoll und wird nicht von allen Browsern unterstützt. Genauso ist die Angabe von JScript zu sehen.

Was aber gelegentlich Sinn macht, ist die Angabe einer konkreten Version von JavaScript. Dies ist zweckmäßig, um Fehlern mit inkompatiblen Browsern vorzubeugen. Wenn einfach nur die Sprache allgemein spezifiziert wird, wird jeder Browser, der diese Sprache versteht, das Script abarbeiten. Sofern dann dort Befehle aus einer Sprachversion genutzt werden, die der Browser nicht unterstützt, kann es zu Komplikationen kommen. Etwa die Kombination JavaScript-Befehle der Version 1.2 und als Browser der Internet Explorer 3.0 oder JavaScript-Befehle der Version 1.3 und Netscape Navigator 3. Oder explizite JavaScript-1.2-Befehle in Verbindung mit dem Opera 3.6. Über die explizite Versionsangabe kann verhindert werden, dass die betroffenen inkompatiblen Browser die Scripte ausführen. Bei JavaScript werden die Versionen so angegeben:

<SCRIPT language ="JavaScript1.0"> 
<SCRIPT language ="JavaScript1.1">
<SCRIPT language ="JavaScript1.2">
<SCRIPT language ="JavaScript1.3">

Wenn man das Verhalten mit verschiedenen Script- Containern für verschiedenartige Browser koppelt, kann man sehr qualifiziert differenzieren. Wir werden im Rahmen unserer Beispiele auf die explizite Angabe der JavaScript-Version verzichten, aber ein Beispiel zum Differenzieren von Browsern und der JavaScript-Version zeigen.

Die Versionsnummer muss ohne Leerzeichen angefügt werden! Es spielt jedoch keine Rolle, ob Javascript oder JavaScript (meist gewählte Variante) oder javascript als Wert genommen wird, d.h. Groß- und Kleinschreibung sind hier egal. Das ist klar, wenn man sich vergegenwärtigt, dass diese Anweisungen noch zu HTML zählen. Erst in den konkreten im Container notierten Anweisungen wird Groß- und Kleinschreibung eine Rolle spielen - dort gilt JavaScript-Syntax.

Für den Internet Explorer kann man die Syntax <SCRIPT language= "JScript"> angeben, wenn explizit die Micorsoft-JavaScript-Variante verwendet werden soll. Dann aber grenzt man die Netscape-Anwender aus, was selten notwendig ist. Man kann allerdings dieses Verhalten nutzen, um Netscape- und Microsoft-Welten zu trennen, was oft wegen der Inkompatibilitäten sinnvoll ist. Wir werden darauf zurückkommen.

Man ist bei der Angabe einer Scriptsprache wie gesagt nicht auf JavaScript oder Abarten davon beschränkt. Jede im Browser unterstützte Scriptsprache lässt sich nach dem gleichen Schema referenzieren. Die Angabe <SCRIPT language="VBScript"> legt beispielsweise VBScript als Scriptsprache in dem Container fest. Die konkrete Syntax für den Script-Container sieht also schematisch immer so aus:

<SCRIPT language="[Sprache]">
  ... irgendwelche Script-Anweisungen
</SCRIPT>

Der <SCRIPT>-Container beinhaltet also im Inneren JavaScript-Anweisungen, mit denen ein HTML- Interpreter nichts anfangen kann. Wenn ein Browser JavaScript versteht, wird von diesem deshalb der Vorgang an den JavaScript-Interpreter weitergegeben, aber nicht-JavaScript-fähige Browser haben mit dem in dem Script-Container notierten Code Probleme. Zwar wird der <SCRIPT>-Tag samt Abschluss-Tag auf Grund des Prinzips der Fehlertoleranz von diesen ignoriert. Da er jedoch nicht verstanden wird, werden die darin notierten Script-Befehle als HTML-Code interpretiert (der Browser weiß ja nichts von Scripten). In der Regel heißt dies, die Scriptanweisungen werden als Klartext verstanden, der einfach in den Anzeigebereich des Browsers geschrieben wird. So gut wie nie wünschenswert. Deshalb steht normalerweise als Vorsichtsmaßnahme bei einem Script-Container direkt nach dem einleitenden <SCRIPT>-Tag ein öffnendes HTML-Kommentarzeichen (<!--) - siehe dazu Tag 3. Dieser HTML-Kommentarcontainer wird unmittelbar vor dem abschließenden Tag </SCRIPT> mit dem entsprechenden HTML-Kommentarendezeichen (-->) wieder geschlossen. Dadurch steht der gesamte Script- Code innerhalb eines HTML-Kommentars. Dies ist wie gesagt nicht zwingend, aber sicherer für den Fall, dass ein Browser die Seite lädt, der keine JavaScripte interpretieren kann.

Der Netscape Navigator reagiert beim Einschluss von Scripten in HTML-Kommentare in manchen Versionen ziemlich gewöhnungsbedürftig. Der innerhalb des <SCRIPT>-Containers aktive Script-Interpreter kann mit der Zeichenkombination für das Ende eines HTML- Kommentars nichts anfangen. Genau genommen erkennt er nicht, dass es eine HTML-Anweisung ist, sondern interpretiert -- als JavaScript-Operator (diesen Operator gibt es) und erzeugt damit einen Fehler. Eine unverständliche Eigenheit, denn der Internet Explorer kommt mit dieser Situation hervorragend zurecht. Für den Navigator muss das Ende-Zeichen des HTML- Kommentars vor dem Script-Interpreter mit JavaScript- Kommentarzeichen versteckt werden (das lernen wir noch genauer kennen). Die Anweisung vor dem Ende des <SCRIPT>-Containers sieht dann so aus:

//-->

Das auch gegen JavaScript-unfähige Browser geschützte Grundgerüst entsprechend so:

<SCRIPT language="[Sprache]">
<!--
  ... irgendwelche Script-Anweisungen
//-->
</SCRIPT>

Die Problematik betrifft nicht die Browser, wo JavaScript nur deaktiviert ist. Diese werden den Container schon erkennen, nur die darin enthaltenen Anweisungen nicht ausführen.

Für die JavaScript-unfähigen Browser sollte man normalerweise dem <SCRIPT>-Container einen weiteren Container folgen lassen:

<NOSCRIPT>
Sorry, diese Seite verwendet JavaScript!
</NOSCRIPT>

Der Text (der natürlich frei wählbar ist) wird dabei explizit nicht in HTML-Kommentare eingeschlossen. Hier ist die Situation ja eine andere. JavaScript-fähige Browser werden den Tag erkennen und den darin enthaltenen Inhalt ignorieren. JavaScript-unfähige Browser werden den Tag genauso wenig kennen, wie sie den <SCRIPT>-Tag kennen. Das ist aber genau so sinnvoll. Dies bedeutet doch, dass er ignoriert und nachfolgender Text einfach in der Webseite angezeigt wird. Bingo! Das soll ja genau so sein.

Führen wir nun ein kleines Beispiel durch, das ein Script verwendet. Die Anweisung wird direkt beim Laden der Webseite ausgeführt.

Beispiel 1:

Geben Sie im Editor den nachfolgenden Quelltext ein:

<HTML>
<HEAD>
<SCRIPT language ="JavaScript">
  alert(navigator.appName);
</SCRIPT>
<NOSCRIPT>
Sorry, diese Seite verwendet JavaScript!
</NOSCRIPT>
</HEAD>
<BODY>
</BODY>
</HTML>

Speichern Sie den Text bitte unter dem Dateinamen Browser.html ab und schauen Sie sich die Datei im Browser an. Experimentieren Sie mit verschiedenen Browsern.

Abbildung 4.1:  Die Anzeige im Navigator beim Laden der Webseite

Die alert()-Anweisung öffnet ein Mitteilungsfenster, wo die Browserversion angezeigt wird. Diese wird über navigator.appName abgefragt.

Ein weiteres Beispiel soll die alert()-Anweisung in einer Funktion »einpacken« (die näheren Hintergründe zu Funktionen bzw. Methoden folgen an späteren Tagen) und diese dann erst bei einem Klick auf eine Schaltfläche in der Webseite aufrufen (auch dieses wird demnächst einen großen Raum einnehmen). Beim Laden der Seite wird die Funktion nicht ausgeführt, was viel mehr Flexibilität erlaubt.

Wir sollten nun die Seite einmal testen, wenn keine JavaScript-Unterstützung vorhanden ist. Laden Sie diese in einen älteren Browser oder deaktivieren Sie die JavaScript-Unterstützung in ihrem Browser. Im Netscape Navigator deaktivieren Sie beispielsweise die JavaScript-Unterstützung unter Bearbeiten, Einstellungen..., Erweitert.

JavaScript-fähige Browser, bei denen die JavaScript-Unterstützung nur deaktiviert ist, werden sich bezüglich des <NOSCRIPT>-Tags genauso wie JavaScript-unfähige Browser verhalten. Sie können das gerne testen. Wir werden in den folgenden Beispielen bis auf wenige Ausnahmen auf den <NOSCRIPT>-Container verzichten.

Beispiel 2:

Geben Sie im Editor den nachfolgenden Quelltext ein:

<HTML>
<SCRIPT language="JavaScript">
function testeBrowser()
{
  alert(navigator.appName);
}
</SCRIPT>
<BODY>
<FORM>
<INPUT type="button" value="Prüfe" onClick="testeBrowser()">
</FORM>
</BODY>
</HTML>

Abbildung 4.2:  Die Anzeige im Navigator bei deaktiviertem JavaScript

Abbildung 4.3:  Deaktivieren von JavaScript im Navigator

Speichern Sie den Text bitte unter dem Dateinamen Browser2.html ab und schauen Sie sich die Datei im Browser an. Klicken Sie auf den Button und experimentieren Sie mit verschiedenen Browsern.

Abbildung 4.4:  Klick auf den  Button führt die JavaScript-Funktion aus

Die Anzahl der Scriptcontainer in einer Webseite ist nicht beschränkt. Es lassen sich mehrere <SCRIPT>-Container in einem Dokument platzieren. Es gibt ein paar sinnvolle Anwendungen, warum nicht alle Scripte in einem Container an einer Stelle notiert werden. Wichtigster Grund ist die Verwendung von verschiedenen Scriptsprachen oder -versionen innerhalb einer Webseite. Oder man möchte Funktionalitäten aus verschiedenen Quellen in einer Webseite nutzen. Eine weitere Anwendung für verschiedene <SCRIPT>-Container ist die damit mögliche logische Strukturierung von Inhalten. Richtig sinnvoll sind aber mehrere <SCRIPT>-Container vor allem in Verbindung mit der externen Notation von Scripten, auf die wir jetzt eingehen wollen.

Externe Notation von Scripten

Neben der Notation von Scripten in den HTML- Quelltext selbst lassen sich JavaScripte unter HTML 4.0 und seit JavaScript in der Version 1.1 in einer oder mehreren externen Dateien ablegen. In dem Fall enthält nicht die Webseite den konkreten JavaScript-Code, sondern die externe(n) Datei(en). In der Webseite wird nur der Aufruf einer Funktion durchgeführt. Um die Verbindung zwischen der Webseite und einer externen Datei zu schaffen, muss in der Webseite der Weg zu dieser Datei angegeben werden. Dies erfolgt mit einer Referenz, welche dann die Möglichkeit zum Laden des JavaScript-Codes eröffnet, wenn eine Funktion aufgerufen wird.

Die Referenz sieht für Scripte allgemein wie folgt aus:

<SCRIPT language="[Sprache]" src="[URL der separaten Script-Datei]">
</SCRIPT>

Im Fall von JavaScript gilt also das:

<SCRIPT language="JavaScript" src="[URL der separaten JavaScript-Datei]">
</SCRIPT>

Mit dem Attribut src wird der URL der separaten Datei angegeben. Dabei gelten beim Referenzieren von separaten JavaScript-Dateien die üblichen Regeln für URLs. Die separate JavaScript-Datei mit dem Quellcode muss wie HTML-Dateien auch eine reine ASCII-Datei sein und ausschließlich JavaScript-Code enthalten. Es gibt kein Grundgerüst, wie bei einer HTML-Seite. Üblich ist die Dateierweiterung .js, aber das ist nicht zwingend. Optional kann das Attribut type="text/JavaScript" angegeben werden, was einen so genannten Mime-Typ spezifiziert.

MIME steht für Multipurpose Internet Mail Extensions und bedeutet einen Internet-Standard zur Spezifizierung von Dateitypen bei der Kommunikation zwischen Servern und Browser im World Wide Web. Sowohl der Server als auch der Browser kennt bestimmte Dateitypen. Beim Übertragen vom Server zum Browser wird über das HTTP-Protokoll der MIME-Typ mit übertragen. Aufgrund seiner Liste mit MIME-Typen kann der Browser eine Datei eines bekannten Typs korrekt behandeln. Werden unbekannte Dateitypen geladen, kann das Programm nicht direkt damit umgehen, sondern muss die Datei speichern oder über zusätzliche Informationsquellen (etwa einen Benutzerdialog) nach der Behandlungsweise forschen.

Die Verwendung von MIME-Typen umgeht zugleich das Problem, dass viele Dateierweiterungen von mehreren Programmen bearbeitet werden können (etwa .bmp, was unter Windows von zahlreichen Grafikprogrammen bearbeitet werden kann). MIME-Typen geben eindeutig das zu verwendende Programm an. MIME-Typen werden nach folgendem Schema angegeben:

Hauptkategorie/Unterkategorie

Hauptkategorien sind etwa text, image oder audio. Unterkategorien von text sind beispielsweise plain (eine reine Textdatei) oder html (eine HTML-Datei). Unterkategorien von image sind beispielsweise gif oder jpeg. Im Anhang finden Sie eine Tabelle mit üblichen MIME-Typen.

Der <SCRIPT>-Container muss für den Fall einer Einbindung von externen Dateien leer sein. Alle JavaScript-Anweisungen befinden sich in der referenzierten Datei oder in mehreren, einzelnen referenzierten externen Dateien!

Externe Scriptdateien bedeuten zwar etwas mehr Verwaltungsaufwand, sind jedoch oft sinnvoll. Folgende Argumente sprechen dafür:

Führen wir nun ein kleines Beispiel durch, das eine externe Scriptdatei verwendet. Beachten Sie, dass hier zwei Funktionen verwendet werden, die beide in der Scriptdatei abgelegt werden.

Beispiel 3:

Erstellen Sie zuerst eine Datei, in der die JavaScript- Funktionen definiert sind. Geben Sie im Editor den nachfolgenden Quelltext ein:

function willkommen() 
{
alert("Herzlich Willkommen");
}
function bey()
{
alert("Und tschüss");
}

Speichern Sie den Text bitte unter dem Dateinamen extern.js.

Erstellen Sie nun die Datei, in der die Datei extern.js verwendet wird. Geben Sie im Editor den nachfolgenden Quelltext ein:

<html>
<head>
<SCRIPT language="JavaScript" src="extern.js">
</SCRIPT>
</head>
<body onLoad="willkommen()" onUnload="bey()">
</body>
</html>

Laden Sie die Datei in einen Browser, nachdem Sie sich zuvor eine andere Datei angesehen haben. Verlassen Sie dann den Browser über die Zurück-Schaltfläche. Sowohl beim Laden als auch dem Verlassen der Webseite wird eine JavaScript-Funktion aufgerufen, die jeweils eine unterschiedliche Meldung auf dem Bildschirm anzeigt.

Die Verwendung eines externen JavaScripts darf nicht so verstanden werden, dass alle dort definierten Funktionen auch verwendet werden müssen. Eine externe Datei kann beliebig viele Funktionen enthalten (und auch Variablen, welche wir noch nicht benutzen), von denen bei Bedarf die angegebene Funktion geladen und verwendet wird. Die nicht benötigten Funktionen beeinträchtigen die Webseite in keiner Weise. Es sollte aber beachtet werden, dass eine externe JavaScript-Datei nicht unnötig groß werden sollte. Eine Aufteilung auf mehrere externe Dateien ist u.U. sinnvoll und wird einfach dadurch möglich, dass die einzelnen, leeren Container mit den verschiedenen Referenzen gemeinsam in der Seite notiert werden.

Die Verwendung von externen JavaScript-Dateien kann ein Problem bedeuten, wenn auf dem Server der Mime-Type text/JavaScript für Dateien mit der Endung der externen Datei (etwa .js) in der Konfiguration des Web-Servers nicht angegeben ist. Dann muss der JavaScript-Text immer direkt in eine HTML-Datei geschrieben werden. Auf jeden Fall sollte die JavaScript-Funktionalität nach dem Laden auf den Server getestet werden.

Der Inline-Aufruf von Script-Anweisungen

Scriptaufrufe lassen sich auch direkt als Attribut in einen HTML-Tag hineingeschrieben. Das nennt man Inline- Aufruf oder auch Inline-Referenz, die in der Regel in Verbindung mit einer Steueranweisung verwendet wird, die auf einen Klick reagieren kann (etwa ein Hyperlink). Letzteres muss so vorsichtig beschrieben werden, weil insbesondere Netscape-Browser diese Variante nur sehr eingeschränkt unterstützen und auch andere Browser damit ihre Probleme haben können. Der Internet Explorer kann diese Technik recht zuverlässig nutzen. Grundsätzlich sieht der Inline-Aufruf eines Scripts syntaktisch so aus:

<[verweissensitives Steuerelement] = "[Scriptsprache]:[Scriptanweisung]"> 
  ...
<[Ende-Tag]>

Eine Webseite kommt sogar ganz ohne den <SCRIPT>- Container aus, wenn bei einem Inline-Aufruf nur einzelne vorgefertigte JavaScript-Anweisungen aufgerufen werden.

Führen wir ein Beispiel mit einem Inline-Aufruf durch.

Beispiel 4:

Geben Sie im Editor den nachfolgenden Quelltext ein:

<HTML>
<SCRIPT language="JavaScript">
function zufall()
{
alert(Math.random());
}
</SCRIPT>
<BODY>
<A href="JavaScript:zufall()">Klick</A>
</BODY>
</HTML>

Speichern Sie den Text bitte unter dem Dateinamen Inline.html ab und schauen Sie sich die Datei im Browser an. Klicken Sie mehrfach auf den Hyperlink. Das Beispiel verwendet einen Zufallsgenerator, der ständig neue Zufallszahlen zwischen 0 und 1 generiert (siehe Abbildungen 4.5 und 4.6).

Abbildung 4.5:  Ein neuer Klick auf den Link erzeugt eine neue Zufallszahl

Abbildung 4.6:  Ein Klick auf den Link führt die JavaScript-Funktion aus

Spezielle Microsoft-Notation von Scripten für Events in einer HTML- Steueranweisung

Microsoft stellt für den Internet Explorer ein Event- Modell bereit, das auf Ereignisse auf nahezu jedem Element in einer Webseite reagieren kann. Dazu wird der <SCRIPT>-Tag dann in Verbindung mit einem for- und einem event-Attribut eingesetzt. Syntax:

<SCRIPT for="[HTML-Steuerelement]" 
event="[Eventhandler]" language="[Scriptsprache]">
... irgendwelche Scriptanweisungen
</SCRIPT>

Diese Syntax wird vom Netscape Navigator nicht verstanden und bietet sich deshalb hauptsächlich für die Webseiten an, welche nur im Internet Explorer angezeigt werden sollen. Allerdings kann man damit auch einen Trick aufbauen, um Browser-Welten zu trennen - das werden wir in einem späteren Teil des Buchs zeigen.

Die Einbindung von Style Sheets in eine Webseite

Style Sheets oder Stilvereinbarungen bzw. Stilinformationen gehören zu den interessantesten Gestaltungsmitteln im WWW. Vergleichbar sind sie mit den Formatvorlagen, wie sie im Rahmen einer gewöhnlichen Textverarbeitung verwendet werden. Wie auch Scripte gehören sie nicht zu HTML, sondern sind eine eigenständige Technik, die seit HTML 4.0 in Webseiten verankert werden kann. Und zwar auf sehr ähnliche Art wie Scripte. Die Idee von Style Sheets entstand aus mehreren Intentionen:

Style Sheets sind nicht unumstritten und haben sich beileibe noch nicht WWW-weit durchgesetzt. Sie setzen bei der Zielplattform eine erhebliche Kompatibilität zu einem vorgegebenen Standard voraus, den so gut wie immer nur der jeweilige Hersteller eines Browsers garantiert. Zudem müssen für die absolute Kontrolle über bestimmte Elemente wie Schriften auch diese Elemente auf der jeweiligen Zielplattform installiert sein (die auch über Standardnamen angesprochen werden können), die Grafikkarte muss relativ leistungsfähig sein, es muss eine Mindestanzahl von Farben dargestellt werden können, die Auflösung darf nicht zu gering sein. Wer Style Sheets einsetzt, sollte - mehr noch als bei HTML - testen, testen, testen. Und unbedingt eine Seite so aufbauen, dass sie auch ohne die Wirkung von Style Sheets noch Sinn ergibt.

Wir beschäftigen uns im Rahmen dieses Buchs mit Style Sheets, weil der Einsatz dieser Technik im Rahmen einer Webseite hervorragend mit JavaScript gesteuert werden kann und umgekehrt JavaScript erheblich in Bezug auf Layout und Dynamik in der Webseite erweitert wird.

Style Sheets sind keine eigene Sprache, sondern es gibt diverse Sprachen, mit denen Style Sheets erstellt werden können. Die genauen Regeln für die Arbeit mit Style Sheets werden je nach verwendeter Style-Sheet-Sprache etwas differieren, sind aber alle ähnlich. Im Web hat sich hauptsächlich der CSS-Standard (Cascading Style Sheets) durchgesetzt, der vom W3C standardisiert wird. Auf dessen Feinheiten gehen wir an späterer Stelle ein - hier soll nur die Einbindung von Style Sheets in eine Webseite behandelt werden. Dies kann darüber geschehen, dass man Style Sheets direkt in eine Seite einbettet (Linken) oder aus einer externen Datei lädt (Importieren).

Eine externe Lösung hat wieder die gleichen Vorteile wie beim Fall von externen JavaScript-Dateien:

Eine externe Style-Sheet-Klartextdatei wird bei Stilformatvorlagen nach dem CSS-Standard meist die Erweiterung .css bekommen. Das ist jedoch wie die Erweiterung .js für JavaScript optional.

Eine direkt in eine Webseite geschriebene Stilinformation hat natürlich auch einiges für sich, sonst gäbe es diese Variante nicht. Eine interne Lösung über eingebettete Style Sheets hält alle Informationen über eine Webseite zusammen und erlaubt schneller Änderungen. Außerdem hat man bei kleineren Seiten alles Notwendige direkt im Blick.

Die Verwendung von Style Sheets kann im Header einer HTML-Datei als Metainformation dokumentiert werden. Dazu wird der <META>-Tag mit dem http-equiv-Parameter verwendet. Um beispielsweise die Verwendung von Cascading Style Sheets zu dokumentieren, wird im Header die folgende Deklaration notiert:

<META http-equiv="Content-Style-Type" content="text/css">

Dies ist aber wie gesagt nur eine Dokumentation eines MIME-Typs für die verwendete Style-Sheet-Sprache, keine explizite Referenz.

Direkte Notation von Style Sheets in der Webseite mit dem <STYLE>-Container

Die direkte Einbindung von Style Sheets in eine Webseite erfolgt über die Notation eines <STYLE>- Containers direkt in den HTML-Code (ein Analogon zu dem <SCRIPT>-Container bei Scripten). In dem Inneren des <STYLE>-Containers werden - meist in HTML- Kommentare eingeschlossen, damit für ältere Browser die Anweisungen verborgen werden - alle Stilinformationen definiert. Man nennt diese Form der Verknüpfung »eingebettete Formatvorlagen«. Wo das Style Sheet konkret in der HTML-Datei notiert wird, ist wie bei Scripten nicht festgelegt. Jedoch gelten ebenso die gleichen Argumente dafür, Style Sheets möglichst noch vor dem Laden des Body-Abschnitts bereitzustellen. Also im Header oder zwischen Header und Body. Die konkrete Referenz erfolgt mit dem Tag <STYLE> wie folgt (CSS):

<STYLE type="text/css"> 
<!--... irgendwelche Stilvereinbarungen ... -->
</STYLE>

Im Inneren werden die konkreten Stilinformationen notiert. Fehlt die Typ-Angabe des MIME-Typs, kann die Stilvereinbarung dennoch korrekt umgesetzt werden, wenn CSS die Default-Style-Sheets des Browsers sind. Darauf sollte man sich allerdings nicht verlassen. Die Referenz auf ein internes Style Sheet erfolgt allgemein so:

<STYLE type="[Style Sheet-Typ]" > 
<!--... irgendwelche Stilvereinbarungen ... -->
</STYLE>

Der HTML-Kommentar-Endebefehl kann hier unmaskiert verwendet werden. Die Probleme wie bei dem JavaScript-Interpreter von Netscape tauchen dabei nicht auf.

Das nachfolgende Beispiel verwendet eingebettete Formatvorlagen. Beachten Sie bei diesem und auch den restlichen Beispielen zur Einbindung von Style Sheets, dass wir die Erklärungen der eigentlichen Stilformatsyntax auf die Tage verschieben wollen, wo sie intensiv behandelt werden.

Beispiel 5:

Geben Sie im Editor den nachfolgenden Quelltext ein:

<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
</HEAD>
<STYLE TYPE="text/css">
<!--
.meinStil1 {
font-family: Arial;
font-size: x-large;
text-align: center;
}
.meinStil2 {
font-weight: bold;
font-style: italic;
color: #FF0000;
background: #9BAAE6;
}
-->
</STYLE>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#FF0000" ALINK="#FF0000" VLINK="#FF0000">
<H1 class=meinStil2>Herzlich Willkommen</H1>
Diese Seite verwendet Style Sheets
<BR>
<SPAN class="meinStil1">
Etwa hier
</SPAN>
</BODY>
</HTML>

Speichern Sie den Text bitte unter dem Dateinamen Stileinbind1.html ab und schauen Sie sich die Datei in verschiedenen Browsern an.

Beachten Sie die Punkte vor meinStil1 und meinStil2. Diese sind zwingend notwendig!

Abbildung 4.7:  Die Überschrift und die dritte  Zeile sind über Style Sheets  formatiert

Die Link-Notation auf eine externe Datei

Über die nachfolgende Syntax kann ein Verweis auf ein externes Style Sheet erfolgen. Das nennt man dann ein verknüpftes Style Sheet bzw. eine Link-Notation. Allgemeine Form:

<LINK type="[Style Sheet-Typ]" rel=stylesheet 
href="[URL einer Datei mit Stilinformationen]"
title="[Name des Style-Sheets]">

Beachten Sie, dass im Gegensatz zu dem <STYLE>-Container hier kein Container definiert wird. Es gibt also keinen Ende-Tag.

Eine CSS-Datei wird schematisch so zu einer Webseite gelinkt:

<LINK type="text/css" rel=stylesheet 
href="[URL einer Datei mit CSS-Informationen]"
title="[Name des Style-Sheets]">

Der Titel ist optional, die Typ-Angabe unter Umständen auch, aber das kann Probleme geben (s.o.). Die restlichen Attribute sind notwendig. Diese Zeile wird am sinnvollsten in den Header der HTML-Seite geschrieben und kennzeichnet eine Style-Sheet-Datei, von wo die in der HTML-Datei verwendeten Stilinformationen bei Bedarf hinzugebunden werden.

Beispiel 6:

Erstellen Sie als erstes die Style-Sheet-Datei:

.meinStil3 
{
font-family: Arial;
font-size: xx-large;
text-align: right;
}
.meinStil4
{
font-weight: bold;
font-style: italic;
color: #FFFF00;
background: #911A16;
}

Speichern Sie die Datei unter externStil.css. Erstellen Sie dann im Editor die nachfolgende Datei:

<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
<LINK type="text/css" rel=stylesheet href="externStil.css">
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#FF0000" ALINK="#FF0000" VLINK="#FF0000">
<H1 class=meinStil3>
Herzlich Willkommen
</H1>
Diese Seite verwendet Style Sheets
<BR>
<SPAN class="meinStil4">
Etwa hier
</SPAN>
</BODY>
</HTML>

Speichern Sie den Text bitte unter dem Dateinamen Stileinbind2.html ab und schauen Sie sich die Datei in verschiedenen Browsern an.

Abbildung 4.8:  Die Überschrift und die dritte  Zeile sind über Style Sheets  formatiert

Die Inline-Referenz

Wie auch bei JavaScript gibt es bei Style Sheets die Möglichkeit einer Inline-Referenz. Dies bedeutet die Erweiterung eines gewöhnlichen HTML-Elementes um nur dort gültige Stilinformationen. Über ein zusätzliches Attribut - style (nicht mit dem Tag <STYLE> zu verwechseln) - wird innerhalb des gewünschten HTML- Tags ein Stilattributwert gesetzt. Die Stilinformation gilt ausschließlich innerhalb des mit dem HTML-Befehl definierten Containers (wobei Container im Sinn von Wirkung des Tags zu verstehen ist - das kann auch ohne Ende-Tag gelten). Eine Inline-Deklaration ist dann sinnvoll, wenn ein Element nur ein- oder zweimal verwendet werden soll und nur wenige Stilformatierungen gesetzt werden sollen. Die abstrakte Syntax:

  <[HTML-Tag] style="Stilinformationen">

Optional kann wie bisher auch über den type-Parameter noch der Typ der Style Sheets definiert werden. Die Angabe type="text/css" spezifiziert, wie oben bereits verwendet, beispielsweise CSS.

Beispiel 7:

Geben Sie im Editor den nachfolgenden Quelltext ein:

<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#FF0000" ALINK="#FF0000" VLINK="#FF0000">
Normaler Text ohne Stilinformationen.
<P style="color : gray">
Ein Inline-Style Sheet, in dem die Schriftfarbe in dem Absatz auf grau gesetzt wird.
</P>
<P type="text/css" style="font-size: 22pt; color: red">
Ein Inline-Style Sheet, in dem die Schriftfarbe in dem Absatz auf rot und die Schriftgrösse auf 22 gesetzt sowie über den type-Parameter der Typ der Style-Sheets definiert wird.
</P>
</BODY>
</HTML>

Speichern Sie den Text bitte unter dem Dateinamen Stileinbind3.html ab und schauen Sie sich die Datei in verschiedenen Browsern an.

Abbildung 4.9:  Die Überschrift und die dritte  Zeile sind über Style Sheets  formatiert

Prioritäten

Wenn mehrere Style Sheets in einer Seite vorhanden sind, kann es zu Konflikten kommen. Sofern sich zwei Stilinformationen der gleichen Art auf dasselbe Element beziehen, wird die jeweils zuletzt notierte Stileinstellung für ein bestimmtes Element verwendet. Für spezielle Fälle gibt es die Möglichkeit, die Priorität einer Stilinformation über einen Modifier (important) zu erhöhen.

Wenn verschiedene Typen von Style-Sheet- Einbindungen in einer Webseite kombiniert werden und es zu Widersprüchen kommt, hat die Inline-Verknüpfung die höchste Priorität, gefolgt von der eingebetteten Formatvorlage. Die verknüpfte Formatvorlage hat die niedrigste Priorität. Das kann auch dazu verwendet werden, über Style Sheets global definierte Elemente mit einer Inline-Deklaration wieder zu überschreiben.

Es gibt auch die Möglichkeit eines Imports externer Stilinformationen über den <STYLE>-Container. Der CSS-Entwurf definiert für die Referenz auf die Datei die Anweisung @import. Die Syntax würde so aussehen:

<STYLE type="text/css">
@import url([URL einer Datei mit CSS-Informationen]);
</STYLE>

Diese Variante wird jedoch von mehreren Browsern nicht unterstützt. Man sollte Sie nur dann einsetzen, wenn man alle in Frage kommenden Browser testen kann (etwa in einem Intranet). Aber streng genommen gibt es kaum einen Grund, diese Version der Einbindung überhaupt zu verwenden.

Zusammenfassung

Sie kennen nun die Möglichkeiten zur Einbindung von JavaScripten (genau genommen jeglicher Scripte, die im Rahmen eines Web-Browsers unterstützt werden) und Style Sheets in Webseiten. Beide Techniken werden von der Logik her auf ähnliche Weise mit HTML bzw. einer Webseite verknüpft. Entweder werden

Die konkrete Syntax für einen allgemeinen Script- Container sieht also schematisch immer so aus:

<SCRIPT language="[Sprache]">
<!--
  ... irgendwelche Script-Anweisungen
//-->
</SCRIPT>

Im Fall von JavaScript folgendermaßen:

<SCRIPT language="JavaScript">
<!--
  ... irgendwelche Script-Anweisungen
//-->
</SCRIPT>

Bei der externen Notation sieht die Referenz für Scripte allgemein wie folgt aus:

<SCRIPT language="[Sprache]" src="[URL der separaten Script-Datei]">
</SCRIPT>

Im Fall von JavaScript gilt also:

<SCRIPT language="JavaScript" src="[URL der separaten JavaScript-Datei]">
</SCRIPT>

Mit dem Attribut src wird der URL der separaten Datei angegeben. Der <SCRIPT>-Container muss für den Fall einer Einbindung von externen Dateien leer sein.

Der Inline-Aufruf eines Scripts sieht grundsätzlich syntaktisch so aus:

<[verweissensitives Steuerelement] = "[Scriptsprache]:[Scriptanweisung]">
  ...
<[Ende-Tag]>

Für JavaScript also so:

<[verweissensitives Steuerelement] = "JavaScript:[Scriptanweisung]">
  ...
<[Ende-Tag]>

Die Einbindung von Style Sheets erfolgt grundsätzlich sehr ähnlich. Die direkte Einbindung von Style Sheets in eine Webseite erfolgt über die folgende Notation (CSS):

<STYLE type="text/css"> 
<!--
  ... irgendwelche Stilvereinbarungen ...
-->
</STYLE>

Die Referenz auf ein externes Style Sheet erfolgt allgemein so:

<STYLE type="[Style Sheet-Typ]" > 
<!--
  ... irgendwelche Stilvereinbarungen ...
-->
</STYLE>

Im Inneren werden die konkreten Stilinformationen notiert.

Die Link-Referenz auf ein externes Style Sheet erfolgt allgemein so:

<LINK type="[Style Sheet-Typ]" rel=stylesheet 
href="[URL einer Datei mit Stilinformationen]"
title="[Name des Style-Sheets]">

Eine CSS-Datei wird schematisch so zu einer Webseite gelinkt:

<LINK type="text/css" rel=stylesheet 
href="[URL einer Datei mit CSS-Informationen]"
title="[Name des Style-Sheets]">

Der Titel ist optional, die Typ-Angabe unter Umständen auch, die restlichen Attribute sind notwendig. Im Gegensatz zu dem <STYLE>-Container wird hier kein Container definiert. Es gibt also keinen Ende-Tag.

Eine Inline-Deklaration sieht so aus:

<[HTML-Tag] style="Stilinformationen">

Fragen und Antworten

Frage:
Wenn man ein Projekt beginnt, in dem Style Sheets und JavaScript verwendet werden, wird ja deutlich im Buch empfohlen, ab einer gewissen Komplexität externe Dateien zu verwenden. Ist es sinnvoll, jeden Dateityp in einem eigenen Verzeichnis abzulegen?

Antwort:
Ja, aber natürlich nicht zwingend. Dann sollte man aber auch so konsequent sein, für Grafiken und andere verwendete Ergänzungstechniken wie Java-Applets eigene Verzeichnisse zu führen. Ab einer gewissen Komplexität eines Web-Projektes zahlt sich eine solche Organisation in Verzeichnissen aus.

Frage:
Welche Style-Sheet-Sprachen sind im Web noch wichtig?

Antwort:
Es gibt verschiedene Versuche, Style Sheets zu standardisieren. Als wichtigster Standard muss man neben CSS JavaScript-Assisted Style Sheets (JSSS) nennen, was ein von Netscape entwickeltes und im Navigator unterstütztes Format ist sowie Extensible Stylesheet Language (XSL - siehe Tag 2). Aber selbst diese wichtigen Formate konnten sich bislang nicht wirklich überzeugend im WWW durchsetzen. Um Cascading Style Sheets führt derzeit kaum ein Weg herum.

Workshop

Experimentieren Sie mit einfachen HTML-Seiten, indem Sie unsere externen JavaScript- und Style-Sheet-Dateien dort einbinden und verwenden.

Gehen Sie online und analysieren Sie Webseiten mit JavaScripten und Style Sheets auf deren Weg der Einbindung. Den Quelltext einer Webseite können Sie sich im Navigator als auch dem Internet Explorer über das Ansicht-Menü und dort den jeweiligen Menüpunkt Seitenquelltext bzw. Quelltext anzeigen ansehen. Bei Frames - auf die gehen wir noch ein - sehen Sie dann unter Umständen nicht viel. Klicken Sie dann dort einfach mit der rechten Maustaste auf den Sie interessierenden Bereich und wählen aus dem Kontextmenü den Befehl zum Anzeigen des Teilbereichs aus.

Kontrollfragen

Im Anhang »Antworten zu den Kontrollfragen« finden Sie die Antworten zu den jeweils am Ende einer Lektion notierten Fragen.

Finden Sie den Fehler:

  1. <SCRIPT language ="JavaScript 1.2">
  2. <SCRIPT langauge="JavaScript" src="extern.js">
    </SCRIPT>
  3. <A href="zufall()">Klick</A>
  4. <STYLE TYPE="text/ccs">
    <!--
    .meinStil1 {
    font-family: Arial
    }
    -->
    </STYLE>
  5. <LINK type="text/css" href="externStil.css">
  6. <P> <style="color : gray">
  7. </SCRIPT> "> <SCRIPT language="JavaScript" src="extern.js">
    alert("Hallo");
    </SCRIPT>



vorheriges KapitelInhaltsverzeichnisStichwortverzeichnisFeedbackKapitelanfangnächstes Kapitel


© Markt+Technik Verlag, ein Imprint der Pearson Education Deutschland GmbH