CedericPrivat / tailwindcss-base-font-size

A Tailwind CSS plugin to set the base font size in proportion to Tailwind's default utility values.
https://www.npmjs.com/package/tailwindcss-base-font-size
MIT License
22 stars 1 forks source link

Configure decimal places #34

Open MichaelBrunn3r opened 2 months ago

MichaelBrunn3r commented 2 months ago

Hi, just found your package. Thx for fixing my exact niche problem :).

I have to use this plugin because I work in an environment where I can't control the root font-size, which is set to 14px. The only remaining issue for me is the rounding. E.g. *-3 (=16px) gets converted to 0.8571428571428571rem. I don't realy need that many decimal places. Would it be possible to add a cofiguration option for the maximum amount of decimal places?

CedericPrivat commented 2 months ago

Hey @MichaelBrunn3r,

thanks for reaching out!

I'm trying to wrap my head around your problem, but I don't really seem to get it. Could you give me an example of a tailwind class that uses spacing (like p-3 or text-lg) and which values your getting and what you are expecting with a base font size set to 14px?

MichaelBrunn3r commented 2 months ago

With the default base font size:

.gap-2 {
    gap: 0.5rem;
}

With a base font size set to 14:

.gap-2 {
    gap: 0.5714285714285714rem;
}

0.5714285714285714rem is the corret value. I just noticed, that my output CSS file was suddenly filled with these long numbers. I didn't write it down, but I remember testing that around the 5-6th decimal place there are no visible layout changes anymore. In the second exapple, gap has 16 decimal places, so its has about 8-9 wasted digits.

This not a bug, just a request to reduce file size

CedericPrivat commented 2 months ago

I see what you mean. The issue here is that browsers handle rounding for fractional values differently. Some browsers just "cut off" decimal values, others round up or down to the nearest integer. But, browsers still use the exact value for calculations that include those fractional values, and round/truncate afterwards.

Therefore, if we would add an option to limit the number of decimal places, we could actually see a difference between the "full" value with all decimal places and a "stripped" value with fewer decimal places.

Although, we could add the option with a disclaimer and it's up to the user to decide, if the tradeoff is relevant for their use case.

What do you think?

MichaelBrunn3r commented 2 months ago

That sounds like a very good idea and would solve my issue.

As you say, I don't think it should be a default. Having the full precision is important to prevent unexpected behaviour. Users should decide on their own when to round the values and be warned of the downsides.

CedericPrivat commented 2 months ago

I will consider the option to configure the number of decimal places for the next release of this package and keep you updated on the changes in this thread.

Thanks again for the input!