Live data from Hacker News

Tailwind: A Utility-First CSS Framework

tailwindcss.com

91–100 of 106 posts

Re: Tailwind: A Utility-First CSS Framework

#91
"it doesn't have a default theme" ...One paragraph later "here's a business card in the default theme"

technically, it have all the themes to the point that picking up individual color for everything make it as unmaintanable.

Re: Tailwind: A Utility-First CSS Framework

#92
post #72

Earlier quoted context omitted.

Wouldn't using em units be a better idea in most cases?

CSS has 'vh' and 'vw' units too, changed my life.

'vmin' and 'vmax' too.

I'm experimenting with using 'em' and % everywhere, base font size with 'vmin' and scaling font size with %. Works pretty well for scroll-less apps.

Example: https://alvaro-cuesta.github.io/instant-trivia/

Re: Tailwind: A Utility-First CSS Framework

#93
An important difference in my mind is between designing a web application vs designing a web document.

In the document case, it is possible to mostly keep the document semantic and apply styling via CSS. It matches the content/style separation well.

For web applications, I really like tailwind-like approaches, for multiple reasons:

* changing the style globally is probably hard anyway without adapting the HTML as well (as in the app case, often lots of other things depend on margins etc for example and you have a lot less uniformity/more special cases than in the document case)

* because there is less uniformity, the reuse aspect of the traditional content/presentation split is greatly reduced anyway

* web apps often use component based frameworks already, so you still get reusable components

Re: Tailwind: A Utility-First CSS Framework

#94

Author of Tailwind here! If you haven't worked with a library like this before, I promise your gut reaction will be "holy hell this is the worst thing I've ever seen" (it was my reaction too!) You really do have to try it to shake that impression. If you need a bit more convincing before you're willing to try it, I wrote an in-depth article a while ago that documents my journey from a "semantic classes"-loving HTML/C…

Adam, your "Separation of Concerns" article was what sold me on utility-first CSS. Thank you.

For anyone building React apps with Tailwind or Tachyons, I just open-sourced a library that makes it easier to reuse CSS classes in standalone, customizable components:

https://www.npmjs.com/package/nanostyled

(I think this is a React implementation of what the Tailwinds docs call "Extracting Components".)

Re: Tailwind: A Utility-First CSS Framework

#95

Author of Tailwind here! If you haven't worked with a library like this before, I promise your gut reaction will be "holy hell this is the worst thing I've ever seen" (it was my reaction too!) You really do have to try it to shake that impression. If you need a bit more convincing before you're willing to try it, I wrote an in-depth article a while ago that documents my journey from a "semantic classes"-loving HTML/C…

Nice work Adam, I've grown to really like util based CSS, mainly from the new Bootstrap 4 utility classes. Since your article came out before BS4 release, wondering what your thoughts were on Bootstrap now?

Re: Tailwind: A Utility-First CSS Framework

#96
post #67

All CSS "frameworks" should be thought of as utility libraries, including Bootstrap. If you apply the framework classes directly to your HTML, you've tightly-coupled your HTML (which is already tightly-coupled to your information architecture) to an implementation detail of your presentation code. Most frameworks support some kind of re-use of CSS declaration blocks - use that feature to build your components from th…

This is imho the correct approach.

All the benefits with none of the coupling. Tailwind might actually be pretty nice if used this way.

Re: Tailwind: A Utility-First CSS Framework

#97
post #23
post #11

It is convenient but you are not separating markup and presentation. I think the whole point of css is to swap stylesheets and get a different presentation, like demostrated by http://www.csszengarden.com/ BEM/OOCSS lets you do this.

How many times you do that in real project? Or have you ever done that in your career? And if a project needs substantial redesign it is usually acompanied by the functionality change, which means you need defferent html/components too, so you still can`t just swap css files.

I have done this a few times for large parts of a projects.

Much more common, however, is overriding styles at the component level, which gets funky with this approach.

You either have to add JavaScript logic to assemble the appropriate class names or you wind up with a situation where elements have classes that conflict with their styles, because they are overridden. Imagine something with .text-purple, where the text is clearly not purple.

Re: Tailwind: A Utility-First CSS Framework

#98
post #36

Earlier quoted context omitted.

Generally you’d have your button html and classes inside a component so you’re just tweaking that one component.

Then it feels like we're just back to writing normal CSS classes.

The secret is that a solution where typical CSS classes are the exception and not the common case, is generally more useful.

Re: Tailwind: A Utility-First CSS Framework

#99

Author of Tailwind here! If you haven't worked with a library like this before, I promise your gut reaction will be "holy hell this is the worst thing I've ever seen" (it was my reaction too!) You really do have to try it to shake that impression. If you need a bit more convincing before you're willing to try it, I wrote an in-depth article a while ago that documents my journey from a "semantic classes"-loving HTML/C…

Thanks for making yourself available!

I was curious what your thoughts are on a JS-based functional CSS library? I noticed that you mentioned emotion on the docs, and that was also what I thought would be the perfect tool for the job

Imagine a set of functions like `textColor()` or `margin()` that return composeable objects that you'd stick onto css props, and just like tailwinds would throw errors or lint warnings if you didn't pass in values it was configured to allow? (E.g., colors.red, okay, colors.maroon, error? Or maybe colors('red') okay)

I figured it'd more elegantly solve the problem of generating stylesheets that are too large and then needs to be pruned off

One trade-off I see is that the utilities would need to be imported to each file that needs it (as opposed to strings you can put anywhere), but the the good thing about that is you could more easily click into the definitions that way, and you could namespace utilities under a variable so you'd only need to import one thing

I would guess you'd put more thought on this topic than I have, very curious to hear what you think

Post reply on HN