nicht angemeldet molily
molily
Gunnar Bittersmann
molily
Gunnar Bittersmann
molily
Tim Tepaße
molily
Guten Tag,
Ich habe zwar schon ein paar Websiten gemacht aber würde mich trotzdem als "Anfänger" betrachten.
Habe mir nun ein Kontaktformular heruntergeladen und es in meine Seite eingebunden.
Seitdem bekomme Ich es einfach nicht mehr hin den W3C Test zu bestehen.
http://validator.w3.org/
Ist es nicht erlaubt PHP in XHTML einzubinden?
Außerdem ist mir aufgefallen, dass der IE7 das Kontaktformular zentriert anordnet, der Firefox 3.0.6 es jedoch linksbündig anordnet.
Was muss Ich ändern?
Die URL zu der besagten Seite lautet:
http://u0000625051.user.hosting-agency.de/Basmer/Kontakt.php
Ich wäre Euch sehr dankbar wenn Ihr mir helfen könntet.
Mfg, Sullivan
Moin
ein "&" muss auch in URLs maskiert werden "&"
Dann ist der Code auch valide
Gruß Bobby
Moin
um es zu verdeutlichen:
<a href="javascript:P91Captcha('&PHPSESSID=f882cb37b50c4c631b962e44b1ab1881');">Neuer Code?</a>
ist nicht valid
<a href="javascript:P91Captcha('&PHPSESSID=f882cb37b50c3c631b962e78b1ab1881');">Neuer Code?</a>
ist valid!
Gruß Bobby
Moin
um es zu verdeutlichen:
<a href="javascript:P91Captcha('&PHPSESSID=f882cb37b50c4c631b962e44b1ab1881');">Neuer Code?</a>ist nicht valid
<a href="javascript:P91Captcha('&PHPSESSID=f882cb37b50c3c631b962e78b1ab1881');">Neuer Code?</a>ist valid!
Beides ist aber trotzdem unsinn - ein Link ist ein Link - ein Link, der auf nichts linkt ist kein Link.
Moin
Beides ist aber trotzdem unsinn - ein Link ist ein Link - ein Link, der auf nichts linkt ist kein Link.
Mag sein. Das war aber nicht seine Frage. Die Frage lautete wie er seine Seite valide bekommt. Und das angegebene Codeschnipsel (der Link) ist von seiner Seite. Genau dieser Link erzeugt einen Fehler beim Validator. Und genau das ist beantwortet.
Nicht mehr und nicht weniger.
Gruß Bobby
Beides ist aber trotzdem unsinn - ein Link ist ein Link - ein Link, der auf nichts linkt ist kein Link.
Irgendein anderes Element wäre nicht besser, sondern schlechter zu bedienen.
</archiv/2008/4/t169545/#m1107626>
</archiv/2008/3/t168236/#m1097856>
Mathias
Irgendein anderes Element wäre nicht besser, sondern schlechter zu bedienen.
Das ist mir durchaus klar - aber was spricht im Falle des OP dagegen in das href-Attribut einen Verweis zu packen und dieses Ziel dann per onclick auszulesen und an diee Funktion zu übergeben - somit wären benutzer ohne JavaScript nicht ausgeschlossen. Das übergeben der Session-ID im Querystring scheint ja eine Krücke zu sein, um "Cookie-Verweigerer" auch glücklich zu machen - aber anstelle dessen foppt man sie nochmal mit JavaScript.
was spricht im Falle des OP dagegen in das href-Attribut einen Verweis zu packen (...) somit wären benutzer ohne JavaScript nicht ausgeschlossen
Und was für einen Verweis? Das Link ruft ein Script auf, dass ein neues CAPTCHA vom Server holt und das Bild auswechselt. Wie willst du das ohne JavaScript machen? Mit einem iframe?
Mathias
Und was für einen Verweis? Das Link ruft ein Script auf, dass ein neues CAPTCHA vom Server holt und das Bild auswechselt. Wie willst du das ohne JavaScript machen? Mit einem iframe?
Durch Neuladen der Seite z.B. - wie wärs mit einem Affenformular? Ein weiterer Absendebutton für das Formular "Ich kann das Captcha nicht lesen" und gut ist.
Wenn es denn wirklich der Eigenschaften wegen ein a-Element sein muss, dann doch bitte per JavaScript erzeugen.
@@molily:
Und was für einen Verweis? Das Link ruft ein Script auf, dass ein neues CAPTCHA vom Server holt und das Bild auswechselt. Wie willst du das ohne JavaScript machen?
Ohne CAPTCHA.
Äußerst zweifelhaftem Nutzen von CAPTCHAs steht gegenüber, dass CAPTCHAs Nutzer sinnlos nerven.
http://de.wikipedia.org/wiki/Captcha#Kritik
http://de.wikipedia.org/wiki/Captcha#Umgehung_von_CAPTCHAs
Live long and prosper,
Gunnar
Ohne CAPTCHA.
Da wir hier bei SELF sind, wo man sein Wissen anderen mitteilt: Schreibe doch bitte mal ein spamsicheres Kontaktformular- und Kommentar-Script und veröffentliche es auf SELFHTML aktuell. (Das, was derzeit auf SELFHTML aktuell vorgestellt wird, kann man nicht online stellen.) Dann haben wir alle etwas davon und die unspezifische Rechthaberei hinsichtlich dieses Themas hat ein Ende.
Mathias
Hoi.
Alternativ möchte ich vorschlagen, die Lösung kommerziell zu patentiern und zu vermarkten. Dank der Tatsache, dass man sich dann über Geld keine Gedanken mehr machen braucht, kann man sich Vollzeit um SELFHTML kümmern.
Grüße
@@molily:
»» Ohne CAPTCHA.
Da wir hier bei SELF sind, wo man sein Wissen anderen mitteilt: Schreibe doch bitte mal ein spamsicheres Kontaktformular- und Kommentar-Script und veröffentliche es auf SELFHTML aktuell.
Warum? Ist dir Ingos Artikel nicht gut genug?
Live long and prosper,
Gunnar
Hoida.
Warum? Ist dir Ingos Artikel nicht gut genug?
http://forum.de.selfhtml.org/?t=183402&m=1215510
Grüße
Hallo Dirk!
http://forum.de.selfhtml.org/?t=183402&m=1215510
Ist es denn so schwer, vor jedem mittels Copy&Paste eingefügten oder handgetippten Link ein < und dahinter ein > einzugeben? Das sind insgesamt 7 Zeichen für Dich, erspart uns aber das Copy&Paste und Klicken aufs Zurückbutton um wieder zu Deinem Beitrag zu kommen.
Sorry, aber Du beteiligst Dich nicht erst seit heute mittag hier.
Viele Grüße aus Frankfurt/Main,
Patrick
Moinmoin.
Ist es denn so schwer, vor jedem mittels Copy&Paste eingefügten oder handgetippten Link ein < und dahinter ein > einzugeben? Das sind insgesamt 7 Zeichen für Dich, erspart uns aber das Copy&Paste und Klicken aufs Zurückbutton um wieder zu Deinem Beitrag zu kommen.
Mea culpa, ja! Richtiger Einwand, ich versuche dran zu denken. Dein Tonfall gefällt mir allerdings nicht.
Sorry, aber Du beteiligst Dich nicht erst seit heute mittag hier.
Ach... Ja sorry. Ich bin ein böser Konsument. Nicht, dass ich seit Jahren keine Frage mehr gestellt, sondern nur antworte und das zu über 90% fachlich.... Nicht doch...
Komisches Volk hier manchmal.
Grüße
Hallo Dirk!
Dein Tonfall gefällt mir allerdings nicht.
Tut mir leid, wenn Du Dich angemacht fühlst, denn es war nicht meine Absicht, aber ich rede (schreibe), wie mir der Schnabel gewachsen ist. Im RL wäre es ganz anders 'rübergekommen.
Ach... Ja sorry. Ich bin ein böser Konsument.
?
sondern nur antworte und das zu über 90% fachlich...
»Und das ist gut so«™
Komisches Volk hier manchmal.
Ja ;)
Viele Grüße aus Frankfurt/Main,
Patrick
Schreibe doch bitte mal ein spamsicheres Kontaktformular- und Kommentar-Script und veröffentliche es auf SELFHTML aktuell.
Warum? Ist dir Ingos Artikel nicht gut genug?
Was heißt »mir nicht gut genug«?
Er erfüllt nicht die o.g. Anforderungen.
Mathias
Yerf!
» Warum? Ist dir Ingos Artikel nicht gut genug?
Was heißt »mir nicht gut genug«?
Er erfüllt nicht die o.g. Anforderungen.
Captchas ebenfalls nicht... das ist wie gegen Atomkraftwerke sein, weil ein Perpetuum Mobile viel besser ist.
Ein absolut spamsicheres Formular existiert nicht, oder besser gesagt durch seine Nichtexistenz wird es spamsicher...
Gruß,
Harlequin
Ein absolut spamsicheres Formular existiert nicht
Das meinte ich nicht damit, dass Ingos Artikel die Anforderungen nicht erfüllt. Ich meinte, dass jemand bitte mal ein hinreichendes Script samt Dokumentation schreiben sollte, dass man hier mal veröffentlichen und verlinken kann.
Mathias
Moin.
»» Schreibe doch bitte mal ein spamsicheres Kontaktformular- und Kommentar-Script und veröffentliche es auf SELFHTML aktuell.
»»
»» Warum? Ist dir Ingos Artikel nicht gut genug?Was heißt »mir nicht gut genug«?
Er erfüllt nicht die o.g. Anforderungen.
Ich halte Ingos Artikel für ausreichend: Ein ausführlicherer Artikel ist nur sinnvoll, falls zusätzlich die allgemeine Technik der Formularvalidierung erläutert werden soll. Für jemanden, der damit bereits vertraut ist, dauert es keine 10 Minuten, Ingos Vorschläge umzusetzen - sofern auf den Inhaltsfilter verzichtet wird.
Wenn ich darüber nachdenke, wäre ein weiterführender Artikel eventuell doch sinnvoll, der z.B. erläutert, was zu tun ist, falls eine Seite mit personalisierten Spam-Skripten attackiert wird - ich denke hier an Dinge wie eine Neu-Verschlüsselung der Feldnamen bei jeder Formularanforderung, was es unmöglich machen würde, Felder anhand ihrer Namen maschinell zu unterscheiden - oder, wie man menschlichen Spammern Herr werden kann (musste sich Patrick nicht mal mit dieser Problematik auseinandersetzen?).
Christoph
PS: Neben der Nutzung eines Zeitstempels und dem Hinzufügen von per CSS versteckten Feldern, deren Werte nicht verändert werden dürfen, ist eine weitere einfache Möglichkeit der Spam-Erkennung das Hinzufügen von zusätzlichen Submit-Buttons, von denen der richtige genutzt werden muss. Allerdings dürfte dies gegenüber den Dummy-Feldern wenig bis keinen Mehrwert bieten. Wäre interessant, wenn jemand mal Messdaten zur Effektivität solch einfacher Maßnahmen sammeln könnte...
Für jemanden, der damit bereits vertraut ist, dauert es keine 10 Minuten, Ingos Vorschläge umzusetzen
Ingos Artikel ist eine Ideensammlung, das ist mir klar, und wer ohnehin weiß, wie man Kontaktformulare, Inhaltsprüfungen usw. implementiert, kann was damit anfangen.
Das ist schön, aber hier kommt üblicherweise jemand ins Forum, der ein fremdes Script oder einen vorgefertigten Webmailer-Service nutzt und dann angemacht wird, weil er Bild-CAPTCHAs verwendet.
ich denke hier an Dinge wie eine Neu-Verschlüsselung der Feldnamen bei jeder Formularanforderung, was es unmöglich machen würde, Felder anhand ihrer Namen maschinell zu unterscheiden
Solche Methoden könnten auf jeden Fall angesprochen werden.
Hinzufügen von zusätzlichen Submit-Buttons (...) Wäre interessant, wenn jemand mal Messdaten zur Effektivität solch einfacher Maßnahmen sammeln könnte...
Ja. Genau das sollte ein Artikel mal leisten: Erfahrungen sammeln, aufbereiten und Best Practises dokumentieren.
Mathias
Hallo,
Beides ist aber trotzdem unsinn - ein Link ist ein Link - ein Link, der auf nichts linkt ist kein Link.
Irgendein anderes Element wäre nicht besser, sondern schlechter zu bedienen.
Inwiefern wäre ein Button schlechter zu bedienen?
Ich frage hier weniger wegen des semantischen Aspekts, sondern aus einer rein egoistischen, an der Optik orientierten Sichtweise. Ich letzter Zeit geht es mir immer mehr auf den Senkel, dass man bei Web-Apps keine visuelle Unterschiedung zwischen Bedienelementen hat, die innerhalb der Seite etwas machen und Bedienelementen, die den Browser veranlassen, die Seite zu verlassen. Buttons mit eigener Formatierung, eventuell sogar abweichender Formatierung von klassischen Formular-Submit-Buttons halte ich da inzwischen für eine sehr viel bessere Lösung.
Tim
Inwiefern wäre ein Button schlechter zu bedienen?
Wäre er nicht, aber seine Präsentation stünde praktisch mehr oder weniger fest ausgehend vom derzeitigen Stand der Technik.
auf den Senkel, dass man bei Web-Apps keine visuelle Unterschiedung zwischen Bedienelementen hat, die innerhalb der Seite etwas machen und Bedienelementen, die den Browser veranlassen, die Seite zu verlassen.
Warum diese rein technische Unterscheidung?
Ich würde eher zu einer funktionalen Unterscheidung tendieren. Also blauer Text mit Unterstrich für »Ansichten«, Buttons und Menüs für »Aktionen«.
Mathias
Inwiefern wäre ein Button schlechter zu bedienen?
Wäre er nicht, aber seine Präsentation stünde praktisch mehr oder weniger fest ausgehend vom derzeitigen Stand der Technik.
Ach nein, ich vergaß, mit viel nirgendwo definierten, geschweige denn standardisiertem CSS - das Innere eines replaced inline elements liegt außerhalb des Herrschaftsbereiches von CSS -, vielen zusätzlichen Elementen sowie einem Haufen Browserhacks kann man einem Button ein anderes Antlitz geben.
Mathias
Irgendein anderes Element wäre nicht besser, sondern schlechter zu bedienen.
</archiv/2008/4/t169545/#m1107626>
</archiv/2008/3/t168236/#m1097856>
Danke, ich habe schon mehr als einmal Links in neuen Tabs geöffnet, um festzustellen, dass die neue Seite nurmehr ein "javascript: ..." als Adresse hatte. Wenn man kein vernünftiges Ziel angeben kann, sollte man auch keinen Link verwenden!
Für Dinge, deren Semantik sonst in HTML nicht verfügbar ist, gibt es übrigens div und span als generische Elemente, zusammen mit den Attributen class und id. Das sind dann wohl die Elemente und Attribute der Wahl.
ich habe schon mehr als einmal Links in neuen Tabs geöffnet, um festzustellen, dass die neue Seite nurmehr ein "javascript: ..." als Adresse hatte.
Aha, und ein blauen unterstrichenen fokussierbaren Text würdest du nicht missverstehen?
Willst du überall <button type=button> haben, damit eine eindeutige Unterscheidung möglich ist? Und was heißt eindeutig - wie sind sie von Formular-Absendebuttons zu unterscheiden? Die könntest du auch in einem neuen Tab öffnen.
Das ist m.E. eine Uneindeutigkeit, mit der man leben muss (und kann).
Für Dinge, deren Semantik sonst in HTML nicht verfügbar ist, gibt es übrigens
divundspanals generische Elemente
Im Prinzip richtig...
Das sind dann wohl die Elemente und Attribute der Wahl.
Sind sie nicht, und warum, habe ich in den verlinkten Postings beschrieben.
Man will durchaus den Großteil der (faktischen, nicht theoretischen) Semantik von a.
Mathias
ich habe schon mehr als einmal Links in neuen Tabs geöffnet, um festzustellen, dass die neue Seite nurmehr ein "javascript: ..." als Adresse hatte.
Aha, und ein blauen unterstrichenen fokussierbaren Text würdest du nicht missverstehen?
Mein Browser würde ihn mir zumindest nicht in einem neuen Tab öffnen, dass macht er nur bei Links.
Willst du überall <button type=button> haben, damit eine eindeutige Unterscheidung möglich ist? Und was heißt eindeutig - wie sind sie von Formular-Absendebuttons zu unterscheiden? Die könntest du auch in einem neuen Tab öffnen.
Das ist m.E. eine Uneindeutigkeit, mit der man leben muss (und kann).
Welches Element zu verwenden ist, hängt vom Einzelfall ab.
Für Dinge, deren Semantik sonst in HTML nicht verfügbar ist, gibt es übrigens
divundspanals generische ElementeIm Prinzip richtig...
Das sind dann wohl die Elemente und Attribute der Wahl.
Sind sie nicht, und warum, habe ich in den verlinkten Postings beschrieben.
Man will durchaus den Großteil der (faktischen, nicht theoretischen) Semantik von a.
Was ist denn die faktische Semantik von a deiner Ansicht nach?
»» Moin
»»
»» um es zu verdeutlichen:
»»
»»<a href="javascript:P91Captcha('&PHPSESSID=f882cb37b50c4c631b962e44b1ab1881');">Neuer Code?</a>
»»
»» ist nicht valid
»»
»»<a href="javascript:P91Captcha('&PHPSESSID=f882cb37b50c3c631b962e78b1ab1881');">Neuer Code?</a>
»»
»» ist valid!Beides ist aber trotzdem unsinn - ein Link ist ein Link - ein Link, der auf nichts linkt ist kein Link.
Das kann Ich leider nicht ändern. (glaube Ich)
Da im Dokument selber steht:
<a href="javascript:P91Captcha('<?=$sessionstringadd;?>');">Neuer Code?</a></td>
Dieses falsche "&" scheint PHP (oder wer auch immer) selber einzufügen.
Mfg, Sullivan
Das kann Ich leider nicht ändern.
Halte ich für ein Gerücht, du weißt nur (noch) nicht wie es zu ändern ist.
(glaube Ich)
Immer diese verdammten religiösen Fanatiker :p
Dieses falsche "&" scheint PHP (oder wer auch immer) selber einzufügen.
Einerseits wäre debugging angebracht - PHP tut nichts von alleine, irgendwer muss die Variable $sessionstringadd befüllen, andererseits liegt es daran, die Dinge kontextspezfisch zu maskieren - in diesem Fall mit htmlspecialchars()
Weiteres solltest du dich nicht auf das vorhandensein von short_open_tags verlassen und anstatt <?=$foo;?> lieber <?php echo $foo; ?> schreiben ;)
»» Dieses falsche "&" scheint PHP (oder wer auch immer) selber einzufügen.
Einerseits wäre debugging angebracht - PHP tut nichts von alleine, irgendwer muss die Variable $sessionstringadd befüllen, andererseits liegt es daran, die Dinge kontextspezfisch zu maskieren - in diesem Fall mit htmlspecialchars()
ah... wunderbar
Habe die Stelle gefunden mit dem "&" und habe es in "&" geändert.
Jetzt sagt mir W3C wieder, dass alles in Ordnung ist. :-)
Danke für die Hilfe
Mfg, Sullivan
