Issue

When querying the container the calculated height of the container freezes (intended).

For shallow DOM trees this doesn't seem to be an issue as the DOM traversal is fast. For massive DOM trees finding the node does take some time, this was tested by placing a Process.sleep before the DOM query.

Possible solution

Make querying the DOM non-blocking if there is a current animation in progress.

Context

The id that is queried lives on the animate-height-container not the animate-height-content. This causes issues then the content changes and we want to animate height the the new content height, specifically when the content height is reduced.

Proposed solution

Place the Id on the content so the dynamic height of it is queried rather than the container height.

If the containers content can resize due to a viewport change, the height information will not be current.

For example if a container is at content height at 200px then the user resizes the viewport to make it wider. The content subsequently adjusts to fill the extra width and now takes up 100px. The container will still be set at 200px.

Possible solution

• Make the container snap to content when it detects a viewport change. Could be expensive, may need to throttle event and only snap on last viewport change after time limit. Gizra/elm-debouncer

Context

When a container is at height auto all dynamically added content that is added to the container automatically increases the height of that container. This can be fine for some views but in general it produces a janky experience as the container snaps to the new content, shifting all content rendered below it.

Proposed solution

Create a way to recalculate the height of a fixed container so it can render to a new height when content is added.

Perhaps a fixedAtAuto could animate the height to a fixed value of the container as if it where auto. This way new content could be added and then calling fixedAtAuto would animate to the new height.

In this scenario the consumer would need to ensure fixedAtAuto be called every time they add new content to the container or else it would not animate.

Context

It very common to want to render different views in the same AnimateHeight container. To ensure the user has a great experience and not have to deal with content height snapping, and assuming they do not have any reduced motion requirements, a smooth transition between heights is by far the best and smoothest experience.

For example, cross fading smoothly between any render states that might abruptly change the height of a section are great candidates for this feature.

I don't feel AnimateHeight is overreaching here as the functionality is chiefly one concerning height.

Context

When auto animating to a height, the css property height is set to auto at the end of the animation to a height > 0. This allows any new dynamic content that shows up to auto adjust the container height.

The overflow property remains hidden however which means that any absolute positioned elements that render proud of the container are cut off.

Proposed solution

Set overflow property to visible when the height property is auto.

When recalculations are performed rapidly one after the other the container animates to 0 pixels when it shouldn't.

Background

In order to correctly animate the a height we copy the content that is passed and put it into an invisible sizer div which we poll for height info. That sizer div has its position set to absolute to keep it out the way.

Issue

Because it is position: absolute; it is prone to allow the contents height to be that of any container divs outside of a AnimateHeight container.

Possible solution

Remove the position: absolute; property and just let the sizer div be part of the DOM flow. Its height is set to 0px anyway so it shouldn't cause too many issues.

Issue

During interrupts and recalculations durations are calculated. With AnimationFrame we calculate a new duration based off of the current height. It is trickier to do this with Transition as we don't track a current height.

Because of this the interrupt/recalculation durations that are calculated are different between Transition and AnimationFrame strategies.

Possible solutions

Transition css duration values change dynamically during recalculations and interrupts. Calculating these values the same as the AnimationFrame values will populate the duration css value automatically.

When a container is animating high and we interrupt its animation the intended behaviour is that it animates low with an interrupt.

Current behaviour doesn't trigger an interrupt and the duration timing is off.

Context

The heightAt function allows the user to set the initial height of the container without animating to it.

Current behaviour

Using heightAt with fixedAtAuto doesn't set the height to a fixed value, instead it sets it to auto.

Expected behaviour

When using heightAt with fixedAtAuto I would expect the container to be set at the fixed height of auto without any animations.

state |> heightAt fixedAtAuto

When there is a recalculation and the container animates to 0 the next animation high snaps to its height instead of animating.

On occasion When recalculating the container to min height then calling toMinHeight during the recalculation, the container doesn't resolve to its lowest position. Instead it snaps to the container content height.

For Transition, I suspect the issue is because the time keeping does not match the css transition perfectly. May need a small time extension.