Preview: https://patternfly-pr-7487.surge.sh

A11y report: https://patternfly-pr-7487-a11y.surge.sh

Can we please try --pf-t--global--motion--duration--md for the expand/collapse durations.

@andrew-ronaldson used --pf-t--global--motion--duration--fade--default for both the opacity and slide durations. I've left those durations separate in the code so we we can make separate durations for expand-slide, expand-opacity, collapse-slide, and collapse-opacity.

If you want to take a stab at tweaking any of these yourself, you can do this in the PR. In dev tools, just select the expandable section you want to modify and in the HTML, be sure to select the .pf-v6-c-expandable-section outer wrapper for the one you're modifying. Then for the "element style" box on the right, add these 4 properties and set whatever you want as the values (instead of 1s, 2s, 3s, 4s)

    --pf-v6-c-expandable-section__content--TransitionDuration--collapse--fade: 1s;
    --pf-v6-c-expandable-section__content--TransitionDuration--collapse--slide: 2s;
    --pf-v6-c-expandable-section__content--TransitionDuration--expand--fade: 3s;
    --pf-v6-c-expandable-section__content--TransitionDuration--expand--slide: 4s;

@andrew-ronaldson some wonderful comments from @thatblindgeye with my responses inline

Detached implementation will rely on the expanded class on the expandable content to animate, but the animation also behaves the same as non-detached (animates upwards while disappearing)

FYI detached just means the toggle and expandable content aren't one single HTML block. They can be right next to one another, or the toggle could be in a toolbar and the content could be in a separate page section. Also that means the expanded content could be on any side of the toggle. We have a variation of the expandable toggle (just the toggle, not the content) for direction="up" that just flips the little caret to point up when expanded instead of down. We also have isDetached for the expandable content to indicate it's detached from the toggle. However, there is no designation in core that you're using a detached expandable section. Some thoughts on how to approach:

• Seems like we need to add a direction prop (and CSS class in core) for detached expandable content when using direction="up" on the toggle, so that both the content and the toggle know which direction the content is expanding.
• The animation needs to be opt-in in core. If a user has a detached expandable section with their expandable content above the toggle, we have no way of knowing 1) that it's detached, and 2) which direction the expandable section should slide in from, so by default it would slide down when it should slide up instead, and I think that would be breaking since a user would have to add a class to their expandable content to fix the animation direction.
  • Alternatively, the animation could just fade by default instead, and you opt in to the directional animation, but for core users, the default animation would be a fade for both detached and non-detached expandable content.
• For react, add a direction prop to the expanded content, too. But that's something users would have to manually opt in to if using isDetached.
• The animation should probably be opt-in in react, too. And if you opt in to the animation, then we can state that if you're using isDetached, then you'll need to add a direction prop to the expandable content if you've specified a direction on your toggle (so that both will animate up instead of down).
  • We could possibly make it not opt-in if the default animation for isDetached were a fade instead of the fade/slide, and then we can say "if you're using isDetached, add a direction to your expandable content to get the slide animation".
• TL;DR - I think the whole animation should be opt-in, and we note that if you're using isDetached with direction="up" on the toggle, add direction="up" to the expandable content as well.
• @thatblindgeye curious what you think!

Truncate variation makes all the content disappear when toggling that expanded class with animations, whereas currently on Org removing the class only makes the expandable content become hidden

D'oh! Good catch, I missed that. The way that truncates is using line-clamp - I don't even know if you can animate that, and it likely wouldn't be performant. Without refactoring the truncate variant to use another way of truncating based on line number, I'd say we just don't animate it. Cool with you @andrew-ronaldson?

Disclosure variation has a little bumping when that class is added and removed (though probably expected since the bottom padding looks to change base don the state)

Also great catch. Delayed that padding change so it matches when the expandable content is shown/hidden.

In addition to the above, looks like React will have to handle when to apply that hidden attribute to the expandable content element. Right now the animations don't occur in React since the content is being hidden before the animations can really happen (or perhaps rather, be seen).

Just removing that hidden attribute in React and updating the pf-m-expanded class in dev tools as noted above does trigger the animations, though, and I'm seeing the same issues as my commentes noted from Coker above

Shortened the collapse duration, changed the slide amount from 1rem to .5rem. Also reversed the role of the --expand and --collapse vars so their values are for the "expand" and "collapse" animations respectively.

🎉 This PR is included in version 6.3.0-prerelease.11 🎉

The release is available on:

• GitHub release
• npm package (@prerelease dist-tag)

Your semantic-release bot 📦🚀