Add a height argument to st.container and st.expander

[durandg12]

Problem

I want to display a large (i.e. with a lot of lines) text output (say, logs from a simulation) and I would like to constrain the space used by this output. So if the size of the text exceeds the allocated space, then the user has to scroll inside the widget. I previously did it with two unsatisfactory hacks. The first was to use st.text_area like this:

import streamlit as st

constrained_height = 50
large_text_output = "".join([f"Line number {i}\n" for i in range(100)])

st.text_area(label="This is the output", value=large_text_output, height=constrained_height)

This is not ideal given that I want my text to be an output, I don't want the user to interact with it and modify it. I found the second hack when I discovered components. It goes like this:

import streamlit as st
import streamlit.components.v1 as components

constrained_height = 50
large_text_output = "".join([f"Line number {i}\n" for i in range(100)])

components.html(
    "This is the output:<br>" + large_text_output.replace("\n", "<br>"),
    height=constrained_height,
    scrolling=True,
)

Again, this is not ideal because the output does not look like the classic output of st.write.

Furthermore my two hacks actually require that I append all my logs in a single string to be displayed later, I can't write them "on the fly", as they are produced.

Solution

I just discovered the new beta containers, and I find that they are great. They even come with a context logic (with container) that allows to write in them on the fly. The solution to my problem is very simple. Add a heightargument similar to the arguments of st.text_area and components.html to the new st.beta_container and st.beta_expander. This way, containers can truly act as modular minipages.

---

Community voting on feature requests enables the Streamlit team to understand which features are most important to our users.

If you'd like the Streamlit team to prioritize this feature request, please use the 👍 (thumbs up emoji) reaction in response to the initial post.

[nthmost]

Hi @durandg12 ,

Thanks for the suggestion! That all makes sense. We're happy to see people (like you) pushing the limits of the new layout options and will definitely file your use case into the next round of considerations for streamlit's layout expansion.

[totalhack]

Are there any plans to get this implemented soon, or other workarounds with streamlit updates over the past 2 years?

[InitialDW]

Plus 1 for this, it'd be very nice to have a way to limit a container/expander height.

[DiTo97]

Is there a roadmap for the addition of this feature? If yes, I hope you can share it; otherwise do you have any hacky suggestions to allow the creation of fixed size containers, with potentially many items, with a non-trivial UI (i.e., not string-only text areas)?

The feature request has been open for over two years now, so I hope you can listen to us Streamlit-ers, @nthmost

[simonfromla]

+1 Would love to see this implemented!

I've tried bringing in bootstrap cards as containers via st.markdown but it is not ideal as it doesnt allow for more complex python objects to be generated inside.

[AleCioc]

+1 for me too, this feature would be incredibly useful for layouts.

Any news at all?

[sfc-gh-jrieke]

Hey all! We don't have any concrete plans to implement this at the moment. But it's not unlikely we'll do it at some point! I think we'll need a bit of design magic to clearly show to viewers that there's a separate scroll surface from the rest of the app. Otherwise this will quickly be confusing.

If you have any concrete examples/sketches/screenshots, please post them below! That will help us find a good solution.

For updates, you can also follow our public roadmap: https://roadmap.streamlit.app/

[jrieke]

6949 wants this specifically for chat.

[ehartford]

how to do this? not very useful if I can't constrain height

[sfc-gh-jrieke]

We're working on this right now! 🎉 We're adding a height parameter to st.container that lets you specify the height in pixels. If the elements in the container overflow, we will enable scrolling on the container. See #7697.

[lukasmasuch]

Streamlit 1.30 will have scrolling support for st.container. This also allows to add scrolling to st.expander by combining it like:

with st.expander("Expander with scrolling content"):
   with st.container(height=200):
       st.write("Inside scrolling container")
       ...

[ehartford]

Thank you!

[Zimix0]

1.30

Streamlit 1.30 will have scrolling support for st.container. This also allows to add scrolling to st.expander by combining it like:

with st.expander("Expander with scrolling content"):
   with st.container(height=200):
       st.write("Inside scrolling container")
       ...

hello ，what is the expected release date for streamlit 1.30

[jrieke]

January 11!

[sfc-gh-jesmith]

st.container can be now configured with a height to create grids or scrolling containers in release 1.30.0: https://docs.streamlit.io/library/changelog#version-1300!

Thanks again for your input and contributions which helped bring this feature to life.🥳  Looking forward to seeing how you utilize scroll containers in your apps. Feel free to share on the forum (https://discuss.streamlit.io/) so the community can see and learn from you!

[wullli]

Is there a reason why this is limited to pixel units? I would assume most people would like to set height dynamically (em, %, vh, vw, etc.)

Why not something like this:

with st.expander("Expander with scrolling content"):
   with st.container(height=10, unit="em"):
       st.write("Inside scrolling container")
       ...

You could keep the default value for unit as "px", so no incompatibility.

[Gian44]

Is there a way to implement the autoscroll now in the containers?