DOM-Fähigkeit des MSIE 6.0

[Thomas Urban]

UNBEDINGT beachten: Wem es im Finger zuckt, um hier allgemeine Flames gegen den MSIE abzulassen, der möge sich diese unnötigen Mühen sparen. Ich kenne Windows, den MSIE, wie auch Firefox, Opera, Linux etc. Kurzum: ich finde jedes davon auf seine eigene Art sch...e, doch das ändert nichts daran, dass man damit arbeiten muss.

Ich nutze den MSIE 6.0 unter XP Home SP2 mit allen derzeit verfügbaren Patches seitens Windows-Update. Leider muss ich dabei feststellen, dass - glaubt man dieser Site hier - dieser nicht so ohne weiteres als DOM-kompatibel hingestellt werden darf, weshalb ich mich frage, ob nicht ein entsprechender Hinweis nötig wäre oder besser eine überarbeitete Kompatibilitätsanzeige, die auch eine teilweise Kompatibilität auszudrücken vermag.

Ich lese über DOM als

"... das Modell, das[s] ein Auszeichnungssprachen-Dokument, egal ob in HTML oder einer anderen, XML-basierten Auszeichnungssprache geschrieben ..."
[/javascript/objekte/node]

und

"Das node-Objekt gilt unter Puristen allerdings als das "reinere" DOM, eben weil es nicht auf HTML beschränkt ist."
[/javascript/objekte/node]

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. Genau dies brauche ich, um in einem Formular eine Gruppe von Elementen für die Eingabe eines weiteren Datensatzes duplizieren zu können. Der Firefox macht keine Sorgen, der MSIE findet einfach nichts.

BTW: Der derzeitige Stand der Entwicklung der DOM-API (innerhalb der Browser) ist meiner Meinung nach sowieso ein Fall von "warum einfach, wenn's auch schwer geht". Obige Formularelementgruppe kostet mich locker 50-100 Zeilen JavaScript-Code, um zwei Zeilen im Browser zu duplizieren. Ein paar Radiobuttons, Textedits, Labels, alles garniert mit Klassennamen etc.
Selbst der Einsatz von cloneNodes bedarf einer recht umfangreichen Nachbearbeitung, damit nicht auch die Inhalte dupliziert werden und eventuell genutzte Namen für die eindeutige Zuordnung seitens des Serverskripts angepasst werden.

Zugegeben, mit x GHz Power unter der Haube sollte ein moderner Rechner selbst derlei viele Zeilen zu interpretierenden Code ausführen können, ohne dass man was spürt, doch nicht nur der Ressourcenhunger des Browsers steigt, nein auch die Fehleranfälligkeit des Skripts samt der damit verbundenen erhöhten Entwicklungszeit.
Ein eingebauter XML-Parser zur Angabe eines Unterbaums per XML würde hier Wunder vollbringen. Oder habe ich das nur noch nicht entdeckt?

Sorry, wegen der E-Mail-Adresse, doch in der Vorschau ist sie im Klartext drin, woher soll ich wissen wie sie im Forum erscheint ... und gerade auf dieser Site hätte ich etwas mehr Sicherheit erwartet.

Grüße,
Thomas

[Gernot Back]

Hallo Thomas,

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. Genau dies brauche ich, um in einem Formular eine Gruppe von Elementen für die Eingabe eines weiteren Datensatzes duplizieren zu können. Der Firefox macht keine Sorgen, der MSIE findet einfach nichts.

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.

Gruß Gernot

[Thomas Urban]

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

[Thomas Meinike]

Hallo,

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.

Haenge String.fromCharCode(160) in einen Textknoten ein.

MfG, Thomas

[Thomas Urban]

Hallo,

Haenge String.fromCharCode(160) in einen Textknoten ein.

Na das nenne ich mal einen Tipp, danke! Der hat zumindest noch dieses Problemchen gelöst. ;-)

Grüße, Thomas

[MudGuard]

Hi,

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.

Warum benutzt Du für einen Abstand nicht einen Abstand (also margin bzw. padding)?

cu,
Andreas

[Thomas Urban]

Hallo,

Warum benutzt Du für einen Abstand nicht einen Abstand (also margin bzw. padding)?

