Kontaktformular & UTF8/Unicode

[Die IP da halt]

Hallo. Ich wurde vom Wiki hierher verwiesen, also hier nochmal meine Nachricht:

Kann mir jemand bei der Frage helfen, wie man mit JavaScript ein einfaches Kontaktformular erstellen kann? Ohne so einem lästigen Zeugs wie CAPTCHA-Sicherheit etc.. Ich habe zwar ein Bisschen Kenntnisse von HTML und CSS, JavaScript ist aber für mich eine totale Fremdsprache, weswegen ich darum bitten würde, eine möglichst laienkonforme Erklärung zu kriegen. Die Abfragefelder sollten neben Name, E-Mail-Adresse, Betreff, Nachricht evtl. auch noch über zusätzliche Angaben verfügen können wie bspw. Alter. Eine Besonderheit wäre da noch interessant: würde es gehen, dass die über das Formular gesendeten Nachrichten an mehrere E-Mail-Adressen versendet werden? Grund ist hier, dass es mehrere Admins der Seite gibt und es sinnvoll wäre, wenn alle schnellstmöglich die Nachrichten kriegen.

Mittlerweile habe ich übr. noch ein weiteres Problem, was mich jetzt vollends zum Verzweifeln bringt. Bei der als problematisch angegebenen Seite funktioniert der Meta-Carset-Tag nicht, um Sonderzeichen korrekt darzustellen. In Firefox geht es zwar, wenn ich UTF-8 durch Unicode ersetze, allerdings nicht in Chrome. Merkwürdig aber: auf der Startseite funktioniert es mit UTF-8 problemlos. Dabei habe ich den Code kopiert, damit es keine Probleme mehr geben könnte. Ob ich vor der schließenden Klammer jetzt noch einen Schrägstrich setze oder nicht, scheint keinen Unterschied zu machen. Ich werde langsam wahnsinnig mit dieser Seite.

PS: Die verlinkte Seite ist noch lange nicht fertig, also bitte nicht wegen der Unvollständigkeit wundern. :)

[Julius]

Hallo Die IP da halt,

Ich wurde vom Wiki hierher verwiesen, also hier nochmal meine Nachricht:

Die Diskussionsseiten im Wiki sind für Diskussionen zu den Wiki-Inhalten bestimmt (auch wenn sich diese Diskussionen zu 99,9% hier im Forum abspielen) und nicht für Fragen.

Kann mir jemand bei der Frage helfen, wie man mit JavaScript ein einfaches Kontaktformular erstellen kann? Ohne so einem lästigen Zeugs wie CAPTCHA-Sicherheit etc.. Ich habe zwar ein Bisschen Kenntnisse von HTML und CSS, JavaScript ist aber für mich eine totale Fremdsprache, weswegen ich darum bitten würde, eine möglichst laienkonforme Erklärung zu kriegen.

Mailformulare sind überbewertet, die Angabe einer E-Mail-Adresse ist oft bereits ausreichend.

Falls du wirklich ein solches Kontaktformular einbauen willst, brauchst du dafür kein JavaScript, sondern eine Server-seitige Sprache wie PHP. So ein Kontaktformular ist kein triviale Sache, sondern bietet großes Missbrauchspotenzial, wenn es falsch, also unsicher, implementiert wurde: Angreifer könnten es beispielsweise zum Spam-Versand missbrauchen. Du musst dich entweder gründlich mit PHP befassen oder auf einer fertige Lösung zurückgreifen, die es bestimmt gibt, von denen ich aber keine kenne (vor allem nicht deren Sicherheit) und daher auch nicht empfehlen kann.

Die Abfragefelder sollten neben Name, E-Mail-Adresse, Betreff, Nachricht evtl. auch noch über zusätzliche Angaben verfügen können wie bspw. Alter.

Die ersten Angaben bietet bereits ein normales E-Mail-Programm, beim Letzteren kannst du ja auf der Impressumsseite einfach um die Angabe des Alters bitten.

Den mailto-Verweis kennst du bestimmt bereits, aber kennst du auch die erweiterten Möglichkeiten, um beispielsweise mehrere Empfänger oder einen Titel für die Nachricht zu übergeben? Diesen Link kann man auch mit JavaScript ändern und so den Inhalt eines Formulars ins E-Mail-Programm bekommen. Bedenke dabei aber, dass (vermutlich) die Mehrheit der Desktop-Nutzer auf Webmail setzt (bei den Handy-Nutzern kann es anders aussehen, dort wird oft eine passende App installiert) und hier funktioniert dieser Link nicht.

Eine Besonderheit wäre da noch interessant: würde es gehen, dass die über das Formular gesendeten Nachrichten an mehrere E-Mail-Adressen versendet werden?

Das ließe sich auch mit der Angabe einer einzigen E-Mail-Adresse erschlagen: Leitet E-Mails an diese Adresse einfach an zwei oder mehr andere Adressen weiter.

Mittlerweile habe ich übr. noch ein weiteres Problem, was mich jetzt vollends zum Verzweifeln bringt. Bei der als problematisch angegebenen Seite funktioniert der Meta-Carset-Tag nicht, um Sonderzeichen korrekt darzustellen.

Doch, er funktioniert, nur nicht so, wie du meinst, dass er funktionieren müsste:

Eine (Text-)datei ist für den Browser erst einmal ein Haufen Bytes, von denen er nicht weiß, was er damit machen soll. Dass es ein HTML-Dokument ist, weiß er bereits aufgrund des Content-Type-HTTP-Headers (Content-Type: text/html), den der Server mit dem Dokument mitgesendet hat. Also macht sich der Browser in der Datei auf die Suche nach der gültigen Angabe der Zeichenkodierung, denn die wurde nicht mitgesendet. Was er findet, ist <meta charset="UTF-8"> also nimmt er UTF-8 als Zeichenkodierung an. Soweit so gut. Dann trifft der Browser aber auf Bytes, die keine gültigen UTF-8-Sequenzen sind und stellt daher stattdessen das �-Symbol dar.

Tatsächlich ist deine Datei aber Windows-1252- und nicht UTF-8-kodiert abgespeichert worden – Du hast quasi einen Text auf Deutsch und behauptest, er wäre in Englisch verfasst. Entweder deklarierst du die Zeichenkodierung richtig, oder du kodierst deine Datei um, wobei letzeres zu empfehlen ist.

In Firefox geht es zwar, wenn ich UTF-8 durch Unicode ersetze, allerdings nicht in Chrome.

Unicode ist keine Zeichenkodierung sondern ein Zeichensatz, der bestimmt, welche Zeichen in ihm enthalten sind. Auf Unicode basierende Zeichenkodierungen wie UTF-8 bestimmen dann, wie die Umsetzung in Bytes konkret abläuft.

„Unicode“ ist hier folglich keine gültige Angabe, daher versuchen die Browser wohl zu raten. Die Ergebnisse siehst du ja.

Merkwürdig aber: auf der Startseite funktioniert es mit UTF-8 problemlos.

... weil du keine Zeichen außerhalb von ASCII (ASCII ist eine Untermenge von UTF-8) eingefügt hast, und so einerseits keine Fehler auftreten, andererseits auch nicht feststellbar ist, welche Zeichenkodierung eigentlich gemeint sein könnte.

Du musst also die Datei UTF-8-kodiert abspeichern, durchforste mal das Menü deines Texteditors. Notepad++ bietet das beispielsweise recht prominent in den Menüs an. Das sollte die Probleme beheben.

Dabei habe ich den Code kopiert, damit es keine Probleme mehr geben könnte. Ob ich vor der schließenden Klammer jetzt noch einen Schrägstrich setze oder nicht, scheint keinen Unterschied zu machen.

Den Schrägstrich brauchst du nicht zu machen, den braucht man nur, falls du das HTML XML-konform als XHTML notieren möchtest.

Außerdem solltest du deine Seiten mit dem Validator überprüfen, der findet zumindest auf deiner Impressums-Seite einige Fehler (unter anderem meckert er über Byte-Sequenzen, die keine gültige Unicode-Zeichen sind, wie bereits oben erklärt). Noch ein paar Tipps für das Beheben der Fehler: Arbeite die Liste möglichst von oben nach unten ab. Du musst auch nicht alle Fehler auf einmal beheben, sondern kannst zwischendurch noch einmal validieren – oft verursacht ein Fehler Folgefehler, die bereits weg sind, wenn der Ausgangsfehler behoben wurde.

Gruß
Julius

[Gunnar Bittersmann]

@@Julius

Was er findet, ist <meta charset="UTF-8">

Das sollte allerdings als erstes gefunden werden, d.h. die Angabe der Zeichencodierung sollte als erstes im head stehen, noch vor title.

Außerdem solltest du deine Seiten mit dem Validator überprüfen, der findet zumindest auf deiner Impressums-Seite einige Fehler

Andere Fehler findet er nicht, z.B. das Fehlen der Angabe <meta name="viewport" content="width=device-width, initial-scale=1.0"/>.

LLAP 🖖

[Julius]

Hallo Gunnar,

Was er findet, ist <meta charset="UTF-8">

Das sollte allerdings als erstes gefunden werden, d.h. die Angabe der Zeichencodierung sollte als erstes im head stehen, noch vor title.

Die Spezifikation schreibt zwar nur vor, dass das in den ersten 1024 Bytes der Datei stehen muss, aber besser ist es, das als erstes zu notieren.

Außerdem solltest du deine Seiten mit dem Validator überprüfen, der findet zumindest auf deiner Impressums-Seite einige Fehler

Andere Fehler findet er nicht, z.B. das Fehlen der Angabe <meta name="viewport" content="width=device-width, initial-scale=1.0"/>.

Faktisch ein Fehler, ja, aber die Angabe ist (leider?) nicht vorgeschrieben – was natürlich nichts daran ändert, dass sie drin stehen sollte. Ich hatte (außerhalb des Forums) schon manches Mal Mühe, Leuten zu erklären, dass diese Angabe für die saubere Darstellung auf Geräten mit kleinen Viewports erforderlich ist, eine Notiz im Validator hätte das wesentlich erleichtert.

Gruß
Julius

[Gunnar Bittersmann]

@@Julius

eine Notiz im Validator hätte das wesentlich erleichtert.

Ich werd dem Mike Smith mal eine Notiz zukommen lassen.

LLAP 🖖

[Die IP da halt]

Oh Gott... Ich wollte doch nur eine einfache, schnelle Lösung für mein Problem, und jetzt schlägt man sich hier die Köpfe um den Sinn oder Unsinn der verschiedensten Methoden ein… Also... Ich hoste die Seite erst einmal auf einem Anbieter, ich habe jetzt keinen direkten Zugriff auf den Server. Allerdings bietet der Anbieter schon viel Programmierfreiheit, so werden die HTML-Dateien komplett ohne vorgegebenem Design etc. selbst erstellt. Daher schreibe ich die Dateien auch entweder in Ms Editor oder direkt im Web-Dateimanager. Was PHP betrifft... Soll wohl auf dem Server verfügbar sein, aber abgesehen davon, dass ich das nicht kann, hätte ich auch keine Ahnung, wie sich PHP-Dateien mit den HTML-Seiten verknüpfen ließen, damit das auch alles Sinn ergibt... Ja ich weiß, ich wirke total lernfaul, aber so ist das nicht. Ich denke einfach, dass ich erst HTML/CSS perfekt beherrschen sollte, bevor ich mich mit höheren Sprachen befassen sollte. Ich ziehe einfach ein Kontaktformular einer einfachen E-Mail-Adresse vor, weil es, naja, professioneller ist. Die erweiterten Angaben für Mailto-Links kenne ich schon, ich könnte sicherlich auch mit viel Aufwand ein vorgefertigten „E-Mail-Entwurf“ erstellen, nur... Ich hätte halt lieber ein Kontaktformular. Zumal damit wohl auch die dämlichsten Nutzer klar kommen müssten. Wegen E-Mail-Client würde ich mir keine Sorgen machen, ich nutze Webmail und Firefox öffnet bei Mailto-Links zuverlässig immer die Gmail-Seite.

Was die Codierung betrifft... Die einzigen Sonderzeichen, die ich verwende, sind die Deutschen (inkl. Satzzeichen wie Halbgeviertstrich). Deswegen gehe ich davon aus, dass diese auf UTF-8 ausgelegt sind. So habe ich auch keine Ahnung, wie ich das umcodieren soll, zumal ich die Startseite einfach genauso wie das Impressum erstellt habe, also keine unterschiedlichen Einstellungen, was unterschiedliche Ergebnisse im Zeichensatz hervorrufen könnte.

[dedlfix]

Tach!

Oh Gott... Ich wollte doch nur eine einfache, schnelle Lösung für mein Problem, und jetzt schlägt man sich hier die Köpfe um den Sinn oder Unsinn der verschiedensten Methoden ein…

Ein Kontaktformular sieht nur auf den ersten Blick einfach aus. Realisiert man es zu einfach, hat man ein Problem, dass es mit Spam zugeschüttet wird. Baut man Fehler rein, kann man Teil des weltweiten Spamproblems werden, weil es missbraucht werden kann, um anderen Adressen Spam zu schicken.

