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

Re: [csswg-drafts] [css-values] Proposal: add sibling-count() and sibling-index() (#4559)

From: Mike Bremford via GitHub <sysbot+gh@w3.org>
Date: Thu, 05 Dec 2019 10:01:20 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-562058086-1575540078-sysbot+gh@w3.org>
I'd been trying to work up a coherent way to do this using `counter()` and `target-counter()` for some time, but I've (somewhat grudgingly) come to the conclusion that a new function is a better option - it avoids all sorts of hazards inherent in counters, which are considerably more complex then they first appear (when it comes to scoping).

I would personally lean towards a new function over a syntax that was a) not a function or b) used `var()`, because it leaves more room for expansion in the future: it's easy enough to define the sibling-index() function now, with no arguments, and get that implemented. If users demand more in the future, you can supply arguments (e.g. a selector as mentioned by @emilio). You would struggle to defined that cleanly with a `var()`.

Can I suggest that instead of `sibling-index()` and `sibling-count()` we consider `index(sibling)` and `count(sibling)` - because you can guarantee there will be situations where you want the count of your _children_ rather than siblings, for example to solve the issue from https://github.com/w3c/csswg-drafts/issues/4211:
ol[reversed] {
    counter-reset: list-item count(children);
It would be good to leave that option available in the syntax, even if it's not implemented yet.

GitHub Notification of comment by faceless2
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4559#issuecomment-562058086 using your GitHub account
Received on Thursday, 5 December 2019 10:01:25 UTC

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