- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 Dec 2024 17:57:46 +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: use the `match-element` keyword for this and disallow it as a value in vt1 spec`` <details><summary>The full IRC log of that discussion</summary> <bramus> noamr: we have a way to generate v-t-names with the keyword `auto`.<br> <bramus> … auto generates name based on the id attribute or element identity when two elements on both end of the VT are the same.<br> <bramus> … the id approach also works cross-document<br> <bramus> … are proposing other value where it does not try to do the `[id]` check first. only uses element identity, only working in same-doc VTs<br> <JakeA> q+<br> <bramus> … in the breakout for VTs a few weeks ago elika proposed match-element which we like<br> <bramus> … are proposing to put that as a function for the purpose of feature detection<br> <bramus> … because right now `v-t-n: match-element` parses as supported<br> <bramus> … important to ship both things together. bigger groups of people who ship sites need a better layering.<br> <Rossen1> q?<br> <bramus> … auto has a better default behavior, but want to allow people to use a cleane rseparation if they so choose<br> <Rossen1> ack fantasai<br> <Zakim> fantasai, you wanted to comment on parsin and to comment on parsing<br> <bramus> fantasai: so the v-t-n accepts none an dcustom ident, which start with double dash<br> <bramus> … browsers should be rejecting any value that does not start with --<br> <bramus> … dont think we should introduce `()`<br> <bramus> bramus: dashed idents are subset of custom idents<br> <emilio> q+<br> <vmpstr> +1<br> <bramus> fantasai: oh, right. still dont like the parenthesis<br> <Rossen1> ack JakeA<br> <fantasai> fantasai: implies there's argument, but definitely there's none<br> <bramus> JakeA: I think we should unship/unspec `auto` as it exists now<br> <bramus> … aim of VTs was to have same behavior for same-doc and cross-doc<br> <bramus> … `match-element` is a useful departure from that but need to make it clear that the behavior only works in one of the two<br> <bramus> … `auto` muddies the water as it has `match-elemetn` but also `[id]` and creates this half-working feature but definitely different between MPA and SAP<br> <bramus> … I dont think that `auto` as “will do it all for you” here<br> <bramus> … might come up with other triggers like hover - should make sure definition of a transition is the same<br> <Rossen1> ack emilio<br> <bramus> emilio: strong agree with fantasai. no need for (). lot of other props with similar syntax restrict which idents they can parse<br> <JakeA> q+<br> <noamr> q+<br> <bramus> … am sure we can come up with an ident that is not a compat conceren<br> <Rossen1> ack fantasai<br> <bramus> fantasai: like to focus on noam’s ask of whether we add match element.<br> <bramus> … lets discuss meaning of auto later<br> <Rossen1> ack JakeA<br> <bramus> JakeA: i want to make sure that `match-element` is not as useful as people think it is<br> <bramus> … similar in codepen/tech demos<br> <bramus> … but if you are doing a page transition, its common for simple case to replace large parts of the DOM using innerHTML, which are different elements<br> <bramus> … element equality is not guaranteed<br> <Rossen1> ack noamr<br> <JakeA> That's an argument for not adding this behaviour into something like `auto`<br> <bramus> noamr: regarding compat: we could go back to CSS vt-1 and make it an illegal keyword<br> <JakeA> …because it's a complex behaviour and you need to know what you're opting into<br> <bramus> … think about compat is not about whether sites use it, its whether sites would catch it<br> <dbaron> For what it's worth, I think I have different opinions about element equality: https://dbaron.org/log/20200221-dom-identity<br> <JakeA> q+<br> <bramus> … to go back to vt-1 then say that its illegal, then new implementations can do that<br> <bramus> … instead of try and parsing it as a name<br> <bramus> … but right now in current implementations it does parse<br> <bramus> q+<br> <Rossen1> ack fantasai<br> <bramus> fantasai: there is a wide grey area in types of ?? and web apps between a demo page and sth that is using a particular framework style<br> <bramus> … we should be designing CSS to be usable and comfortable to it<br> <bramus> … I reject his argument that element identity is not useful at all<br> <Rossen1> ack JakeA<br> <bramus> JakeA: didnt say it wasnt usefull at all, but that it is less useful<br> <fantasai> s/at all/at all on real websites/<br> <bramus> … I covered other ground of simple page changes that fetch data and innerHTML it<br> <noamr> agree that match-element is useful for a lot of the spectrum, but attr() and ident() can cover a lot of the more complex/frameworky cases<br> <bramus> … in all simple demos I created they use innerHTML<br> <bramus> … widely used pattern, outside of frameworks<br> <bramus> JakeA: I am worrried about kicking the auto discussion down the road<br> <bramus> … concerns were raised in october and safari shipped in december<br> <bramus> … not covering now could leave us stuck with it<br> <bramus> fantasai: given that chrome is not even shipping can indicatate that its a really useful feature<br> <astearns> -1 to the practice of allowing browsers to ship things and then see if compat issues come up<br> <bramus> … if we both shippped it and it was harmful then ???<br> <bramus> … fine to discuss, but dont think we need to resolve<br> <JakeA> q+<br> <fantasai> s/???/it would be urgent to remove/<br> <fantasai> s/resolve/resolve today necessarily/<br> <Rossen1> ack JakeA<br> <bramus> JakeA: agree with it just being safari then there is less of a riks<br> <bramus> … but dont like that being used as an excuse<br> <bramus> … more worried about that if it does get used, it’s sold as a “we’ll do things for you” but it has footguns detailed in the thread<br> <astearns> q+<br> <bramus> … could block us from doing useful things in the future<br> <Rossen1> ack bramus<br> <noamr> bramus: re match-element being a function, it solves a short term, while in the long term a keyword would be best<br> <noamr> bramus: fine with match-element as a keyword, even without it being feature-detectable<br> <fantasai> +1 let's design for hte ong term<br> <fantasai> s/hte ong/the long/<br> <Rossen1> ack astearns<br> <bramus> astearns: at the very least I would appreciate it if the Safari would stop talking about the `auto` value until we figure out whether we can support it long term or want it to go away<br> <noamr> astearns: at the very least I would appreciate it if the Safari folks would not talk about the auto value until we figure out if we want to support it long term<br> <bramus> … the less it gets evanglized the more options we have in the future<br> <bramus> Rossen1: ok, let’s see if we can wrap this up<br> <bramus> noamr: proposed resolution would be then to have match-element as keyword and thus to disallow it as a name in v-t-1<br> <JakeA> +1 to `match-element`<br> <bramus> Rossen1: Any additional feedback or objections?<br> <bramus> fantasai: overall sounds good<br> <bramus> … did we call the other names? `self` and `match-element`<br> <bramus> … tab commented we should have a keyword that also works equally well in `random()`<br> <bramus> Rossen1: which one of the two is currently being used int he issue or spec?<br> <bramus> fantasai: mostly `match-element` is used<br> <bramus> Rossen1: can we stick to that for now and bikshed later?<br> <vmpstr> +1 to `match-element`<br> <Rossen1> ack fantasai<br> <bramus> noamr: this is already result of a lot of bikshedding inthe issue and a breakout before<br> <bramus> … I suggested `self` but like `match-element` today<br> <bramus> Rossen1: OK<br> <JakeA> (I'm not tied to the name `match-element`, as long as it's a name that suggests the behaviour as much as possible)<br> <bramus> RESOLVED: use the `match-element` keyword for this and disallow it as a value in vt1 spec<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-2551949161 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 December 2024 17:57:46 UTC