Diskussion:Websiteentwicklung: XHTML: Formulare

Versionsgeschichte von HTML-Kurs:Textfelder und HTML-Kurs:Auswahllisten[Bearbeiten]

HTML-Kurs:Textfelder[Bearbeiten]

(Aktuell) (Letzte)  13:31, 23. Jan 2005 Progman K (löschantrag)
(Aktuell) (Letzte)  11:15, 14. Dez 2004 80.120.149.118 (→Erklärung:)
(Aktuell) (Letzte)  11:12, 14. Dez 2004 80.120.149.118 (→Erklärung:)
(Aktuell) (Letzte)  11:43, 1. Nov 2004 Swissgenie (Artikel erstellt)
(Aktuell) (Letzte)  22:08, 29. Okt 2004 Swissgenie

HTML-Kurs:Auswahllisten[Bearbeiten]

(Aktuell) (Letzte)  13:35, 23. Jan 2005 Progman K (löschantrag)
(Aktuell) (Letzte)  11:18, 14. Dez 2004 80.120.149.118 (→Herzliche Gratulation!)
(Aktuell) (Letzte)  11:45, 1. Nov 2004 Swissgenie (Kapitel eingefügt)

Aufbau und Beschriftung 5 - 5.6[Bearbeiten]

Durch die Hierarchie scheint es so, als ob die weiteren Formularteile (Radiobuttons etc.) vom mehrzeiligen Textfeld abhängen würden.

Des weiteren sind die Beschriftungen der Punkte ein wenig nichtssagend:
Wenn man sich nur das Inhaltsverzeichnis ansehen und sich nicht für die Beispiele interessieren würde, würde man nie zu den weiteren Formularteilen vordringen.

--Kato-cha 14:14, 31. Mär. 2009 (CEST)[Beantworten]

Was kann ein Submit-Button?[Bearbeiten]

Aus diesem Kapitel wird leider nicht ganz ersichtlich, was ein Submit-Schalter eigentlich genau kann.

Mir ist klar, dass man damit die Formulardaten an einen Server schicken kann.

Kann man einen Submit-Schalter aber auch dann verwenden, wenn die Daten gar nicht weggeschickt, sondern z.B. von einem JavaScript, das sich in separater Datei befindet, weiterverarbeitet werden sollen? Ich habe probiert, das action-Attribut auf ein .js zu adressieren, bin damit aber gescheitert.

Um eine Alternative wäre nicht verlegen. Aber kann einem in einem solchen Fall ein Submit-Schalter überhaupt irgendwie helfen? --Stilfehler 20:46, 13. Sep. 2010 (CEST)[Beantworten]

Bei Buttons, die auf Javascript reagieren sollen, kann die "onclick" Eigenschaft des Buttons gesetzt werden. Außerdem sollte die Javascript-Funktion ein "false" zurückgeben, damit die Seite nicht "submittet" wird. -- ThePacker 20:58, 13. Sep. 2010 (CEST)[Beantworten]

Danke für die schnelle Antwort. Ich werde das einmal probieren. --Stilfehler 21:15, 13. Sep. 2010 (CEST)[Beantworten]

Das geht wunderbar mit einem Submit-Button:

<html><head><title>Test</title>
<script type="text/javascript">
function foo () {

     alert("Eingabe war: " + document.forms[0].elements[0].value);
     return false;
}
</script>
</head><body>
<form onsubmit="return foo();">
Eingabe: <input type="text" size="30">
<input type="submit" value="ok">
</form>
</body></html>

--Jan 19:51, 30. Sep. 2010 (CEST)[Beantworten]

