[css-view-transitions-2] view-transition-name determined by element

[jakearchibald]

Thinking of this example https://codepen.io/jaffathecake/pen/VwBprqL

In this case the developer has to manually give each list item a unique view-transition-name. This could be avoided via something like:

.list-item {
  view-transition-name: element-uuid();
}

Where element-uuid() returns a value unique and constant for that DOM node.

The proposal for CSS random() has a per-element value that could be generalised as element-uuid(). #2826 (comment) (cc @tabatkins)

The downside to this is it would only work for same-document transitions, since element-uuid()s will always be different across documents. It also depends on element usage being consistent, which some frameworks don't always get right.

Edit: This would depend on #8319, otherwise styling the resulting pseudos is impossible.

[mirisuzanne]

As @chriscoyier pointed out recently, this solution doesn't really give authors a way to define transitions for the unique names that are generated. How would an author write ::view-transition-* selectors to target these elements with dynamically generated names? In your example, you use the * name selector, but that would target all view transitions on the page. Ideally, we'd be able to target just list-items. Maybe I'm missing something that already makes that possible?

[jakearchibald]

I think that's a separate feature #8319, but yes, you would need that feature before this one. I should have mentioned it in the OP.

[tabatkins]

I don't think we actually want this to be a generic feature, for a few reasons.

1. As Miriam/[css-view-transitions-2] Creating 'classes' of transition groups #8319 points out, having it be just the randomly-generated identifier isn't actually very useful, and you instead want to be able to group them in some targetable way while giving them unique identities. That's something fairly specific to view-transitions.
2. As @dbaron points out over in the Toggle repo, having computed styles be unique per element defeats some style-sharing optimizations that are pretty nice to keep. In the toggle case, the common case we need to care about is referencing the sibling index of the element, which we can defer resolving until used-value time; I think this would fall into the same bucket, where all you need at computed-value time is the idea that the names are unique in some way, but they don't actually need to become unique until used-value time.

So I instead recommend having view-transitions define a custom way of saying "this thing has a name, but also is unique based on element identity in a way that's not exposed directly but does affect before/after matching". Maybe just view-transition-name: foo unique; or foo per-element?

[jakearchibald]

I'm happy to sit on this one for a bit. #8319 is higher priority.

[noamr]

Suggesting that a solution to this should take #8319 (comment) into account, and build upon #9141 as a way to dynamically generate unique idents.

For example, given a playlist of songs, all of the songs can have a song view-transition-name, but also each one of them needs a unique one (if for example this is a sort animation). So the song would need something like a song-123 name.

The idea in #9141 is to concat it from attributes, e.g. view-transition-name: ident("song-" attr(id)).
The big advantage over using something like element-uuid() is that this can work across documents - you generate the ID from existing HTML data rather than from some internal browser state that can't carry over between documents.

This is also flexible in a way that DOM order can be used instead of attributes, e.g. with the counter() function:
view-transition-name: ident("item-" counter(list-foo)) or any result of a calc: ident("item-" mod(var(--something), 3).

[khushalsagar]

@tdresser shared an interesting observation today, frameworks like React have a concept of a unique key for list items : https://react.dev/learn/rendering-lists#keeping-list-items-in-order-with-key. It seems like instead of a native API, where we can only assume element identify via the corresponding Node, it would be cool to leverage such concepts within the frameworks. Maybe add an API which makes hooking up a custom attribute to the CSS property value easier?

[mirisuzanne]

As someone who is very often not using one of these frameworks, it doesn't feel like a great solution to me.

[jakearchibald]

@mirisuzanne are you otherwise happy with a feature that would only work same-document transitions?

[noamr]

I wonder what people think about an idea like this:

section.list li.item[:id] img { view-transition-name: item-[:id] }

Where the attributes are captured in the selector chain and then used to generate a name.

[mirisuzanne]

Oh, my happiness. Interesting… :)

I'm not actually opposed to a feature that makes it easier for third-party tools to assist in the cross-document functionality. I just hope we also keep working towards a solution that doesn't rely on frameworks?

@noamr I think your proposal still has the cross document issue? Those IDs would be specific to a given document?

[noamr]

