Hallo, > > Ist `select` das *richtige* Element? Falls ja, nimm ein select-Element … > > Du kennst das doch sicher auch, das es für vieles mehrere Lösungen gibt. ja, aber meistens ist es dann trotzdem so, dass eine der Lösungen richtig gut geeignet ist, vielleicht auch noch eine zweite, während die anderen zwar auch denkbar, aber weniger günstig sind. > Mein altes Projekt hatte eine Listbox mit <select size=10> > Wenn das Formular submitted wird, ist der selektierte alte Wert wieder mit JS und > "document.forms[0].MeinSelect.selectedIndex=pr_index" > wieder markiert worden. Warum mit Javascript? Das sollte IMO schon serverseitig passieren, indem das ausgewählte option-Element dann eben das Attribut "selected" bekommt. > Es geht darum die Optik und das Aussehen etwas zu erneuern. Dafür gibt es ja CSS. > Daher habe ich jetzt versucht eine Auswahlliste zu gestalten mit einem Bild links daneben. Zusätzlich ist die Schrift anders gestaltet und unter dem eigentlichen Eintrag gibt es noch eine Beschreibung. Kurzum, das mit einem Select zu machen scheint mir fast nicht möglich. > > Daher habe ich es jetzt mit einem Scrollbaren Div gemacht. Nur geht halt hier nicht mehr das > "document.forms[0].MeinSelect.selectedIndex=pr_index" und man muss dies mit einer Scroll Funktion machen. Du baust also die **Funktionalität** eines optimal geeigneten Standard-Elements nach, nur um in der visuellen Gestaltung mehr Freiheiten zu haben. Normalerweise würde ich lauthals davon abraten - aber leider ist es tatsächlich so, dass Formularelemente sich teils nur sehr eingeschränkt stylen lassen, so dass der Nachbau manchmal ... ja, fast eine Notwendigkeit ist. Ich würde das select-Element aber nicht mit einem aussagefreien div und ein paar untergeordneten Boxen nachbauen, sondern mit der Struktur ~~~html <fieldset> <legend /> <label><input type="radio">Beschreibung</label> <label><input type="radio">Beschreibung</label> <label><input type="radio">Beschreibung</label> ... </fieldset> ~~~ So bleiben die Dinger von der Semantik her echte Formularelemente, die serverseitige Auswertung bleibt nahezu identisch, und die verwendeten Elemente lassen sich in der Regel recht gut stylen. Man könnte aus optischen Erwägungen sogar die Radiobuttons selbst mit CSS verschwinden lassen (display:none), denn das Konstrukt ist ja durch die klickbaren Labels ebenfalls bedienbar. Sogar per Tastatur. Die etwas unschöne Verschachtelung von label und input-Element hat den Vorteil, dass man nicht große Rudel von IDs generieren muss, um label und input miteinander zu verheiraten. Korrektur: Nein, das Verschachteln ist doch keine gute Idee. Damit ist es nämlich nicht möglich, die label-Elemente anhand des checked-Status ihrer Radiobuttons zu stylen, weil es keinen Selektor gibt, der vom Kindelement aufwärts selektiert. Also schreibt man sie doch wieder als Geschwisterelemente nebeneinander: ~~~html <input type="radio" id="list001-opt004" ...><label for="list001-opt004">Beschreibung</label> ~~~ So kann man das label-Element mit ~~~css input + label { ...} input:checked + label { ... } ~~~ sowohl generisch als auch speziell im ausgewählten Zustand stylen. So long,  Martin

Hallo, > > Ist `select` das *richtige* Element? Falls ja, nimm ein select-Element … > > Du kennst das doch sicher auch, das es für vieles mehrere Lösungen gibt. ja, aber meistens ist es dann trotzdem so, dass eine der Lösungen richtig gut geeignet ist, vielleicht auch noch eine zweite, während die anderen zwar auch denkbar, aber weniger günstig sind. > Mein altes Projekt hatte eine Listbox mit <select size=10> > Wenn das Formular submitted wird, ist der selektierte alte Wert wieder mit JS und > "document.forms[0].MeinSelect.selectedIndex=pr_index" > wieder markiert worden. Warum mit Javascript? Das sollte IMO schon serverseitig passieren, indem das ausgewählte option-Element dann eben das Attribut "selected" bekommt. > Es geht darum die Optik und das Aussehen etwas zu erneuern. Dafür gibt es ja CSS. > Daher habe ich jetzt versucht eine Auswahlliste zu gestalten mit einem Bild links daneben. Zusätzlich ist die Schrift anders gestaltet und unter dem eigentlichen Eintrag gibt es noch eine Beschreibung. Kurzum, das mit einem Select zu machen scheint mir fast nicht möglich. > > Daher habe ich es jetzt mit einem Scrollbaren Div gemacht. Nur geht halt hier nicht mehr das > "document.forms[0].MeinSelect.selectedIndex=pr_index" und man muss dies mit einer Scroll Funktion machen. Du baust also die **Funktionalität** eines optimal geeigneten Standard-Elements nach, nur um in der visuellen Gestaltung mehr Freiheiten zu haben. Normalerweise würde ich lauthals davon abraten - aber leider ist es tatsächlich so, dass Formularelemente sich teils nur sehr eingeschränkt stylen lassen, so dass der Nachbau manchmal ... ja, fast eine Notwendigkeit ist. Ich würde das select-Element aber nicht mit einem aussagefreien div und ein paar untergeordneten Boxen nachbauen, sondern mit der Struktur ~~~html <fieldset> <legend /> <label><input type="radio">Beschreibung</label> <label><input type="radio">Beschreibung</label> <label><input type="radio">Beschreibung</label> ... </fieldset> ~~~ So bleiben die Dinger von der Semantik her echte Formularelemente, die serverseitige Auswertung bleibt nahezu identisch, und die verwendeten Elemente lassen sich in der Regel recht gut stylen. Man könnte aus optischen Erwägungen sogar die Radiobuttons selbst mit CSS verschwinden lassen (display:none), denn das Konstrukt ist ja durch die klickbaren Labels ebenfalls bedienbar. Sogar per Tastatur. Die etwas unschöne Verschachtelung von label und input-Element hat den Vorteil, dass man nicht große Rudel von IDs generieren muss, um label und input miteinander zu verheiraten. So long,  Martin