Ich muss zudem sagen, dass ich deine Bearbeitungen recht unglücklich und wenig professionell finde. Sie sind sehr vom persönlichem "Erfahren" des Themas geprägt. Wenn du z.B. was nicht hinbekommst (eben die Submit-Sache), ist das für dich Fakt, dass es auch nicht geht. Die Aussage, dass Textfelder "sehr geeignet" seien für statischen Text, wird dir sicherlich auch kein Profi unterschreiben. Was da vorher stand, war besser, vor allem neutraler. Und warum die Aussage: "Webdesigner, die mit JavaScript programmieren, benötigen gelegentlich ein Feld, in dem sie Text ausschließlich anzeigen möchten."? Die, die keine Webdesigner sind, die JavaScript nutzen, brauchen sowas nie? Auch das unter "Verteckte Felder" liest sich, als ob das Schicken an den Server eine Ausnahme darstellt. Dagegen ist das aber der Regelfall. Dass man den Submit-Button so "verbiegt", dass der Formularinhalt nur lokal mit JS verarbeitet wird, ist ja eher der exotische Fall (und gehört vielleicht auch eher in das JS-Kapitel). --Jan 22:10, 30. Sep. 2010 (CEST)[Beantworten]

Das Beispiel hier drüber ist zum einen kein XHTML, worum es in dem Buch geht, zum anderen braucht ein form-Element immer ein action-Attribut, wo dann immer drinsteht, wohin die eigegebenen Formulardaten geschickt werden. Das gewährleist die Funktion und Zugänglichkeit des Formular. Die Ereignisbehandlung mit onsubmit ist da kein Ersatz, allenfalls eine Alternative, weil so ein Formular ohne server-seitige Verarbeitungsadresse nicht funktioniert, wenn der Nutzer die Interpretation von Skripten deaktiviert hat. XHTML hat keine deklarative Ereignisbehandlung wie etwa SVG, daher gibt es da praktisch außer dem Abschicken von Formularen und Verweisen keine verläßliche Methode, durch Nutzer hervorgerufenen Ereignisse zu behandeln ... also so geht das nicht ...

Wenn man solch ein Skript alternativ zur Verarbeitung auf einem server per anwenderseitigem Skript anbeiten will, muß man das Abschicken des Formulares mit der Skriptsprache abfangen und auf das Skript umbiegen, nicht aber das notwendige action-Atribut weglassen, das bleibt da schon mit einem sinnvollen Wert stehen!

Leute, die Skriptinterpretation deaktiviert oder nicht verfügbar haben, merken dann von dieser Alternative nichts. Bei aktivierter Skriptinterpretation (soweit Sicherheitsvorkehrungen am browser das nicht unterbinden) wird dann das Skript interpretiert und das Formular wird in diesen Fällen nicht mehr zum server geschickt. Doktorchen 17:08, 24. Jun. 2011 (CEST)[Beantworten]

Aktueller Wust von Änderungen[Bearbeiten]

Ich denke, man darf Anfänger auch nicht überfordern, daher gefällt mir die vorherige Variante besser, die Elemente samt Beispielen schrittweise einzuführen statt dem Leser zum Schluß ein paar Beispiele in voller Komplexität an den Kopf zu knallen. Die Effektivität eines Lehrbuches besteht ja auch darin, daß man schrittweise etwas Neues lernen kann, da sind reichlich einfach Einzelbeispiele immer hilfreicher als gleich mit allem konfrontiert zu werden.

Die Änderungen an den Beispiele oder deren Streichungen deuten auch daraufhin, daß die teils inhaltlich nicht verstanden wurden.

Daher würde ich dafür plädieren, erstmal die alte Version wiederherzustellen, die zweifellos auch überarbeitungswürdig ist, und dann behutsamer zu ändern. Doktorchen 10:39, 14. Okt. 2011 (CEST)[Beantworten]

Der Aufbau ist in meinen Augen schrittweise – nämlich von außen nach innen. Also form - fieldset - legend - label - input/select/textarea/button…

"Die Änderungen an den Beispiele deuten auch daraufhin, daß die teils nicht verstanden wurden." Nein, sie deuten darauf hin, dass ich tatsächlich sehr häufig die Erfahrung gemacht habe, dass Lernende dann genau die einfachsten Beispiele nutzen um sie Anfangs immer wieder zu kopieren und sich deren Aufbau anzugewöhnen. label und legend wären ja schließlich lediglich Optionen. An dieser Stelle kann man dem Lernenden viel in Richtung Barrierefreiheit und Benutzbarkeit beibringen. Apropos, tabindex & Co. fehlen noch --Feeela 20:15, 14. Okt. 2011 (CEST)[Beantworten]

