More button types and colors

[murtazabasu]

Hello, I want to customize buttons with different styles. I am already using a local_css method to customize buttons in a page (following a particular a style of customization). using this css:

body {
    color: #fff;
    background-color: #11A27B;
    /* font-size: 40px; */
}

.stButton>button{
    color: #11A27B;
    box-sizing: 5%;
    height: 5em;
    width: 5em;
    font-size:50px;
    border: 7px solid;
    border-radius: 10px;
    padding: 30px;
}

.stTextInput>div>div>input {
    color: #000000;
}

.fullScreenFrame > div {
    display: flex;
    justify-content: center;
}

.center {
    display: block;
    margin-left: auto;
    margin-right: auto;
  }

and I call this method

def local_css(file_name):
    with open(file_name) as f:
        st.markdown(f'<style>{f.read()}</style>', unsafe_allow_html=True)

Now the problem is, that I have a second page where I have new buttons and I want to customize each button with different styles, shape, etc. So what I did was I created a new css file and changed few properties and called the load_css method again. But now what happened is that properties of the "old button" changed as well (which is obvious). Because .stButton works globally I guess.

How can I uniquely define and set properties for each individual buttons? Is there a way?

[kmcgrady]

Hi @murtazabasu Thank you for sharing your ideas about styling buttons here. Our mission is to make Streamlit the best way to build data apps, and your thoughts help us focus our roadmap where people feel the most pain. We're going to get this in front of our product team to see how we can best integrate this with our future plans.

We can't integrate every feature into the mainline codebase, but alternatively there are lots of interesting ways to extend Streamlit for your use cases via our Custom Components framework. You can read the docs about components here. If you can't use Custom Components, don't forget, Streamlit is really just Python, so the possibilities are endless! 🙂

We'll get back to you if we are able to prioritize this work!

[coolkau]

There are so many usecases for this. Make one large submit button. Make a floating error window docked to the top of the window, ie make it always visible. Make an on-off toggle...

Right now we are locked into those few widgets provided, or we are all alone with components. And the components then have other issues such as no callbacks without a hack, they dont sync with the session state so they wont interact with other widgets... This is all a lot of work if you for instance, just want the submitbutton to be larger and green and the cancel button red or so.

I totally get that you cant do everything, but this is a great way to say "hey we wont do it, but here you can do it yourself easily"

This

[LorenzoVela]

I strongly agree about the prioritization of this ER. Please, the potential is huge with columns expanders etc etc, but a unique style of the buttons for the same page is frustrating. Thank you :)

[CHerSun]

I'd really love to see this implemented too. Personally, I don't need exact styling or anything, but just some way to make buttons distinguishable. For example by specifying danger level. And it's already somewhat used in Streamlit for success, info, warning, error messages. Could be well applied to buttons backgrounds to make them better visually distinguishable. This is especially needed for destructive actions (like in a CRUD app).

Just as a reference:

[gkarozis]

Hello @CHerSun . Did you find any solution for this problem? I am looking for a solution for a couple of days now but nothing came up.

[CHerSun]

@gkarozis not for Streamlit, unfortunately, the reason for this issue exactly. Example above is taken from Panel.

[coolkau]

I would try wrapping it into a div. Then adding a css targeting all button children within that div. I am using this for markups a lot. I have not tried it for buttons. But Streamlit Modal is using a trick like this for their modal. I adapted their modal for a lot of things in the direction of styling.

The issue you might run into is, that Streamlit adds a style directly onto the button which would then take priority over your indirect style. This kill me a lot when overriding default styles.

If you end up trying this out, I would be keen to hear where you land.

[CHerSun]

I would try wrapping it into a div. Then adding a css targeting all button children within that div. I am using this for markups a lot. I have not tried it for buttons. But Streamlit Modal is using a trick like this for their modal. I adapted their modal for a lot of things in the direction of styling.

The issue you might run into is, that Streamlit adds a style directly onto the button which would then take priority over your indirect style. This kill me a lot when overriding default styles.

If you end up trying this out, I would be keen to hear where you land.

