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.
Rolf
--
sumpsi - posui - obstruxi
sumpsi - posui - obstruxi