[css-values]: Expose `n` as a `<calc-constant>`

[brandonmcconnell]

Introducing n as a new <calc-constant> with reference access to n value from :nth-child() and similar

1. Introduction

This proposal presents a concept for accessing the n variable as a <calc-constant> for use in CSS math functions like calc()/min()/max()/clamp()/etc. This feature would allow developers to achieve dynamic computation of styles and enable more control over numerical relationships within a stylesheet.

2. Proposal Description

Currently, CSS math functions permit a mix of different types of units, for instance, percentages and pixels, and more recently, pi, e, infinity, and -infinity. This proposal suggests introducing a new <calc-constant> value n to access an iterative n variable within such functions.

The syntax proposed would look as follows:

element:nth-child(n) {
  property: calc(n * 1px);
}

In this case, n is the index of the current element iteration. The property is calculated based on the index number of the current element.

3. Use Cases / Examples

1. Staggered Styles: By providing access to n in the mathematical expressions, we can apply staggered styles to elements. For instance, with animations or transitions, each subsequent element could have a progressively larger delay, giving a "wave" effect.

   .box:nth-child(n) {
     animation-delay: calc(n * 100ms);
   }

2. Dynamic Spacing: You can create dynamic spacing between items in a list or grid by using the n variable to calculate margins or gaps.

   .item:nth-child(n) {
     margin-top: calc(n * 10px);
   }

3. Proportional Dimensions: The width or height of elements could be proportionally determined using n, potentially useful in creating visual hierarchies or pyramid-like structures.

   .bar:nth-child(n) {
     height: calc(n * 5%);
   }

4. Variable Opacity: One could create an interesting visual effect by modifying the opacity of consecutive elements.

   .card:nth-child(n) {
     opacity: calc(n * 0.1);
   }

5. Color Variations: You could use n in calc() for creating color gradients or variations across multiple elements.

   .gradient:nth-child(n) {
     filter: brightness(calc(100% - n * 5%));
   }

4. Considerations

1. Value of n

   There are significant questions around how the value of n should be determined when used in conjunction with an expression such as n + 1 within the :nth-child() pseudo-class. The ambiguity revolves around whether n should be considered as equivalent to the value of n + 1, or if it should reflect the value n would have held without the + 1 expression.

   Options:

   1. Value equal to the total expression

      The first approach considers n as equivalent to the result of the entire expression. In this case, for an element selected with :nth-child(n + 1), the n inside calc() would represent the numeric value equivalent to the actual position of the selected element in the document tree.

      This approach aligns with the intuitive expectation that n represents the selected element's numeric position. However, this method could potentially confuse developers, especially when complex expressions are used within the :nth-child() pseudo-class.

      Example:

      element:nth-child(n + 1) {
        property: calc(n * 1px);  /* n = index of the selected element in the sequence of matched elements */
      }

   2. Value equal to its use in the expression

      The alternative approach interprets n to be the raw value it would have been without the + 1 (or any other expression) in the :nth-child() selector. Here, n represents the iteration count in the sequence of elements, starting from 1, before any expression is applied.

      While this interpretation might be less intuitive initially, it offers developers more precise control over the numerical relationship, and it remains consistent regardless of the complexity of the :nth-child() expression.

      Example:

      element:nth-child(n + 1) {
        property: calc(n * 1px);  /* n = raw iteration count, starting from 1 */
      }

2. Separate variable for matched n sequence count

   Would it also be helpful to have another related constant to the effect of ncount that would represent the total number of elements in the sequence? This constant could be useful for creating dynamic styles that depend on the total number of elements— detecting where the "halfway point" is, for instance, which could also pair well with the mod() function.

   Example:

   element:nth-child(n) {
     /* Calculate height based on position */
     height: calc(1em + mod(n, ncount + 1) * 1em);
   }

5. Conclusion

Introducing the ability to access the n variable within CSS math functions would present developers with a greater range of possibilities for dynamic styling. This addition would provide a powerful tool for creating unique and responsive designs, and it fits well within the already established logical paradigms of CSS.

