On 25/03/2019 06:21, Domenic Denicola wrote: > Some time ago we spent some effort documenting a cross-browser > mostly-interoperable behavior for list-item-like behaviors, in > https://github.com/whatwg/html/pull/2002 and linked threads. The result is > the spec at > https://html.spec.whatwg.org/multipage/grouping-content.html#list-owner and > the tests at > https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-ol-element > . > > The spec at https://drafts.csswg.org/css-lists/#declaring-a-list-item seems > to contradict that hard-fought consensus. It states simply that > >> Additionally, list items automatically increment the special list-item >> counter. Unless the counter-increment property manually specifies a >> different increment for the list-item counter, it must be incremented by 1 >> on every list item, at the same time that counters are normally incremented. > > This omits all the details at > https://html.spec.whatwg.org/multipage/grouping-content.html#ordinal-value , > e.g. reversed="", the collection of owned list items, value="" attribute > parsing, etc. > > It seems like a regression to implement list item numbering according to that > spec, instead of according to HTML.
FWIW, the check-in fixing this[1] fixed multiple WPT tests related to this, and regressed none, see the .ini file changes. >> web-platform-tests: > > 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 involved, and from > what I can tell, https://drafts.csswg.org/css-lists/ does not change that. > (The appendix at https://drafts.csswg.org/css-lists/#ua-stylesheet is > informative, not normative.) So, including tests that getComputedStyle > continues to return no results for the counter-related properties or > pseudo-elements seems important to maintaining interop on this front. I agree that testing this seems useful, but I disagree on it being ignored in computed style serialization of all counter-* properties, that feels rather magical. I agree that the counter-increment should be ignored in computed style serialization (I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1539171 to fix that). Note that <li value=""> attribute parsing hasn't changed, and it's just a mapped attribute mapping to counter-set. I don't think this conflicts with the HTML spec, and I think that we should keep <li value=""> serializing counter-set in getComputedStyle. I don't think there are interop concerns for counter-set since counter-set is not implemented in other engines, but attribute mapping is straight-forward and works similarly everywhere. -- Emilio [1]: https://hg.mozilla.org/mozilla-central/rev/ae4e4daebdc4 > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