Was PHP betrifft... Soll wohl auf dem Server verfügbar sein, aber abgesehen davon, dass ich das nicht kann, hätte ich auch keine Ahnung, wie sich PHP-Dateien mit den HTML-Seiten verknüpfen ließen, damit das auch alles Sinn ergibt... Ja ich weiß, ich wirke total lernfaul, aber so ist das nicht. Ich denke einfach, dass ich erst HTML/CSS perfekt beherrschen sollte, bevor ich mich mit höheren Sprachen befassen sollte.

Perfekt beherrschen musst du es nicht. Um mit PHP oder einer anderen serverseitigen Sprache HTML zu erstellen, muss man im Prinzip nur die Syntaxregeln kennen. Ob man dann Detailwissen hat, was jedes einzelne Element und Attribut macht, oder es nicht hat, macht das Kraut dann auch nicht mehr fett. Also, fang ruhig schon jetzt mit PHP an. Das brauchst du in jedem Fall, um Mail zu versenden. Javascript kannst du zunächst außen vor lassen. Genannt wurde ja bereits Affenformular als Technik, um den Anwender dazu zu bringen, alles richtig einzugeben. Nach dem Einstieg in die Grundlagen zu PHP ist auch die Sicherheit wichtig, vor allem das Wissen um korrekt ausgeführte Kontextwechsel.

Was die Codierung betrifft... Die einzigen Sonderzeichen, die ich verwende, sind die Deutschen (inkl. Satzzeichen wie Halbgeviertstrich). Deswegen gehe ich davon aus, dass diese auf UTF-8 ausgelegt sind.

Das ist ungefähr so, als wenn du Buchstaben aneinanderreihst, und hoffst, dass sie für den Empfänger einen Sinn ergeben. Das tut es aber nur dann, wenn du beim Schreiben die Regeln von Rechtschreibung und Grammatik berücksichtigt hast. Von allein sortieren sich die Buchstaben nicht, auch nicht dann, wenn du ihnen sagst, sie sollen deutsche Sätze ergeben.

Bei Textdokumenten im Computer ist es etwas anders, da muss man dem Editor sagen, dass er das Ergebnis als UTF-8 kodieren soll. Auch der kann nichts automatisch, sondern nur gemäß von Anweisungen oder Voreinstellungen machen. Erst dann kann der Empfänger mit der Kodierungsangabe etwas anfangen, denn nun kann er die Zeichen entsprechend den Regeln der Kodierung korrekt interpretieren.

So habe ich auch keine Ahnung, wie ich das umcodieren soll, zumal ich die Startseite einfach genauso wie das Impressum erstellt habe, also keine unterschiedlichen Einstellungen, was unterschiedliche Ergebnisse im Zeichensatz hervorrufen könnte.

Beim Speichern dem Edior sagen, welche Kodierung zu verwenden ist, oder generell einstellen, dass er eine bestimmte Kodierung nehmen soll.

dedlfix.

[Julius]

Hallo Die IP da halt,

Oh Gott... Ich wollte doch nur eine einfache, schnelle Lösung für mein Problem, und jetzt schlägt man sich hier die Köpfe um den Sinn oder Unsinn der verschiedensten Methoden ein…

Das ist kein „Kopf einschlagen“ sondern eine angeregte Diskussion. Freu dich, am Ende kannst du relativ sicher sein, dass man dir keine halbgaren Lösungen vorschlägt 😀

Daher schreibe ich die Dateien auch entweder in Ms Editor oder direkt im Web-Dateimanager.

Der Windows-Editor ist unbrauchbar, nimm Notepad++, der ist FLOSS und kann Syntaxhighlighing und unterstützt dich beim Editieren besser als der Windows-Editor.

Was PHP betrifft... Soll wohl auf dem Server verfügbar sein, aber abgesehen davon, dass ich das nicht kann, hätte ich auch keine Ahnung, wie sich PHP-Dateien mit den HTML-Seiten verknüpfen ließen, damit das auch alles Sinn ergibt...

Wenn du Dateien mit der Endung .php abspeicherst, werden diese von PHP ausgeführt und die Ausgabe ausgegeben. Du kannst ja einfach mal folgendes in eine .php-Datei packen und die dann aufrufen:

<?php
echo "Hallo Welt!<br>";
echo "3×8 ist: ";
echo 3*8;
?>

Wenn PHP aktiv wird, solltest du so etwas als Ausgabe erhalten:

Hallo Welt!
3×8 ist: 24

Ja ich weiß, ich wirke total lernfaul, aber so ist das nicht.

Keine Sorge, so kommst du nicht rüber, man kann schließlich nicht alles auf einmal lernen. Sich vorerst auf bestimmte Teilgebiete einzuschränken, bedeutet ja schließlich auch ein Verbergen der Komplexität. Ist in der Schule nicht anders 😉.

Ich denke einfach, dass ich erst HTML/CSS perfekt beherrschen sollte, bevor ich mich mit höheren Sprachen befassen sollte.

PHP ersetzt HTML und CSS nicht, sondern ergänzt sie. Genau genommen ist es also keine „höhere Sprache“. Du liegst richtig, dass man etwas HTML können sollte, wenn man sich sinnvoll mit PHP beschäftigen will, aber man muss keineswegs perfekt HTML und CSS können.

PHP kannst du auch bereits nutzen, ohne dass du dich zu 100% damit oder mit HTML und CSS auskennst, beispielsweise, um bestimmte, über mehrere Seiten hinweg konstante Teile deiner Site auszulagern und mithilfe von PHP zusammenzubauen oder um ein Kontaktformular in deine Seite zu integrieren 😀.

Ich hätte halt lieber ein Kontaktformular.

Ich habe da im Wiki doch noch etwas passendes gefunden: https://wiki.selfhtml.org/wiki/PHP/Anwendung_und_Praxis/Formmailer-Advanced

Gib aber zusätzlich auch eine E-Mail-Adresse an, deutsche Gerichte habe in letzter Zeit entschieden, dass ein Kontaktformular alleine nicht ausreicht. Außerdem gibt es Leute, die doch lieber eine E-Mail in ihrem eigenen E-Mail-Programm schreiben, zumal sie dann eine Empfangsbestätigung einbauen können und ihre E-Mail dann im Gesendet-Ordner haben und noch einmal nachlesen können.

Wegen E-Mail-Client würde ich mir keine Sorgen machen, ich nutze Webmail und Firefox öffnet bei Mailto-Links zuverlässig immer die Gmail-Seite.

Ich glaube, dass man dafür vor nicht allzu langer Zeit einen Mechanismus spezifiziert hat (Firefox muss ja irgendwoher wissen, dass du Gmail verwendest!), wie weit der verbreitet ist, kann ich nicht sagen. Ich werde das mal ausprobieren, danke für den Hinweis!

Was die Codierung betrifft... Die einzigen Sonderzeichen, die ich verwende, sind die Deutschen (inkl. Satzzeichen wie Halbgeviertstrich). Deswegen gehe ich davon aus, dass diese auf UTF-8 ausgelegt sind.

Es ist im Allgemeinen eine schlechte Idee, von irgendetwas auszugehen. Du musst in deinem Editor nachschauen, als was kodiert er das speichert. Wenn er diese Möglichkeit nicht bietet, solltest du ihn durch einen besseren ersetzen.

So habe ich auch keine Ahnung, wie ich das umcodieren soll, zumal ich die Startseite einfach genauso wie das Impressum erstellt habe, also keine unterschiedlichen Einstellungen, was unterschiedliche Ergebnisse im Zeichensatz hervorrufen könnte.

Die Startseite enthält aber soweit ich das sehe, nur gültige ASCII-Zeichen, daher funktioniert es (im Sinne von „sieht ordentlich aus“). Dass die Umlaute funktionieren, liegt daran, dass du sie als ü etc. maskierst. Das hat man früher gemacht, als ASCII der kleinste gemeinsame Nenner war. Heute ist das dank Unicode und UTF-8 überflüssig.

Weitere Anmerkungen:

1. Ein Link-Disclaimer im Impressum hat rechtlich keinerlei Wert, ersetze ihn daher besser durch eine andere Formulierung.
2. Kennst du schon das HTML-Grundgerüst im Wiki? Da ist alles Wichtige drin.

Gruß
Julius

[Die IP da halt]

Okay... Ich kriege hier immer so viele Informationen auf einmal... Das ist schon ganz gut, aber ich weiß dann gar nicht mehr, wo ich wie antworten soll... Okay, ich versuche, anzufangen. Ich habe zunächst einmal das Impressum soweit geändert, sollte jetzt „rechtssicher“ sein. Notdürftig habe ich vorübergehend jetzt einen Mailto-Link gesetzt. Zur Erkennung von Gmail: in Firefox habe ich es erst einstellen müssen (Extras → Einstellungen → Anwendungen, dort Mailto auswählen und „Mit Gmail öffnen“ einstellen). Dass eine Angabe im Head-Bereich das Codierungsproblem gelöst hat, habe ich ja bereits erwähnt. Zum Kontaktformular... Ich werde mir mal den Link von Julius ansehen, bis dahin lasse ich erst einmal den Mailto-Link im Impressum.

Ich glaube, jetzt habe ich das wichtigste beantwortet... Tut mir leid, für meine inhaltlich so ungeordneten Beiträge.

[Julius]

Hallo,

Okay... Ich kriege hier immer so viele Informationen auf einmal...

Kein Problem, du musst nicht immer sofort antworten, kannst erst einmal in Ruhe alles verdauen und dann später antworten. Neue Beiträge in einem mehrere Tage alten Thread werden hier in der Regel auch zur Kenntnis genommen und beantwortet.

Das ist schon ganz gut, aber ich weiß dann gar nicht mehr, wo ich wie antworten soll...

Immer unter dem Beitrag, auf den du dich beziehst, und mit den Themen, die in diesem Zweig thematisiert werden. Dieses Forum ist ein echtes threaded Forum und kein Board (manchmal auch fälschlicherweise ebenfalls als „Forum“ bezeichnet), wo neue Beiträge einfach unten dran geklebt werden.
Die Unterschiede zwischen beiden werden in einem etwas älteren, aber immer noch aktuellem Beitrag von Stefan Münz sehr gut erklärt: Foren und Boards

Ich habe zunächst einmal das Impressum soweit geändert, sollte jetzt „rechtssicher“ sein.

„Rechtssicherheit“ kannst du nur erreichen, wenn du nicht auf illegale Seiten verlinkst. Also Bombenbauanleitungen, Kinderporno, extremistisches Gedankengut, etc – und solche Seiten kann man in 99,9% der Fälle durch bloßes Einschalten des Verstands erkennen, man braucht kein Jurist zu sein. Dieser verbesserte Hinweis erfüllt nur den Zweck, darauf hinzuweisen, dass man Links zwar sorgfältig überprüft, aber keinesfalls gewährleisten kann, dass sie sich nicht nachträglich ändern und man daher Hinweise auf anstößige Seiten gerne entgegen nimmt.

Im Prinzip ist auch dieser Text überflüssig, weil auch er keine rechtliche Bedeutung hat. Es gibt allerdings auch Stimmen (ich meine sogar Juristen), die den Standard-Disclaimer (also den, den du vorher hattest), nach dem man sich von allen Links distanziert, als Indiz dafür sehen, dass man die Seiten vor der Linksetzung gar nicht überprüft (= angeguckt) oder gar bewusst auf anstößige oder illegale Inhalte verlinkt.

Zur Erkennung von Gmail: in Firefox habe ich es erst einstellen müssen (Extras → Einstellungen → Anwendungen, dort Mailto auswählen und „Mit Gmail öffnen“ einstellen).

Cool, schaue ich mir mal an.

Dass eine Angabe im Head-Bereich das Codierungsproblem gelöst hat, habe ich ja bereits erwähnt.

Ja, geschrieben hattest du das bereits, aber das Problem gelöst hat es nicht. Du hast bloß die Seite so kaputt gemacht, dass es nicht mehr auffällt. Wie ich bereits schrieb.

Zum Kontaktformular... Ich werde mir mal den Link von Julius ansehen, bis dahin lasse ich erst einmal den Mailto-Link im Impressum.

Wie bereits geschrieben, muss eine E-Mail-Adresse zwingend angeben werden, wenn man ein ordnungsgemäßes Impressum haben möchte.

Gruß
Julius

[Die IP da halt]

Immer unter dem Beitrag, auf den du dich beziehst, und mit den Themen, die in diesem Zweig thematisiert werden. Dieses Forum ist ein echtes threaded Forum und kein Board (manchmal auch fälschlicherweise ebenfalls als „Forum“ bezeichnet), wo neue Beiträge einfach unten dran geklebt werden.

Ich bin offensichtlich ein „Boardkind“, aber ich versuche, mich mit dem System hier anzufreunden.

Ja, geschrieben hattest du das bereits, aber das Problem gelöst hat es nicht. Du hast bloß die Seite so kaputt gemacht, dass es nicht mehr auffällt. Wie ich bereits schrieb.

