[elm-ui] Parent element grows to encompass children instead of scrolling

I want to have a textbox in my view that gets a scrollbar when there’s too much text. Here’s the desired behavior:

https://ellie-app.com/7Pp6xNtCFy8a1

But I can’t get it working when this textbox is nested deeper into the view (inside multiple layers of row and column). What I see instead is the parent element growing to accommodate the size of the text. For example:

https://ellie-app.com/7PpgS4j724Sa1

Changing the column marked -- middle layer to a row gives the desired behavior. I tried to play with where I insert the scrollbarX, inserting scrollbarX on multiple layers, adding clipX, changing the innermost node from paragraph to text inside an el and so on, but I can’t get it to work. The problem persists if instead of text I use a very tall column of els.

This seems to break composability of the library. It’s also incompatible with my model of how elements are sized. I thought height fill, width fill means that the element fills the available space in the parent and then those dimensions are fixed. Is that wrong?

fill will fill the available space if the content is smaller than its’ parent.

If the content is larger than the parent then you will still get overflow (fill will not prevent this), however, this is where the scrollbar and clip functions come into play - but they need to know where to clip and scroll. fill does not provide sizing information to these functions, so if the parent has height fill, clip and scrollbar do not know where to clip or scroll. If the height or width of the parent is set to a specific size, then clip and scrollbar do know where to clip and scroll.

So, the reason your second example doesn’t work as you expect, is because the parents of the textbox have height fill, which results in those elements overflowing. If you replace height fill with height <| px 500 on the parent column of the textbox you will get your desired behaviour.

The reason the overflow is only vertical, is because of your use of paragraph, which will respect the first specific width set by a parent/grandparent, in this case px 500. If you change paragraph to el you will see the content overflow horizontally.

I have found that whenever I get an issue with scrollbars I just pass down “scrollbars” or “scrollbarY” from the top level and downwards. This is typically only needed when you have dynamically sized containers. If you set height (px 500) on the actual element you want scrollbars for, you dont need to do this.
Here is an ellie where you get the desired result: https://ellie-app.com/7Q6YNHTVp69a1
(dont know why the extra outher scrollbar appers)

That’s unacceptable because it throws responsiveness out of the window! The whole point of a layout engine is that I don’t have to manually size and position each element.

I can give the topmost element a fixed size using Browser.Dom.getViewport, but that’s it.

Ouch, that extra scrollbar is a sore, but this is probably what I’ll have to do. Thanks.

So far this seems like a bug? I imagine this is a usecase that should be supported.

I went on to look at the github issues of elm-ui and, sure enough, it is a bug:

I applied the workaround mentioned in the issue, and it worked!
https://ellie-app.com/7QfN86Gf2Bxa1

Sadly, it doesn’t work in my production code, either. I guess the dream of never writing CSS again is still out of reach :worried:

Edit: This also seems relevant https://github.com/mdgriffith/elm-ui/issues/12

Got it! It works in my production view now.

Add the following attributes to the first row ancestor:

 , Element.clip
 , Element.htmlAttribute (Html.Attributes.style "flex-shrink" "1")

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.