Re: [csswg-drafts] [css-values] enable the use of counter() inside calc() (#1026)

Hello! I apologize if this is not 100% related, but I have found a genuine use case for enabling `counter()` to work inside of `if()` functions. 

I develop themes for an Electron application (Obsidian) where the DOM is generated by JavaScript and cannot be modified. There are containers that visually have no children (all children are `display: none`) but are not structurally empty, since they contain a wrapper element that itself has no visible descendants. The only way to conditionally style the container right now is by using `:has()`, which is costly and already frequently used in the application's own stylesheet. A counter-based approach allows me to detect "visually empty" containers without using `:has()`.

I observed that `counter-increment` does not increment on an element with `display: none`. This means a counter scoped to a parent and incremented by its children effectively counts only **visible** children, which `sibling-count()` does not since it counts all DOM siblings regardless of their display state. Counters correctly track this information, and they render accurately when called in `content`. But there is currently no way to access their result outside of `content`, or crucially, to use the result to branch via `if()` or `@container` style queries.

Now as for implementing such a change, I believe there is a good precedent for it. From my understanding, `sibling-count()` already returns an integer value for use in `calc()` and conditional statements. Either a hypothetical `counter-value()` function, or allowing `counter()` to resolve to an `<integer>` when used outside of `content`, would enable visible-child-aware styling that is intuitive and performant compared to using `:has()`.

This is what I have attempted so far:

1. `counter-reset: children` on a parent container
2. `counter-increment: children` on each child element
3. Storing the result in a variable `--count: counter(children)`
4. Styling the parent based on this result `if(style(--count: 0): /* hide parent */)`

The first three work, but as expected, I run into a roadblock at the last point. The variable stores the **unresolved** `counter()` tokens, not the resolved value. From my limited understanding, the only context where `counter()` currently resolves to a usable value is when used in `content` (where it resolves to a string). Therefore, my `if()` styling does not work.

There is an additional complication, that being that the updated counter value only shows up on an `::after` pseudo-element of the parent and not the parent itself. This means that I cannot access the updated `counter()` value from the parent element I actually want to style, only from its pseudo-element which appears *after* all the children element in the DOM. 

What this means is that the only options for conditionally styling the parent, even if I am able to access `counter()`'s value outside of `content`, is to use the pseudo-element to hide or cover the parent, or by grabbing the pseudo-element's `content` using a hypothetical `content(after)` statement. This has been considered already in the past: "The CSS generated content module introduces six yet-to-be implemented CSS functions including `content()`, `string()`, and `leader()`, and the three [`[<target>](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/content#target)`](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/content#target) functions `target-counter()`, `target-counters()`, and `target-text()`." in https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Generated_content#functions.

On one last note, I have tried to read and understand the rationale against implementing these changes, due to the risk of circular dependencies. However, I believe the use case I suggested is simple and isolated enough to mostly sidestep the issue. After all, there is no use of `calc()` in my use case, and all of the child elements are already `display: none` so the counter reads 0 on the first layout pass. Hiding the parent element (and thus removing all its children from the rendering tree) based on this result does not change the counter, since the counter already resolved to 0 to begin with.

-- 
GitHub Notification of comment by Gonzalo-D-Sales
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1026#issuecomment-4874645530 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 3 July 2026 09:11:33 UTC