Ich hatte aber auch schon geschrieben, dass es selbst nach der Reparatur noch funktionierte.

[Matthias Apsel]

Hallo Die IP da halt,

Ich hatte aber auch schon geschrieben, dass es selbst nach der Reparatur noch funktionierte.

Du hast es nicht repariert.

https://validator.w3.org/nu/?doc=https%3A%2F%2Fkiddi-kugel.lima-city.de%2Fimpressum.html

Bis demnächst
Matthias

[encoder]

Oh Gott... Ich wollte doch nur eine einfache, schnelle Lösung für mein Problem

Die einfachste Lösung hast du doch schon durch den Tip "Mailadresse angeben" 😀

Ich ziehe einfach ein Kontaktformular einer einfachen E-Mail-Adresse vor, weil es, naja, professioneller ist.

Findest du? Eine Mail an eine Adresse schicken kriegt inzwischen jeder hin. Auch die dämlichsten...
So ein Formular halte ich nicht für professionell sondern nervtötend. Man muss oft wer weiß alles für sinnlose Angaben machen, zum Teil einen Betreff aus einer Liste auswählen die alles enthält, nur nicht das was gerade passt. Anrede muss ich aus einer Liste auswählen ... so ein Blödsinn. Das kostet alles Zeit und bringt keinen Vorteil.
Das dümmste dabei, man hat den geschriebenen Text nicht im gesendet Ordner der Mails, falls man mal was nachsehen will.

Sowas findet man immer wieder bei Hotlines oder Supportformularen. Zum schnellen Kontakt ist es meiner Meinung nach gar nicht geeignet, eher um abzuschrecken und nicht so viel Arbeit zu haben 😉

Edit: Ein Vorteil des Formulars ist, deine Mailadresse ist nicht öffentlich. Aber mach es wenn schon dann bitte so einfach wie möglich.

[Matthias Apsel]

Hallo encoder,

Edit: Ein Vorteil des Formulars ist, deine Mailadresse ist nicht öffentlich. Aber mach es wenn schon dann bitte so einfach wie möglich.

Ob das ein Vorteil ist…

Bis demnächst
Matthias

[Julius]

Hallo Matthias,

Edit: Ein Vorteil des Formulars ist, deine Mailadresse ist nicht öffentlich. Aber mach es wenn schon dann bitte so einfach wie möglich.

Ob das ein Vorteil ist…

... zumal man ja auch oft eine Antwort erwartet. Falls man wirklich jemanden anonym „trollen“ will, hindert das jemanden nicht daran, sich einfach eine Wegwerf-Adresse zulegen.

Gruß
Julius

[encoder]

Ich meinte die Mailadresse des Seiteninhabers. Die steht nicht öffentlich und für jeden Spambot erkennbar da. Der Absender einer Nachricht sollte natürlich schon seine Adresse angeben wenn er eine Antwort haben will. Also wäre die Eingabe der Mailadresse das einzige Pflichtfeld das ich mir sinnvoll erklären kann.

[Matthias Apsel]

Hallo encoder,

Ich meinte die Mailadresse des Seiteninhabers.

Die meinte ich auch.

Die steht nicht öffentlich und für jeden Spambot erkennbar da.

Die Rechtsprechung ist der Meinung, eine solche Adresse sollte ohne weiteres les- und verwendbar sein.

Bis demnächst
Matthias

[Julius]

Hallo,

So habe ich auch keine Ahnung, wie ich das umcodieren soll, zumal ich die Startseite einfach genauso wie das Impressum erstellt habe, also keine unterschiedlichen Einstellungen, was unterschiedliche Ergebnisse im Zeichensatz hervorrufen könnte.

Ich habe mal mein Windows gebootet und zwei erklärende Screenshots erstellt.

Zeichenkodierung im Windows Editor einstellen (dort muss „UTF-8“ stehen):

Zeichenkodierung in Notepad++ einstellen:

Hier musst du „Konvertiere zu UTF-8 ohne BOM“ auswählen. Die Optionen ohne „Konvertiere“ im Namen sorgen lediglich dafür, dass Notepadd++ die Dateien so liest, als ob sie beispielsweise UTF-8 sind, sie also nur anders interpretiert, aber nicht konvertiert.

Dann musst du nur noch carset in charset umändern und dann sollte alles sauber sein.

Gruß
Julius

[Matthias Apsel]

Hallo Julius,

Die Optionen ohne „Konvertiere“ im Namen sorgen lediglich dafür, dass Notepadd++ die Dateien so liest, als ob sie beispielsweise UTF-8 sind, sie also nur anders interpretiert, aber nicht konvertiert.

Beim nächsten Speichern wird dennoch die neue Kodierung verwendet.

Bis demnächst
Matthias

[Julius]

Hallo Matthias,

Die Optionen ohne „Konvertiere“ im Namen sorgen lediglich dafür, dass Notepadd++ die Dateien so liest, als ob sie beispielsweise UTF-8 sind, sie also nur anders interpretiert, aber nicht konvertiert.

Beim nächsten Speichern wird dennoch die neue Kodierung verwendet.

Das ist ein interessanter Einwand, ich habe mal ein wenig mit ISO-8859-1- und UTF-8-kodiertem Text experimentiert: Die Bytes auf der Festplatte ändern sich tatsächlich nicht, allerdings werden die Bytes im Programm anders interpretiert und auch in der weiteren Verarbeitung im Programm so wie definiert behandelt (was ich im Ursprungs-Posting so meinte). Bei einer Datei mit einer Byte-Folge am Anfang, die als UTF-8-BOM interpretiert werden kann und (zweckmäßigerweise) von notepad++ auch wird, aber ISO-8859-1-kodiertem Inhalt, die dann „uminterpretiert“ und dann gespeichert wird, verschwinden die das UTF-8-BOM darstellenden Bytes aus der Datei, obwohl sie auch in ISO-8859-1 eine Bedeutung haben.

Gruß
Julius

[Die IP da halt]

Das Problem ist, dass ich die Dateien ja nicht direkt von meinem Computer als HTML-Dateien auf den Server lade (also nicht die im Editor gespeicherten Dateien), sondern den Quellcode direkt in den eigenen webbasierten File-Manager von Lima-City kopiere (manchmal auch direkt darin schreibe). Theoretisch müsste es zwar möglich sein, HTML-Dateien im File-Manager hochzuladen, aber bei meiner Methode hat es bspw. den Vorteil, dass ich die Dateien nicht doppelt auf dem Server und auf dem eigenen Computer habe. Zwar wäre das auch eine Möglichkeit, zumal ich sie dann auch lokal gesichert hätte, aktuell sehe ich dazu aber noch keinen Anlass.

[Die IP da halt]

So, habe jetzt von Lima-City den Support kontaktiert. Vielleicht können diese mir erklären, wie sich im File-Manager Dateien in UTF-8 abspeichern lassen. Wie ich gerade festgestellt habe, nützt eine lokale Dateispeicherung ohnehin nichts, da alle Admins über den File-Manager Dateien erstellen können müssen; die aber auch von verschiedenen Geräten darauf zugreifen.

[Die IP da halt]

Keine Ahnung, ob mir hier noch jemand antwortet... Die Kontaktaufnahme mit Lima-City hat ergeben, was ich befürchtet hatte, dass es nicht über den dortigen Editor möglich ist, die Dateicodierung zu ändern. Letzte Frage jetzt: lässt es sich irgendwie einstellen, dass der Browser die Angaben aus dem Charset-Tag bezieht und die Dateicodierung ignoriert?

[Julius]

Hallo,

Die Kontaktaufnahme mit Lima-City hat ergeben, was ich befürchtet hatte, dass es nicht über den dortigen Editor möglich ist, die Dateicodierung zu ändern.

Aber du kannst doch einfach die Dateien lokal erstellen und dann mit einem FTP-Programm wie beispielsweise FileZilla oder WinSCP hochladen. Die FTP-Zugangsdaten dafür solltest du haben.

Letzte Frage jetzt: lässt es sich irgendwie einstellen, dass der Browser die Angaben aus dem Charset-Tag bezieht und die Dateicodierung ignoriert?

Erst mal mit FTP und einem ordentlichen lokalen Editor probieren und nicht mit dieser Webeditor-Krücke. Dann sehen wir weiter.

Außerdem scheinst du noch nicht verstanden zu haben, wie eine Zeichenkodierung (und dessen richtige Deklaration) funktioniert: https://wiki.selfhtml.org/wiki/Zeichenkodierung

Gruß
Julius

[Julius]

Hallo,

Theoretisch müsste es zwar möglich sein, HTML-Dateien im File-Manager hochzuladen, aber bei meiner Methode hat es bspw. den Vorteil, dass ich die Dateien nicht doppelt auf dem Server und auf dem eigenen Computer habe.

Das kannst du auch mit einem echten FTP-Programm statt des WebFTP, zumal dieses Vorgehen sogar von deinem Hoster empfohlen wird. In FileZilla kann man das einen Rechtsklick auf die entsprechende Datei und den Menüpunkt „Ansehen / Bearbeiten“ erreichen. Dann hast du keine Duplikate.

Falls Lima-City (zu Lasten der Sicherheit ihrer Nutzer) noch auf das unsichere, da unverschlüsselte, FTP setzt, kannst du auch mit dem Windows Explorer genauso wie auf lokale Dateien auf den Server zugreifen. Falls Lima-City auf das sichere SFTP setzt, geht das nicht, SFTP kann der Windows Explorer noch nicht. Zu (S)FTP gibt es auch Infos im Wiki: Grundlagen/File Transfer Protocol

Gruß
Julius

[Die IP da halt]

Habe es gerade mit dem Windows-Explorer probiert, der Zugriff funktioniert schon mal. Was mich etwas verwundert: trotz inkorrekter Zeichendarstellung zeigt Firefox unter „Seiteninformationen“ bei „Textcodierung“ „UTF-8“ an.

[dedlfix]

Tach!

Habe es gerade mit dem Windows-Explorer probiert, der Zugriff funktioniert schon mal. Was mich etwas verwundert: trotz inkorrekter Zeichendarstellung zeigt Firefox unter „Seiteninformationen“ bei „Textcodierung“ „UTF-8“ an.

Wenn ich auf einen Briefumschlag schreibe 100 € und nur 20 € reinlege, zeigt der Umschlag weiterhin 100 € an. Auch ändert sich nichts am Inhalt, wenn ich erst das Geld reinlege und dann einen anderen Betrag draufschreibe. Auch bei der Zeichenkodierung wird es erst dann komplett richtig, wenn die Angabe zum Inhalt passt. Es ist jedenfalls nicht so, dass wenn der Browser UTF-8 oder was auch immer als Angabe sieht, dann sämtliche kaputte Daten richtig erkennen könnte.

dedlfix.

[Die IP da halt]

So. Scheint jetzt endlich zu funktionieren (glaube ich). Allerdings finde ich alle Dateien, die auf dem FTP-Server sind, auch im Ordner „Dokumente“ auf dem Computer, soll das so sein? Und... Wenn ich die Dateien in Dokumente bearbeite, werden die Änderungen dann sofort am FTP-Server übernommen (habe die Anmeldedaten gespeichert, müsste also mit dem Windows-Explorer dauerangemeldet sein)? Und wenn nicht, wie kann ich die Dateien dann überhaupt noch bearbeiten, ohne, sie laufend durch Neuerstellung zu ersetzen (so habe ich es jetzt bei der Umcodierung gemacht, also in Microsoft Editor bei „Speichern unter…“ im selben Ordner [bei Dokumente] mit UTF-8 abgespeichert und dann in den FTP-Ordner rüberkopiert)? Schon wieder nur Fragen…

[Julius]

Hallo,

Scheint jetzt endlich zu funktionieren (glaube ich).

Die Zeichenkodierung ja, aber dein HTML ist noch nicht valide (um das festzustellen, reicht ein Blick in die Quelltextansicht des Browsers, FF zeigt Fehler nämlich an):

Du musst das a-Element schließen.

Allerdings finde ich alle Dateien, die auf dem FTP-Server sind, auch im Ordner „Dokumente“ auf dem Computer, soll das so sein?

Dieser „Dokumente“-Ordner ist, wenn ich mich recht entsinne und das auch noch für aktuelle Windows-Versionen gültig ist, kein richtiger Ordner, weil die Dateien physisch auch wo anders liegen können (oder sogar müssen?) und im Dokumente-Ordner quasi nur Links (im konkreten Fall halt auf den Webspace) auf diese gespeichert werden. Das kannst du einfach überprüfen, indem du eine Datei anlegst (oder eine vorhandene änderst), die bearbeitest und dann vom Webspace abrufst (ggf. mittels Strg und F5 neu laden, damit die auch wirklich vom Server und nicht aus dem Cache kommt). Falls die Dateiinhalte letztlich die gleichen sind – also bloß Links im Ordner „Dokumente“ liegen, siehst du deine Änderungen auch in den anderen Dateien.