Ich würde mal sagen, dass das ästhetische Gründe hat. Letztlich setzt man auch am Anfang oder Ende einer Aufzählung kein weiteres Komma und den Effekt hätte ich, mit einem margin-top oder margin-bottom. Gewiss, man kann wieder Fallunterscheidungen etc. betreiben und unterschiedliche Klassen zuweisen, doch ein explizit separater Spacer ist hierbei frei von Sonderbehandlungen und bietet ganz nebenbei weiterreichende Möglichkeiten für Layoutanpassungen per CSS, etwa durch Hintergrundgrafiken (Linien), sich abhebende Hintergründe etc.

Zugegeben, ich habe letztlich aber auf die Methode umstellen müssen, da an anderer Stelle ein Problem entstand. Diese hätten auch das oben hingenommene Prinzip der Fallunterscheidung als Lösungsmethode verworfen.

Abgesehen davon war mein Einwand unabhängig von meiner konkreten Anwendung. DOM wird auf dieser Site beworben als das Mittel, um endlich HTML dynamisch nach Strich und Faden anzupassen, dazu kann ich dann Bäume parsen noch und nöcher, kriege zwei Hände voll Knotentypen angezeigt und kann satte 3 davon auch anlegen ... ich sehe da eine spürbare Asymmetrie in dieser Folge. Ja, Kommentare sieht keiner mehr, aber gerade Zeichen-Entitäten finde ich nicht sooo unwichtig ... die Möglichkeit zum Austricksen fand sich letztlich dann auch noch.

Grüße, Thomas

[Struppi]

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 ...

&...; sind auch Textknoten, nur musst du dafür die enstprechenden Code Werte eingeben.

z.b.
  = 160 (DEZ) => \160 => \xA0
&euro = 8364 (DEZ) => \u20AC

Mehr hab ich bisher auch nicht gebraucht. Irgendwo gibt es bestimmt auch Tabellen dazu.

Struppi.

[MudGuard]

Hi,

&...; sind auch Textknoten, nur musst du dafür die enstprechenden Code Werte eingeben.
z.b.
  = 160 (DEZ) => \160 => \xA0
&euro = 8364 (DEZ) => \u20AC

Mehr hab ich bisher auch nicht gebraucht. Irgendwo gibt es bestimmt auch Tabellen dazu.

http://www.unicode.org/charts/

cu,
Andreas

[Thomas Meinike]

Hallo,

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. Genau dies brauche ich, um in einem Formular eine Gruppe von Elementen für die Eingabe eines weiteren Datensatzes duplizieren zu können. Der Firefox macht keine Sorgen, der MSIE findet einfach nichts.

getElementsByName() gehoert nicht zu den Core-DOM-Methoden und wurde fuer eigens das HTML-DOM spezifiziert.

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 ...

MfG, Thomas

[Thomas Urban]

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

[Thomas Meinike]

Hallo,

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.

Die Methode getElementsByName() steht aber nur im HTML-DOM zur Verfuegung. Verwende ggf. geeignetere Methoden wie getElementById(), getElementsByTagName(), getAttribute() usw.

MfG, Thomas

[Thomas Urban]

Hallo,

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.

Die Methode getElementsByName() steht aber nur im HTML-DOM zur Verfuegung. Verwende ggf. geeignetere Methoden wie getElementById(), getElementsByTagName(), getAttribute() usw.

Gut, ich habe das inzwischen mit getElementsByTagName gelöst und habe dann zu Fuß nach dem name-Attribut gesucht. Einzig vorteilhaft war die Möglichkeit, eine RegExp-Suche vorzunehmen.

Grüße, Thomas

[HaThoV]

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.

[Thomas Urban]

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

[MudGuard]

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.

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.

cu,
Andreas

[Thomas Urban]

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

[Thomas Urban]

Hallo,

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.

Noch ein Nachtrag: Vermag "XML-DOM" wirklich nicht mehr als HTML- und XHTML-Dateien anzusprechen? Wäre ja auch wieder traurig. Kann DOM nur arbeiten, wenn alle Randbedingungen für eine pure XML-Datei vorhanden sind? XML ist meinetwegen ohne DTD nicht validierbar, es bleibt aber per se immer noch lesbar und kann geparst werden, oder? Also sollte man auch per DOM sich durch einen meinetwegen nicht validierten Baum hangeln können, wenn es ausnahmsweise auch mal um Luxus für den Nutzer/Entwickler gegangen wäre.

Grüße, Thomas

[Thomas Meinike]

Hallo,

Das all-Objekt war für damalige Verhältnisse wohl ein gutes Beispiel hierfür.

