gradio 3.44 and higher force specific style

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

33.41k stars 2.53k forks source link

gradio 3.44 and higher force specific style #5847

Closed vladmandic closed 10 months ago

vladmandic commented 1 year ago

Describe the bug

gradio 3.44 started forcing specific css styling on components without ability to define it. for example, pr #5535 added style for sliders, but its hard coded in svelte and cannot be defined in either a theme or user css since svelte styles are applied last.

severity? i'm stuck on gradio 3.43 pretty much forever since app ui customization is no longer taking effect.

Have you searched existing issues? 🔎

[X] I have searched and found no existing issues

Reproduction

see above.

Screenshot

No response

Logs

No response

System Info

gradio version: 3.44.4

Severity

Blocking usage of gradio

abidlabs commented 1 year ago

Hi @vladmandic in general, we do not guarantee that the Gradio components DOM will be consistent between versions of Gradio. This caveat is mentioned a few times in the Gradio documentation, particularly in the section for custom css and js. We try to minimize changes to the DOM , but in some cases, we need to change the Gradio DOM because there are other considerations (e.g. accessibility or consistency or something else).

In this case, can you tell us a bit more about the kind of customization you're trying to do, so that we can see if its possible for us to support it in gr.Slider?

cc @dawoodkhan82

vladmandic commented 1 year ago

i understand that. i think larger issue is that styling applied by svelte is on dynamically generated class names which take priority over any general user css customizations (unless user throws !important absolutely everywhere which is just bad)

for example, gr.Slider implements class input[type=range].svelte-1fqubt4 which is included from Range-c39e2e66.css

if it simply implemented styles for input[type=range], i'd have no issues as user styling could be applied.
alternatively, allow disabling of gradio built-in styles (e.g. skip loading of Range-c39e2e66.css).

i understand the desire from gradio team and i'm ok with default behavior for building quick prototype apps that are sharable. but this absolutely blocks any chance of gradio being used in larger apps with their custom ui look&feel.

my screenshot to illustrate:

abidlabs commented 10 months ago

Should be fixed by https://github.com/gradio-app/gradio/pull/6738, closing!