[css-values] A way to dynamically construct custom-ident and dashed-ident values

[bramus]

(This proposal has some overlap with #542, but that one is specifically about string concatenation. This proposal is about using concatenation to construct custom-idents and dashed-idents)

In many CSS features, authors need to give elements a certain name so that they can later refer to those targeted elements. Think of container-name, view-transition-name, view-timeline-name, scroll-timeline-name, etc. Depending on the property these names are of the type <custom-ident> or <dashed-ident>. These names need to be unique (within the feature that’s being used). In case of View Transitions and Scroll-Driven Animations this uniqueness can become burden for authors.

Take this Scroll-Driven Animations example, where the author is setting a unique timeline name per element, using :nth-child():

.parent {
  timeline-scope: --tl-1, --tl-2, --tl-3;
}

nav {
  li:nth-child(1) { animation-timeline: --tl-1; }
  li:nth-child(2) { animation-timeline: --tl-2; }
  li:nth-child(3) { animation-timeline: --tl-3; }
}

main {
  div:nth-child(1) { view-timeline: --tl-1; }
  div:nth-child(2) { view-timeline: --tl-2; }
  div:nth-child(3) { view-timeline: --tl-3; }
}

Same with View Transitions, where I’ve seen this code in the wild

        &:nth-child(1) {
          view-transition-name: opt-1;
          & > label {
            view-transition-name: opt-1-label;
          }
          & > input {
            view-transition-name: opt-1-input;
          }
        }
        &:nth-child(2) {
          view-transition-name: opt-2;
          & > label {
            view-transition-name: opt-2-label;
          }
          & > input {
            view-transition-name: opt-2-input;
          }
        }
        &:nth-child(3) {
          view-transition-name: opt-3;
          & > label {
            view-transition-name: opt-3-label;
          }
          & > input {
            view-transition-name: opt-3-input;
          }
        }

To make things easier for authors, it would be nice if they could dynamically construct <custom-ident> or <dashed-ident> values. I am thinking of two functions:

• ident(…) to generate a <custom-ident> value
• dashed-ident(…) to generate a <dashed-ident> value

The functions can accept an arbitrary number of arguments, but need at least 1. The arguments are of the type <string> or a function that generates string-like values (*).

With sibling-index() being accepted, the first example could be simplified as follows:

nav li {
  animation-timeline: dashed-ident("tl-", sibling-index()); }
}

main div {
  view-timeline: dashed-ident("tl-", sibling-index());
}

Ideally, the output of calc() and attr() would also be allowed as arguments into the proposed functions.

(*) Maybe this last part needs an explicit cast to string, which is covered in #542. Or ff the casting of the arguments would be too difficult to do, maybe some value interpolation could be used? In that case the functions would accept only 1 argument, e.g. dashed-ident("tl-{sibling-index()}").

[argyleink]

yes! i have many use cases for this 🙂
it would really DRY up my styles.

i asked about this at the end of presenting sibling-index(), thank you so much for formalizing it and articulating the space so well 🙏🏻

[bramus]

While building https://codepen.io/bramus/pen/mdabWzr earlier today I came to the realisation that sibling-index() won’t cut it in the case of View Transitions. If one, for example, inserts a node in a list at position x then all indexes after that position would get shifted, essentially breaking the View Transition for all those elements.

Instead, something like random() should be used, as that one is able to generate a value per element. However, it might lead to clashes in case it generates the same value twice, so it’s not 100% closing. Maybe we also need something like unique() as that is guaranteed to not generate duplicate values.

All this to say that my initial “Ideally, the output of calc() and attr() would also be allowed as arguments into the proposed functions.” might be a requirement from the start.

[noamr]

I love this! especially for #8320, in conjunction with #8319.
A few nits:

• Not sure if it needs to be dashed-ident or simply ident() that joins whatever it gets, strings or attributes
• For concatenation I would use space separation rather than comma, the same way concatenation works for content

e.g.:

ident("song" attr(id) "-" counter(foobar)) would return e.g. song300-1

[vmpstr]

