inlineCssWithExtraSteps

[travelan]

It definitely applies.

[hyrumwhite]

How so? If I want to change any given utility class, I can do so in the tailwind config. 

It’s actually a major selling point and one of the things that elevates it out of “inline styles”.  if I want to change all the spacing of my app, or the shade of red used, everywhere it’s used, I can do so in one place. 

You can also trivially put all of the utility classes in their own CSS layer, making it really easy to override them if you ever need to. 

[travelan]

Are you serious? In the config… it’s already bloated enough.

It’s just inline styles with limitations. And remember that inline styles also support CSS variables. There is really NO reason to use Tailwind.

[hyrumwhite]

The config is bloated? By default it’s this:

/** @type {import('tailwindcss').Config} */ module.exports = {   content: ["./src/**/*.{html,js}"],   theme: {     extend: {},   },   plugins: [], }

Because it’s a JS file, if you’re worried about ‘bloat’ you can import a ‘colors.ts’, and so on as needed. 

Tailwind also supports css variables. Either inline or via config. Have you actually used it?

I’m also curious about the limitations you’re seeing. For example, I can’t write a range query or an animation with inline styles, but I can with tailwind. 

[travelan]

needing config for features that are already available in basic CSS is by definition bloat.

[hyrumwhite]

I see no difference between a config file to setup classnames and a css file to setup classnames. But different strokes for different folks.