HTML-Einführung
von Hubert Partl
HTML-Einführung
von Hubert Partl
Im Gegensatz zu HTML-Files, die einen fixen Inhalt haben, kann man damit Informationen verteilen, die sich laufend ändern oder die von Benutzer-Eingaben abhängen.
Der Aufruf der CGI-Prozedur erfolgt in einem
Hypertext-Link
oder einem
Formular
mit einem
URL
der Form
http://hostname/cgi-directory/filename
oder
http://hostname/cgi-directory/filename?parameterliste
Beispiel:
- - - Eine einfache Unix-Shell-Prozedur wie
#!/bin/sh echo "Content-Type: text/html" echo "" echo "<html><head><title>Datum</title></head>" echo "<body><p>Today is " /bin/date echo "</body></html>" exit- - - sendet z.B. den folgenden HTML-Code an den Client
<html><head><title>Datum</title></head> <body><p>Today is Thu Mar 8 19:30:00 MET 2001 </body></html>- - - und das bewirkt eine Darstellung wie
Today is Thu Mar 8 19:30:00 MET 2001
- - -
Eine etwas ausführlichere Version einer solchen Datumsanzeige finden Sie an der BOKU Wien.
CGI-Programme und Prozeduren können in beliebigen Sprachen geschrieben werden (Shell-Scripts, Perl-Scripts, C-Programme, Java-Programme u.a.). Die Detail-Informationen dazu finden Sie in der Dokumentation des jeweiligen WWW-Servers und in den Referenzen, siehe auch die Hinweise von Stefan Münz zu CGI-Programmen und Perl.
Wenn das CGI-Programm in Java geschrieben wird und wenn der Web-Server es unterstützt, dann kann man dieses Java-Programm als sogenanntes Java-Servlet einrichten, das dann besonders effizient innerhalb des Web-Servers läuft. Mehr darüber finden Sie in der Java-Einführung und in den dort angeführten Referenzen.
Andere Möglichkeiten, nicht ein fixes HTML-File sondern eine zur Aufrufzeit dynamisch generierte bzw. modifzierte HTML-Seite auszugeben, sind
Hier ein Beispiel für ein PHP-File, das eine Datenbank-Abfrage in einen HTML-Text einbettet:
- - - Das PHP-File am Server
<html>
<head>
<title>freie Plaetze</title>
</head>
<body>
<p>
Im <b>HTML-Kurs</b> sind noch
<?php
$con = ocilogon ('KursDB', 'user', 'password');
$sql = "SELECT frei FROM kurse WHERE titel='HTML-Kurs' " ;
$stmt = ociparse ($con, $sql);
ociexecute ($stmt);
while ( ocifetch ($stmt) ) {
$frei = ociresult ($stmt, 'frei');
print($frei);
}
ocilogoff ($con);
?>
Plätze frei.
</body>
</html>
- - - sendet z.B. den folgenden HTML-Code an den Client
<html> <head> <title>freie Plaetze</title> </head> <body> <p> Im <b>HTML-Kurs</b> sind noch 3 Plätze frei. </body> </html>- - - und das bewirkt eine Darstellung wie
Im HTML-Kurs sind noch 3 Plätze frei.
- - -
Für vollständige Informationen über PHP wird auf die Referenzen verwiesen.
Relativ leicht können Sie erfahren, wie oft auf Ihr HTML-File am WWW-Server zugegriffen wurde. Die meisten WWW-Server führen ein "Log-File", in dem alle Zugriffe protokolliert werden, und Sie können mit einem einfachen Unix-Shell-Script zählen, wie oft Ihr Filename darin vorkommt. Beispiel:
#!/bin/sh url="$1" logfile=/usr/local/apache/logs/access_log n=`grep -i "$url" $logfile | wc -l` echo "$n Zugriffe auf $url" exitAußerdem finden Sie im Log-File auch die Information, von welchen Client-Rechnern auf Ihr File zugegriffen wurde (aber im allgemeinen nicht, von welchen Personen).
Damit zählen Sie aber nur die Anzahl der File-Übertragungen und nicht, wie oft die Information tatsächlich gelesen wurde. Schuld daran sind die sehr nützlichen sogenannten Cache-Speicher, die zur Entlastung der Netzverbindungen notwendig sind:
Die meisten Web-Browser haben einen lokalen Cache-Speicher. Wenn z.B. ein Benutzer in Berlin zehn mal die in Wien gespeicherte HTML-Einführung liest, wird sie nur beim ersten Mal von Wien nach Berlin übertragen und, solange der Platz ausreicht, in seinem Cache-Speicher abgelegt. Bei allen weiteren Zugriffen wird das File nicht nochmals von Wien nach Berlin übertragen, sondern viel einfacher und schneller aus dem lokalen Cache geholt (außer der File-Inhalt wurde inzwischen erneuert).
Viele Institutionen verwenden auch globale Cache-Server ("Proxy"), die dann für alle Zugriffe aus diesem Bereich wirken. Wenn z.B. tausend Benutzer in Berlin die in Wien gespeicherte HTML-Einführung lesen, wird sie nur beim ersten Mal von Wien nach Berlin übertragen und eine Kopie am Berliner Cache-Server abgelegt (solange der Speicherplatz ausreicht). Bei allen weiteren Zugriffen wird das File nicht nochmals von Wien nach Berlin übertragen, sondern viel schneller aus dem Berliner Cache-Server geholt (außer der File-Inhalt wurde inzwischen erneuert).
Die Zahl, wie oft Ihr File tatsächlich gelesen wurde, ist im allgemeinen also wesentlich höher als die am WWW-Server gezählte Zahl der File-Übertragungen.
Manche Autoren wollen die Zahl der Zugriffe auch innerhalb des HTML-Files speichern. Dies ist zwar technisch möglich (z.B. mit Hilfe einer CGI-Prozedur), aber nicht empfehlenswert, weil das eine zusätzliche Netz- und Server-Belastung bedeutet und weil die Anzahl der File-Übertragungen meist ohnehin nur für den Autor der Information und den Verwalter des WWW-Servers, aber nicht für die Leser interessant ist.
Beispiel:
- - - Die Eingabe von
<form method="get" action="http://www.boku.ac.at/cgi-bin/hein-get"> <b>Anmeldung</b> zur Geburtstagsfeier am 8. März <p> <input type="radio" name="kommt" value="ja" checked> Ich komme. <br> <input type="radio" name="kommt" value="nein"> Ich komme nicht. <p> Name: <input name="wer" size="40" maxlength="512"> <p> Telefonnummer: <input name="tel" size="20" maxlength="512"> <p> <input type="submit" value="Anmeldung absenden"> </form>- - - bewirkt eine Darstellung wie
- - -
Anmerkung: Die in diesem Beispiel verwendete CGI-Prozedur dient nur für Tests durch die Leser dieser Einführung. Wenn Sie dieses Formular ausfüllen und absenden, bekommen Sie eine kurze Test-Antwort, aber (leider) keine wirkliche Einladung zum "Heurigen".
Eine "echte" Anmeldungs-Prozedur würde die Zu- und Absagen mit Name und Telefonnummer in einer Datenbank speichern und dann die Bestätigung an den Client senden.
Das Senden einer solchen Antwort ist immer notwendig, denn der Benutzer muss auf seinem Bildschirm erkennen können, dass das "Anklicken" des Submit-Knopfes funktioniert hat ("Feedback"). Im einfachsten Fall genügt eine kurze Meldung, dass die Eingabe verarbeitet wird, und eventuell ein Hinweis, dass der Benutzer mit der Back-Taste oder dem Back-Befehl seines Browsers zur vorherigen Information zurückkehren und weiterarbeiten kann.
Bei der Gestaltung von Formularen müssen die Normen und Konventionen für Benutzerschnittstellen und die Gewohnheiten und Erwartungen der Benutzer berücksichtigt werden.
Für genauere Informationen über die vom Server unterstützten Übertragungs-Methoden ("get" oder "post") und die Übergabe der Eingabedaten an die CGI-Prozedur wird auf die Dokumentation des jeweiligen WWW-Servers und auf die Referenzen verwiesen. Die CGI-Prozeduren müssen so geschrieben werden, dass Ihre Ausführung kein Sicherheitsrisiko für den Server-Computer darstellen kann, egal was für eventuell seltsame Eingaben von den Benutzern kommen.
Wenn Sie keine Möglichkeit haben, ein CGI-Programm auf dem von Ihnen verwendeten WWW-Server zu installieren, bietet sich als Alternative die Verwendung von Electronic Mail an.
Manche (wenige) Web-Browser
bieten die Möglichkeit, Formulare per E-Mail zu verarbeiten.
Dazu würden Sie im Formular mit
<form
action="mailto:user@host.domain" enctype="text/plain">
Ihre eigene Mail-Adresse angeben,
und jedesmal, wenn ein Leser dann den Submit-Knopf "drückt",
bekommen Sie den Formularinhalt als lesbaren Text
per E-Mail in Ihre Mailbox gesendet
und können ihn dann händisch oder
mit einem auf Ihrem Computer laufenden Programm
verarbeiten.
Allerdings werden solche Mailto-Formulare von sehr vielen Web-Browsern nicht unterstützt. Diese Methode kann daher nur innerhalb von kleinen, geschlossenen Benutzergruppen eingesetzt werden, bei denen man sicher ist, dass sie alle eine dafür geeignete Browser-Version verwenden, abe nicht für allgemein verwendbare Anwendungen.
Deshalb sollte man, wenn man keine CGI-Programme verwenden kann, lieber gar keine Formulare verwenden sondern ein normales Mailto-Link, bei dem die Benutzer den Text "formlos" schreiben und per E-Mail absenden können. Diese Möglichkeit steht dann allen Internet-Benutzern offen.
Beispiel:
<p> Bitte senden Sie Ihre Anmeldung per <a href="mailto:user@host.domain">E-Mail an user@host.domain</a> oder per Telefax an ...- - -
Dafür gibt es zwei verschiedene Verfahren:
<map> und usemap)
vorgesehen, die direkt im HTML-File spezifiziert
und vom Web-Browser verarbeitet werden.
Dies ist die neuere Methode, sie ist einfacher zu realisieren
und wird von allen neueren Web-Browsern unterstützt.
Im HTML-File ist eine Kombination aus einem
<a href>-Befehl
für die CGI-Prozedur und einem
<img>-Befehl
für das Bild mit der Angabe "ismap" anzugeben.
Beispiel:
- - - Die Eingabe von
<a href="http://www.boku.ac.at/cgi-bin/hein-map"> <img src="austria.gif" ismap></a>- - - bewirkt eine Darstellung wie
und je nachdem, wo in diesem Bild Sie "klicken", bekommen Sie eine entsprechende Antwort von der CGI-Prozedur.
- - -
Für genauere Informationen über das Zusammenspiel zwischen Bild und CGI-Prozedur und über Hilfsprogramme zu deren Erstellung wird auf die Referenzen verwiesen.
Die Spezifikation,
welche Teile des Bildes den Sprung zu welchem
Hypertext-Link
bewirken sollen,
erfolgt mit Hilfe von <map>
entweder im selben HTML-File wie die Verwendung des Bildes
oder in einem separaten File,
das gemeinsam mit dem Bild abgespeichert ist.
Im
<img>
oder
<object>-Befehl
des Bildes wird dann mit "usemap" auf diese Map-Spezifikation
verwiesen.
Da nicht alle Benutzer
die Darstellung von Bildern eingeschaltet haben
und da manche Web-Browser und viele
Suchmaschinen
solche Image-Maps nicht richtig verarbeiten,
muss man bei einer Image-Map zusätzlich
ein "normales" Link mit
<a href>
angeben, das zu einer
Liste von Hypertext-Links
in einfacher Textform führt.
Damit wird sichergestellt,
dass alle Benutzer und Suchhilfen
die betreffenden Informationen erreichen können.
Beispiel:
- - - Die Eingabe von
<map name="map3"> <area shape=rect coords="0,0,89,15" href="#oben" alt="oben"> <area shape=rect coords="0,16,89,31" href="#mitte" alt="mitte"> <area shape=rect coords="0,32,89,47" href="#unten" alt="unten"> </map> <p>Klicken Sie auf eines der drei Felder der Fahne <a href="#ohnemap"> <img src="austria.gif" alt="oder hier!" usemap="#map3"></a>- - - bewirkt die Ausgabe von
Klicken Sie auf eines der drei Felder der Fahne
Je nachdem, wo Sie in diesem Bild "klicken", gelangen Sie zu einer der folgenden vier Stellen:
Die Eingabe für die im vierten Punkt beschriebene Alternative hat einen Aufbau der folgenden Form:
<a name="ohnemap">Ihr Browser ... </a> Sie ... können ... nun ... auswählen: <ul> <li><a href="#oben">Informationen zum oberen Bereich</a> <li><a href="#mitte">Informationen zum mittleren Bereich</a> <li><a href="#unten">Informationen zum unteren Bereich</a> </ul>- - -
Manche Web-Browser stellen <map> nicht als Bild
sondern als eine Art Pull-down-Menü mit den in den
ALT-Parametern angegebenen Texten dar.
Die Angabe dieser Texte mit
alt= in <area>
ist deshalb zwingend vorgeschrieben.
Viele Benutzer haben wegen dieser Sicherheitsrisiken die Möglichkeiten von JavaScript und dergleichen in ihren Web-Browsern ausgeschaltet. Deswegen und weil diese Möglichkeiten nicht in allen Web-Browsern richtig funktionieren auch von Suchmaschinen nicht unterstützt werden, muss der Autor der Web-Page immer auch Alternativen in gewöhnlichem HTML vorsehen (mit <noscript> etc.).
Die wichtigsten Möglichkeiten sind:
Was ist Java?
Java ist eine Programmiersprache, ähnlich wie Pascal, Modula, C und C++.
Java ist plattformunabhängig. Wenn Sie ein Java-Programm auf einem Computer schreiben und kompilieren, dann läuft es unverändert auf allen Arten von Computern, egal ob Windows-PC, Macintosh, Unix-Rechner oder TV-Settopbox.
Java is objektorientiert und eignet sich daher auch sehr gut für komplexe Anwendungen, die aus vielen Einzelteilen bestehen, sowie für graphische User-Interfaces.
Java hat eine umfangreiche Klassenbibliothek, in der Sie viele Klassen für die verschiedensten Zwecke schon fertig vorfinden und damit auch komplizierte Aufgaben mit wenig Aufwand realisieren können (z.B. Bildbearbeitung, dynamisch wachsende Listen, Sortieren, Multithreading, E-Mail, Socket-Verbindungen über das Internet, Datenbankoperationen u.v.a.).
Java hat zahlreiche Sicherheitsmechanismen eingebaut, die vor typischen Programmfehlern schützen. So können Java-Programme zum Beispiel keine "allgemeine Schutzverletzung" bewirken, weil es die Sprachelemente, die dazu führen können (Pointer-Arithmetik u.a.), in Java gar nicht gibt.
Aus allen diesen Gründen eignet sich Java nicht nur für "normale" Computer-Programme sondern auch besonders gut für Anwendungen, die über das Internet verbreitet werden. Neben normalen Java-Applikationen gibt es daher auch Java-Applets, die in Web-Pages eingebaut werden und dann bei jedem Benutzer innerhalb des Web-Browsers ablaufen.
Durch spezielle Sicherheitsvorkehrungen ist sichergestellt, dass diese Applets in den Web-Browser "eingesperrt" bleiben und keine bösen Nebenwirkungen auf den Rechner des Benutzers haben können: Applets können z.B. nicht auf die dort gespeicherten Dateien zugreifen und keine Systemfunktionen oder anderen Programme aufrufen.
Java ist eine neue und moderne Programmiersprache. Dieser Vorteil ist gleichzeitig auch ein Nachteil: Java ist so neu, dass seine Eigenschaften noch laufend erweitert und verbessert werden. Seit 1995 gibt es Version 1.0, Anfang 1997 kam Version 1.1 heraus, Ende 1998 die Version 1.2 (auch Java 2 genannt). Die Hersteller der Web-Browser haben Mühe, mit dieser Entwicklung Schritt zu halten. Dies sollte sich aber in hoffentlich nicht zu ferner Zukunft bessern.
Ich bin davon überzeugt, dass Java in ein bis zwei Jahren die nötige Reife und Stabilität erreichen wird und nicht nur eine aufregende Gegenwart sondern auch eine gute und stabile Zukunft hat.
Innerhalb der Web-Page werden Applets mit dem HTML-Tag <applet> eingefügt und aufgerufen. Dies erfolgt nach dem folgenden Schema:
<applet code="Xxxx.class" width=nnn height=nnn> <param name="xxx" value="yyy"> ... Text ... </applet>
Im Applet-Tag muss mit dem Parameter code der Name des Java-Applet angegeben werden (Class-File mit dem plattformunabhängigen Bytecode), und mit width und height die Breite und Höhe des Applet in Pixels.
In diesem Fall muss sich das Class-File im selben Directory am selben Server wie das HTML-File befinden. Wenn dies nicht der Fall ist, muss man mit einem zusätzlichen Parameter codebase den URL des Directory angeben, aus dem das Class-File geladen werden soll. Beispiel:
<applet codebase="http://www.boku.ac.at/javaeinf/"
code="HelloApp.class" width=300 height=100>
Falls das Class-File kein einzelnes Files ist sondern in einem komprimierten Archiv (ZIP- oder JAR-File) enthalten ist, ist der Name dieses Archiv-Files mit dem Parameter archive anzugeben:
<applet codebase="http://hostname/dirname/"
archive="xxxxx.jar" code="Xxxxx.class"
width=300 height=100>
Mit einem oder mehreren Param-Tags können Parameter an das Applet übergeben werden.
Der (abgesehen von den Param-Tags) zwischen <applet> und </applet> stehende Text wird von den Browser-Versionen, die Java nicht unterstützen, an Stelle des Java-Applet dargestellt. Dies kann beliebig formatierter HTML-Text sein, also z.B. auch Bilder enthalten.
In der neuen HTML-Norm HTML 4.0 ist vorgesehen, dass statt dem Tag <applet> der Tag <object> verwendet werden soll. Dies wird aber von dem meisten Browsern noch nicht unterstützt.
Ausführlichere Informationen über Java finden Sie in der Java-Einführung und in den dort angeführten Referenzen sowie in der Newsgruppe de.comp.lang.java
Hier ein Beispiel, wie Sie ein fertiges Java-Applet in Ihre Web-Page einbauen und mit <param>-Tags an Ihre Bedürfnisse anpassen können, das - inzwischen schon allzu populäre - Lake-Applet von David Griffiths. Dieses Applet stellt ein Bild als Spiegelung in einem See dar. Das Class-File muss zu diesem Zweck in dasselbe Directory kopiert werden, wo sich auch Ihr HTML-File und Ihr Bild befindet, und mit den Parametern image und href wird angegeben, welches Bild sich im See spiegeln soll und was passieren soll, wenn der User auf das Bild klickt.
Das HTML-File sieht so aus:
<html> <head> <title>Badende Venus</title> </head> <body> <h1 align=center>Lake Applet</h1> <p align=center> <applet code="lake.class" width=604 height=723> <param name=image value="http://www.boku.ac.at/htmleinf/big.jpg"> <param name=href value="http://www.boku.ac.at/htmleinf/hein53.html#java"> Ohne Java können Sie das Bild nur ohne Wasserspiegelung sehen: <p align=center> <img src="big.jpg" alt="Badende Venus"> </applet> </body> </html>Wenn Ihr Web-Browser Java unterstützt, dann können Sie hier ausprobieren, wie das aussieht.
JavaScript ist etwas anderes als Java.
JavaScript ist keine selbständige Programmiersprache, sondern eine Erweiterung von HTML durch ein paar Script-Befehle, die dann vom Web-Browser ausgeführt werden.
JavaScript ist nicht plattformunabhängig, sondern läuft nur in Netscape und Internet Explorer, und auch da nicht in allen Versionen in der gleichen Weise.
JavaScript verfügt nicht über die guten Sicherheitsvorkehrungen von Java und kann daher durchaus böse Nebenwirkungen auf den Benutzer haben. In noch stärkerem Maße gilt dies übrigens für Active-X und Active Desktop im Internet Explorer und in Windows 98.
JavaScript wird mit dem HTML-Tag <script> direkt in das HTML-File eingebettet:
<script> ... JavaScript-Programm ... </script> <noscript> ... Text ... </noscript>Im <noscript>-Block wird in normaler HTML-Schreibweise die Information angegeben, die in der Web-Page erscheinen soll, falls der Benutzer JavaScript ausgeschaltet hat oder falls der Web-Browser oder die Suchmaschine JavaScript nicht unterstützt.
Wenn das JavaScript zum Beispiel dazu dient, Hilfstexte ("Tooltips") anzuzeigen, wenn die Maus an eine bestimmte Stelle zeigt, dann sollen dieselben Erklärungen im <noscript>-Block als normale HTML-Texte stehen. Oder wenn das JavaScript dazu dient, auf andere Web-Pages zu verzweigen, müssen im <noscript>-Block die gleichen Links als normale <a href>-Befehle erscheinen. Dies ist sowohl für Anwender als auch für Suchmaschinen wichtig, die sonst die Informationen in den Links gar nicht erreichen können.
Ausführlichere Informationen über JavaScript finden Sie vor allem bei Stefan Münz sowie in der Newsgruppe de.comp.lang.javascript
Wenn Sie nur ein paar Spezialeffekte in Ihre Web-Page einbauen wollen - z.B. dass sich ein Link ändert, wenn die Maus darüber fährt, oder dass die Dateneingabe in einem Formularfeld kontrolliert wird, - dann genügt JavaScript.
Wenn Sie in Ihrer Web-Page eine komfortable Benutzerführung oder Berechnungen oder Simulationen ablaufen lassen wollen, dann brauchen Sie Java. Java eignet sich außerdem nicht nur für Applets und Servlets sondern auch für eigenständige Anwendungen (Applikationen) als eine modernere und bequemere Alternative zu anderen Programmiersprachen wie Cobol, Fortran, Basic und C.
Wenn man den Zugriff auf bestimmte Web-Pages auf bestimmte Personen oder Personengruppen einschränken will, dann soll man die dafür im Web-Server vorgesehenen Funktionen verwenden. Alle Web-Server-Produkte erlauben es, den Zugriff auf Client-Rechner einer Domain (also z.B. nur für alle Benutzer innerhalb des Intranet der Firma oder Universität) zu beschränken oder den Zugriff von der Eingabe eines Username und Paßworts abhängig zu machen, also nur für bestimmte Personen verfügbar zu machen (z.B. nur für zahlende Kunden).
Solche Einschränkungen und Paßwort-Kontrollen dürfen grundsätzlich nur am Server erfolgen. Wenn man versucht, Einschränkungen oder Paßwort-Kontrollen mit Applets oder JavaScript am Client durchzuführen, können erfahrene Benutzer den Inhalt der Applets bzw. Scripts ansehen und den darin enthaltenen Schutz einfach umgehen. Man darf, bildlich gesprochen, niemals Schloß und Schlüssel gleichzeitig aus der Hand geben. Ein sicherer Schutz ist nur auf dem Server möglich.
Die von der Web-Server-Software und dem Protokoll HTTP unterstützte Paßwort-Abfrage hat außerdem den Vorteil, dass das vom Benutzer im Web-Browser eingegebene Paßwort verschlüsselt vom Client an den Server übertragen wird und daher gegen Ausspähen geschützt ist.
Falls andere wichtige oder sensible Daten zwischen Client und Server übertragen werdem (z.B. nach Eintragen im einem Formular an das CGI-Programm), dann muss diese Übertragung verschlüsselt erfolgen. Zu diesem Zweck müssen sowohl der Web-Server als auch der Browser die automatische Verschlüsselung der Daten unterstützen. Dazu werden eine Internet-Verbindung mit SSL (secure socket layer) und das Protkoll https (secure HTTP) verwendet.
Die meisten Firmen, Universitäten und Institutionen verwenden Workflow-Systeme oder Datenbanken für die Verwaltung von umfangreichen Informationen und Daten. Deshalb ist es in den letzten Jahren immer wichtiger geworden, über das World-Wide Web nicht bloß einzelne Dokumente verfügbar zu machen, die in Form von eigenständigen HTML-Files erstellt und mühsam laufend aktualisiert werden müssen, sondern einen möglichst direkten Zugriff auf die jederzeit aktuellen Informationen und Daten in den Workflow-Systemen und Datenbanken zu ermöglichen.
Dies wird als "dynamische Web-Pages" bezeichnet und über Schnittstellen zwischen dem Web-Server und dem Workflow-System bzw. der Datenbank realisiert, oder über integrierte Server-Systeme, bei denen das Workflow-System bzw. das Datenbanksystem direkt von den Web-Browsern über das Protokoll HTTP bzw. die CGI-Schnittstelle angesprochen werden kann und das System die Ergebnisse im Format HTML an den Web-Browser ausgibt. Beispiele dafür sind z.B. der im Workflow-System Lotus Notes integrierte Domino-Server oder der im Datenbanksystem Oracle integrierte Web-Server.
<a href>-Befehl
gibt dem Leser die Möglichkeit, von seinem
Client
aus eine kurze Nachricht per
E-Mail
an eine bestimmte Mail-Adresse zu senden,
z.B. an den
Autor
der
Web-Page.
Der Benutzer muss das Subject, den Text der Nachricht und seine Absender-Adresse am Client eintippen, und er muss die Erlaubnis zum Absenden von Mail haben.
In
HTML 4.0
ist vorgesehen, dass man das "Subject" (den Betreff)
in der Form
<a href="mailto:mailadresse" title="subject">...</a>
angeben kann.
Dies wird allerdings derzeit noch von vielen Web-Browsern ignoriert,
d.h. die E-Mail wird von denen zwar richtig zugestellt,
aber eventuell nicht mit dem angegebenen Subject.
Es gibt ein paar Web-Browser,
die stattdessen die nicht genormte Form
<a href="mailto:mailadresse?subject">...</a>
unterstützen.
Diese Form sollte man aber niemals verwenden,
denn sie führt bei allen anderen Web-Browsern dazu,
dass die E-Mail überhaupt nicht zugestellt
werden kann,
weil sie eine durch das "Anhängsel" ungültige
Mail-Adresse aufweist.
Ob das Absenden von E-Mail innerhalb des Web-Browsers funktioniert, hängt von der Konfiguration am Client-Rechner ab. Außerdem sind "richtige" Mail-Programme für das Versenden von Electronic Mail im allgemeinen besser geeignet, insbesondere für wichtige oder längere Mail-Texte und für das Lesen von Antworten.
Deshalb und auch für den Fall, dass der Benutzer die Web-Page auf einem Drucker ausdruckt, sollte man die Mail-Adresse nicht nur "versteckt" im URL sondern auch sichtbar im Text angeben.
Beispiel:
- - - Die Eingabe von
Wenn Ihnen meine HTML-Einführung gefällt, sagen Sie es bitte Ihren Kollegen. <br> Wenn Sie darin Fehler finden, sagen Sie es bitte <a href="mailto:partl@mail.boku.ac.at">mir</a>. <br> Meine Mail-Adresse ist <a href="mailto:partl@mail.boku.ac.at">partl@mail.boku.ac.at</a>.- - - bewirkt eine Darstellung wie
Wenn Ihnen meine HTML-Einführung gefällt,
sagen Sie es bitte Ihren Kollegen.
Wenn Sie darin Fehler finden, sagen Sie es bitte
mir.
Meine Mail-Adresse ist
partl@mail.boku.ac.at.
- - -