-
Notifications
You must be signed in to change notification settings - Fork 661
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-view-transitions-2] view-transition-name determined by element #8320
Comments
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 |
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. |
I don't think we actually want this to be a generic feature, for a few reasons.
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 |
I'm happy to sit on this one for a bit. #8319 is higher priority. |
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 The idea in #9141 is to concat it from attributes, e.g. This is also flexible in a way that DOM order can be used instead of attributes, e.g. with the |
@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? |
As someone who is very often not using one of these frameworks, it doesn't feel like a great solution to me. |
@mirisuzanne are you otherwise happy with a feature that would only work same-document transitions? |
I wonder what people think about an idea like this:
Where the attributes are captured in the selector chain and then used to generate a name. |
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. |
Interesting. I like how this allows you to capture an attribute from a parent element and use that on a child. With Two thoughts:
|
Isn't the |
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: 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');
}
This all feels very complicated though. |
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. |
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) |
I'm curious what the |
Which ID would you pick, given: section[id] > li[id] label * { view-transition-name: item-[@id] }` Without |
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 This caused me to have to write this code:
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. |
This would be a much better solution: |
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. |
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)
While that could solve some Same-Document View Transitions, this solution won’t work for:
This is also discussed earlier in this thread. Also see the discussions in #9639 and #9141 which are concerned with solving this naming problem. |
Btw the rest of points here also make sense to me.
|
I'm not sure I understand the problem. What would break in these cases? |
Let's say you have an element with |
I pondered a lot about this one... The main issue I have with Given that, I think I prefer the
|
I would prefer (This might be a stretch but preferably the generated ident should start with To get reuse 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. |
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.
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. |
^ 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
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 That said, if there's other use-cases for |
The CSS Working Group just discussed
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. |
Fwiw, it was mentioned multiple times in this thread, but I do not think we should be introducing |
I included your comment in the |
@nt1m I like |
`auto` resolves to either the element's ID, or to a unique identifier that is stable for the duration of the transition and is not web-observable. Resolution: w3c#8320 (comment) Closes w3c#8320
* [css-view-transitions-2] Allow `auto` as a keyword `auto` resolves to either the element's ID, or to a unique identifier that is stable for the duration of the transition and is not web-observable. Resolution: #8320 (comment) Closes #8320 * Fix refs * Tighten definition of unique string * Update css-view-transitions-2/Overview.bs Co-authored-by: Khushal Sagar <[email protected]> * Handle scoping * Change scoping text * Change scoping text * Update Overview.bs Co-authored-by: Khushal Sagar <[email protected]> --------- Co-authored-by: Khushal Sagar <[email protected]>
* [css-view-transitions-2] Allow `auto` as a keyword `auto` resolves to either the element's ID, or to a unique identifier that is stable for the duration of the transition and is not web-observable. Resolution: w3c#8320 (comment) Closes w3c#8320 * Fix refs * Tighten definition of unique string * Update css-view-transitions-2/Overview.bs Co-authored-by: Khushal Sagar <[email protected]> * Handle scoping * Change scoping text * Change scoping text * Update Overview.bs Co-authored-by: Khushal Sagar <[email protected]> --------- Co-authored-by: Khushal Sagar <[email protected]>
@noamr Are you planning to also add |
Yea, though we haven't resolved on the name. Happy to have an async resolution for that one. |
One thing I don’t like about I think |
How about |
I like the |
I think |
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:Where
element-uuid()
returns a value unique and constant for that DOM node.The proposal for CSS
random()
has aper-element
value that could be generalised aselement-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.
The text was updated successfully, but these errors were encountered: