Hallo Gernot,

Nach allem, was ich da lese, ist ein Name-Attribut für DIV-Elemente gar nicht vorgesehen. Vielleicht kannst du ja stattdessen mit mehreren Formularen arbeiten und diese ggf. duplizieren.

Zugegeben, es handelt sich durchaus um einen Verstoß gegen HTML-Spezifikationen, nicht aber um ungültiges XML.

Abgesehen davon sollte DOM doch das Leben erleichtern. Doch bisher wurde der Code nur umfangreicher und man trickst herum, um letztlich für den Blick des Nutzers eher simple und nützliche Features zu erhalten. Unzulänglichkeiten des eigentlich Ordnung in die Welt bringenden DOMs durch mehrere Formulare auszubügeln scheint mir der falsche Weg und außerdem ist es serverseitig nicht machbar.

Ich habe ein Formular, in dem bspw. Termine mit zugehörigen Orten eingegeben werden können.

termin(e):   [zeit       ]  [ort        ]
             [zeit       ]  [ort        ]

[BUTTON:Termin hinzufügen]

Auf mehrere Formulare verteilen hieße separate Informationen verschicken (was ja nicht im Sinne des HTTP ist), eventuell JavaScript einmal mehr aufwendig bemühen, um Daten mehrerer Formulare zu sammeln. All das erscheint mir kaum komfortabel und hilfreich. Als Entwickler muss ich auch mit TS-/Thin-Clients (etwa in Uni-Büros) rechnen, die nicht imstande sind, flüssig hunderte Zeilen Javascript-Code auszuführen, nur weil das W3C glaubt, die Welt verbessert zu haben.

BTW: Die Lösung für's Duplizieren steht inzwischen dank aufwendiger Durchforstung des DOM-Baums. Nur schade dass die Designer des Modells bzw. der Einbindung der DOM-API in Browser per Javascript nicht ausreichend weit gedacht haben. Vielleicht entgeht mir wieder nur etwas, doch scheine ich nicht imstande zu sein, dem Mozilla Firefox oder dem MSIE ein dynamisch erzeugtes   zu entlocken, damit beide gleichsam ein ansonsten leeres DIV zum Abstandhalten angemessen darstellen.

createElement ist nur für Elementknoten, createTextNode erzeugt Textknoten, da ist weder Platz für  , noch für ein € oder jedweder Unicode-Markup ... so erscheint es mir zumindest beim Durchforsten von Selfhtml.org ...

Grüße Thomas

Hallo,

Das name-Attribut ist jedoch kein Universalattribut [wie id mit Ansprache ueber getElementById()] und insofern verhaelt sich der IE hier voellig korrekt, waehrend die Mozilla-Derivate ueber's Ziel hinaus schießen ...

genau darum zitierte ich den XML-Ansatz von DOM, wonach es wohl Jacke wie Hose sein sollte, ob nun name ein HTML-Universalattribut ist oder nicht.

Grüße, Thomas

Obige Formularelementgruppe kostet mich locker 50-100 Zeilen JavaScript-Code, um zwei Zeilen im Browser zu duplizieren.

Welche Formularelementegruppe und was willst Du duplizieren. Kann mir nicht vorstellen, daß das tatsächlich 50-100 Zeilen Code benötigt.

<div class="beliebig">
<input type="radio" class="auch" name="mode[]" value="0" />&nbsp;
Nachname,Vorname:&nbsp;<input type="text" class="anders" name="sn" value="vomserver" size="20" maxlen="64" />,
<input type="text" class="anders" name="fn" value="vomserver" size="20" maxlen="64" /><br />
<input type="radio" class="auch" name="mode[]" value="1" />&nbsp;N.N.
<span class="sep">&nbsp;</span>
<input type="radio" class="auch" name="mode[]" value="2" />&nbsp;alternativ A
<span class="sep">&nbsp;</span>
<input type="radio" class="auch" name="mode[]" value="3" />&nbsp;alternativ B
<span class="sep">&nbsp;</span>
<input type="button" class="knopf" onclick="del( .... );" value="Löschen" />
</div>

So ich hoffe, dass ich damit deine Vorstellung anregen konnte ;-) ... bau das mal "from scratch" mit DOM API und ein paar Zeilen, die du auch nach 12 Monaten noch lesen und wiederverwenden kannst ...

BTW: Mag sein, dass da Fehler im HTML sind, aber der Sinn sollte drin sein.

Grüße, Thomas

Hi,

und frage mich, wie sich damit vereinbaren lässt, dass der MSIE einen Zugriff auf INPUT-Tags per getElementsByName() zulässt, nicht aber auf entsprechend markierte DIV-Tags.

Weder die HTML- noch die XHTML-DTDs erlauben ein name-Attribut im div-Element.
Also egal ob über HTML-DOM oder XML-DOM zugegriffen wird - wenn der IE ein solches Attribut gar nicht erst in seinen internen Dokumentbaum aufnimmt (gibt es ja nicht), kann man ihm keinen Vorwurf machen.

Nungut, er nimmt es aber auf ... und ich kann es auch auslesen, nur die Suche per getElementsByName versagt an dieser Stelle. Mich stört ein wenig die oberkorrekte Art, mit der XML samt allem Sammelsurium drumherum festgelegt wurde. es mangelte aber von anfang an einer orientierung am nutzer / entwickler ... ich stoße ebenso häufig über definitionsschwächen bei XML/DOM wie auch bei CSS, bei PHP, bei JS ... und wenn man dies bemängelt heißt es immer nur: na SOO will es der Standard XY ... danke, aber nicht der Nutzer/Entwickler.

Der Firefox macht auch nicht alles beim CSS richtig, bspw. im Umgang mit prozentualen Breiten. Doch das verlangt CSS1 nicht, na und CSS2 will man ja noch gar nicht fertig unterstützen ... das man Tabellen nicht per CSS anpassen kann ist dann auch erst mal dank CSS1-Mängel keine Debatte wert. Es kommen mir mehr Ideen zur Nutzung als diese fortschrittlichen Standards es mir ermöglichen.
Da lob ich mir jeden mutigen Vorstoß seitens MS, um die komfortable Nutzerführung, die den Sekretärinnen und anderen Bürohengsten sehr leicht von der Hand geht, auch auf Webseiten umzusetzen. Das all-Objekt war für damalige Verhältnisse wohl ein gutes Beispiel hierfür.

Genau dies brauche ich, um in einem Formular eine Gruppe von Elementen

Formular-Elemente sollten mit dem dafür vorgesehenen Element fieldset gruppiert werden.
Wenn die defaultmäßig erzeugte border oder die Legende stören: das läßt sich per CSS unterdrücken.

Es geht hier nicht um fieldset oder nicht, sondern wie ich die ganze K...e per JS duplizieren, neue Namen zuweisen, Inhalte rücksetzen kann. Und DOM ist dabei nicht die einfachste Technik. Ein Kind muss in DOM noch das Elternteil bitten, es zu "töten":

child.parentNode.removeChild( child );

Das nenne ich sprachlich umständlich, wenngleich der Ansatz einer "überschaubaren" Spezifikation zur leichteren Implementation der API-Bibliothek mir durchaus sinnvoll erscheint. Die Nutzbarkeit leidet doch darunter.

Grüße, Thomas

Hallo,

ist es so unfassbar schwer, _keine_ E-Mail-Adresse einzutragen?

Es ist schwer, explizit "keine" Adresse einzutragen, weil die Maske dies schlicht und ergreifend nicht zulässt.

| t@t.de: Host or domain name not found. Name service
| error for name=t.de type=A: Host not found

... und gerade auf dieser Site hätte ich etwas mehr Sicherheit erwartet.

FAQ.

Danke fürs FAQ, doch da stehen offensichtlich nicht ohne Grund _zwei_ Absätze. Die Sicherheitsbedenken werden auch nur erwähnt, und nicht als ausreichend berücksichtigt beschrieben.

Ich habe schon heute jede Menge Spam auf meinem Konto, wenngleich der SpamAssassin alles fleißig markiert. Durch muss es trotzdem. Außerdem lenke ich damit einmal mehr die Augen der Bots auf meinen Server, und da ist mir jedes bischen Traffic heilig, auch im Interesse meiner Kunden.

Die Bequemlichkeit der anderen Leser ist potenziell mein Nachteil für die nächsten Wochen oder gar Monate ... ich bemühe mich sogar, meine Web-Adresse mit unterzubringen, damit man notfalls darüber den Kontakt herstellen kann. Doch antworte ich ja auch fleißig hier im Forum ... ;-)

Ein x [at] y [dot] com hat noch keinem geschadet und hätte mir gereicht. Ein Verstecken durch Javascript versaut auch nach heutiger Ansicht (und Vorstellung mancher EU-Großprojekte) nicht mehr die Chance zum barrierefreien Surfen und ermöglicht ganz nebenbei den Komfort für den Kontaktwilligen ... hätte mich auch zufriedengestellt. Nicht aber kann mich eine statische Seite zufriedenstellen, die randvoll ist mit leckeren mailto-Links.

Da bitte ich auch meine Interessen zu berücksichtigen und ich denke Sicherheit ist heutzutage wichtiger als Komfort (von meinen mir durch das BDSG eingeräumten Rechten mal ganz zu schweigen), denn darum mussten wir schon so manchen Feature-Wegfall wegstecken. Auch ohne Mail-Adresse stehe ich zu meinen Beiträgen und lasse mich bei ungepflegtem Benehmen gern rechtlich belangen, dank Web-Site sogar auf postalischem Wege ...

Grüße, Thomas

Hallo,

Du hast seltsame Vorstellungen bzgl. Sicherheit.

Ich bin froh mir zumindest sicher sein zu können, dass du meine Vorstellungen letztlich nicht wirklich kennen kannst. Dennoch würden mich Gründe für die Wahl deiner Bewertung selbiger interessieren.

Gewiss gibt es noch andere Unsicherheiten in dieser Welt, doch eine Site, die HTML, JavaScript und die richtige Entwicklung von Webseiten zu vermitteln versucht, kann doch in unseren heutigen Tagen kaum noch das Thema Sicherheit ausgrenzen oder nur beschreiben, damit es die anderen machen.

Ich weiß nebenbei dass ich mich nie ausgiebig in Newslettern und weiß der Henker eingetragen wo habe, sondern immer nur in Foren mal nen Beitrag gepostet habe. Wie kommt es nun, dass ich wirklich Unmengen an Spam jeden Tag erhalte. Ja, durch Bekannte mit infizierten Computern. Und gewiss auch durch Klartext-Mail-URI, die ich als gezielt nach Foren suchendes Skript per wget auslese und wegspeichere. Da reichen primitivste Techniken, die dafür umso effizienter arbeiten können.

Richtig, solche Bemühungen schützen mich nicht per se zu 100% vor Trojanern, Würmern und dergleichen. Doch Prävention sollte hier ein angemessenes Schlagwort sein und jeden Schritt rechtfertigen, der die Bedrohung der Sicherheit meiner Daten wie auch meiner verfügbaren Zeit einzugrenzen vermag.

Das mag dir so seltsam erscheinen wie mir deine Vorstellungen von Kommunikation merkwürdig anmuten.

Grüße, Thomas