JS - Variablen in HTML mehrfach belegen, mit einer Funktion auswerten

[Ammeres]

Hallo,

Hintergrund: Ich möchte ein Formular erstellen, das dem Nutzer ähnlich einer MindMap durch einen Pfad führt, abhängig von seinen bisherigen Eingaben. Ausgehend vom Hauptknoten gibt es jeweils mehrere Fieldsets, die anfangs "hidden" sind und über eine Wenn-Dann-Funktion für den Nutzer sichtbar werden sollen.

Kurz gesagt: Ich möchte mit JS das Attribut "hidden" hinzufügen oder entfernen können.

Gedanke: Theoretisch sollte dafür EIN JavaScript genügen, das immer wieder verwendet wird - vorausgesetzt, ich belege dieselben Variablen im entsprechenden Fieldset mit jeweils anderen Werten.

JS-DATEI:

function Sichtbarkeit() {
if (WertIst == WertSoll)
document.getElementByClass("EinAusblenden").removeAttribute "hidden"
else
document.getElementByClass("EinAusblenden").setAttribute "hidden"
}

Entsprechent wird in jedem Fieldset ein Script eingebunden, das die jeweilige Variable deklariert.

HTML-DATEI:

<fieldset name="..." class="EinAusblenden">
<script>
let WertIst = document.getElementById("vorherigeAuswahl").value
let WertSoll = "RichtigeAuswahlFürDiesesFieldset"
</script>

[nächste Auswahlmöglichkeiten]
</fieldset>

Die Lösung sollte möglich sein und ist sicher deutlich eleganter, als für jedes Fieldset ein eigenes Script mit geringen Abweichungen zu definieren. Leider bin ich zu doof, das auch praktisch umzusetzen. Möglich, dass ich irgendwo einen dummen Anfängerfehler mache und was übersehe.

Alternativ könnte ich auch im HTML direkt zu "true" oder "false" auswerten und im JS nur noch den Attributswechsel verarbeiten. Das kann praktisch sein, wenn mehrere Auswahlmöglichkeiten richtig sind, erfordert aber wieder mehr Code im HTML-Dokument.

Hat irgend jemand Vorschläge?

[klawischnigg]

Hi there,

Gedanke: Theoretisch sollte dafür EIN JavaScript genügen, das immer wieder verwendet wird - vorausgesetzt, ich belege dieselben Variablen im entsprechenden Fieldset mit jeweils anderen Werten.

JS-DATEI:

function Sichtbarkeit() {
if (WertIst == WertSoll)
document.getElementByClass("EinAusblenden").removeAttribute "hidden"
else
document.getElementByClass("EinAusblenden").setAttribute "hidden"
}

muß heissen ..removeAttribute("hidden"), sonst gibts einen Syntaxerror.

Hat irgend jemand Vorschläge?

Naja, wenn Du einen Knoten hast, wie Du zu Beginn schreibst, dann könntest Du mit Fieldset-Hierarchien arbeiten (die Du jeweils in den IDs der Fieldsets notieren könntest), wenn nicht, dann gibts immer noch die Möglichkeit, den Formular-Elementen der jeweiligen Fieldsets bestimmte Klassen zu geben. Damit kannst Du die ansprechen und jeweils ganze Sets ein- und ausblenden...

[Ammeres]

Naja, wenn Du einen Knoten hast, wie Du zu Beginn schreibst, dann könntest Du mit Fieldset-Hierarchien arbeiten (die Du jeweils in den IDs der Fieldsets notieren könntest), wenn nicht, dann gibts immer noch die Möglichkeit, den Formular-Elementen der jeweiligen Fieldsets bestimmte Klassen zu geben. Damit kannst Du die ansprechen und jeweils ganze Sets ein- und ausblenden...

Wie meinst du das mit Hierarchien? Ich habe eben im Wiki nichts gefunden.

Und ich will sie gern schrittweise einblenden, da sich die Wege mehrfach verzweigen und wieder zusammenführen können. Außerdem ist so die Nutzerführung besser (s. Wiki).

Das mit den Attributen klingt gut; deutlich besser als was ich vor hatte. Werde ich morgen früh gleich mal etwas damit spielen!

[klawischnigg]

Hi there,

Wie meinst du das mit Hierarchien? Ich habe eben im Wiki nichts gefunden.

Ich meinte kein Javascript-Feature sondern einfach eine logische Auszeichnung für die ID oder auch die Data-Attribute, aus der die Ebene des Knotens hervorgeht, so in der Art, Ebene 0 hat die Werte A0...,A1...,A2..., Ebene 1 die Werte B0..., B1..., B2 etc. etc. - ist vermutlich ohnehin nicht notwendig, könnte nur in Deinem Fall hilfreich sein, wenn Du Deinen Anwender wieder eine Ebene nach "oben" zurückgehen läßt...

[Ammeres]

Ah. Möglich... auch wenn ich denke, sprechende Namen wären besser. Vllt. kombiniere ich es auch.

[MudGuard]

Hi,

Theoretisch sollte dafür EIN JavaScript genügen, das immer wieder verwendet wird - vorausgesetzt, ich belege dieselben Variablen im entsprechenden Fieldset mit jeweils anderen Werten.

hinterlege die Werte in data-Attributen im jeweiligen Element.

cu,
Andreas a/k/a MudGuard

[Gunnar Bittersmann]

@@Ammeres

