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

**URL:** <https://discourse.elm-lang.org/t/elm-ui-parent-element-grows-to-encompass-children-instead-of-scrolling/5032>\
**Category:** Learn\
**Created:** [January 20, 2020, 8:05pm UTC](https://discourse.elm-lang.org/t/elm-ui-parent-element-grows-to-encompass-children-instead-of-scrolling/5032 "2020-01-20T20:05:07Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ictor](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/ictor/32/2884_2.png) [@Ictor](https://discourse.elm-lang.org/u/Ictor)\
**Post date:** [January 20, 2020, 8:05pm UTC](https://discourse.elm-lang.org/t/elm-ui-parent-element-grows-to-encompass-children-instead-of-scrolling/5032/1 "2020-01-20T20:05:07Z")

</div>

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](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](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 `el`s.

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?

---

<div class="post-metadata">

**Author:** ![paulh](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/paulh/32/5022_2.png) [@paulh](https://discourse.elm-lang.org/u/paulh)\
**Post date:** [January 22, 2020, 11:09am UTC](https://discourse.elm-lang.org/t/elm-ui-parent-element-grows-to-encompass-children-instead-of-scrolling/5032/2 "2020-01-22T11:09:16Z")

</div>

> [@Ictor](#):
>
> I thought `height fill, width fill` means that the element fills the available space in the parent and then those dimensions are fixed.

`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 `overflow`ing. 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.

---

<div class="post-metadata">

**Author:** ![Atlewee](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/atlewee/32/4603_2.png) [@Atlewee](https://discourse.elm-lang.org/u/Atlewee)\
**Post date:** [January 22, 2020, 11:17am UTC](https://discourse.elm-lang.org/t/elm-ui-parent-element-grows-to-encompass-children-instead-of-scrolling/5032/3 "2020-01-22T11:17:02Z")

</div>

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](https://ellie-app.com/7Q6YNHTVp69a1)  
(dont know why the extra outher scrollbar appers)

---

<div class="post-metadata">

**Author:** ![Ictor](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/ictor/32/2884_2.png) [@Ictor](https://discourse.elm-lang.org/u/Ictor)\
**Post date:** [January 22, 2020, 6:38pm UTC](https://discourse.elm-lang.org/t/elm-ui-parent-element-grows-to-encompass-children-instead-of-scrolling/5032/4 "2020-01-22T18:38:05Z")

</div>

> [@paulh](#):
>
> 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 `overflow` ing. If you replace `height fill` with `height <| px 500` on the parent `column` of the `textbox` you will get your desired behaviour.

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.

> [@Atlewee](#):
>
> Here is an ellie where you get the desired result: [https://ellie-app.com/7Q6YNHTVp69a1](https://ellie-app.com/7Q6YNHTVp69a1)  
> (dont know why the extra outher scrollbar appers)

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.

---

<div class="post-metadata">

**Author:** ![Ictor](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/ictor/32/2884_2.png) [@Ictor](https://discourse.elm-lang.org/u/Ictor)\
**Post date:** [January 22, 2020, 7:01pm UTC](https://discourse.elm-lang.org/t/elm-ui-parent-element-grows-to-encompass-children-instead-of-scrolling/5032/5 "2020-01-22T19:01:18Z")

</div>

> [@Ictor](#):
>
> 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:

> <https://github.com/mdgriffith/elm-ui/issues/149>
>
> When putting a \`row \> column \[scrollbarY\]\` inside any \`row\`, \`column\` or \`el\`, t…he scrollbar does not show.
> The SSCCE from Ellie is available \[here\](https://ellie-app.com/6Ccz5SHJBrsa1).
> 
> \*\*Expected behavior\*\*
> There should be a scrollbar for the column, regardless of how it is nested.
> 
> \*\*Versions\*\*
> - OS: macOS Mojave 10.14.5
> - Browser and version: Safari 12.1.1, Firefox 69.0, Chrome 76.0.3809.132
> - Elm Version: 0.19.0
> - Elm UI Version: 1.1.5

I applied the workaround mentioned in the issue, and it worked!  
[https://ellie-app.com/7QfN86Gf2Bxa1](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 😟

**Edit:** This also seems relevant [Scrollbars within a row require manual setting of `flex-shrink` and clip · Issue #12 · mdgriffith/elm-ui · GitHub](https://github.com/mdgriffith/elm-ui/issues/12)

---

<div class="post-metadata">

**Author:** ![Ictor](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/ictor/32/2884_2.png) [@Ictor](https://discourse.elm-lang.org/u/Ictor)\
**Post date:** [January 22, 2020, 7:40pm UTC](https://discourse.elm-lang.org/t/elm-ui-parent-element-grows-to-encompass-children-instead-of-scrolling/5032/6 "2020-01-22T19:40:02Z")

</div>

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")
```

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/elm_lang/original/1X/50a05e53677a2c3b47776d7abd0f113eb50193a1.png) [@system](https://discourse.elm-lang.org/u/system)\
**Post date:** [February 1, 2020, 7:55pm UTC](https://discourse.elm-lang.org/t/elm-ui-parent-element-grows-to-encompass-children-instead-of-scrolling/5032/7 "2020-02-01T19:55:44Z")

</div>

Closed on February 1, 2020, 7:55pm UTC

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