DaisyUI – Tailwind CSS Components • Hacker News Board

Re: DaisyUI – Tailwind CSS Components

#121

Post by antihero » Fri, Jul 30, 2021, 12:49 PM UTC

mikevm wrote: post #27

rvense wrote: post #23

Earlier quoted context omitted.

With Tailwind, if you write out something like that more than once or twice, you're really supposed to bundle it together. Either as a plain CSS class, or a component in your framework of choice. I suppose a library of common elements is a good thing to have, but the reason I like Tailwind is that I can use the utilities at first and then easily gather them together as plain CSS classes as and when that makes sense t…

But if you're going to hide away CSS inside a component, why not just use inline CSS? What does Tailwind add to this?

Tailwind gives you rules and constraints.

Re: DaisyUI – Tailwind CSS Components

#122

Post by Phillips126 » Fri, Jul 30, 2021, 12:49 PM UTC

peterkelly wrote: post #93

jpomykala wrote: post #79

You are trying to solve problems which were created by Tailwind, and you end up with Bootstrap.

I've never used Tailwind, but am familiar with Bootstrap. When looking at the examples, the ones on the right looked pretty much exactly like Bootstrap and I didn't understand what was interesting or novel about it. Is the code on the left (with lots of classes) actually what tailwind is like to use in practice?

> Is the code on the left (with lots of classes) actually what tailwind is like to use in practice?

As a fan of tailwind, I can say that I initially thought this was dumb and it would be hard to read through a huge number of classes applied to each HTML element. Later, I found that for many of my reusable components, I could combine classes into a single class. As an example, my stylesheet may look like this:

  @tailwind base;
  @tailwind components;
  @tailwind utilities;

  @layer components {
   .button {
     @apply text-2xl p-2 bg-gray-100 text-gray-600 border border-gray-200 cursor-pointer hover:bg-gray-200 hover:border-gray-300;
   }
  }

I can now just give all of my reusable buttons the ".button" class instead of the giant string above.

Re: DaisyUI – Tailwind CSS Components

#123

Post by NaN1352 » Fri, Jul 30, 2021, 1:03 PM UTC

Looks good. I’d really like to use this. Mainly I like that the author used same approach as I do whereby with careful use of low specificity, a custom "btn" class can be further customized just by adding TW classes (ie. not css specificity issues).

My only gripe with this is that you should then use a clearly defined and separate naming convention for custom classes, for example SuitCSS is good:

Not

btn btn-large rounded-full

But

du-Btn du-Btn—-primary rounded-full

ie. PascalCase component names,

optional prefix (eg. du for daisy ui, because other apps also have their prefix see eg. Twitch and Algolia css)

Bem conventions like double dash for modifier as opposed to a descendant

https://github.com/suitcss/suit/blob/master/doc/naming-conve...

So yeah I would like to be able at a glance to know where a class is from. "btn" is not from tailwind, but where is it from? What if my app uses multiple components, from third party etc? It’s not clear.

Other than that This is better than Bootstrap approach even with custom classes, because you take care of css specificity problem (assuming you can add a tw class anywhere and override the builtin custom classes)...

this is the middle way that nobody uses for whatever reason, the one that makes sense, but requires a good basic understanding of css specificity as well as setup stringent css linter

Also using a convention would let you use a good linter on the custom selectors

https://github.com/postcss/postcss-bem-linter

Re: DaisyUI – Tailwind CSS Components

#124

Post by Phillips126 » Fri, Jul 30, 2021, 1:04 PM UTC

ponyous wrote: post #73

This library highlights the biggest issue of tailwind for me. > Clean HTML The rest of your code will still use bunch of shitty tailwind shortcuts that are really chaotic the moment you build something more than a simplest component.

I mentioned it in another comment, but I felt the same way until I figured out there is a solution. Here is an example of a simple CSS file with a reusable button class:

  @tailwind base;
  @tailwind components;
  @tailwind utilities;

  @layer components {
   .button {
     @apply text-2xl p-2 bg-gray-100 text-gray-600 border border-gray-200 cursor-pointer hover:bg-gray-200 hover:border-gray-300;
   }
  }

I can now just give all of my reusable buttons the ".button" class instead of the giant string above. I can even add more styles or overwrite existing styles to give it a different look such as:

  Click Me

Re: DaisyUI – Tailwind CSS Components

#125

Post by NaN1352 » Fri, Jul 30, 2021, 1:07 PM UTC

armchairhacker wrote: post #83

