molily: Ermittlung/Wechsel von className's

Beitrag lesen

#zusatzcheckbox:checked ~ input[type="checkbox"] { /*verstecken*/ }

Nicht schlecht. Setzt aber ein DOM voraus, bei dem alle Checkboxen ein gemeinsamen Elternelement haben. Letztlich käme man z.B. zu solchen absurden Selektoren:

#zusatzcheckbox:checked ~ p input[type="checkbox"]
#zusatzcheckbox:checked ~ p input[type="checkbox"] + label
#zusatzcheckbox:checked ~ p input[type="checkbox"]:checked + label

Das ginge. Schön ist das nicht, effizient schon gar nicht.

Das mag man** vielleicht auf Grund der extra Checkbox nicht besonders elegant finden - dafür ist es an keine zusätzlichen Techniken wie bspw. JavaScript gebunden; m.E. damit ein vertretbarer Trade-off.

Da es ohnehin um eine grafische Verschönerung geht, sehe ich kein Problem dabei, sie von JavaScript abhängig zu machen. Das erspart einem hässliche Hacks. Als Markup-Purist sollte es einem widerstreben, inhaltsloses Präsentations-Markup einzufügen. Nichts anderes ist die funktionslose Zusatz-Checkbox.

Damit die extra Checkbox keinen Nutzer verwirrt, wenn das in einem Formular eingesetzt und ohne CSS betrachtet würde, könnte man diese Checkbox noch auf readonly setzen, und noch mit einer "bitte nicht beachten" Beschriftung/Label versehen, dann wäre dieser seltene Fall auch noch abgedeckt.

Solcher Noise verwirrt den Nutzer eher vollends. Aber die Zusatzcheckbox könnte display: none, das hidden-Attribut und aria-hidden="true" besitzen, damit es unzugänglich ist.

Mathias