Und... Wenn ich die Dateien in Dokumente bearbeite, werden die Änderungen dann sofort am FTP-Server übernommen (habe die Anmeldedaten gespeichert, müsste also mit dem Windows-Explorer dauerangemeldet sein)?

Auch das kannst du einfach durch das Ändern der Dateien und anschließender Kontrolle, was mit den anderen Dateien passiert, herausfinden.

Und wenn nicht, wie kann ich die Dateien dann überhaupt noch bearbeiten, ohne, sie laufend durch Neuerstellung zu ersetzen (so habe ich es jetzt bei der Umcodierung gemacht, also in Microsoft Editor bei „Speichern unter…“ im selben Ordner [bei Dokumente] mit UTF-8 abgespeichert und dann in den FTP-Ordner rüberkopiert)?

Schau erst mal ob dem wirklich so ist. Falls der Windows Explorer sich wirklich solche Schnitzer leisten sollte, kannst du ja immer noch FileZilla oder WinSCP benutzen.

Gruß
Julius

[Die IP da halt]

So, alle A-Tags geschlossen.

Die Dokumente-Dateien ändern nichts an den Dateien auf dem FTP-Server. Allerdings kann ich, wenn’s auch umständlich ist, erst einmal die Dateien im Dokumente-Ordner ändern und dann zum FTP-Server kopieren. Dokumente ist ein richtiger Dateiordner, die darin gespeicherten Dateien zeigen die Adresse auch, wenn man sie im Browser aufruft.

[Matthias Apsel]

Hallo Die IP da halt,

So, alle A-Tags geschlossen.

Die a-Tags waren auch vorher schon geschlossen; ein a-Element war nicht geschlossen. Beachte den Unterschied.

Btw.: Vergiss, dass es target="_blank" gibt. Bzw. setze es (wie in diesem Forum) nur auf ausdrücklichen Nutzerwunsch ein. Überlass dem Nutzer die Entscheidung, ob er den Link in einem neuen Fenster oder Tab öffnen möchte.

Bis demnächst
Matthias

[Die IP da halt]

Ich habe die Funktion zum direkten Öffnen der Seite in einem neuen Tab gesetzt, weil der Link praktisch ja auf eine externe Seite verweist. Ich kann aus eigener Nutzererfahrung sprechen, wenn ich sage, dass ich so manches Mal froh wäre, wenn Links auf andere Seiten in einem neuen Tab geöffnet werden, damit ich danach leichter zur vorherigen zurückkehren kann (zumindest, falls ich auch auf der neuen Seite weitere Links geklickt habe). Zwar öffne ich die Seite auch gleich selbst in einem neuen Tab, wenn ich gerade daran denke, dass das nützlich werden könnte, aber ich vergesse es auch oft genug und verlasse mich dann auf die Verlinkung der Seite.

[Julius]

Hallo,

Ich habe die Funktion zum direkten Öffnen der Seite in einem neuen Tab gesetzt, weil der Link praktisch ja auf eine externe Seite verweist.

Ja und? Warum sollte man eine externe Seite nicht im aktuellen Tab bzw. Fenster öffnen wollen?

Ich kann aus eigener Nutzererfahrung sprechen, wenn ich sage, dass ich so manches Mal froh wäre, wenn Links auf andere Seiten in einem neuen Tab geöffnet werden, damit ich danach leichter zur vorherigen zurückkehren kann (zumindest, falls ich auch auf der neuen Seite weitere Links geklickt habe).

Ich kann aus meiner Erfahrung sprechen, dass du damit den Nutzer bevormundest:

• Meine Mutter benutzt keine Tabs, sie benutzt die Zurück- und Vor-Tasten des Browser, die bei einem zwangsweise geöffneten neuen Tab dummerweise nicht funktionieren, weil jeder Tab seine eigene History besitzt (ich meine, dass Mozilla da gerade ein paar Experimente am laufen hat, eine Tabs die History des öffnenden Tabs mitzugeben – aber das sind erstmal nur Experimente).
• ich öffne neue Tabs dann (und nur genau dann), wenn ich es will

Zwar öffne ich die Seite auch gleich selbst in einem neuen Tab, wenn ich gerade daran denke, dass das nützlich werden könnte, aber ich vergesse es auch oft genug und verlasse mich dann auf die Verlinkung der Seite.

Ich öffne auch gerne Links in neuen Tabs, habe mir die Funktion auf die mittlere Maus-Taste gelegt und weil ich mich eben nicht auf irgendwelche Seiten verlassen möchte, habe ich ein Greasemonkey-Skript im Browser, das alle target=_blanks aus dem DOM kegelt – ich bestimme, ob ich einen neuen Tab öffnen möchte und niemand sonst.

Eigentlich wäre ich sogar froh darüber, wenn man das in Firefox fein einstellen könnte (oder die target=_blank komplett eliminieren würden):

• neuen Tab [/Fenster] bei target=_blank öffnen
• neuen Tab [/Fenster] bei externem Link (andere Domain) öffnen
• alle Links in neuen Tabs [/Fenstern] öffnen

Dummerweise kann man das Öffnen neuer Tabs in about:config zwar abschalten, aber dann werden auch keine neuen Tabs geöffnet, wenn ich beispielsweise in meinem E-Mail-Programm auf einen Link klicke, was ich aber möchte.

Gruß
Julius

[Matthias Apsel]

Hallo Julius,

Ich öffne auch gerne Links in neuen Tabs, habe mir die Funktion auf die mittlere Maus-Taste gelegt

gelegt⁉️

Ist das nicht automatisch so? (Mausrad oder mittlere Maustaste?)

Bis demnächst
Matthias

[Julius]

Hallo Matthias,

Ich öffne auch gerne Links in neuen Tabs, habe mir die Funktion auf die mittlere Maus-Taste gelegt

gelegt⁉️

Ist das nicht automatisch so? (Mausrad oder mittlere Maustaste?)

Stimmt, du hast Recht. In about:config steht es vom Status her auf „Standard“.

Gruß
Julius

[Die IP da halt]

Hallo Julius,

(Ich versuche, mich jetzt daran zu gewöhnen, dass man sich hier bei jedem neuen Beitrag neu begrüßt.) Deiner Mutter würde ich empfehlen, dass sie, wenn sich eine Seite im neuen Tab geöffnet hat, mit dem Tastaturbefehl STRG+F4 den Tab wieder zu schließen (zumindest unter Windows, so pflege ich es auch zu tun). Ich meine auch mal gesehen zu haben, dass man bei Target-Links, genauso wie man auch manuell einen neuen Tab öffnen, den Link auch manuell im selben Tab öffnen kann. Natürlich muss man dafür zuvor wissen, dass es sich um einen Target-Link handelt und ich bin mir auch nicht ganz sicher, aber es könnte halt sein. Was den Rest anbelangt... Ich denke, es ist einfach eine sehr umstrittene Ansichtssache, was die sog. „Bevormundung“ bei Tabs betrifft. Aber ich möchte auch anmerken, dass man sich bei der Entwicklung von HTML was dabei gedacht haben wird, als man diese Funktion ohne viel Umstände einbaute.

Gruß, Die IP da halt

[Matthias Apsel]

Hallo Die IP da halt,

Ich meine auch mal gesehen zu haben, dass man bei Target-Links, genauso wie man auch manuell einen neuen Tab öffnen, den Link auch manuell im selben Tab öffnen kann.

Ich wüsste nicht, wie das gehen sollte,

Natürlich muss man dafür zuvor wissen, dass es sich um einen Target-Link handelt

Woher soll die „Laufkundschaft“ das wissen können?

und ich bin mir auch nicht ganz sicher, aber es könnte halt sein.

Ich glaube nicht.

Was den Rest anbelangt... Ich denke, es ist einfach eine sehr umstrittene Ansichtssache, was die sog. „Bevormundung“ bei Tabs betrifft. Aber ich möchte auch anmerken, dass man sich bei der Entwicklung von HTML was dabei gedacht haben wird, als man diese Funktion ohne viel Umstände einbaute.

Dazu kannst du diesen Artikel lesen.

Bis demnächst
Matthias

[dedlfix]

Tach!

Dazu kannst du diesen Artikel lesen.

Wie man in den dortigen Kommentaren lesen kann, ist man anscheinend in der Minderheit, wenn man das in jedem Fall selbst entscheiden möchte. Manche Leute sind auch eigenartig. Sie argumentieren damit, dass die Anwender ihre Browser/Mäuse nicht beherrschen und man den ahnungslosen Anwendern deshalb helfen müsse. Sie selbst wissen jedoch um diese Funktionalität, ärgern sich aber, wenn sie sie nicht nutzen und der Link kein target=_blank hat. Die wissen es und können es, machen es aber nicht und ärgern sich dann - über die Webseite statt über ihre eigene Unfähigkeit, den ihnen bekannten Mechanismus zu nutzen, um die von ihnen gewünschten Komfort zu erhalten. Da fehlen mir die Worte. Und nimmt es den gewünschten Komfort, ohne dass ich gegensteuern kann (außer im Firefox mit einem Add-On).

dedlfix.

[Julius]

Hallo Matthias,

Ich meine auch mal gesehen zu haben, dass man bei Target-Links, genauso wie man auch manuell einen neuen Tab öffnen, den Link auch manuell im selben Tab öffnen kann.

Ich wüsste nicht, wie das gehen sollte,

Den Link in die Adresszeile des Browser ziehen. Ist aus Usability-Sicht imho aber genauso ein Schrott wie über das Kontextmenü gehen zu wollen müssen (wenn es denn implementiert wäre).

Gruß
Julius

[Die IP da halt]

Hallo Matthias Apsel,

Erst mal Entschuldigung, dass ich nicht auf jeden einzelnen hier antworten kann... Ich versuche aber, allgemein auf alle wichtigen Punkte einzugehen.

Ich wüsste nicht, wie das gehen sollte,

Nachdem ich es in Firefox gerade extra getestet habe, scheint es auch wirklich nicht so zu funktionieren, wie ich es in Erinnerung hatte.

Dazu kannst du diesen Artikel lesen.

Auch wenn ich jetzt eine Gegenposition gegenüber der hier in diesem Forum vorherrschenden Meinung einnehme, aber ich stimme dem Großteil der dortigen Kommentatoren zu. Nach meiner Einschätzung ist es leider tatsächlich so, das ein beträchtlicher Anteil der Internetnutzer auf dem „Bildungsstand“ ist, dass sie wissen, wie man Suchbegriffe in die Suchleiste eingibt, Adressen aufruft, evtl. auch Tabs öffnet und schließt. Aber von den „weiterführenden Techniken“, die das Web bzw. der Browser bietet, haben viele bedauerlicherweise keine Ahnung. Ich sage nicht, dass man es denjenigen Recht machen muss, nur, damit auch Leute, die nicht weiter denken, auch problemlos mit dem Fortschritt umgehen können, aber ich denke, man muss es schon gar nicht der etwas kleineren Masse gerecht machen, die nicht mal mit Tabs umgehen kann. Das ist dann eine Gruppe, von denen ich sage, wer nicht mal damit klar kommt, hat auch nichts im Internet verloren. Allerdings ist das automatische Öffnen neuer Tabs auch für diejenigen ein Service, die zwar mit den weiteren Funktionen vertraut sind, aber nicht bei jedem Link nachdenken wollen, ob man das jetzt in welchem Tab wie öffnen soll.

Gruß, Die IP da halt

[dedlfix]

Tach!

Deiner Mutter würde ich empfehlen, dass sie, wenn sich eine Seite im neuen Tab geöffnet hat, mit dem Tastaturbefehl STRG+F4 den Tab wieder zu schließen (zumindest unter Windows, so pflege ich es auch zu tun).

Ich bin nicht seine Mutter, aber auch ich pflege recht ungern von meiner Maus auf die Tastatur zu wechseln und dann wieder zurück, wenn ich stattdessen einfach den bei mir vorhandenen Zurück-Button auf der Maus nehmen kann.

Ich meine auch mal gesehen zu haben, dass man bei Target-Links, genauso wie man auch manuell einen neuen Tab öffnen, den Link auch manuell im selben Tab öffnen kann.

Wirklich? Ich hab das noch nicht gefunden. Ich würde es im Kontextmenü vermuten. Oder als Einstellung im Browser.

Natürlich muss man dafür zuvor wissen, dass es sich um einen Target-Link handelt und ich bin mir auch nicht ganz sicher, aber es könnte halt sein.

Ja, das löst das Problem nicht, das mir da die Webseitenbetreiber einbrocken, weil ich dann ständig nur noch diese Funktion nehmen müsste statt den Links-Klick. Ich kann mir derzeit nur im Firefox behelfen, da gibt es ein Plugin, der ungefragte neue Tabs unterbindet. Im Chrome fluche ich jedesmal, wenn man mir meine Navigation kaputtmacht.

Was den Rest anbelangt... Ich denke, es ist einfach eine sehr umstrittene Ansichtssache, was die sog. „Bevormundung“ bei Tabs betrifft. Aber ich möchte auch anmerken, dass man sich bei der Entwicklung von HTML was dabei gedacht haben wird, als man diese Funktion ohne viel Umstände einbaute.