[tabatkins]

We cannot make values dependent on what kind of selector they were applied with. That information is lost immediately in the cascade; it also makes things like inheritance weird, or setting a value via the OM. It's also simply not well-defined - there can be multiple :nth-child() expressions in a selector.

Exposing a way to access the sibling index of an element is theoretically possible, but would need to be done directly via some new function. We haven't done it so far because it has the side-effect of defeating a lot of style-sharing optimizations, since the styles become more specialized to the precise element they're on.

[bleper]

#1026 covers the same use cases

[brandonmcconnell]

Left my thoughts on the related ticket @rthrejheytjyrtj545 mentioned. Granted that this n idea seems to be a sizable departure from the original heart of that issue.

Would it be better to leave this issue here open, dedicated to this idea, or close this in favor of that one?

Below are the thoughts I shared on that ticket. Only sharing them here as well in response to the other comments left here:

---

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.

---

That's a good point, 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);
}

[Crissov]

I think most use cases presented in this issue and the mentioned counter() issue could be solved new index variables for the n-th any-child and m-th same-child, which can only be accessed and cannot be altered by authors.
Some additional use cases (n-th-last, last, only) would be covered if the total counts of any-sibling and same-sibling were available as well, but my understanding is that these would be rather performance-expensive.

Authors would have to recreate the effective calculations from the counter-* properties or from the :*-child and :*-of-type pseudoclasses within calc(), but in most cases this seems very doable – sometimes further calculation would have been needed anyway.

[brandonmcconnell]

@Crissov Thanks for your response. Could you provide an example of what the syntax for these new "index variables" could look like?

[Crissov]

It’s what @tabatkins said:

Exposing a way to access the sibling index of an element is theoretically possible, but would need to be done directly via some new function.

dt::after {
  content: concat("I’m the ", n, "th of ", cousins, " elements, but the ", m ,"th of ", siblings, " defined terms.");
}

… assuming a calc()-like string function. Otherwise, I assume var() could be reused:

dt::after {
  content: "I’m the " var(n) "th of " var(cousins) " elements, but the " var(m) "th of " var(siblings) " defined terms.";
}

[brandonmcconnell]

@Crissov In those examples, where are the n and m variables defined?

[Crissov]

They would be universally defined in the specification, not in a stylesheet.

[brandonmcconnell]

I guess a quick workaround that would work for simpler nth-style expressions could just be…

:nth-child(1) { --nth-child: 1; }
/* ... */
:nth-child(999) { --nth-child: 999; }

:nth-last-child(1) { --nth-last-child: 1; }
/* ... */
:nth-last-child(999) { --nth-last-child: 999; }

:nth-of-type(1) { --nth-of-type: 1; }
/* ... */
:nth-of-type(999) { --nth-of-type: 999; }

/* etc. */

Although, this could blow up your CSS size if you use some huge limit like 999.

---

Some official and more dynamic implementation of this idea could avoid all this and solved for iterable/incremental values in CSS.

[Loirooriol]

#1026 is about counters, not element indices. Even if the difference may not matter to authors is simple cases, they are an entirely different beast in general.

This is trying to achieve the same as #4559, and I very much prefer #4559 over this for the reasons stated by Tab.

[brandonmcconnell]

@Loirooriol Yes! I just reviewed that issue, and it appears to achieve exactly what I'm going for here, and more simplistically.

Closing this ticket in favor of #4559. Thanks, all!

[tavin]

Sorry to see this closed as having calc() constants x and y for :nth-child(x of ...) and :nth-child(y of ...) would indeed solve a problem I have. This w.r.to a list returned by a selector, hence not answered by counting siblings. Well I can only offer a solution for the disambiguation of n and not for the loss of selector details pointed out by @tabatkins.

[brandonmcconnell]

@tavin have you checked #4559?

Upon further assessment of your comment, I understand that your scope is a bit more specific and would relate more to my original spec.