@@Rolf b
Aber ich möchte doch bitten, nicht zu sehr auf die Mängel des gezeigten Markups einzugehen.
Doch doch, dazu sind wir ja da.
Und wie MrMurphy1 schon sagte, bist du ja nicht der einzige, der Antworten liest. Und andere sollen sich doch nicht an unkorrigiertem Markup ein schlechtes Beispiel nehmen.
Deswegen argumentiert ihr ohne Kenntnis des eigentlichen Formulars. […] Aber da ich das Bestreben vieler hier kenne, eine ganzheitliche Antwort zu liefern, hatte ich bewusst auf die Themen hingewiesen, die ich nicht diskutieren wollte.
Du hättest im ersten Posting eher die Besonderheit deines Anwendungsfalls schildern sollen als unbegründet Dinge zu erwähnen, die du aus der Diskussion raushalten wolltest. Mit letzterem lockst du eher Leute an, die genau diese Dinge in die Diskussion reinbringen.
Die Frage mit der div-Klammerung um ein Label-Input Pärchen finde ich aber wieder sehr interessant. Ich hatte das für mich als DIV-Überschuss gesehen. Wozu Gruppen bilden, wenn da keine sind.
Ich hab da mal was hervorgehoben. Du siehst den Widerspruch?
Mit Labels als eigenem Element muss ich den Input-Elementen eine Id und einen Namen geben, das fand ich lästig und hatte deshalb bewusst die Input-Elemente in die Labels eingebettet. Ist die <div> Lösung die allgemein favorisierte?
Ganz abgesehen davon, dass input
in label
geschachtelt semantisch nicht stimmig ist (das Eingabefeld ist ja nicht Teil seiner Beschriftung), kommen einige Screenreader damit nicht klar.
Der Variante mit gruppierendem div
oder span
außenrum und label
mit for
und input
mit id
ist der Vorzug zu geben.
Nachtrag: p
als gruppierendes Element sollte auch passen.
LLAP 🖖
“I love to go to JS conferences to speak about how to avoid using JavaScript. Please learn CSS & HTML to reduce your JS code bloat.” —Estelle Weyl