Naja, zu IE4-Zeiten -- also von 1997-1999 -- war das von praktischem Interesse ...

BTW: Du kennst
var all_elements = document.getElementsByTagName("*");
?

MfG, Thomas

[Thomas Urban]

Hallo,

Das all-Objekt war für damalige Verhältnisse wohl ein gutes Beispiel hierfür.

Naja, zu IE4-Zeiten -- also von 1997-1999 -- war das von praktischem Interesse ...

Eben, ... ;)

BTW: Du kennst
var all_elements = document.getElementsByTagName("*");
?

Nee, JavaScript war bisher eher kaum eine Sprache, der ich angemessen viel Aufmerksamkeit gewidmet habe - irgendwann irritiert dieser Wust aus Sprachen auch. Aber klingt allemal interessant. Da spart man sich ne kleine Rekursion, zu der ich in einem solchen Falle wohl gegriffen hätte.

Grüße, Thomas

[Thomas Meinike]

Hallo,

BTW: Du kennst
var all_elements = document.getElementsByTagName("*");
?

Nee, JavaScript war bisher eher kaum eine Sprache, der ich angemessen viel Aufmerksamkeit gewidmet habe ...

Das hat ja primaer auch nichts mit JS sondern eben mit dem DOM zu tun ;-).

Bereits DOM Level 1 Core definierte 1998 fuer getElementsByTagName(): "The special value "*" matches all tags."

MfG, Thomas

[Thomas Urban]

Hallo,

Nee, JavaScript war bisher eher kaum eine Sprache, der ich angemessen viel Aufmerksamkeit gewidmet habe ...

Das hat ja primaer auch nichts mit JS sondern eben mit dem DOM zu tun ;-).

Gut, sei's drum ... letztlich war DOM auch kein Thema für mich, solange ich fernab von JavaScript programmiert habe. Doch in JavaScript kommt man ja nun wirklich nur kaum noch drumherum ...

Grüße, Thomas

[TomIRL]

Hallo,

Nee, JavaScript war bisher eher kaum eine Sprache, der ich angemessen viel Aufmerksamkeit gewidmet habe ...

Das hat ja primaer auch nichts mit JS sondern eben mit dem DOM zu tun ;-).

Gut, sei's drum ... letztlich war DOM auch kein Thema für mich, solange ich fernab von JavaScript programmiert habe. Doch in JavaScript kommt man ja nun wirklich nur kaum noch drumherum ...

Oh doch..
ich setze es faktisch nie ein..
Und auch alle Seiten des Bundes werden künftig ohne JS und DOM auskommen.
TomIRL

[Thomas Urban]

Hallo,

Gut, sei's drum ... letztlich war DOM auch kein Thema für mich, solange ich fernab von JavaScript programmiert habe. Doch in JavaScript kommt man ja nun wirklich nur kaum noch drumherum ...

Oh doch..
ich setze es faktisch nie ein..
Und auch alle Seiten des Bundes werden künftig ohne JS und DOM auskommen.

Zugegeben, ohne JS ist sowieso besser ... ich sitze ja nicht gerade an meiner ersten Website, es ist nur einfach die erste, die eine einseitige, komfortable Eingabemaske haben soll. Und darum musste diesmal wieder JS ran.

Ich finde kaum Nutzen in Sachen wie animierte Buttons etc. und kam bisher recht gut bei meinen Projekten ohne aus, daher auch meine Sicht, dass man bei JS nur schwer um DOM herum kommt. Die Masse der JS Anwendungsfälle liegen für mich einfach darin, LnF einer Seite weniger WWW-typisch und mehr einer klassischen Anwendung ebenbürtig darzubringen. Komfort-features wie tooltips, dauerhaft sichtbare Menüs etc. gehören für mich dort überall rein, und sei es nur ein Aufruf von getElementById(), schon hat man Kontakt mit DOM.

Wer ohne JS kann, hat eine gute Serverseite und das ist allemal im Interesse des Kunden und der Informationen, um die es letztlich geht.

Grüße, Thomas

[Orlando]

Hi Thomas,

Sorry, wegen der E-Mail-Adresse, doch in der Vorschau ist sie im Klartext drin, woher soll ich wissen wie sie im Forum erscheint

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

| [e-mail]: 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.

Grüße,
 Roland

[Thomas Urban]

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.

| [e-mail]: 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

[Orlando]

