Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DaisyUI – Tailwind CSS Components

daisyui.com

Post reply on HN
Print view View original

161–170 of 174 posts

Re: DaisyUI – Tailwind CSS Components

#161

Post by edoceo »

rmetzler wrote: post #92
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 also haven’t done much CSS since bootstrap 2.x days. I wonder if there is some tooling you would run in your CI to propose CSS changes - not failing like most linters but just nudge the devs a little to improve on low hanging fruits.

Back in the day it was `grep style=` in the code. All over-rides started there, then would (eventually?) get promoted.

Re: DaisyUI – Tailwind CSS Components

#162

Post by e12e »

mcluck wrote: post #159
zkldi wrote: post #143

Earlier quoted context omitted.

But why would you use @apply instead of something like: .button { background-color: $gray-100; border: 1px $gray-200 /\* so on... \*/ } i don't understand how these "micro" css classes actually help versus just setting the property.

After working with Tailwind for a period of time I came to the exact same conclusion. You can achieve all of this in a better way using CSS variables. You can transform 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; } } in to this: .button { font-…

How do you deal with media queries/responsiveness?

Re: DaisyUI – Tailwind CSS Components

#164

Post by e12e »

NaN1352 wrote: post #123

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 ro…

Why mix in Pascal case ?

Re: DaisyUI – Tailwind CSS Components

#165

Post by runarberg »

dmitriid wrote: post #71
bennyp101 wrote: post #50

Earlier quoted context omitted.

I think that ship has sailed, I really don't think that average users expect a button to 'do something' (in the sense it submits a form or something). Going to a different page /is/ 'doing something' as far as users are concerned. Certainly not the internet of old where a form was a form, and a link was a link.

An average user has no idea what's going on in modern software anymore, to be honest. Nothing is what it seems and is redesigned every couple of months

On the GitHub front page there is a sidebar with a second level heading for “Repositories”. Next to the heading there is a:

    
      New
Below the heading there is a list of repos which had a recent activity by you. Each list item has a link to an that repo.

   
     namespace/repo
There is a substantial difference between these two links. One takes you to a location, the other one starts a process which ends with an action.

As a user you are not going to be clicking the “New” button everyday. Maybe once a month, maybe once a year. So you are likely not going to remember where it is from the last time you clicked it. If you don’t find it when you need it, you will get frustrated. It needs a lot of visual weight relative to the other links in this nav section. Giving the same weight as a button is a reasonable decision.

Re: DaisyUI – Tailwind CSS Components

#166

Post by conatus »

Cool to see this out, but there is something about Tailwind I've never really got. And this is not from abstraction, but in production use on a number of pretty large sites.

Each Tailwind class corresponds to a CSS property, with a few exceptions where you have utility classes for degrees of that property (for example, padding, margin). Then along come these CSS component libraries, which substitute a thicket of these utility classes for a single class. Including Tailwind UI itself.

Given that the relationship of class to property is one to one, why not cut out the middle person and just use CSS directly? There seems no real advantage. You've basically indepedently re-invented CSS, while adding a strange layer of additional abstraction on top. It is nice and fast to write it in the HTML I'll grant, but, the speed advantage is not so great that it is worth it compared to the mental overhead of other aspects of working with Tailwind (e.g. having to trim all the classes with automated scripts and so on).

Perhaps I am missing something here?

Re: DaisyUI – Tailwind CSS Components

#167

Post by neurotrace »

e12e wrote: post #162
mcluck wrote: post #159

Earlier quoted context omitted.

After working with Tailwind for a period of time I came to the exact same conclusion. You can achieve all of this in a better way using CSS variables. You can transform 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; } } in to this: .button { font-…

How do you deal with media queries/responsiveness?

I'm on mobile so forgive me for not giving more extensive code examples. In my case, I'm building my app with React, TypeScript, and react-jss. I've got an enum which stores my common media queries and I just use it in the style declaration.

    button: {
      [MediaQueries.Medium]: ... 
    }
I can't use CSS variables for that but I personally don't think it's useful to let the user redefine those queries anyway

Re: DaisyUI – Tailwind CSS Components

#168

Post by verisimilidude »

conatus wrote: post #166

Cool to see this out, but there is something about Tailwind I've never really got. And this is not from abstraction, but in production use on a number of pretty large sites. Each Tailwind class corresponds to a CSS property, with a few exceptions where you have utility classes for degrees of that property (for example, padding, margin). Then along come these CSS component libraries, which substitute a thicket of thes…

For each project, there's a unique balance between HTML, CSS, and the greater organization.

Consider a site that mostly renders Markdown or XML documents. Tailwind is probably the wrong choice. You have less control of the HTML content in this case, because it's generated. If you want to use Tailwind here, you'd need to make liberal use of Tailwind's @apply directive for basic declarations, which IMO is not the best expression of Tailwind usage. On the other hand, you have a lot of control over the CSS. It makes more sense to write the CSS directly.

Now consider an organization with many separate web properties, which all require consistent branding. The organization has a UI guy who creates universal stylesheets and components for use across sites. Here you have less control over the CSS, and more over the HTML. Tailwind makes more sense. You can add all the utility classes to HTML that you want, with few overrides or other enterprise pull-ups.

This latter scenario also highlights one of Tailwind's strengths. Tailwind limits your options. If you need to keep a brand consistent across a large number of properties, Tailwind keeps you in the guardrails of the style guide. I can't be the only one who's worked at an organization where there's supposed to be only one shade of blue to represent the brand, but you wind up finding 160 different shades of blue throughout the CSS.

Anyway, Tailwind has its time and place. I love it when it fits.

Re: DaisyUI – Tailwind CSS Components

#170

Post by zkldi »

mcluck wrote: post #159
zkldi wrote: post #143

Earlier quoted context omitted.

But why would you use @apply instead of something like: .button { background-color: $gray-100; border: 1px $gray-200 /\* so on... \*/ } i don't understand how these "micro" css classes actually help versus just setting the property.

After working with Tailwind for a period of time I came to the exact same conclusion. You can achieve all of this in a better way using CSS variables. You can transform 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; } } in to this: .button { font-…

I really like this approach - I forget CSS has native variables now (maybe it has had it for a while?) and always think of scss's $variables.
Post reply on HN