Imo, Streamlit is all about NOT using JS, HTML & CSS, and that's exactly what I like about it personally. There are plenty of other frameworks which utilize those. But Streamlit definitely needs a bit more customization options.

[CHerSun]

type argument was added to st.button, it partially does the job for me, but it'd be great to expand primary and secondary options with a few other things. Like in this issue #6414 (tertiary). Maybe also something like danger?

[coolkau]

@CHerSun
regards

Imo, Streamlit is all about NOT using JS, HTML & CSS,

I didnt say its pretty, but it is a solution. :) Sadly you have to hack steamlit quite often that way. They have the luxury of saying "we can't do it all, but here you can easily customize things yourself. Your risk, but here you go". Instead they seem to put up huge barriers to any customization. Even the only official way to customize, components, lacks things such as callbacks, ... again hack hack, you can add them easily by reading the right post and messing with the source code... and snowflake seems to have more interest in the developers than the product sadly.

type argument was added to st.button, it par

thanks for sharing will check it out :D

[jrieke]

Hey all! Yeah this is definitely a cool idea, and kinda fits in nicely with the type="primary"|"secondary" parameter we have now. We could easily extend that e.g. to type="danger". I don't see any blocker to us doing this and marked it on our roadmap again. But can't give a time estimate unfortunately since it's one of a ton of small issues we have and unfortunately there are many others with even more upvotes.

@coolkau on your comment:

Sadly you have to hack steamlit quite often that way. They have the luxury of saying "we can't do it all, but here you can easily customize things yourself. Your risk, but here you go". Instead they seem to put up huge barriers to any customization. Even the only official way to customize, components, lacks things such as callbacks, ... again hack hack, you can add them easily by reading the right post and messing with the source code... and snowflake seems to have more interest in the developers than the product sadly.

We know that visual customization is a super common request, we hear you. We discussed this several times in the past in the product team but could never really find a good solution that we all agreed on. It's unfortunately not a super simple thing:

• We want to be opinionated about design and make sure Streamlit apps always look great, no matter what you do. We do of course see that pros want to customize their apps but at the same time we want to make sure less design-savvy users don't make their apps look worse than before.
• There are several approaches for how we could allow more visual customization (e.g. is it pure CSS, is it additional parameters on elements, is it extended theming, ...). We need to do a more thorough investigation of these approaches before we ship anything (which is planned for later this year). Streamlit is used by a lot of people now so we need to make sure we don't ship suboptimal features and need to roll them back or break them later.
• As with the button stuff above, it's a question of time and prioritization. We have ~300 feature requests on GitHub and tons of others we hear from users and companies. Making progress on all of these issues (unfortunately!) takes time.

[CHerSun]

on topic @jrieke yeah, I'd appreciate danger on buttons for sure. And if you decide to go this way - maybe warning should be added too - red and yellow/orange. Looks to be sensible for how Streamlit works now (st.write, st.info, st.warning, st.error).

offtopic @jrieke :

We want to be opinionated about design and make sure Streamlit apps always look great, no matter what you do. We do of course see that pros want to customize their apps but at the same time we want to make sure less design-savvy users don't make their apps look worse than before.

That's exactly why I personally love Streamlit. But it does need a few touches for sure, including minor customizations and better interaction with data (for me - selectable row on dataframe; minor elements customization, like those buttons; deferred rendering on some components - tabs, expanders, file download, etc; way to add new data in place - multiselect, selectbox or text input with suggestions; hierarchical menu).

[RubenVanEldik]

Hi @jrieke,

Would the Streamlit team be open to a PR with this feature? I think it would be awesome if st.button could be expanded to:

st.button("Very standard", type="primary")
st.button("Less intrusive", type="secondary")
st.button("Yeey, success", type="success")
st.button("Warning, warning", type="warning")
st.button("Very dangerous", type="danger")
st.button("Just informative", type="info")

I think this is a feature that does not require a fundamental overhaul of how st.button currently works and I think I could implement this in a weekend or two. (please let me know if I'm very wrong about this 🙃)