Andere Elemente zur Strukturierung, die nicht spezifisch für Formulare sind, eignen sich natürlich auch. Was man verwendet, hängt vom Problem ab - (X)HTML ist da eben sehr flexibel. Hinsichtlich des Lerneffektes lebt so ein Buch von einfachen, sofort durchschaubaren Beispielen, das verschafft dem Leser auch Erfolgserlebnisse. Daher denke ich nach wie vor, daß einfache Beispiele zu jeden neuen Element hilfreich sind. Und da verwendet man natürlich nach Möglichkeit nur Strukturen, die man bereits vorher erklärt hat. So muß man zwar form vor input erklären (weil input sonst nicht erfolgreich sein kann), nicht aber vor input noch fieldset und label, weil man die nicht unbedingt braucht. Daß es auch ohne zugänglich geht, ist auch schon damit angedeutet, daß sie im Basis-Modul für Formulare nicht vorhanden sind (wobei zugegebenermaßen XHTML BASIC 1.1 bereits das komplette Formularmodul verwendet, in dem Buch hier also nicht diskutiert werden braucht, wie man wirklich ohne die Elemente auskommen muß).

Dazu kommen natürlich auch Beispiele mit komplizierterem Inhalt wie das eine, welches jetzt irgendwie verschwunden ist. Das zeigt, daß Formulare breit verteilten sonstigen Inhalt haben können, die Reihenfolge für das Senden nicht so wichtig ist und man solch ein Formular wirklich ergonomisch in den Inhalt integrieren kann - was ein anderes Konzept sein kann, also Formularelemente zu separieren und dominierend hervorstechen zu lassen - das den Benutzer auch dazu verleiten kann, die gegebenen Hilfen zum Ausfüllen zu ignorieren.

tabindex und accesskey - da hatte ich noch überlegt, ob man die an einer allgemeineren Stelle erklären sollte, weil die nicht nur für Formulare zuständig sind. Da man aber leider in (X)HTML nicht wie in SVG beliebige Elemente fokussieren kann, ist es wohl angebracht, bei jedem Element oder in jedem Kapitel zu erklären, wo sind anwendbar sind. Anders die allgemein verwendbaren Attribute, da muß noch ziemlich vorne ein Kapitel rein. tabindex und accesskey habe ich bei ein paar Projekten mal ausgiebig verwendet, teilweise habe ich das dann aber zugunsten einer guten Strukturierung der Seite wieder rausgeworfen, nachdem ich mitbekommen habe, daß der automatische Mechanismus der Darstellungsprogramme gut ist, wenn das Projekt gut strukturiert ist - und doppelt muß nicht sein. Pessimierung damit hinsichtlich der Zugänglichkeit ist hingegen recht einfach - muß also jedenfalls gut erklärt werden, wann und wie man das sinnvoll anwendet. Wie WAI-ARIA ist das auch so eine Funktion am Rande des Übergangs, wie man Mängel im Projekt doch noch irgendwie kompensiert, ohne es wirklich ordentlich machen zu müssen.

Hinsichtlich fehlen - zweifellos fehlt da auch noch ein Hinweis, daß man die Nutzer nicht mit unnötigen Einschränkungen der Eingabemöglichkeiten schikanieren und frustrieren sollte - habe ich schon öfter erlebt, daß da durch blödsinnige Angaben Leute abgeschreckt werden - was man als Autor ja meist nicht wollen wird. Und hinsichtlich der Zugänglichkeit eine Warnung vor den lustigen Pixelbildchen oder Audiodateien, mit denen einige Autoren das Verarbeiten von Formularen zu verhindern suchen - eigentlich gedacht, um dumme Roboter fernzuhalten, aber auch dazu geeignet, um Formularergebnisse effektiv für einige Leute unzugänglich zu machen.