Ja, man dachte sich, dass das eine prima Funktionalität ist im Zusammenhang mit Frames. Man bestimmte damit den Ziel-Frame. target gab es auch nicht in der Strict-Variante von HTML, in der es auch keine Frames gab. Man hatte also nicht im Sinn, dass man das zum Spammen von neuen Fenstern/Tabs verwenden soll. Man hat diesen Missbrauch mit HTML5 leider zum zulässigen Verfahren auch abseits von Frames erhoben, nachdem es bereits ein Quasi-Standard geworden war.

dedlfix.

[Gunnar Bittersmann]

@@Die IP da halt

Aber ich möchte auch anmerken, dass man sich bei der Entwicklung von HTML was dabei gedacht haben wird, als man diese Funktion ohne viel Umstände einbaute.

Davon ist nicht unbedingt auszugehen. Es gibt in HTML so einigen Blödsinn, bspw. das multiple-Attribut für select-Felder.

LLAP 🖖

[Julius]

Moin!

(Ich versuche, mich jetzt daran zu gewöhnen, dass man sich hier bei jedem neuen Beitrag neu begrüßt.)

Das ist hier wohl seit Urzeiten so Sitte, außerdem wird die Begrüßung von der Forumssoftware vorausgefüllt, wenn man sich das aktiv so eingestellt hat. Ich finds auch angenehmer, als einfach so reinzurumpeln (war wahrscheinlich auch der Grund, warum das CForum diese Möglichkeit bietet). Nebenbei kann man dann sehen, auf wen sich der Poster bezieht.

Deiner Mutter würde ich empfehlen, dass sie, wenn sich eine Seite im neuen Tab geöffnet hat, mit dem Tastaturbefehl STRG+F4 den Tab wieder zu schließen (zumindest unter Windows, so pflege ich es auch zu tun).

Geht am eigentlichen Problem vorbei: Sie kann oder will nicht mit Tabs arbeiten (ich betreibe da noch Feldforschung), scheint sie sogar irgendwie auszublenden und nimmt sie anscheinend erst dann wahr, wenn der Browser beim Schließen meckert (diese Meldung war auch das erste, was sie erwähnte, als ich sie nach „Tabs“ fragte!). Falls eine Website bei ihr im Browser einen neuen Tab öffnet, hat der Seiten-Ersteller erreicht, was er eigentlich verhindern wollte: Die Seite verschwindet von ihrer Bildfläche, weil sie die Seite über den Zurück-Button nicht erreichen kann. Auf mobilen Geräten ist das das Selbe: Dort fliegen vor Ewigkeiten geöffnete Tabs herum, die sie gar nicht mehr auf dem Schirm hatte. Sie ist auch kein Einzelfall, ich habe das schon mehrmals bei dieser Generation gesehen. Tastenkürzel scheinen auch nicht ihr Ding zu sein, obwohl sie im Job viel am PC sitzt.

Aber ich möchte auch anmerken, dass man sich bei der Entwicklung von HTML was dabei gedacht haben wird, als man diese Funktion ohne viel Umstände einbaute.

In HTML gibt es viele Dinge, die obsolet oder von deren Verwendung mittlerweile abzuraten ist:

• Framesets (die waren nur aufgrund der normativen Macht des Faktischen mal im Standard enthalten) (≠ IFrame!)
• Reset-Buttons in Formularen (einfach das Formular neu zu laden, erfüllt den gleichen Zweck)
• input[type="submit"], das button-Element ist viel flexibler, da man HTML als Beschriftung angeben kann, außerdem semantischer, da der Inhalt von den Tags umfasst wird und nicht in einem Attribut steht und ein Button nun mal ein Button und kein Eingabeelement wie ein Textfeld ist.
• Image-Maps (funktionieren nicht bei Skalierung des Bildes, besser auf SVG zurückgreifen)
• Präsentationsbezogene Elemente oder Attribute, font, vmargin, border und face

Nichts ist in Stein gemeißelt, besonders nicht das Web.

Gruß
Julius

[Die IP da halt]

Hallo Julius,

Geht am eigentlichen Problem vorbei: Sie kann oder will nicht mit Tabs arbeiten

Tabs sind im heutigen Internet unumgänglich (wenn man nicht unzählige Fenster auf haben will). Daher ist das ein individuelles Problem ihrerseits, worauf kein Webentwickler rücksicht nehmen wird und kann. Ich kann auch sagen, dass ich keine runden Räder an meinem Auto haben will, die Fortbewegung gestaltet sich dann nur etwas schwierig…

Gruß, Die IP da halt

[Gunnar Bittersmann]

@@Die IP da halt

Tabs sind im heutigen Internet unumgänglich (wenn man nicht unzählige Fenster auf haben will).

Ja. Aber es sollte in der Hand des Nutzers liegen, wann sie einen neuen Tab aufmachen will und wann nicht.

Daher ist das ein individuelles Problem ihrerseits, worauf kein Webentwickler rücksicht nehmen wird und kann.

Nein. Es ist ein allgemeines Problem im Web, dass sich dort Entwickler tummeln, die nur auf ihre eigenen Belange, nicht aber auf die der Nutzer Rücksicht nehmen.

Es sind nicht die Nutzer, die – wie du sagst – „nichts im Internet verloren [haben]“, sondern diese Sorte von Entwicklern hat im Web nichts verloren.

LLAP 🖖

[Die IP da halt]

Es sind nicht die Nutzer, die – wie du sagst – „nichts im Internet verloren [haben]“, sondern diese Sorte von Entwicklern hat im Web nichts verloren.

Ich denke, ich sollte das jetzt einfach mal ignorieren, weil ich diese Meinungsverschiedenheit (mehr ist das nicht) nicht so hohe Priorität zuordne, dass sie zu einer Eskalation in diesem Forum führen sollte.

[Gunnar Bittersmann]

@@Die IP da halt

Es sind nicht die Nutzer, die – wie du sagst – „nichts im Internet verloren [haben]“, sondern diese Sorte von Entwicklern hat im Web nichts verloren. Ich denke, ich sollte das jetzt einfach mal ignorieren

Das denke ich nicht.

diese Meinungsverschiedenheit (mehr ist das nicht)

Es scheint mir eine Meinungsverschiedenheit über Grundlegendes zu sein. Weniger ist das nicht.

nicht so hohe Priorität zuordne, dass sie zu einer Eskalation in diesem Forum führen sollte.

Wann immer Entwickler ihre Belange über die der Nutzer stellen, werde ich das hier im Forum eskalieren. Immer und immer wieder.

LLAP 🖖

[Die IP da halt]

Bei allem Respekt gegenüber deinem rebellischen Talent, aber meinst du nicht, dass man bei so einer Sache nicht gleich übertreiben sollte? Nur, weil man ein kleinen Code-Schnipsel mehr oder weniger in einem Link verbaut, heißt es nicht, dass einem die Nutzer egal wären.

[MudGuard]

Hi,

Nichts ist in Stein gemeißelt, besonders nicht das Web.

sprach der Steinmetz

cu,
Andreas a/k/a MudGuard

[Gunnar Bittersmann]

@@Die IP da halt

Ich habe die Funktion zum direkten Öffnen der Seite in einem neuen Tab gesetzt, weil der Link praktisch ja auf eine externe Seite verweist.

Was sind „externe Seiten“?

Ich kann aus eigener Nutzererfahrung sprechen, wenn ich sage, dass ich so manches Mal froh wäre, wenn Links auf andere Seiten in einem neuen Tab geöffnet werden

Dann mach das doch. – Du hast es in der Hand.

Wenn jedoch target="_blank" gesetzt ist, hat der Nutzer es nicht in der Hand. Er kann die Folgeseite dann nicht so einfach im selben Tab öffnen, wenn er es möchte.

damit ich danach leichter zur vorherigen zurückkehren kann

Bei Mobilgeräten sieht das mit „leichter zur vorherigen Seite zurückkehren können“ ganz anders aus.

TL;DR: Es mag in Ausnahmefällen Gründe geben, dass der Seitenautor dem Nutzer die Entscheidung abnimmt (d.h. wegnimmt). Im Allgemeinen sprechen aber die Gründe dagegen, dies zu tun.

“Don't pollute my screen with any more windows [/ tabs], thanks.” —Jakob Nielsen

LLAP 🖖

[Julius]

Moin!

Die Dokumente-Dateien ändern nichts an den Dateien auf dem FTP-Server. Allerdings kann ich, wenn’s auch umständlich ist, erst einmal die Dateien im Dokumente-Ordner ändern und dann zum FTP-Server kopieren.

Das klingt arg umständlich. Vielleicht kann man dieses Verhalten umstellen? Ansonsten solltest du vielleicht mal FileZilla ausprobieren, ich komme damit gut klar.

Gruß
Julius

[Die IP da halt]

Oh, das habe ich jetzt erst gesehen. Was Filezilla betrifft, würde ich es meiden, da es unvermeidbar mit Malware versäucht zu sein scheint (laut Wikipedia). Ich habe noch ein FTP-Programm als Firefox-Add-on (Fire FTP), aber auch da müsste ich mich erst länger dran gewöhnen, bis ich damit klar kommen werde. Ich könnte ja auch die Dateien offline erstellen und sie dann über den Web-FTP von Lima-City hochladen, macht aber beim aktuellen Zustand auch keinen Unterschied mehr.

[Die IP da halt]

Letzte Meldung: Lösung ist Microsoft Visual Studio. Damit kann ich auf FTP zugreifen und die Dateierstellung ist unglaublich eingfach.

[Julius]

Hallo,

Was Filezilla betrifft, würde ich es meiden, da es unvermeidbar mit Malware versäucht zu sein scheint (laut Wikipedia).

Man muss nicht alles glauben, was bei Wikipedia steht. Besonders wenn sich die Argumentation des betreffenden Absatzes so leicht widerlegen lässt, wenn man einfach die Installer von Sourceforge herunterlädt (ausführen muss man sie ja nicht direkt) und dann mal die SHA512-Hashsummen mit den angegebenen vergleicht: Sie sind identisch, was ja laut Wikipedia eben nicht der Fall sein sollte. Natürlich kann auch der Entwickler selbst die Adware eingebaut oder Sourceforge die SHA512-Hashes generiert haben, das müsste man noch überprüfen (Taucht im Download-Dialog Adware auf? Werden verdächtige Verbindungen aufgebaut?), auch wenn ich es für unrealistisch halte.

Selbst wenn der benutzte Installer für Windows verseucht wäre, wären Linux-Distributionen nicht davon betroffen, da man sich dort in der Regel FileZilla aus den Repositories der Distribution holt.

Ich könnte ja auch die Dateien offline erstellen und sie dann über den Web-FTP von Lima-City hochladen, macht aber beim aktuellen Zustand auch keinen Unterschied mehr.

Es gibt noch zahlreiche andere FTP-Programme, die du ausprobieren kannst, beispielsweise:

• Cyberduck
• WinSCP (bereits (mehrfach?) von mir hier im Thread erwähnt)

Gruß
Julius

[Die IP da halt]

Hallo,

Wie bereits gesagt, die vorerste Lösung ist Visual Studio. Wie das dann mit der Bearbeitung durch mehrere Admins funktioniert, ohne, dass alle Visual Studio installieren (evtl. auch ein anderes FTP-Programm) müssen, muss ich dann weiter sehen, für mich selbst genügt das erst einmal.

Gruß, Die IP da halt

[Gunnar Bittersmann]

@@Die IP da halt

Wie bereits gesagt, die vorerste Lösung ist Visual Studio. Wie das dann mit der Bearbeitung durch mehrere Admins funktioniert

Spätestens dann ist ein Versionskontrollsystem (git o.ä.) angesagt. Ansonsten kann es passieren, dass einer die Änderungen eines anderen unvorhergesehen (und womöglich auch unerkannt) überschreibt.

LLAP 🖖

[Die IP da halt]

Ich weiß nicht wieso... Aber das Codierungsproblem hat sich erledigt, als ich Folgendes im Head-Bereich hinzugefügt habe: <meta name="viewport" content="width=device-width, initial-scale=1.0">

[Julius]

Hallo,

Ich weiß nicht wieso... Aber das Codierungsproblem hat sich erledigt, als ich Folgendes im Head-Bereich hinzugefügt habe: <meta name="viewport" content="width=device-width, initial-scale=1.0">

Nein, damit hat das nichts zu tun:
Du hast die charset-Angabe kaputt gemacht: <meta <meta carset="UTF-8">

Daher fällt der Browser auf ISO-irgendwas zurück und dann passt die Zeichenkodierung, die der Browser annimmt, ungewollt wieder zu der des Dokuments. Wie ich bereits schrieb.

Benutze den Validator, speichere dein Dokument mit einer Zeichenkodierung, die der im Meta-Element angegebenen entspricht (bevorzugt UTF-8) und benutze einen Editor, der Syntaxhighlighting beherrscht (dann kannst du auch Syntaxfehler in deinem HTML besser erkennen).

Gruß
Julius

[Die IP da halt]

