Listen, value-Attribut und counters() - Bug oder unverstandenes Feature?

[Rolf B]

Hallo alle,

ich bin gerade etwas erstaunt. Arg erstaunt! Mein eigentliches HTML war umfangreicher, hier ist die minimalistische Version:

<ol>
<li>Bananen</li>
<li value="7">Äpfel</li>
<li>Birnen</li>
</ol>

Diese Liste wird brav 1,7,8 durchnummeriert, aber jetzt füge ich eine counters()-Ausgabe hinzu:

li::after { content: ' (' counters(list-item, '.') ')'; }

Erwartet:

1. Bananen (1)
7. Äpfel (7)
8. Birnen (8)

Vorgefunden (Edge Chromium v120)

1. Bananen (1)
7. Äpfel (1.7)
8. Birnen (1.8)

Das heißt: die Value-Eigenschaft hat nicht, wie die Counters- und HTML-Spec schreiben, einen counter-set: list-item 7 durchgeführt, sondern einen counter-reset und einen geschachtelten Zähler erzeugt.

Das finde ich jetzt gruselig falsch. Für mein Minibeispiel ist's natürlich wurscht, aber wenn man real mit geschachtelten Zählern und dem value-Attribut arbeitet, führt das gefundene Verhalten zu blödsinniger Darstellung.

Als Workaround kann ich mit style="counter-set: list-item 7" arbeiten. Dann ist das Ergebnis richtig. Aber das solle ja eigentlich nicht nötig sein.

Bevor ich bei Chromium einen Bug poste: Mache ich was falsch? Bringen andere Browser das auch? Ich habe jetzt nur Chromium parat.

Fiddle: https://jsfiddle.net/vcmh3pf7/1/

Rolf

[Gunnar Bittersmann]

@@Rolf B

Bevor ich bei Chromium einen Bug poste: Mache ich was falsch? Bringen andere Browser das auch? Ich habe jetzt nur Chromium parat.

Fiddle: https://jsfiddle.net/vcmh3pf7/1/

Sowohl Firefox als auch Safari zeigen in beiden Fällen das Richtige an:

1. Bananen (1)
7. Äpfel (7)
8. Birnen (8)

Sieht also nach Chromium-Bug aus.

Chromium ist der neue IE.

Kwakoni Yiquan

[Rolf B]

Hallo Gunnar,

danke. Dann schaun wir mal, was wird

Rolf

[Felix Riesterer]

Lieber Rolf,

<li value="7">Äpfel</li>

echt jetzt? Kein counter="7", sondern value="7"? Wer hat denn das verbrochen?

Liebe Grüße

Felix Riesterer

[MudGuard]

Hi,

echt jetzt? Kein counter="7", sondern value="7"? Wer hat denn das verbrochen?

jemand, der CSS-counter nicht kannte, weil es sie noch gar nicht gab …

cu,
Andreas a/k/a MudGuard

[Felix Riesterer]

Lieber MudGuard,

jemand, der CSS-counter nicht kannte, weil es sie noch gar nicht gab …

da hat er wohl zu viel bei den input-Elementen herumgeschnüffelt. So super semantisch finde ich das Attribut nämlich nicht. Und bei der Überarbeitung zu HTML5 hätte man das missbilligte Attribut nicht bestätigen müssen, sondern hätte es ersetzen können, denn CSS war da schon weit genug fortgeschritten. Und komme man mir bloß nicht mit Rückwärtskompatibilität! HTML5 hatte echte Chancen alte Dinge endlich richtig zu machen, wie z.B.

• <img src="URL" ... >Alternativtext</img>
• <li counter="123">
• <element href="URL">(spec-konforme Nachfahrenelemente)</element>.

Die Liste ist keinesfalls vollständig.

Liebe Grüße

Felix Riesterer

[Rolf B]

Hallo Felix,

Rückwärtskompatibilität 🤮

Doch. Genau die.

Ich nehme an, dass es gegen die Missbilligung von value zu viel Geschrei gab, so dass sie in 5.0 zurückgenommen wurde. Schließlich musste es ja auch einen Grund gegeben haben, das Attribut in HTML 3.2 einzuführen (in 3.0 habe ich es noch nicht gefunden).

Wenn Dir value nicht passt, nimm halt counter-set in einem Style-Attribute. Das ist semantischer, gelle?

Was leider nicht funktioniert, ist

li[counter] {
   counter-set: list-item attr(counter number);
}

Aber wer weiß. Irgendwann vielleicht. Dazu müssten sie attr (a) außerhalb von content interpretieren und (b) die Typoption für attr implementieren.

Rolf

[Gunnar Bittersmann]

@@Felix Riesterer

Und komme man mir bloß nicht mit Rückwärtskompatibilität! HTML5 hatte echte Chancen alte Dinge endlich richtig zu machen

Leider nicht. HTML5 wurde bewusst abwärtskompatibel gehalten. Andernfalls hätten Browser zwei HTML-Parser an Bord haben müssen: einen für altes, einen für neues HTML – und das für immer und ewig. Man will ja gewiss nicht, dass bestehende Webseiten auf einmal in Browsern nicht mehr funktionieren.

Das hätte auch bedeutet, dass man nicht einfach bestehende Seiten mit neuen Features wie den neuen input types hätte verbessern können, ohne alles neu zu machen.

Der Weg, nicht abwärtskompatibel zu sein, sollte ja mit XHTML2 beschritten werden – was sich keiner allgemeinen Beliebtheit erfreute.

---

• <img src="URL" ... >Alternativtext</img>

Ich erinnere mich, dass molily hier im Forum mal erklärt hat, warum man das in HTML nicht mehr fixen kann.

Kwakoni Yiquan

[Rolf B]

Hallo Felix,

keine Ahnung, aber in html 3.2 war's drin, in 4 war's deprecated und jetzt ist's reprecated.

Rolf