Was die Leute so machen - da es haufenweise schwachsinnige und fehlerhafte Anleitungen im Netz gibt, kann man die Leute ohnehin nicht davon abhalten, irgendwoher irgendwas zu kopieren. Und wenn hier korrekte Kurzbeispiele fehlen, werden sich die vergleichenden Leser natürlich schon fragen, warum das hier so kompliziert zelebriert wird, wenn XHTML es auch einfacher erlaubt. Ich meine, wer wirklich ein Lehrbuch lesen will, der wird auch das Kapitel bis zum Ende lesen und seine eigenen Schlüsse ziehen. Und wer dazu keine Lust hat, dem werden bei der anderen Variante ohnehin die beispiellosen Definitionen zu langweilig sein und der wird zu einer anderen Anleitung wechseln, die es einfacher macht, in kleineren Schritten mit einfachen Beispielen und wohlmöglich schöner strukturierte Formulare ganz wegläßt, wie es hier übrigens auch der Fall war, bevor ich die vor Kurzem ergänzt habe ;o)

Inhalt den Leuten nicht nur richtig, sondern wohlmöglich auch noch schön beizubringen, ist ein Gradwanderung zwischen Bevormundung und Anleitung zum selbständigen, sinnvollen Handeln. Letztlich wird das Ziel ja sein, daß der Leser durch eigenständiges Denken zu einem sinnvollen Handeln kommt. Dazu muß er aber auch anhand von Alternativen erklärt bekommen, was einerseits möglich und korrekt ist, andererseits aber auch mit etwas mehr Aufwand zusätzlich besser strukturiert und nutzbar ist. Da lohnt es sich schon zu diskutieren, wie man dabei als Autor auf Kurs bleibt ;o)

Doktorchen 12:50, 15. Okt. 2011 (CEST)[Beantworten]

Ich habe ja nichts gegen kurze Beispiele. Jedoch sollten diese sich meiner Meinung nach – auch nach dem Lesen deiner ausführlichen Darstellung – auf nicht-funktionsfähige Mini-Beispiele begrenzen. Funktionsfähige Beispiele sollten in meinen Augen immer so umfassend wie möglich sein. Vielleicht unterschätzt du hier das Verständnis der Leser – oder ich überschätze es (wie du oben andeutest). Ich habe keine Ahnung, wo die goldene Mitte dieser "Gratwanderung" liegt und kann mich daher lediglich auf meine langjährige Erfahrung als Webentwickler und Autodidakt berufen. Schön wäre an dieser Stelle die Meinung eines Dritten.

Zu "das eine [Beispiel], welches jetzt irgendwie verschwunden ist": Na wie jetzt – entweder sind die Beispiele zu komplex oder nicht!? Dieses elendig lange, fernab der der normalen Tätigkeit eines Webentwicklers liegende Über-Beispiel habe ich genau aus dem Grund entfernt, dass es eben hochkomplex ist und den Leser hier wie eine Lawine überrollte. Klar kann man alles iregendwie auch anders einsetzen – aber sollte das dann wirklich in diesem Kapitel zu den Beispielen gehören? Hier könnte ich mir eher einen entsprechenden Anhang vorstellen ("Tips, Tricks und Hacks", o.ä). --Feeela 21:36, 15. Okt. 2011 (CEST)[Beantworten]

Weitere Meinungen sind ja schon implizit verfügbar, wenn man sich die Historie anguckt. Wobei ich da allerdings auch sagen würde, man darf es nicht so einfach machen, daß man wichtige Dinge verschweigt und das dann per Überschrift als Grundlagen verkauft. Wenn man das ganze Kapitel gelesen hat, sollte man schon einen qualifizierten Eindruck von sehr einfach bis gut strukturiert bekommen, um sich als Leser selbst ein Urteil bilden zu können. Den ursprünglichen Autoren lag, soweit ich deren Diskussionen überflogen habe, am schnellen Erfolgserlebnis, weswegen die bei der Kapitelreihenfolge auch nicht die Syntax vor die erste Seite gesetzt hätten - anhand des Konzeptes mit der ersten Seite, was man hier noch ausbauen kann, kann man allerhand motivieren. Ähnlich ist es bei Formularen natürlich auch, wenn man da einen funktionsfähigen 4- oder 5-Zeiler bei einer Elementdefinition hat, hilft das natürlich zu motivieren, das Grundprinzip zu verstehen. Das erhöht die Bereitschaft, sich mit längeren Beispielen auseinanderzusetzen oder auch mit einer komplexeren Kombination von Elementen und Attributen, weil man bis dahin ja schon verstanden hat, was die technische Funktion bestimmt - und was man dann ergänzen sollte, damit der Nutzer die Funktion des Formulars besser versteht.

