Elm Animator - animating the height of an element

[paulh]

I’ve been trying to animate the height of an element so that it reveals an error message underneath an input field, and was wondering if anyone could explain what’s going on here - it had me going round in circles for a while, and the wall began to look very appealing to my head…

The problem I was having was that the text was not being hidden in Chrome, although I later discovered that it was hidden correctly in Safari (OSX). I normally just use Chrome to test in initially, then when I’m happy with things I check it on other browsers, so I was only seeing the failure case for code that looked like it should be working.

I now have it fixed, but am wondering why the fix is needed, if it’s a bug, or just some quirk between browsers.

The fix is to explicitly set the height of the element being animated to 0px.

There’s a simplified example Ellie here: https://ellie-app.com/8H8sYhW48c9a1

Line 76 in the Ellie is where the height is set to 0px, if you remove this line you will see that in Chrome the text is not hidden, in Safari it is.

As you will also see in the Ellie, I am using Animator.Inline.style to animate the height which is initially set to 0px until the animation is activated. Therefore, I figured this would be the initial height of the element containing the text, and the text would be clipped accordingly. When I took a look under the hood at the HTML, the inline style for the element was set to 0px, and if I set the animation to run for a few seconds, I could see that the height in the inline style was being updated correctly.

Looking further, I found that it appears to have something to do with flex-basis, which, when I looked at the MDN docs…

I’ll stop right there because I’ve just re-read the docs on MDN while writing this, and see that flex-basis is relevant to height only in the case of flex-direction : column. So I’ve just changed my container from Element.el to Element.column and the ‘fix’ described above is no longer required. Everything works as intended across all browsers (haven’t tested on IE).

I’d still be interested to know a bit more about this situation though if anyone can elaborate, (@mdgriffith (?))

Why does the ‘fix’ above work on an Element.el? Should we be able to animate the height of an Element.el without the ‘fix’? Has this all come about due to a gap in my knowledge? (I can take a hit )

Thanks to anyone that can shed some light on this for me.

[mdgriffith]

Hello!

Unfortunately I don’t have an exact answer for you

So, this was one of the reasons I decided to initially release elm-animator without direct elm-ui support, namely that CSS is super complicated and integrating it in a sane way with elm-ui would be a bunch of work on top of building the animation engine itself.

But, I feel you. I’ve definitely wrestled with these sorts of frustrations so many times. Heck, this sort of thing is the primary motivation for building elm-ui in the first place.

unfortunately that’s all I have time for right now as I’m deep in a project, but I wish you good luck! Hopefully someone else can jump in.

[alexkorban]

I don’t really have an answer, but I think this is something to do with flexbox rather than elm-animator. There are a few known issues in elm-ui which are all to do with flex-basis:

• https://github.com/mdgriffith/elm-ui/issues/191
• https://github.com/mdgriffith/elm-ui/issues/190
• https://github.com/mdgriffith/elm-ui/issues/147

[paulh]

Thanks for the info, I wondered why elm-ui wasn’t supported out of box, now I understand why.

I had a height animation working already, so trying to figure out why this particular one wasn’t was making me think I was going mad . I was just lucky the first time around that the element needed to be a column

At least I’ve learned something today; use a column when I need to animate an elements’ height - which isn’t tough to remember as it almost, kinda, makes sense, in away.

Cheers for taking the time away from your project to reply it’s appreciated.

[paulh]

Yes, thanks for the links, I’ll keep them in mind going forward, along with the fixes you mention in 190 and 191.