Might also consider something like an iota() that would just be a single :root-level counter that increments after each use. I like leaning into counters here, since we need to be a bit careful about style containment.

unique() works too though

[bramus]

(#) Not sure if it needs to be dashed-ident or simply ident() that joins

I split out both because they return a different value. But I think I am misunderstanding what you are saying here.

(#) For concatenation I would use space separation rather than comma, the same way concatenation works for content

Good suggestion!

(#) All this to say that my initial “Ideally, the output of calc() and attr() would also be allowed as arguments into the proposed functions.” might be a requirement from the start.

Since attr() comes with its own set of challenges, authors initially can work around it by setting a custom prop to some sort of identifier, and use that in ident(). For example:

#item-x { --id: x; }
#item-y { --id: y; }
#item-z { --id: z; }

.item
    view-transition-name: ident("item-" var(--id));
}

[LeaVerou]

I’m not sure if the best solution is a way to construct dynamic idents, or just better scoping for these features. E.g. what if nesting these inside other rules also scoped their idents?

With dynamic idents authors still need to think of a way to ensure uniqueness, which increases cognitive overhead, and is error prone.

[noamr]

I’m not sure if the best solution is a way to construct dynamic idents, or just better scoping for these features. E.g. what if nesting these inside other rules also scoped their idents?

Can you please elaborate? I don't fully understand.

With dynamic idents authors still need to think of a way to ensure uniqueness, which increases cognitive overhead, and is error prone.

In light of #8319, the ident itself doesn't have to be unique (for view transitions).
I get the issues with this but not the alternative (yet).

Right now authors still need to ensure uniqueness but they have to do that with JS or on the server, this allows them to do this in css directly. Happy to discuss alternatives!

[bramus]

(#) I’m not sure if the best solution is a way to construct dynamic idents, or just better scoping for these features. E.g. what if nesting these inside other rules also scoped their idents?

Can you please elaborate? I don't fully understand.

I think @LeaVerou means that if names could be contained/scoped by whatever trigger, that would open up the way to safely allow duplicate names to exist alongside each other.

While that would work in some cases – i.e. where children look up the DOM tree to get access to a thing with a certain name – it does not work when all those named items are part of bigger whole.

For example: View Transitions with many cards still need a unique name on each card as they all participate in the same VT, or ScrollTimelines that all need to be hoisted up to a shared parent via timeline-scope, same with anchoring, etc.

(#) With dynamic idents authors still need to think of a way to ensure uniqueness, which increases cognitive overhead, and is error prone.

They already need to think about uniqueness in many cases (names for view-transition elements, containers, timelines, anchors, custom properties, etc). The solution that is pursued here would allow authors to dedupe a lot of repetitive uniqueness.

E.g. things like this:

/* This requires uniqueness in HTML and CSS */
#item-1 { --item-id: item-1; }
#item-2 { --item-id: item-2; }
#item-3 { --item-id: item-3; }
#item-4 { --item-id: item-4; }

/* This requires uniqueness only in HTML, as CSS can access those values */
.item { --item-id: ident(attr(id)); }

[noamr]

@bramus what does the ident() function add here? Why not use strings, and turn it into an ident automatically when the property expect an ident (e.g. view-transition-name)

[bramus]

Parsing purposes. Think of shorthands, such as scroll-timeline.

With ident():

• scroll-timeline: inline ident("tl-" var(--id))
• scroll-timeline: ident("tl-" var(--id)) inline

Without ident():

• scroll-timeline: inline "tl-" var(--id)
• scroll-timeline: "tl-" var(--id) inline

[noamr]

Parsing purposes. Think of shorthands, such as scroll-timeline.

With ident():

• scroll-timeline: inline ident("tl-" var(--id))
• scroll-timeline: ident("tl-" var(--id)) inline

Without ident():

• scroll-timeline: inline "tl-" var(--id)
• scroll-timeline: "tl-" var(--id) inline

Sure, though perhaps these can work without the ident function when it's not in a shorthand.

scroll-timeline-axis: inline;
scroll-timeline-name: "tl-" var(--id);
/* or */
scroll-timeline: inline ident("tl-" var(--id));