Ich habe deinen Code mal als solchen formatiert. Bitte das nächste Mal selber machen – ``` davor und danach im Markdown oder einfach mit dem </>-Button überm Eingabefeld.

function Sichtbarkeit() {
if (WertIst == WertSoll)
document.getElementByClass("EinAusblenden").removeAttribute "hidden"
else
document.getElementByClass("EinAusblenden").setAttribute "hidden"
}

Das kann aus mehreren Gründen nicht funktionieren. Die schon angesprochenen fehlenden Klammern sind nur einer davon.

Die Methode setAttribute() erwartet zwei Parameter: Name und Wert des Attributs. Um ein boolesches Attribut zu setzen, wäre als Wert der Leerstring anzugeben.

Viel einfacher ist aber, die hidden-Eigenschaft zu verwenden:

function Sichtbarkeit() {
  if (WertIst == WertSoll)
    document.getElementByClass("EinAusblenden").hidden = false;
  else
    document.getElementByClass("EinAusblenden").hidden = true;
}

Und noch viel einfacher: die if-Abfrage entsorgen. Die brauchst du nicht, weil du als Wert ja genau die Negation der Bedingung zuweisen willst:

function Sichtbarkeit() {
  document.getElementByClass("EinAusblenden").hidden = (WertIst != WertSoll);
}

Jetzt wirst du darüber stolpern, dass es keine Methode getElementByClass() gibt. Es gibt getElementsByClassName() – beachte den Plural!

Was willst du: genau ein Element ansprechen oder mehrere?

😷 LLAP

PS: Wenn die Funktion Sichtbarkeit() nur noch aus einem Einzeiler besteht, dann macht es vermutlich wenig Sinn, diesen in einer Funktion zu kapseln.

[Der Martin]

Hallo,

function Sichtbarkeit() {
  document.getElementByClass("EinAusblenden").hidden = (WertIst != WertSoll);
}

PS: Wenn die Funktion Sichtbarkeit() nur noch aus einem Einzeiler besteht, dann macht es vermutlich wenig sinn, diesen in einer Funktion zu kapseln.

wo du das Stichwort kapseln erwähnst: Hier ist ja nichts gekapselt. Die Funktion greift auf irgendwelche Werte außerhalb ihres Scopes zu. Das ist gar nicht schön.

Eine Funktion sollte die Werte, mit denen sie arbeiten soll, als Argumente (Funktionsparameter) übergeben bekommen. In diesem Fall also WertIst und WertSoll, und vielleicht noch den Klassennamen, der da zu betrachten ist.

Dann kann man sie nämlich auch für beliebige Elemente und Werte nutzen.

Live long and pros healthy,
 Martin

[Ammeres]

Hallo Gunnar,

dein Vorschlag sieht sehr elegant aus! Ich hätte nicht erwartet, dass hidden automatisch entfernt wird, weil es ja nicht explizit angewiesen wird.

Jetzt wirst du darüber stolpern, dass es keine Methode getElementByClass() gibt. Es gibt getElementsByClassName() – beachte den Plural!

Ich hab das aus dem Kopf gemacht... in Brackets gibt's dafür die automatischen Vorschläge. ;)

Was willst du: genau ein Element ansprechen oder mehrere?

Viele Elemente (im Endeffekt wohl die meisten Fieldsets), die alle eigene Soll- und IstWerte haben. Letzteres werde ich entsprechend mit Data-Attributen (danke MudGuard) versuchen.

PS: Wenn die Funktion Sichtbarkeit() nur noch aus einem Einzeiler besteht, dann macht es vermutlich wenig Sinn, diesen in einer Funktion zu kapseln.

Andererseits muss ich sie dutzendfach verwenden - ich denke, es wäre "unsauber", das immer wieder zu copy-pasten, wenn es einen anderen Weg gibt.

[Ammeres]

Ich habe nun versucht, Gunnars Beispiel nachzubauen. Das Ergebnis sieht so aus und funktioniert noch nicht:

document.addEventListener("DOMContentLoaded", registerEventListenerHidden);

function registerEventListenerHidden() {
document.getElementById("ADP").addEventListener("change", function ELADP() {
document.getElementById("NPZ").onchange.hidden = (document.getElementById("ADP").value != "Pn");
});
}

Tut sich einfach nichts. :/ Ist der Code so korrekt?

Zugleich habe ich mehrere Fehlermeldungen:

Kann das damit zusammenhängen?

[dedlfix]

Tach!

Tut sich einfach nichts. :/

Was sagt die Browser-Konsole? Wenn sie nichts sagt, Debugger verwenden, Breakpoints setzen und schauen, was konkret passiert oder auch nicht.

Ist der Code so korrekt?

Augenscheinlich ja.

Zugleich habe ich mehrere Fehlermeldungen:

Das sind Meckereien von zwei Lintern. Die meckern anhand einer statischen Anlayse. Sie haben keine Ahnung von der Laufzeitumgebung. Vielleicht kann man ihnen sagen, dass der Code in einer Browserumgebung läuft, dann wüssten sie, dass document vom Browser bereitgestellt existiert. Die meisten gelben Warnungen betreffen Einrückungen. Das sind nur Schönheitsfehler.

Den typsicheren Vergleich !== statt dem nicht typsicheren != zu verwenden bringt in diesem Fall weder Plus- noch Minuspunkte. Der Value eines Eingabefeldes ist immer vom Typ String. Der Vegleich findet mit einem Stringliteral statt, da sind die Typen stets gleich, und Typgleichheit zu erzwingen, ändert daran nichts.

Die Funktion wurde zwar laut Reihenfolge im Code eher verwendet als angelegt, aber zur Laufzeit sorgt das Hoisting dafür, dass benannte Funktionen vor dem Start der Ausführung sozusagen im Code nach oben geholt werden, und damit zur Verfügung stehen.

dedlfix.

[Rolf B]

Hallo dedlfix,

Augenscheinlich ja

Augenscheinlich nein. Es hätte eine Fehlermeldung in der Browserkonsole geben müssen, dass die Eigenschaft hidden von null nicht existiert.

document.getElementById("NPZ").onchange.hidden = ...

So hat Gunnar das nicht aufgeschrieben.

Das onchange-Attribut enthält einen String mit Javascript-Code oder eine Funktion, die beim Auslösen des Change-Events zu rufen sind (als historische Alternative zu addEventListener). Und dafür gibt's kein hidden.

Wenn, dann so:

document.getElementById("NPZ").hidden = ...

Rolf

[Ammeres]

So hat Gunnar das nicht aufgeschrieben.

Wow bin ich ein Trottel, danke... das "onchange" hat sich irgendwie in meinem Hirn festgefressen und ich hab keine Ahnung, woher. Ich habe es eben geändert, aber es funktioniert immer noch nicht.

Screenshot der Konsole (ohne Erweiterungen): Ich interpretiere, dass Brackets keine Verbindung ins Netz aufbauen kann (wobei mir der Grund schleierhaft ist). Das sollte den Live Preview aber nicht beeinflussen; zumindest mit HTML funktioniert das gut.

Frage: Erkenne ich im Seitenquelltext, ob

• eine .js-Datei erfolgreich eingebunden wurde?
• ein Event-Handler gesetzt wurde?

Ich habe den Code mal minimalisiert. Das hab ich bisher:

<!DOCTYPE html>
<html lang="de">

<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Titel</title>
    <link rel="stylesheet" href="main.css">
    <script src="zustaendig.js" async></script>
</head>

<body>
    <main>

        <form name="FZE">
            <fieldset name="ADP">
                <select id="APD">
                    <option value="-">-</option>
                    <option value="Pn">N-P</option>
                    <option value="Pj">J-P</option>
                </select>
            </fieldset>

            <fieldset id="NPZ">
                <!-- Dieses soll bei "Pn" eingeblendet, sonst hidden sein. -->
                <legend>Zweck der Datenerfassung</legend>
                <input type="checkbox" value="EN">PZ<br>
                <input type="checkbox" value="EN">FZ<br>
                <input type="checkbox" value="EJ">AZ
            </fieldset>
        </form>
    </main>
</body>

</html>

'use strict';

document.addEventListener("DOMContentLoaded", registerEventListenerHidden);

function registerEventListenerHidden() {
    /* Diese Funktion fügt jedem Fieldset einen EventListener hinzu, der es abhängig von vorherigen Eingaben dynamisch ein- und ausblendet. */
    document.getElementById("ADP").addEventListener("change", function ELADP() {
        document.getElementById("NPZ").hidden = (document.getElementById("ADP").value != "Pn");
    });
}

Vielleicht sieht jemand etwas, das ich nicht sehe.

[Rolf B]

Hallo Ammeres,

Variablengebrauch 101:

• Benenne deine Identifikationen so, dass sie Dich nicht verwirren. ADP und APD ist gruselig, da guckt man fünfmal drauf und verwechselt es immer noch
• Das gilt für JS-Variablen genauso wie für id und name Attribute.

DOM Methoden 101:

• id und name sind nicht das selbe
• getElementById("foo") findet demnach nichts mit name="foo"

Wenn Du ein Element mit einem bestimmten name-Attribut finden willst, musst Du document.getElementsByName verwenden - beachte den Plural. Eine id muss eindeutig im Dokument sein, ein name nicht, deswegen ist getElementsByName auf die Rückgabe einer NodeList ausgelegt und getElementById auf die Rückgabe eines einzelnen Elements.

Gunnar weist auch gerne auf den alternativen Zugriff über die document.forms Auflistung hin, da findest Du dein Form als document.forms.FZE. Von da aus kommst Du auch an die Form-Elemente heran - ich vermeide das aber grundsätzlich, weil man im Script nicht weiß, ob document.forms.FZE.ADP ein einzelnes Element oder eine Elementliste liefert. Das hängt davon ab, ob im HTML ein oder mehrere Elemente mit einem solchen Namen stehen; ich habe also auf einmal eine Strukturabhängigkeit zwischen Script und HTML. Sowas ist schlechte Architektur, und darum verwende ich lieber eine Methode, bei der der Ergebnistyp wohldefiniert ist.

Wenn Du Alternativen zu getElementsByName suchst, wären die Methoden querySelector und querySelectorAll vorzuziehne, mit denen Du ausgehend vom Dokument ODER von einem Element einen CSS Selektor verwenden kannst, um ein bestimmtes Element oder eine Liste von passenden Elementen zu finden.

Rolf

[Ammeres]

Leider bringt mich das nicht groß weiter. An IDs sind hier nur 2 relevant, 1x APD - der Selector - und einmal NPZ - das Feld, das dynamisch hidden oder eben nicht sein soll. (ADP ist für das Script irrelevant.)

Ich habe auch nochmals kontrolliert; ich habe bei beidem ID verwendet, sowohl im HTML als auch im JS. So kann ich das Script also auch nicht zum laufen bewegen. :/

Gibt es eigentlich eine Konvention zur Länge von Variablen? Sprechende Variablen sind ja ganz nützlich, wenn sie aber aufeinander aufbauen wird irgendwann sowas wie...

function registriereEventListenerChangeSelectVonAdresseDesUrgrossvatersFürFormZukuenftigeAdresseDesUrenkels() {
}

Gibt es einen Richtwert, ab wann Abkürzungen okay bzw. empfohlen sind? Und sollen die sich durch die ganze Benennung ziehen?

[Rolf B]

Hallo Ammeres,

ADP ist für das Script irrelevant.

Eben. Aber du machst ein getElementById darauf. Und deswegen referierte ich über verwirrende Benennungen.

Zum Namensthema möchte ich ein Zitat bringen, das Phil Karlton zugeschrieben wird (ehemals „Principal Curmudgeon“ bei Netscape):

There are only two hard things in Computer Science: cache invalidation and naming things

Es gibt noch eine Erweiterung, deren Quelle mir aber unbekannt ist:

There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors

Der von Dir gebrachte Name ist natürlich überlang. Ein guter Name muss den Spagat zwischen Prägnanz und Benutzbarkeit finden. Wenn viele Namen zusammentreffen, ist auch Unverwechselbarkeit ein wichtiges Kriterium. Diese Aufgabe zu lösen ist jedesmal eine neue Herausforderung, und ob etwas prägnant, benutzbar und unverwechselbar ist, ist auch zum Teil Auffassungssache des Namensgebers. Wenn man in einem Team arbeitet, gibt man sich oft Regeln, nach denen Namen zu bilden sind, um Edit Wars zu vermeiden. Das kann helfen, wenn die Regeln zum eigenen Stil passen, oder gruselig sein, wenn sie es gar nicht tun. Ist man alleine, muss man seine eigenen Regeln finden.

Methoden tun etwas, deshalb sollte der Name auch eine Tätigkeit wiederspiegeln. Deswegen getElementById, und nicht beispielsweise "elementWithId". Eigenschaften repräsentieren Dinge oder Zustände, deswegen sollte deren Name auch ein Substantiv oder ein Adjektiv sein (oder daran erinnern).

Ob man beim Benennen einen Sprachmix benutzt oder nicht, ist Auffassungssache. Eine Methode "getAdresse" findet sich häufig, weil "get" eine Standardoperation ist, aber viele kritisieren den Englisch-Deutsch Mix und nennen die Methode "ladeAdresse" oder "getAddress". Du musst für Dich festlegen, was Du für richtig hältst.

Rolf

[Ammeres]

Eben. Aber du machst ein getElementById darauf. Und deswegen referierte ich über verwirrende Benennungen.

Point taken.

Ich habe den Code diesbezüglich nochmal eindeutig benannt und erneut ausgemistet:

<!DOCTYPE html>
<html lang="de">

<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <script src="JavaScript.js" async></script>
</head>

<body>
    <form>
        <fieldset>
            <select id="Value-Quelle">
                <option value="-">-</option>
                <option value="Sichtbar">Ja</option>
                <option value="andererValue">Nein</option>
            </select>
        </fieldset>

        <fieldset id="Un-Hide">
            <!-- Dieses soll bei "Ja" / "Sichtbar" eingeblendet, sonst hidden sein. -->
            <legend>Sichtbarkeitstest</legend>
        </fieldset>
    </form>
</body>

</html>

sowie JS:

'use strict';

document.addEventListener("DOMContentLoaded", registerEventListenerHidden);

function registerEventListenerHidden() {
    document.getElementById("Value-Quelle").addEventListener("change", function EinAusblenden() {
        document.getElementById("Un-Hide").hidden = (document.getElementById("Value-Quelle").value != "Sichtbar");
    });

[Ammeres]

Nachtrag zu diesem Thread: Ich denke, Rolf hat die Aufgabe exzellent gelöst. https://forum.selfhtml.org/self/2021/sep/12/js-variablen-in-html-mehrfach-belegen-mit-einer-funktion-auswerten/1791592#m1791592

[JürgenB]

Hallo

Hat irgend jemand Vorschläge?

auf die Javascript-Fehler wurde ja schon hingewiesen. Ein Blick in die Javascriptkonsole deines Browsers ist da recht hilfreich.

Zu deinem Problem: du möchtest auf eine Nutzereingabe reagieren, also auf ein Event. Daher solltest du dich auch noch mit dem Thema Eventhandling beschäftigen. Ich würde hier das input-Event nehmen und addEventListener verwenden.

Gruß
Jürgen

[Rolf B]

Hallo Ammeres,

ich verstehe deinen inhaltlichen Ansatz noch nicht. Du hast ein Fieldset mit einem Eingabefeld, und wenn ein bestimmter Wert eingegeben wird, sollen andere Fieldsets sichtbar werden?

Ist das ein Quiz / eine Wissensabfrage? Denn andernfalls wäre eine Checkbox benutzerfreundlicher.

Oder ist deine Logik eigentlich umfangreicher als ein einfacher Test auf Gleichheit? Wenn es einfach mehrere Werte sind und je nach Wert ein anderer Teil sichtbar werden soll, könntest Du über Radiobuttons nachdenken, oder <select> Elemente.

Wie genau man deinen Code so strukturiert, dass er möglichst aus wiederverwendbaren Komponenten besteht, hängt von dieser Fachlichkeit ab.

Und das hier:

<fieldset name="..." class="EinAusblenden">
<script>
let WertIst = document.getElementById("vorherigeAuswahl").value
let WertSoll = "RichtigeAuswahlFürDiesesFieldset"
</script>

hat noch ein ganz anderes Problem: Du findest in WertIst immer nur den Wert vor, den das Eingabeelement mit der id "vorherigeAuswahl" beim Laden der Seite hat. Benutzereingaben findest Du darin nicht. Das liegt daran, dass der Browser beim Laden der Seite nicht an einem Script anhält und auf Benutzereingaben wartet. Er führt alles von oben nach unten aus und wartet dann auf Benutzerinteraktion.

Du musst also, wie Jürgen schrieb, auf das input- oder change-Event der Eingabefelder reagieren und in der Funktion, die das Event behandelt, den Wert des Eingabefeldes auslesen, das das Event ausgelöst hat. Und dann kannst Du basierend darauf andere Eingabefelder bzw. Fielsets freischalten. Der Unterschied zwischen input und change ist, dass input nach jedem Zeichen, dass Du eingibst, sofort reagiert und change erst, wenn Du das Feld verlässt.

Rolf

[Ammeres]

Hallo Rolf,

bis auf den Anfang, an dem ein - für die Logik unrelevanter - Text eingegeben werden können soll (Zukunftsmusik - die Logik soll später für einzelne Einheiten jeweils einzeln durchlaufen werden können), sind keine Textfelder geplant, sondern nur <select>, falls nur eine Auswahl richtig sein kann, oder <input checkbox>, falls mehrere Möglichkeiten nebeneinander bestehen können. Daher hatte ich an Change gedacht - denn auswählen und das "Feld verlassen" sollten ja identisch sein.

Oder ist deine Logik eigentlich umfangreicher als ein einfacher Test auf Gleichheit?

Hm... die einzelnen Logik-Schritte lassen sich sehr gut als Gleichheitstest umsetzen. Grundsätzlich ist es so aufgebaut: "Wenn A, zeige Feld X, wenn B zeige Feld Y, wenn C, zeige Feld Z". Umgekehrt ergibt sich daraus "Zeige Feld X wenn A (sonst nicht). / Zeige X nicht, wenn nicht A (sonst schon)." - und das ist ein einfacher Gleichheitstest. Die Logik ergibt sich dann aus mehreren solchen Schritten hintereinander, die zu unterschiedlichen Ergebnissen führen können. Der elementare Schritt ist jedoch immer: Wenn A, dann B, sonst nichts.

Ich habe nochmal den Beitrag zu Radio Buttons durchgelesen: ich verstehe, warum sie nutzerfreundlicher sind; sie bieten einfach eine größere Klickfläche und sind daher intuitiver, und bieten programmiertechnisch mehr Möglichkeiten (sich ausschließende Auswahlen). Ich werde dann auf diese wechseln.

PS: Event-Handling habe ich mir schon vormarkiert: https://wiki.selfhtml.org/wiki/JavaScript/Tutorials/DOM/Ereignisverarbeitung#Event-Handler_registrieren:_addEventListener Wenn ich da nicht durchsteige hatte ich das eher für einen eigenen Thread gedacht - sollte aber Standard genug sein, um Anleitungen en masse zu finden.

[Rolf B]

Hallo Ammeres,

okay, wenn Du Checkboxen, Radiobuttons oder Select Elemente verwendest, ist die Logik einfacher.

Das event-Objekt des input-Events hat ein eine target-Eigenschaft, darin findest Du das relevante HTML Element.

• Bei Checkboxen: checked-Attribut abfragen
• Bei Radiobuttons: Alle Buttons einer Gruppe müssen das gleiche name-Attribut, aber unterschiedlichen Value haben (damit Du sie unterscheiden kannst). In event.target findest Du im Eventhandler den Radiobutton, der ausgewählt wurde, und dort im value Attribut, was ausgewählt wurde
• Bei select: event.target.value liefert das value-Attribut des ausgewählten option-Elements.

Und basierend darauf kannst Du dann relativ einfach weitermachen.

Aber irgendwie brauchst Du ja deine Mindmap. Die musst Du auch irgendwie im System hinterlegen. Wenn Du das im HTML unterbringen willst, könntest Du dazu das data-Attribut verwenden. Bei Checkboxen ist es vermutlich so, dass jede Checkbox einen bestimmten Bereich freischaltet? Oder gibt es bei Dir Konstrukte, dass die Sichtbarkeit eines Fieldsets von einer bestimmten Checkbox-Kombination im vorigen Fieldset abhängt? Bei Radiobuttons kannst du ein data-Attribut auf den Radiobutton selbst legen, und bei Selects kannst Du den Options data-Attribute geben. Über die selectedOptions Eigenschaft des select-Elements bekommst Du die ausgewählte Option heraus und kannst auf deren dataset zugreifen.

Die Alternative ist ein Bereich im JavaScript-Teil, der die Mindmap darstellt. So gaaanz einfach ist das nicht, du jonglierst da schon etwas mit Datenstrukturen herum.

Rolf

[Ammeres]

Bei Radiobuttons: Alle Buttons einer Gruppe müssen das gleiche name-Attribut, aber unterschiedlichen Value haben (damit Du sie unterscheiden kannst).

Hallo Rolf,

da habe ich den Wiki-Eintrag so gelesen: Radio-Buttons müssen den gleichen name haben, WENN nur einer zugleich zutreffen kann - also dieselbe Funktion wie bei select. Sie müssen jedoch unterschiedliche name haben, wenn mehrere zugleich ausgewählt werden können sollen.

Soweit richtig verstanden?

[Der Martin]

Hallo,

Bei Radiobuttons: Alle Buttons einer Gruppe müssen das gleiche name-Attribut, aber unterschiedlichen Value haben (damit Du sie unterscheiden kannst).

Radio-Buttons müssen den gleichen name haben, WENN nur einer zugleich zutreffen kann - also dieselbe Funktion wie bei select. Sie müssen jedoch unterschiedliche name haben, wenn mehrere zugleich ausgewählt werden können sollen.

Soweit richtig verstanden?

ja, vollkommen korrekt.

Das gleiche name-Attribut bei mehreren Radio-Buttons hat zwei Auswirkungen:

1. Der Browser erkennt die Gruppe als solche, und beim Anklicken eines Radio-Buttons einer Gruppe wird der vorher aktive wieder abgewählt.
2. Beim Absenden des Formulars werden aus jeder Gruppe nur die aktuell aktiven Radio-Buttons an den Server übermittelt. Die anderen werden ignoriert.

Live long and pros healthy,
 Martin

[MudGuard]

Hi,

2. Beim Absenden des Formulars werden aus jeder Gruppe nur die aktuell aktiven Radio-Buttons an den Server übermittelt. Die anderen werden ignoriert.

wird aus jeder Gruppe nur der aktuell aktive Radio-Button an den Server übermittelt - es kann ja pro Gruppe nur einen geben. Ist wie beim Highlander …

cu,
Andreas a/k/a MudGuard

[Der Martin]

Hallo,

2. Beim Absenden des Formulars werden aus jeder Gruppe nur die aktuell aktiven Radio-Buttons an den Server übermittelt. Die anderen werden ignoriert.

wird aus jeder Gruppe nur der aktuell aktive Radio-Button an den Server übermittelt - es kann ja pro Gruppe nur einen geben. Ist wie beim Highlander …

ja, es kann aber mehrere unabhängige Gruppen geben. So rechtfertigt sich der Plural dann doch, und so war es gemeint.

Live long and pros healthy,
 Martin

[Ammeres]

Zu den Radio Buttons: Ich habe eben ausprobiert und kann sie nicht mehr ent-checken, anders als bei einer Checkbox. Sie bleiben einfach weiterhin ausgewählt. Soll das so?

[Rolf B]

Hallo Ammeres,

ja, das soll so. Alle entchecken ist nicht vorgesehen.

Workaround 1: Sieh einen Zusatz-Radiobutton vor mit einem "nichts" Wert

Workaround 2: Sieh einen Zusatz-Button vor mit der Funktion "Auswahl löschen". Da deine Seite konzeptionell ohne JS nicht zu funktionieren scheint, kann man das machen.

Bonusfrage: Wie geht deine Seite generell mit Situationen um, in denen JavaScript nicht ausgeführt wird? Das kann mehrere Gründe haben

• dein JavaScript ist buggy und crasht (das kannst Du verhindern)
• der User hat JavaScript deaktiviert (das kann der User ändern - wenn er will)
• dein User ist in einer Gegend, wo das Netz wackelig ist, und hat die JS Datei nicht bekommen - oder NOCH nicht bekommen, weil die Daten noch hereintröpfeln (das kann keiner von euch verhindern)

Es ist ärgerlich, wenn man hinter einem 200MBit Hochdruckrohr sitzt, an sowas denken zu müssen, aber viele Mobilanwender müssen mit diesem Problem umgehen.

Rolf

[Ammeres]

Dann funktioniert die Seite nicht. Zumindest kann ich mir nicht vorstellen, wie ich es nur in HTML schreiben können sollte, und hier kamen auch keine entsprechenden Vorschläge.

Workaround 1: ...

Wozu so komplex, wenn es auch Checkboxen tun?

Anderes: Ich habe die Fehlermeldung 'document' is not defined (W117). Ich habs durch Google gejagt, aber nur zurück bekommen, dass JavaScript zu früh ausgeführt würde... aber ich habe meine Script-Datei als async eingebunden, d.h. das sollte nicht vorkommen. (Auch "defer" ändert nichts daran)

<script src="zustaendig.js" async></script>

Editor Brackets, strict mode.

[Rolf B]

Hallo Ammeres,

Zumindest kann ich mir nicht vorstellen, wie ich es nur in HTML schreiben können sollte,

Nein, das kannst Du auch nicht. Hm. VIELLEICHT schon, mit CSS Hacks, aber das wäre ein Krampf, wäre schlecht bedienbar (im Sinne von Zugänglichkeit) und entspricht auch nicht guter Praxis.

Eine JavaScript-freie Lösung braucht serverseitigen Code, d.h. nach jeder Änderung einer Auswahlstufe bräuchte es einen Submit-Button, der die Seite zum Server schickt und der schaltet die weiteren Fieldsets frei.

Wenn es für Dich okay ist, dass die Seite ohne JS gar nicht nutzbar ist, dann mach das so. Aber Du solltest deine User darüber informieren.

• wenn dein JavaScript inline in der HTML Seite ist: Setze den Info-Paragraphen in ein <noscript> Element
• wenn dein JavaScript in einer separaten JS Datei liegt: Sorge dafür, dass dein JavaScript den Info-Paragraphen als erste Amtshandlung auf "hidden" setzen. Bei einer lahmen Internetverbindung kann es sein, dass die Info einen Moment stehen bleibt, bis das Script anläuft und sie entfernt. Ist dann so.

Wozu so komplex, wenn es auch Checkboxen tun?

Mit Checkboxen kannst Du keine Gruppe von Radiobuttons abbilden. Diese beiden Bedienelemente haben unterschiedliche Bedeutung und sind nicht untereinander austauschbar.

W117

Das schrieb ja schon Dedlfix. Du hast 3 Code-Validatoren drin (Linter), und jeder hat eigene Vorschläge dazu, was Du besser machen könntest. Einer versucht Dir seine Ideen von Code-Style aufzudrücken (JSLint), und die beiden anderen (ESLint und JSHint) sind unpassend für deinen Zweck konfiguriert, sonst würden sie nicht über eine bekannte globale Variable meckern.

Lösung für ESLint

Lösung für JSHint - entweder trägst Du globale Variablen des Browsers in einer der möglichen Konfigurationsdateien ein, oder Du deklarierst sie inline mit /* globals document */

Du könntest aber überlegen, ob Du tatsächlich drei Linter brauchst; sicherlich kann man irgendwo einstellen, welche verwendet werden.

Rolf

[Ammeres]

Eine JavaScript-freie Lösung braucht serverseitigen Code, d.h. nach jeder Änderung einer Auswahlstufe bräuchte es einen Submit-Button, der die Seite zum Server schickt und der schaltet die weiteren Fieldsets frei.

Genau das wollte ich tunlichst vermeiden. Wenn das Technische steht will ich versuchen, eine PWA-Funktion hinzuzufügen. Ich will, dass alles "offline" funktioniert, d.h. der Server nur einmal die Files rausrückt und sonst nichts zu tun hat.

Aber Du solltest deine User darüber informieren.

Guter Hinweis, ist auf der ToDo-Liste.

Mit Checkboxen kannst Du keine Gruppe von Radiobuttons abbilden. Diese beiden Bedienelemente haben unterschiedliche Bedeutung und sind nicht untereinander austauschbar.

Checkbox: tut, was ich will. Radio: tut was anderes. ;) Ich brauche die Radio-Funktionen aktuell schlicht nicht.

Die Linter und Hinter habe ich mittlerweile gefixt:

//Dieser Abschnitt entfernt verschiedene Fehlermeldungen von JShint, JSlint und ESlint.
/* jshint browser: true */
/*eslint no-undef: "error"*/
/*eslint-env browser*/
/*jslint node: true */

Jetzt kommt nur noch "was used before it was defined" und "expected !== and saw !=.

[Rolf B]

Hallo Ammeres,

ich habe mal ein bisschen gespielt. Das Ergebnis ist wie befürchtet relativ abstrakt, aber das JavaScript ist relativ klein und die komplette Steuerlogik ergibt sich aus den aria-controls Attributen im HTML. Ich hoffe, @Gunnar Bittersmann, dass ich aria-controls korrekt anwende.

Eine aria-Attributierung brauchst Du mutmaßlich sowieso, denn ein Screenreader muss ja mitbekommen, ob Änderungen am Element A zu Änderungen des Elements B führen.

https://jsfiddle.net/Rolf_b/pry7xwn2/

Der Code verwendet Pfeilfunktionen und die for..of Schleife. Wenn Du möchtest, dass er im Internet Explorer funktioniert, musst Du das durch Alt-Konstrukte ersetzen.

Kern der Aktion ist die controlVisibility-Funktion, die eine Liste von controller-Elementen bekommt - also solche, die potenziell ein aria-controls Attribut tragen können, und alle IDs, die sie darüber findet, ein- oder ausblendet.

Angesteuert wird sie von controlVisibilityChange, die je nach Typ des Steuerelements die passenden controller-Elemente heraussucht.

Und controlVisibilityChange wird vom eigentlichen Eventhandler aufgerufen, der als Pfeilfunktion in der Registrierschleife versteckt ist.

Die Idee dabei ist, dass an den option-, Radio- und Checkbox-Elementen jeweils ein aria-controls Attribut steckt, das die IDs der Fieldsets beinhaltet, die durch dieses Element sichtbar gemacht werden.

Jedes Auswahlelement bzw. jede Auswahlgruppe bekommt eine value-source Klasse - das Script sucht sich diese heraus und registriert einen generischen Handler darauf. Generisch deshalb, weil man beim Umschalten weiter oben die Sichtbarkeit weiter unten wieder herstellen muss, basierend auf den eingestellten Werten der eingeblendeten Fieldsets, und ein generischer Handler kann das rekursiv erledigen.

Das Script setzt natürlich darauf, dass die value-source Gruppen ein standardisiertes Markup haben. D.h.

Typ Select: Die value-source Klasse sitzt auf dem Select-Element und die aria-controls Attribute auf den Option-Elementen

Typ Radio: Die value-source Klasse sitzt auf einem Container, der die Radiobuttons enthält, und die Radiobuttons haben die aria-controls Attribute

Typ Checkbox: Die value-source Klasse sitzt auf einem Container, der die Checkboxen enthält, und die Checkboxen haben die aria-controls Attribute

Für die rekursive Fortsetzung braucht man noch den showSelected-Schalter, um festlegen zu können, ob nur ausgeblendet werden soll oder auch die selektierten Folge-Fieldsets einzublenden sind.

Ich hoffe, das ist jetzt nicht weit über deiner Hutschnur...

Rolf

[Ammeres]

Wow. Das ist sehr gute Arbeit, Rolf; einen dicken Dank meinerseits!

Die Wirkweise habe ich schon verstanden: wenn ein value gewählt wird sagt es dem Handler, welches fieldset er sichtbar machen soll. Das gefällt mir von der Übersichtlichkeit her sehr gut. Außerdem lehne ich mich mal aus dem Fenster, es sollte möglich sein, mehrere Fieldsets mit einem Attribut zugleich ein- und auszublenden. (Auch wenn es aktuell keinen Bedarf gibt.)

Mir ist aufgefallen, dass der value gespeichert bleibt, auch wenn ein Feld aus- und wieder eingeblendet wird. Zuerst dachte ich mir, ich lösche bei "hide" automatisch alle Daten, aber irgendwie gefällt es mir - so ist bei einem Missklick nicht alles weg. Ich denke, ich werde stattdessen einen "clear"-Button in jene fieldsets einfügen, in denen er sinnvoll scheint.

Wenn Du möchtest, dass er im Internet Explorer funktioniert, musst Du das durch Alt-Konstrukte ersetzen.

Du weckst Kindheitserinnerungen. :P Ich hab mir schon vorgenommen (analog zu "Java Script muss aktiv sein") einen Hinweis einzubringen: "Der Code funktioniert mit allen modernen Browsern*. *Der Internet Explorer ist kein Browser, sondern eine Sicherheitslücke."

Für die rekursive Fortsetzung braucht man noch den showSelected-Schalter, um festlegen zu können, ob nur ausgeblendet werden soll oder auch die selektierten Folge-Fieldsets einzublenden sind.

Ich hoffe, das ist jetzt nicht weit über deiner Hutschnur...

Hutschnur habe ich schon lange nicht mehr gehört. :)

Bis auf den zitierten letzten Satz ist soweit alles verständlich. Den Switch - bzw. seinen Anknüpfpunkt - habe ich gefunden, er ist hier:

controlVisibility(controlGroup.querySelectorAll("option"), false); 

Das Verhalten passt perfekt so, wie es ist. Am Ende soll ja über genau diese Methode dem Nutzer nur die "richtige" Antwort angezeigt werden. Alle einzublenden würde bedeuten, dass er wieder nicht weiß, welche richtig sind. Das würde den ganzen anderen Code ad absurdum führen.

Ist meine Hutschnur hoch genug angesetzt? :)

.

Dazu habe ich noch 2 möglicherweise dumme, allgemeine Fragen:

1. Warum werden eigentlich so viele Variablen deklariert?

    let controls = controlGroup.querySelectorAll("input[type=radio]");
    if (controls.length > 0)

ließe sich eigentlich in einer Zeile schreiben, da du die Variable nirgendwo anders verwendest:

    if (controlGroup.querySelectorAll("input[type=radio]").length > 0)

Da die Variable im Prinzip nichts anderes als ein Shortcut des Links ist, bleibt sich das Ergebnis doch gleich?

2. Zu Aria: So wie ich es verstanden habe, sind die Aria-Attribute eine Art "verbesserte" Version der normalen Attribute - also Attribute, die wirklich interaktiv oder leichter zugänglich sind. Richtig soweit?

PS: Gibt es einen Grund, warum "let controls = ..." erst beim zweiten Teil (radio) eingeführt wird und nicht bereits bei dem Block (select)?

[Rolf B]

Hallo Ammeres,

einen dicken Dank

Gern geschehen. Wobei ich mich damit mal wieder über die Energie des Verstehens hinweg gesetzt habe - wir wollen eigentlich keinen kopierfähigen Code raushauen, sondern die Forenteilnehmer zum Selberdenken motivieren. Aber die Aufgabe hatte mich gereizt, und ich glaube, selbst konstruiert hättest Du das in der Art erstmal nicht.

Außerdem lehne ich mich mal aus dem Fenster, es sollte möglich sein, mehrere Fieldsets mit einem Attribut zugleich ein- und auszublenden.

Dafür kannst Du das Fenster zulassen, das mach ich im Un-Hide-F Block des Fiddles doch vor 😂

ließe sich eigentlich in einer Zeile schreiben, da du die Variable nirgendwo anders verwendest

Guck nochmal hin, gleich eine Zeile drunter verwende ich sie, weil ich den querySelectorAll nicht für die Parameterübergabe wiederholen möchte.

Du hast sicher gesehen, dass controlVisibility zweimal aufgerufen wird.

Das erste Mal mit false, um sämtliche abhängigen Fieldsets auszublenden. Sozusagen, um eine saubere "Arbeitsgrundlage" für den zweiten Aufruf zu bekommen.
Das zweite Mal mit true, um die ausgewählten Fieldsets wieder einzublenden.

Das könnte man sicherlich auch so erledigen, dass man die abhängigen Fieldsets nur einmal durchgeht und pro Durchlauf prüft, ob man das Fieldset nun aus- oder einblenden muss, aber der Code dafür ist deutlich umständlicher. Und da die Layout-Engine des Browsers ohnehin erst nach Abschluss des Eventhandlers zu arbeiten beginnt, spart das auch nicht wirklich Verarbeitungszeit.

Zu Aria: Nun ja, eine "Verbesserung der normalen Attribute" ist das eher nicht, sondern ein Addon, um Zusatzinformationen für Assistenztechnologien bereitzustellen, die vom normalen HTML nicht geliefert werden. WAI-ARIA ist ein komplexes Biest und zumeist beißt es mich in den Hintern…

Hier verwende ich es für den Zusammenhang, dass ein Element ein anderes steuert - und den so definierten Zusammenhang nutze ich dann auch gleich im Script. Ob das so den Ideen von WAI-ARIA entspricht, soll Gunnar noch begutachten, der ist Accessibility-Experte.

Rolf

[Ammeres]

Dafür kannst Du das Fenster zulassen, das mach ich im Un-Hide-F Block des Fiddles doch vor 😂

Das habe ich später dann auch gesehen. :D

wir wollen eigentlich keinen kopierfähigen Code raushauen, sondern die Forenteilnehmer zum Selberdenken motivieren.

Ehrlich gesagt hatte ich gedacht, es handele sich um eine Basisfunktion, für die es dutzende Beispiele gibt. Also wie "so geht eine Wenn-Dann-Funktion" eben "so blenden sie Felder dynamisch ein und aus". Aber du hast mich dennoch zum Selbstdenken motiviert: Das ist mein erstes HTML-Projekt und ohne diese Funktion wäre der Ansatz gescheitert; ich hätte mich also kaum mehr weiter mit HTML beschäftigt. Ich hatte mir schon überlegt, WordPress nochmals eine Chance zu geben, aber das liefert noch unverständlicheren Code und ich habe gar keine Ahnung mehr, was ich eigentlich tue. Kurz gesagt: In ein paar Tagen werde ich auf jeden Fall schlauer sein, als ich ohne deine Hilfe jemals geworden wäre. ;)

und ich glaube, selbst konstruiert hättest Du das in der Art erstmal nicht.

Ganz sicher nicht - schon allein, weil mir bis eben die Aria-Attribute und ihr Nutzen unbekannt waren.

Guck nochmal hin, gleich eine Zeile drunter verwende ich sie, weil ich den querySelectorAll nicht für die Parameterübergabe wiederholen möchte.

Stimmt, du hast es zweimal; mein Fehler. Musste mich erst einmal so durchkämpfen.

[Rolf B]

Hallo Ammeres,

freut mich, dass Du Dich da hineinwühlen willst und es nicht stumpf kopierst.

Wenn Du noch Fragen hast, immer herbei.

Rolf

[Ammeres]

Hallo Zusammen,

ich habe Rolfs Vorschlag nun so umgearbeitet, dass er Klassen statt IDs kontrolliert. Dabei habe ich nun zwei Herausforderungen:

1. aria-controls
   aria-controls ist per Definition dafür gedacht, eine Liste an IDs zu enthalten, nicht an Klassen. Es wäre stilsicherer, eine aria-* zu nutzen, die für eine Liste an Klassen gedacht ist - ich konnte jedoch keine finden.
   Kann mir jemand eine nennen?

.

2. Ich stehe nun vor drei Möglichkeiten:

a) Ich bleibe bei IDs.
Das wäre von der Handhabung her unpraktisch, da teilweise viele Elemente abhängig von einer Eingabe eingeblendet werden sollen.

b) Ich wechsle vollständig auf Klassen.
Praktischere Handhabung, aber aria-controls wird missbraucht.

c) Ich nutze beides.
Dazu muss ich nur das Skript doppelt verwenden, und einmal auf aria-controls (für IDs) und aria-owns (für Klassen) [vice versa] einstellen. Die Möglichkeit wäre zwar vielseitig, zugleich aber doppelt so viel Code und mehr Möglichkeiten, etwas durcheinander zu bringen.

Aktuell tendiere ich zu b.
Dennoch wollte ich euer Erfahrungswissen anzapfen:
Gibt es weitere Punkte, die für a oder c sprechen - oder gegen b?
Gibt es eventuell noch ein d, das ich nicht gesehen habe?

[Rolf B]

Hallo Ammeres,

meine Meinung hast Du schon: Bleib bei IDs. Damit ist die Zugänglichkeit am besten unterstützt. Wenn Du mit einem Radiobutton oder einer Checkbox 10 Fieldsets einschalten musst, könntest Du auch überlegen, ob Du nicht alle 10 in eine section legst und die Section aktivierst.

Allerdings scheint mir die Seite ziemlich gewaltig zu sein. Wieviele fieldsets hast Du da?

Rolf

[MudGuard]

Hi,

meine Meinung hast Du schon: Bleib bei IDs. Damit ist die Zugänglichkeit am besten unterstützt. Wenn Du mit einem Radiobutton oder einer Checkbox 10 Fieldsets einschalten musst, könntest Du auch überlegen, ob Du nicht alle 10 in eine section legst und die Section aktivierst.

dürfen fieldsets geschachtelt werden?

Falls ja, wäre das auch als gruppierendes Element denkbar.

cu,
Andreas a/k/a MudGuard

[Der Martin]

Hallo,

dürfen fieldsets geschachtelt werden?

ich habe die Spec gerade nicht zur Hand, geschweige denn im Kopf.
Aber mein Bauchgefühl sagt: Nein.

Falls ja, wäre das auch als gruppierendes Element denkbar.

Ja. Aber ein Formular mit geschachtelten fieldsets macht mir Angst. Das wird semantisch so komplex, dass das kaum noch zu begreifen ist.

Live long and pros healthy,
 Martin

[Ammeres]

Ja, fieldsets dürfen verschachtelt werden - form-Elemente hingegen nicht. Das hatte ich mir auch schon überlegt.
In dem Fall wäre ich jedoch mehr für <section> oder <div>, da fieldsets deutliche Auswirkungen auf die Graphik haben - und das mittels CSS zu kompensieren wird am Ende noch "irrer".

Beides ändert jedoch nichts daran, dass ich damit die inhalts-logische Struktur zerstöre (oder sehr viele davon brauche).

[Ammeres]

Keine <fieldset>, sondern <li>.

Mein Endergebnis ist eine <ul> mit aktuell über 30 <li> (Unterlisten nicht eingerechnet), Tendenz steigend. Diese Punkte haben eine Art "innerer Reihenfolge". Abhängig von den vorherigen Auswahlen sollen bestimmte Punkte eingeblendet werden, andere nicht, das überschneidet sich eben an manchen Stellen. Es wäre theoretisch mit Fieldsets möglich, ich müsste allerdings etliche Punkte mehrfach aufnehmen und die inhaltlich-logische bzw. quellenbezogene Struktur zerbrechen und der fachlich-logischen unterordnen. Dazu ist es dann nicht mehr "einheitlich" formatiert, da die Fieldsets die Liste unterbrechen (dann eher noch <div>s - wie es bei <section> ist, weiß ich gerade nicht). Das würde die Nutzer nur unnötig verwirren.
Zusätzlich gibt es Punkte, die sich sehr ähnlich sind, aber inhaltlich "steigern".
Manchmal wird bei einer Auswahl nur ein Punkt angezeigt, ein andermal 10 und mehr.

Aktuell kann ich jeden <li> gezielt ansteuern, sei er nun allein oder im Dutzend. Durch die gleiche Klassen-Benennung ist der logische Zusammenhang im HTML auch schnell ersichtlich.

Dazu kommt, dass ich die Struktur langfristig für ähnliche Projekte parallel nutzen / zur Verfügung stellen will. Die sich thematisch überschneiden und idealerweise wieder inhaltslogisch verschachteln/kombinieren lassen...

[Tabellenkalk]

Hallo,

Mein Endergebnis ist eine <ul> mit aktuell über 30 <li> (Unterlisten nicht eingerechnet), Tendenz steigend. Diese Punkte haben eine Art "innerer Reihenfolge".

Wäre es dann nicht besser eine <ol> zu nehmen?

Gruß
Kalk

[Ammeres]

Hallo Kalk,

Wäre es dann nicht besser eine <ol> zu nehmen?

Eine <ol> ist doch durchnummeriert. Wenn ich also einzelne <ol>-Punkte dynamisch ausblende, hat das entweder zur Folge, dass bestimmte Punkte "übersprungen" werden, oder dass eine Nummer verschiedene Inhalte hat. (Vmtl. ersteres?)
Bei ersterem wird sich der Nutzer fragen, warum und welche Punkte übersprungen wurden; bei letzterem kann es passieren, dass er sich denkt "Die Nummer kenne ich schon", ohne auf den Inhalt zu achten.

Ich stelle mir das eher hinderlich vor fürs Verständnis, lasse mich aber gern eines besseren belehren. Welchen Nutzen versprichst du dir davon?

(Ich kann es mal im Hinterkopf behalten - im Endeffekt muss ich 2 Buchstaben austauschen und kanns mir später selbst ansehen.)

[Der Martin]

Hallo,

Wäre es dann nicht besser eine <ol> zu nehmen?

Eine <ol> ist doch durchnummeriert.

zunächst ja. Die Numerierung als solche kann man aber mit CSS ausblenden.

Wenn ich also einzelne <ol>-Punkte dynamisch ausblende, hat das entweder zur Folge, dass bestimmte Punkte "übersprungen" werden, oder dass eine Nummer verschiedene Inhalte hat. (Vmtl. ersteres?)

Vermute ich auch.

Welchen Nutzen versprichst du dir davon?

Es geht rein um die Semantik, nicht ums Aussehen. Ein ul steht für unordered list, also eine Liste ohne vorgegebene Reihenfolge; ol steht für ordered list, also eine sortierte Liste.
Merke: sortiert ≠ numeriert.

Live long and pros healthy,
 Martin