Hallo nix,

viel zu riesig, das guckt sich keiner an.

Für die Überschrift: Es heißt ::before , nicht :before 😉

„Different from Firefox“ ist irreführend

Korrekt ist: „Only in Safari“. Chrome zählt nämlich auch richtig. Und beim Firefox ist es tatsächlich so, dass die eine Spec-Änderung umgesetzt haben, die Blödsinn war und die von den anderen Browsern NICHT umgesetzt wurde (siehe meinen Counter-Thread von vorgestern). Der Hinweis „Different from Firefox“ könnte die Analysten dazu bringen, das Problem in dieser unterschiedlichen Implementierung zu verorten. Du hast aber ein counter-reset im article, so dass sich der FF-Unterschied nicht auswirkt.

Warum die A- und B-Liste?

Reicht da nicht eine?

Warum so viele Listenpunkte?

Reichen nicht ein oder zwei mit ext? Einer in der Subliste und einer außerhalb?

Warum die <p> Elemente um die Items?

Die blähen nur das Markup auf und erzeugen in der Ausgabe unnötig Margin

Warum class="dft"?

Für den Bug ist sie uninteressant und bläht nur das Markup auf.

Ohne unnötige Klassen ist das Markup so kompakt, dass es lesbar bleibt, wenn die Sublisten auf einer Zeile stehen.

Die & vor Typselektoren

Das war in Chrome nötig, einen geschachtelten Selektor, der als Typselektor begann, verstand er nicht. Das hat sich geändert. & li braucht man nicht mehr (bzw. wenn, dann muss man es auch überall verwenden). &.ext bleibt natürlich nötig.

Warum ein themenfremer Punkt?

Das ::before-Problem mag Dich interessieren, aber es hat mit den Countern nichts zu tun.

Hinweis 1

Falls Du im real-life nur 2 Ebenen hast, brauchst Du die Klasse nGrp nicht. li > ul reicht hin.

Hinweis 2

&.ext li { display: none; } wird übrigens deshalb nicht beachtet, weil Du kein li Element hast, das Kind eines Elements mit Klasse ext ist. Du hast höchstens li Elemente mit Klasse ext - aber die haben keine Kind-Listen.

Wie wär's hiermit?

Rolf