Add sibling-index and sibling-count as custom properties

[myfonj]

A bit silly feature idea: introduce optional import(s) (or JS generator in the "bookmarklet" include) emulating upcoming sibling-count() and sibling-index() proposal (by some @argyleink dude) in a brute-force ad-nauseam low-key manner:

--sibling-index

*:nth-child(1) { --sibling-index: 0; }
*:nth-child(2) { --sibling-index: 1; }
/* ... */
*:nth-child(<N>) { --sibling-index: <N-1>; }

(*), and similarly

--sibling-count

*:has(> *:last-child:nth-child(<N>)) > * { --sibling-count: <N>; }

or for super backwards ":has()-less" compatibility (or perhaps better performance(?)) the way Lea showcased in the distant past:

*:first-child:nth-last-child(<N>),
*:first-child:nth-last-child(<N>) ~ * { --sibling-count: <N>; }

Open question remains what initial threshold to pick (1-99?) and whether pre-generate further chunks (100-999, 1000-9999, ...?) in separate includes.

Most probably ideal alternative to includes in client-side environments with scripting available could be a dynamic JS polyfill with lazy mutation observer spitting out additional chunks into in-page <style> when maximum sibling count increases somewhere in the tree..

---

(*: I am consciously proposing zero-based indexing here as god intended, even though I clearly know it has zero-chance to be adopted this way; I just had to try 🙃. For 1-based property I'd propose --sibling-order. )

[argyleink]

I see what you mean here! Nice little microjs file to aid in adopting the --sibling-index idea 🙂

I could def see this as a classname/attribute and a js import which has a mutation observer too?

I am consciously proposing zero-based indexing here as god intended

lol, I mean, if it's your function then you get to make the choices! lots of good ideas come from building tools that match your preferences.

[kizu]

I mentioned this issue in my latest article, so wanted to link back: https://kizu.dev/tree-counting-and-random/

From all my experiments there, I think it could be feasible to have reusable --sibling-index and --sibling-count up to ~100 elements. The --sibling-index requires only 19 rules to cover 99 elements, but the --sibling-count will need more if it will be using the ~ method. It is possible to make it more compact with :has(), but it is also much more performance-intensive — my article initially frozen Safari due to it.

The ~ method, though, seems pretty well optimized in all browsers, and has an excellent browser support. So if you don't need to write it from scratch and if it covers ~100 elements, that would be enough for most cases.