Problem mit form und submit

Status
Nicht offen für weitere Antworten.
Ich habs mal nachgelesen. Da steht folgendes:
n SGML-based HTML 4 certain elements were permitted to omit the end tag; with the elements that followed implying closure. XML does not allow end tags to be omitted. All elements other than those declared in the DTD as EMPTY must have an end tag. Elements that are declared in the DTD as EMPTY can have an end tag or can use empty element shorthand (see Empty Elements).
Hervorhebung von mir.

Unter "empty element shorthand" steht:
Empty elements must either have an end tag or the start tag must end with />. For instance, <br/> or <hr></hr>. See HTML Compatibility Guidelines for information on ways to ensure this is backward compatible with HTML 4 user agents.
Siehe http://www.w3.org/TR/2002/REC-xhtml1-20020801/#h-4.6
 
Zuletzt bearbeitet:
Das ist aber alles hinfällig, da das textarea-Element nicht zu den inhaltsleeren Elementen (Standalone-Tags) zählt.
 
Na und?

Es gibt da die HTML compatibility guidelines http://www.w3.org/TR/2002/REC-xhtml1-20020801/#guidelines
Die besagen, wie man xhtml xml-Konform hinschreiben sollte, damit ein HTML4 User Agent damit auch noch umgehen kann. Ein HTML4 user agent bekommt html und kann auch nur html verarbeiten. So wie eben der IE. Auch, wenn Du im DOCTYPE behauptest, das wäre eine xhtml Datei, für den IE ist und bleibt es html. Was Anderes kann der eben nicht. Ob Etwas html oder xhtml ist, entscheidet der http response header Content-Type. Da steht entweder text/html oder application/xhtml+xml (oder notfalls application/xml oder sogar text/xml). Ein Browser, der xml und damit xhtml kann, muß xml können! Also richtig xml. Also kann ich jedes Element, das leer ist, aus welchem Grund auch immer es leer ist, so abkürzen, wie es das xml vorsieht.

Da die xhtml Seiten bei mir mit application/xhtml+xml ausgeliefert werden (der Grund, warum der IE damit Nichts anfangen konnte), ist auch der Grund, warum ich die xml Schreibweise vollständig verwenden kann, und warum ein entsprechender Browser diese Datei auch tatsächlich als xhtml und nicht als html behandelt.

Alte Browser wie der IE bekommen bei mir per automatic content negotiation text/html geliefert, wo dann solche Elemente nach html-Norm geschlossen werden.

BTW: Ich verwende übrigens xhtml 1.1
 
Zuletzt bearbeitet:
Um diese Diskussion mal zu beenden, habe ich eine email an Shane McCarron geschickt, einen der Autoren der xhtml 1.1 Spezifikation beim w3c. Hier meine mail (Auszug):
I have an xhtml 1.1 file which, among other things, contains a construct like
<textarea/> (with attributes, of course). So it uses the xml shorthand type
of closing the element. Is this valid or not?

I'm not interested in backwards compatibility here. For backwards
compatibility i have the same content in an html 4.01 strict format. Which
file is sent is determined by the http accept header via automatic content
negotiation. The files are sent with the correct mime type
(application/xhtml+xml for the xhtml 1.1 version, text/html for the html 4.01
version). So for the xhtml construct backwards compatibility is absolutely no
issue. The only question is: Is ist _valid_ or not?

Und hier seine Antwort:
Sure its valid. You can shorthand any XML element that does not have
content. Have you tried feeding the page to the W3C validator? It
should just work.
 
Ok, dann lass dir von dem guten Mann auch gleich den passenden Browser dazu schicken ;)

Musst dann nur noch hoffen, dass deine Besucher den dann auch benutzen.


Abgesehen davon mal kurz angemerkt... zu Beginn dieses Themas hattest du mitnichten ein xhtml1.1-File, sondern ein Ungültiges Dokument ohne DOCTYPE.
Jetzt hast du ein ungültiges XHTML1.1-Dokument, welches schätzungsweise 70% deiner Besucher nicht zu Gesicht bekommen...Glückwunsch :)
 
