gradio-app / gradio

Build and share delightful machine learning apps, all in Python. 🌟 Star to support our work!
http://www.gradio.app
Apache License 2.0
32.49k stars 2.44k forks source link

Theme-related requests #3544

Open pngwn opened 1 year ago

pngwn commented 1 year ago

Is there something you would like to style via the theming API but isn't currently supported?

Please add a reply to this issue detailing exactly what you would like to style and how you would like to style it! Screenshots are very welcome!

space-nuko commented 1 year ago

The section on CSS theme variables makes it sound like there's an autogenerated CSS class for all major components/layouts, but actually this isn't the case, the available CSS vars are only whatever's defined by the devs in the .svelte files, and not all components support them

For example, I want to get rid of all padding on elements, but not on gr.Accordions. Turns out the Block element that wraps the inner Accordion element is what defines the padding. In this case it seems like the specificity I need is not covered by the theme API

And it looks like the only CSS vars exposed for accordions are some --section-header-text-* ones that target other elements also, there is nothing that contains an --accordion prefix

In fact, I couldn't even write a good custom CSS rule for this case, I needed to manually add a .gr-accordion class to every created gr.Accordion to have something besides an autogenerated class to target (what I was mentioning in #3545). The important thing is elem_classes doesn't help since I want to target all gr.Accordion elements, including ones added by extensions (where I might not be able to control what classes they have)

anapnoe commented 1 year ago

469 --vars already most of them are generic

this is a complicated issue and there are a lot of different design patterns most frameworks had spend years to define and find balance between flexibility and bulkiness if you want to do it right at least study some other frameworks

1.first of all you need to prefix your vars so there are no conflict with other frameworks this is important gr is nice and small 2.seperate the components by feature some of them may need more attributes to be defined keep consistency in names 3.write the mixin for each variant

this is an example code of how bootstrap5 does it

@mixin table-variant($state, $background) {
  .table-#{$state} {
    $color: color-contrast(opaque($body-bg, $background));
    $hover-bg: mix($color, $background, percentage($table-hover-bg-factor));
    $striped-bg: mix($color, $background, percentage($table-striped-bg-factor));
    $active-bg: mix($color, $background, percentage($table-active-bg-factor));
    $table-border-color: mix($color, $background, percentage($table-border-factor));

    --#{$prefix}table-color: #{$color};
    --#{$prefix}table-bg: #{$background};
    --#{$prefix}table-border-color: #{$table-border-color};
    --#{$prefix}table-striped-bg: #{$striped-bg};
    --#{$prefix}table-striped-color: #{color-contrast($striped-bg)};
    --#{$prefix}table-active-bg: #{$active-bg};
    --#{$prefix}table-active-color: #{color-contrast($active-bg)};
    --#{$prefix}table-hover-bg: #{$hover-bg};
    --#{$prefix}table-hover-color: #{color-contrast($hover-bg)};

    color: var(--#{$prefix}table-color);
    border-color: var(--#{$prefix}table-border-color);
  }
}
anapnoe commented 1 year ago

The section on CSS theme variables makes it sound like there's an autogenerated CSS class for all major components/layouts, but actually this isn't the case, the available CSS vars are only whatever's defined by the devs in the .svelte files, and not all components support them

For example, I want to get rid of all padding on elements, but not on gr.Accordions. Turns out the Block element that wraps the inner Accordion element is what defines the padding. In this case it seems like the specificity I need is not covered by the theme API

And it looks like the only CSS vars exposed for accordions are some --section-header-text-* ones that target other elements also, there is nothing that contains an --accordion prefix

In fact, I couldn't even write a good custom CSS rule for this case, I needed to manually add a .gr-accordion class to every created gr.Accordion to have something besides an autogenerated class to target (what I was mentioning in #3545). The important thing is elem_classes doesn't help since I want to target all gr.Accordion elements, including ones added by extensions (where I might not be able to control what classes they have)

this should be available for all components not only accordion each component must provide a human readable default class name in the wrapper div of the component

oobabooga commented 1 year ago

I'd like to request the possibility of using the 3.18.0 Chatbot layout again. I liked it a lot better.

Before After
b a
akx commented 1 year ago

It would be useful to be able to set a process-wide default theme object for programs that use multiple gr.Blocks calls.

bent-verbiage commented 1 year ago

When using the Theme builder, I wasn't able to find the specific styles for the chatbot: Background, colours for messages, those kind of things. Did I miss them, or aren't they there yet?

abidlabs commented 1 year ago

When using the Theme builder, I wasn't able to find the specific styles for the chatbot: Background, colours for messages, those kind of things. Did I miss them, or aren't they there yet?

Not currently there, but good suggestion imo!

akx commented 1 year ago

The default themes should not rely on external services (Google Fonts): https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/10024

Google Fonts may also be a GDPR issue, as they're able to track users requesting their fonts.

muge-birlik commented 12 months ago

I would love to be able to check if light or dark mode is being used.

ketsapiwiq commented 2 months ago

Just cross-linking this issue here: https://github.com/gradio-app/gradio/issues/8924 I would love to have a way to disable all theme-related CSS in gradio. Thanks