| Syntax | <FORM>...</FORM> |
|---|---|
| Attribut- Spezifikationen |
|
| Inhalte |
|
| Beinhaltet in | APPLET, BLOCKQUOTE, BODY, CENTER, DD, DEL, DIV, FIELDSET, IFRAME, INS, LI, MAP, NOFRAMES, NOSCRIPT, OBJECT, TD, TH |
Das FORM-Element definiert ein interaktives Formular. Das Element sollte die Formular-Kontrollen--INPUT, SELECT, TEXTAREA und BUTTON-- beinhalten durch die der User interagiert.
Wenn der User das Formular versendet, durch ein INPUT oder BUTTON-Element mit dem TYPE=submit, werden die Formularwerte an die URI verschickt, die im für FORM notwendigen ACTION-Attribut steht. ACTION verweist normalerweise auf ein Server-seitiges Script, das das verschickte Formular entgegennimmt und verarbeitet.
Eine Mailto-URI (z.B., mailto:liam@htmlhelp.com) ist ebenfalls als ACTION zulässig, dies wird jedoch nicht von allen Browern unterstützt. Auch wenn der Browser dies unterstützt, Mailto-Formulare sind lästig, wenn sie fehlschlagen dem User Feedback zu bieten, wenn das Formular versendet wurde und wenn Browser beginnen Privacy Warnings anzuzeigen, bevor das Formular an die E-Mailadresse versendet wird.
Kostenlose CGI scripts existieren z.B für handling Formulare; einige sind auch remotely hosted für Autoren, deren Provider nicht gestatten CGI-Scripts lokal laufen zulassen.
Wie der Inhalt des Fornulars an den Server versendet wird, hängt von den METHOD- and ENCTYPE-Attributen ab. Wenn das Attribut METHOD=get ist (der Standardwert), wird das Formular als HTTP GET Anfrage an die URI, die im ACTION-Attribut spezifiziert wird, mit dem Anhang ?form_data versendet.
Durch die Verwendung der get-Methode wird die Formularübertragung komplett als Anhang an die URL abgewickelt. Das kann in soweit von Vorteil sein, da es das Abspeichern als Lesezeichen im Browser erlaubt. Wie auch immer, die Datenmenge des Formulars, die mit der get-Methode übertragen werden kann, ist auf die maximale Länge der URL begrenzt, die der Server und der Browser verarbeiten können. Um sicher zu gehen, sollte für jedes Formular, dessen Inhalt mehr als bloß einige hundert Zeichen beinhalten könnte das Attribut METHOD=post verwendet werden.
Mit dem METHOD-Wert post, wird der Formularinhalt als HTTP POST Anfrage, wo sich die Daten im Body der Anfrage befinden, verschickt. Die meisten aktuellen Browser können noch keine Lesezeichen für POST Anfragen abspeichern, jedoch erbt POST nicht die Längenbeschränkungen von GET.
Das ENCTYPE-Attribut spezifiziert den Inhaltstyp, der in der Übertragung des Formulars verwendet wird, und legt standardmäßig application/x-www-form-urlencoded fest. Dieser Inhaltstyp führt dazu, dass in Name/Value-Paaren, die zum Server als name1=value1&name2=value2... verschickt werden, die Leerzeichen durch "+" und reservierte Zeichen (wie "#") durch "%HH" ersetzt werden, wobei HH der ASCII-Code des Zeichens in hexadezimal darstellt. Zeilenumbrüche werden als "%0D%0A" verschlüsselt-- ein Carriage Return (Wagenrücklauf) gefolgt von einem Zeilenwechsel.
Autoren sollten generell nur einen verschiedenen ENCTYPE verwenden, wenn das Formular ein TYPE=file INPUT-Element beinhaltet, in einem solchen Fall sollte das Attribut ENCTYPE multipart/form-data und METHOD post sein. Das Format der multipart/form-data Anfragen ist RFC 2388.
Werkzeuge, wie z.B. cg-eye ermöglichen Autoren sehr einfach eine Anfrage zu generieren und sich diese anzuschauen, indem eine Übertragung eines Formulars simuliert wird. Wie auch immer, Autoren brauchen sich dabei keine Sorgen wegen des exakten Formats der Übertragung zu machen; CGI Libraries, die CGI.pm verwenden, behandeln get und post Übertragungen übersichtlich als application/x-www-form-urlencoded oder multipart/form-data.
Das ACCEPT-CHARSET-Attribut spezifiziert eine Liste von Zeichenverschlüsselungen, die vom Form Handler akzeptiert werden. Der Wert besteht aus einer Liste von "Zeichensätzen", die durch Kommata und/oder Leerzeichen getrennt sind. Der Standardwert ist UNKNOWN und ist normalerweise die Zeichenverschlüsselung, die verwendet wird um das Dokument, das FORM beinhaltet, zu übertragen.
Das ACCEPT-Attribut gibt eine durch Kommata-getrennte Liste von Mediatypen an, die für den File Upload akzeptiert werden, wodurch dem Browser ermöglicht wird unpassende Dateien herauszufiltern. Aktuelle Browser ignorieren das ACCEPT-Attribut jedoch generell.
Das TARGET-Attribut wird in Zusammenhang mit Frames verwendet um den Frame angeben zu können in dem die Formularantwort angezeigt werden soll. Wenn kein Frame mit solch einem Namen existiert, wird die Antwort in einem neuen Fenster angezeigt bis diese vom User überschrieben wird. Spezielle Framenamen beginnen mit einem Unterstrich:
In HTML 4, ist der Wert des TARGET-Attributs case-insensitive, sodass _top und _TOP die gleiche Bedeutung haben. Wie auch immer, die meisten Browser behandeln den Wert des Target-Attributs als case-sensitive und bemerken nicht, dass _TOP die gleiche Bedeutung wie _top besitzt.
Das FORM-Element nimmt ebenso eine weitere Anzahl von Attributen entgegen, die Client-seitige Scripting Actions für verschiedene Events spezifiziert. Zusätzlich zu den Kern-Events, wie die meisten Elemente auch, akzeptiert FORM die folgenden Event-Attribute:
Das NAME-Attribut, zum FORM-Element in HTML 4.01 hinzugefügt, spezifiziert einen Namen, der auf das Formular für ein Client-seitiges Script verweist. Das ID-Attribut bietet die gleiche Funktion, jedoch unterstützen ältere Browser wie Netscape 4.x nur das NAME-Attribut.
HTML 4.0 Referenz ~ Elemente nach Funktion ~ Elemente - alphabetisch
Copyright © 1998-2007 Liam Quinn. All rights reserved.