Bei diesem Dokument handelt es sich um eine Übersetzung eines W3C-Textes. Dieser Text ist urheberrechtlich geschützt; bitte beachten Sie die nachfolgenden Hinweise des Originaldokuments. Die Rechte an der Übersetzung liegen bei den Übersetzern und dem Verlag Addison-Wesley. Die Übersetzung hat keine durch das W3C legitimierte, normative Wirkung. Das einzige maßgebliche Dokument ist das englische Original.
Bitte senden Sie Fehler und Korrekturen zur deutschen Fassung an die Übersetzer.
Kommentare der Übersetzer, die als solche gekennzeichnet sind, unterliegen dem Urheberrecht der Übersetzer. Sie sind nicht Bestandteil des Ursprungsdokuments.
Diese Veröffentlichung ist eine Vorveröffentlichung.
Kein Teil dieses Textes darf kopiert werden. Alle Rechte vorbehalten.
Nach Abschluss der Arbeit wird das endgültige Dokument unter
der oben angegebenen Adresse veröffentlicht. Die jetzige Veröffentlichung
während der laufenden Arbeit dient zur Information von Interessierten und
zur Prüfung durch die Fachöffentlichkeit. Sollten Sie Fehler finden oder
Verbesserungsvorschläge haben, schicken Sie diese bitte per Mail
an die Übersetzer.
Folgende Teile liegen noch in Englisch vor und müssen noch
in deutscher Fassung
generiert werden: (a) Gesamtinhaltsverzeichnis (b) Index
Inhaltsverzeichnis
Ein HTML-Formular ist ein Abschnitt eines Dokuments, der normalen Inhalt, Bezeichner, spezielle Elemente, genannt Steuerelemente (Checkboxen, Radio-Buttons, Menüs und so weiter) und Beschriftungen für diese Steuerelemente enthält. Benutzer »vervollständigen« ein Formular im Allgemeinen durch die Veränderung seiner Steuerelemente, bevor das Formular zu einer Anwendung übertragen wird (zum Beispiel zu einem Webserver, zu einem Mailserver und so weiter).
Hier ist ein einfaches Formular, das Beschriftungen, Radio-Buttons und Schaltflächen (Zurücksetzen oder Absenden des Formulars) enthält:
<FORM action="http://somesite.com/prog/adduser" method="post"> <P> <LABEL for="vorname">Vorname: </LABEL> <INPUT type="text" id="vorname"><BR> <LABEL for="nachname">Nachname: </LABEL> <INPUT type="text" id="nachname"><BR> <LABEL for="email">E-Mail: </LABEL> <INPUT type="text" id="email"><BR> <INPUT type="radio" name="geschlecht" value="Maskulin"> Maskulin<BR> <INPUT type="radio" name="geschlecht" value="Feminin"> Feminin<BR> <INPUT type="submit" value="Absenden"> <INPUT type="reset" value="Zurücksetzen"> </P> </FORM>
Anmerkung: Diese Spezifikation gibt in den Unterabschnitten von Anmerkungen zu Formularen (Anhang B) detailiertere Informationen über Formulare.
Benutzer interagieren mit Formularen über benannte Steuerelemente.
Der »Steuerelementname« eines Steuerelements wird über sein name-Attribut zugewiesen. Der Geltungsbereich des name-Attributs für ein Steuerelement innerhalb eines FORM-Elements ist das FORM-Element.
Anmerkung der Übersetzer:
Ein kleines Beispiel wird das verdeutlichen. Wir gehen von einer Seite aus, die die beiden folgenden Formulare enthält:
<FORM ACTION="adduser.pl" METHOD="get"> <P> <LABEL FOR="vorname">Vorname: </LABEL> <INPUT TYPE="text" NAME="vorname"><BR> <LABEL FOR="nachname">Nachname: </LABEL> <INPUT TYPE="text" NAME="nachname"><BR> <LABEL FOR="email">E-Mail: </LABEL> <INPUT TYPE="text" NAME="email"><BR> <INPUT TYPE="radio" NAME="geschlecht" VALUE="Maskulin"> Maskulin<BR> <INPUT TYPE="radio" NAME="geschlecht" VALUE="Feminin"> Feminin<BR> <INPUT TYPE="submit" VALUE="Absenden"> <INPUT TYPE="reset" VALUE="Zurücksetzen"> </P> </FORM> <FORM ACTION="searchuser.pl" METHOD="get"> <P> <LABEL FOR="vorname">Vorname: </LABEL> <INPUT TYPE="text" NAME="vorname"><BR> <LABEL FOR="nachname">Nachname: </LABEL> <INPUT TYPE="text" NAME="nachname"><BR> <INPUT TYPE="submit" VALUE="Absenden"> <INPUT TYPE="reset" VALUE="Zurücksetzen"> </P> </FORM>
Beim Absenden des ersten Formulars wird das Perl-Skript
adduser.pl
aufgerufen, beim zweiten
searchuser.pl
. Beide erwarten Parameter, nämlich
die Werte des ausgefüllten Formulars. Füllt man die
Formulare aus und schaut nach dem Absenden den URI an, so erkent
man deutlich, dass die Werte des jeweiligen Formulars
übertragen werden.
Der URI nach dem Übertragen des ersten Formulars:
...adduser.pl?vorname=Albert&nachname=Meier&email=albert.meier%40irgendwo.de&geschlecht=Maskulin
Der URI nach dem Übertragen des zweiten Formulars:
...searchuser.pl?vorname=Ruth&nachname=Schulze
»vorname« und »nachname« werden in beiden Fällen übergeben, jedoch mit dem eingegebenen Wert des jeweiligen Formulars.
Jedes Steuerelement hat sowohl einen Anfangswert als auch einen aktuellen Wert, beide Werte sind Zeichenketten. In den individuellen Definitionen der Steuerelemente finden Sie Informationen über Anfangswerte und mögliche Beschränkungen für Werte, die vom Steuerelement auferlegt werden. Im Allgemeinen wird der Anfangswert über das Attribut value des Steuerelements angegeben. Jedoch wird der Anfangswert eines TEXTAREA-Elements durch seinen Inhalt angegeben, und der Anfangswert eines OBJECT-Elements in einem Formular wird durch die Implementierung des Objekts bestimmt (das heißt, er liegt außerhalb des Geltungsbereichs dieser Spezifikation).
Der »aktuelle Wert« eines Steuerelements wird zuerst auf seinen Anfangswert gesetzt. Danach kann der aktuelle Wert des Steuerelements durch Interaktion des Benutzers oder durch Skripte verändert werden.
Der Anfangswert eines Steuerelements verändert sich nicht. Wird ein Forumlar zurückgesetzt, werden folglich die aktuellen Werte aller Steuerelemente auf ihre Anfangswerte zurückgesetzt. Hat ein Steuerelement keinen Anfangswert, ist die Auswirkung einer Zurücksetzung für dieses Steuerelement nicht definiert.
Wird ein Formular für die Verarbeitung übertragen, fassen einige Steuerelemente ihre Namen mit den aktuellen Werten zu einem Paar zusammen, und diese Paare werden mit dem Formular übertragen. Steuerelemente, für die solche Name/Wert-Paare übertragen werden, nennt man erfolgreiche Steuerelemente (successful controls).
HTML definiert die folgenden Steuerelementtypen:
Autoren sollten die Skriptsprache für das Skript einer allgemeinen Schaltfläche über eine Deklaration der Standard-Skriptsprache (siehe Abschnitt 18.2.2) angeben (mit dem Element META).
Autoren können Schaltflächen mit den Elementen BUTTON oder INPUT erzeugen. Details über die Angabe unterschiedlicher Schaltflächentypen finden Sie in den Definitionen dieser Elemente.
Einige Checkboxen in einem Formular können den gleichen Steuerelementnamen teilen. So gestatten es Checkboxen zum Beispiel, mehrere Werte für die gleiche Eigenschaft auszuwählen. Checkbox-Steuerelemente werden mit dem Element INPUT erzeugt.
Zu allen Zeiten ist genau ein Radio-Button in einer
Gruppe ausgewählt. Ist für keines der
<INPUT>-Elemente einer Gruppe mit Radio-Button das Attribut
CHECKED
gesetzt, dann muss das Benutzerprogramm den
ersten Radio-Button der Gruppe zu Beginn
auswählen.
Weil sich die Vorgehensweise der Benutzerprogramme voneinander unterscheidet, sollten Autoren sicherstellen, dass in jeder Gruppe mit Radio-Buttons einer zu Beginn eingeschaltet ist.
Die Elemente, die zur Erzeugung eines Steuerelements verwendet werden, stehen im Allgemeinen innerhalb eines FORM-Elements, können aber auch außerhalb eines FORM-Elements stehen, wenn sie zur Erzeugung von Benutzerschnittstellen verwendet werden. Dies wird in Abschnitt 18.2.3, »Eingebettete Ereignisse« besprochen. Beachten Sie, dass Steuerelemente außerhalb eines Formulars keine erfolgreichen Steuerelemente werden können.
<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- interactive form --> <!ATTLIST FORM %attrs; -- %coreattrs, %i18n, %events -- action %URI; #REQUIRED -- server-side form handler -- method (GET|POST) GET -- HTTP method used to submit the form-- enctype %ContentType; "application/x-www-form-urlencoded" accept %ContentTypes; #IMPLIED -- list of MIME types for file upload -- name CDATA #IMPLIED -- name of form for scripting -- onsubmit %Script; #IMPLIED -- the form was submitted -- onreset %Script; #IMPLIED -- the form was reset -- accept-charset %Charsets; #IMPLIED -- list of supported charsets -- >
Start-Tag: erforderlich, End-Tag: erforderlich
Attributdefinitionen
Der Standardwert für dieses Attribut ist die reservierte Zeichenkette »UNKNOWN«. Benutzerprogramme können diesen Wert als die Zeichenkodierung interpretieren, die für die Übertragung des Dokuments mit dem FORM-Element verwendet wurde.
An anderer Stelle definierte Attribute
Das Element FORM ist ein Container für Steuerelemente. Es gibt an:
Ein Formular kann zusätzlich zu Formular-Steuerelementen Text und Auszeichnungen (Absätze, Listen und so weiter) enthalten.
Das folgende Beispiel zeigt ein Formular, das vom Programm »adduser« verarbeitet werden muss, wenn es übertragen wird. Das Formular wird über die HTTP-Methode »post« an das Programm gesendet.
<FORM action="http://somesite.com/prog/adduser" method="post"> ...Formularinhalt... </FORM>
Informationen darüber, wie ein Benutzerprogramm die Formulardaten für Server herrichten muss und wie es die erwarteten Antworten verarbeiten soll, finden sie im Abschnitt »Formularübertragung«.
Anmerkung: Die weiterführende Diskussion über das Verhalten der Server, die Formulardaten erhalten, liegt nicht im Geltungsbereich dieser Spezifikation.
<!ENTITY % InputType "(TEXT | PASSWORD | CHECKBOX | RADIO | SUBMIT | RESET | FILE | HIDDEN | IMAGE | BUTTON)" > <!-- attribute name required for all but submit and reset --> <!ELEMENT INPUT - O EMPTY -- form control --> <!ATTLIST INPUT %attrs; -- %coreattrs, %i18n, %events -- type %InputType; TEXT -- what kind of widget is needed -- name CDATA #IMPLIED -- submit as part of form -- value CDATA #IMPLIED -- Specify for radio buttons and checkboxes -- checked (checked) #IMPLIED -- for radio buttons and check boxes -- disabled (disabled) #IMPLIED -- unavailable in this context -- readonly (readonly) #IMPLIED -- for text and passwd -- size CDATA #IMPLIED -- specific to each type of field -- maxlength NUMBER #IMPLIED -- max chars for text fields -- src %URI; #IMPLIED -- for fields with images -- alt CDATA #IMPLIED -- short description -- usemap %URI; #IMPLIED -- use client-side image map -- ismap (ismap) #IMPLIED -- use server-side image map -- tabindex NUMBER #IMPLIED -- position in tabbing order -- accesskey %Character; #IMPLIED -- accessibility key character -- onfocus %Script; #IMPLIED -- the element got the focus -- onblur %Script; #IMPLIED -- the element lost the focus -- onselect %Script; #IMPLIED -- some text was selected -- onchange %Script; #IMPLIED -- the element value was changed -- accept %ContentTypes; #IMPLIED -- list of MIME types for file upload -- >
Start-Tag: erforderlich, End-Tag: verboten
Attributdefinitionen
text
oder password
. In diesem Fall
bezieht sich der Wert auf die Anzahl (Integer) der Zeichen.An anderer Stelle definierte Attribute
Der durch das INPUT-Element definierte Steuerelementtyp ist abhängig vom Wert des type-Attributs:
Anmerkung: Anwendungsentwickler sollten berücksichtigen, dass dieser Mechanismus nur geringen Schutz bedeutet. Auch wenn das Benutzerprogramm das Passwort vor den Augen möglicher Beobachter versteckt, wird es als normaler Text zum Server übertragen und könnte von jedem gelesen werden, der auf einer niedrigeren Ebene Zugang zum Netzwerk hat.
Wird ein Zeigergerät verwendet, um auf ein Bild zu klicken, dann wird das Formular übertragen und die Klick-Koordinaten werden an den Server weitergeleitet. Der x-Wert wird in Pixeln von der linken Seite des Bildes und der y-Wert wird in Pixeln von der Oberseite des Bildes gezählt. Die übermittelten Daten enthalten name.x=x-Wert und name.y=y-Wert, wobei »name« der Wert des Attributs name ist, und x-Wert sowie y-Wert die Werte der x- bzw. y-Koordinaten sind.
Zeigt der Server abhängig vom angeklickten Ort unterschiedliche Reaktionen, werden Benutzer von nicht graphischen Browsern benachteiligt sein. Aus diesem Grund sollten Autoren alternative Möglichkeiten in Erwägung ziehen:
Das folgende Beispiel eines HTML-Fragments definiert ein einfaches Formular, das es dem Benutzer gestattet, einen Vornamen, einen Familiennamen, eine E-Mail-Adresse und ein Geschlecht anzugeben. Wird die Absenden-Schaltfläche aktiviert, wird das Formular an das Programm übertragen, welches über das action-Attribut angegeben ist.
<FORM action="http://somesite.com/prog/adduser" method="post"> <P> Vorname: <INPUT type="text" name="vorname"><BR> Nachname: <INPUT type="text" name="nachname"><BR> E-Mail: <INPUT type="text" name="email"><BR> <INPUT type="radio" name="geschlecht" value="Maskulin"> Maskulin<BR> <INPUT type="radio" name="geschlecht" value="Feminin"> Feminin<BR> <INPUT type="submit" value="Absenden"> <INPUT type="reset" value="Zurücksetzen"> </P> </FORM>
Dieses Formular könnte wie folgt angezeigt werden:
Im Abschnitt über das Element LABEL erörtern wir die Erstellung von Beschriftungen wie "Vorname".
Anmerkung der Übersetzer:
Formularelemente werden in unterschiedlichen Browsern und erst recht unter verschiedenen Betriebssystemen stark voneinander abweichend dargestellt. Die folgenden Bilder des Formulars von oben, lediglich erweitert um ein Menü-Element, illustrieren dies:
Auch Stylesheets ändern nichts an betriebssystemspezifischen Darstellungen von Steuerelementen. Wir empfehlen daher beim Einsatz von Formularen, nicht zu versuchen, optisch starre Layouts zu erstellen. Dieser Versuch wird sehr wahrscheinlich scheitern.
Im nächsten Beispiel wird die JavaScript-Funktion verify aufgerufen, wenn das onclick-Event auftritt:
<HEAD> <META http-equiv="Content-Script-Type" content="text/javascript"> </HEAD> <BODY> <FORM action="..." method="post"> <P> <INPUT type="button" value="Drück Mich" onclick="verify()"> </FORM> </BODY>
Mehr Informationen über Skripte und Events finden Sie im Abschnitt Eingebettete Ereignisse.
Das folgende Beispiel zeigt, wie der Inhalt einer vom Benutzer angegebenen Datei mit einem Formular übertragen werden kann. Der/die BenutzerIn wird nach seinem/ihrem Namen und einer Liste mit Dateinamen gefragt, deren Inhalte mit dem Formular übertragen werden sollen. Durch Angabe des enctype-Werts »multipart/form-data« wird der Inhalt jeder Datei in einem eigenen Bereich eines Multipart-Dokuments »verpackt«.
<FORM action="http://server.dom/cgi/handle" enctype="multipart/form-data" method="post"> <P> Wie heißt Du? <INPUT type="text" name="name_des_absenders"> Welche Dateien verschickst Du? <INPUT type="file" name="name_der_dateien"> </P> </FORM>
<!ELEMENT BUTTON - - (%flow;)* -(A|%formctrl;|FORM|FIELDSET) -- push button --> <!ATTLIST BUTTON %attrs; -- %coreattrs, %i18n, %events -- name CDATA #IMPLIED value CDATA #IMPLIED -- sent to server when submitted -- type (button|submit|reset) submit -- for use as form button -- disabled (disabled) #IMPLIED -- unavailable in this context -- tabindex NUMBER #IMPLIED -- position in tabbing order -- accesskey %Character; #IMPLIED -- accessibility key character -- onfocus %Script; #IMPLIED -- the element got the focus -- onblur %Script; #IMPLIED -- the element lost the focus -- >
Start-Tag: erforderlich, End-Tag: erforderlich
Attributdefinitionen
An anderer Stelle definierte Attribute
Schaltflächen, die mit dem BUTTON-Element erzeugt werden, funktionieren wie Schaltflächen, die mit dem INPUT-Element erzeugt wurden, bieten ledoch mehr Darstellungsmöglichkeiten: das BUTTON-Element kann Inhalt haben. Zum Beispiel funktioniert ein BUTTON-Element mit Bild wie ein INPUT-Element, dessen type-Attribut auf »image« gesetzt ist und kann ihm gleichen, das Element BUTTON gestattet jedoch Inhalt.
Visuelle Benutzerprogramme könnten BUTTON-Schaltflächen mit Relief und Auf/Ab-Bewegung darstellen, wenn sie angeklickt werden, während sie INPUT-Schaltflächen als »flaches« Bild anzeigen könnten.
Das folgende Beispiel erweitert das vorherige Beispiel, jedoch erzeugt es Absenden- und Zurücksetzen-Schaltflächen mit BUTTON statt mit INPUT. Den Schaltflächen werden über das IMG-Element Bilder zugewiesen.
<FORM action="http://somesite.com/prog/adduser" method="post"> <P> Vorname: <INPUT type="text" name="vorname"><BR> Nachname: <INPUT type="text" name="nachname"><BR> E-Mail: <INPUT type="text" name="email"><BR> <INPUT type="radio" name="genus" value="Maskulin"> Maskulin<BR> <INPUT type="radio" name="genus" value="Feminin"> Feminin<BR> <BUTTON name="senden" value="senden" type="submit"> Absenden<IMG src="/icons/wow.gif" alt="wow"></BUTTON> <BUTTON name="reset" type="reset"> Zurücksetzen<IMG src="/icons/oops.gif" alt="oops"></BUTTON> </P> </FORM>
Rufen Sie sich in Erinnerung, dass Autoren alternativen Text für ein IMG-Element angeben müssen.
Es ist nicht gestattet, eine Imagemap mit einem IMG zu verknüpfen, das im Inhalt eines BUTTON-Elements steht.
UNGÜLTIGES
BEISPIEL
Das Folgende ist in HTML nicht gestattet:
<BUTTON> <IMG src="foo.gif" usemap="..."> </BUTTON>
<!ELEMENT SELECT - - (OPTGROUP|OPTION)+ -- option selector --> <!ATTLIST SELECT %attrs; -- %coreattrs, %i18n, %events -- name CDATA #IMPLIED -- field name -- size NUMBER #IMPLIED -- rows visible -- multiple (multiple) #IMPLIED -- default is single selection -- disabled (disabled) #IMPLIED -- unavailable in this context -- tabindex NUMBER #IMPLIED -- position in tabbing order -- onfocus %Script; #IMPLIED -- the element got the focus -- onblur %Script; #IMPLIED -- the element lost the focus -- onchange %Script; #IMPLIED -- the element value was changed -- >
Start-Tag: erforderlich, End-Tag: erforderlich
Attributdefinitionen für SELECT
An anderer Stelle definierte Attribute
Das SELECT-Element erzeugt ein Menü. Jede Auswahlmöglichkeit wird durch ein OPTION-Element repräsentiert. Ein SELECT-Element muss mindestens ein OPTION-Element enthalten.
Das OPTGROUP-Element gestattet Autoren, die Auswahlmöglichkeiten logisch anzuordnen. Dies ist besonders hilfreich, wenn der Benutzer aus einer langen Liste auswählen muss; Gruppen verwandter Auswahlmöglichkeiten sind einfacher zu verstehen und zu behalten als eine einfache lange Liste mit Auswahlmöglichkeiten. In HTML 4 müssen alle OPTGROUP-Elemente direkt innerhalb eines SELECT-Elements angegeben werden (das heißt, Gruppen dürfen nicht verschachtelt werden).
Keine oder mehrere Möglichkeiten können für den Benutzer vorausgewählt sein. Benutzerprogramme sollten wie folgt feststellen, welche Möglichkeiten ausgewählt sind:
Im Anfangszustand ist die erste Möglichkeit ausgewählt, wenn kein SELECTED-Attribut für irgendein <OPTION>-Element angegeben ist.
Weil sich die Vorgehensweise der Benutzerprogramme unterscheidet, sollten Autoren sicherstellen, dass jedes Menü als Voreinstellung ein vorausgewähltes OPTION-Element enthält.
<!ELEMENT OPTGROUP - - (OPTION)+ -- option group --> <!ATTLIST OPTGROUP %attrs; -- %coreattrs, %i18n, %events -- disabled (disabled) #IMPLIED -- unavailable in this context -- label %Text; #REQUIRED -- for use in hierarchical menus -- >
Start-Tag: erforderlich, End-Tag: erforderlich
Attributdefinitionen für OPTGROUP
An anderer Stelle definierte Attribute
Anmerkung: Entwickler seien darauf hingewiesen, dass in zukünftigen Versionen von HTML die Gruppierungsmechanismen eventuell erweitert werden und verschachtelte Gruppen gestattet werden (das heißt, OPTGROUP-Elemente können verschachtelt werden). Dies wird Autoren die Möglichkeit geben, eine reichhaltigere Hierarchie der Auswahlmöglichkeiten darzustellen.
<!ELEMENT OPTION - O (#PCDATA) -- selectable choice --> <!ATTLIST OPTION %attrs; -- %coreattrs, %i18n, %events -- selected (selected) #IMPLIED disabled (disabled) #IMPLIED -- unavailable in this context -- label %Text; #IMPLIED -- for use in hierarchical menus -- value CDATA #IMPLIED -- defaults to element content -- >
Start-Tag: erforderlich, End-Tag: optional
Attributdefinitionen für OPTION
An anderer Stelle definierte Attribute
Wird eine Menüauswahl dargestellt, sollten Benutzerprogramme den Wert des label-Attributs des OPTION-Elements als Auswahlmöglichkeit präsentieren. Ist dieses Attribut nicht angegeben, sollten Benutzerprogramme den Inhalt des OPTION-Elements verwenden.
Das label-Attribut des OPTGROUP-Elements gibt die Beschriftung für eine Gruppe mehrerer Auswahlmöglichkeiten an.
In diesem Beispiel erzeugen wir ein Menü, das dem Benutzer erlaubt zu entscheiden, welche der sieben verschiedenen Software-Komponenten installiert werden sollen. Die erste und zweite Komponente sind vorausgewählt, können aber vom Benutzer deselektiert werden. Die übrigen Komponenten sind nicht vorausgewählt. Das size-Attribut sagt aus, dass das Menü nur vier Zeilen haben soll, auch wenn der Benutzer aus sieben Möglichkeiten auswählen kann. Die anderen Auswahlmöglichkeiten sollten durch einen Scroll-Mechanismus verfügbar gemacht werden.
Dem SELECT folgen die Absenden- und Zurücksetzen-Schaltflächen.
<FORM action="http://somesite.com/prog/component-select" method="post"> <P> <SELECT multiple size="4" name="component-select"> <OPTION selected value="Komponente_1_a">Komponente_1</OPTION> <OPTION selected value="Komponente_1_b">Komponente_2</OPTION> <OPTION>Komponente_3</OPTION> <OPTION>Komponente_4</OPTION> <OPTION>Komponente_5</OPTION> <OPTION>Komponente_6</OPTION> <OPTION>Komponente_7</OPTION> </SELECT> <INPUT type="submit" value="Absenden"><INPUT type="reset" value="Zurücksetzen"> </P> </FORM>
Nur ausgewählte Optionen werden erfolgreich (unter Verwendung des Steuerelementnamens»component-select«). Sind keine Optionen ausgewählt, ist das Steuerelement nicht erfolgreich und weder der Name noch der Wert werden an den Server übertragen, wenn das Formular übertragen wird. Beachten Sie, ist das value-Attribut angegeben, gibt es den Anfangswert des Steuerelements an, ansonsten ist es der Inhalt des Elements.
In diesem Beispiel verwenden wir das Element OPTGROUP zur Gruppierung von Optionen. Der folgende Quelltext:
<FORM action="http://somesite.com/prog/someprog" method="post"> <P> <SELECT name="ComOS"> <OPTION selected label="keine" value="keine">Keine</OPTION> <OPTGROUP label="PortMaster 3"> <OPTION label="3.7.1" value="pm3_3.7.1">PortMaster 3 mit ComOS 3.7.1</OPTION> <OPTION label="3.7" value="pm3_3.7">PortMaster 3 mit ComOS 3.7</OPTION> <OPTION label="3.5" value="pm3_3.5">PortMaster 3 mit ComOS 3.5</OPTION> </OPTGROUP> <OPTGROUP label="PortMaster 2"> <OPTION label="3.7" value="pm2_3.7">PortMaster 2 mit ComOS 3.7</OPTION> <OPTION label="3.5" value="pm2_3.5">PortMaster 2 mit ComOS 3.5</OPTION> </OPTGROUP> <OPTGROUP label="IRX"> <OPTION label="3.7R" value="IRX_3.7R">IRX mit ComOS 3.7R</OPTION> <OPTION label="3.5R" value="IRX_3.5R">IRX mit ComOS 3.5R</OPTION> </OPTGROUP> </SELECT> </FORM>
repräsentiert die folgende Gruppeneinteilung:
Keine PortMaster 3 3.7.1 3.7 3.5 PortMaster 2 3.7 3.5 IRX 3.7R 3.5R
Optische Benutzerprogramme können Benutzern gestatten, über ein hierarchisches Menü aus Optionsgruppen auszuwählen oder über einen anderen Mechanismus, der die Auswahlstruktur widerspiegelt.
Ein graphisches Benutzerprogramm könnte dies so darstellen:
Diese Graphik zeigt ein SELECT-Element, das als kaskadierende Menüauswahl dargestellt wird. Die oberste Beschriftung zeigt den aktuell ausgwählten Wert (PortMaster 3, 3.7.1). Der Benutzer hat zwei kaskadierende Menüs aufgerufen, aber den neuen Wert noch nicht ausgewählt (PortMaster 2, 3.7). Beachten Sie, dass jedes kaskadierende Menü die Beschriftung eines OPTGROUP- oder OPTION-Elements trägt.
Anmerkung der Übersetzer:
Die Darstellung derartige Menüs ist von Benutzerprogramm zu Benutzerprogramm sehr verschieden. In der gleichen Situation wie eben sieht ein Nutzer des Internet Explorer 5 unter MAC OS dieses:
Er sieht in diesem Moment zum Beispiel nicht mehr, dass er aktuell den Wert »PortMaster 3, 3.7.1« ausgewählt hat, weil er sich mit der Maus inzwischen über »Postmaster 2« befindet
<!ELEMENT TEXTAREA - - (#PCDATA) -- multi-line text field --> <!ATTLIST TEXTAREA %attrs; -- %coreattrs, %i18n, %events -- name CDATA #IMPLIED rows NUMBER #REQUIRED cols NUMBER #REQUIRED disabled (disabled) #IMPLIED -- unavailable in this context -- readonly (readonly) #IMPLIED tabindex NUMBER #IMPLIED -- position in tabbing order -- accesskey %Character; #IMPLIED -- accessibility key character -- onfocus %Script; #IMPLIED -- the element got the focus -- onblur %Script; #IMPLIED -- the element lost the focus -- onselect %Script; #IMPLIED -- some text was selected -- onchange %Script; #IMPLIED -- the element value was changed -- >
Start-Tag: erforderlich, End-Tag: erforderlich
Attributdefinitionen
An anderer Stelle definierte Attribute
Das Element TEXTAREA erzeugt ein mehrzeiligesTexteingabe-Steuerelement. Benutzerprogramme sollten den Inhalt dieses Elements als den Anfangswert des Steuerelements verwenden und diesen als Text zu Beginn darstellen.
Dieses Beispiel erzeugt ein TEXTAREA-Steuerelement mit 20 Zeilen und 80 Spalten, das zwei Zeilen Anfangstext enthält. Dem Element TEXTAREA folgt eine Absenden- und eine Zurücksetzen-Schaltfläche.
<FORM action="http://somesite.com/prog/text-read" method="post"> <P> <TEXTAREA name="thetext" rows="20" cols="80"> Erste Zeile mit Anfangstext. Zweite Zeile mit Anfangstext. </TEXTAREA> <INPUT type="submit" value="Absenden"><INPUT type="reset" value="Zurücksetzen"> </P> </FORM>
Die Angabe des readonly-Attributs gestattet Autoren die Anzeige von unveränderbarem Text in einer TEXTAREA. Dies unterscheidet sich davon, normal ausgezeichneten Text in einem Dokument zu verwenden, weil der Wert von TEXTAREA mit dem Formular übertragen wird.
ISINDEX ist missbilligt. Dieses Element erzeugt ein einzeiliges Texteingabe-Steuerelement. Autoren sollten das INPUT-Element verwenden, um Texteingabe-Steuerelemente zu erzeugen.
Die formale Definition ist in der Transitional DTD nachzulesen.
Attributdefinitionen
An anderer Stelle definierte Attribute
Das Element ISINDEX erzeugt ein einzeiliges Texteingabe-Steuerelement, das eine beliebige Anzahl von Zeichen erlaubt. Benutzerprogramme können den Wert des prompt-Attributs als Titel für die Eingabeaufforderung verwenden.
MISSBILLIGTES BEISPIEL:
Die folgende ISINDEX-Deklaration:
<ISINDEX prompt="Geben Sie Ihren Suchbegriff an: ">
kann durch ein INPUT-Element wie folgt ausgedrückt werden:
<FORM action="..." method="post"> <P>Geben Sie Ihren Suchbegriff an: <INPUT type="text"></P> </FORM>
Semantik von ISINDEX: Zur Zeit ist die Semantik für ISINDEX nur wohldefiniert, wenn der Basis-URI für das einschließende Dokument ein HTTP-URI ist. In der Praxis ist die Eingabezeichenkette auf Latin-1 beschränkt, weil es keinen Mechanismus für den URI gibt, einen anderen Zeichensatz anzugeben.
Einige Formular-Steuerelemente haben bereits automatisch eine zugehörige Beschriftung (Schaltflächen), während die meisten keine haben (Textfelder, Auswahlfelder, Radio-Buttons und Menüs).
Für Steuerelemente, die eine implizite Beschriftung haben, sollten Benutzerprogramme den Wert des value-Attributs als Beschriftungszeichenkette verwenden.
Das Element LABEL wird für die Beschriftung der Steuerelemente verwendet, die keine implizite Beschriftung haben.
<!ELEMENT LABEL - - (%inline;)* -(LABEL) -- form field label text --> <!ATTLIST LABEL %attrs; -- %coreattrs, %i18n, %events -- for IDREF #IMPLIED -- matches field ID value -- accesskey %Character; #IMPLIED -- accessibility key character -- onfocus %Script; #IMPLIED -- the element got the focus -- onblur %Script; #IMPLIED -- the element lost the focus -- >
Start-Tag: erforderlich, End-Tag: erforderlich
Attributdefinitionen
An anderer Stelle definierte Attribute
Das Element LABEL kann dazu verwendet werden, Steuerelementen Informationen hinzuzufügen. Jedes LABEL-Element ist genau einem Formular-Steuerelement zugeordnet.
Das for-Attribut verknüpft eine Beschriftung explizit mit einem anderen Steuerelement: der Wert des for-Attributs muss der gleiche sein, wie der des id-Attributs des verbundenen Steuerelements. Mehr als ein LABEL kann mit dem gleichen Steuerelement verknüpft werden, wenn mehrere Verweise über das for-Attribut erzeugt werden.
Dieses Beispiel erzeugt eine Tabelle, die dazu verwendet wird, zwei Texteingabe-Steuerelemente und ihre entsprechenden Beschriftungen auszurichten. Jede Beschriftung ist mit genau einer Texteingabe verknüpft:
<FORM action="..." method="post"> <TABLE> <TR> <TD><LABEL for="vname">Vorname</LABEL> <TD><INPUT type="text" name="vorname" id="vname"> <TR> <TD><LABEL for="nname">Nachname</LABEL> <TD><INPUT type="text" name="nachname" id="nname"> </TABLE> </FORM>
Dieses Beispiel erweitert ein vorheriges Beispielformular um LABEL-Elemente.
<FORM action="http://somesite.com/prog/adduser" method="post"> <P> <LABEL for="vorname">Vorname: </LABEL> <INPUT type="text" id="vorname"><BR> <LABEL for="nachname">Nachname: </LABEL> <INPUT type="text" id="nachname"><BR> <LABEL for="email">E-Mail: </LABEL> <INPUT type="text" id="email"><BR> <INPUT type="radio" name="geschlecht" value="Maskulin"> Maskulin<BR> <INPUT type="radio" name="geschlecht" value="Feminin"> Feminin<BR> <INPUT type="submit" value="Senden"> <INPUT type="reset" value="Zurücksetzen"> </P> </FORM>
Um eine Beschriftung mit einem anderen Steuerelement implizit zu verbinden, muss das Steuerelement innerhalb des Inhalts des LABEL-Elements liegen. In diesem Fall sollte das LABEL nur ein Steuerelement enthalten. Die Beschriftung selbst kann vor oder nach dem entsprechenden Steuerelement angebracht werden.
In diesem Beispiel verknüpfen wir implizit zwei Beschriftungen mit zwei Texteingabe-Steuerelementen:
<FORM action="..." method="post"> <P> <LABEL> Vorame <INPUT type="text" name="vorname"> </LABEL> <LABEL> <INPUT type="text" name="nachname"> Nachname </LABEL> </P> </FORM>
Beachten Sie, dass diese Technik nicht angewandt werden kann, wenn eine Tabelle für das Layout verwendet wird, in der die Beschriftung in einer Zelle ist und das entsprechende Steuerelement in einer anderen.
Bekommt ein LABEL-Element den Fokus, reicht es den Fokus weiter an sein entsprechendes Steuerelement. Der folgende Abschnitt über Zugriffstasten zeigt Beispiele.
Beschriftungen können von Benutzerprogrammen auf verschiedene Art dargestellt werden (zum Beispiel optisch, durch Sprachsynthesizer gesprochen und so weiter).
<!-- #PCDATA is to solve the mixed content problem, per specification only whitespace is allowed there! --> <!ELEMENT FIELDSET - - (#PCDATA,LEGEND,(%flow;)*) -- form control group --> <!ATTLIST FIELDSET %attrs; -- %coreattrs, %i18n, %events -- > <!ELEMENT LEGEND - - (%inline;)* -- fieldset legend --> <!ATTLIST LEGEND %attrs; -- %coreattrs, %i18n, %events -- accesskey %Character; #IMPLIED -- accessibility key character -- >
Start-Tag: erforderlich, End-Tag: erforderlich
Attributdefinitionen für LEGEND
An anderer Stelle definierte Attribute
Das Element FIELDSET gestattet Autoren, thematisch vergleichbare Steuerelemente und Beschriftungen zu gruppieren. Die Gruppierung von Steuerelementen vereinfacht Benutzern, deren Zweck zu verstehen, gleichzeitig wird die Tabulatornavigation für optische Benutzerprogramme und die Sprachnavigation für sprachorientierte Benutzerprogramme erleichtert. Die sorgfältige Verwendung dieser Elemente macht Dokumente zugänglicher.
Das Element LEGEND gestattet Autoren, einem FIELDSET eine Beschriftung zu verleihen. Die Beschriftung verbessert die Zugänglichkeit, wenn das FIELDSET nicht visuell ausgegeben wird.
In diesem Beispiel erzeugen wir ein Formular, dass man in der Arztpraxis ausfüllen könnte. Es ist in drei Bereiche aufgeteilt: persönliche Informationen, medizinische Vergangenheit und aktuelle Medikation. Jeder Bereich enthält Steuerelemente zur Eingabe der entsprechenden Informationen.
<FORM action="..." method="post"> <P> <FIELDSET> <LEGEND>Persönliche Informationen</LEGEND> Nachname: <INPUT name="pers_nachname" type="text" tabindex="1"> Vorname: <INPUT name="pers_vorname" type="text" tabindex="2"> Adresse: <INPUT name="pers_adresse" type="text" tabindex="3"> ...mehr persönliche Informationen... </FIELDSET> <FIELDSET> <LEGEND>Medizinische Vergangenheit</LEGEND> <INPUT name="geschichte_krankheit" type="checkbox" value="Pocken" tabindex="20"> Pocken <INPUT name="geschichte_krankheit" type="checkbox" value="Mumps" tabindex="21"> Mumps <INPUT name="geschichte_krankheit" type="checkbox" value="Schwindel" tabindex="22"> Schwindel <INPUT name="geschichte_krankheit" type="checkbox" value="Schnupfen" tabindex="23"> Schnupfen ...mehr medizinische Vergangenheit... </FIELDSET> <FIELDSET> <LEGEND>Aktuelle Medikation</LEGEND> Nehmen Sie zur Zeit irgendwelche Medikamente? <INPUT name="medikamente_jetzt" type="radio" value="Ja" tabindex="35">Ja <INPUT name="medikamente_jetzt" type="radio" value="Nein" tabindex="35">Nein Wenn Sie zur Zeit Medikamente nehmen, geben Sie diese bitte im Textfeld unten an: <TEXTAREA name="aktuelle_medikamente" rows="20" cols="50" tabindex="40"> </TEXTAREA> </FIELDSET> </FORM>
Beachten Sie, dass wir die optische Darstellung des Formulars dadurch verbessern könnten, dass wir die Elemente innerhalb der FIELDSET-Elemente ausrichten (mit Stylesheets), Farbe und Informationen zur Schriftart hinzufügen (mit Stylesheets), Skripte hinzufügen (sagen wir, um das Textfeld zur aktuellen Medikation nur zu öffnen, wenn der Benutzer angibt, dass er zur Zeit Medikamente einnimmt) und vieles mehr.
In einem HTML-Dokument muss ein Element vom Benutzer den Fokus zugewiesen bekommen, um aktiv zu werden und seine Aufgabe zu erfüllen. Zum Beispiel müssen Benutzer einen durch das A erzeugten Verweis aktivieren, um dem angegebenen Verweis zu folgen. Ähnlich müssen Benutzer einer TEXTAREA den Fokus zuweisen, um dort Text eingeben zu können.
Es gibt verschiedene Wege, einem Element den Fokus zuzuweisen:
Attributdefinitionen
Die Tabulator-Reihenfolge definiert die Reihenfolge, in der die Elemente den Fokus erlangen, wenn der Benutzer über die Tastatur navigiert. Die Tabulator-Reihenfolge kann Elemente enthalten, die innerhalb anderer Elemente verschachtelt sind.
Elemente, die den Fokus erlangen können, sollten durch Benutzerprogramme nach folgenden Regeln angesteuert werden:
Die folgenden Elemente unterstützen das tabindex-Attribut: A, AREA, BUTTON, INPUT, OBJECT, SELECT und TEXTAREA.
In diesem Beispiel wird die Tabulator-Reihenfolge wie folgt sein: das BUTTON-Element, die INPUT-Elemente in Reihenfolge (beachten Sie, dass »feld1« und die Schaltfläche (button) den gleichen Tab-Index teilen, »feld1« jedoch später im Zeichenstrom erscheint) und schließlich der Link, der durch das Element A erzeugt wird.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <HTML> <HEAD> <TITLE>Ein Dokument mit FORM</TITLE> </HEAD> <BODY> ...etwas Text... <P>Gehe zu der <A tabindex="10" href="http://www.w3.org/">W3C-Webseite.</A> ...noch mehr... <BUTTON type="button" name="get-database" tabindex="1" onclick="get-database"> Hole die aktuelle Datenbank. </BUTTON> ...noch mehr... <FORM action="..." method="post"> <P> <INPUT tabindex="1" type="text" name="feld1"> <INPUT tabindex="2" type="text" name="feld2"> <INPUT tabindex="3" type="submit" name="submit"> </P> </FORM> </BODY> </HTML>
Tabulator-Tasten: Die Tastenfolge, die eine Tabulator-Navigation oder eine Elementaktivierung hervorruft, hängt von der Konfiguration des Benutzerprogramms ab (zum Beispiel wird die »Tab«-Taste zur Navigation verwendet und die »Enter«-Taste zur Aktivierung des ausgewählten Elements).
Benutzerprogramme können ebenso Tastenfolgen zur entgegengesetzten Navigation durch die Tabulator-Reihenfolge verwenden. Wenn das Ende (oder der Anfang) der Tabulator-Reihenfolge erreicht ist, sollten Benutzerprogramme wieder zurück zum Anfang (oder zum Ende) schalten.
Attributdefinitionen
Das Drücken einer Zugriffstaste, die einem Element zugeordnet ist, gibt dem Element den Fokus. Die Aktion, die eintritt, wenn ein Element den Fokus erhält, ist abhängig vom Element selbst. Wenn zum Beispiel ein Benutzer einen Link aktiviert, der vom A-Element erzeugt wird, folgt das Benutzerprogramm im Allgemeinen dem Link. Aktiviert ein Benutzer einen Radio-Button, verändert das Benutzerprogramm den Wert des Radio-Buttons. Aktiviert ein Benutzer ein Textfeld, erlaubt es die Texteingabe und so weiter.
Die folgenden Elemente unterstützen das Attribut accesskey: A, AREA, BUTTON, INPUT, LABEL, LEGEND und TEXTAREA.
Dieses Beispiel weist der Beschriftung eines INPUT-Steuerelements die Zugriffstaste »U« zu. Das Drücken der Zugriffstaste vergibt den Fokus an die Beschriftung, welche ihrerseits den Fokus an das verbundene Steuerelement weitergibt. Der Benutzer kann dann Text in den INPUT-Bereich eingeben.
<FORM action="..." method="post"> <P> <LABEL for="fuser" accesskey="U"> User Name </LABEL> <INPUT type="text" name="user" id="fuser"> </P> </FORM>
In diesem Beispiel weisen wir einem Verweis, der mit dem A-Element definiert ist, eine Zugriffstaste zu. Das Drücken dieser Zugangstaste führt den Benutzer zu einem anderen Dokument, in diesem Fall zum Inhaltsverzeichnis.
<P><A accesskey="C" rel="Contents" href="http://someplace.com/specification/inhalt.html"> Inhaltsverzeichnis</A>
Der Aufruf der Zugriffstasten hängt vom basierenden System ab. Zum Beispiel muss man auf Rechnern mit MS Windows im Allgemeinen die »Alt«-Taste zusätzlich zur Zugriffstaste drücken. Auf Apple-Systemen muss im Allgemeinen die »cmd«-Taste zusätzlich zur Zugriffstaste gedrückt werden.
Die Darstellung der Zugriffstasten hängt vom Benutzerprogramm ab. Wir empfehlen, dass Autoren die Zugriffstaste in die Beschriftung einschließen oder wo immer die Zugriffsaste verwendet werden muss. Benutzerprogramme sollten den Wert einer Zugriffstaste so darstellen, dass ihre Funktion unterstrichen wird und dass sie von den anderen Zeichen unterschieden werden kann (zum Beispiel durch unterstreichen).
In Kontexten, in denen Benutzereingaben entweder unerwünscht oder irrelevant sind, ist es wichtig, Steuerelemente deaktivieren zu können oder sie schreibgeschützt darzustellen. Zum Beispiel möchte vielleicht jemand eine Absenden-Schaltfläche deaktivieren bis der Benutzer erforderliche Daten eingegeben hat. Oder es möchte ein Autor vielleicht schreibgeschützten Text einschließen, der als Wert mit dem Formular übertragen werden muss. Der folgende Abschnitt beschreibt deaktivierte und schreibgeschützte Steuerelemente.
Attributdefinitionen
Ist es angegeben, hat das Attribut disabled die folgenden Auswirkungen auf ein Element:
Die folgenden Elemente unterstützen das Attribut disabled: BUTTON, INPUT, OPTGROUP, OPTION, SELECT und TEXTAREA.
Dieses Attribut wird vererbt, jedoch überschreiben lokale Deklarationen den vererbten Wert.
Wie deaktivierte Elemente dargestellt werden, ist abhängig vom Benutzerprogramm. Zum Beispiel stellen einige Benutzerprogramme deaktivierte Menüpunkte, Schaltflächenbeschriftungen und so weiter grau dar.
In diesem Beispiel ist das INPUT-Element deaktiviert. Deshalb kann es weder Benutzereingaben entgegennehmen noch wird sein Wert mit dem Formular übertragen.
<INPUT disabled name="fred" value="stone">
Anmerkung der Übersetzer:
disabled
funktioniert bei einer Reihe etwas
älterer Browser nicht.
Anmerkung: Der einzige Weg, den Wert des disabled-Attributs dynamisch zu verändern, ist durch ein Skript.
Attributdefinitionen
Das Attribut readonly gibt an, ob das Steuerelement vom Benutzer verändert werden kann.
Ist es angegeben, hat das readonly-Attribut die folgenden Auswirkungen auf ein Element:
Die folgenden Elemente unterstützen das Attribut readonly: INPUT und TEXTAREA.
Wie schreibgeschützte Elemente dargestellt werden, ist abhängig vom Benutzerprogramm.
Anmerkung: Der einzige Weg, den Wert des readonly-Attributs dynamisch zu verändern, ist durch ein Skript.
Der folgende Abschnitt erklärt, wie Benutzerprogramme Formulardaten zu formularverarbeitenden Programmen übertragen.
Das Attribut method des FORM-Elements gibt die HTTP-Methode an, die zur Übertragung des Formulars an das verarbeitende Programm verwendet wird. Dieses Attribut kann zwei Werte entgegennehmen:
Die Methode »get« sollte verwendet werden, wenn das Formular idempotent ist (das heißt, keine Nebeneffekte hat). Viele Datenbankanfragen haben keinen sichtbaren Nebeneffekt und bieten ideale Anwendungen für die Methode »get«.
Wenn der Dienst zur Verarbeitung eines Formulars Nebeneffekte verursacht (wenn das Formular zum Beispiel eine Datenbank oder ein Abonnement eines Dienstes verändert), sollte die Methode »post« verwendet werden.
Anmerkung: Die Methode »get« beschränkt Formulardatensatzwerte auf ASCII-Zeichen. Nur die Methode »post« (mit enctype=»multipart/form-data«) ist spezifiziert, den gesamten [ISO10646]-Zeichensatz zu unterstützen.
Ein erfolgreiches Steuerelement ist »gültig« für die Übertragung. Für jedes erfolgreiche Steuerelement wird sein Steuerelementname, gepaart mit seinem aktuellen Wert, als Teil des Formulardatensatzes übermittelt. Ein erfolgreiches Steuerelement muss innerhalb eines FORM-Elements definiert sein und muss einen Steuerelementnamen haben.
Jedoch:
Hat ein Steuerelement keinen aktuellen Wert, wenn das Formular übertragen wird, wird von Benutzerprogrammen nicht gefordert, es als ein erfolgreiches Steuerelement zu behandeln.
Überdies sollten Benutzerprogramme die folgenden Steuerelemente nicht als erfolgreich betrachten:
Stylesheet-Angaben nicht dargestellt werden, können dennoch erfolgreich sein. Zum Beispiel:
und Steuerelemente, die aufgrund von<FORM action="..." method="post"> <P> <INPUT type="password" style="display:none" name="unsichtbares-passwort" value="meinpasswort"> </FORM>
wird trotzdem einen Wert zur Folge haben, der mit dem Namen »unsichtbares-passwort« gepaart und mit dem Formular übertragen wird.
Überträgt der Benutzer ein Formular (zum Beispiel durch die Aktivierung einer Absenden-Schaltfläche), verarbeitet das Benutzerprogramm dieses Formular wie folgt.
Ein Formulardatensatz ist eine Folge von Paaren aus Steuerelementname/aktueller Wert, die aus erfolgreichen Steuerelementen erzeugt wird.
Der Formulardatensatz wird dann entsprechend dem Inhaltstyp kodiert, der vom enctype-Attribut des FORM-Elements angegeben wird.
Schließlich werden die kodierten Daten unter Verwendung des vom method-Attribut angegeben Protokolls zum vom action-Attribut ausgewählten verarbeitenden Programm gesendet.
Diese Spezifikation gibt nicht alle gültigen Übertragungsmethoden oder Inhaltstypen an, die mit Formularen verwendet werden könnten. Jedoch müssen HTML 4-Benutzerprogramme die bestehenden Konventionen in den folgenden Fällen erfüllen:
Für jeden anderen Wert von action oder method ist das Verhalten nicht spezifiziert.
Benutzerprogramme sollten die Antwort der HTTP-Transaktionen »get« und »post« darstellen.
Das Attribut enctype des FORM-Elements gibt den Inhaltstypen an, der zur Kodierung des Formulardatensatzes für die Übertragung zum Server notwendig ist. Benutzerprogramme müssen die unten aufgeführten Inhaltstypen unterstützen. Das Verhalten für andere Inhaltstypen ist nicht spezifiziert.
Bitte lesen Sie ebenfalls den Abschnitt »Und-Zeichen in URI-Attributwerten« (B.2.2).
Dies ist der Standard-Inhaltstyp. Formulare, die mit diesem Inhaltstyp übertragen werden, müssen wie folgt kodiert werden:
Anmerkung: Bitte lesen Sie [RFC2388] für weitere Informationen über Datei-Uploads, einschließlich Fragen zur Rückwärtskompatibilität, die Beziehung zwischen »multipart/form-data« und anderen Inhaltstypen, Leistungsfragen und so weiter.
Bitte lesen Sie im Anhang B die »Anmerkungen zur Sicherheit«.
Der Inhaltstyp »application/x-www-form-urlencoded« ist nicht leistungsfähig genug, um große Mengen binärer Daten zu verschicken oder Daten, die Nicht-ASCII-Zeichen enthalten. Der Inhaltstyp »multipart/form-data« sollte zur Übertragung von Formularen verwendet werden, die Dateien, Nicht-ASCII-Daten und binäre Daten enthalten.
Der Inhalt »multipart/form-data« ist konform zu den Regeln aller mehrteiligen MIME-Datenströme, wie in [RFC2045] umrissen. Die Definition von »multipart/form-data« ist verfügbar bei der [IANA]-Registratur.
Eine »multipart/form-data«-Nachricht enthält mehrere Teile, jedes repräsentiert ein erfolgreiches Steuerelement. Die Teile werden in der gleichen Reihenfolge zu dem verarbeitenden Programm gesendet, in der sie im Dokumentfluss auftauchen. Teilgrenzen sollten nicht in irgendeinem Teil der Daten auftauchen; wie dies erreicht wird, liegt außerhalb des Geltungsbereichs dieser Spezifikation
Wie bei allen mehrteiligen MIME-Typen, hat jeder Teil einen optionalen »Content-Type«-Header, dessen Voreinstellung »plain/text« ist. Benutzerprogramme sollten den »Content-Type«-Header angeben, begleitet von einem »charset«-Parameter.
In jedem Teil werden erwartet:
So würde zum Beispiel für ein Steuerelement mit Namen »meinesteuerung« der korrespondierende Teil so angegeben:
Content-Disposition: form-data; name="meinesteuerung"
Wie bei allen MIME-Übertragungen wird »CR LF« (zum Beispiel »%0D%0A«) dazu verwendet, Datenzeilen voneinander zu trennen.
Jeder Teil kann kodiert und der »Content-Transfer-Encoding«-Header übergeben werden, falls der Wert des Teils nicht konform zu der voreingestellten (7 Bit) Kodierung ist (siehe [RFC2045], Abschnitt 6)
Wird der Inhalt einer Datei mit einem Formular übertragen, sollte der Dateiinhalt durch den entsprechenden Inhaltstypen (zum Beispiel »application/octet-stream«) identifiziert werden. Werden mehrere Dateien als Ergebnis eines einfachen Formulareintrags zurückgegeben, sollten sie als »multipart/mixed« eingebettet in »multipart/form-data« zurückgegeben werden.
Das Benutzerprogramm sollte versuchen, einen Dateinamen für jede übertragene Datei zu übergeben. Der Dateiname könnte mit dem Parameter »filename« des »Content-Disposition: form-data«-Headers angegeben werden, oder, im Fall von mehreren Dateien, in einem »Content-Disposition: file«-Header des Teilstückes. Ist der Dateiname des Client-Betriebsystems nicht in US-ASCII, könnte der Dateiname angenähert oder mit einer Methode nach [RFC2045] kodiert werden. Dies ist zum Beispiel in den Fällen praktisch, in denen die hochgeladenen Dateien Verweise zueinander enthalten (zum Beispiel eine TeX-Datei und ihre ».sty«-Hilfsformatbeschreibung).
Das folgende Beispiel zeigt eine »multipart/form-data«-Kodierung. Stellen Sie sich vor, wir haben das folgende Formular:
<FORM action="http://server.com/cgi/handle" enctype="multipart/form-data" method="post"> <P> Wie ist Dein Name? <INPUT type="text" name="submit-name"><BR> Welche Dateien schickst Du? <INPUT type="file" name="files"><BR> <INPUT type="submit" value="Absenden"> <INPUT type="reset"> </FORM>
Gibt der Benutzer in der Texteingabe »Larry« ein, und wählt die Textdatei »file1.txt« aus, könnte das Benutzerprogramm folgende Daten zurücksenden:
Content-Type: multipart/form-data; boundary=AaB03x --AaB03x Content-Disposition: form-data; name="submit-name" Larry --AaB03x Content-Disposition: form-data; name="files"; filename="file1.txt" Content-Type: text/plain ... Inhalt von file1.txt ... --AaB03x--
Hat der Benutzer eine zweite Datei »file2.gif« (ein Bild) ausgewählt, könnte das Benutzerprogramm die Teile wie folgt aufbauen:
Content-Type: multipart/form-data; boundary=AaB03x --AaB03x Content-Disposition: form-data; name="submit-name" Larry --AaB03x Content-Disposition: form-data; name="files" Content-Type: multipart/mixed; boundary=BbC04y --BbC04y Content-Disposition: file; filename="file1.txt" Content-Type: text/plain ... Inhalt von file1.txt ... --BbC04y Content-Disposition: file; filename="file2.gif" Content-Type: image/gif Content-Transfer-Encoding: binary ...Inhalt von file2.gif... --BbC04y-- --AaB03x--
Anmerkung der Übersetzer:
Für diesen Abschnitt sind die Korrekturen in den Errata zu
beachten: »Beschreibung: RFC2388 beschreibt in Abschnitt 4.4
falsch: im Fall von mehreren Dateien, in einem
content-disposition: file
-Header des untergeordneten
Teils.
Diese Syntax erscheint im Beispiel in Abschnitt 17.13.4.2.
Berichtigung: Ändern in content-disposition:
attachment
.«