Ich habe den Fehler jetzt im Meta-Tag behoben... Der Text wird immer noch korrekt codiert. Was den Validator betrifft... Der hilft mir nur eingeschränkt weiter, weil ich in der englischen Sprache alles andere als bewandert bin, schon gar nicht, dass es für diese komplexen Texte ausreichen würde. Ich könnte natürlich jeden einzelnen Teil mit Google übersetzen lassen... Aber ob das bei Googles Kompetenz ausreicht, diese Zusammenhänge zu verstehen, mag ich bezweifeln.

[Tabellenkalk]

Hallo,

Ich habe den Fehler jetzt im Meta-Tag behoben...

Nicht den, sondern einen Fehler hast du darin behoben.
Pro-Tipp: Zeichensätze haben nix mit Autositzen zu tun.

Gruß
Kalk

[pl]

Kann mir jemand bei der Frage helfen, wie man mit JavaScript ein einfaches Kontaktformular erstellen kann?

Das Formular wird nicht mir JavaScript (JS) erstellt sondern mit HTML. JS dient lediglich dazu, die einzelnen Felder auszulesen. Im SELFWiki findest Du alles, was hierzu notwendig ist, einschließlich encoding.

Eine Besonderheit wäre da noch interessant: würde es gehen, dass die über das Formular gesendeten Nachrichten an mehrere E-Mail-Adressen versendet werden?

Formulardaten werden per Ajax zunächst an den Webserver gesendet. Dort können sie, über einen serverseitigen Prozess, an mehrere Empfänger verteilt werden.

MfG

[Regina Schlauklug]

Kann mir jemand bei der Frage helfen, wie man mit JavaScript ein einfaches Kontaktformular erstellen kann?

Das Formular wird nicht mir JavaScript (JS) erstellt sondern mit HTML. JS dient lediglich dazu, die einzelnen Felder auszulesen.

Javascript dient bestenfalls dazu, den Nutzer direkt bei der Eingabe (und nicht erst nach Absenden) auf Fehler hinzuweisen oder das Formular, abhängig von eingegebenen Daten, zu verändern.

Formulardaten werden per Ajax zunächst an den Webserver gesendet.

Das halte ich für groben Unfug. Formulardaten können, seit HTML Formulare unterstützt, per HTTP-POST quasi selbständig an den Server gesendet werden und jeder Server unterstützt derlei Datenübermittlung. Auf diese POST-Anfrage noch Javascript bzw. Ajax obendrauf zu klemmen verkompliziert die Angelegenheit nur, ohne auch nur ansatzweise irgendeinen Nutzen zu bieten.

Kurzum: Wer ein HTML-Formular erstellt und mit Javascript anfängt, zäumt das Pferd von hinten auf, bevor er feststellt, dass es sich um ein Kamel handelt.

[pl]

Das halte ich für groben Unfug.

Die Frage bezog sich auf JavaScript! Und selbstverständlich kann man ein Formular auch mit JS absenden, seit wann ist das grober Unfug!?

[Julius]

Hallo pl,

Das halte ich für groben Unfug.

Die Frage bezog sich auf JavaScript!

Der TO möchte ein Kontaktformular erstellen, dass ihm eine bzw. zwei E-Mails sendet. Das geht nur Serverseitig, weil Clientseitig oft kein E-Mail-Client installiert ist. Also brauchst du eine Server-seitige Programmiersprache, beispielsweise PHP.

Ihm dann JavaScript als Grundvoraussetzung vorzuschlagen, ist tatsächlich grober Unfug.

Und selbstverständlich kann man ein Formular auch mit JS absenden, seit wann ist das grober Unfug!?

Man kann es aber auch ohne machen. Und weil der TO sich mit JavaScript noch nicht auskennt, ist das auch zu empfehlen, zumal JavaScript hierfür nicht wirklich nötig ist.

Gruß
Julius

[pl]

Ihm dann JavaScript als Grundvoraussetzung vorzuschlagen, ist tatsächlich grober Unfug.

Hab ich auch nicht gemacht. Im Übrigen kann man alles lernen, auch JavaScript. Darüber könntest Du mal nachdenken, und ja, Du entscheidest doch gar nicht über das Wie und die Art und Weise, wie sich andere ihr Wissen aneignen!

MfG

[Julius]

Hallo pl,

Ihm dann JavaScript als Grundvoraussetzung vorzuschlagen, ist tatsächlich grober Unfug.

Hab ich auch nicht gemacht.

Und was sind dann Sätze wie „JS dient lediglich dazu, die einzelnen Felder auszulesen.“ oder „Formulardaten werden per Ajax zunächst an den Webserver gesendet.“? Bei einem Anfänger kannst du nicht davon ausgehen, dass er weiß, was progressive enhancement bedeutet.

Im Übrigen kann man alles lernen, auch JavaScript.

Das habe ich nicht infrage gestellt. Nur scheint es mir nicht sinnvoll, das alles (JavaScript und eine Server-seitige Programmiersprache) auf einmal lernen zu müssen, bloß um ein Kontaktformular zu erstellen. Erst einmal einfach anfangen und dann immer weiter machen, macht wahrscheinlich mehr Freude.

Darüber könntest Du mal nachdenken, und ja, Du entscheidest doch gar nicht über das Wie und die Art und Weise, wie sich andere ihr Wissen aneignen!

Du aber genauso wenig. Der TO kann ja aus dieser Diskussion eine für sich passende Lösung heraussuchen, und zu deiner doch sehr JS-fixierten Lösung sollte halt angemerkt werden, dass es grundsätzlich auch ohne JS und man mit JS halt mehr machen kann.

Gruß
Julius

[pl]

Auf diese POST-Anfrage noch Javascript bzw. Ajax obendrauf zu klemmen verkompliziert die Angelegenheit nur, ohne auch nur ansatzweise irgendeinen Nutzen zu bieten.

So ein Quatsch! JS steigert die Benutzerfreundlichkeit und vom Programmieraufwand ergibt sich auch kein größererer Aufwand, die Fehlerbehandlung wird sogar einfacher, weil die bisherige Eingabe im Browser verbleibt.

MfG

[Julius]

Hallo pl,

Auf diese POST-Anfrage noch Javascript bzw. Ajax obendrauf zu klemmen verkompliziert die Angelegenheit nur, ohne auch nur ansatzweise irgendeinen Nutzen zu bieten.

So ein Quatsch! JS steigert die Benutzerfreundlichkeit und vom Programmieraufwand ergibt sich auch kein größererer Aufwand

... außer man muss erst JavaScript lernen, um ein Formular abzusenden, was bereits mit HTML-Bordmitteln geht. Merkste was?

Gruß
Julius

[Gunnar Bittersmann]

@@pl

Auf diese POST-Anfrage noch Javascript bzw. Ajax obendrauf zu klemmen verkompliziert die Angelegenheit nur, ohne auch nur ansatzweise irgendeinen Nutzen zu bieten.

So ein Quatsch! JS steigert die Benutzerfreundlichkeit und vom Programmieraufwand ergibt sich auch kein größererer Aufwand, die Fehlerbehandlung wird sogar einfacher, weil die bisherige Eingabe im Browser verbleibt.

Das tut sie bei einem Affenformular auch.

Aber natürlich sollte die Fehlerbehandlung als progressive enhancement schon clientseitig erfolgen. Wenn die HTML5-Bordmittel dafür nicht gut genug sind, mit JavaScript.

LLAP 🖖

[pl]

So ein Quatsch! JS steigert die Benutzerfreundlichkeit und vom Programmieraufwand ergibt sich auch kein größererer Aufwand, die Fehlerbehandlung wird sogar einfacher, weil die bisherige Eingabe im Browser verbleibt.

Das tut sie bei einem Affenformular auch.

Nein. Da musst Du sie nämlich erst zum Server schicken und die Seite bzw. das Formular mit den bisherigen Eingaben ausgefüllt erneut in den Browser laden. Und auch die Fehlermeldung muss in die Seite eingebaut sein.

MfG

[Gunnar Bittersmann]

@@pl

Das tut sie bei einem Affenformular auch.

Nein. Da musst Du sie nämlich erst zum Server schicken und die Seite bzw. das Formular mit den bisherigen Eingaben ausgefüllt erneut in den Browser laden.

Ja eben. Das ist das Wesen eines Affenformulars.

LLAP 🖖

[dedlfix]

Tach!

Nein. Da musst Du sie nämlich erst zum Server schicken und die Seite bzw. das Formular mit den bisherigen Eingaben ausgefüllt erneut in den Browser laden.

Ja eben. Das ist das Wesen eines Affenformulars.

Und um ein solches kommt man mit dem besten Javascript nicht herum, denn Javascript ist optional und deaktivierbar.

dedlfix.

[Regina Schlauklug]

Formulardaten können, seit HTML Formulare unterstützt, per HTTP-POST quasi selbständig an den Server gesendet werden und jeder Server unterstützt derlei Datenübermittlung. Auf diese POST-Anfrage noch Javascript bzw. Ajax obendrauf zu klemmen verkompliziert die Angelegenheit nur, ohne auch nur ansatzweise irgendeinen Nutzen zu bieten.

So ein Quatsch! JS steigert die Benutzerfreundlichkeit

Das …

Javascript dient bestenfalls dazu, den Nutzer direkt bei der Eingabe (und nicht erst nach Absenden) auf Fehler hinzuweisen

… schrieb ich bereits. Weniger hilfreich ist es, mit dem Fehlerhinweis zu warten, bis das Formular abgesendet wird; sowas sollte erscheinen, sobald der Fehler sichtbar ist, wo nötig auch mit kurzer Rückfrage an den Server. Es hat niemand etwas gegen den Einsatz von Javascript als Hilfe gesagt.

Darum geht es aber gar nicht, es geht um das bloße Übermitteln der Daten. Quatsch ist es, schon für diesen Vorgang Javascript vorauszusetzen, da gibt es für den Nutzer keinerlei Vorteile gegenüber der Standard-POST-Methode. Falls du Vorteile siehst: Bitte, erkläre.

[Gunnar Bittersmann]

@@Regina Schlauklug

Darum geht es aber gar nicht, es geht um das bloße Übermitteln der Daten. Quatsch ist es, schon für diesen Vorgang Javascript vorauszusetzen

Voraussetzen nicht, aber auch hier kann man mit JavaScript als progressive enhancement Gutes tun.

da gibt es für den Nutzer keinerlei Vorteile gegenüber der Standard-POST-Methode. Falls du Vorteile siehst: Bitte, erkläre.

Offline first: Die Nutzerin kann die Nachricht schreiben und auf „abschicken“ clicken, auch wenn keine Netzverbindung besteht. Sobald die Verbindung wieder da ist, schickt der service worker die Nachricht dann ohne weiteres Zutun des Nutzers raus.

Die Nutzerin sollte freilich darüber informiert werden, dass die Nachricht erstmal lediglich im „Postausgang“ gelandet ist. Ein allzu optimistic UI ist hier nicht angebracht.

LLAP 🖖

[pl]

Na, weil Du's bist: Wie ich bereits schrieb, die Fehlerbehandlung wird einfacher, weil die bisherigen Eingaben im Browser verbleiben und nicht erst zum Server hin und zurück gesendet werden müssen.

Ein erheblicher weiterer Vorteil ist die Benutzerfreundlichkeit. So kann ein Formular auch ganz unten am Ende einer Seite stehen und kann das auch bei etwaigen Fehlermeldungen bleiben. Andernfalls müsste der Anwender wieder nach ganz unten scrollen. Bei umfangeichen Formularen very schlecht.

Allgemein: Vieles lässt sich im Browser erledigen ohne es im Einzelnen über HTTP schleifen zu müssen. Stell Dir eine umfangeiche Konfiguration vor oder Tabellen wo der Benutzer zwischendurch immer mal wieder speichern möchte -- Ich kenn keine Textverabeitung die beim Speichern das ganze Dokument neu laden muss, warum sollte das ein Online-Editor-Backend machen!?

Deine Erfahrungen hierzu musst Du aber selber machen, das kann ich Dir nicht abnehmen und das wird hier im Forum auch nicht vermittelt.

Also einfach machen. Es ist alles nur eine Frage der Übung.

[dedlfix]

Tach!

Wie ich bereits schrieb, die Fehlerbehandlung wird einfacher, weil die bisherigen Eingaben im Browser verbleiben und nicht erst zum Server hin und zurück gesendet werden müssen.

Sie wird nicht einfacher, weil sie auf dem Server nicht verzichtbar ist. Das heißt, dass man sie nun doppelt braucht.

Allgemein: Vieles lässt sich im Browser erledigen ohne es im Einzelnen über HTTP schleifen zu müssen. Stell Dir eine umfangeiche Konfiguration vor oder Tabellen wo der Benutzer zwischendurch immer mal wieder speichern möchte -- Ich keine keine Textverabeitung die beim Speichern das ganze Dokument neu laden muss, warum sollte das ein Online-Editor-Backend machen!?

Eine Kontaktformular ist keine dokumentenbasierte Textverarbeitung.

