- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Sep 2024 17:00:22 +0000
- To: public-css-archive@w3.org
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.`
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> bramus: Right now we require a unique VT name for every element<br>
<TabAtkins> bramus: A bit cumbersome for authors, if you have 40 cards on the page that participate, they each need a unique name<br>
<TabAtkins> bramus: A lot of input in the thread<br>
<TabAtkins> bramus: To summarize, our conclusion seems to be needing some way to auto-name the element<br>
<TabAtkins> bramus: Right now, value is "auto", with details still a little uncertain<br>
<TabAtkins> bramus: Two suggestions - auto uses the ID if it has one, or else generates a unique internal ident.<br>
<TabAtkins> bramus: Second is to just go straight to unique internal ident<br>
<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<br>
<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<br>
<vmpstr> q?<br>
<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.<br>
<TabAtkins> khush: Elika left good points on the issue.<br>
<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.<br>
<TabAtkins> khush: Tho talking with Vlad, if that's a showstopper we can namespace explicit vs ID-derived names.<br>
<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.<br>
<astearns> ack fantasai<br>
<TabAtkins> (Agree with that, ident() seems fine, or attr(foo ident), whatever.)<br>
<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.<br>
<TabAtkins> fantasai: If you can only do it explicitly, you have to know there is an ID on that element.<br>
<TabAtkins> (I mean, `.foo[id] { v-t-name: attr(id ident); }`)<br>
<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.<br>
<TabAtkins> fantasai: Should be something that works with a single keyword.<br>
<TabAtkins> fantasai: If the element exists in both trees they probably want it to identify with itself.<br>
<TabAtkins> fantasai: shoudln't make the author do additional work<br>
<vmpstr> q+<br>
<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.<br>
<khush> q+<br>
<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<br>
<TabAtkins> fantasai: that's fine with me<br>
<TabAtkins> fantasai: I just want things to work by default<br>
<TabAtkins> fantasai: Matching up obvious things seems obvious<br>
<astearns> ack vmpstr<br>
<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?<br>
<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.<br>
<fantasai> `auto` is the keyword of magic!<br>
<TabAtkins> vmpstr: Maybe that's something we can overcome with dev education<br>
<bramus> q+<br>
<TabAtkins> vmpstr: I think there are other things we might want to match on, like being selected<br>
<TabAtkins> vmpstr: So I think having an attr is useful<br>
<TabAtkins> q+<br>
<astearns> ack khush<br>
<TabAtkins> khush: I like the idea of two explicit keywords<br>
<TabAtkins> khush: And maybe "auto" that magically chooses between the two, if it's not the initial value.<br>
<TabAtkins> khush: We can make it pretty explicit int he property description<br>
<TabAtkins> khush: So I'd be fine with "auto" as the name, if the behaviors were chooseable separately.<br>
<TabAtkins> astearns: So you're proposing three keywords?<br>
<TabAtkins> khush: The ability to draw from an attribute is somethign proposed generically<br>
<astearns> ack bramus<br>
<TabAtkins> khush: So three things (tho not necessarily keywords)<br>
<fantasai> wfm<br>
<TabAtkins> bramus: One thing for proposed ident() function, this doesn't just apply to v-t-name, but anywhere that takes an ident<br>
<TabAtkins> bramus: So that's why I'm a big fan, it's not focused on only VT.<br>
<astearns> ack TabAtkins<br>
<fantasai> scribe+<br>
<fantasai> TabAtkins: Haven't read entire thread, very long, but<br>
<fantasai> TabAtkins: sounds like we want multiple strategies, and if one doesn't work, we fall back<br>
<fantasai> TabAtkins: so can we do comma-separated?<br>
<fantasai> TabAtkins: then we could allow future things, like use the selected thing (?)<br>
<fantasai> TabAtkins: Then we can have strategies for marking and matching view transitions<br>
<vmpstr> +1<br>
<khush> sgtm<br>
<TabAtkins> bramus: commas seem a bit weird?<br>
<fantasai> bramus: commas seem a bit weird, e.g. animation-name, [missed]<br>
<TabAtkins> bramus: If you do commas in animation-name, both names apply<br>
<fantasai> bramus: view-transition-name: x, y<br>
<fantasai> vmpstr: we could do space separated<br>
<fantasai> TabAtkins: we use commas for lists of stuff, helps allow future syntax evolution<br>
<fantasai> TabAtkins: problem with the counter properties because they didn't have commas<br>
<fantasai> vmpstr: This isn't something we're thinking of doing today, but at some point we considered having multiple view transition names<br>
<fantasai> vmpstr: so that same element can morph into multiple<br>
<fantasai> vmpstr: so prefer space separation for that reason<br>
<fantasai> TabAtkins: fine with that<br>
<fantasai> TabAtkins: I doubt any syntax evolution here, it's just a name<br>
<fantasai> TabAtkins: so fine to do space separation, I just default to commas<br>
<astearns> ack fantasai<br>
<TabAtkins> fantasai: I think multiple keywords are a bit more cognitive overhead if there's really only two things that are fallbacks<br>
<TabAtkins> fantasai: I think having auto keyword doing that makes the most sense<br>
<TabAtkins> (we've already discussed more than two behavior in this convo)<br>
<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<br>
<TabAtkins> astearns: Tab said we already had more discssuion<br>
<TabAtkins> fantasai: Like what?<br>
<TabAtkins> TabAtkins: The selected element between two trees<br>
<TabAtkins> vmpstr: Specifically, just some element with a particular class in both trees<br>
<TabAtkins> fantasai: Isn't that what selectors are for?<br>
<TabAtkins> fantasai: If you want to choose one attribute if it's .foo, another with .bar, we can do that with selectors<br>
<TabAtkins> (tbf that same argument applies to ID, tho the possible common-ness of ID use is still an argument in favor)<br>
<TabAtkins> astearns: If we go with "auto" for now, nothing stops us from allowing multiple fallbacks in the future<br>
<TabAtkins> +1<br>
<fantasai> +1<br>
<khush> q+<br>
<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<br>
<astearns> ac khush<br>
<astearns> ack khush<br>
<TabAtkins> khush: For using a keyword for ID, is that something we want to do in other naming properties? Or is it VT specific?<br>
<fantasai> PROPOSED: Introduce keyword for element identity, some other syntax for using the element's ID, and auto keyword that switches between the two<br>
<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.<br>
<TabAtkins> fantasai: We could extend this to other properties possibly. Other properties have more referencing, might be a bit less useful.<br>
<TabAtkins> fantasai: You name the thing, *and* refer to it from other elements. In that case the CSS needs to know the name anyway.<br>
<khush> that's fair<br>
<TabAtkins> fantasai: VT is a case where you don't need to know the name, you can reference it just via classes.<br>
<TabAtkins> fantasai: If we introduce an ident() it should have its own issue<br>
<TabAtkins> bramus: #9141<br>
<TabAtkins> fantasai: If we do it shoudl be generic across CSS<br>
<TabAtkins> vmpstr: Still just one keyword to specify? No fallback list?<br>
<TabAtkins> fantasai: Yes. Three new keywords, but only use one at a time.<br>
<TabAtkins> astearns: the ident() function isn't part of this issue, will be a different discussion<br>
<TabAtkins> astearns: So three new keywords, use one at a time. Objections?<br>
<TabAtkins> bramus: If we do ident() elsewhere, do we need the third keyword now? Will that be affected?<br>
<fantasai> PROPOSED: Introduce keyword for element identity, some other syntax for using the element's ID, and auto keyword that switches between the two<br>
<TabAtkins> fantasai: This'll be whatever the markup language defines as the element identifier, "id" in html<br>
<flackr> q+<br>
<TabAtkins> fantasai: xml:id in XML<br>
<TabAtkins> flackr: The function for using element's ID, is that differetn from attr()<br>
<fantasai> TabAtkins: proposal here is to have a specialized keyword that uses the ID<br>
<fantasai> TabAtkins: could *also* allow the ident() function<br>
<fantasai> flackr: and attr() would be a separate solution<br>
<fantasai> fantasai: currently no-one implements ident-generating attr(), only string-generating attr()<br>
<TabAtkins> RESOLVED: Add three keywords, one for ID attribute, one for element identity, and one that does fallback between the two.<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-2344208387 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 September 2024 17:00:23 UTC