Das verschwundene Beispiel war in dem Sinne ja nicht komplex, weil es ja nur wenige Elemente verwendete - und inhaltlich hat es eben unter anderem die Funktion zu zeigen, daß die Reihenfolge und Übersichtlichkeit egal für den Erfolg des Formulars ist - ist bei einer Abo-Falle natürlich eine unerwünschte Nebenwirkung, nichts, was man wirklich empfehlen kann ;o) Und dann kommt es auch öfter vor, daß Autoren mehr Text im Formular haben, um dies verständlicher zu machen - etwa auch mit CSS-popups etc (wenn sie es nicht gar mit einem Java-Skript so vergurken, daß die Information ohne Skriptinterpretation unzugänglich wird... gut und psychologisch machen 'bemerkenswerte' Beispiele oder auch solche mit Praxisrelevanz natürlich mehr Spaß und sind einprägsamer als stromlinienförmige Lehrbuchbeispiele. Da kommt immer schnell beim Schreiben das Problem auf, daß den Autoren nichts besonders viel einfällt (siehe Historie des Kapitels) und die dann nur relativ lustlos irgendwas hinschreiben, was weder besonders spannend noch relevant ist. Ich habe es schon oft bei irgendwelchen Anleitungen erlebt, daß ich mich dann am Ende des Kapitels immer noch gefragt habe, wie ich mein eigentliches Problem lösen soll, weil die Autoren einige Dinge geschickt umgangen haben, die ich aber gern gebraucht hätte. Und da anders als bei einem richtigen Buch hier Platz kein relevantes Kürzungsargument ist, kann man da schon mal einige Beispiele zeigen, was man bei einem gedruckten Buch eher nicht macht, um Kosten zu sparen.

Verständnis der Leser - gibt eben 'sonne und seuche' - und da habe ich an der Uni auch schon einiges erlebt, was ich (dort) nicht für möglich gehalten hätte, während ich woanders auch schon Leuten begegnet bin, die ohne viel Vorbildung ziemlich fix Informationen verwerten konnten (Bauernschläue nannte man das wohl früher ...) Doktorchen 18:43, 16. Okt. 2011 (CEST)[Beantworten]

Ich gebe den Benutzer:Doktorchen recht. Ich finde diese aktuelle Version ist zwar sehr informationsvoll, aber es hebt sich deutlich von anderen Seiten ab. Das Buch hat das Ziel die Grundlagen von XHTML zu vermitteln und nicht den Leser von einem Anfänger zu einem Profi zu machen. Wir müssen immer von einem "dummen" Leser ausgehen, der nichts vom Thema weiß und wir müssen das Buch so gestalten, dass er es schnell versteht.--Bagok 11:16, 18. Okt. 2011 (CEST)[Beantworten]

Mmmh, 2:1. Statt eines Reverts würde ich die einzelnen Blöcke aber manuell nochmals verschieben. Zu den Beispielen hatte ich gerade die Idee, ein Thema zu nehmen und dieses über die einzelnen Formularbestandteile aufzubauen. Mir viele da als erstes ein Formular zur Registrierung auf einer Webseite ein. Zuerst eben nur ein Formular mit Angabe des Namens und Passworts, dann das hinzufügen von Auswahllisten zur verwendeten Sprache oder der Lokalität und schließlich der Aufbau des Formulars inklusive Fieldset und Label sowie einem ersetzten Submit-Button (um button als Element unter zu kriegen). Vielleicht können somit dann zwei Fliegen mit einer Klappe geschlagen werden: Die Erklärungen sind wie oben gewünscht strukturiert und aufeinander aufbauend strukturiert, aber mit den einfachsten Varianten beginnend und zweitens gäbe es dann ein konsistentes, praxisnahes Beispiel. --Feeela 13:11, 18. Okt. 2011 (CEST)[Beantworten]

Ich meine, vorher war das ja auch weitab von vollständig und optimal, insofern kann man das natürlich auch neu machen, eben nach dem historischen Aufbau vorgehen und die Beispiele bei den jeweiligen Elementen bewußt so knapp halten, daß der Leser sie eher als Lehrbuchbeispiele erkennt und vielleicht nicht einfach kopiert. Stattdessen macht man dann hinten noch einen Abschnitt dran, nachdem alle Formularelemente erklärt sind, in welchem ausführlichere Beispiele stehen.

Hinsichtlich des Zaubberer-Beispieles ist das 'b' und 'rince' schon Absicht, weil zumindest der Zauberer-literaturkundige Leser dann in dem Beispiel zwei fantasy-Zauberer-Welten wiederfinden kann, was natürlich zu der Intention paßt, daß man mit absoluter Adressierung Resourcen in verschiedenen Projekten gemeinsam nutzen kann - was besonders für Anfänger interessant ist, wenn die gar keinen eigenen chat basteln können oder betreiben dürfen, aber dennoch irgendjemanden gefunden haben, der sich bei einem anderen Projekt des Problem annehmen möchte, auch weil da vielleicht nur wenig Leute den existierenden Dienst nutzen.

Hinten fehlt auch noch ein Verweis zu der Seite im PHP-Buch, wo (zwar nur knapp aber immerhin) erlärt wird, wie man die Auswertung zusammenbasteln kann, wenn PHP auf dem server läuft. Gibt schon noch eine ganze Menge, was man ergänzen und besser machen kann. Ein sinnvolles und zugängliches Beispiel für button gehört sicher dazu. Beim Formular mit verweissensitiver Graphik kann man vielleicht besser auf das entsprechende Kapitel verweisen und das dort erklären, weil es da sehr umfangreich und kreativ werden kann, eine zugängliche Variante zu formulieren - oder überhaupt erstmal ein sinnvolles Beispiel, wo man den Klickpunkt pixelgenau wissen möchte... Doktorchen 13:36, 18. Okt. 2011 (CEST)[Beantworten]

Beispiele[Bearbeiten]

UPDATE konsistentes, praxisnahes Beispiel: Ich hab da mal was vorbereitet und bitte um konstruktive Mitarbeit: Benutzer:Feeela#Entwurf eines durchgehenden Beispiels für Websiteentwicklung: XHTML: Formulare (die Idee mit dem Chat-Login finde ich sehr weit her geholt, wer macht so etwas im Jahr 2011?) zu "Formular mit verweissensitiver Graphik": mir fällt dein kein sinnvolles Beispiel ein, dir? zu "fehlender Verweis zu…" entsprechend sollte hier auch auf CSS verwiesen werden; so nutze ich zum Beispiel nie die implizierten label, da dies einfach weniger Gestaltungsspielraum via CSS lässt; bei einem, vom input getrennten label, kann dies alles mit CSS in verschiedenen Ausrichtungen angezeigt werden; --Feeela 14:52, 18. Okt. 2011 (CEST)[Beantworten]

Ich habe mal einen neuen Abschnitt begonnen und fange mal mit einer kleineren Einrückung an, der Lesbarkeit wegen ;o)