We've gone full circle - CSS components to inline CSS-in-HTML back to CSS components. But I actually think I will use this. A big problem with CSS is that you end up making overrides no matter how composable you make the classes. And some simple things (e.g. responsiveness) are unintuitive and / or annoying to do in CSS. Hence Tailwind's "CSS-in-HTML" mini classes. But that doesn't fill the core purpose of CSS, bigge…

Correct you explained better than I did.

Using a convention for custom classes helps distinguish from tw classes and other libraries, and allows stringent linting of css selectors to make sure the specificity issue is covered (without using !important on all tw and custom utilities which imho is a bad solution).

https://github.com/postcss/postcss-bem-linter

Re: DaisyUI – Tailwind CSS Components

#126

Post by chrisweekly » Fri, Jul 30, 2021, 1:09 PM UTC

udbhavs wrote: post #38

whoisjuan wrote: post #5

I’m not saying this is ugly but the visual execution of some of these components is poor. No good usage of padding in some examples, poor ratios between the typography and the containers, inconsistent use of different line widths and border radius, weird and incosistent design choices in spacing and proportions… I mean. This looks alright and it will certainly make any UI look pretty decent, but the execution is not…

This sort of stuff was difficult to figure out when I was learning HTML/CSS, do you know of any guides which list similar rules and how to make "proper" use of properties like borders, padding, typography etc?

https://every-layout.dev

Re: DaisyUI – Tailwind CSS Components

#127

Post by blacktriangle » Fri, Jul 30, 2021, 1:14 PM UTC

armchairhacker wrote: post #83

We've gone full circle - CSS components to inline CSS-in-HTML back to CSS components. But I actually think I will use this. A big problem with CSS is that you end up making overrides no matter how composable you make the classes. And some simple things (e.g. responsiveness) are unintuitive and / or annoying to do in CSS. Hence Tailwind's "CSS-in-HTML" mini classes. But that doesn't fill the core purpose of CSS, bigge…

I think the thing with Tailwind that people are missing is the opinion that CSS's bigger general purpose classes to avoid repetition have failed. However, most of us are using some kind of HTML templating system. What matters is that the design work only happens once in the code, repetition in the finished product is just fine. So moving the job of avoiding repetition out of CSS and into your HTML templating system is the right way to go.

Re: DaisyUI – Tailwind CSS Components

#128

Post by NaN1352 » Fri, Jul 30, 2021, 1:14 PM UTC

eric4smith wrote: post #59

Very welcome. Sometimes the amount of classes needed in Tailwind is enormous. I paid for the TailwindUI pack too. But as nice as Tailwind is, the guys who built TailwindUI don't really get or understand a lot of real-world design patterns. A lot of stuff in there is needlessly complicated. Our team end up trimming down things to 50% of the markup that they use, while retaining full responsiveness. Overuse of flex for…

I would suggest the use of convention like SuitCss for your custom component classes so you can lint them thoroughly to ensure low specificity.

I would recommend to use a prefix on your custom classes, to "namespace" them. "btn" is far too generic. This can even be linted by eg. postcss-bem-linter.

Re: DaisyUI – Tailwind CSS Components

#129

Post by XCSme » Fri, Jul 30, 2021, 1:16 PM UTC

I am not sure this is production-ready. I had a look over some components and the UI/UX is poor in general (bad alignment, padding, bad accessibility, no proper focus traps, no keyboard support, etc.). Maybe some of those are lacking because it is a CSS-only implementation? But you still can't use them as it is without proper accessibility support.

Re: DaisyUI – Tailwind CSS Components

#130

Post by mosburger » Fri, Jul 30, 2021, 1:20 PM UTC

onion2k wrote: post #37

whoisjuan wrote: post #5

I’m not saying this is ugly but the visual execution of some of these components is poor. No good usage of padding in some examples, poor ratios between the typography and the containers, inconsistent use of different line widths and border radius, weird and incosistent design choices in spacing and proportions… I mean. This looks alright and it will certainly make any UI look pretty decent, but the execution is not…

Back when Bootstrap 2 was the most popular UI library one of the biggest problems with it was that the defaults were good enough that no one changed them, and consequently every SaaS startup's product looked the same for about 5 years. Pushing people to tweak things while still giving them a solid foundation is a good thing. I'm not saying that's necessarily the case here, but there is a strong argument in favor of n…

I still think about the quote I once heard around that era... "Made with Bootstrap" is the "ft. Pitbull" of web design.