Comments (24)
I agree that the circularity is a problem that needs to be solved for option 1 (which is why I haven't mentioned it, but did think about it).
Auto grouping makes the example above awkward to express, since you need to modify your dom to encompass some things but not others.
I like option 3, just have both: by default view-transition-tree
establishes a grouping for descendant vt elements -- this solves a lot of cases without needing to specify parents on each descendant -- and have the ability to explicitly name an ancestor with view-transition-parent
. Note that the circularity is resolved in that the named parent has to be an ancestor of this element, otherwise the name is invalid
from csswg-drafts.
Can you expand a bit more on what you mean by "access to underlying data"? I suspect you already have the bits you need via getComputedStyle on the pseudos.
Oh, I didn't realize we could do that, yeah actually nevermind then, that's perfect. I think the primary issue with that would be say if it was access to dimensions of a parent that are animating to a new size, but that should be covered by the view-transition-parent
option.
from csswg-drafts.
Can you elaborate on the reasons?
It's mostly this use-case: "I have a list of cards in a container and only one of them needs to be parented to that container". Adding view-transition-parent
to that one card would be the least lines of code to accomplish it. The other way, view-transition-tree
on the parent + a view-transition-parent: none
on all other children is more code and I don't see why that's better.
It is also somewhat strange to me that this element would only nest the referenced element, and not the rest of its descendants (unless also explicitly named).
The author can get this behaviour by using view-transition-tree
though. I just think that the use-case of only child being nested under a parent is also a valid use-case and we don't have to choose a syntax which makes it unnecessarily verbose.
Are there any other CSS concepts that align closer to this? For some reason I'm thinking of anchor positioning, but even there, I don't think there's this type of effect
Good question. Anchor positioning does require a anchor-name
declaration for another element to be able to anchor to it. But I suspect its because you need a way to identify that element in CSS and add constraints to it to be able to be an anchor. We're already getting all of that by the fact that the parent needs to have a view-transition-name
. So we don't need to also add view-transition-tree
? @tabatkins to validate my thinking.
from csswg-drafts.
Thinking through an example:
ScreenFlow.mp4
In this case, the top box doesn't want to be contained, as it wants to transition between containers, whereas the other items need to be contained within the container.
I can think of a couple of ways of doing this:
Option 1: Manual grouping
view-transition-parent: name | auto | none
. Takes the name of a group to be nested within, or auto
, which takes the name of the closest ancestor with a view-transition-name
.
So, for the above example:
<div class="container-1">
<div class="card card-switching-containers" style="view-transition-name: card-1"></div>
<div class="card" style="view-transition-name: card-2"></div>
<div class="card" style="view-transition-name: card-3"></div>
<div class="card" style="view-transition-name: card-4"></div>
</div>
<div class="container-2"></div>
And the CSS for the transition:
.container-1 {
view-transition-name: container-1;
}
.card {
view-transition-parent: auto;
}
.card-switching-containers {
view-transition-parent: none;
}
html::view-transition-group(container-1) {
overflow: clip;
}
This is a bit manual, as I need to set things up for this particular transition.
Option 2: Auto grouping
The view-transition-tree
proposal in the OP, but children are grouped to the closest view-transition-tree: preserve
'parent' that is in both the old and new states.
<div class="container-1">
<div class="card" style="view-transition-name: card-1"></div>
<div class="card" style="view-transition-name: card-2"></div>
<div class="card" style="view-transition-name: card-3"></div>
<div class="card" style="view-transition-name: card-4"></div>
</div>
<div class="container-2"></div>
And the CSS for the transition:
.container-1 {
view-transition-name: container-1;
view-transition-tree: preserve;
}
html::view-transition-group(container-1) {
overflow: clip;
}
This case 'just works', because a given card won't be grouped within container-1
's group if it's moving to/from container-2
.
I wonder if there are cases this doesn't provide enough flexibility.
If the tree goes from three groups A > B > C
to B > A > C
, which group would C
be part of?
Option 3: both?
Allow option 2, but also allow individual children to assign themselves to a particular parent group. The assignment from the child would take priority.
from csswg-drafts.
With view-transition-tree: preserve | flatten
it's unclear to me whether what container to apply it on, or even if it applies to the container or the child in the first place.
view-transition-parent: <name> | auto | none
is better in terms of use-case coverage, but the main issue is circularity (.child { view-transition-parent: parent; } .parent { view-transition-parent: child }
), it would be good to avoid this footgun.
I don't have great suggestions on top of my head, but could the use cases be covered by scoped element transitions? e.g. making so running a document VT + a scoped element transition concurrently parents things accordingly? or having some API to run both at the same time?
from csswg-drafts.
The circularity is a good point. Option 2 doesn't have that problem.
I don't have great suggestions on top of my head, but could the use cases be covered by scoped element transitions? e.g. making so running a document VT + a scoped element transition concurrently parents things accordingly? or having some API to run both at the same time?
Interesting! But don't we run into all sorts of problems by trying to run two nested transitions like this?
from csswg-drafts.
In this case, the top box doesn't want to be contained, as it wants to transition between containers, whereas the other items need to be contained within the container.
That's an excellent point Jake. We actually considered option 1 too but leaned towards option 2 because it avoids the possibility of circularity. The use-case you mentioned though is a good reason to go for option 1. We already know which names appear in the ancestor chain when we reach a named element, so its trivial to fix the circularity issue by simply ignoring the view-transition-parent
not in the chain.
If we have to pick an option, the view-transition-parent
one is maximally flexible. option 1 is then syntactic sugar for a common use-case.
Re: mismatch in old and new DOM hierarchy, the situation can happen with either syntax option. We can consider a couple of options:
- The ancestor is decided based on the old DOM. So if a name appears in the old DOM, we ignore the
view-transition-parent
for it specified in the new DOM. This is similar to our approach for paint order, we let the paint order of names be decided by the old DOM. It's only for entry animations that we consider parent declarations in the new DOM. - If the ancestor mismatches for an element between old and new DOM, then fallback to flattening to the root.
I don't have great suggestions on top of my head, but could the use cases be covered by scoped element transitions? e.g. making so running a document VT + a scoped element transition concurrently parents things accordingly? or having some API to run both at the same time?
Excellent question! The use-cases we've seen do involve a full page transition. Think clicking on a button which expands to a widget while the background changes. This kind of thing is harder to coordinate with 2 independent transitions. We also have to think through how to deal with resizing for scoped transitions. For the scoped element, its layout for the end state will keep changing as its resized.
That said, @jakearchibald's example of a subset of nested elements being clipped can't be solved with scoped transitions. When a scoped transition is started, only elements in the subtree of the scoping element can participate in that transition. Content inside the scoping element can't animate out of it. For this you do need a transition at the root but with nested ::view-transition-group
s.
from csswg-drafts.
- The ancestor is decided based on the old DOM. So if a name appears in the old DOM, we ignore the
view-transition-parent
for it specified in the new DOM. This is similar to our approach for paint order, we let the paint order of names be decided by the old DOM. It's only for entry animations that we consider parent declarations in the new DOM.- If the ancestor mismatches for an element between old and new DOM, then fallback to flattening to the root.
FWIW, I prefer keeping the old dom structure. So in exit or paired animations, the old state determines the structure. For entry animations, the new state determines where to attach the entry groups. It's simple and I suspect most of the time works for reasonable effects
from csswg-drafts.
FWIW, I prefer keeping the old dom structure. So in exit or paired animations, the old state determines the structure.
SGTM! @jakearchibald @nt1m do you see any issues with this approach?
from csswg-drafts.
If we have to pick 1, seems like option 2 is maximally flexible. option 1 is then syntactic sugar for a common use-case.
The other way around, no?
from csswg-drafts.
FWIW, I prefer keeping the old dom structure.
I don't think I fully understand what's being proposed here.
In this example:
<div class="container-1">
<div class="card" style="view-transition-name: card-1"></div>
<div class="card" style="view-transition-name: card-2"></div>
<div class="card" style="view-transition-name: card-3"></div>
<div class="card" style="view-transition-name: card-4"></div>
</div>
<div class="container-2"></div>
And the CSS for the transition:
.container-1 {
view-transition-name: container-1;
view-transition-tree: preserve;
}
html::view-transition-group(container-1) {
overflow: clip;
}
If card-1
is moved to container-2
, where will ::view-transition-group(card-1)
be nested?
from csswg-drafts.
The proposal is to keep it in the structure where it appeared in the old state. So if both container-1
and container-2
are view-transition-tree: preserve
, then the ultimate structure is something like the following:
::view-transition
|__ ::view-transition-group(root)
|__ ::view-transition-group(container-1)
| |__ ::view-transition-group(card1)
| |__ ::view-transition-group(card2)
|__ ::view-transition-group(container-2)
In other words, even though the card moved in the "new state", in the "old state" it's still a part of container-1
.
With the clip, it means that the card will "disappear" as it tries to slide out of container-1
. I realize that it precludes it sliding in, but I think that's fine since we don't want effects that make an element disappear (because of new container clipping) and then slide into view again.
from csswg-drafts.
The other way around, no?
Yup. Sorry, fixed the comment above.
If card-1 is moved to container-2, where will ::view-transition-group(card-1)
What @vmpstr said. In the case above, you want card-1
to be under ::view-transition
directly right? So I think this example would work with view-transition-parent
+ the approach to use old state parent names (if provided).
from csswg-drafts.
Our use case typically would benefit most from Option 1. We do have cases like @jakearchibald demonstrates in #10334 (comment) where we move an item from 1 container to another, and we want to contain the items moving to the second container that might be in a another tree. Here's an example where we move a group of items from 1 container to the other. We'd definitely use the view-transition-parent
in this case:
80ec9e897c407837b4a0761ad3037299.mp4
I did have another use-case that I've been curious about, if we have the view-transition-parent
set or just in general, it would be great to have access to the underlying data as well if we want to say animate a clip-path
or do an offset within it. Something like clip-path: inset(env(view-transition-parent-top) ...)
. Having access to other ones would be great too but I realize that might be adding a lot of complexity.
from csswg-drafts.
it would be great to have access to the underlying data as well
Can you expand a bit more on what you mean by "access to underlying data"? I suspect you already have the bits you need via getComputedStyle
on the pseudos.
from csswg-drafts.
Evaluating how view-transition-parent
would work with the naming proposals on #8320.
There shouldn't be an issue with the attr()
and element-uuid()
syntax. One of the examples on the issue shows how custom properties allow using a parent's name on a child. For example,
.card {
--card-id: element-uuid();
view-transition-name: ident(var(--card-id));
img {
view-transition-parent: ident(var(--card-id));
view-transition-name: ident(var(--card-id) "-img");
}
}
But I don't see how view-transition-parent
could be set if an ancestor was named via view-transition-name: auto
. Not a big deal, we don't have to support all naming syntaxes with view-transition-parent
. Just something worth thinking through.
from csswg-drafts.
Proposed resolution to go with option 3 from the comment above: #10334 (comment).
One question, what should happen if the author adds view-transition-parent
to a child but doesn't add view-transition-tree: preserve
to the corresponding parent? Is view-transition-parent
enough to opt-in to grouping under that parent or does that parent explicitly need to allow grouping under it via view-transition-tree
.
The pro of requiring view-transition-tree
is that it aligns closely with position: absolute
so would make it easier for authors to understand the concept. The con is that if only child under a node wants to be parented under it, then the author explicitly has to set view-transition-parent: none
for all named elements under that parent. I lean strongly towards not requiring view-transition-tree
but this comes down to what would be more preferable for authors. So happy to go with either based on developer feedback.
@jakearchibald @calinoracation any suggestions?
from csswg-drafts.
I lean strongly towards not requiring
view-transition-tree
Can you elaborate on the reasons?
Requiring view-transition-tree
would indeed closer align with the containing block models found elsewhere. Typically it is the properties of an element that make it a containing block, not the fact that a descendant references it in some property. It is also somewhat strange to me that this element would only nest the referenced element, and not the rest of its descendants (unless also explicitly named). Are there any other CSS concepts that align closer to this? For some reason I'm thinking of anchor positioning, but even there, I don't think there's this type of effect
from csswg-drafts.
One approach would be to make view-transition-parent
an inherited property, so to accomplish the use-case in question you would do something like the following:
.container {
view-transition-name: container;
view-transition-tree: preserve;
view-transition-parent: none;
}
.special-item {
view-transition-name: special-item;
view-transition-parent: container;
}
.other-item {
view-transition-name: other-item;
/* view-transition-parent: none is inherited from .container */
}
I think whether or not view-transition-parent
should be inherited is a worthwhile topic on its own, since if an element wants to have a different parent, presumably all its children by default also want to have that parent? Or are there use cases where this is not true?
I guess a counter example to inheriting is also the above case where the container wants to escape its parent, but all the children should be auto. The only way to do that is something like the following:
.container {
view-transition-name: container;
view-transition-tree: preserve;
view-transition-parent: none;
}
.container > * {
view-transition-parent: auto;
}
which seems unintuitive
from csswg-drafts.
One approach would be to make view-transition-parent an inherited property
We don't need it to be an inherited property for this. A simple descendant selector will do it, though it reads kinda awkward.
.container {
view-transition-name: container;
/* Parent all named children to me. */
view-transition-tree: preserve;
}
.container * {
/* Actually, don't. */
view-transition-parent: none;
}
I think whether or not view-transition-parent should be inherited is a worthwhile topic on its own
That's true! I'm not sure about this: "since if an element wants to have a different parent, presumably all its children by default also want to have that parent?". I expect the common case would be for that element's children to be parented to it. Something like:
.container {
/* Parent me to foo */
view-transition-parent: foo;
/* Parent all named children to me */
view-transition-tree: preserve;
}
In fact since the proposal above is for view-transition-parent
to have preference over view-transition-tree
, in the above example inheriting view-transition-parent
would mean the author has to remove it.
from csswg-drafts.
One thing I’m not entirely convinced of is the fact that the containers in the given example need to have a view-transition-name
although these containers themselves don’t actually transition. Only reason to do this, is to enable clipping. Feels like a technicality that puts extra load on the author and also increases the number of captured elements.
Maybe there could be a way to mark element to become a “view transition container” that automatically clips its participating contents without the container itself moving around or stuff? I’m leaning towards CSS Containment for this.
-
Example using keywords:
-
CSS:
.container { container-type: view-transitions; /* Capture my dimensions and use it to clip the VT snapshots contained */ } .card { view-transition-name: auto; view-transition-container: nearest; /* default */ } .card-switching-containers { view-transition-name: the-card; view-transition-container: none; /* render as direct child of the ::view-transition pseudo */ }
-
Resulting Tree:
::view-transition |__ ::view-transition-group(root) |__ ::view-transition-container(container-1) | |__ ::view-transition-group(card1) | |__ ::view-transition-group(card2) |__ ::view-transition-container(container-2) | |__ ::view-transition-group(card3) | |__ ::view-transition-group(card4) |__ ::view-transition-group(the-card)
-
-
Example using a named container:
-
CSS:
.container { container-type: view-transitions; } .containers-wrapper { container: containers-wrapper / view-transitions; /* Named container */ } .card { view-transition-name: auto; view-transition-container: nearest; /* default */ } .card-switching-containers { view-transition-name: the-card; view-transition-parent: containers-wrapper; /* render in the containers-wrapper pseudo */ }
-
Resulting tree:
::view-transition |__ ::view-transition-group(root) |__ ::view-transition-container(container-wrapper) |__ ::view-transition-container(container-1) | |__ ::view-transition-group(card1) | |__ ::view-transition-group(card2) |__ ::view-transition-container(container-2) | |__ ::view-transition-group(card3) | |__ ::view-transition-group(card4) |__ ::view-transition-group(the-card)
-
Setting container-type
to view-transitions
basically does the view-transition-tree: preserve
thing covered in this thread.
from csswg-drafts.
Only reason to do this, is to enable clipping. Feels like a technicality that puts extra load on the author and also increases the number of captured elements.
So if the element is container only, it's painted content draws into its ancestor's snapshot (as usual) but there is a group pseudo-element generated to mirror its geometry and parent its descendant named elements. If the goal is just to optimize out redundant snapshots, then the browser can do this automatically. If the container has no painted content, we optimize out its snapshot. So I'm hesitant to add this paradigm unless needed for a use-case, for example, the element has painted content which needs to draw into its ancestor instead of underneath its own group pseudo.
from csswg-drafts.
I've heard several requests for this. E.g. https://x.com/spinbutton/status/1792914789452140789?s=46&t=0fEqkKvBXH87vG_Sqv-Tbg
from csswg-drafts.
I've heard several requests for this.
Sorry I didn't mean use-cases for the feature itself. It's for an approach where requiring a name on the container wouldn't work because the author didn't want to lift the container's painting from its ancestor, just a group pseudo to mirror it's box.
from csswg-drafts.
Related Issues (20)
- [selectors][css-transitions-2] `:starting-style` pseudo-class HOT 10
- [css-grid] respect `justify-content: center` even when column width is fluid and has max-width using `auto-fit/fill` HOT 1
- [css-syntax] Concrete criteria for rule / declaration validity when being produced by a [compliant] parser? HOT 4
- [css-color-5] Clarification on `none` components in relative color syntax.
- [css-anchor-position] Drawing irregular shapes between two items HOT 1
- Custom state pseudo classes are changing from ":--muted" to ":state(muted)" soon???
- [css-text-3][css-text-4] Japanese small kana and `line-break: normal` HOT 1
- [css-view-transitions-2] Support same-site cross-origin view transitions HOT 10
- [css-anchor-position] Make anchor-center work without position-anchor HOT 2
- [css-colors-4] Clip negative whiteness/blackness of `<hwb()>`? HOT 1
- [css-animations] Handling values where endpoints are valid, but midpoints are IACVT HOT 2
- [css-cascade-6] Publish an updated WD HOT 3
- [css-properties-and-values-api] Resolved value of registered <color> custom properties. HOT 2
- [css-color] Mitigating fingerprinting for AccentColor/AccentColorText HOT 9
- GoGab
- [css-images-4] Gradient interpolation doesn't specify how to handle positionless stops at computed-value time
- [css-font-loading] CSS-connectedness of @font-face rules in constructed stylesheets
- [css-ui] DOM/Box structure for appearance:base-select
- [css-ui-4] Extend `outline` to include offset
- [css-contain] Describe generalized goals containment
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from csswg-drafts.