Oh, my happiness. Interesting… :)

I'm not actually opposed to a feature that makes it easier for third-party tools to assist in the cross-document functionality. I just hope we also keep working towards a solution that doesn't rely on frameworks?

@noamr I think your proposal still has the cross document issue? Those IDs would be specific to a given document?

You can have elements with the same IDs on the new document, eg if the IDs come from some database.

[bramus]

(#) I wonder what people think about an idea like this:

section.list li.item[:id] img { view-transition-name: item-[:id] }

Where the attributes are captured in the selector chain and then used to generate a name.

Interesting. I like how this allows you to capture an attribute from a parent element and use that on a child. With attr() that’s not immediately possible, unless you jump through some hoops using a custom property.

Two thoughts:

• I would use something different than : to capture it, as it could be confused with pseudos. Am thinking of an @ right now:

  section.list li.item[@id] { … }

• To use it in an ident, I think we’d still need somethink like [css-values] A way to dynamically construct custom-ident and dashed-ident values #9141 to dynamically construct the resulting ident.

  section.list li.item[@id] {
      view-transition-name: ident("item-" @id);
  }

  (Am using @id to refer to the local variable here)

[noamr]

(#) I wonder what people think about an idea like this:
section.list li.item[:id] img { view-transition-name: item-[:id] }
Where the attributes are captured in the selector chain and then used to generate a name.

Interesting. I like how this allows you to capture an attribute from a parent element and use that on a child. With attr() that’s not immediately possible, unless you jump through some hoops using a custom property.

Two thoughts:

• I would use something different than : to capture it, as it could be confused with pseudos. Am thinking of an @ right now:

  section.list li.item[@id] { … }

• To use it in an ident, I think we’d still need somethink like [css-values] A way to dynamically construct custom-ident and dashed-ident values #9141 to dynamically construct the resulting ident.

  section.list li.item[@id] {
      view-transition-name: ident("item-" @id);
  }

Isn't the ident function redundant though? why not "item-" @id or item-(@id) or something like that?

[jakearchibald]

One issue with that syntax is it allows you to capture an attribute named n from only one element in the chain. As in, you can't do: .one[@foo] .two[@foo], because now you have two @foo and no way to differentiate them.

I don't like the naming/syntax here, but you could do something like:

:capture-for-attr(.one, 'one') :capture-for-attr(.two, 'two') {
  view-transition-name: captured-attr('one', 'foo') captured-attr('two', 'foo');
}

:capture-for-attr(selector, name) - where selector is processes as normal, but the selected element is stored as name.

captured-attr(name, attribute) - like attr(), but the first arg is the name of something captured earlier in the selector.

This all feels very complicated though.

[noamr]

I think that if we wanted to support multiple attributes with the same name in the future we could add something like:

.one[@id1:id] .two[@id2:id] { view-transition-name: "something" @id1 @id2 } 

(JS destructuring assignments have the same problem and a similar sollution)

If we go with verbose function-style I'd rather use the more conservative attr+CSS-variables.

[bramus]

A while back I ran a poll (Twitter, Mastodon) asking authors what is missing from View Transitions. Out of the 33 replies, 6 requested this feature, making it the number 1 request (along with retargetable transitions and scoped transitions)

[mirisuzanne]

I'm curious what the .foo[@id] selector syntax adds in this proposal. On the other end, item-[@id] seems like a nice concise syntax equivalent to e.g. item- attr(id, ident)). If we can access attributes as idents (or interpolate them into idents), I'm not sure if the selector-side syntax bring anything new to the equation? Having a value-side shorthand for accessing attributes as idents might still be useful - it's certainly simpler to write.

[noamr]

I'm curious what the .foo[@id] selector syntax adds in this proposal. On the other end, item-[@id] seems like a nice concise syntax equivalent to e.g. item- attr(id, ident)). If we can access attributes as idents (or interpolate them into idents), I'm not sure if the selector-side syntax bring anything new to the equation? Having a value-side shorthand for accessing attributes as idents might still be useful - it's certainly simpler to write.

Which ID would you pick, given:

section[id] > li[id] label * { view-transition-name: item-[@id] }`

Without @ at the selector we'd have to assume that you mean the attribute on the selected element, but that's not always the case.

[jensimmons]

I'm making a simple demo that uses View Transitions to animate enlarging an item that's laid out with CSS Grid, and shifting the other items in the grid around. I was surprised to learn that 1) I have to use JavaScript to use View Transitions, and 2) that I have to give each item in the Grid a unique view-transition-name, and there's no mechanism for applying the functionality to all items.

This caused me to have to write this code:

	.card:nth-child(1) { view-transition-name: card-1; }
	.card:nth-child(2) { view-transition-name: card-2; }
	.card:nth-child(3) { view-transition-name: card-3; }
	.card:nth-child(4) { view-transition-name: card-4; }
	.card:nth-child(5) { view-transition-name: card-5; }
	.card:nth-child(6) { view-transition-name: card-6; }
	.card:nth-child(7) { view-transition-name: card-7; }
	.card:nth-child(8) { view-transition-name: card-8; }
	.card:nth-child(9) { view-transition-name: card-9; }
	.card:nth-child(10) { view-transition-name: card-10; }
	.card:nth-child(11) { view-transition-name: card-11; }
	.card:nth-child(12) { view-transition-name: card-12; }
	.card:nth-child(13) { view-transition-name: card-13; }
	.card:nth-child(14) { view-transition-name: card-14; }
	.card:nth-child(15) { view-transition-name: card-15; }
	.card:nth-child(16) { view-transition-name: card-16; }
	.card:nth-child(17) { view-transition-name: card-17; }
	.card:nth-child(18) { view-transition-name: card-18; }
	.card:nth-child(19) { view-transition-name: card-19; }
	.card:nth-child(20) { view-transition-name: card-20; }
	.card:nth-child(21) { view-transition-name: card-21; }
	.card:nth-child(22) { view-transition-name: card-22; }
	.card:nth-child(23) { view-transition-name: card-23; }
	.card:nth-child(24) { view-transition-name: card-24; }
	.card:nth-child(25) { view-transition-name: card-25; }
	.card:nth-child(26) { view-transition-name: card-26; }
	.card:nth-child(27) { view-transition-name: card-27; }
	.card:nth-child(28) { view-transition-name: card-28; }
	.card:nth-child(29) { view-transition-name: card-29; }
	.card:nth-child(30) { view-transition-name: card-30; }
	.card:nth-child(31) { view-transition-name: card-31; }
	.card:nth-child(32) { view-transition-name: card-32; }
	.card:nth-child(33) { view-transition-name: card-33; }
	.card:nth-child(34) { view-transition-name: card-34; }
	.card:nth-child(35) { view-transition-name: card-35; }
	.card:nth-child(36) { view-transition-name: card-36; }
	.card:nth-child(37) { view-transition-name: card-37; }
	.card:nth-child(38) { view-transition-name: card-38; }
	.card:nth-child(39) { view-transition-name: card-39; }
	.card:nth-child(40) { view-transition-name: card-40; }
	.card:nth-child(41) { view-transition-name: card-41; }
	.card:nth-child(42) { view-transition-name: card-42; }
	.card:nth-child(43) { view-transition-name: card-43; }
	.card:nth-child(44) { view-transition-name: card-44; }
	.card:nth-child(45) { view-transition-name: card-45; }
	.card:nth-child(46) { view-transition-name: card-46; }
	.card:nth-child(47) { view-transition-name: card-47; }
	.card:nth-child(48) { view-transition-name: card-48; }
	.card:nth-child(49) { view-transition-name: card-49; }
	.card:nth-child(50) { view-transition-name: card-50; }

Which is not robust — what if there are more than 50 items on the Grid?? The experience will break.

It seems View Transitions was designed with the expectation that websites are JavaScript first — that it's fine if every items needs to be uniquely named, a developer can just use JS to create all the HTML, and inline styles with JS-created names.

[jensimmons]

This would be a much better solution: .card { view-transition-name: auto; }

[noamr]

This would be a much better solution: .card { view-transition-name: auto; }

See discussion above - the problem with this solution is that it doesn't work for cross-document, or if the framework recreates the element. Generating the name from attributes is perhaps more verbose but works for all those use-cases.

[bramus]

It seems View Transitions was designed with the expectation that websites are JavaScript first

This is only the case for Same-Document View Transitions. For Cross-Document View Transitions JavaScript is not mandatory.

(And, in the future, there could always be worked on defining some non-JS based triggers for Same-Document View Transitions)

This would be a much better solution: .card { view-transition-name: auto; }

While that could solve some Same-Document View Transitions, this solution won’t work for:

• Cross-Document View Transitions.
• Frameworks that trash and re-add nodes as they see fit.

This is also discussed earlier in this thread.

Also see the discussions in #9639 and #9141 which are concerned with solving this naming problem.

[khushalsagar]

Btw the rest of points here also make sense to me.

• Supporting pseudo-elements for the ID based matching approach.
• Providing classes in the name for VT pseudo-elements on script APIs if they don't use explicit naming.

[fantasai]

You might have auto without ID on multiple elements, and now instead of having to give all of them explicit view-transition-name the author would need to set explicit IDs.
It would be annoying if an author used "auto" for element identity based naming, and another teammate adds an id for a completely unrelated use-case which has a side effect of changing VT naming.

I'm not sure I understand the problem. What would break in these cases?

[noamr]

You might have auto without ID on multiple elements, and now instead of having to give all of them explicit view-transition-name the author would need to set explicit IDs.
It would be annoying if an author used "auto" for element identity based naming, and another teammate adds an id for a completely unrelated use-case which has a side effect of changing VT naming.

I'm not sure I understand the problem. What would break in these cases?

Let's say you have an element with view-transition-name: auto. You now changed its ID to hero. If you had another element with view-transition-name: hero explicitly, the view transition will now be invalid. It's not a huge thing though.

[noamr]

I pondered a lot about this one... The main issue I have with auto is that it complicates the model of how the generated pseudos are addressed. Up until now every pseudo was addressable by its name, and now we have to remember "wait what about auto?" every time we add an API that addresses view transition pseudo-elements, like WAAPI, or addressing pseudos in IntersectionObserver.

Given that, I think I prefer the ident(attr()) model, or do something with auto that maintains the string-to-pseudo relationship. For example:

• auto can resolve to an actual unique name that's stable for the same element, and getComputedStyle(element).viewTransitionName can reflect it
• Have an element-uuid() thing like in the original proposal that's usable in other features

[bramus]

I would prefer auto to behave like the suggested element-uuid(), in which it generates a unique ident for the element instead of trying to read the [id] and/or other attributes. Getting the computed value would return that generated ident.

(This might be a stretch but preferably the generated ident should start with auto- to allow script to detect that it was generated)

To get reuse [id] (or any other attribute, except the ones rejected by attr()) as the view-transition-name, authors should use the ident(attr()) approach (originally #9141), which would compliment this auto approach. That ident(attr()) approach would work not only for View Transitions, but for any other property that accepts an ident.

This two-fold approach prevents the potential collision issue detailed earlier in this thread and also allows id-based naming which was also requested before.

[fantasai]

I don't think it's great to expose automatically generated string IDs for elements here. We've never done it before, and I don't think we need to do it here.

auto in CSS tries to "use context to do the right thing". I think in this case reflecting the element's ID, if it has one, is pretty obviously the right thing to do given context. Wrapping functions within functions in order to be super explicit about exactly how we're doing the right thing is how programming languages work, but this is CSS: we use keywords to express concepts, and make the browser do the work.

For the cases where the element doesn't have an ID, then auto-generating something to represent the element's identity is the obvious and reasonable fallback. But I don't think we should be exposing this as a string. It should remain internal to the implementation. If the author wants to style these elements, they can use view transition classes. If they wanted to target it individually, they would have given it an individual name.

[khushalsagar]

^ I'm ok with figuring out a way to avoid exposing generated strings. The CSS targeting being limited to view transition classes seems reasonable, we'll need something reasonable to use for pseudo element strings in script APIs (maybe just ::view-transition-*(auto)?

auto in CSS tries to "use context to do the right thing". I think in this case reflecting the element's ID, if it has one, is pretty obviously the right thing to do given context. Wrapping functions within functions in order to be super explicit about exactly how we're doing the right thing is how programming languages work, but this is CSS: we use keywords to express concepts, and make the browser do the work.

My worry with using ID if available is the subtlety of it which is so not obvious with a keyword like "auto". Someone not working on view transitions at all could add an id to a node for a completely unrelated reason and not realize the side-effect it would have on view transitions. The worst being that the ID happens to collide with an existing view transition name, resulting in a collision which is an error. @vmpstr had a good idea of namespacing auto generated vs explicit names such that the view-transition-name: foo won't match with view-transition-name: auto on an element with id foo. With that, I'm ok if we take this route.

That said, if there's other use-cases for ident(attr()) that will allow authors to explicitly derive the name from ID anyway, then I don't see the advantage of auto also doing it implicitly.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-2] view-transition-name determined by element , and agreed to the following:

• RESOLVED: Add three keywords, one for ID attribute, one for element identity, and one that does fallback between the two.

The full IRC log of that discussion

<TabAtkins> bramus: Right now we require a unique VT name for every element
<TabAtkins> bramus: A bit cumbersome for authors, if you have 40 cards on the page that participate, they each need a unique name
<TabAtkins> bramus: A lot of input in the thread
<TabAtkins> bramus: To summarize, our conclusion seems to be needing some way to auto-name the element
<TabAtkins> bramus: Right now, value is "auto", with details still a little uncertain
<TabAtkins> bramus: Two suggestions - auto uses the ID if it has one, or else generates a unique internal ident.
<TabAtkins> bramus: Second is to just go straight to unique internal ident
<TabAtkins> bramus: Reason for second path is if the author has ID on the element, like <div id=hero>, it will use "hero" as its name. If someone later explicitly uses "hero" as the VT name, it'll clash
<TabAtkins> bramus: I think that's where we're at. In addition to "auto" only being able to generate unique ids, there's a proposal for an ident() function that can be used like ident(attr(foo)), to produce an ident from an arbitrary attribute
<vmpstr> q?
<TabAtkins> bramus: So options are "auto" tries to use ID, otherwise generates unique. Second is we just only do unique. And then for either, maybe give authors ability to take name from a different attribute.
<TabAtkins> khush: Elika left good points on the issue.
<TabAtkins> khush: I'm less a fan of deriving from ID for two reasons. One, can be a bit of a surprise if author isn't expecting the ID to be used, not obvious. Can cause unintended collisions.
<TabAtkins> khush: Tho talking with Vlad, if that's a showstopper we can namespace explicit vs ID-derived names.
<TabAtkins> khush: If we do decide on being able to use any attribute as the name, I'm more not in favor of auto doing it automatically. Author can just do it explicitly.
<astearns> ack fantasai
<TabAtkins> (Agree with that, ident() seems fine, or attr(foo ident), whatever.)
<TabAtkins> fantasai: The reason to have "auto" use the ID by default and fallback if needed is it allows author to rely on IDs in the markup that are already created, if that exists.
<TabAtkins> fantasai: If you can only do it explicitly, you have to know there is an ID on that element.
<TabAtkins> (I mean, `.foo[id] { v-t-name: attr(id ident); }`)
<TabAtkins> fantasai: LIke, as an author, you want an elment to transition, and if you have an ID it'll transition even if it's moving around the document or something.
<TabAtkins> fantasai: Should be something that works with a single keyword.
<TabAtkins> fantasai: If the element exists in both trees they probably want it to identify with itself.
<TabAtkins> fantasai: shoudln't make the author do additional work
<vmpstr> q+
<TabAtkins> astearns: Would it help if the attr method is invalid if the ID doesn't exist? So you can set auto on everything, and for the things you want to use an ID, use the function; it'll fallback.
<khush> q+
<TabAtkins> fantasai: So you're proposing two keywords, one that uses ID if possible with fallback to element identity, and the ohter that just uses element identity
<TabAtkins> fantasai: that's fine with me
<TabAtkins> fantasai: I just want things to work by default
<TabAtkins> fantasai: Matching up obvious things seems obvious
<astearns> ack vmpstr
<TabAtkins> vmpstr: I agree with the last point, not making author do extra work. I think there are edge cases that might not be common, where an element matches by ID, but the ID attr is removed - do we continue matching by identity?
<TabAtkins> vmpstr: I worry there's a little magic, like if you remove the element and add it back, it works *if* you had an ID on it, but not if you relied on identity.
<fantasai> `auto` is the keyword of magic!
<TabAtkins> vmpstr: Maybe that's something we can overcome with dev education
<bramus> q+
<TabAtkins> vmpstr: I think there are other things we might want to match on, like being selected
<TabAtkins> vmpstr: So I think having an attr is useful
<TabAtkins> q+
<astearns> ack khush
<TabAtkins> khush: I like the idea of two explicit keywords
<TabAtkins> khush: And maybe "auto" that magically chooses between the two, if it's not the initial value.
<TabAtkins> khush: We can make it pretty explicit int he property description
<TabAtkins> khush: So I'd be fine with "auto" as the name, if the behaviors were chooseable separately.
<TabAtkins> astearns: So you're proposing three keywords?
<TabAtkins> khush: The ability to draw from an attribute is somethign proposed generically
<astearns> ack bramus
<TabAtkins> khush: So three things (tho not necessarily keywords)
<fantasai> wfm
<TabAtkins> bramus: One thing for proposed ident() function, this doesn't just apply to v-t-name, but anywhere that takes an ident
<TabAtkins> bramus: So that's why I'm a big fan, it's not focused on only VT.
<astearns> ack TabAtkins
<fantasai> scribe+
<fantasai> TabAtkins: Haven't read entire thread, very long, but
<fantasai> TabAtkins: sounds like we want multiple strategies, and if one doesn't work, we fall back
<fantasai> TabAtkins: so can we do comma-separated?
<fantasai> TabAtkins: then we could allow future things, like use the selected thing (?)
<fantasai> TabAtkins: Then we can have strategies for marking and matching view transitions
<vmpstr> +1
<khush> sgtm
<TabAtkins> bramus: commas seem a bit weird?
<fantasai> bramus: commas seem a bit weird, e.g. animation-name, [missed]
<TabAtkins> bramus: If you do commas in animation-name, both names apply
<fantasai> bramus: view-transition-name: x, y
<fantasai> vmpstr: we could do space separated
<fantasai> TabAtkins: we use commas for lists of stuff, helps allow future syntax evolution
<fantasai> TabAtkins: problem with the counter properties because they didn't have commas
<fantasai> vmpstr: This isn't something we're thinking of doing today, but at some point we considered having multiple view transition names
<fantasai> vmpstr: so that same element can morph into multiple
<fantasai> vmpstr: so prefer space separation for that reason
<fantasai> TabAtkins: fine with that
<fantasai> TabAtkins: I doubt any syntax evolution here, it's just a name
<fantasai> TabAtkins: so fine to do space separation, I just default to commas
<astearns> ack fantasai
<TabAtkins> fantasai: I think multiple keywords are a bit more cognitive overhead if there's really only two things that are fallbacks
<TabAtkins> fantasai: I think having auto keyword doing that makes the most sense
<TabAtkins> (we've already discussed more than two behavior in this convo)
<TabAtkins> fantasai: So I think having just "auto" doing the two fallbacks makes the most sense. If we have more behaviors in the future we can add it
<TabAtkins> astearns: Tab said we already had more discssuion
<TabAtkins> fantasai: Like what?
<TabAtkins> TabAtkins: The selected element between two trees
<TabAtkins> vmpstr: Specifically, just some element with a particular class in both trees
<TabAtkins> fantasai: Isn't that what selectors are for?
<TabAtkins> fantasai: If you want to choose one attribute if it's .foo, another with .bar, we can do that with selectors
<TabAtkins> (tbf that same argument applies to ID, tho the possible common-ness of ID use is still an argument in favor)
<TabAtkins> astearns: If we go with "auto" for now, nothing stops us from allowing multiple fallbacks in the future
<TabAtkins> +1
<fantasai> +1
<khush> q+
<TabAtkins> astearns: So I'd like to propose we have three values - one that uses the ID, one that uses element identity, and "auto" that uses ID then falls back to identity
<astearns> ac khush
<astearns> ack khush
<TabAtkins> khush: For using a keyword for ID, is that something we want to do in other naming properties? Or is it VT specific?
<fantasai> PROPOSED: Introduce keyword for element identity, some other syntax for using the element's ID, and auto keyword that switches between the two
<TabAtkins> fantasai: I think that's a good question. A challenge is we have two different concepts for "id" and "identity" that's hard to distinguish in explanation.
<TabAtkins> fantasai: We could extend this to other properties possibly. Other properties have more referencing, might be a bit less useful.
<TabAtkins> fantasai: You name the thing, *and* refer to it from other elements. In that case the CSS needs to know the name anyway.
<khush> that's fair
<TabAtkins> fantasai: VT is a case where you don't need to know the name, you can reference it just via classes.
<TabAtkins> fantasai: If we introduce an ident() it should have its own issue
<TabAtkins> bramus: #9141
<TabAtkins> fantasai: If we do it shoudl be generic across CSS
<TabAtkins> vmpstr: Still just one keyword to specify? No fallback list?
<TabAtkins> fantasai: Yes. Three new keywords, but only use one at a time.
<TabAtkins> astearns: the ident() function isn't part of this issue, will be a different discussion
<TabAtkins> astearns: So three new keywords, use one at a time. Objections?
<TabAtkins> bramus: If we do ident() elsewhere, do we need the third keyword now? Will that be affected?
<fantasai> PROPOSED: Introduce keyword for element identity, some other syntax for using the element's ID, and auto keyword that switches between the two
<TabAtkins> fantasai: This'll be whatever the markup language defines as the element identifier, "id" in html
<flackr> q+
<TabAtkins> fantasai: xml:id in XML
<TabAtkins> flackr: The function for using element's ID, is that differetn from attr()
<fantasai> TabAtkins: proposal here is to have a specialized keyword that uses the ID
<fantasai> TabAtkins: could *also* allow the ident() function
<fantasai> flackr: and attr() would be a separate solution
<fantasai> fantasai: currently no-one implements ident-generating attr(), only string-generating attr()
<TabAtkins> RESOLVED: Add three keywords, one for ID attribute, one for element identity, and one that does fallback between the two.

[nt1m]

Fwiw, it was mentioned multiple times in this thread, but I do not think we should be introducing ident(), attr() takes a type argument already that can be set to ident in css-values-4. So attr(data-vt-id ident) should theoretically work.

[bramus]

Fwiw, it was mentioned multiple times in this thread, but I do not think we should be introducing ident(), attr() takes a type argument already that can be set to ident in css-values-4. So attr(data-vt-id ident) should theoretically work.

I included your comment in the ident() issue and left a reply over there: #9141 (comment)

[noamr]

@nt1m I like from-element that you suggested for the other keyword that doesn't respect ID. I think for a keyword that only respects ID perhaps attr(id ident) when we introduce that is sufficient? If we want to make it less ugly it can simply be id.

[nt1m]

@noamr Are you planning to also add from-element ?

[noamr]

@noamr Are you planning to also add from-element ?

Yea, though we haven't resolved on the name. Happy to have an async resolution for that one.

[bramus]

One thing I don’t like about from-element is that it reads like “read the id from the element” which authors will interpret as “read the id attribute from the element”. Ideally the value makes it clear that it’s an internal id, unrelated to the id attribute.

I think element-uuid as suggested in the OP comes closest to this.

[noamr]

One thing I don’t like about from-element is that it reads like “read the id from the element” which authors will interpret as “read the id attribute from the element”. Ideally the value makes it clear that it’s an internal id, unrelated to the id attribute.

I think element-uuid as suggested in the OP comes closest to this.

How about view-transition-name: self? It implies that it's some identity without being specifically about ID.

[khushalsagar]

I like the self suggestion for the node identity based name. We need a keyword for the "for-id" version as well?

[noamr]

I like the self suggestion for the node identity based name. We need a keyword for the "for-id" version as well?

I think attr(<ident> id) is perhaps good enough for that?