Formulare in HTML und XHTML

[Robert Bienert]

Hallo zusammen!

Auf meiner Homepage habe ich einige kleinere Include-Dateien, z.B. damit jede Seite die gleiche Navigation hat. Diese Dateien wurden bislang immer in HTML eingefügt, was keinerlei Probleme mit sich brachte. Nun verwende ich eine der Dateien in einer XHTML-Datei und da habe ich den Salat:

Der W3C-Validator ist der Meinung, "This page is not Valid -//W3C//DTD XHTML 1.0//EN!"

Line 45, column 44: there is no attribute "name" (explain...).
    <form action="./suche/" method="get" name="Suche" id="Suche">

(URI der Seite: http://www.robertbienert.de/datenschutz.php, Validator-Ergebnis: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.robertbienert.de%2Fdatenschutz.php)

Hab ich da was verpasst, dass nur noch id statt name (in XHTML) verwendet werden darf?

Grüße, Robert

[egal]

Hab ich da was verpasst, dass nur noch id statt name (in XHTML) verwendet werden darf?

also von name hab ich sowieso noch nie was gehört, also scheint das
falsch zu sein!

[wahsaga]

hi,

Hab ich da was verpasst, dass nur noch id statt name (in XHTML) verwendet werden darf?

also von name hab ich sowieso noch nie was gehört, also scheint das
falsch zu sein!

bullshit.

http://selfhtml.teamone.de/html/formulare/eingabe.htm#felder

<img src="/images/06.gif" border="0" alt="">

wenn's für dieter nuhrs berühmten spruch auch eine message-grafik gäbe, bekämst du die jetzt im gegenzug serviert ...

gruss,
wahsaga

[Robert Bienert]

<img src="/images/06.gif" border="0" alt="">

OK, ich hätte vielleicht besser Meinung statt HTML drüber geschrieben ...

Robert

[Thomas Luethi]

Hallo,

OK, ich hätte vielleicht besser Meinung statt HTML drüber geschrieben ...

Lass Dich nicht von einem - erst noch anonym auftretenden - Troll in
die Irre fuehren!
"egal" ist ein Idiot, Ignorant und Wichtigtuer. Aber ist ja auch "egal"...

Der Themenbereich HTML war voellig korrekt.

Und Deine Frage war durchaus berechtigt.

Einerseits ist der Validator durchaus nicht perfekt.

Andererseits steht es ja nirgends _ausdruecklich_,
dass das name-Attribut fuer <form> in XHTML 1.0 Strict
(im Gegensatz zu XHTML 1.0 Transitional) verboten ist.

Unter http://www.w3.org/TR/xhtml1/#h-4.10 steht ja
nur folgendes:
  "Note that in XHTML 1.0, the name attribute of these elements
  (a, applet, form, frame, iframe, img, and map, weiter oben erwaehnt, Anmerkung TL)
  is formally deprecated, and will be removed in a subsequent version of XHTML."

Da steht also nur, dass es "deprecated" ist und demnaechst
abgeschafft werde. Daraus kann man hoechstens implizit
schliessen, dass es bereits in XHTML 1.0 Strict nicht mehr
erlaubt sei, sondern nur noch in Transitional.

Verwirrlich finde ich zudem, dass das name-Attribut fuer <a>
auch in XHTML 1.0 Strict offenbar noch erlaubt ist, und aus
Gruenden der Rueckwaerts-Kompatibilitaet fuer Anker
sogar noch empfohlen wird:
http://www.w3.org/TR/xhtml1/#C_8
  "Many existing HTML clients don't support the use
  of ID-type attributes in this way, so identical values
  may be supplied for both of these attributes to ensure
  maximum forward and backward compatibility
  (e.g., <a id="foo" name="foo">...</a>)."
Weiter unten steht auch dort:
  "Finally, note that XHTML 1.0 has deprecated the name attribute
  of the a, applet, form, frame, iframe, img, and map elements,
  and it will be removed from XHTML in subsequent versions."

<a> und <form> werden da also in einem Atemzug genannt.
Dass in XHTML 1.0 Strict das name-Attribut bei <a> noch erlaubt ist,
bei <form> aber nicht mehr, kann man nur "durch Zufall" herausfinden,
entweder, wenn man wie Du ueber eine Validator-Meldung stolpert,
oder indem man die DTDs selbst minutioes studiert und vergleicht...

http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-strict.dtd_a
http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-strict.dtd_form

Gruesse,

Thomas

[molily]

Verwirrlich finde ich zudem, dass das name-Attribut fuer <a> auch in XHTML 1.0 Strict offenbar noch erlaubt ist, und aus Gruenden der Rueckwaerts-Kompatibilitaet fuer Anker sogar noch empfohlen wird

Ich denke zwar nicht, dass die Working Group das so sieht, vor allem ist es ja bereits die zweite Ausgabe, aber ich persönlich halte das fehlende name-Attribut für form in Strict für einen groben Fehler, der der Logik der Kompatibilitätsrichtlinien widerspricht. Andererseits fehlt das name-Attribut auch bei img, sodass die üblichen Bilderwechsel über document.images['bildname'] genauso fehlschlagen wie der Zugriff auf document.forms['formularname']. Da wie du sagst a und map aus der Reihe tanzen, mutmaße ich, dass dahinter kein konsequentes System steckt, sondern einfach danach geurteilt wurde, ob das Wegkürzen des name-Attributs sehr große Kompatibilitätsprobleme verursacht. Bei map und a konnte das name-Attribut nicht deprecated sein, weil dann keine praktische HTML-Kompatibilität mehr möglich wäre (Anker lassen sich nunmal in prä-HTML4-Clients nicht ohne name lösen und map auch nicht, weil usemap einen Verweis auf ein name-Attribut erwartet), bei form und img ist nur Scripting betroffen.

Dass name bei object nicht deprecated ist, liegt übrigens wahrscheinlich daran, dass es eine besondere Aufgabe in Formularen hat, siehe http://www.w3.org/TR/html401/interact/forms.html#object-control. Das unterstützt meines Wissens aber sowieso kein Browser, das passt also in die Inkonsequenz...

[MudGuard]

Hi,

Ich denke zwar nicht, dass die Working Group das so sieht, vor allem ist es ja bereits die zweite Ausgabe, aber ich persönlich halte das fehlende name-Attribut für form in Strict für einen groben Fehler, der der Logik der Kompatibilitätsrichtlinien widerspricht.

Naja - das name-Attribut des form-Attributs ist aus HTML-Sicht nicht notwendig - es wird nicht in HTML verwendet - im Gegensatz zum name-Attribut der input-, textarea-, select- und button-Elemente, deren name-Attribut ja beim Formularabschicken übertragen wird.

Andererseits fehlt das name-Attribut auch bei img

Auch hier ist das name-Attribut aus HTML-Sicht nicht erforderlich.

Da wie du sagst a und map aus der Reihe tanzen,

Hier ist das name-Attribut wieder aus HTML-Sicht [früher, moderne Browser sollten auch mit id zurechtkommen] erforderlich gewesen - als Anker.

Anker lassen sich nunmal in prä-HTML4-Clients nicht ohne name lösen und map auch nicht

Eben, genau deswegen - hier hat das name-Attribut eine Bedeutung in HTML.

bei form und img ist nur Scripting betroffen.

Auch das paßt doch.

Dass name bei object nicht deprecated ist, liegt übrigens wahrscheinlich daran, dass es eine besondere Aufgabe in Formularen hat, siehe http://www.w3.org/TR/html401/interact/forms.html#object-control. Das unterstützt meines Wissens aber sowieso kein Browser, das passt also in die Inkonsequenz...

Ich seh die Inkonsequenz nicht.
Da, wo das name-Attribut nur für Scripting erforderlich ist, ist es weggefallen. In den anderen Fällen nicht.
Wobei sich die Notwendigkeit nicht nach real existierenden Browsern, sondern nach den HTML-Standards richtet.

cu,
Andreas

[molily]

Ich seh die Inkonsequenz nicht.
Da, wo das name-Attribut nur für Scripting erforderlich ist, ist es weggefallen. In den anderen Fällen nicht.

Jaja, welcher Sinn steckt dahinter? Die Aussage meines Postings war eben, dass ich die Unterscheidung zwischen »aus HTML-Sicht erforderlich« und »nur für Scripting erforderlich« bzw. »Bedeutung für HTML an sich« und »Bedeutung über HTML hinausgehend« nicht als Krtierium anerkenne, anhand dessen Elemente und Attribute einerseits zwecks Abwärtskompatibilität im Strict-Typ belassen werden und andere sang- und klanglos ausge-x-t werden, als wären sie irrelevant und nutzlos. Ich sehe beide Arten im Prinzip als gleich wichtig hinsichtlich der Kompatibilität an, und damit meine ich nicht die formale Kompatibilität und theoretische Funktionalität gemäß den Specs. Die Elemente und Attribute, die primär bzw. praktisch vollständig dem Scripting dienen, sind für mich genauso Bestandteil von HTML wie die anderen. Die Streichung dieser führt praktisch dazu, dass simpelste Scripte in XHTML nicht kompatibel mit HTML-Clients sein können, die über Prä-DOM unter Verwendung von HTML 4-Techniken durchaus bedienbar wären. Ob das W3C Scripting nun für vernachlässigbar hält, ändert nichts an der Tatsache, dass das Dokument als Gesamtgebilde nicht kompatibel zum HTML 4 Strict-Äquivalent mit ein paar name-Attributen mehr ist.

Wenn ich eine Sprache HTML-kompatibel nenne und davon rede, dass ein Dokument sowohl als HTML als auch als X(HT)ML verarbeitet werden kann, dann muss ich solche Umstände beachten. Ansonsten ist es teilweise kompatibel, teilweise nicht kompatibel. Beziehungsweise unter Umständen kompatibel. Dann deckt die Kompatibilität das Minimum ab, nämlich die Verarbeitung als HTML-Dokument an sich, alles drumherum wird ausgeklammert und für unwichtig befunden. Die Kompatibilität wird an die Voraussetzung gebunden, dass der Client das DOM beherrscht.
Natürlich findet sich in der Spec kein Wort dazu, der Leser wird nirgends darauf hingewiesen, das zeigt wohl die Unbekümmertheit. Aber es ist ja nicht einmal gesagt, dass XHTML im Prinzip nicht HTML-kompatibel sein kann und die sogenannte HTML-Kompatibilität nur auf unzureichenden HTML-Implementationen basiert.

Wobei sich die Notwendigkeit nicht nach real existierenden Browsern, sondern nach den HTML-Standards richtet.

Na wunderprächtig. Es ist waschechter Selbstbetrug, angesichts dessen von Kompatibilität zu sprechen (Phrasen wie »Although there is no requirement for XHTML 1.0 documents to be compatible with existing user agents, in practice this is easy to accomplish.«), und man verschließt die Augen vor den tatsächlichen Umständen.

[at]

Hallo.

Jaja, welcher Sinn steckt dahinter? Die Aussage meines Postings war eben, dass ich die Unterscheidung zwischen »aus HTML-Sicht erforderlich« und »nur für Scripting erforderlich« bzw. »Bedeutung für HTML an sich« und »Bedeutung über HTML hinausgehend« nicht als Krtierium anerkenne, anhand dessen Elemente und Attribute einerseits zwecks Abwärtskompatibilität im Strict-Typ belassen werden und andere sang- und klanglos ausge-x-t werden, als wären sie irrelevant und nutzlos.

Über den Sinn oder besser Unsinn dieser Umstände wirst du mit kaum jemandem streiten müssen. Aber auch wenn du dieses Kriterium für dich nicht anerkennen magst, scheint es mir in sich schlüssig, wenngleich eben wenig weitsichtig. Weitblick -- also der Blick über den eigenen Tellerand hinaus -- war meines Erachtens aber noch nie die Stärke des W3C.
MfG, at

[Thomas Luethi]

Hallo Robert,

Line 45, column 44: there is no attribute "name" (explain...).
    <form action="./suche/" method="get" name="Suche" id="Suche">
Hab ich da was verpasst, dass nur noch id statt name (in XHTML) verwendet werden darf?

Du solltest noch erwaehnen, dass Du XHTML 1.0 Strict benutzt.

In XHTML 1.0 Transitional ist das name-Attribut bei form noch erlaubt:
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-transitional.dtd_form

in XHTML 1.0 Strict dagegen ist es nicht mehr erlaubt:
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-strict.dtd_form

Lies auch:
http://www.w3.org/TR/xhtml1/#h-4.10

Gruesse,

Thomas

[Robert Bienert]

Hallo Robert,

in XHTML 1.0 Strict dagegen ist es nicht mehr erlaubt:
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd

Hab ich dann auch gesehen. Ich wusste das gar nicht und war dann vom Validator-Ergebnis ein wenig überrascht, zumal bei SELFHTML nichts genaues darüber steht.

Lies auch:
http://www.w3.org/TR/xhtml1/#h-4.10

Interessant.

Gruesse,

Thomas

Danke,
Robert