[css-values] enable the use of counter() inside calc()

[psylok]

Feature request.
It would be nice to be able to use the counter() function inside of calc() function.
That would enable new possibilities on layouts.

I copy here the link to a thread which proposed it last august.
https://lists.w3.org/Archives/Public/www-style/2016Aug/0073.html

[AmeliaBR]

Relevant section of the spec, which includes an inline issue discussing possible use cases. But getting an issue on GitHub will hopefully provide an easier forum for other people to mention their use cases and/or possible implementation issues.

[MelSumner]

Hi, ran into a case today where this would have helped, so posting a comment here.

I'm setting up some CSS for an image/logo slider. While I know right now that there are 8 images, I don't know how many there will be in the future (nor do I wish to have to know). I'm using only CSS to animate it, and it would be useful to be able to say "for each one of the items that exist (, increment this property by x."
I ended up using sass to do something like this:

@for $i from 1 through 8 {  
    &:nth-of-type(#{$i}) {
        $delay: calc(5s * #{$i});
	animation: slideIn 45s linear $delay infinite;
    }
}

[Loirooriol]

The problem with this proposal is that counter() returns a , but calc() does not work with strings. For example, counter(id, upper-latin) might be 'A'. How exactly is calc() supposed to know that this means 1?

So I think we need some way to get the numeric value of a counter, either by adding some parameter to counter() or a new function. This should be allowed to appear anywhere an integer is expected, including (but not necessarily in) calc(). I wrote my thoughts in #1871.

[Crissov]

JFTR, I would hate to see int() or str2num() in CSS.

[tabatkins]

Yeah, an explicit parsing function is probably bad. No real need for it. But having something that can retrieve a counter value as a number (rather than going to the extra effort of formatting it as a string) would work. (Same as how attr() has functionality to parse the attr value as a number or dimension.)

[upsuper]

Wouldn't allowing counter() in calc() either ruin any attempt to parallelize styling, or make us need to delay calculating of every numeric value to used-value time?

[Loirooriol]

@upsuper Fair point, counter values are inherited from the immediately preceding element in document order instead of from the parent element as usual. So maybe it would be better to add a sibling-index() function as Tab Atkins proposed in #1869 (comment); it would be less powerful but I think it would cover most usecases.

However, note that the CSS Lists draft currently allows counter() anywhere a is expected, doesn't this have the same problem? If it's possible to use a counter value as a string, it should also be possible to use it as an integer.

[upsuper]

However, note that the CSS Lists draft currently allows counter() anywhere a is expected, doesn't this have the same problem? If it's possible to use a counter value as a string, it should also be possible to use it as an integer.

Firstly, there are a lot fewer places where is accepted, and they are usually relatively less complicated than and its friends when it comes to layout, so expanding them in used-value time (like what is currently done for content property) may not be as bad.

Also, allowing counter() anywhere is allowed is something new. counter() functions are listed as independent item of content property in CSS2. And I'm not aware of any browser who has implemented that anywhere outside content. That means, its feasibility may also be questioned, and my argument above can potentially be apply to that as well.

[upsuper]

Firstly, there are a lot fewer places where is accepted, and they are usually relatively less complicated than and its friends when it comes to layout, so expanding them in used-value time (like what is currently done for content property) may not be as bad.

It may not be as bad, but it could still be very bad. One issue comes to my mind is that can be a , and font-family is inherited, so you may really want to make counter() be expanded in computed-value time (rather than in used-value time like what we do now for content), otherwise it can lead to some funny behavior. This is some case which seems to be neither useful nor easy to implement, which would be a native consequence if we allow counter() be in anywhere is allowed.

I guess we should start this topic in a separate issue, now.

[kizu]

I would really, really love to have counter's value available inside calc(). The syntax I'd propose could be something like counter-value() that would return the counter's value as an integer. Other than the use-cases for sibling-index, this could be used for a lot more cases (not only experimental ones). While I understand that that can be non-trivial to implement, the possibilities it would unlock would be tremendous.

[LeaVerou]

Two more use cases:

• Staggered animations by using it in animation-delay
• Reversing the z-index order by using it in z-index

Regarding syntax, I like @tabatkins's proposal for a new formatting argument, if an explicit syntax is required.
Although IMO ideally it would be nice if we could auto cast number-like strings to numbers in calc() akin to how many programming languages do it (including JS). It's not like strings actually do anything in calc(), so there's no disambiguation problem.

[jonjohnjohnson]

My sad excuse of a utility without this feature...

...
.count--3 { --count: 3 }
.count--4 { --count: 4 }
.count--5 { --count: 5 }
...
.count > :nth-child(1) { --count-current: 1 }
.count > :nth-child(2) { --count-current: 2 }
.count > :nth-child(3) { --count-current: 3 }
...
.el {
  animation-delay: calc((var(--count, 0) - var(--count-current, 0)) * 0.1s);
} 

[faceless2]

I like this in general and I'd love to see it implemented too. But I'd really, really hate implementing it.

All of the paged media layout engines have the same problem with counters, in particular "page" and "pages", although technically it's any counters incremented in the @page margin areas (still a largely theoretical constraint at the time of writing). The moment you hit one of these you have to consider a second layout pass - it's not always required, but for something like span::after { content: counter(pages upper-roman); } you really haven't got much choice.

You need the first layout pass to count the pages, or to work out with certainty which page your element is on (that's more of an issue with target-counter(nnn, page) to be fair). But once you start introducing counters to other properties - say margin-top: calc(counter(pages) * 20px) - you've introduced a loop: layout depends on values computed from an earlier pass of the layout, and so on.

It's not quite as awful for the "page" counter, or any counter other than "pages". But it's still a little complex: orphans: calc(counter(page) * 20) may force a page-break, which would change the value of orphans...

So although I'm not exactly against this, I just wanted to flag that it is almost unfeasibly hairy for some cases. Think of the multiple passes required to stabilise layout for ::first-line, except it's a whole document that needs to be stabilised. These would need to be considered if this goes anywhere.

[LeaVerou]

Won’t we get this for free once we have a function to convert between types, the likes of which has been discussed multiple times?

[brandonmcconnell]

Hey all, as the scope of this issue has changed quite a bit from its original concept/spec, it may be worth considering changing the name on the ticket, so it can be found more easily.

I essentially duplicated the more recent evolution of this issue in #8981.

---

@tabatkins made a good point in my related ticket that using n to reference the n from an nth-child statement wouldn't work well since multiple nth-child statements can be used on a single selector.

One possibility would be to introduce a second optional argument to nth-child for a CSS custom property to assign the iterator value to, like this:

element:nth-child(n + 1, --n) {
  transition: /* ... */;
  --delay: calc(var(--n) * 200ms);
  transition-delay: var(--delay);
}

In either case, we should still discuss all the pros/cons/implications of allowing selectors to also be property-declarative in this way, as this would set a very new precedent not before used in CSS afaik.

Another consideration of using a second argument in those pseudo-selector expressions for this is that it would also beg the question, "Would each :nth-child() second arg value yield a unique value per its expression, or would this iterator value match the nth matched element?"

element:nth-child(n, --m):nth-child(n + 1, --n) {
  /* are `m` and `n` equal?
     it's a bit unclear. */
}

Alternatively, should an iterator require a completely different syntax altogether, such as the following example, where the custom property name is used completely outside the expression itself, after the selector and before the style block?

element:nth-child(n):nth-child(n + 1) --n {
  transition: /* ... */;
  --delay: calc(var(--n) * 200ms);
  transition-delay: var(--delay);
}

[bleper]

@brandonmcconnell, custom properties are intentionally left untouched by the language, so if provide this constant as a variable, then it should be done at the property declaration level: for example, some special value or function nth for the initial value descriptor.

[brandonmcconnell]

@rthrejheytjyrtj545 That makes sense. In that case, it would probably make the most sense as a that needs to be used in a property (standard or custom) with the styles under a selector with an :nth-child() rule, or similar, which would match the nth matched element.

[Loirooriol]

Counters can be modified within all the subtree in abitrary ways. If you just want the element index and sibling count, refer to #4559 instead.

[brandonmcconnell]

@Loirooriol Thanks for pointing me to that issue. Adding my thoughts there. 🙂

[tavin]

It's not possible for counter() to return a string or integer depending on whether it's inside a string expression or calc() expression? I just mean, why counter-value()?

Background: I wanted to initialize a counter using the counter() of another counter...

Related: Has there been discussion anywhere about permitting @property { inheritance: tree-order; } or similar? It would be another way to propagate a value per the same rule that counters follow.

[Loirooriol]

@tavin calc(counter(foo, lower-alpha)) makes no sense. Also it's confusing if the same expression can resolve to entirely different types depending on the context.

[tavin]

@Loirooriol we can debate whether counter(foo) is confusing in a numeric expression, but any idea whether this or even calc(counter-value(foo)) has a real chance of being adopted?

[Loirooriol]

Doesn't seem much likely to happen due to #1026 (comment)

[kizu]

Doesn't seem much likely to happen due to #1026 (comment)

Could something akin to setting up a particular scope for a certain counter help with that?

Similar to how we can use timeline-scope to set up a scope for an animation? So something like a counter-value-scope: foo on a container switching anything that tries to access this particular counter's value inside to this non-parallel/delayed slower mode? This way nothing would be affected by default, and authors couldn't easily “break” the performance of everything, as they would be required to explicitly state which counter should receive this behavior.

[tomasdev]

Alternatively maybe some sort of nth-usage inside calc?

foo:nth-child(n) {
  animation-delay: calc(n) * 20ms; 
}

[Loirooriol]

@tomasdev See #8981, "We cannot make values dependent on what kind of selector they were applied with".
However, in this case you could use animation-delay: calc(sibling-index() * 20ms); which is already in the spec.

[alystair]

@tomasdev See #8981, "We cannot make values dependent on what kind of selector they were applied with". However, in this case you could use animation-delay: calc(sibling-index() * 20ms); which is already in the spec.

Thanks for the update re: sibling-index() @Loirooriol! This would permit me to achieve my intended use showcased in my 2022 comment above. Hope to see it implemented in the future. When used along with sibling-count() it could generate a sort of seed based randomness for artistic use (confetti, etc)... although I hope it works on #foo::before{content:''} elements!

[Loirooriol]

@alystair For randomness, see https://drafts.csswg.org/css-values-5/#randomness

For sibling-*() on pseudo-elements, see #9573

[LeaVerou]

sibling-index() is nice but counter() is more powerful, as it doesn't just count siblings (and can be incremented with any increment). I would much rather see something that works like counter() but produces a number.

[petergoes]

Quite recently we got an upgrade to the attr() function where it now can receive a type() function.
Could the counter() function get a similar upgrade so we could do something like this?

counter(counterName type(>))

Reading through the comments of this issue, I understand that sometimes you can end up in a loop which is undesirable.
As an alternative, could the calc function get an upgrade so we could do something like this:

animation-delay: calc( counter(item) type(>) * 0.5s );

Here the returned value of counter(item) is converted to a by the calc function.

Personally, I would prefer the first option.

[cletusw]

Chrome intends to ship sibling-index() in the next stable version (138)!

https://groups.google.com/a/chromium.org/g/blink-dev/c/opsqx1cBPyc/m/pJaRwh7UAAAJ

[5e-Cleric]

Chrome intends to ship sibling-index() in the next stable version (138)!

https://groups.google.com/a/chromium.org/g/blink-dev/c/opsqx1cBPyc/m/pJaRwh7UAAAJ

The feature is still some ways of reaching its full potential. Whenever the style queries start processing the values of custom properties, we could have something like this with the new ternary operator if():

<body>
    <div>div>
    <div>div>
    <div>div>
    <div>div>
    <div>div>
    <div>div>
body>

body {

   div {
      --number:sibling-index();
      --min: 5;
      --max: 7;
      --value: clamp(0, min(
                  calc((var(--number) - var(--min)) * 1000),
                  calc((var(--max) - var(--number)) * 1000)
               ), 1);

      background:if(style(--value: 1): blue; else: red);
      
   }

}

And you could style ranges of pages "relatively" easily.

This doesn't work because right now style() queries do not compute the custom property, just evaluate the value as a string, so they evaluate the clamp as a string vs the integer as a string.

I hope this is changed in the future.

[Loirooriol]

@5e-Cleric This already works in Chromium Canary, just register the property as : https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13828

[5e-Cleric]

Damn, spent 2h yesterday figuring this out and trying different combinations, i was using counters before i found sibling-index() and custom properties were messing assignment somehow, so i figured they would not allow for the interpretation!

Thanks for that, then, it is indeed a great addition with lots of potential.

(This example in particular was thought because i create documents with markdown+css, and i wanted an easy programatic way to get sections styled)