chat - warum nicht? Habe ich selbst schon in diesem Jahrtausend als eine der ersten Fingerübungen für PHP gebastelt - und natürlich verwenden viele Leute heute chats. Und die meisten davon sind nicht selbstgebastelt und liegen vermutlich auch auf anderen servern.

Verweissensitive Graphik - tja nicht einfach, da geht es bei meinem Ideen-Vorrat leicht ins Mathematisch-Künstlerische - wenn man etwa ein Fraktal an einer bestimmten Stelle weiterrechnen lassen will oder auch praktischer, wenn man eine Landkarte an einer bestimmten Stelle vergrößert haben will - beides Beispiele, wo es Spaß macht sich zu überlegen, welche Alternative man da für Leute ohne Graphikausgabe bereitstellt - wobei man die Karte ohnehin besser intern in einer SVG-Datei macht und das dann nur per object oder direkt als Fragment und ohne Formular in XHTML einbindet ;o)

Die implizierten label scheinen mir jedenfalls den Vorteil zu haben, daß sie vom Quelltext her sehr übersichtlich sind und gerade wegen der starren Struktur auch bei deaktiviertem CSS eine brauchbare Zuordnung garantieren - anders als was ich auch schon gesehen habe, wo die Liste der Beschriftungen gar nichts mit den Eingaben zu tun hatte, nachdem man CSS deaktiviert hat - denn gängige browser stellen da doch nicht wirklich eine Zuordnung dar, dafür müßte man als normaler Nutzer doch schon in den Quelltext gucken.