dedlfix.

[pl]

Eine Kontaktformular ist keine dokumentenbasierte Textverarbeitung.

Was Du nicht sagst.

[Regina Schlauklug]

Eine Kontaktformular ist keine dokumentenbasierte Textverarbeitung.

Was Du nicht sagst.

Schön, warum kommst du dann damit? Dass du beim Versuch, eine Begründung für den von dir geforderten Javascript-Zwang selbst bei einfachen Formularen zu finden, allen Ernstes bei einer Online-Textverarbeitung landest, zeigt, dass du dich bei deiner Argumentation mal wieder heillos verzettelt hast.

[pl]

Ich hab versucht Dir zu erklären, dass sich Vereinfachungen ergeben, keine Ursache. Aber wenn Du das nicht verstehen willst, gib bitte nicht mir die Schuld, das wird ja immer schöner hier.

[pl]

Sie wird nicht einfacher, weil sie auf dem Server nicht verzichtbar ist. Das heißt, dass man sie nun doppelt braucht.

Unsinn. Wenn ich sage dasss es einfacher wird, dann wird es das auch. Grundsätzlich erfolgt die Prüfung de Eingaben immer am Server, egal auf welchem Weg sie dahin kommen. Aber wenn sie mit Ajax gesendet werden, dann reicht es, eine Exception zu werfen und das ist in der Tat einfacher als eine komplette Seite zusammenzubauen.

[dedlfix]

Tach!

Grundsätzlich erfolgt die Prüfung de Eingaben immer am Server, egal auf welchem Weg sie dahin kommen. Aber wenn sie mit Ajax gesendet werden, dann reicht es, eine Exception zu werfen und das ist in der Tat einfacher als eine komplette Seite zusammenzubauen.

Die Seite ist bereits nahezu komplett, weil sie ja auch initial ausgeliefert werden muss. Das Einbauen der für das Affenformular nötigen Dinge kann man sich nur dann sparen, wenn man das Formular nur mit eingeschaltetem Javascript lauffähig haben möchte. Das möchte man aber in der Regel nicht.

Ohne Javascript hat man nur drei Techniken, HTML, CSS und PHP. Mit Javascript kommt eine vierte Technik hinzu, die neben der Sprache an sich noch aus den beiden Teilen DOM-Manipulation und dem Handling der Ajax-Übertragung besteht. Natürlich erhöht das die Komplexität des Gesamtsystems gegenüber einer Javascript-freien Lösung. Gerade wenn man noch Anfänger ist und nun nicht nur PHP, sondern PHP, Javascript, DOM-Manipulation und Ajax lernen muss.

Und wir haben es hier immer noch nur mit einem Kontaktformular zu tun, selbst wenn da ein paar Daten mehr abgefragt werden. Das wird recht selten verwendet und es spielt da im Gegensatz zu sehr häufig auszfüllenden und/oder komplexen Formularen keine gesteigerte Rolle, ob die Eingabe-Prüfung ein wenig länger dauert. Man kann und sollte bereits beim leeren Formular Hinweise auf Pflichtfelder und Bedingungen bei den Werten geben, so dass die meisten Anwender gar nicht erst im Fehlerfall der Prüfung landen. Der Vorteil von Javascript wiegt meiner Meinung nach den Aufwand beim derzeitigen Kenntnisstand des Probleminhabers nicht auf.

dedlfix.

[Julius]

Hallo Die IP da halt,

ich habe da noch ein paar Ergänzungen:

1. Diese Linkhaftungsklausel in deinem Impressum ist rechtlich gesehen keinen Pfifferling wert. Kann und sollte daher anders formuliert werden.
2. Greife zum Erstellen von HTML-Seiten auf das HTML-Grundgerüst zurück; da ist alles Wichtige drin.

Gruß
Julius

[pl]

Wg. Zeichnkodierung: Dein Server sendet nur den Content-Type: text/html ohne Angabe der Zeichenkodierung. Das Problem kann Dein Provider lösen, der kann das auch am Server konfigurieren.

MfG

PS: Zumindest können das die Provider die ich kenne.

[dedlfix]

Tach!

Wg. Zeichnkodierung: Dein Server sendet nur den Content-Type: text/html ohne Angabe der Zeichenkodierung. Das Problem kann Dein Provider lösen, der kann das auch am Server konfigurieren.

Als Provider würde ich das auch können, jedoch nicht wollen. Denn dann können die unwissenden Kunden nicht mehr einfach mit der Im-Dokument-Angabe eine andere Kodierung wählen. Die Server-Angabe hat ja Vorrang. Stattdessen kann man den Kunden es selbst in die Hand geben, wo sie es gern haben wollen. Für die Server-Angabe braucht man nur eine .htaccess mit passendem Eintrag anzulegen.

dedlfix.

[pl]

Als Provider würde ich das auch können, jedoch nicht wollen. Denn dann können die unwissenden Kunden nicht mehr einfach mit der Im-Dokument-Angabe eine andere Kodierung wählen.

Das ist ja nun kompletter Quatsch: Warum sollte die Angabe der Zeichenkodierung im Dokument von der im Content-Type-Header gesendeten abweichen?

Und selbstverständlich kann ein als Default gesetzter Content-Type jederzeit überschrieben werden, wenn das in dem Webserver nachgelagerten Prozess so gewünscht wird.

[dedlfix]

Tach!

Als Provider würde ich das auch können, jedoch nicht wollen. Denn dann können die unwissenden Kunden nicht mehr einfach mit der Im-Dokument-Angabe eine andere Kodierung wählen.

Das ist ja nun kompletter Quatsch: Warum sollte die Angabe der Zeichenkodierung im Dokument von der im Content-Type-Header gesendeten abweichen?

Weil der Kunde nicht unbedingt weiß, dass er auf eine vom Provider festgenagelte Kodierung angewiesen ist und stattdessen eine andere verwendet. Natürlich ist es technisch unsinnig, unterschiedliche Kodierungen anzugeben, genauso wie es nicht zielführend ist, Fehler zu machen. Das hält niemanden davon ab, sie trotzdem zu machen.

Und selbstverständlich kann ein als Default gesetzter Content-Type jederzeit überschrieben werden, wenn das in dem Webserver nachgelagerten Prozess so gewünscht wird.

Wenn du sowieso eine .htaccess anlegen darfst, dann kannst du als Provider auch gleich den Default-Wert weglassen.

Szenario 1: Der Provider setzt keinen Default-Wert. Der Kunde kann sich aussuchen, ob er eine Angabe im Document oder via .htaccess im HTTP-Header haben möchte, oder beides.

Szenario 2: Der Provider setzt einen Default-Wert und der Kunde weiß es nicht, weil niemand Dokumentationen liest. Deshalb schreibt er seine Dokumente in einer anderen Kodierung inklusive Angabe im Dokument. Natürlich weiß er auch nicht, dass die Serverangabe stärker ist und er überschreibt sie auch nicht, er kommt noch nicht mal auf die Idee, die HTTP-Header anzuschauen. Solche Probleme lassen sich vermeiden, wenn man keine Default-Angabe setzt.

Als Dienstleister ist man bestrebt, die Kosten niedrig zu halten und unnötigen Aufwand zu vermeiden. Ich würde es nicht wollen, für die Kunden die Kodierung zu setzen, auf dass sie morgen wieder ankommen und eine andere haben wollen. Es bringt keinen Vorteil, die Kodierung serverseitig zu setzen. Man möchte sie auf jeden Fall im Dokument haben, damit es auch im abgespeicherten Zustand ohne HTTP-Header richtig angezeigt werden kann. Das Weglassen im HTTP-Header vermeidet jedoch Fehler.

TL;DR: Angabe im Dokument angeben und im HTTP-Header weglassen. Ersteres braucht man auch abseits einer HTTP-Übertragung, letzteres bringt keinen Vorteil, ist aber anfällig für Fehler.

dedlfix.

[pl]

Weil der Kunde nicht unbedingt weiß, dass er auf eine vom Provider festgenagelte Kodierung angewiesen ist

Der Begriff "Default" sorgt immer wieder für Missverständnisse. Default heißt nicht etwa Standard wie das hier oft angenommen wird, vielmehr ist ein Default das was den fehlenden Wert ersetzt. Genau aus diesem Grund ist jeder Default ersetzbar.

Im Übrigen sendet die problematische Seite immer noch keine Angabe zur Kodierung im Content-Type-Header. So oder so ist hier mal ein Gespräch mit dem Provider fällig. MfG

[dedlfix]

Tach!

Weil der Kunde nicht unbedingt weiß, dass er auf eine vom Provider festgenagelte Kodierung angewiesen ist

Der Begriff "Default" sorgt immer wieder für Missverständnisse. Default heißt nicht etwa Standard wie das hier oft angenommen wird, vielmehr ist ein Default das was den fehlenden Wert ersetzt. Genau aus diesem Grund ist jeder Default ersetzbar.

Es ist insofern ein Default-Wert, als dass er mit einem weiteren den HTTP-Header beeinflussenden Konfiguration oder Anweisung ersetzt werden kann. Es ist außerdem auch ein Wert mit höherer Priorität gegenüber der Angabe mittels Meta-Element im Dokument. Insofern ist es eine problematische Vorgehensweise einen Default-Wert zu setzen, der sich nicht auf diese einfache Weise überschreiben lässt, sondern eine überschreibende Serverkonfiguration oder das Neusetzen des Content-Type-Headers bedingt.

Im Übrigen sendet die problematische Seite immer noch keine Angabe zur Kodierung im Content-Type-Header. So oder so ist hier mal ein Gespräch mit dem Provider fällig.

Neien! Das ist nicht hilfreich, sondern verkompliziert die Angelegenheit nur unnötig. Es ist nicht nur ein einfacher Default-Wert, es ist einer mit höherer Priorität gegenüber der Angabe im Meta-Element.

Du könntest ja mal darlegen, welchen Vorteil es aus deiner Sicht bringen soll, dass der Provider eine Vorgabe macht, die der Kunde nur über .htaccess oder PHPs header()-Funktion ändern, nicht aber mittels Meta-Element im Dokument überschreiben kann.

dedlfix.

[Gunnar Bittersmann]

@@pl

Der Begriff "Default" sorgt immer wieder für Missverständnisse. Default heißt nicht etwa Standard wie das hier oft angenommen wird

Noch öfter wird hier „Standart“ angenommen. ;-)

„Standard“ ist eine mögliche Übersetzung von default. Andere Bedeutungen sind: Versäumnis, Nichteinhaltung, …

vielmehr ist ein Default das was den fehlenden Wert ersetzt.

Da zäumst du das Pferd von hinten auf. Der Default ist zuerst da und kann durch einen anderen Wert ersetzt werden. Was du vermutlich mit

Genau aus diesem Grund ist jeder Default ersetzbar.

meintest.

„Standard“ ist tatsächlich nicht die beste Übersetzung. Besser spricht man von Voreinstellung, Vorgabewert.

LLAP 🖖

[pl]

Noch öfter wird hier „Standart“ angenommen. 😉

Aha, da hahm wirs doch! Wobei ich jetzt hier anmerken muss, dass wir genau dieses Thema bereits vor ca. 10 Jahren hier im Forum ausführlich geklärt hatten. Offensichtlich ist da nicht viel hängengeblieben.

Deswegen noch einmal: Die Angabe der Zeichenkodierung im Content-Type-Header ist lt. HTTP zwar nicht zwingend vorgegeben aber notwendig, damit der Browser die Zeichen richtig darstellt. Von daher ist es zweckmäßig, einen Default zu setzen. D.h., der Default ersetzt eine fehlende Angabe.

Und in dem Moment, wenn diese Angabe anderweitig, z.B. von der Anwendung vorgegeben wird, egal ob vom Default abweichend oder nicht, wird der Default überschrieben, weil die fehlende Angabe in diesem Fall ja vorliegt. MfG

[Gunnar Bittersmann]

@@pl

Deswegen noch einmal:

Penetrante Wiederholung macht deine Aussagen nicht richtiger.

Die Angabe der Zeichenkodierung im Content-Type-Header ist lt. HTTP zwar nicht zwingend vorgegeben aber notwendig, damit der Browser die Zeichen richtig darstellt.

Das ist völliger Unsinn. Der Browser stellt die Zeichen auch ohne Angabe der Zeichencodierung im Content-Type-Header richtig dar, wenn die entsprechende Zeichencodierung auf anderem Weg angegeben ist.

Ein Beispiel, wo die Angabe der Zeichencodierung im Content-Type-Header eher schädlich als nützlich ist, hatte ich genannt.

Von daher ist es zweckmäßig, einen Default zu setzen. D.h., der Default ersetzt eine fehlende Angabe.

Dass das sprachlich das Pferd von hinten aufzäumt, hatte ich bereits erwähnt.

LLAP 🖖

[Christian Kruse]

Hallo pl,

Deswegen noch einmal: Die Angabe der Zeichenkodierung im Content-Type-Header ist lt. HTTP zwar nicht zwingend vorgegeben aber notwendig, damit der Browser die Zeichen richtig darstellt.

