- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 May 2024 17:02:22 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] view-transition-name determined by element `. <details><summary>The full IRC log of that discussion</summary> <emilio> vmpstr: unique names for transitions is cumbersome because authors need to come up with a bunch of unique names<br> <emilio> ... various proposals<br> <emilio> ... one is to have v-t-n: auto / from-element which matches with element identity<br> <emilio> ... so as long as it doesn't change it works nicely<br> <emilio> ... but it doesn't work with cross-document transitions<br> <emilio> ... and also for frameworks that might replace the dom nodes<br> <emilio> ... another proposal is `element-uuid()` but it's effectively the same as above, just more explicit<br> <emilio> ... another one is `attr()`, which would work for cross-document v-t and frameworks<br> <emilio> ... my proposal would be to do both<br> <khush> q?<br> <emilio> ... leaving attr for more advanced use cases<br> <emilio> q+<br> <astearns> ack fantasai<br> <emilio> fantasai: I think doing both (`auto` / `from-element` and `attr()`) makes sense<br> <emilio> ... there was another idea in the thread which needs more thought<br> <emilio> ... right now we restrict v-t-n to be unique<br> <emilio> ... if it's not it gets ignored or something, it's an error condition<br> <emilio> ... in a bunch of cases, let's say you're reordering a list or so you don't necessarily want to number them all<br> <emilio> ... if we could have multiple names and we could number them somehow automatically that might help<br> <emilio> ... but that might be doable in addition to these things<br> <astearns> ack emilio<br> <fantasai> s/reordering/shifting items after inserting into/<br> <flackr> emilio: my main concern is how likely is it for someone to use from element and not realize it doesn't work for cross document?<br> <flackr> emilio: from where i stand it seems obv it doesn't work, but requires some internals knowledge<br> <astearns> q+<br> <flackr> emilio: just a mild concern, not blocking.<br> <emilio> ack fantasai<br> <Zakim> fantasai, you wanted to answer emilio's question<br> <astearns> ack fantasai<br> <emilio> fantasai: vt has been focused on the fact that you have "pages", and you're changing pages from one page in a web app to another one<br> <emilio> ... but lots of transitions authors can do are single-page<br> <emilio> ... and sometimes view-transitions is the best tool<br> <emilio> ... for those cases this element identity stuff it's not an issue<br> <ydaniv> +1<br> <flackr> emilio: for those use cases this is fine, it just feels like it might be confused<br> <flackr> emilio: or worse the browser could accidentally have a same pointer<br> <flackr> emilio: i guess that's just a bug<br> <emilio> flackr: my comment is somewhat related<br> <astearns> ack flackr<br> <emilio> ... while I agree that attr() should be supported<br> <emilio> ... if the common case is an identity<br> <emilio> ... maybe we can roll it into `auto` in-some cases<br> <emilio> ... so if element has an `id` attribute then `auto` would take that<br> <fantasai> interesting<br> <emilio> ... or an ancestor one or something<br> <emilio> vmpstr: we still need to define for the `auto` cases<br> <emilio> ... we still need some identifier that an author can see<br> <emilio> ... I think the element's uuid is a good choice there<br> <fantasai> -1 to uuid<br> <emilio> ... but we haven't thought too much about it<br> <emilio> q+<br> <fantasai> if the author wants to reference it they should give it a name<br> <khush> q+<br> <fantasai> using the id attribute<br> <emilio> astearns: I think the automatic number is interesting but has a different set of failure modes that it probably could be a separate issue<br> <vmpstr> it's about the param in ::view-transition-group(param) etc, not sure what to put there, or leave it as "auto"?<br> <emilio> ... I wanted to push back a bit, it seems a bit of a smell that people don't want to put unique names in css so we make them put it on the markup?<br> <astearns> ack astearns<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to respond to astearns<br> <emilio> fantasai: a lot of times you have these unique ids already<br> <emilio> ... so you might as well just reuse them<br> <astearns> ack emilio<br> <fantasai> I like flackr's idea of having `auto` take the ID if it has one, and fall back to element identity matching otherwise<br> <flackr> emilio: just want to confirm, allowing attr would make this id mutable in some interesting ways. I guess we have a well defined point where we collect them so it doesn't add much complexity, right?<br> <astearns> q+<br> <flackr> khush: I imagine it's similar to attribute changes requiring recomputing style<br> <flackr> emilio: my point is, if the mutation happens after we start the transition, then presumably it shouldn't count? This detail probably needs to be mentioned<br> <flackr> khush: this is called out already for view-transition-name as it's an issue already for name changes<br> <flackr> emilio: sounds good<br> <flackr> emilio: the auto thing seems like it could use a bit more work since as vmpstr mentioned the name is exposed in the css. My slight preference is to resolve attr and figure out auto later<br> <flackr> emilio: happy to also resolve on auto and resolve the details later<br> <astearns> ack khush<br> <emilio> khush: +1 to fantasai, attr() is useful where you already have unique names for your items without having to use JS<br> <emilio> ... the other thing is, I think we'll have an easier time resolving on attr()<br> <flackr> +1 as well, css is often in a separate file and not unique per element<br> <emilio> ... for auto / from-element vs element-uuid<br> <emilio> ... there was an example where element-uuid could be used to name an ancestor or child of an element rather than auto<br> <emilio> ... auto would only allow to set the id on that element itself<br> <flackr> q+<br> <emilio> ... one other point was that anything that ties with element identity it doesn't work for MPA<br> <emilio> ... we might want to just ignore the name altogether for MPA transitions<br> <emilio> ... so it's harder to miss<br> <emilio> ... but I think we should probably resolve on attr() and work on the other details on transitions<br> <emilio> astearns: I wanted to ask whether it'd make sense to make from-element only work on SPA and reserve auto for something that can work eventually on MPA<br> <emilio> ... so resolve on from-element for now, and opening an issue on an additional auto which does something along the lines that flackr was suggesting<br> <emilio> vmpstr: I don't mind the idea but I'd like a different name that from-element<br> <emilio> ... I'd prefer a different id<br> <astearns> ack astearns<br> <astearns> ack flackr<br> <emilio> ... because from-element seems you're reading something from the element rather than using the element itself<br> <emilio> TabAtkins: can we take it back to the issue? random() has similar use cases and we should make sure they're in sync<br> <emilio> flackr: for auto / from-element it was mentioned that this is exposed<br> <emilio> ... is that necessary?<br> <emilio> ... are there other ways we could do it?<br> <emilio> vmpstr: we can hide it by using auto<br> <emilio> ... we don't currently have the same parameter in the view transition pseudos I don't think it's a problem<br> <emilio> ... the reason we added v-t-c is similar<br> <emilio> ... so I think we can hide it<br> <emilio> flackr: I think you can expose the initial style without a name<br> <emilio> khush: web animations might be weird because you get a list of pseudos and can't differentiate it<br> <emilio> ... any place the name would have appeared then it'd be replaced with auto<br> <emilio> flackr: that's one possibility<br> <emilio> ... maybe there are others<br> <emilio> ... worth exploring<br> <emilio> khush: we use ua css to put styles, we need to figure out how the UA css would work<br> <emilio> flackr: right, but that can be an implementation detail<br> <astearns> ack fantasai<br> <emilio> fantasai: I like flackr's suggestion of auto pulling the id if it has an ID and otherwise uses other way of identity<br> <emilio> q+<br> <emilio> fantasai: I agree we want to expose randomly generated IDs into author CSS<br> <emilio> ... they can given it a name if they need to target something<br> <fantasai> s/want/don't want/<br> <emilio> khush: attr() didn't ship for reasons<br> <emilio> fantasai: let's draft some more concrete proposal<br> <emilio> ... and come back<br> <emilio> vmpstr: vague resolution is fine and we can come back with details<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8320#issuecomment-2113040820 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 May 2024 17:02:23 UTC