Ok, dann lass dir von dem guten Mann auch gleich den passenden Browser dazu schicken ;)
Kein mir bekannte Browser, der xhtml kann, hat damit auch nur das geringste Problem.
Musst dann nur noch hoffen, dass deine Besucher den dann auch benutzen.
Es ist mir wurscht, welchen Browser die Besucher verwenden. Es tut jeder. Selbst mit Lynx gibt's kein Problem.
Abgesehen davon mal kurz angemerkt... zu Beginn dieses Themas hattest du mitnichten ein xhtml1.1-File, sondern ein Ungültiges Dokument ohne DOCTYPE.
Das ist richtig.
Jetzt hast du ein ungültiges XHTML1.1-Dokument, welches schätzungsweise 70% deiner Besucher nicht zu Gesicht bekommen...Glückwunsch :)
Das ist nicht richtig. Es ist ein güliges, valides xhtml 1.1 Dokument. Wenn 70% der Besucher dieses Format nie zu Gesicht bekommen, ist mir das auch egal, denn es gibt die gleiche Seite noch mal im html 4.01 Format, zum Beispiel speziell für den IE. Dieser sendet entweder keinen http accept header und bekommt dann per default html geliefert, oder er sendet dort explizit text/html und bekommt dann ebenfalls explizit das geliefert.

Bei anderen Browsern hängt es von der Browsereinstellung ab. Wenn der http accept header konfiguriert ist, bekommen diese anderen Browser das geliefert, was sie haben wollen: xhtml 1.1 oder html 4.01, ganz nach Wunsch.

Um dieses automatic content negotiation zu nutzen wird bei der url einfach die "file extension" weggelassen. Es gibt also zur Zeit beispielsweise die Dateien http://www.rorkvell.de/prj/flexblog/admin/newblog.xhtml und http://www.rorkvell.de/prj/flexblog/admin/newblog.html

Um nun die für den jeweiligen Browser optimale Version zu bekommen, lautet die Adresse einfach http://www.rorkvell.de/prj/flexblog/admin/newblog

Allerdings kümmere ich mich derzeit noch kaum um die html-Variante, da andere Teile des Projekts erst mal weitaus wichtiger sind.

Die html Version wird automatisch per xsl aus der xhtml Version erstellt, das ist nur einen Bruchteil einer Sekunde zusätzlicher Aufwand für den Computer bei der Erstellung.

Also, wo ist das Problem?
 
So rein aus Interesse mal nachgefragt, wozu das Ganze?
XHTML1.1 ist ja nun nicht gerade das, was in der Zukunft eine Rolle spielen wird.

Da bin ich ganz und gar gegenteiliger Ansicht. Allenfalls sei noch hinzugefügt, dass in der fernen Zukunft allerdings weniger xhtml 1.1, sondern eher xhtml 2.0 eine Rolle spielen wird.

Ich habe mir das Ergebnis des Validators grad mal angeschaut. Ganze 4 Fehler, und davon ist einer nicht mein Fehler, sondern ein Fehler des Validators:

there is no attribute "schemaLocation"
Falsch! Laut Spezifikation kann das html-Element dieses Attribut haben.
http://www.w3.org/TR/xhtml11/conformance.html#s_conform Punkt 4

value of attribute "method" cannot be "POST"; must be one of "get", "post"
Na toll. Dann schreibe ich es eben klein.

document type does not allow element "input" here; missing one of "ins", "del", "h1", "h2", "h3", "h4", "h5", "h6", "p", "div", "address", "fieldset" start-tag.
Hrmpf, also bei xhtml darf ein input nur als Kindelement z.B. eines fieldset vorkommen. Auch kein Problem.

Und der vierte Fehler ist das Gleiche noch mal, mit dem anderen input.

Kurz korrigiert, jetzt validiert es. Und noch immer mit
Code:
<textarea/>
statt
Code:
<textarea></textarea>

Nachtrag: Ich hab schemaLocation wieder reingemacht, auch wenn sich der Validator beschwert.
 
Zuletzt bearbeitet:
Status
Nicht offen für weitere Antworten.

Neue Beiträge

Zurück