Size Change: 0 B

Total Size: 8.75 MB

_{compressed-size-action}

Flaky tests detected in 0de2140.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/23196476077
📝 Reported issues:

• [Flaky Test] post title and content are editable and blocks can be inserted #76524 in /test/e2e/specs/editor/various/post-content-focus-mode.spec.js
• [Flaky Test] should not highlight more than one format #48529 in /test/e2e/specs/editor/various/rich-text.spec.js

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ciampo <[email protected]>
Co-authored-by: jameskoster <[email protected]>
Co-authored-by: jasmussen <[email protected]>
Co-authored-by: fcoveram <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

The animation likely needs refinements. Happy to apply any feedback myself, but also feel free to take over this PR (especially from @WordPress/gutenberg-design ) and apply changes directly.

Nice work. I'd love @fcoveram input if he has capacity, he's been looking into adjacent behaviors for the command palette, seems like principles here could/should be the same.

The main thing that I'm personally stuck on is: the animation here is a a little bit of flair applied to the contents, which move and fade in. In fact to be true to the materials, if we imagined this was a physical card that was somehow folded (I know, physical cards don't behave like this), then the contents inside would not be animated at all: that would be printed on the paper itself, immutable. The thing that would animate is the card itself. So in that vein, this feels a bit upside down to me, I'd expect the text that gets revealed to always be visible, to not animate, to not fade, but for the card itself to disclose it with animation.

Can the card itself animate instead of the contents?

Can the card itself animate instead of the contents?

It technically can, but since cards are often part of the document flow, animating the card itself would also animate the layout of the surrounding content. On long settings pages this could feel visually overwhelming, since a large portion of the page would be shifting at the same time. It may also be more expensive performance-wise compared to animating only the inner content.

but since cards are often part of the document flow, animating the card itself would also animate the layout of the surrounding content

Valid and good point, though is there a way we can avoid that while still embracing the concept? Something like jump almost to the end of the animation and animate only the last 5% of the height? Perhaps even reserving the final height space already, so there's only a single jump in the content.

The alternative breaks principles as far as what gets animated, IMO. Not a strong opinion and will definitely defer to others, but I'd almost prefer no animation in this case.

Something like jump almost to the end of the animation and animate only the last 5% of the height? Perhaps even reserving the final height space already, so there's only a single jump in the content.

This feels a bit difficult to implement / overengineered.

Another alternative solution to evaluate could be to:

• make the layout "jump" instantly, occupying with empty space the expanded card's height
• animate the card's height without causing animated layout reflows (since the initial jump already reserved the space)

It's still a non-trivial animation to implement. Let's hear other folks' thoughts before moving forward.

Happy also to implement a few variations (full height animations, or the most advanced behaviours discussed above) to get a better feeling for it

I do agree that animating the root would be nice to try (like Collapsible/Accordion in Base UI), but I don't think it needs to hold up this work which is a nice enhancement by itself. Seems fine to explore in a follow-up.

…if we imagined this was a physical card that was somehow folded (I know, physical cards don't behave like this), then the contents inside would not be animated at all: that would be printed on the paper itself, immutable. The thing that would animate is the card itself.

Agree with this approach.

Another alternative solution to evaluate could be to:

• make the layout "jump" instantly, occupying with empty space the expanded card's height
• animate the card's height without causing animated layout reflows (since the initial jump already reserved the space)

I’m not sure about this solution. There will be a small portion of time where the white space is visible.

In that vein, the base UI examples shared by Jay move the whole layout, and it doesn't feel distracting. I feel the outcome will be similar to the update in popover (#74082).

@fcoveram as shared before, given how often CollapsibleCard is going to be rendered in content-heavy pages (eg settings pages with many cards stack up), I'm afraid it will lead to two main issues:

• cognitively, causing large portions of the page to all animate at once, which can feel overwhelming
• potentially janky animations (every height change causes the browser to re-calculate the page layout and re-paint every frame, which can be quite expensive)

Which is why I discouraged animating the height like in the Collapsible base ui examples shared above.

Having said that, I went ahead and implemented it.

Happy to follow your guidance here on the next steps, including trying this animation and coming back to the drawing board if needed

@ciampo would it be worth adding a (maybe temporary) story with multiple stacked collapsible cards with varying content to test?

cognitively, causing large portions of the page to all animate at once, which can feel overwhelming

I understand, but I also don't see a solution where the implementation doesn’t account for the layout and how the card is placed next to other content.

potentially janky animations (every height change causes the browser to re-calculate the page layout and re-paint every frame, which can be quite expensive)

I follow your expertise here.

The video shared above looks good to me. Nothing to add from the visual and interaction side.

Added a storybook example. Here's a video

It doesn't look too bad, but also, Storybook is not as complex as a real app, and my machine is quite fast.

Still, I believe we should ship this and keep an eye. Removing the animation wll be easy and non-breaking, anyway.

I think this is fine. Seeing a big stack of collapsible cards like that makes me a bit cold on the pattern in general; it's so easy to lose your place in the document when you begin expanding/collapsing, especially as scroll position can change. We might want to add some guidance about that (separately). That would help with any performance concerns too.