Aha-Effekt: es hat was mit dem CSS-Nesting zu tun. „Flachgebügelt“ (einzige Ausnahme: li steckt noch im ul) zälen sie beide wie erwartet.
Weitere Entdeckung, Typ „könnte ggf. hilfreich sein“: counters() liefert in einer Liste zunächst auch nur das, was counter abgibt. Sobald eine Liste als Kind der Liste auftaucht, wird die Ausgabe „mehrstufig“. (Und wenn man obendrein bei der Unterliste das Einpacken in <li></li> vergißt, hört das nicht mehr auf, auch nach der mißglückten Unterliste wird mehrstufig gezählt — immerhin: die Browser stört dieser Fehler sonst – anscheinend – überhaupt nicht.)
Aber: den Bug-Report kann ich wohl streichen. Denn die Quelle scheint eben in diesem Nesting begraben zu sein. Und zwar, grob schematisiert und ohne jeden störenden, ablenkenden, „sonstigen Kram“, so:
element {
ul { … }
ul li { … }
ul > li { … }
.x ul { … }
}
Wenn die Listen/Unterlisten mit anderen Dingen „verziert“ sind (irgendwas mit weiteren Selektoren), meist nicht so offensichtlich, und diese „Zweige“ zwar aktiv sind (Auswirkungen bei der Gestaltung zeigen), dann bedeutet das nicht zwingend, daß die Counter da schon deshalb zählen. Und zu sehen bekommt man ja nur das Endergebnis: es zählt, es zählt nicht – aber warum wo? Wo nicht oder (auf einem „alternativen Weg“?) wo doch?
Fazit: Nesting ist schon was Feines. Aber: nicht alles gehört da rein. Nur das, was aus der Hierarchie entsprechende Auswirkungen zeigen muß. „<p> ist kein Fall für ein „body { p { …}}“. Aber nicht, weil es (das CSS) „so ästhetischer selbst der Gestaltung dessen folgt, was damit selbst gestaltet werden soll“.
nicht angemeldet
Matthias Scharwies
Gunnar Bittersmann
Rolf B
