immerweiter: checkbox als Pflichtfeld AGB

Hallo.
Lese mich jetzt schon seit Tagen durch und komme nicht weiter, obwohl es einiges zu dem Thema gibt. Hilft mir aber alles nicht.

Ich habe einen Bezahlbutton von PayPal.
Darüber stehen drei Checkboxen: AGB, Datenschutz und Widerruf.
Bevor der Kunde über den PayPalButton kauft, muss er die Checkboxen ankreuzen.
Das geht auch alles.

Mir fehlt aber der Befehl, dass der PayPalButton nicht ausgeführt wird, wenn auch nur eine der drei checkboxen nicht einen Haken aufweist.

Außerdem hätte ich natürlich gerne einen Text ("Bitte stimmen Sie den AGB zu") der erscheint, wenn der Kunde weiter will, ohne die checkbox angeklickt zu haben.

Hoffe, es kann mir jemand helfen.

Ich benutze Rapid Weaver für die Erstellung der Seite, bin Anfänger, also bitte alles möglichst einfach.

DANKE!

  1. Mir fehlt aber der Befehl,

    In welcher Sprache? Deutsch, spanisch, englisch, suaheli, php, perl, js - oder gar in Esperanto?

    dass der PayPalButton nicht ausgeführt wird, wenn auch nur eine der drei checkboxen nicht einen Haken aufweist.

    ...

    Ich benutze Rapid Weaver für die Erstellung der Seite, bin Anfänger, also bitte alles möglichst einfach.

    Du willst uns damit sagen, dass Du kein Grundlagenwissen hast aber einen Webshop baust?
    Ich rate DRINGEND davon ab.

    Jörg Reinholz

    1. Du willst uns damit sagen, dass Du kein Grundlagenwissen hast aber einen Webshop baust?
      Ich rate DRINGEND davon ab.

      Sei mal nicht so gemein. Er sagt er hat keine Grundkentnisse, er sagt nicht dass er sich die Abmahnungen nicht leisten kann *hrhr*.

      Nagut im Ernst. Ich sage ja immer man kann nur mit Projekten wachsen. Wenn man natürlich einem Grundschüler eine Quantenphysikalische Formel auf den Tisch knallt hmm... aber ich denke du kannst deine Fähigkeiten und Begabungen selbst am besten einschätzen.

      Was du möchtest ist wahrscheinlich eine Javascript spielerei. Wenn eine Checkbox nicht angeklickt ist, ist der Button disabled. Sind alle angeklickt wird der Button wie von Zauberhand wieder aktiv und man kann ihn drücken.
      Mit JS sind das ein paar Zeilen. Einziges Problem sind die User ohne JS. Die haben entweder immer einen aktiven oder inaktiven Button. Ergo ist die einzig sichere Methode das zu prüfen mit einer Serverseitigen Programmiersprache. Das JS kann jedoch aus userbility gründen noch oben drauf gesetzt werden.

      Gruß
      Abmahngebühreneintreiber
      T-Rex

      1. @@T-Rex:

        nuqneH

        aber ich denke du kannst deine Fähigkeiten und Begabungen selbst am besten einschätzen.

        Selbsteinschätzung und Fremdeinschätzung weichen mitunter stark voneinander ab.

        Mit JS sind das ein paar Zeilen. Einziges Problem sind die User ohne JS.

        Ohne JS sind das null Zeilen. Einziges Problem sind die User ohne vernünftigen Browser (d.h. mit alten IE oder Safari).

        http://forum.de.selfhtml.org/archiv/2013/2/t212733/#m1453470 ff.

        Wurde der Bug in iOS 7 eigentlich gefixt? Und wenn ja, Betriebssystemupdate wegen Browserbugfix? Auch wenn einem iOS 7 zu flach erscheint?

        Qapla'

        --
        „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
        1. Wurde der Bug in iOS 7 eigentlich gefixt?

          Nein. (Quelle: iOS-Simulator.)

          Mathias

        2. Ohne JS sind das null Zeilen. Einziges Problem sind die User ohne vernünftigen Browser (d.h. mit alten IE oder Safari).

          Oder die Spaßvögel die einen Request direkt an eine URL abschicken. Da kann im HTML das required noch so fett oder in Schönschrift stehen ohne Serverseitige Prüfung macht der Server sonst was.

          http://forum.de.selfhtml.org/archiv/2013/2/t212733/#m1453470 ff.

          Wurde der Bug in iOS 7 eigentlich gefixt? Und wenn ja, Betriebssystemupdate wegen Browserbugfix? Auch wenn einem iOS 7 zu flach erscheint?

          Jo Browserbugs kommen auch noch dazu.

          Ich bleibe bei meiner Antwort. Der Sichere Weg ist eine Prüfung auf Serverebene und mittels JS kann man noch was hübsches oben drauf setzten.

          Selbsteinschätzung und Fremdeinschätzung weichen mitunter stark voneinander ab.

          Na und?

          Gruß
          Selbsteinschätzender
          T-Rex

          1. @@T-Rex:

            nuqneH

            Ich bleibe bei meiner Antwort. Der Sichere Weg ist eine Prüfung auf Serverebene

            Die Notwendigkeit der serverseitigen Validierung hat niemand in Abrede gestellt.

            und mittels JS kann man noch was hübsches oben drauf setzten.

            Und wegen dieser Missgeburt von Safari sollte man das auch tun. Kein Dank, Apple.

            Qapla'

            --
            „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
            1. Und wegen dieser Missgeburt von Safari sollte man das auch tun. Kein Dank, Apple.

              Wie immer gibt es technische Gründe:
              https://bugs.webkit.org/show_bug.cgi?id=59019
              https://bugs.webkit.org/show_bug.cgi?id=44436

              Dass WebKit als plattformübergreifende Software keine Shadow-DOM-Implementierung einbauen will, verstehe ich, aber das trifft nicht auf Safari zu.

              Außerdem gab es wohl Probleme mit namhaften Sites; Blink hat dazu diesen hässlichen Ausnahmecode direkt in die C++-Klasse für <input> eingebaut:
              https://chromium.googlesource.com/chromium/blink/+/6a881460b939c2ae1ef25bfbe659d6291a18a30a^!/#F0

              Ich nehme einmal an, Firefox musste ebenfalls irgendwo eine solche Ausnahme hinzufügen. Dieses Spiel hat Opera Jahrzehnte lang spielen müssen.

              Mathias

              1. @@molily:

                nuqneH

                Außerdem gab es wohl Probleme mit namhaften Sites; Blink hat dazu diesen hässlichen Ausnahmecode direkt in die C++-Klasse für <input> eingebaut:

                Wie krank ist das denn?

                Ich sehe mich in meiner Ansicht bestärkt, dass die Abkehr von XHTML das Dümmste war, was der Webentwicklung passieren konnte.

                Man hätte einfache Regeln (XML) festgelegt und von Entwicklern erwartet, dass sie diese auch einhalten, weil ansonsten die Webseite nicht angezeigt wird, sondern der XML-Parser mit Fehlermeldung aussteigt, was zur unverzüglichen Behebung des Fehlers führt.

                (Das heißt nicht, dass fehlerhafte alte Seiten nicht mehr angezeigt werden würden; der Tagsoup-Parser bleibt den Browsern erhalten. Laien hätten auch weiterhin HTML-4-Tagsoup schreiben können.)

                Aber nein, man entschied sich für Wenndiesnichtdanndasaußerwennjenes. Sehr bedauerlich.

                Qapla'

                --
                „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
                1. Hallo!

                  Wie krank ist das denn?

                  Willkommen im Web. Browserhersteller müssen einen großen Teil ihrer Zeit dafür aufwenden, Seitenerstellern die korrekte Nutzung von HTML, CSS und JavaScript beizubringen. Auch daran ist Opera letztlich gescheitert: Andere Browserhersteller mussten Quirks einbauen, damit sie das Web unterstützen, und Opera musste den Quirks mühselig nachbauen, damit das Web mit Opera nutzbar ist.

                  Ich sehe mich in meiner Ansicht bestärkt, dass die Abkehr von XHTML das Dümmste war, was der Webentwicklung passieren konnte.

                  Wie kommst du jetzt auf XML?

                  Wenn ich das richtig verstehe, hat eine wichtige Seite (U.S. Citizenship and Immigration Services) in seinem zentralen Formular offenbar ein damals nicht existentes Attribut (required) gesetzt, um es mit JavaScript auszulesen. Eine Technik, die schon 2005 kritisch diskutiert wurde, als es noch keine data-Attribute gab. Jetzt wurde die Sprache erweitert und das Attribut bekommt eine andere Semantik. Jetzt kamen Browser auf, die das required-Attribut erstmals umsetzen.

                  Was macht man da? Für die Webkit-Programmierer war es ein Fall für »DevRel«, Developer Relations. Sie haben die Seitenersteller aber nicht erreichen können, der Fehler ist immer noch im Code. Also denken sie aus Benutzersicht: Die Seite muss in unserem Browser unbedingt funktionieren, also bauen wir einen Workaround ein.

                  Man hätte einfache Regeln (XML) festgelegt und von Entwicklern erwartet, dass sie diese auch einhalten, weil ansonsten die Webseite nicht angezeigt wird, sondern der XML-Parser mit Fehlermeldung aussteigt, was zur unverzüglichen Behebung des Fehlers führt.

                  Ich denke, du verwechselst hier etwas. Hier geht es um Semantik, nicht um Syntax. Ein XML-Parser setzt Wohlgeformtheit voraus, nicht semantische Korrektheit. Im oben beschriebenen Szenario ist das Dokument wohlgeformt. Ein XML-Parser alleine hätte in dem Fall auch nicht geholfen. Vielleicht hätte eine Validierung ergeben, dass required="no" fehlerhaft ist, aber diese führt kein Browser durch.

                  Das ist ja das Fiese: XHTML 2 hätte eben nicht die Probleme wie das obige gelöst. Es hätte sie auch nicht verhindert.

                  Mathias