- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 Oct 2022 16:57:04 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Selector syntax for generated elements`, and agreed to the following: * `RESOLVED: Go with the Option 3 syntax.` * `RESOLVED: Name the function .startViewTransition()` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: Selector syntax for generated elements<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7788<br> <TabAtkins> vmpstr: We've discussed the names previously<br> <TabAtkins> vmpstr: Two parts - what names do the pseudos have, and how to select them in CSS?<br> <TabAtkins> vmpstr: Summarized in one of the later comments<br> <vmpstr> https://github.com/w3c/csswg-drafts/issues/7788#issuecomment-1287309961<br> <TabAtkins> vmpstr: some names that don't seem to have much discussion<br> <TabAtkins> vmpstr: A lot focused on "images" vs "group/set/etc" for the wrapper element that has isolation on it<br> <TabAtkins> vmpstr: don't think we have consensus<br> <TabAtkins> vmpstr: But hoping we can resolve on the rest<br> <TabAtkins> vmpstr: So, about selection, option 1 is full chaining<br> <TabAtkins> vmpstr: Shows the whole structure of the pseudos<br> <TabAtkins> vmpstr: option 2 is the same but with repetition removed from the nested names<br> <TabAtkins> vmpstr: option 3 is we let all the elements hang off of the root, so you can select any of them directly without needing to navigate the nesting<br> <TabAtkins> vmpstr: option4 is ::transition-part() which is similar syntactically to ::part() but otherwise resembles option 3<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: I don't think the redundant chaining is a good idea, should eliminate it.<br> <JakeA> q+<br> <TabAtkins> fantasai: Either reduced chaining or direct attachment makes the most sense<br> <TabAtkins> fantasai: I think (1) is unnecessarily terrible, 2 and 3 seem like best options<br> <TabAtkins> fantasai: No strong opinion between those two<br> <TabAtkins> fantasai: Slightly concerned in 2 when you add the subtree version of the transitions, will it make these longer or keep the same?<br> <TabAtkins> fantasai: I think there was discussion about nesting inside of things, so if we reflect the full structure will it get longer?<br> <TabAtkins> flackr: i don't think it will<br> <TabAtkins> vmpstr: I think it will, if we do the full chaining<br> <TabAtkins> khush: Yes, same as existing pseudos, you have to have the full chain (like ::before::marker isn't matched by ::marker)<br> <miriam> q+<br> <TabAtkins> [missed a clarification]<br> <TabAtkins> fantasai: So I think that would be a reason to not go with 2<br> <TabAtkins> vmpstr: So that leaves 3 as your pref?<br> <TabAtkins> fantasai: Based on what I know so far, yes.<br> <astearns> ack JakeA<br> <TabAtkins> I also vote 3, fwiw<br> <TabAtkins> JakeA: There was a proposal for a pseudo-descendant combinator which would let you skip some of the things in option 1 and 2<br> <vmpstr> :>> old<br> <smfr> q+<br> <TabAtkins> JakeA: But with option 2 there's a worry there's an ambiguity - a short `::old` which is nicely short and contextual, suddenly becomes potentially clashing with other uses<br> <astearns> ack miriam<br> <astearns> q+<br> <TabAtkins> miriam: I asked in the doc - on 4, is it possible to allow combinators within the function?<br> <TabAtkins> miriam: i'm thinking about, "when you have old but not new, do something special" - can we attach that to a part-like syntax?<br> <TabAtkins> astearns: Would that just come after the function?<br> <TabAtkins> miriam: I was imagining it inside but mayb eit does work<br> <TabAtkins> khush: Since this borrows the ::part() syntax, the keywords that go inside it are like class names.<br> <JakeA> q+<br> <astearns> ack smfr<br> <TabAtkins> khush: we could add a new tag marking when something has just-old, just-new, or both, but you wouldn't be able to query arbitrary things yourself<br> <astearns> ack astearns<br> <TabAtkins> smfr: Can I use normal descendant selectors to address these elements?<br> <TabAtkins> JakeA: No, not true for pseudos in general<br> <vmpstr> TabAtkins: you can't use general descendant selectors into shadows<br> <TabAtkins> smfr: seems bad to lose the ability to use familiar selector syntax<br> <TabAtkins> TabAtkins: true for shadows too - all you ahve is ::part(), which loses structure<br> <TabAtkins> smfr: can you write a selector that does do structure inside the shadow?<br> <TabAtkins> TabAtkins: no<br> <TabAtkins> smfr: unfortunate. Seems the nested double-colon things are unwieldy.<br> <TabAtkins> fantasai: These things we're selecting, are they elements or are they pseudos?<br> <TabAtkins> fantasai: Can you pull them out and change their styles with JS?<br> <TabAtkins> JakeA: Per previous resolution, they're pseudo-elements.<br> <fantasai> html::view-transition(:root)<br> <TabAtkins> fantasai: What about something like option 4 but rather than part-like with keywords, it takes a selector subset?<br> <fantasai> html::view-transition(old)<br> <fantasai> html::view-transition(.currenttransitionthingIlike new)<br> <fantasai> html::view-transition(.currenttransitionthingIlike > new)<br> <smfr> q+<br> <miriam> +1 that's what I was trying to get at<br> <TabAtkins> fantasai: So we'd take some subset of selectors, you can use the tree-querying selectors like :root or :first-child<br> <JakeA> q-<br> <TabAtkins> khush: So ::view-transition just gets you at the root node for these pseudos, then any selector that you can use today will traverse this tree?<br> <TabAtkins> fantasai: Pretty much, yeah.<br> <miriam> https://docs.google.com/document/d/1kW4maYe-Zqi8MIkuzvXraIkfx3XF-9hkKDXYWoxzQFA/edit?disco=AAAAiKGTYoY<br> <TabAtkins> JakeA: In this model where would I be saying I"m targeting the "new" of the header?<br> <TabAtkins> ::view-transition(images.header > old)<br> <fantasai> html::vt(.header new) /* if flat */<br> <fantasai> html::vt(.header > image-set > new) /* if complicated */<br> <TabAtkins> JakeA: a pseudo with a class name seems different but i don't hate it...<br> <TabAtkins> (I think this is a good idea actually.)<br> <astearns> ack smfr<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to ask about subtree selectors<br> <JakeA> I like that it retains the structure<br> <ydaniv> or ::view-transition(::new) ?<br> <TabAtkins> smfr: The things being styled are the snapshots, right?<br> <TabAtkins> vmpstr: yes<br> <fantasai> fantasai^: I don't know if it's a good idea, but it's an idea<br> <TabAtkins> smfr: Would it be possible to describe these by pointing to the element being snapshotted?<br> <TabAtkins> JakeA: I tried to create a proposal based on that, but in many cases you're animating somethign that's no longer there<br> <TabAtkins> JakeA: So trying to target somethign that might be gone (or which the matched els have changed) is weird<br> <TabAtkins> smfr: Seems like you'd snapshot<br> <TabAtkins> JakeA: IN a multi-page transition you'd be mixing styles from the old and new page, whichi gets tricky.<br> <TabAtkins> JakeA: The model is for multi-page the incoming page gets to control the animation<br> <emilio> q+<br> <TabAtkins> smfr: Yeah I see that case is hard<br> <TabAtkins> smfr: Is multi-page sitll a realistic goal?<br> <TabAtkins> JakeA: Yeah, I'm working on it right now<br> <TabAtkins> smfr: Still seems the from and to page have to have a close enough appearance, so maybe it's not too bad to require them to have close structures<br> <vmpstr> q?<br> <TabAtkins> flackr: The containers around the snapshot don't belong to either starting or ending element<br> <astearns> ack emilio<br> <TabAtkins> JakeA: I think smfr was suggesting a pseudo targeting that<br> <TabAtkins> [missed what that actually meant]<br> <TabAtkins> emilio: Is the idea that the pseudos are still on the root?<br> <TabAtkins> vmpstr: Yes, if you tag elements in your page they get flattened to a list attached to the root<br> <TabAtkins> vmpstr: In the later proposal instead of flattening we'd retain the hierarchy from the DOM, but the structure would still attach to the root element<br> <TabAtkins> emilio: So these pseudos will still only be usable from the root<br> <TabAtkins> vmpstr: yes<br> <TabAtkins> emilio: I"m not a fan of "arbitrary selectors", mostly becuase we've already seen it's weird that we need extra containers for wrappers and isolation<br> <TabAtkins> emilio: So once we expose the structure we can't change that ever<br> <TabAtkins> emilio: maybe that's ok<br> <JakeA> q+<br> <TabAtkins> TabAtkins: Several of the syntaxes already epxose the structure, and I think in general styling will expose the structure.<br> <TabAtkins> TabAtkins: Don't think the structure can be changed without a mode switch<br> <TabAtkins> emilio: say you have a new transition type that needs a new wrapper<br> <TabAtkins> emilio: stuff generally keeps working<br> <fantasai> +1 to emilio's point<br> <TabAtkins> khush: I was expecting one thing that would be consistent is that the only thing that affects the structure is view-transition-name<br> <TabAtkins> khush: So if you ahve two doms and have the same tag applied, you'll consistnetly get the same structure<br> <TabAtkins> khush: So if the structure changes I expect it's from the author changing something<br> <TabAtkins> khush: so was emilio talkinga bout changing the structure even if the authors don't change anything?<br> <TabAtkins> emilio: Yeah, if you want to expose a new transition type with a differetn structure<br> <TabAtkins> q+ about this<br> <TabAtkins> ack about<br> <TabAtkins> ack this<br> <TabAtkins> q+<br> <astearns> ack JakeA<br> <TabAtkins> JakeA: The reason we added the image wrapper was to give us some leeway for this nested model<br> <TabAtkins> JakeA: otherwise we could use the container itself for the isolation<br> <TabAtkins> JakeA: We didn't think we could add structure later without breaking author styles<br> <TabAtkins> JakeA: There's also Miriam's point about "only old" or "only new" wanting a different animation<br> <TabAtkins> JakeA: So if we use :only-child for that that does lock us into some structure<br> <vmpstr> TabAtkins:<br> <astearns> ack TabAtkins<br> <fantasai> scribe+<br> <fantasai> TabAtkins: Concern that emilio has, not necessarily that we change structure of existing transitions, but if we add a new type that needs a new structure<br> <fantasai> TabAtkins: concern would be if you have styles generically applying to old styles, and add new transition type, something might break<br> <fantasai> TabAtkins: don't think we should be concerned; if you make a new type of transition, make new styles<br> <fantasai> TabAtkins: also not sure any existing styling would work properly under a new structure, might implicitly depend on it<br> <fantasai> TabAtkins: so not guaranteed to work. And it's a new feature anyway<br> <fantasai> TabAtkins: so I don't think this is a very strong argument<br> <astearns> ack fantasai<br> <khush> q?<br> <JakeA> q+<br> <TabAtkins> fantasai: say, picking out the old from a transition is a little tricky<br> <TabAtkins> fantasai: if you want the old header transition, you ahve to pipe thru the whole structure and use child selectors<br> <TabAtkins> fantasai: if the header has a nested icon also transitioning (assuming nested transitions) you can't just generically address olds<br> <TabAtkins> fantasai: So using the selector syntax has more power but does require a little extra work<br> <khush> q+<br> <TabAtkins> fantasai: So my inclination is option 3, and if at some point we need to add more structure we can do 4 with selectors<br> <fremy> +1, I think this is the type of things we can add later<br> <TabAtkins> fantasai: But I think ahving a pseudo that doe sthe lookup cleanly seems fine anyway<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <astearns> ack khush<br> <argyle> q+<br> <astearns> ack JakeA<br> <TabAtkins> TabAtkins: I was assuming that everything under a tag would be tagged with it, so `old.header` would work instead of needing `.header > images > old`<br> <TabAtkins> khush: +1 to option 3, dealing with selectors would just be hard<br> <TabAtkins> khush: Also yes, we do tag every element with the given tag<br> <TabAtkins> JakeA: We should capture the selector idea in the issue for later, tho<br> <TabAtkins> argyle: Somethign I like about 4 is it's clear what's being selected<br> <TabAtkins> argyle: Since 3 is nice, I suggest instead of using a pseudo-element function we just use a descendant combinator<br> <fantasai> I think argyle is asking for something like html::view-transition old.header<br> <fantasai> ?<br> <fremy> @argyle: do you mean `::view-transition #id` ?<br> <TabAtkins> yeah adam is asking for elika's idea, just not inside the parens<br> <TabAtkins> vmpstr: The "foo" in option 3 is the tag of the container itself, it's not like :has()<br> <JakeA> seems ambiguous with descendant combinators?<br> <fremy> JakeA: yeah, I think the idea is that it's like a descendant in the "view-transition" tree<br> <TabAtkins> argyle: Okay, I was misunderstadning how the targeting worked, the pseudo-element is targeting the pseudo in question<br> <fremy> fantasai, ah yes, good idea. I'm falling for the autocomplete...<br> <Sebastian_Zartner> +1<br> <TabAtkins> astearns: So proposal is to go with option 3, leaving the possibility of future selector power<br> <TabAtkins> RESOLVED: Go with the Option 3 syntax.<br> <Sebastian_Zartner> +1 on option 3 with option 4 for future extensions<br> <TabAtkins> vmpstr: are the names part of this resolution, or do we need to discuss those separately?<br> <TabAtkins> astearns: This is the CSSWG, we'll definitely discuss names again. But go with what's in the issue for now.<br> <TabAtkins> vmpstr: Also the JS api name to start a transition isn't good.<br> <TabAtkins> vmpstr: Proposal is .transitionView()<br> <vmpstr> document.transitionView()<br> <TabAtkins> khush: Took inspriation from element.animate()<br> <TabAtkins> astearns: Is there an issue open for this?<br> <TabAtkins> vmpstr: it's part of this issue<br> <TabAtkins> smfr: "transition view" reads like a noun<br> <TabAtkins> smfr: startViewTransition()?<br> <fantasai> +1 to startTransitionView<br> <TabAtkins> JakeA: createViewTransition() was what we had before<br> <fantasai> or startViewTransition<br> <TabAtkins> ydaniv: There's a separate issue about whether we should start by default<br> <TabAtkins> astearns: Objections to .startViewTransition() ?<br> <TabAtkins> RESOLVED: Name the function .startViewTransition()<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7788#issuecomment-1292336905 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 26 October 2022 16:57:07 UTC