Repository navigation
[css-view-transitions-1] CSS selector keywords. #7960
Description
Forking this from #7788 to resolve on the exact keywords used in the selector.
-
Property used on DOM elements to tag them for independent animations:
view-transition-name. -
The pseudo-element which directly originates from the root element and is the ancestor for all container elements. Options are:
html::view-transitionhtml::view-transition-root
Proposed Resolution:html::view-transition
-
The pseudo-element which animates the size and position for tagged elements. Options are:
html::view-transition-container(*)html::view-transition-group(*)
Proposed Resolution:html::view-transition-group(*)
-
The pseudo-element which adds
isolationfor blending. Options are:html::view-transition-image-group(*)html::view-transition-pair(*)html::view-transition-effect-group(*)html::view-transition-images(*)html::view-transition-set(*)html::view-transition-image-set(*)html::view-transition-image-pair(*)
-
The pseudo-element which displays snapshot from the old DOM element. Options are:
html::view-transition-old(*)
Proposed Resolution:html::view-transition-old(*)
-
The pseudo-element which displays snapshot from the new DOM element. Options are:
html::view-transition-new(*)
Proposed Resolution:html::view-transition-new(*)
Please comment in case I missed an existing suggestion from #7788 or if you have any other suggestions.
- 1, 5 and 6 have only option which is the proposed resolution.
- 2 has a couple of options but I think we converged on (2.i) so I added that as the proposed resolution.
- 3, 4 need consensus.
Pasting fantasai's comment on 3,4:
- changing
::view-transition-image-groupto::view-transition-pairbecause it's shorter (and not a hyphenated phrase) and avoids evoking the idea of groups in SVG, which it's not conceptually similar to - changing
::view-transition-containerto::view-transition-groupbecause it's shorter and evokes the idea of groups in SVG (which create hierarchy in the graphic elements)
The downside of using "pair" is that it'll make it awkward if a future change needs a pseudo-element other than old/new under this element. It's not a pair anymore then. ^_^ But no hard preference there, we don't forsee anything that would add more pseudo-elements under this node right now.
I also didn't follow why the the element adding isolation isn't conceptually similar to SVG groups but the one which mirrors size/position of the DOM element is. @fantasai could you clarify?
Regarding shorter names, the motivation to use view-transition-image-group/view-transition-image-pair instead of view-transition-group/view-transition-pair would be that the latter sounds similar to view-transition-container. The "image" keyword there makes it obvious that it's a pair of replaced elements. We could go with view-transition-image-pair instead of view-transition-image-group.
Activity
vmpstr commentedon Oct 28, 2022
Here's my 2c:
::view-transitionif fine, since addingrootis unnecessarily verbosecontainerorgroupis ok with me, but I like the fact thatgroupis shorter and easier to type, so that would be my voteimageoreffectin this name, sinceview-transition-set, for example, is too close toview-transition-groupto not be confusing.pairis also a misnomer in some cases, since exit and enter animations would only have one constituent image. I likeview-transition-image-setorview-transition-image-list, sincesetgives me an impression that order doesn't matter. So my vote is forview-transition-image-list.view-transition-oldis fine.view-transition-newis fine.fantasai commentedon Oct 28, 2022
In your extended proposal, this is the element that creates hierarchy, right? That's exactly what groups do in SVG.
“list” has a very strong implication of “one or more, and probably many of an indeterminate number”, I think. Doesn't seem like a good fit for what is, afaict, only ever going to be two images (one of which might be empty)?
Are you thinking there will be three images in some future revision? @_@
khushalsagar commentedon Oct 28, 2022
By extended proposal I think you mean Nested transition containers. And yes, this will be the element which will have other container/group elements as children with that proposal.
With the current API it can be 1 or 2 images. 1 in the case where a
view-transition-nameexists only on the old or new DOM. In that case the other replaced element is not generated. This is different from it being empty since no node (and box in the box tree) will be created for it.That comment was just to note a consideration for future flexibility. Given that we have no extension planned that could have more than 2 nodes, please disregard it. The only argument against
pair(in the comments above) is that it's possible to have 1 replaced element under this element.fantasai commentedon Oct 31, 2022
I think that's fine. It's not an empty image but we're still conceptually transitioning between old and new, it's just that there's no image for one of these. :) Anyway that's my take.
khushalsagar commentedon Nov 1, 2022
Thanks for the feedback @fantasai.
I don't see any opposition to picking
view-transition-groupfor the node which animations size and position. Since this element will have otherview-transition-groupelements as children (with nested transitions) it also builds off a similar concept in SVG. Added that as the proposed resolution in the first comment.For the pseudo-element adding
isolation, I don't see any opposition to using the patternview-transition-image-foo. Having the word image disambiguates it fromview-transition-groupsince it can only have 1 or 2 replaced elements as children. The options for foo here arelist,pairorsetand ideal would be something which indicates that there can be 1 or 2 childrenpair: Con is the case where there is guaranteed to be only 1 child (enter/exit animations).set: Con is that set makes it sound like the order of children doesn't matter but it does. Also not clear that there can't be more than 2.list: Again, not clear that there can't be more than 2.I'd be ok with pair or list. @astearns @tabatkins any other suggestions?
css-meeting-bot commentedon Nov 3, 2022
The CSS Working Group just discussed
css-view-transitions-1] CSS selector keywords., and agreed to the following:RESOLVED: Accept the proposed resolutions for items 1, 2, 3, 5, & 6The full IRC log of that discussion
<dael> Topic: css-view-transitions-1] CSS selector keywords.<dael> github: https://github.com//issues/7960
<fantasai> https://github.com//issues/7960
<dael> fantasai: This is about naming varios pseudo elements for view transitions. Proposal for almost all in the issue. Could probably resolve all except 4
<dael> astearns: Prop is take propsals for items 1, 2, 3, 5, 6 in the issue
<dael> astearns: Objections on those names?
<dael> RESOLVED: Accept the proposed resolutions for items 1, 2, 3, 5, & 6
<dael> fantasai: Item 4. view-transition-group we just accepted gives a grouping mech with a hierarchy. In item 4 it's a leaf with one or two images
<dael> fantasai: It exists because need isolation for blending. Item 4 is to name that almost leaf grouping. List of names is the proposed ones
<dael> fantasai: Names fall into two sets. Ones that include image, ones that have grouping word, and ones with both
<PaulG> q+
<dael> astearns: And this will not be used as much as rest?
<dael> fantasai: Yes
<astearns> ack PaulG
<dael> PaulG: Confirming these are pseudo element images snapshotted and will not hit ax tree or carry content?
<dael> fantasai: Right
<dael> PaulG: Thank you
<dael> astearns: we're at time. We'll come back to the issue for the one remaining thing
Rename all CSS properties and associated concepts
css-meeting-bot commentedon Nov 9, 2022
The CSS Working Group just discussed
[css-view-transitions-1] CSS selector keywords, and agreed to the following:RESOLVED: view-transition-image-pairThe full IRC log of that discussion
<fantasai> Topic: [css-view-transitions-1] CSS selector keywords<fantasai> github: https://github.com//issues/7960
<fantasai> khush: This is about resolving on the selector keywords
<fantasai> khush: last meeting we got through everything except #4
<fantasai> khush: This is a pseudo-element for providing isolation for blending the old and new snapshots
<fantasai> khush: it's a leaf of the tree, only has old and new snapshots
<fantasai> khush: In terms of suggestions for naming, using word 'effect' or 'image', something to indicate that only nodes under here are replaced elements
<fantasai> khush: and need to disambiguate from view-transition-group() which cna change position/size, and can have other view-transition elements underneath it
<fantasai> khush: if we go with view-transition-image-foo, what's foo?
<fantasai> khush: Con of using "set" is that it doesn't indicate that DOM order matters, "list" makes it look like any number of elements but can only have two, and "pair" is nicest but sometimes there's only one element
<fantasai> khush: e.g. if DOM element only exists on one side
<fantasai> khush: but if we're okay with that, my proposal is view-transition-image-pair
<Rossen_> fantasai: +1 to using a pair. conceptually you have two things being transitioned independently
<Rossen_> ack fantasai
<fantasai> fantasai: wrt image, i'm less sure
<fantasai> JakeA: Tab wanted view-transition-images for brevity, but ppl didn't like plural
<fantasai> fantasai: for brevity, could also drop the "image" part and just say "view-transition-pair"
<fantasai> khush: "view-transition-group" and "view-transition-pair" not immediately obvious what's the difference
<fantasai> khush: but I could go either way, "view-transition-pair" vs "view-transition-image-pair"
<fantasai> Rossen_: I think group vs pair will clash for many non-native speakers, but wouldn't object
<fantasai> JakeA: It's not something folks will select a lot, ppl will select it ... I don't know, if they want to remove isolation for some reason?
<fantasai> Rossen_: even more reason to use a longer name
<flackr> Agree with Rossen_, I have a slight preference for view-transition-image-pair for clarity
<JakeA> +1 to image-pair
<khush> +1
<fantasai> Rossen_: Proposed to resolve on view-transition-image-pair
<fantasai> wfm
<lea> as a non-native speaker, I don't think group and pair are that frequently confused. Are there languages that do not distinguish between group and pair?
<ydaniv> +1 to image-pair
<fantasai> Rossen_: objections?
<fantasai> RESOLVED: view-transition-image-pair
khushalsagar commentedon Nov 9, 2022
The spec already names this element as view-transition-image-pair so no edit needed.