Hi Thomas,

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.

natürlich tut sie das.

Ich habe schon heute jede Menge Spam auf meinem Konto, wenngleich der SpamAssassin alles fleißig markiert. Durch muss es trotzdem.

Richtig. Deshalb habe ich meine Adresse, mit der ich hier seit Jahren schreibe kürzlich deaktiviert. Kontakt ist per URI möglich.

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.

Dann gib bitte keine Adresse an, es funktioniert tatsächlich. ;-) Außerdem erzeugst du woanders Traffic, nämlich bezüglich Spam und Bounces.

Ein x [at] y [dot] com hat noch keinem geschadet und hätte mir gereicht.

Sollte das hier zur Diskussion stehen, würde ich dagegen stimmen. Daher also meine Bitte: Gib entweder eine korrekte Adresse an oder gar keine. Danke.

Grüße,
 Roland

[Thomas Urban]

Hallo,

Dann gib bitte keine Adresse an, es funktioniert tatsächlich. ;-) Außerdem erzeugst du woanders Traffic, nämlich bezüglich Spam und Bounces.

Die Adresse [e-mail] dürfte in erster Linie beim Adressensucher und dessen DNS-Servern Traffic verursachen. Eine reale Domain dieser Art dürfte wohl gemäß der Richtlinien der DeNIC Utopie bleiben, so dass auch kein Server belastet wird.

Das nebenbei Bounces als Mehr-Belastung angesehen werden ist gleichfalls ein Problem, dass ich so gern an die jeweiligen Spam-Filter-Betreiber weiterreichen möchte, denn bei mir rangieren 95% der Bounce-Mails auf einer Stufe mit Spam und wenn dies mal irgendwo sinnvoll zur Debatte stehen sollte, wäre ich für die Abschaffung der Bounce-Mails im Falle von Spam-Erkennung.

Ich lasse das Feld leer und mich hiermit eines besseren beleeren. Keine Ahnung, warum dort vorhin ständig Fehler kamen. War vielleicht nicht-leer, aber keine offensichtlich gültige Adresse. Dann möchte ich mir hier entschuldigen!

Grüße, Thomas

[Robert]

Hallöle,

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.

Es gehört schon eine gewaltige Leistung dazu, ein leeres Eingabefeld einfach leer zu lassen ...

cu,
Robert

[Christian Kruse]

你好 Thomas,

Sorry, wegen der E-Mail-Adresse, doch in der Vorschau ist sie im
Klartext drin, woher soll ich wissen wie sie im Forum erscheint ...
und gerade auf dieser Site hätte ich etwas mehr Sicherheit erwartet.

Du hast seltsame Vorstellungen bzgl. Sicherheit.

再见,
 CK

[Thomas Urban]

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

[Christian Kruse]

你好 Thomas,

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.

Sicherlich nicht, dein Kommentar laesst jedoch Rueckschluesse zu.

Dennoch würden mich Gründe für die Wahl deiner Bewertung selbiger
interessieren.

s.o.

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.

Warum eine Verschleiherung von E-Mail-Adressen genau gar keinen Sinn
macht kannst du mehrfach im Archiv nachlesen. Die Suche hilft dir dabei.

再见,
 CK

[Thomas Urban]

Hallo,

Warum eine Verschleiherung von E-Mail-Adressen genau gar keinen Sinn
macht kannst du mehrfach im Archiv nachlesen. Die Suche hilft dir dabei.

Dass jede Massnahme - egal worum es geht - nur darauf wartet, von einer im Umfang entsprechend angepassten Gegenmassnahme nihiliert zu werden, ist mir klar und bedarf nicht erst deines Kommentars. Dennoch kann die Folge hieraus nicht lauten, dann einfach gleich das Silbertablett draußen stehen zu lassen.

Meiner Erfahrung nach sind selbst hochergiebige Bots wie etwa der Googlebot zu primitivsten Techniken (Refreshs verfolgen, JavaScript interpretieren, etc.) nicht imstande. Es mag Software geben, die genau das leistet und dennoch wird diese weniger effizient arbeiten und ein mehr an Entwicklungsressourcen verschlingen, weshalb ich eher zur jeden noch so ökonomischen Form der _Prävention_ greifen würde, als zu resignieren, weil sowieso kein Weg zur risikofreien Sicherheit führt. Diese innere Ruhe möge dich befriedigen ...

Grüße, Thomas