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