altair_chart height computation broken for plots with yOffset since 1.34

[velochy]

Checklist

• I have searched the existing issues for similar issues.
• I added a very descriptive title to this issue.
• I have provided sufficient information below to help reproduce this issue.

Summary

It seems something changed in the plot height computation for altair_chart in 1.34 that changes it's behavior to be incompatible to how plots display in other places (like in jupyter). The new behavior seems to force a fixed height, compressing bars down very thin. I have included screenshots of both old and new behavior.

Now the toy example i posted below might not look very bad compressed, but I assure you it is a very real problem in some more complex use cases. Attached is a before-after of a boxplot I have in an active dashboard, both before and after:

Before (i.e. version 1.33.0):

After (i.e. version 1.34.0):

Reproducible Code Example

import altair as alt
import streamlit as st
from vega_datasets import data
source = data.barley()
chart = alt.Chart(source).mark_bar().encode(
    color="year:O",
    x="yield",
    y="variety",
    yOffset="site",
)
st.altair_chart(chart)

Steps To Reproduce

Just run the example

Expected Behavior

Current Behavior

Is this a regression?

• Yes, this used to work in a previous version.

Debug info

• Streamlit version: 1.34.0
• Python version: 3.12
• Operating System: Ubuntu linux
• Browser: Firefox

Additional Information

No response

[github-actions]

If this issue affects you, please react with a 👍 (thumbs up emoji) to the initial post.

Your feedback helps us prioritize which bugs to investigate and address first.

[kmcgrady]

Hey @velochy Thanks for the issue!

This is very likely due to this change #8497. This was to solve another problem where some situations when the discrete height is not directly set, the chart doesn't display.

There's a few possible solutions.

1. Streamlit should provide reasonable defaults, and users can override. So if you want to get the chart back, you can set discrete height (I believe adding .properties(height=YOUR_DESIRED_HEIGHT) would work). This has tended to be the policy of the past. For what it's worth, we do this along side continuous graphs.
2. We can also, not provide the "reasonable default" and undo the change and tell people to directly set the height.
3. We can adopt the standard like discrete width and discuss the idea of a step, this can make the height more dynamic, but keep it reasonable looking. I would have to test it with our test cases to see if they work (It just will affect different graphs).
4. Another solution I haven't thought of.

I'll think on this more, but any thoughts would be appreciated.

[velochy]

Can't you just set 'discreteHeight':{'step':20} instead of 350 in the theme? Overriding that setting to that value with .configure_view() fixes the display for me, and it should leave the other issue of altair needing to know height still solved :)