Das ist falsch. Notwendig ist eine Angabe der Kodierung, nicht aber zwangsläufig die im HTTP-Header. Und vorgeschrieben ist gar keine. Der Standard sagt zu dem Thema:

1. User override.
2. An HTTP "charset" parameter in a "Content-Type" field.
3. A Byte Order Mark before any other data in the HTML document itself.
4. A META declaration with a "charset" attribute.
5. A META declaration with an "http-equiv" attribute set to "Content-Type" and a value set for "charset".
6. Unspecified heuristic analysis.

und weiter:

Normalize the given character encoding string according to the Charset Alias Matching rules defined in Unicode Technical Standard #22. Override some problematic encodings, i.e. intentionally treat some encodings as if they were different encodings. The most common override is treating US-ASCII and ISO-8859-1 as Windows-1252, but there are several other encoding overrides listed in this table. As the specification notes, "The requirement to treat certain encodings as other encodings according to the table above is a willful violation of the W3C Character Model specification."

und weiter:

You should always specify a character encoding on every HTML document, or bad things will happen. You can do it the hard way (HTTP Content-Type header), the easy way (<meta http-equiv> declaration), or the new way (<meta charset> attribute), but please do it. The web thanks you.

Von „es muss und sollte in jedem Fall im Header angegeben werden” steht da nichts. Im Gegenteil, es ist sogar „nur” eine dringende Empfehlung (should), keine Vorschrift (must), überhaupt eine Kodierung anzugeben.

Von daher ist es zweckmäßig, einen Default zu setzen.

Für einen Hoster etwa ist es sinnvoll, die Angabe wegzulassen. Er kann nicht wissen, welche Kodierung der Kunde benutzen wird, und da eine Angabe im HTTP-Header die Angabe aus dem Dokument überschreibt würde man den Kunden daran hindern, die gewünschte Kodierung zu nutzen. Es macht viel mehr Sinn, in diesem Szenario darauf zu setzen, dass der Kunde die Kodierung im Dokument angibt. Und mehr ist nicht nötig, um sicherzustellen, dass das Dokument richtig dargestellt wird!

Für ein großes Legacy-Projekt etwa ist es sinnvoll, die Angabe wegzulassen. Die Dokumente liegen hier in verschiedenen Kodierungen vor. Eine Angabe im HTTP-Header würde dazu führen, dass Legacy-Dokumente in der alten Kodierung nicht richtig angezeigt werden könnten, denn die überschreibt die Angabe im Dokument.

Du siehst, worauf das hinaus läuft?

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Das ist falsch. Notwendig ist eine Angabe der Kodierung, nicht aber zwangsläufig die im HTTP-Header. Und vorgeschrieben ist gar keine. Der Standard sagt zu dem Thema:

1. User override.
2. An HTTP "charset" parameter in a "Content-Type" field.
3. A Byte Order Mark before any other data in the HTML document itself.
4. A META declaration with a "charset" attribute.
5. A META declaration with an "http-equiv" attribute set to "Content-Type" and a value set for "charset".
6. Unspecified heuristic analysis.

Welcher Standard sollte das sein?

In dem von dir verlinkten Artikel genießt das BOM höchste Priorität. Das sollte also an 2. Stelle nach 1. User override vor 3. HTTP-Content-Type stehen.

Oder hat sich da wieder was geändert?

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Welcher Standard sollte das sein?

Ja, das war nicht ganz korrekt. Ich hatte da einen alten Blog-Post zitiert.

LG,
CK

[Gunnar Bittersmann]

@@pl

Das ist ja nun kompletter Quatsch

Bringen wir das mal in den historischen Kontext: Wann immer es hier um Zeichencodierung ging, hat dedlfix fachlich gehaltvolle Beiträge beigesteuert. Deine Beiträge hingegen habe ich als bestenfalls neutral, aber eher der anderen Seite des Spektrums zugehörig in Erinnerung.

Nun könnte es sein, dass dedlfix inzwischen senil geworden ist oder dass du was dazugelernt hättest. Aber ich denke, weder das Eine noch das Andere ist hier der Fall.

Warum sollte die Angabe der Zeichenkodierung im Dokument von der im Content-Type-Header gesendeten abweichen?

Sollte sie (bestenfalls) nicht. Das stiftet nur Verwirrung, welche Angabe denn nun a) die richtige und b) die gültige ist.

Wenn es nur eine Angabe (entweder im Dokument oder im HTTP-Header) gibt, kann da nichts voneinander abweichen.

Stell dir mal eine umfangreiche Website vor, voller Altlasten in ISO 8859-1 codiert. Das möchte man ändern und UTF-8 verwenden – bei neuen Seiten oder denen, die man gerade überarbeitet. (Für die anderen gibt es keinen Grund, die Zeichencodierung zu ändern, der den Aufwand rechtfertigen würde.)

Wenn der Server keine Zeichencodierung im HTTP-Header angibt, kein Problem: im Dokument UTF-8 angeben, mit UTF-8 speichern – fertig.

Wenn der Server aber ISO 8859-1 im HTTP-Header angibt, dann hat man ein Problem.

Und selbstverständlich kann ein als Default gesetzter Content-Type jederzeit überschrieben werden

Das wäre zwar möglich, aber wartungsintensiv: Man müsste jedes neue/geänderte Dokument seinen Content-Type mit PHP selbst setzen lassen oder in .htaccess eine Liste der bereits UTF-8-codierten Ressourcen pflegen.

Die andere Möglichkeit, UTF-8 mit BOM zu verwenden, was höhere Priorität hat als die Angabe im HTTP-Header, scheitert daran, dass sie das in IrgendEinem Browser nicht hat; und an der Problematik der Unsichtbarkeit.

TL;DR: Es gibt Fälle, in denen es sinnvoll und hilfreich ist, dass der Server keine Zeichencodierung angibt.

LLAP 🖖

[pl]

Bringen wir das mal in den historischen Kontext: Wann immer es hier um Zeichencodierung ging, hat dedlfix fachlich gehaltvolle Beiträge beigesteuert. Deine Beiträge hingegen habe ich als bestenfalls neutral, aber eher der anderen Seite des Spektrums zugehörig in Erinnerung.

Es ist hier in diesem Forum mittlerweile so, dass jedesmal wenn ich hier was poste ein übler Mob losgeht. Da fragt jemand nach, ich erkläre das ausführlich und fachlich korrekt und anschließend werde ich hier hingestellt wie ein Idiot -- gehts noch!? Ne mein Lieber Gunnar, das ist persönlich und grenzt schon an Beleidigung und auch Du machst da keine Ausnahme.

Darüber solltest Du mal nachdenken. Außerdem könnt Ihr auch gerne selber zeigen, wie bestimmte Dinge praktisch gelöst werden können, auf Euren Wiki-Seiten habt Ihr da die beste Gelegenheit. Aber ich denke eher, Euch fehlt ganz einfach die Erfahrung, das zeigen ja Eure Antworten.

Und Gunnar, Dein Beitrag zum Thema Affenformular erweckt eher den Eindruck, als hättest Du gar nicht verstanden was Progressive Enhancement in Sachen Fehlerbehandlung bedeutet. Hauptsache englisch, mit Fachbegriffen um sich werfen und den Anspruch erheben, eine fachlich hilfreiches Forum+Wiki zu haben -- Davon seid Ihr meilenweit entfernt!

MfG

[Gunnar Bittersmann]

@@pl

Das lass ich jetzt mal zur Belustigung aller so stehen.

Es ist hier in diesem Forum mittlerweile so, dass jedesmal wenn ich hier was poste ein übler Mob losgeht. Da fragt jemand nach, ich erkläre das ausführlich und fachlich korrekt und anschließend werde ich hier hingestellt wie ein Idiot -- gehts noch!? Ne mein Lieber Gunnar, das ist persönlich und grenzt schon an Beleidigung und auch Du machst da keine Ausnahme.

Darüber solltest Du mal nachdenken. Außerdem könnt Ihr auch gerne selber zeigen, wie bestimmte Dinge praktisch gelöst werden können, auf Euren Wiki-Seiten habt Ihr da die beste Gelegenheit. Aber ich denke eher, Euch fehlt ganz einfach die Erfahrung, das zeigen ja Eure Antworten.

Und Gunnar, Dein Beitrag zum Thema Affenformular erweckt eher den Eindruck, als hättest Du gar nicht verstanden was Progressive Enhancement in Sachen Fehlerbehandlung bedeutet. Hauptsache englisch, mit Fachbegriffen um sich werfen und den Anspruch erheben, eine fachlich hilfreiches Forum+Wiki zu haben -- Davon seid Ihr meilenweit entfernt!

MfG

LLAP 🖖

[dedlfix]

Tach!

Das lass ich jetzt mal zur Belustigung aller so stehen.

Ich finde das ganz und gar nicht lustig.

Es ist hier in diesem Forum mittlerweile so, dass jedesmal wenn ich hier was poste ein übler Mob losgeht. Da fragt jemand nach, ich erkläre das ausführlich und fachlich korrekt und anschließend werde ich hier hingestellt wie ein Idiot -- gehts noch!?

Ich empfinde diese Erklärungen überwiegend nicht verständlich. Meist sind sie recht knapp gehalten und lassen damit viel Interpretationsspielraum. Und sie setzen oft auch Wissen voraus, dass sich anscheinend nur in pls Kopf befindet. Die fehlenden Zusammenhänge beim Erklären machen das Verstehen nicht einfacher. Da ich nicht finde, dass solche Bruchstücke geeignet sind, die Fragen der Probleminhaber zu klären, setze ich dann meine Erklärungsversuche dazu. Hinzu kommt noch, dass konkrete Rückfragen nicht selten unbeantwortet bleiben und gern auch irgendwelcher Perl-Code herhalten muss bei Themen, in denen nicht nach Perl gefragt wurde. Perl ist im Webumfeld bedeutungslos geworden, kaum einer versteht die Sprache. Solche Lösungs-/Erklärungsversuche tragen dann auch nicht zum Verständnis bei.

dedlfix.

[Christian Kruse]

Mein lieber pl,

wieder ein Fall von austeilen aber nicht einstecken wollen. Viele deiner Thesen wurden diverse male fundiert widerlegt. Doch jedesmal, wenn man dir tatsächlich auf fachlicher Ebene begegnet, bist du die nächsten 14 Tage weg. Dein Muster ist offensichtlich. Mit dir ist eine fachliche Diskussion schlicht und ergreifend nicht möglich. In diesem Sinne erspare ich es mir auch, auf die einzelnen Punkte näher einzugehen.

LG,
CK

[Christian Kruse]

Lieber Gunnar,

Das ist ja nun kompletter Quatsch

Bringen wir das mal in den historischen Kontext: Wann immer es hier um Zeichencodierung ging, hat dedlfix fachlich gehaltvolle Beiträge beigesteuert. Deine Beiträge hingegen habe ich als bestenfalls neutral, aber eher der anderen Seite des Spektrums zugehörig in Erinnerung.

Nun könnte es sein, dass dedlfix inzwischen senil geworden ist oder dass du was dazugelernt hättest. Aber ich denke, weder das Eine noch das Andere ist hier der Fall.

Ich zitiere mal:

Formulieren Sie bitte höflich und wertschätzend.

Diese Spitzen hätten nicht sein müssen.

LG,
CK

[Matthias Apsel]

Hallo Christian Kruse,

Ich zitiere mal:

Formulieren Sie bitte höflich und wertschätzend.

Diese Spitzen hätten nicht sein müssen.

Ich sehe da nur eine.

Wann immer es hier um Zeichencodierung ging, hat dedlfix fachlich gehaltvolle Beiträge beigesteuert. Deine Beiträge hingegen habe ich als bestenfalls neutral, aber eher der anderen Seite des Spektrums zugehörig in Erinnerung.

halte ich für eine chartagemäße Formulierung. Es hilft ja nicht, mit der Wahrheit hinter dem Berg zu halten.

Bis demnächst
Matthias

[Christian Kruse]

Hallo Matthias,

Ich sehe da nur eine.

von mir aus auch „die Spitze” 😜

LG,
CK

[Christian Kruse]

Lieber pl,

Als Provider würde ich das auch können, jedoch nicht wollen. Denn dann können die unwissenden Kunden nicht mehr einfach mit der Im-Dokument-Angabe eine andere Kodierung wählen.

Das ist ja nun kompletter Quatsch:

Ich zitiere mal:

Formulieren Sie bitte höflich und wertschätzend.

LG,
CK

[Tabellenkalk]

Hallo,

Ich zitiere mal:

Formulieren Sie bitte höflich und wertschätzend.

Ich beantrage eine automatische Charta-Zitierfunktion, die von selbst aufpoppt, sobald man gegen die Charta verstößt 😱

Gruß
Kalk

[Matthias Apsel]

Hallo Tabellenkalk,

Ich beantrage eine automatische Charta-Zitierfunktion, die von selbst aufpoppt, sobald man gegen die Charta verstößt 😱

Wir erwarten deinen PullRequest. 😂

Bis demnächst
Matthias