Just like in the codepen above, I dymaically add a is_closing attribute of true to the element when it’s clicked in order to change various css properties (height, opacity and overflow).
There is one issue though. My proof-of-concept implementation requires an explicit height value so that the css transition can go from some known height down to 0 smoothly.
Without an explicit height, the animation does not work, and the element’s CSS properties change immediately without a transition. If you want to see what I mean, remove the height CSS property from the #info-box selector, or make the height value auto. Then you’ll see that the animation no longer works.
An easy fix would be to add height (px whateverHere) in my elm code, but I don’t want to hard-code a height on my actual elm implementation because that would mean that the alert’s height doesn’t automatically adjust to the contents of the alert component.
What I’m considering doing is querying the DOM using Browser.Dom.getElement in order to retrieve the height of the rendered element … but this just seems hacky in my opinion.
I am also trying to not use 3rd party packages either as most of them impose a particular way of doing things that would cascade down to users of elm-antd.
Any suggestions on how to address this? Maybe there’s an entirely different way of doing this animation that is a lot simpler?
Why does that seem hacky to you? The dynamic height needs a dynamic solution … If the css transition does require a fixed height, this seems straightforward…
Suppose there are 3 alerts on the page, all of which have different heights. For each alert I need to generate a unique id value to call Browser.Dom.getElement and get the correct value back. Generating unique ids would likely impact the user-facing API of the alerts. And I want to make sure that the alert API is intuitive and simple.
According to the Mozilla Developer Network docs, auto values have been intentionally excluded from the CSS transitions spec. It looks like it’s been requested by a few people, but when you think about it, it makes at least a little sense that it hasn’t been included. The browser process that re-calculates the sizes and positions of all elements based on their content and the way they interact with each other (known as “reflow”) is expensive. If you were to transition an element into a height of auto , the browser would have to perform a reflow for every stage of that animation, to determine how all the other elements should move. This couldn’t be cached or calculated in a simple way, since it doesn’t know the starting and/or ending values until the moment the transition happens. This would significantly complicate the math that has to be done under the hood and probably degrade performance in a way that might not be obvious to the developer.
I’m beginning to think that I’m going to need to add an animation library. But because of the optimizations that elm does to reduce asset size, I think my concerns are less relevant - as long as the API for Alert remains simple and intiutive.
