Jovo Rakic: einfacher Button

Hallo zusammen

ich glaube meine Frage ist ganz einfach für euch. also was ich möchte, ist ein Button erstellen auf dem steht " platz Frei" und dieser soll grün sein. Wenn ich darauf klicke soll er rot werden und es soll stehen Platz besetzt. Wenn man wiederum darauf klickt soll wieder Platz Frei kommen. Ich kenne mich leider gar nicht mit html aus. Könnte mir jemand vlt. so ein Text vormachen, damit ich evtl. nur die grösse des Buttons ändern könnte. Das wäre einfach SUPER!!

Danke im Vor raus.

Gruss

  1. Hallo und guten Abend,

    ich glaube meine Frage ist ganz einfach für euch. also was ich möchte, ist ein Button erstellen auf dem steht " platz Frei" und dieser soll grün sein. Wenn ich darauf klicke soll er rot werden und es soll stehen Platz besetzt. Wenn man wiederum darauf klickt soll wieder Platz Frei kommen. Ich kenne mich leider gar nicht mit html aus. Könnte mir jemand vlt. so ein Text vormachen, damit ich evtl. nur die grösse des Buttons ändern könnte. Das wäre einfach SUPER!!

    Ich habe Dir etwas gebastelt. Bitte versuche DU doch nun mal zu erklären, was da passiert :-)

    <!Doctype html>
    <html>
    <head>
        <meta charset="utf-8">
        <style type="text/css">
            #b1, #b2, #b3 
            {
                background-color: #00FF00;
                width: 5rem;
                font-size: 1.2rem;    
            }
        </style>
    
        <title>Buttons mit Eventlistener</title>
    </head>
    <body>
    
        <button id="b1" type="button" name="btn[b1]">frei</button>
        <button id="b2" type="button" name="btn[b2]">frei</button>
        <button id="b3" type="button" name="btn[b3]">frei</button>
    
    </body>
    
        <script type="text/javascript">
            function settext()
            {
                if (this.innerHTML == 'frei')
                {
                    this.innerHTML = 'besetzt';
                    this.style.backgroundColor = '#FF0000';
                    this.style.color = '#FFFF50';                
                }
                else
                {
                    this.innerHTML = 'frei';
                    this.style.backgroundColor = '#00FF00';
                    this.style.color = '#000050';
                }    
                return true;
            }
    
            document.getElementById('b1').addEventListener('click', settext, false);
            document.getElementById('b2').addEventListener('click', settext, false);
            document.getElementById('b3').addEventListener('click', settext, false);
        </script>
    </html>
    

    Nun müsstest Du Dir für die spätere Auswertung auf dem Server noch ein paar Gedanken machen.

    Grüße
    TS

    1. Hallo TS

          document.getElementById('b1').addEventListener('click', settext, false);
          document.getElementById('b2').addEventListener('click', settext, false);
          document.getElementById('b3').addEventListener('click', settext, false);
      

      Capturing ist per Default auf false gestellt, weshalb du dir die Übergabe des Parameters sparen kannst.

      Bubbling ist eine feine Sache, mit der man sich Wiederholungen im Code wie diese sparen kann.

      Gruß,

      HAL

      1. Hallo und guten Abend,

            document.getElementById('b1').addEventListener('click', settext, false);
            document.getElementById('b2').addEventListener('click', settext, false);
            document.getElementById('b3').addEventListener('click', settext, false);
        

        Capturing ist per Default auf false gestellt, weshalb du dir die Übergabe des Parameters sparen kannst.

        Bubbling ist eine feine Sache, mit der man sich Wiederholungen im Code wie diese sparen kann.

        Ich habe diese Aufgabenstellung aufgegriffen, weil ich auf etwas anderes hinaus will und diese als gute Vorübung empfinde.

        Ich habe zwar auch von molily eine ausführlichere Erläuterung gefunden, aber verstanden habe ich nun selber trotzdem noch nichts. Was bewirkt das dritte Funktionsargument (Capturing)?

        Wie könnte man das vereinfachen? Wie meinst Du das mit dem "Bubbeling"?`

        Mein nächster Schritt wäre jetzt die Collection und Filterung der Buttons gewesen und eine Funktion für die automatische Zuweisung des Eventlisteners. So, wie ich das hier gemacht habe, dürfte es ja sowieso nicht bleiben, weil addEventListener() auf die Schnauze fällt, wenn getElementById() das Element nicht findet. Das war nur ein Schnellschuss.


        @Jovo Rakic:
        Ich glaube sowieso, dass ein Button das falsche Element ist. Siehe hierzu auch den Thread von Dag.

        Grüße
        TS

        1. Hallo TS

          Ich habe zwar auch von molily eine ausführlichere Erläuterung gefunden, aber verstanden habe ich nun selber trotzdem noch nichts. Was bewirkt das dritte Funktionsargument (Capturing)?

          Molily hat es doch recht gut beschrieben, da wüsste ich ehrlich nicht, was ich da noch groß hinzufügen sollte. ;-)

          Stell es dir einfach so vor:

          Jedes Event hat wenigstens zwei und meistens drei Phasen:

          | Capturing-Phase | Target-Phase | Bubbling-Phase |

          ----------------> -------------> -------------->

          Beim Capturing durchläuft das Event, ausgehend von Window die ganze DOM-Hierarchie, bis es beim Zielelement angekommen ist, und innerhalb dieser Phase werden auf dem Weg alle für den entsprechenden Event-Typ hinzugefügten Handler ausgelöst, für die Capture = true gesetzt ist.

          Da Capturing aber per Default auf false gesetzt ist, passiert in dieser Phase normalerweise nichts.

          Wenn dann die Target-Phase erreicht ist, wird der für das Zielelement angelegte Handler ausgelöst, und wie es dann weitergeht, dass hängt davon ab. ;-)

          Entweder es handelt sich um ein Event, dass über keine Bubbling-Phase verfügt, weil es semantisch an das Zielelement gebunden ist, wie etwa 'load', 'focus', 'blur' usw., dann ist hier Schluss.

          Ebenso ist die Geschichte zu Ende, wenn das Event-Bubbling durch event.stopPropagation( ); unterbunden wurde.

          Gibt es hingegen bei dem Event-Typ eine Bubbling-Phase und wurde diese auch nicht händisch unterbunden, dann beginnt hier der gleiche Prozess wie in der Capturing-Phase von vorne, nur umgekehrt.

          Das heißt, das Event durchläuft - diesmal ausgehend - vom Zielelement den DOM-Baum bis hoch zu Window, und löst dabei alle Event Handler aus, die auf dem Weg dorthin für diesen Event-Typ gesetzt wurden.

          Wie könnte man das vereinfachen? Wie meinst Du das mit dem "Bubbeling"?`

          Mit Vereinfachen meinte ich, dass du dir das Event-Bubbling insofern zu Nutze machen kannst, als dass du statt für jedes einzelne Element einen Event Listener anzumelden, du den Listener auch an ein Element knüpfen kannst, welches höher in der Hierarchie ist, wie bspw. body, oder eben das nächste Vorfahrenelement, für das es im Gesamtkontext sinnvoll ist.

          Beispiel:

          var body = document.getElementsByTagName('body')[0];
          
          
          body.addEventListener('click', function (e) {
          
            if (e.target.tagName === 'button' && e.target.innerHTML == 'frei') {
          
              // etc...
          
            }
          
          });
          

          An die Callback-Funktion wird als Argument immer das Event-Objekt übergeben, also das Zielelement, welches du innerhalb der Funktion mit e.target ansprechen kannst.

          Auf die Art setzt du den Event Listener also beispielsweise nur einmal, statt für jedes Element einzeln, und selektierst dann wie gewohnt innerhalb der Callback-Funktion. - Was einem eben einiges an Schreibarbeit sparen kann. ;-)

          Gruß,

          HAL

          1. Hallo und gute Nacht,

            danke nochmal. So ungefähr habe ich es jetzt verstanden.

            Du hast in deinem Beispiel jetzt eine anonyme Funktion benutzt. Ich könnte aber auch eine benannte nehmen, oder?

            Ich mach jetzt erstmal Schluss und probiere es morgen nochmal. Vorhin hatte ich es schon fast, aber irgendwo steckte wohl ein Fehler. Da hat es mir immer das p-Element zerdröselt, in dem ich die Buttons untergebracht habe.

            Für den Einsatz für die Linkkontrolle ist das dann ja eine erhebliche Vereinfachung. Da werde ich morgen wohl noch bei AJAX ankommen :-)

            Gute Nacht TS

            1. Hallo TS

              danke nochmal. So ungefähr habe ich es jetzt verstanden.

              Freut mich. ;-)

              Du hast in deinem Beispiel jetzt eine anonyme Funktion benutzt. Ich könnte aber auch eine benannte nehmen, oder?

              Sicher,

              element.addEventListener('click', myCallback);

              und

              function myCallback (e) { /* ... */ }

              ginge genauso.

              Gute Nacht

              Bon Nuit,

              HAL

  2. Hallo zusammen

    ich glaube meine Frage ist ganz einfach für euch. also was ich möchte, ist ein Button erstellen auf dem steht " platz Frei" und dieser soll grün sein. Wenn ich darauf klicke soll er rot werden und es soll stehen Platz besetzt.

    Erster Gedanke: Datenstruktur. Z.B.

    var state = { color: 'red', label: 'occupied' };

    Nächster Gedanke: Was damit machen? Z.B. legen wir state als eine statische Eigenschaft einer Funktion fest. Statisch deswegen, damit einmal gesetzte Werte beim Funktionsaufruf nicht verloren gehen (die Funktion muss sich an den letzten Zustand erinnern können).

    Und nun? Ganz einfach, bei jedem Klick wird die Funktion aufgerufen, fertig, Dag

    Wenn man wiederum darauf klickt soll wieder Platz Frei kommen. Ich kenne mich leider gar nicht mit html aus. Könnte mir jemand vlt. so ein Text vormachen, damit ich evtl. nur die grösse des Buttons ändern könnte. Das wäre einfach SUPER!!

    Danke im Vor raus.

    Gruss

    1. Hallo und guten Abend,

      ich glaube meine Frage ist ganz einfach für euch. also was ich möchte, ist ein Button erstellen auf dem steht " platz Frei" und dieser soll grün sein. Wenn ich darauf klicke soll er rot werden und es soll stehen Platz besetzt.

      Erster Gedanke: Datenstruktur. Z.B.

      
      > var state = {
      >      color: 'red',
      >      label: 'occupied'
      > };
      
      

      Man benötigt für das Button-Element keine zusätzlich Variable zum Merken des Zustandes. Es hat auch eine Value-Property, die man per HTML initialisieren und per JS dann nutzen (auslesen, setzen) kann. Ich habe sie im Beispiel nur erst einmal weggelassen, weil ich es nicht überfrachten wollte.

      Solltes es also zum Submit kommen, kann man sämtliche Werte mit übertragen.

      Grüße
      TS

      1. Hallo und guten Abend,

        Man benötigt für das Button-Element keine zusätzlich Variable zum Merken des Zustandes. Es hat auch eine Value-Property, die man per HTML initialisieren und per JS dann nutzen (auslesen, setzen) kann.

        Das Gute am Button-Element ist: Beschriftung und value= sind zwei ganz verschiedene Dinge. Ergo werde ich den Teufel tun und am value was ändern, wenn ich die Beschriftung ändern wollte. Und genauso empfehle ich das auch. value= geht in Richtung Programmlogik, <>Beschriftung</> geht an Benutzer. Sauber getrennt und für den Zustand gibt es außerdem eine dedizierte static Variable.

        Abstarkt gesehen isses völlig Wurscth ob ein solcher Flipflop serverseitig oder clientseitig gebaut wird.

        Dag

        1. JS Beispiel

          <button onClick="ff()" id='but' style="color:white; padding:0.08in; width:2in"></button>
          
          <script>
          function ff(){
              // initialize
              if( this.state == null ){
                  this.state = { color: 'green', label: 'free' };
                  return apply(this.state);
              }
          
              // FlipFlop
              this.state = 
                 this.state.color == 'green' 
                   ? { color: 'red', label: 'occupied' }
                   : { color: 'green', label: 'free' };
              apply(this.state);
          }
          
          function apply(state){
              document.getElementById('but').innerHTML = state.label;
              document.getElementById('but').style.backgroundColor = state.color;
          }
          
          window.onload = function(){ ff() };
          
          </script>
          
  3. @@Jovo Rakic

    ich glaube meine Frage ist ganz einfach für euch. also was ich möchte, ist ein Button erstellen auf dem steht " platz Frei" und dieser soll grün sein. Wenn ich darauf klicke soll er rot werden und es soll stehen Platz besetzt. Wenn man wiederum darauf klickt soll wieder Platz Frei kommen.

    Mit „Button“ meinst du jetzt sicher allgemein ein interaktives UI-Element, keinen Absendebutton für Formulare?

    Das entsprechende UI-Element für zwei Zustände (aus/an, frei/belegt etc.) ist eine Checkbox:

    <input type="checkbox" id="seattaken" name="seattaken"/>
    <label for="seattaken">Platz besetzt</label>
    

    Mit CSS kann das so gestaltet werden, dass nur das Label zu sehen ist, nicht die Checkbox selbst; und dass das Label in Abhängigkeit davon, ob die Checkbox angehakt ist, seine Farbe und seinen (visuell sichtbaren) Text ändert.

    Danke im Vor raus.

    Nette Variante, leider falsch. Anstatt Space kommt ein Backspace: Voraus.

    LLAP 🖖

    --
    Ist diese Antwort anstößig? Dann könnte sie nützlich sein.
    1. Hallo und guten Morgen,

      ich glaube meine Frage ist ganz einfach für euch. also was ich möchte, ist ein Button erstellen auf dem steht " platz Frei" und dieser soll grün sein. Wenn ich darauf klicke soll er rot werden und es soll stehen Platz besetzt. Wenn man wiederum darauf klickt soll wieder Platz Frei kommen.

      Mit „Button“ meinst du jetzt sicher allgemein ein interaktives UI-Element, keinen Absendebutton für Formulare?

      Das entsprechende UI-Element für zwei Zustände (aus/an, frei/belegt etc.) ist eine Checkbox:

      <input type="checkbox" id="seattaken" name="seattaken"/>
      <label for="seattaken">Platz besetzt</label>
      

      Mit CSS kann das so gestaltet werden, dass nur das Label zu sehen ist, nicht die Checkbox selbst; und dass das Label in Abhängigkeit davon, ob die Checkbox angehakt ist, seine Farbe und seinen (visuell sichtbaren) Text ändert.

      Ich würde trotzdem für eine Radiogroup (mit zwei Möglichkeiten) pro Platz plädieren, weil das die Verarbeitung auf dem Server vereinfacht. Checkbox-Parameter werden ja beim Submit leider nur übertragen, wenn sie ausgewählt wurden. Warum man das so gemacht hat, habe ich bis heute nicht verstanden.

      Und nun meine Frage dazu: Könnte man die auch so stylen, dass man die eigentlichen Radioelemente nicht mehr sieht? Das kann ich mir im Moment jetzt nicht vorstellen.

      Grüße
      TS

      1. Hallo

        Das entsprechende UI-Element für zwei Zustände (aus/an, frei/belegt etc.) ist eine Checkbox:

        <input type="checkbox" id="seattaken" name="seattaken"/>
        <label for="seattaken">Platz besetzt</label>
        

        Mit CSS kann das so gestaltet werden, dass nur das Label zu sehen ist, nicht die Checkbox selbst; und dass das Label in Abhängigkeit davon, ob die Checkbox angehakt ist, seine Farbe und seinen (visuell sichtbaren) Text ändert.

        Ich würde trotzdem für eine Radiogroup (mit zwei Möglichkeiten) pro Platz plädieren, weil das die Verarbeitung auf dem Server vereinfacht.

        Gunnars Lösung fiele damit aber in ihrer Einfachheit flach, weil mehrere Radiobuttons nicht ein gemeinsames Label haben.

        Checkbox-Parameter werden ja beim Submit leider nur übertragen, wenn sie ausgewählt wurden. Warum man das so gemacht hat, habe ich bis heute nicht verstanden.

        Warum sollten die nicht ausgewählten Werte übertragen werden? Bei Radiobuttons ist das Verhalten klar. Es ist (bzw. wird) zwangsläufig ein Wert aus einer zusammengehörigen Gruppe von Werten ausgewählt. Bei Checkboxen kann es keinen, einen oder mehrere ausgewählte Werte geben. Mir fällt dabei aber für die Verarbeitung kein Anwendungszweck für die Verfügbarkeit der nicht ausgewählten Werte ein. Hast du ein Beispiel parat?

        Tschö, Auge

        --
        Es schimmerte ein Licht am Ende des Tunnels und es stammte von einem Flammenwerfer.
        Terry Pratchett, „Gevatter Tod“
        1. Hallo und guten Abend,

          Warum sollten die nicht ausgewählten Werte übertragen werden? Bei Radiobuttons ist das Verhalten klar. Es ist (bzw. wird) zwangsläufig ein Wert aus einer zusammengehörigen Gruppe von Werten ausgewählt. Bei Checkboxen kann es keinen, einen oder mehrere ausgewählte Werte geben. Mir fällt dabei aber für die Verarbeitung kein Anwendungszweck für die Verfügbarkeit der nicht ausgewählten Werte ein. Hast du ein Beispiel parat?

          Weil Du in deiner Datenbank gezielt einen Booleschen Wert wieder auf False zürücksetzen willst?

          Grüße
          TS

          1. Hallo

            Warum sollten die nicht ausgewählten Werte übertragen werden? Bei Radiobuttons ist das Verhalten klar. Es ist (bzw. wird) zwangsläufig ein Wert aus einer zusammengehörigen Gruppe von Werten ausgewählt. Bei Checkboxen kann es keinen, einen oder mehrere ausgewählte Werte geben. Mir fällt dabei aber für die Verarbeitung kein Anwendungszweck für die Verfügbarkeit der nicht ausgewählten Werte ein. Hast du ein Beispiel parat?

            Weil Du in deiner Datenbank gezielt einen Booleschen Wert wieder auf False zürücksetzen willst?

            Boolescher Wert bei einer Checkbox? Wir haben offensichtlich unterschiedliche Auffassungen für den Einsatz von Checkboxen.

            Für mich sind Checkboxen dann sinnvoll, wenn ich einen oder mehrere Werte aus einer Gruppe auswählen kann/soll, die zueinander gehören, aber nicht voneinander abhängig sind. Das wären z.B. eine oder mehrere Farben aus einer Auswahl von Farben. Das sind dann halt diese und jene Farben, die anderen aus der Auswahl jedoch nicht. Oder es ist bei der Auswahl von Benachrichtigungsarten die Email, aber nicht die SMS oder die IM-Nachricht. Im ersten Beispiel würde ich auch nicht boolesche Werte umschalten wollen, sondern eine Liste aus der Auswahl generieren. Im zweiten Beispiel wäre das Umschaten boolescher Werte zumindest eine Option, ich würde dennoch zu einer Liste (hier aus einem Element) tendieren.

            Das Nichtausgewähltsein eines Punktes lässt sich ja auch aus dem Fehlen in der Auswahl schließen. Bequemer wäre es wohl anders herum, aber dann würde es für jede Auswahlmöglichkeit jeweils zwei Übertragungen geben müssen (Name der Auswahl, Status der Auswahl). Passt mMn irgendwie nicht in's Prinzip.

            Tschö, Auge

            --
            Es schimmerte ein Licht am Ende des Tunnels und es stammte von einem Flammenwerfer.
            Terry Pratchett, „Gevatter Tod“
            1. Hallo und guten Morgen,

              Weil Du in deiner Datenbank gezielt einen Booleschen Wert wieder auf False zürücksetzen willst?

              Boolescher Wert bei einer Checkbox? Wir haben offensichtlich unterschiedliche Auffassungen für den Einsatz von Checkboxen.

              Für mich sind Checkboxen dann sinnvoll, wenn ich einen oder mehrere Werte aus einer Gruppe auswählen kann/soll, die zueinander gehören, aber nicht voneinander abhängig sind. Das wären z.B. eine oder mehrere Farben aus einer Auswahl von Farben. Das sind dann halt diese und jene Farben, die anderen aus der Auswahl jedoch nicht. Oder es ist bei der Auswahl von Benachrichtigungsarten die Email, aber nicht die SMS oder die IM-Nachricht. Im ersten Beispiel würde ich auch nicht boolesche Werte umschalten wollen, sondern eine Liste aus der Auswahl generieren. Im zweiten Beispiel wäre das Umschaten boolescher Werte zumindest eine Option, ich würde dennoch zu einer Liste (hier aus einem Element) tendieren.

              Das Nichtausgewähltsein eines Punktes lässt sich ja auch aus dem Fehlen in der Auswahl schließen. Bequemer wäre es wohl anders herum, aber dann würde es für jede Auswahlmöglichkeit jeweils zwei Übertragungen geben müssen (Name der Auswahl, Status der Auswahl). Passt mMn irgendwie nicht in's Prinzip.

              Du musst nicht Dinge verteidigen, die aus informationstechnischer Sicht Schrott sind. Da es kein Protokoll für Formularelemente gibt, sondern alles fein namensbasiert passiert, fehlt beim Nichtanklicken eine Information. Und das hat mir schon mein Professor beigebracht, dass man beim Fehlen einer Information keinen Zustand dafür ableiten darf, wenn kein Protokoll existiert. Protokoll bedeutet die Festlegung, an welcher Stelle in der Übertragung die Information zu finden ist. Nur wenn das Protokoll eingehalten wird und anstelle der Information eine Lücke übertragen wird, darf man daraus etwas ableiten.

              Formlemente können aber in beliebiger Reihenfolge mit beliebigen Lücken (kann mir jetzt aber keine vorstellen) und in beliebiger Kombination übertragen werden. Zur Übertragung eines Zustandes müssen sie daher in der Übertragung vorhanden sein.

              Insbesondere bei Verwendung von SQL im Backend ist das von Bedeutung. Nicht angesprochene Spalten im Update behalten nämlich ihren Wert.

              Grüße
              TS

              1. Hallo

                Das Nichtausgewähltsein eines Punktes lässt sich ja auch aus dem Fehlen in der Auswahl schließen. Bequemer wäre es wohl anders herum, aber dann würde es für jede Auswahlmöglichkeit jeweils zwei Übertragungen geben müssen (Name der Auswahl, Status der Auswahl). Passt mMn irgendwie nicht in's Prinzip.

                Du musst nicht Dinge verteidigen, die aus informationstechnischer Sicht Schrott sind. Da es kein Protokoll für Formularelemente gibt, sondern alles fein namensbasiert passiert, fehlt beim Nichtanklicken eine Information.

                Für mich ist eine Gruppe von Checkboxen die browserübergreifend funktionierende und für den typischen Benutzer eingängige Entsprechung einer Optionsliste mit der Möglichkeit, mehrere Einträge auszuwählen. Da ich bei einer Optionsliste ums Verrecken nicht erwarte, alle Optionen mit ihrem jeweiligen Status übertragen zu bekommen, erwarte ich das auch nicht bei Checkboxen. Zudem weiß ich typischerweise, welche Checkboxen ich überhaupt anbiete und traue mir daher durchaus zu, aus der erfolgten Auswahl meine Schlüsse zu ziehen.

                Tschö, Auge

                --
                Es schimmerte ein Licht am Ende des Tunnels und es stammte von einem Flammenwerfer.
                Terry Pratchett, „Gevatter Tod“
                1. Hallo und guten Morgen,

                  Für mich ist eine Gruppe von Checkboxen die browserübergreifend funktionierende und für den typischen Benutzer eingängige Entsprechung einer Optionsliste mit der Möglichkeit, mehrere Einträge auszuwählen. Da ich bei einer Optionsliste ums Verrecken nicht erwarte, alle Optionen mit ihrem jeweiligen Status übertragen zu bekommen, erwarte ich das auch nicht bei Checkboxen. Zudem weiß ich typischerweise, welche Checkboxen ich überhaupt anbiete und traue mir daher durchaus zu, aus der erfolgten Auswahl meine Schlüsse zu ziehen.

                  Das Konzept "Checkbox" ist aus informationstechnischer Sicht Schrott. Es fehlt die Übertragung des anderen OFF-Zustandes. Das sollte geändert werden. Ist doch nur ein Klacks Sache für die Browserentwickler.

                  Grüße
                  TS

                  1. Hallo TS,

                    Das Konzept "Checkbox" ist aus informationstechnischer Sicht Schrott. Es fehlt die Übertragung des anderen OFF-Zustandes. Das sollte geändert werden. Ist doch nur ein Klacks Sache für die Browserentwickler.

                    Das würde jedoch bedeuten, dass ganz viele Skripte geändert werden müssten, nämlich all die, deren Programmierer sich darauf verlassen hat, dass ein Vorhandensein eines entsprechenden name im $_POST gleichbedeutend mit checked ist. Das ist ganz sicher irgendwo spezifiziert[1] und kann im Sinne der Abwärtskompatibilität nicht einfach so geändert werden.

                    Bis demnächst
                    Matthias

                    --
                    Signaturen sind bloed (Steel) und Markdown ist mächtig.

                    1. zum Beispiel für HTML 4.01 in der Spezifikation 17.13 ↩︎

                    1. Hallo und guten Morgen,

                      Mitdenker finden Wege, Quertreiber Gründe.
                      Das war schon immer so.

                      Dann muss man eben ein neues Element einführen. Das darf sogar genauso aussehen, bekommt aber einen anderen Elementbezeichner. Und wenn das alte dann eines Tages kaum noch benutzt wird, kann man es ja auf die Unerwünscht-Liste setzen.

                      Grüße
                      TS

                      1. Hallo TS,

                        Dann muss man eben ein neues Element einführen. Das darf sogar genauso aussehen, bekommt aber einen anderen Elementbezeichner.

                        Ja, zum Beispiel eine 3-Status-Checkbox

                        Bis demnächst
                        Matthias

                        --
                        Signaturen sind bloed (Steel) und Markdown ist mächtig.
                      2. @@TS

                        Mitdenker finden Wege, Quertreiber Gründe.
                        Das war schon immer so.

                        Oder wie es Hans Krailsheimer ausdrückte: „Talente finden Lösungen, Genies entdecken Probleme.“

                        (Was bis vor kurzem meine Signatur war.)

                        LLAP 🖖

                        --
                        Ist diese Antwort anstößig? Dann könnte sie nützlich sein.
                  2. Tach,

                    Das Konzept "Checkbox" ist aus informationstechnischer Sicht Schrott. Es fehlt die Übertragung des anderen OFF-Zustandes. Das sollte geändert werden. Ist doch nur ein Klacks Sache für die Browserentwickler.

                    das ist nicht möglich; welchen value sollte eine Chekbox die nicht gewählt ist übertragen? Jeder value du den wählst macht eine Applikation, die diesen Value nutzt kaputt; und diese Applikationen haben das Recht zu existieren, da nie spezifische Namen oder Values als reserviert für solche Zwecke definiert waren. Der Off-Zustand wird durch die Absenz des Names signalisiert, das ist eindeutig, solange man weiß wie der Zustand vorher war (was bei einem zustandslosen Protokoll wie HTTP natürlich keine gute Idee ist, aber das ist durch exakte Interfacespezifikationen handlebar). Da alle Namen und alle Values zulässig sind, gibt es keine Möglichkeit außer reservierter Schlüsselwörter, um das unchecked zu kennzeichnen, Tim Berners Lee (bzw. die anderen Mitentwickler, Formulare waren erst in HTML 2.0, oder?) hat sich damals dagegen entschieden (vermutlich unbewusst) und das wird sich nicht in absehbarer Zeit ändern.

                    mfg
                    Woodfighter

                    1. Hallo und guten Tag,

                      Das Konzept "Checkbox" ist aus informationstechnischer Sicht Schrott. Es fehlt die Übertragung des anderen OFF-Zustandes. Das sollte geändert werden. Ist doch nur ein Klacks Sache für die Browserentwickler.

                      das ist nicht möglich; welchen value sollte eine Chekbox die nicht gewählt ist übertragen? Jeder value du den wählst macht eine Applikation, die diesen Value nutzt kaputt; und diese Applikationen haben das Recht zu existieren, da nie spezifische Namen oder Values als reserviert für solche Zwecke definiert waren. Der Off-Zustand wird durch die Absenz des Names signalisiert, das ist eindeutig, solange man weiß wie der Zustand vorher war (was bei einem zustandslosen Protokoll wie HTTP natürlich keine gute Idee ist, aber das ist durch exakte Interfacespezifikationen handlebar). Da alle Namen und alle Values zulässig sind, gibt es keine Möglichkeit außer reservierter Schlüsselwörter, um das unchecked zu kennzeichnen, Tim Berners Lee (bzw. die anderen Mitentwickler, Formulare waren erst in HTML 2.0, oder?) hat sich damals dagegen entschieden (vermutlich unbewusst) und das wird sich nicht in absehbarer Zeit ändern.

                      siehe: http://forum.selfhtml.org/self/2015/jul/24/einfacher-button/1646704#m1646704

                      Grüße
                      TS

                      1. Tach,

                        siehe: http://forum.selfhtml.org/self/2015/jul/24/einfacher-button/1646704#m1646704

                        ich glaube, dass die Rückwärtskompatibilität, die wir im Web brauchen, dafür sorgen wird, dass das nicht passiert. Es gibt mit dem radio-Typen bereits eine Alternative, die das tut, was du willst und checkbox wird nicht deprecated werden, weil es akademisch sinnvoll wäre; da haben wir Standards im Internet die deutlich dringender durch etwas Inkompatibles ersetzt werden müssten.

                        mfg
                        Woodfighter

      2. @@TS

        Ich würde trotzdem für eine Radiogroup (mit zwei Möglichkeiten) pro Platz plädieren, weil das die Verarbeitung auf dem Server vereinfacht.

        Nicht wirklich.

        Checkbox-Parameter werden ja beim Submit leider nur übertragen, wenn sie ausgewählt wurden.

        Ja und? Ob ein Parameter seattaken im Query auftaucht oder nicht ist genauso einfach – wenn nicht gar noch einfacher – abgefragt als ob ein Parameter seat den Wert "taken" oder "free" hat.

        Und nun meine Frage dazu: Könnte man die auch so stylen, dass man die eigentlichen Radioelemente nicht mehr sieht?

        Ja, genauso wie Checkboxen.

        Der Charme an Radiobuttons wäre, das zwei Labels (d.h. beide benötigte Texte) im Markup vorhanden sind. Bei meiner Lösung mit der Checkbox steht ein Text im Markup, der andere im Stylesheet. Schön ist das nicht.

        Dummerweise will man den Text des Labels des angewählten Radiobuttons anzeigen und das andere Label verstecken. Geht aber nicht, weil man zum Umschalten eben gerade das Label des nicht angewählten Radiobuttons braucht.

        LLAP 🖖

        --
        Ist diese Antwort anstößig? Dann könnte sie nützlich sein.
        1. Hallo und guten Morgen,

          Der Charme an Radiobuttons wäre, das zwei Labels (d.h. beide benötigte Texte) im Markup vorhanden sind. Bei meiner Lösung mit der Checkbox steht ein Text im Markup, der andere im Stylesheet. Schön ist das nicht.

          Dummerweise will man den Text des Labels des angewählten Radiobuttons anzeigen und das andere Label verstecken. Geht aber nicht, weil man zum Umschalten eben gerade das Label des nicht angewählten Radiobuttons braucht.

          Dann darf man das nicht zutreffende Label eben immer nur teilweise anzeigen.

            +---------+---+      +---+---------+                
            |   Frei  |   |      |   | Besetzt | 
            +---------+---+      +---+---------+    
          

          Grüße
          TS

          1. Hallo TS,

            Dann darf man das nicht zutreffende Label eben immer nur teilweise anzeigen.

              +---------+---+      +---+---------+                
              |   Frei  |   |      |   | Besetzt | 
              +---------+---+      +---+---------+    
            

            http://cssdeck.com/labs/css-checkbox-styles

            Bis demnächst
            Matthias

            --
            Signaturen sind bloed (Steel) und Markdown ist mächtig.
            1. Hallo und guten Abend,

              Dann darf man das nicht zutreffende Label eben immer nur teilweise anzeigen.

                +---------+---+      +---+---------+                
                |   Frei  |   |      |   | Besetzt | 
                +---------+---+      +---+---------+    
              

              http://cssdeck.com/labs/css-checkbox-styles

              Ist ja ein netter Link für Checkboxen.

              Es ging allerdings um den Style für Radio-Groups mit zwei Elementen. Und da sieht selbst Gunnar, wie ich das allerdings schon befürchtet hatte, auch keine Chance. Allerdings könnte man es eventuell so gestalten, wie es oben angedeutet habe.

              Grüße
              TS

              1. @@TS

                Und da sieht selbst Gunnar, wie ich das allerdings schon befürchtet hatte, auch keine Chance.

                Ha! CSS – entdecke die Möglichkeiten!

                LLAP 🖖

                --
                Ist diese Antwort anstößig? Dann könnte sie nützlich sein.
                1. Hallo und guten Abend,

                  Und da sieht selbst Gunnar, wie ich das allerdings schon befürchtet hatte, auch keine Chance.

                  Ha! CSS – entdecke die Möglichkeiten!

                  geeenau! Gut gemacht ;-) +1

                  Grüße
                  TS

        2. @@Gunnar Bittersmann

          Der Charme an Radiobuttons wäre, das zwei Labels (d.h. beide benötigte Texte) im Markup vorhanden sind. Bei meiner Lösung mit der Checkbox steht ein Text im Markup, der andere im Stylesheet. Schön ist das nicht.

          Dummerweise will man den Text des Labels des angewählten Radiobuttons anzeigen und das andere Label verstecken. Geht aber nicht, weil man zum Umschalten eben gerade das Label des nicht angewählten Radiobuttons braucht.

          Aber auch dafür gibt es eine Lösung – in Browsern, die pointer-events unterstützen:

          Beide Labels werden an der selben Stelle positioniert; das Label des ausgewählten Radiobuttons erhält einen höheren z-Index, verdeckt also das andere, somit ist nur der Text lesbar, der den aktuellen Status angibt.

          Zusätzlich wird mit pointer-events: none dafür gesorgt, dass man das Label des aktuell gewählten Radiobuttons nicht clicken kann, sondern der Click auf das Label des anderen Radiobuttons zielt.

          LLAP 🖖

          --
          Ist diese Antwort anstößig? Dann könnte sie nützlich sein.
          1. Liebe Mitdenker, liebe Wissende, liebe Neugierige,

            Der Charme an Radiobuttons wäre, das zwei Labels (d.h. beide benötigte Texte) im Markup vorhanden sind. Bei meiner Lösung mit der Checkbox steht ein Text im Markup, der andere im Stylesheet. Schön ist das nicht.

            Dummerweise will man den Text des Labels des angewählten Radiobuttons anzeigen und das andere Label verstecken. Geht aber nicht, weil man zum Umschalten eben gerade das Label des nicht angewählten Radiobuttons braucht.

            Aber auch dafür gibt es eine Lösung – in Browsern, die pointer-events unterstützen:

            Beide Labels werden an der selben Stelle positioniert; das Label des ausgewählten Radiobuttons erhält einen höheren z-Index, verdeckt also das andere, somit ist nur der Text lesbar, der den aktuellen Status angibt.

            Zusätzlich wird mit pointer-events: none dafür gesorgt, dass man das Label des aktuell gewählten Radiobuttons nicht clicken kann, sondern der Click auf das Label des anderen Radiobuttons zielt.

            Schöne Lösung. Könnte man die Elemente nun auch noch als Bildet (von Stühlen) stylen?

            Spirituelle Grüße
            Euer Robert
            robert.r@online.de

            --
            Möge der wahre Forumsgeist ewig leben!
          2. @@Gunnar Bittersmann

            Aber auch dafür gibt es eine Lösung – in Browsern, die pointer-events unterstützen:

            Damit man also die Funktion der Seite nicht kaputtmacht, wäre das Ganze in @supports zu kapseln. Auch wenn daurch einige Browser ausgeschlossen werden, die zwar pointer-events, aber nicht @supports unterstützen.

            LLAP 🖖

            --
            Ist diese Antwort anstößig? Dann könnte sie nützlich sein.
    2. Das entsprechende UI-Element für zwei Zustände (aus/an, frei/belegt etc.) ist eine Checkbox:

      Wenn Du nur 2 Zustände hast, mag das gehen. Letztendlich haben wir jedoch eine programmiertechnische Aufgabe und die würde ich nicht vom Vorhandensein von HTML-Elementen abhängig machen (Trennung von Semantik und Geschäftslogik). Zum Abstahieren weiterer Zustände habe ich meinen Ansatz mal erweitert. Wobei das Element was geklickt werden soll, nicht unbedingt ein <button> sein muss. Es sind beliebig viele Zustände möglich, die bei jedem Klick in einer vorgegebenen Reihenfolge eingestellt werden (round robin). Die Aufgabe für 2 Zustände ist somit nur ein Spezialfall.

      Schönen Sonntag

      <button onClick="ff()" id="button" style="padding:0.5em; width:2in; font-weight:bold">...</button>
      
      <script>
      function ff(nr){
          // declarations
          if(this.state == null){
              this.state = [];
              this.state[0] = { bgcolor: 'red',    text: 'Occupied',    color: 'white' };
              this.state[1] = { bgcolor: 'yellow', text: 'DAMAGED',     color: 'black' };
              this.state[2] = { bgcolor: 'green',  text: 'Free',        color: 'white' };
              this.state[3] = { bgcolor: 'blue',   text: 'nobody knows', color: 'gold' };
              this.state[4] = { bgcolor: 'white',   text: 'Closed',     color: 'navy' };
              console.log('initialize, done...');
          }
      
          // initialize
          if( this.stnr == null ){
              this.stnr = nr != null ? nr : 0;
              return apply( this.state[this.stnr]  );
          }
      
          // on each click
          this.stnr++;
          if( this.stnr > this.state.length - 1 ) this.stnr = 0;
          return apply( this.state[this.stnr]  );
      }
      
      function apply(state){
          document.getElementById('button').innerHTML             = state.text;
          document.getElementById('button').style.backgroundColor = state.bgcolor;
          document.getElementById('button').style.color           = state.color;
      }
      
      window.onload = function(){
          ff(3);
      };
      
      </script>
      
      
      1. @@Dag

        Das entsprechende UI-Element für zwei Zustände (aus/an, frei/belegt etc.) ist eine Checkbox:

        Wenn Du nur 2 Zustände hast, mag das gehen.

        Für mehrere Zustände ist das entsprechende UI-Element eine Gruppe von Radiobuttons.

        Letztendlich haben wir jedoch eine programmiertechnische Aufgabe

        ?? Was haben wir?

        und die würde ich nicht vom Vorhandensein von HTML-Elementen abhängig machen (Trennung von Semantik und Geschäftslogik).

        Ich habe Semantik und Präsentation getrennt. Geschäftslogik ist keine erforderlich.

        Wobei das Element was geklickt werden soll, nicht unbedingt ein <button> sein muss.

        Doch, muss es. Was denn sonst? a-Elemente sind für Links zu anderen Seiten gedacht. Andere Elemente kann man im Allgemeinen nicht ohne weiteres clicken.

        LLAP 🖖

        --
        Ist diese Antwort anstößig? Dann könnte sie nützlich sein.
        1. Letztendlich haben wir jedoch eine programmiertechnische Aufgabe

          ?? Was haben wir?

          Zumindest habe ich da eine Solche in der Aufgabenstellung erkannt. Habe ein Datenmodell entwickelt, welches Zustände auf Objekte abbildet. Habe festgestellt, dass mein Datenmodell transportfähig ist und dass es egal ist, an welcher Stelle das Datenmodell initialisiert wird. In meiner derzeitigen Lösung erfolgt dies alles clientseitig mit JavaScript in einer Funktion und ist unabhängig vom Markup. Es ist also soweit abstrahiert, dass es ebenso auch serverseitig implementiert werden kann, auch transparent und für den Benutzer unsichtbar. Nicht zuletzt ist mein Datenmodell beliebig erweiterbar (derzeit beschreiben 3 Attribute einen Zustand) und es sind auch beliebig viele Zustände möglich. Für mich als Entwickler ist der resultierende Code so beschaffen, dass er überschaubar, wartungsfreundlich und leicht verständlich ist (anhand des Codes ist die ursprüngliche Aufgabenstellung leicht rekonstruierbar).

          Gude Tach.

          1. Hallo und guten Morgen,

            Zumindest habe ich da eine Solche in der Aufgabenstellung erkannt. Habe ein Datenmodell entwickelt, welches Zustände auf Objekte abbildet. Habe festgestellt, dass mein Datenmodell transportfähig ist und dass es egal ist, an welcher Stelle das Datenmodell initialisiert wird. In meiner derzeitigen Lösung erfolgt dies alles clientseitig mit JavaScript in einer Funktion und ist unabhängig vom Markup. Es ist also soweit abstrahiert, dass es ebenso auch serverseitig implementiert werden kann, auch transparent und für den Benutzer unsichtbar. Nicht zuletzt ist mein Datenmodell beliebig erweiterbar (derzeit beschreiben 3 Attribute einen Zustand) und es sind auch beliebig viele Zustände möglich. Für mich als Entwickler ist der resultierende Code so beschaffen, dass er überschaubar, wartungsfreundlich und leicht verständlich ist (anhand des Codes ist die ursprüngliche Aufgabenstellung leicht rekonstruierbar).

            Natürlich steckt dahinter eine "programmiertechnische Aufgabe". Was soll man mit einer Bedienkonsole, zu der kein zu bedienendes Gerät (Datenbank) gehört?

            Aber was mich interessieren würde: eie gewährleistest Du den Fallback für JS-lose Clients? Wie überträgst Du deine States zum Server? Das hast Du alles noch nicht gezeigt.

            Grüße
            TS

            1. Hallo und guten Morgen,

              Natürlich steckt dahinter eine "programmiertechnische Aufgabe". Was soll man mit einer Bedienkonsole, zu der kein zu bedienendes Gerät (Datenbank) gehört?

              Genau. Ansonsten wäre die Eröffnung dieses Threads ja eine Halluzination gewesen ;)

              Aber was mich interessieren würde: eie gewährleistest Du den Fallback für JS-lose Clients? Wie überträgst Du deine States zum Server? Das hast Du alles noch nicht gezeigt.

              Geil, es geht weiter!:

              Möglichkeit: Der Button wird innerhalb eines Forms platziert und das Form reagiert mit onSubmit="return false". Somit läuft die Businesslogik über JS, wenn das verfügbar ist. Des Weiteren schlagt Ajax zu und überträgt den von Benutzer erklickten Zustand via HTTP-Request zum Server. Dazu wird das Objekt, was den Zustand beschreibt, transportsicher verpackt (JSON, serialize).

              Fallback (JS komplett ausgefallen): Der Button ist type="submit". So kann gesendet werden, was gesendet werden soll. Bspw. nur der Klick wobei die Zustände im Formular (JSON in hidden field) selbst gespeichert sind.

              ...

              1. Hallo und guten Morgen,

                Natürlich steckt dahinter eine "programmiertechnische Aufgabe". Was soll man mit einer Bedienkonsole, zu der kein zu bedienendes Gerät (Datenbank) gehört?

                Genau. Ansonsten wäre die Eröffnung dieses Threads ja eine Halluzination gewesen ;)

                Aber was mich interessieren würde: eie gewährleistest Du den Fallback für JS-lose Clients? Wie überträgst Du deine States zum Server? Das hast Du alles noch nicht gezeigt.

                Geil, es geht weiter!:

                Möglichkeit: Der Button wird innerhalb eines Forms platziert und das Form reagiert mit onSubmit="return false". Somit läuft die Businesslogik über JS, wenn das verfügbar ist. Des Weiteren schlagt Ajax zu und überträgt den von Benutzer erklickten Zustand via HTTP-Request zum Server. Dazu wird das Objekt, was den Zustand beschreibt, transportsicher verpackt (JSON, serialize).

                Fallback (JS komplett ausgefallen): Der Button ist type="submit". So kann gesendet werden, was gesendet werden soll. Bspw. nur der Klick wobei die Zustände im Formular (JSON in hidden field) selbst gespeichert sind.

                Wie kommen die dahin? Wo sie herkommen, kann ich mir schon vorstellen. Aber die alten will ich beim Request ja nicht wiederhaben, sondern eben die neuen vom Benutzer ausgewählten.

                Grüße
                TS

                1. Hallo und guten Morgen,

                  Fallback (JS komplett ausgefallen): Der Button ist type="submit". So kann gesendet werden, was gesendet werden soll. Bspw. nur der Klick wobei die Zustände im Formular (JSON in hidden field) selbst gespeichert sind.

                  Wie kommen die dahin? Wo sie herkommen, kann ich mir schon vorstellen. Aber die alten will ich beim Request ja nicht wiederhaben, sondern eben die neuen vom Benutzer ausgewählten.

                  Über einen Platzhalter im Template. Nach dem Submit wird ja die ganze Seite neu geschickt. Ein weiteres hidden field hält die Nummer für den aktuellen Zustand. Weitergezählt wird serverseitig.

                  Machbar ist alles ;)

      2. Liebe Mitdenker, liebe Wissende, liebe Neugierige,

        Das entsprechende UI-Element für zwei Zustände (aus/an, frei/belegt etc.) ist eine Checkbox:

        Wenn Du nur 2 Zustände hast, mag das gehen. Letztendlich haben wir jedoch eine programmiertechnische Aufgabe und die würde ich nicht vom Vorhandensein von HTML-Elementen abhängig machen (Trennung von Semantik und Geschäftslogik). Zum Abstahieren weiterer Zustände habe ich meinen Ansatz mal erweitert. Wobei das Element was geklickt werden soll, nicht unbedingt ein <button> sein muss. Es sind beliebig viele Zustände möglich, die bei jedem Klick in einer vorgegebenen Reihenfolge eingestellt werden (round robin). Die Aufgabe für 2 Zustände ist somit nur ein Spezialfall.

        Schönen Sonntag

        <button onClick="ff()" id="button" style="padding:0.5em; width:2in; font-weight:bold">...</button>
        
        <script>
        function ff(nr){
            // declarations
            if(this.state == null){
                this.state = [];
                this.state[0] = { bgcolor: 'red',    text: 'Occupied',    color: 'white' };
                this.state[1] = { bgcolor: 'yellow', text: 'DAMAGED',     color: 'black' };
                this.state[2] = { bgcolor: 'green',  text: 'Free',        color: 'white' };
                this.state[3] = { bgcolor: 'blue',   text: 'nobody knows', color: 'gold' };
                this.state[4] = { bgcolor: 'white',   text: 'Closed',     color: 'navy' };
                console.log('initialize, done...');
            }
        
            // initialize
            if( this.stnr == null ){
                this.stnr = nr != null ? nr : 0;
                return apply( this.state[this.stnr]  );
            }
        
            // on each click
            this.stnr++;
            if( this.stnr > this.state.length - 1 ) this.stnr = 0;
            return apply( this.state[this.stnr]  );
        }
        
        function apply(state){
            document.getElementById('button').innerHTML             = state.text;
            document.getElementById('button').style.backgroundColor = state.bgcolor;
            document.getElementById('button').style.color           = state.color;
        }
        
        window.onload = function(){
            ff(3);
        };
        
        </script>
        
        

        wir haben in diesem Thread ja schon viel gelernt über Eventlistener und capturing und bubbeling und über Fallback usw. Nun wäre es doch konsequent, wenn Du dein Beispil nochmal so umbauen würdest, dass diese Dinge alle berücksichigt werden, z.B. mal für eine ganze Sitzreihe.

        Und dann bleibt bei mir noch eine Frage übrig: könnte man für die Schaltelemente auch Bildet nehmen, hier eben von Stühlen?

        Ich kann leider noch nicht wiedef mitspielen. Auf dem Tablet geht das nicht so gut. Abet es kribbelt schon wieder ;-)

        Spirituelle Grüße
        Euer Robert
        robert.r@online.de

        --
        Möge der wahre Forumsgeist ewig leben!
        1. hi Bob,

          wir haben in diesem Thread ja schon viel gelernt über Eventlistener und capturing und bubbeling und über Fallback usw. Nun wäre es doch konsequent, wenn Du dein Beispil nochmal so umbauen würdest, dass diese Dinge alle berücksichigt werden, z.B. mal für eine ganze Sitzreihe.

          Und dann bleibt bei mir noch eine Frage übrig: könnte man für die Schaltelemente auch Bildet nehmen, hier eben von Stühlen?

          Was meinst du was ein Programmierer hieraus ableiten würde?

          Mein Vorschlag, nach meinem Verständnis:

          • beliebig viele klickbare Objekte bereitstellen, deren Grundform variabel ist (Stuhl, Tisch, Amboß, Zielscheibe, Feuermelder...),
          • jedes klickbare Objekt kennt mehrere Zustände, die von anderen klickbaren Objekten unabhängig sind,
          • jeder Klick löst einen Zustandübergang aus,
          • die Reihenfolge der einzelnen Zustände ist zentral konfigurierbar,
          • jeder Zustand ist durch beliebig viele Attribute gekennzeichnet wobei alle Zustände zwar diegleichen Attribute jedoch unterschiedliche Werte hierzu haben,
          • jeder Zustand ist somit auf ein Objekt abgebildet,
          • die Verwaltung der Objekte erfolgt zentral auf dem Server.

          Ich kann leider noch nicht wiedef mitspielen. Auf dem Tablet geht das nicht so gut. Abet es kribbelt schon wieder ;-)

          Aber ne verständliche Aufgabenstellung abliefern ;)

          Dag

          1. Hallo und guten Morgen,

            wir haben in diesem Thread ja schon viel gelernt über Eventlistener und capturing und bubbeling und über Fallback usw. Nun wäre es doch konsequent, wenn Du dein Beispil nochmal so umbauen würdest, dass diese Dinge alle berücksichigt werden, z.B. mal für eine ganze Sitzreihe.

            Ich kann leider noch nicht wiedef mitspielen. Auf dem Tablet geht das nicht so gut. Abet es kribbelt schon wieder ;-)

            Aber ne verständliche Aufgabenstellung abliefern ;)

            Für mich ist die Aufgabenstellung verständlich. Du hast nur aus dem Zusammenhang gerissene Idden abgeliefert und wurdest nun aufgefordert, sie in Zusammenhang zu bringen und die Rahmenbedingungen (Fallback, zeigen wie der Submit stattfindet, ...) einzuhalten.

            Grüße
            TS