- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Oct 2024 15:34:14 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-view-transitions-2] Allow an auto-generated `view-transition-name` that doesn't default to ID``, and agreed to the following: * ``RESOLVED: [Pending async confirmation] `auto` will match elements using their ID attributes, falling back to element identity; `match-element` will only use element identity.`` <details><summary>The full IRC log of that discussion</summary> <fantasai> bramus: This issue is about allowing an auto view-transition-name to be generated by specifying a keyword<br> <fantasai> bramus: a number of keywords suggested, from-element, per-element, self, auto, auto-id<br> <fantasai> bramus: I asked authors "which keyword conveys using ID and falling back to auto-generated" and "which keyword conveys automatically generated"<br> <fantasai> bramus: when I asked which is "automatically generated", they picked "auto"<br> <fantasai> bramus: when I asked about the ID and fallback, the responses ...<br> <fantasai> bramus: We were thinking 'from-element' but authors expected 'auto' for "automatically generated".<br> <fantasai> bramus: we could meet developers by reverting previous resolution about auto reading ID and falling back<br> <fantasai> bramus: and come up with a better keyword<br> <fantasai> bramus: or push authors towards using attr() function which is suited for this, can use attr(id, auto) for fallback behavior<br> <fantasai> bramus: or keep previous resolution of using auto for fallback behavior, but then we need to come up with a very good keyword for the autogeneration<br> <fantasai> bramus: Authors prefer auto-id for autogenerated, and some suggested generated<br> <fantasai> bramus: and some others said, don't we have attr() for this?<br> <bramus> fantasai: we can conclude from the poll that there is cnofusion over keywords<br> <bramus> … wording of poll most likely prompted some of the responses<br> <bramus> … using “automatically generated id” pushed authors towards `auto`<br> <bramus> … internally we are generating one, bu thtat is just the meachism<br> <bramus> … it is an internal detail<br> <bramus> … the will never see it … we might not even generate one and use poitner identity<br> <bramus> … its not about automatically generating ids, its about the identify of the element object<br> <bramus> … poll is propably a but confused on that point<br> <bramus> … could try to come up with good keywords but maybe need some more ideas<br> <bramus> … but doesnt mean that we should revert decision on `auto`<br> <bramus> … in terms of possible keywords: `mathc-elememtn` is an option as we use match in a few other places<br> <bramus> … but open to ideas<br> <astearns> q+<br> <bramus> … at webkit we think `auto` is the right way to define it<br> <khush> q+<br> <astearns> ack fantasai<br> <bramus> … and maybe need other keyword for the other thing<br> <noamr> I like match-element<br> <bramus> astearns: the currently specced behavior for auto is to use the id attr and fall back to auto generated one?<br> <bramus> fantasai: its to use the identity of the element<br> <bramus> … if there is no id, we look at the element being the same object or not<br> <bramus> … in that case, the object hasnt been destroyed - its a singular one that you can map between tree versions<br> <astearns> ack astearns<br> <astearns> ack khush<br> <bramus> khush: spec might say to generate one, but conceptually get the point that that is one way to implement it. you don”t need strings to establish identity<br> <bramus> … of all options maybe self is nice as it doesnt hit at generating something<br> <florian> q+<br> <bramus> … your identtity is the nodes identity<br> <bramus> … auto is confusing. kind of a grab value in css to figure out automatically what to do which is what we doing here as well<br> <astearns> ack florian<br> <fantasai> match-element? same-element?<br> <bramus> florian: explanation fantasai just gave: if that can be used. key point is stability … so maybe akeyword like stable?<br> <bramus> … if the elemen tis still around it will be the same<br> <noamr> q+<br> <bramus> … dont describe what we do but the why<br> <astearns> ack noamr<br> <bramus> noamr: I like match-element. we match not just the id, but the actual elements<br> <bramus> … matching two state of the same element<br> <bramus> q+<br> <khush> i'm ok with match-node or match-element<br> <fantasai> bramus: I like all these suggestions just now, `stable` and `match-element`.<br> <fantasai> bramus: doesn't seem confusing<br> <astearns> ack bramus<br> <fantasai> bramus: `from-element` implies reading from the element, but matching is matching so seems like a good suggestion<br> <fantasai> bramus: wrt `auto` part, as DevRel we can hammer on this point, means "try to get a name" not "automatically generate one"<br> <fantasai> astearns: which method do we expect authors to use most?<br> <fantasai> noamr: It depends<br> <fantasai> noamr: Likely use explicit names. Otherwise likely to use auto, it will just work.<br> <fantasai> noamr: But if they want to specifically say that id attrs don't participate, then use match-element<br> <fantasai> noamr: I think auto would be more common, it will usually just work.<br> <fantasai> noamr: element identity, not observable if generated string<br> <fantasai> astearns: We have a way of using the ID attribute, specifically, by using attr() function<br> <fantasai> astearns: we have defined `auto` to match the element by ID if there is one, or using other methods if not<br> <fantasai> astearns: Is there really a use case for "throw out the IDs and only use the opaque element-matching algorithm" ?<br> <fantasai> khush: Point came up last time, if these are only two (auto and attr(id)), then there's no way to say "I want to match based on element identity even though I put an ID on it"<br> <fantasai> noamr: You wouldn't be able to match if element has an ID in only one of the state<br> <fantasai> khush: or if ID is used for a different reason, and not used in view transitions<br> <fantasai> astearns: I can see the case, but not expecting authors to run into it much<br> <fantasai> noamr: cleaner solution to have specific keywords for each behavior<br> <fantasai> astearns: understand, but that's a theoretical purity argument<br> <fantasai> khush: We heard from one [missed]<br> <astearns> ack fantasai<br> <bramus> fantasai: in terms of the name clashing we might want to consider namespacing ids taken from the element vs names that we put direclty into css<br> <astearns> s/[missed]/AirBnB where teams use ids for entirely different things<br> <bramus> … that would avoid name clasing<br> <bramus> … already have pseudo selelcting syntax but are not using the ! sign for keywords. Could say tha ti fyou pull the id from the attr, then it gets prefixed with the ! sign in the matching.<br> <noamr> q+<br> <bramus> … that would namespace it and avoid clashes<br> <fantasai> s/!/#/g<br> <bramus> astearns: this would be an additional thing<br> <bramus> fantasai: would mean for auto and I guess attr() tha twe are generating the namemt hen you would use v-t-g(#id) to select and style it<br> <bramus> q+<br> <bramus> khush: not sure about this, but maybe could do it for auto-generated ones. Not for those read from attr.<br> <bramus> … will be a pain to keep track of where it came fromg<br> <bramus> fantasai: fair<br> <astearns> ack noamr<br> <bramus> noamr: against namespacing because of flexibility of VTs.<br> <bramus> … take cross-doc VT with #hero id on one side and one with hero v-t-name on other side<br> <bramus> … would want to transition between those<br> <bramus> khush: can open issue separately from this<br> <astearns> ack bramus<br> <fantasai> bramus: Just realized, we could not tackle this problem as part of view transitions, keep auto as it is, and look at the ident() function and allow it to take a keyword<br> <fantasai> bramus: so if you want to auto-generate an ident you use it<br> <bramus> fantasai: so ident() should take wjhat?<br> <bramus> bramus: `view-transition-name: ident(auto)` to auto-generate an ident<br> <bramus> … so we dont have to come up with a keyword for this<br> <bramus> fantasai: but that retrurns an actual observable identifier<br> <bramus> … which we dont think we want to do<br> <bramus> … should still have keyword for it<br> <noamr> q+<br> <bramus> … can consider is distinguishing between auto keyword actually creating a referencable v-t-n or just an internal matching<br> <bramus> … can you selec tagainst the generated identifier is an open question<br> <bramus> … would we do that or just use the id attr to match elements but not to select against it<br> <bramus> … like `::v-t-g(id)`<br> <bramus> khush: would be nice if you could do it for for the `[id]` case<br> <bramus> … pretty convenient<br> <bramus> fantasai: only downside is that we might have namespace clashes and stuff that you are using for identity in the document<br> <bramus> noamr: right, mixing things<br> <bramus> fantasai: can agree on keeping `auto` as it is<br> <bramus> … and for now add a keyword `match-element` for only looking at element id<br> <bramus> … and open issue to mix the namespaces<br> <noamr> q-<br> <fantasai> s/to mix/about mixing/<br> <bramus> astearns: Gonna need async resolution as we are low on people attending<br> <bramus> PROPOSED RESOLUTION: Add `match-element` keyword that will only use element identity and not use id attributes.<br> <bramus> astearns: will be submitted as an async resolution<br> <fantasai> RESOLVED: [Pending async confirmation] `auto` will match elements using their ID attributes, falling back to element identity; `match-element` will only use element identity.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10995#issuecomment-2447567969 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 30 October 2024 15:34:15 UTC