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:
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.
