Re: [csswg-drafts] [css-view-transitions-2] view-transition-name determined by element (#8320)

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>
&lt;fantasai> noamr: Automatically generating names<br>
&lt;fantasai> noamr: Proposal from Apple to do 'auto'<br>
&lt;fantasai> noamr: Previous agreement was to also come up with a proposal around attr()<br>
&lt;fantasai> noamr: so I think we should move forward with 'auto' for now<br>
&lt;fantasai> noamr: The thing that wasn't clear in proposal, it creates pseudos without names, so how can you animate them?<br>
&lt;fantasai> noamr: these are nameless pseudos that you can style with CSS<br>
&lt;fantasai> fantasai: That's what view-transition-class is for, right?<br>
&lt;khush> q+<br>
&lt;fantasai> noamr: but you can't grab them with element.animate<br>
&lt;fantasai> noamr: unless we add an API to get via view-transition-class<br>
&lt;Rossen2> ack fantasai<br>
&lt;Rossen2> ack fantasai<br>
&lt;Rossen2> ack khush<br>
&lt;fantasai> khush: we conceptually convinced ourselves that if you need to do specific targetting, then use explicit names<br>
&lt;fantasai> khush: but if you want to "do this to all with view-transition-class", proper way to do in script would be to use pseudo-elements<br>
&lt;fantasai> khush: and grab them with that<br>
&lt;fantasai> khush: I don't think we need to block on that, but could allow for extension later<br>
&lt;fantasai> +1<br>
&lt;flackr> +1<br>
&lt;flackr> there are a lot of things that you can't do without the PseudoElement interface<br>
&lt;fantasai> noamr: Also ok if some things not supported for auto because it's a convenience feature. Can always fall back to generate view transition names if you want to do something specific<br>
&lt;fantasai> noamr: what was worrying me about auto was that you start using it and then realize you need to generate names later<br>
&lt;fantasai> noamr: but it's a trade-off<br>
&lt;fantasai> ntim: could name it differently, to make restrictions more explicit<br>
&lt;fantasai> noamr: maybe better as a function?<br>
&lt;fantasai> ntim: it could be another keyword, e.g. from-element or something<br>
&lt;vmpstr> we then would have to exclude the new name from valid view-transition-names (auto is already excluded)<br>
&lt;fantasai> ntim: it's very similar to the view() function ...<br>
&lt;fantasai> s/ntim/noamr/<br>
&lt;TabAtkins> fantasai: I think they're quite different.<br>
&lt;TabAtkins> fantasai: view does do lookup to the element itself, but so do other features<br>
&lt;TabAtkins> fantasai: for 'auto' i think some of the restrictions you wer ediscussing, like not working for cross -document, there was some discussion in the issue of using the ID of the element if it has one<br>
&lt;TabAtkins> fantasai: I think that makes sense to build in, so we don't necessarily have to restrict it from cross-doc transitions<br>
&lt;TabAtkins> fantasai: I think what you could say is if the leement has an ID, identify it by that. If the element is recreated, you're mapping across the change. If it doesn't have an ID, you use the object identity, and that doesn't work cross-docuemnt<br>
&lt;TabAtkins> noamr: I think that works. But you can style a shadow part<br>
&lt;TabAtkins> noamr: like my-slider::part(inner-bar)<br>
&lt;Rossen2> ack fantasai<br>
&lt;TabAtkins> noamr: Right now the only way to style things in web components is to use parts, those are also uniquely identifiabl eby ID+part name<br>
&lt;TabAtkins> noamr: So we can say auto means ID and ID+part, and if that doesn't exist use object identity<br>
&lt;TabAtkins> noamr: And then some APIs still aren't resolved, you can't reach that element<br>
&lt;TabAtkins> fantasai: Yeah that's fine<br>
&lt;TabAtkins> (makes enough sense to me)<br>
&lt;fantasai> Rossen2: from privacy / security point of view, are we OK?<br>
&lt;TabAtkins> Rossen2: from priv/sec, have we thought about what using those IDs mean?<br>
&lt;khush> q+<br>
&lt;fantasai> noamr: doesn't really expose anything... it's like selectors<br>
&lt;fantasai> Rossen2: cross-doc?<br>
&lt;fantasai> noamr: this is same-origin<br>
&lt;fantasai> noamr: the whole security around cross-document transitions is baed on same-origin<br>
&lt;fantasai> noamr: exposing view-transition-name and ID is same in that regard<br>
&lt;Rossen2> ack khush<br>
&lt;fantasai> khush: trying to understand the ID proposals<br>
&lt;fantasai> khush: so it sounds like we'd have different layers of names now<br>
&lt;fantasai> khush: explicitly named is one, then IDs, then shadow DOM<br>
&lt;vmpstr> q+<br>
&lt;noamr> q+<br>
&lt;fantasai> khush: I'm curious if we've seen enough use cases for cross-document to go down this rabbit-hole, rather than limiting to same-document<br>
&lt;fantasai> khush: also some script APIs where where you need a string to identify<br>
&lt;fantasai> khush: our goal is to give you something, but not uniquely identify the pseudo-element<br>
&lt;fantasai> khush: what name do we use when we give a name for these in our script APIs?<br>
&lt;vmpstr> q-<br>
&lt;fantasai> noamr: seems a lot of details to work out, but made good progress. I'l summarize in issue<br>
&lt;fantasai> Rossen2: ok, let's end here and pick up again next week<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-2248497781 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 24 July 2024 16:59:57 UTC