Einzelbeispiele gucke ich mir noch genauer an - so im Überfliegen - statt ein konkretes Beispiel zu HTML5 zu geben, könnte man da vielleicht besser nur auflisten, für welche Eingabetypen da automatische Prüfungen geplant sind. Ich meine, der Teil von HTML5 ist zwar ziemlich abgeschlossen, hängt aber wie der ganze Rest ohne Spezifikation in der Luft - ein konkretes und korrektes Beispiel im Rahmen des Buches ist das dann eben gerade nicht, ist zwar schade in dem Falle, aber praktisch kaum zu ändern - und prüfen muß man den Kram auf dem server ja sowieso wieder, also hält sich der Vorteil ohnehin in Grenzen. Damit man neue Bestandteile von HTML5 nutzen kann, müßte man ja ein HTML5-Dokument schreiben können. Das ist aber bei einem XHTML1.1-Dokument nicht der Fall, von daher kann man dazu kein definiertes Beispiel angeben, welches korrekt wäre. Wenn man formal korrekt mittels RDFa auf die Funktionalität verweist, wird es hingegen vermutlich kein gängiger browser mehr korrekt interpretieren.

Wozu die Namen der Felder in englisch, wenn der Seiteninhalt auf deutsch ist? Wenn es Leser gibt, die nicht fließend englisch beherrschen, werden die mit Vokabeln wie 'gender' sicher Probleme haben. Ich meine, ich hatte das nicht mal in der Schule, habe von dem Wort das erste mal gehört bei Personen, wo das körperliche Geschlecht nicht zur psychischen Befindlichkeit paßt - ist auch ein typisches Beispiel, wo man eine Minderheit mit einem Formular versehentlich in Verlegenheit bringen kann oder auch solche Mitmenschen, die diese Information nicht gerne exponieren möchten - Auswahlmöglichkeit 'männlich', 'weiblich', 'egal' besser?

Auch oder gerade eine textarea muß man irgendwie losschicken können... andere Sachen habe ich auch schon so losgeschickt bekommen, obgleich der Abschickeknopf fehlte oder mit js pessimiert war, aber nur textarea ist kniffliger. Zudem müssen in form Blockelemente stehen, also genauer Überschrift, Liste, Block, kein Text. Doktorchen 16:04, 18. Okt. 2011 (CEST)[Beantworten]

Das HTML5-Beispiel sollte so auch nicht in den Artikel übernommen werden – ich habe deine Kritik vorgestern schon verinnerlicht. Es ist schön dass du so viele Kritikpunkte vorbringst, leider hast du kein Wort zu der Idee an sich verloren. Ich habe die Beispiele ja mit Absicht auf meiner Nutzerseite begonnen, damit diese erst mal durchdacht werden können und alle drei derzeit hier aktiven Autoren einen gemeinsamen Nenner finden. War das nun also allgemeine Zustimmung mit Kritik (Sprache der Bezeichner, Schachtelung in Blockelemente, …) oder war das eine Ablehnung? Das Beispiel zu männlich und weiblich dient übrigens der Verdeutlichung eines radio-Buttons, nicht der politischen Korrektheit – wenn dem so wäre dürfte solch eine Abfrage heutzutage gar nicht mehr auftauchen (wie es die Entwicklungen derzeit in GB und Australien deutlich machen und z.B. in Deutschland von der Piratenpartei gefordert wird). --Feeela 10:55, 19. Okt. 2011 (CEST)[Beantworten]

Nun kommt drauf an, ob es eine inhaltlich relevante Funktion hat, wenn der Autor herausfinden will, was der Nutzer ist - bei einer Kontaktbörse, wo die Anmelder Sexualpartner suchen, kann es etwa schon relevant sein, was der Nutzer biologisch ist, welche Präferenzen er hat etc. Ich glaube auch nicht, daß diese Informationen bei einer Kontaktbörse der Mehrheit der Briten, Australier oder Piraten egal sind - viele haben da ja doch recht spezifische Vorstellungen und möchten das nicht erst bei einem persönlichen Treffen herausfinden ;o) Kommt also immer drauf an, was der Inhalt des Projektes ist ;o) Ein fiktionales Beispiel wie das mit dem Zauberstab vermeidet die Notwendigkeit, Ungeschicklichkeiten und soziale Implikationen an der Stelle zu diskutieren. Weil diese aber natürlich relevant sind, um guten Inhalt abzuliefern, sollten die in der Endfassung des Kapitels in einem gesonderten Abschnitt dann schon erläutert werden.

Und meiner Meinung nach dient ein Lehrbuch über das Schreiben von Text nicht nur dazu, zu erklären, wie man Buchstaben eintippt. An solchen Stellen bietet es sich natürlich auch an, kurz zu erläutern, wie man typische Fettnäpfchen umgeht und den Benutzer nicht unnötig unter Streß setzt - nicht bei einem minimalen Beispiel, aber das Thema, 'wie erstelle ich ein sinnvolles Formular, ohne den Ausfüller zu drangsalieren' ist natürlich relevant für ein Lehrbuch, dann eher im Anschluß an die rein technische Definition der Elemente samt minimaler Beispiele.

Hinsichtlich der inhaltlichen Relevanz des Beispieles - das kann man sicherlich so machen. Allerdings reiht man sich damit in die Unmenge bereits bestehender Anleitungen nahtlos ein, ohne Eigenheiten, neudeutsch 'Alleinstellungsmerkmale' herauszubilden. Von daher verzichtet man mit stromlinienförmigen Beispielen auf eigenes Profil, eckt damit kaum oder gar nicht an, macht das Buch aber nicht gerade zu einer spannenden, herausragenden Lektüre, eben zu Literatur, die eben auch von liebevollen Eigenheiten und Details lebt, um bemerkenswert zu werden oder bemerkt zu werden. Von daher ist formal nichts gegen so ein stromlinienförmiges Beispiel einzuwenden - zumal es immerhin direkt zeigt, was der Leser häufig brauchen wird. Es macht das Buch aber auch nicht zu etwas, was aus der Masse der Beliebigkeit herausragt - was zugegebenermaßen schwierig ist und etwas, mit dem man sich auch noch beschäftigen kann, nachdem man das Buch mit dem minimal notwendigen Inhalt gefüllt hat ;o) Und wenn man direkt fertig präsentiert, was der Nutzer braucht, hilft es diesem zwar, dieses Problem zu lösen, aber nicht unbedingt, um selbständig Probleme zu lösen. Etwas weniger praxistaugliche Beispiele vermeiden natürlich auch das von dir bereits angesprochene Kopieren und fördern wohlmöglich das eigenständige Denken und selbständige Lösen von Problemen.

Daher ist es aus meiner Sicht mehr oder weniger Geschmacksache, ob und wo man welche Beispiele verwendet. Wenn dahinter ein sinnvolles Konzept steht und guter, das Beispiel erkärender Text vorhanden ist, geht das. Geht natürlich auch anders. Gibt ja nicht nur eine Möglichkeit oder Wahrheit - die exklusiv von mir oder dir vertreten wird ;o) Persönlich bemühe ich mich immer, soweit mir etwas dazu einfällt, Beispiele auch unterhaltsam zu gestalten und möglichst nicht so praxisrelevant, daß es dem Leser erspart bleibt, selber zu denken und seine Anwendung selber einzutippen ;o) Doktorchen 12:10, 19. Okt. 2011 (CEST)[Beantworten]

Wow, ein klares deutliches Jein ;-) Ich hab's halt nicht so mit Zauberwelten und Belletristik im allgemeinen. --Feeela 14:00, 19. Okt. 2011 (CEST)[Beantworten]