> seems to contradict that hard-fought consensus. It seems like a
> regression to implement list item numbering according to that spec,
> instead of according to HTML.
As others have clarified, there are zero regressions from these changes
(that we know of) and **a lot** of bugs fixed. The compatibility with
other UAs and web content is now greatly improved.
You seem to think that HTML is the authoritative specification for
how list items work. That's only partly true.
HTML specifies the part where certain elements opens a list item
scope (ol/ul/menu), have a default 'display:list-item' value (li)
and that <li value=N> sets the value of the counter, etc.
However, the actual semantics for how list items work are
exclusively defined by CSS ([css-lists], [css-pseudo]).
The above mentioned HTML elements/attributes simply maps to
the relevant CSS properties, using a built-in 'list-item' counter.
Most importantly: this counter behaves **exactly** the same as any
other CSS counter would for a given set of style values.
We're simply not going to add a parallel "HTML counter" implementation
that is incompatible with CSS counters just to implement these HTML
elements (in fact, we've just removed the special counting we had).
Mapping HTML lists to CSS has **major** benefits for authors and
implementors alike. I'd be happy to elaborate on that if you wish.
> This omits all the details at [...], e.g. reversed="", the collection
> of owned list items, value="" attribute parsing, etc.
<li value> is mapped to the 'counter-set' property.
<ol reversed> is the one thing that isn't yet defined fully in a CSS spec.
We have implemented it using an internal (not exposed to web content)
inherited CSS property, and then map the attribute to that.
So, what our new implementation proves is that all of HTML's funky list
items can be fully and exclusively implemented using CSS concepts.
Well, we hope so anyway. We'll know after it hits the release channel :-)
> An important thing to test here is the result of getComputedStyle on
> list items as a result of this change. HTML specifies that ordinal
> values are displayed on list items without any counter CSS properties
Emilio filed https://github.com/w3c/csswg-drafts/issues/3769
I disagree that getComputedStyle should lie about the actual value
of any of the counter-* properties. I see no benefit to anyone
in doing that and I also don't think it's needed for web-compatibility.