Support for Padding, Margin?

[niklasgrewe]

Hi, thank you very much for creating this plugin. I know that this plugin was developed mainly for the font size. Would there still be the possibility to support padding and margin as well? That would be pretty handy, since the configuration would only need to be set once.

[davidhellmann]

Thought about it and discussed it with some people. I'm not sure at the moment. I'll think about it again. But when I think I release a different plugin. Most of the settings here are just useful for fonts. For paddings / margins I think it needs just this settings

min/max breakpoint factor (default 2). prio (min or max)

what do you think?

[niklasgrewe]

glad to hear you're thinking about it again. Good idea to create a separate plugin for it. The settings you mentioned, I find so far sufficient. I would not need more in my projects. However, I always find that I need the following css code again and again, like this:

<div class="max-w-[min(80vw,48rem)]" />

of course i can use arbitrary values, but would you have an idea how to include such css properties in the plugin, maybe like this?

<div class="max-w-min min-80vw min-max-w-3xl" />

it would be cool, if we could write something dynamic and not static, so we can also use the tailwind spacing values in this case. I imagine something similar to the dynamic transform class that tailwind provides us with

[davidhellmann]

I think depending on the settings it should looks like this:

<div class="p-4 m-2" />

and the CSS output like this (with prio min in mind and factor 2):

div {
  padding: calc(1rem, __dynamic_value__, 2rem);
}

So p-4 is 1rem on min width and on max-width it's simple *2 and results in a p-8 in real.

The biggest problem here is its no possible to mix this values with fixed ones. And spacings creating a lot of classes. So I'm not sure how to handle that. Maybe p-4 etc. are fluid and stuff like p-[2rem] is fixed? Prefixing can be a solution but again, this creates a lot of extra classes.

[niklasgrewe]

I agree with your idea. It is only important to me that I am able to set min and max values. But as you have shown it, that is enough for me.

Good that you say that with the spacing values. It's true, this creates again many new classes, which are not all necessarily needed. I had overlooked that. And to work with prefix, I think it's also not best idea.

I would be happy if you would implement it the way you showed it in your example, i.e. p-4 for fluid and e.g. p-[4rem] for the fixed values.

[davidhellmann]

I'll close this for now. I think about it to create another plugin but for this one, less is more :)

[davidhellmann]

Follow up here… Played a bit last week with this. I think it's possible to build something like this for Margin / Paddings but the bigger problem is that so many other things depend on these values so I think it's not really a good thing to do it. All positions and transforms etc. use the same values as margin/padding. So when you use fluid margins/padding you should also use these values for transforms and positions etc.

In the end, you overwrite most of the tailwind core stuff and that's not a good idea I think. For fonts, it's much easier and has fewer dependencies so nearly zero side effects here.

[changethe]

hey david, first of all thanks for this awesome plugin and sorry for replying to a closed issue :)

I played around a little bit with the responsive spacing, and I think it would be really helpful to have that available with the same scaling settings as the font scaling factors for harmonic scaling.

web.dev is using a clamp value for spacing for example, and there is a calculator on https://utopia.fyi/space/calculator/ that has some interesting ideas for inspiration.

the spacings could be extended to tailwinds default spacings with a prefix, so the fixed spacing utilities would still available for things that shouldn't scale. But especially for gutters, prose elements etc. it would be really helpful to be able to make this fluid via clamp with the same scale as the typography settings.

there could be 2 different class types generated:

m-fluid-SIZE -> scales from base size to scaling setting m-fluid-SIZE-to-SIZE -> scales from size 1 to size 2 in the defined scaling speed.

the scaling setting could basically just the same as the this plugins' settings, and the base values would be taken from the tailwind defaults.

if these are added to the tailwind defaults, it would be available in all spacing utilities like margins, paddings, gaps etc. and be really useful.

you could do things like gap-fluid-3, or gap-fluid-5-to-10 etc.

[davidhellmann]

Hey @changethe Maybe you can have a look at this issue #22, and you can use this approach. I'll not include this in this plugin, and having a plugin that affects nearly the whole TailwindCSS config is not a good idea. I understand your thoughts about it, but in the past, we used this approach initialized by me, but the designers weren't happy with that. But anyway. Currently, I don't have time to build something like that. It needs much more effort to achieve this. It's not just margin and padding. Position transforms etc. etc.

But feel free to fork this plugin or do a PR :)

[changethe]

hey david,

yeah I agree that this would probably belong into a seperate plugin. a sister plugin at that though :-) not sure what exactly you mean by affecting the whole tailwind config though, as it could just be seperate extended fluid classes.

for now I just wrote a quick and dirty script to generate them for me: https://www.npmjs.com/package/tailwindcss-clamp

the scaling etc. could probably be done a lot better. I'm gonna experiment around with it a bit more.

with this i can now use it in margins, paddings, heights etc... anywhere tailwind uses the spacing utilities like gap-5-to-10 etc.

let's see how useful it will be. will experiment around for a bit and see :)

thanks again!

[davidhellmann]

Thanks for sharing. Sure, with additional classes it's much easier as to overwrite the default spacing. But when you do it this way, you also need that stuff for spacing, positions, transforms etc. etc. Sure, you can also create these classes. But is it a good way to create a tailwind inside tailwind? :D For me there is just one solution to do something like that, and that is to overwrite the default tailwind logic for that stuff. But I wonder if that is the right way (maintaining, breaking changes etc).

I think the approach from #22 is much easier for that without adding additional classes. But feel free to update the issues, happy to hear how you handle it and how it work in the end.