- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 21 Jan 2026 17:44:50 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] Revisiting view-transition-name: auto keyword name`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> ScribeNick: TabAtkins<br> <TabAtkins> vmpstr: We've resolved to have a v-t-n:auto a while ago, with behavior that it selects an ID attribute if one is present, otherwise falls back to match-element<br> <TabAtkins> vmpstr: there was pushback raised by JakeA that said that's a bad idea, because it's a little too magical to tie an auto behavior to an ID attribute<br> <TabAtkins> vmpstr: he raised with TAG and they seem to agree<br> <TabAtkins> vmpstr: failure case is it's easy to make a mistake where a dev that changes an ID can check if that ID is referenced anywhere, not find it, and miss that they're implicitly depending on it for a view-transition name. easy mistake to make<br> <TabAtkins> vmpstr: there's a way to specify that using attr() function, TAG guidance was to either name the value something less innocuous than auto, or just rely on Attr() for it<br> <TabAtkins> vmpstr: so i'm revisiting the value. I believe Safari is shipping currently, so it would be a breaking change<br> <TabAtkins> astearns: is WebKit the only engine shipping auto?<br> <emilio> That's correct<br> <TabAtkins> vmpstr: Not sure about gecko but I think so, yes<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: a few points about attr()<br> <TabAtkins> fantasai: 1, it doesn't solve the motivating problem, which is "I searched my codebase for this ID and it didn't show up"<br> <TabAtkins> fantasai: attr(id) doesn't solve that either, so that's not a real solution to the problem<br> <TabAtkins> fantasai: 2, depending on Attr() makes it dependent on a large amount of machinery, and making the feature depend on Attr() requires a lot of work<br> <TabAtkins> fantasai: 3, attr() is way more awkward for an author to use. syntax isn't particularly simple, and you have to know it exists in the first place<br> <TabAtkins> fantasai: so, can you do it? yes. but it's not easy for the author or the engine<br> <TabAtkins> fantasai: as for whether 'auto' is appropriate for this feature, it's historically meant "do the obvious thing". if you're asking if two elements are the same, checking the ID is a pretty obvious connection<br> <TabAtkins> fantasai: so I don't think I agree with the idea that this isn't the "natural" behavior for 'auto'<br> <TabAtkins> fantasai: so I don't feel very convinced this is something we need to remove or that is harmful<br> <TabAtkins> fantasai: TAG mentioned that defaults should be safe, this isn't the default. you still have to explicitly set it.<br> <TabAtkins> vmpstr: the idea isn't that ID appears in the styles, it's that the word "id" appears<br> <TabAtkins> fantasai: that's a bit of a stretch h<br> <TabAtkins> I agree with fantasai on this point, the concern is about finding if a *particular* ID appears<br> <TabAtkins> astearns: why is the attr() difficult relevant here?<br> <TabAtkins> fantasai: attr() needs to work everywhere for everything<br> <TabAtkins> fantasai: it's definitely not a small feature, it's very generic and has several subfeatures within it<br> <TabAtkins> astearns: what's your impl status?<br> <TabAtkins> fantasai: we don't have it yet. would like to someday<br> <emilio> Gecko is actively implementing<br> <TabAtkins> astearns: in blink/gecko?<br> <TabAtkins> futhark: blink has it<br> <noamr> q+<br> <TabAtkins> vmpstr: just to clarify - I dont' think you're saying that *if* attr() was already implemented, you'd support removing auto. right?<br> <TabAtkins> fantasai: right, I think. attr() is a heavy feature to depend this on now. but even with attr(), it's still a complicated thing for an author to lean on for what should be a common use-case<br> <TabAtkins> fantasai: reasonable for an expert user, but not for a less advanced CSS user<br> <TabAtkins> astearns: Jake is making the opposite argument, that the keyword is easy to use but we're not explicit about what it means<br> <TabAtkins> fantasai: I think having a keyword that checks ID, and otherwise checks element identity, isn't complex for authors to grasp<br> <TabAtkins> astearns: And Jake has been consistently arguing that this isnt' something authors *should* want. i'm not sure how to evaluate that assertion<br> <astearns> ack noamr<br> <TabAtkins> noamr: possible middle ground, what if it was called match-id?<br> <TabAtkins> noamr: or a v-t specific match-attr() function or something<br> <TabAtkins> noamr: alias as a very particular use of attr() without invoking the whole feature. and we already have match-element, so it's discoverable together<br> <TabAtkins> fantasai: currently 'auto' does both, right?<br> <TabAtkins> fantasai: falls back to element identity if the ID isn't there<br> <TabAtkins> q+<br> <TabAtkins> fantasai: if we have two elements with the same ID in the before/after trees, if I ask a human, they'd pretty clearly say the two elements are matching<br> <TabAtkins> noamr: I think we just have different concepts of what's "obvious" here<br> <vmpstr> +1<br> <diekus> +1<br> <fantasai> scribe+<br> <davidleininger> +1<br> <fantasai> TabAtkins: Elika's objection match-id falling back to match-element, we could make that happen<br> <fantasai> TabAtkins: If the specified attribute doesn't exist, then automatically fall back to match-element<br> <fantasai> TabAtkins: Literally renaming auto to match-id would solve the concerns here<br> <lwarlow> q+<br> <fantasai> TabAtkins: and match up to match-element naming scheme<br> <emilio> +1, that seems reasonable<br> <kbabbitt> +1<br> <astearns> ack TabAtkins<br> <fantasai> TabAtkins: So we don't have to invoke a bunch of fallback machinery if we say that's the default behavior<br> <flackr> or match-identity to avoid the assumption that it is literally the "id" attribute?<br> <astearns> ack lwarlow<br> <TabAtkins> lwarlow: I don't see how having "match-id" that falls back to match-element is actually better than "auto"<br> <fantasai> lwarlow: I don't see how match-id magically falling back to match-element is better than an auto value that does automagic on different conditions<br> <fantasai> lwarlow: auto might be confusingly non-specific<br> <fantasai> lwarlow: but renaming to match-id is worse, because the meaning doesn't match what it does<br> <TabAtkins> lwarlow: I think "auto" might be confusing and doesn't say what it's doing, but having "match-id" also match on things that aren't IDs would also be bad. it would do more than what's stated<br> <kbabbitt> match-id-or-element ?<br> <TabAtkins> lwarlow: I think if you have match-id that *just* matched on ID that would be okay<br> <vmpstr> I like flackr's suggestion match-identity<br> <TabAtkins> astearns: my current take is that we'r enot agreeing and should move on for now<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: I think i agree with what Luke said. I dont' think that means we can't do both. we could add match-id, and maybe have match-auto which does both via fallback<br> <TabAtkins> fantasai: maybe call it match-identity, that might be a slightly confusing word. match-auto is pretty clear across CSS tho<br> <TabAtkins> I quite like this fwiw<br> <noamr> match-magic<br> <lwarlow> +1 to fantasai's idea<br> <TabAtkins> noamr, we spell "magic" A-U-T-O in css<br> <kbabbitt> match(id || element)<br> <TabAtkins> astearns: I'd like to take this back to the issue to get Jake's opinions on adding more keywords here<br> <vmpstr> +1 to match-auto match-id etc<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12091#issuecomment-3780046512 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 21 January 2026 17:44:51 UTC