W3C home > Mailing lists > Public > public-css-archive@w3.org > March 2019

Re: [csswg-drafts] [css-lists] Initial value of counter-increment needs to be something different from none (#3686)

From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
Date: Tue, 12 Mar 2019 18:44:03 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-472132164-1552416243-sysbot+gh@w3.org>
Put more directly, I think (A) is the closest we can get to having the default list counter be implemented via the UA stylesheet, while maintaining back-compat. When you need to interact with the `list-item` counter explicitly, the code you write under (A) is identical to what you'd write if `list-item` was just set up in the UA sheet, or in an author sheet.

I'm against (B) and (C) because they cause the code you write for `list-item` to be *different* than what you'd write for a manually-created counter. (B) has some conceptual simplicity (it acts like an "additively" cascaded value, which we've talked about in the past), but I don't think that underlying conceptual simplicity is worth the additional visible complexity.

I'm against (C) because of the action-at-a-distance. Having `li[value] { counter-set: list-item attr(value integer); }`, all by itself, cancel out the increment, when any *author-created* list counters would require adding an additional `counter-increment: foo 0;` to the rule, looks confusing and unexpected. This is again added visible complexity, but without even the underlying simplicity that (B) attempts to apply.

GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3686#issuecomment-472132164 using your GitHub account
Received on Tuesday, 12 March 2019 18:44:05 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:45 UTC