search

themesberg / flowbite-svelte

Official Svelte components built for Flowbite and Tailwind CSS
https://flowbite-svelte.com
MIT License
2k stars 239 forks source link

STOP making layout decisions on components #1156

Open niemyjski opened 7 months ago

niemyjski commented 7 months ago

Describe the bug

You keep on injecting layout styles on components that shouldn't be there and left up to the user to apply. Which is causing really big pain points and hard to use. Components should address look and feel, behaviors. Even things like light mode and dark mode color schemes should be inherited styles and ANYTHING with layout should NOT be the responsibility of components. Users shouldn't be fighting or looking at the source to fix your applied styles.

Navbar

For example your navbar controls inject extra container or full width styles that should be left up to the user, making it almost impossible to recreate your admin theme.

image

This causes us to go back and look at the source and inject px-0 sm:px-0 py-0 into the navbar, figure out fluid, and then inject mx-0 into the NavContainer.. It doesn't stop there

NavHamburger

https://github.com/themesberg/flowbite-svelte/blob/main/src/lib/navbar/NavHamburger.svelte#L11

It's not visible on medium width layouts? Why make these decisions All visibility and placement should be LEFT up to the user. https://github.com/themesberg/flowbite-svelte/issues/108

Suggestions

Remove all padding, margin, flex layouts, visibility from all components. And also try recreating (dog fooding) the admin template with these controls. You will find tons of usability and themeing issues....

Reproduction

Look at the source.

Flowbite version and System Info

Latest
niemyjski commented 7 months ago

Also, I might add, the components do not feel idiomatic to svelte and definitely not svelte5 especially for eventing. There is too much magic happening and applying these styles do not help at all.

solvingproblemswithtechnology commented 7 months ago

We faced the same problems this week and ended up creating our own component. I guess it's a problem of finding the right balance. I prefer to use layouts with flex + gap instead of margins and paddings for components so you need less stuff within the component and it's easier to override. That + slots to override certain sections if needed.

rbozan commented 7 months ago

Honestly I think if your project is not that far, skeleton UI seems more promising than this library. This library is "OK" but often frustrates me.

Sebastian-henn commented 1 week ago

I agree, forcing design decisions with no obvious ways to override them is problematic. I don't like having to manually modify css classes to disable behaviour like disappearing hamburgers, definitely feels like an anti-pattern