Tailwindcss: Feature request: Add support for using px instead of rem's

Created on 22 Mar 2019  Â·  5Comments  Â·  Source: tailwindlabs/tailwindcss

Can you please replace the rem's with px instead?
https://mindtheshift.wordpress.com/2015/04/02/r-i-p-rem-viva-css-reference-pixel/
Or at least make it an option when creating tailwind.js.

Most helpful comment

I read the article. It's a good article, but I wasn't talking about accessibility / user preferences when I said that rems were useful. I'm talking about the ability to scale your entire site by a certain % on different screen sizes. I often make everything slightly larger on very big screens to make better use of all the space available, like this:

html {
    font-size: 16px;
}

@screen xl {
    html {
        font-size: 18px;
    }
}

That wouldn't work if everything was in px instead of rem. I can't say whether that's the reason Tailwind uses rem by default, but I like it for that reason.

All 5 comments

I read the article. It's a good article, but I wasn't talking about accessibility / user preferences when I said that rems were useful. I'm talking about the ability to scale your entire site by a certain % on different screen sizes. I often make everything slightly larger on very big screens to make better use of all the space available, like this:

html {
    font-size: 16px;
}

@screen xl {
    html {
        font-size: 18px;
    }
}

That wouldn't work if everything was in px instead of rem. I can't say whether that's the reason Tailwind uses rem by default, but I like it for that reason.

Ok, that's fine, so what I propose is to make it optional.
./node_modules/.bin/tailwind init [filename] --unit-px
..or something like that.

What benefit would you get if we defined everything in pixels? p-4 would
still be 16px by default like it is already, so I can’t quite figure out
what the improvement would be. Is it because you are measuring things in a
designer-provided mock-up and trying to find the matching value in Tailwind
or something?

Rem is definitely better for the reason Ben stated and comes with no
downside as far as I’ve seen. Would simply including the pixel conversions
in the docs be all you actually need?
On Fri, Mar 22, 2019 at 5:30 PM Andreas Heintze notifications@github.com
wrote:

Ok, that's fine, so what I propose is to make it optional.
./node_modules/.bin/tailwind init [filename] --unit-px
..or something like that.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tailwindcss/tailwindcss/issues/800#issuecomment-475789923,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEH3bDg2H0Pfa3vWhLevsJvLOghdFb70ks5vZUtYgaJpZM4cEa-n
.

You are right, there's no benefit in supporting switching to px in the creation of tailwind.js. As long as we avoid using rem and em in media queries and if we want control over it, we can just override the browsers default font-size by setting it in px on html element. So just forget my proposal. :)

While I wouldn't subscribe to the idea of changing the system to px over rem, I believe there is an argument to be made for a pixel utility for occasions when you need the fine grained control that pixel level adjustments give you.

The best thing about tailwind is its ability to add more fine grained control over elements in a simply way, ie: not having to write your own classes. And while I absolutely love tailwind, and I mean LOVE ... I find there are times when it's seems a bit opinionated and forces the user to break out of the tool to solve a given issue.

Let me give an example that I gave on Twitter.

I have a button with pt-2 (which is translated to 8px) but because the text has a lowercase G it visually looks too small to use pb-2. So I tried pb-3 (12px) and that's simply too much, what I need, is a simple one-off way to call for a 10px padding without the need to create a new class, or make tailwind config adjustments, or to have to break out of the consistency of the tool.

In my case I was forced to eliminate the bottom padding from the class tag and use a style tag on the element to set it to padding-bottom:10px. Obviously this isn't the end of the world, especially since these are normally one-off events and a little inline styling never hurt anyone.

But would it not fit the tailwind ideology to have this functionality baked in as a utility?

I would propose a simple utility for any elements that use rem measurements currently that allows the user to call a pixel based measurement on a given element when it's needed. I know this is possible because we have the px classes now that set elements to 1px.

For instance given my previous example:

class="pt-2 pb-x10"

Where x would tell tailwind to use the number that follows and pixels for bottom-padding on this selector.

Obviously it wouldn't need to be an x, Adam and the team would be better suited to select the correct character to preceed the pixel count, but you get the idea.

Not something that would be used all the time, but I think it would be a useful utility to add to make the tool more complete and flexible.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

manniL picture manniL  Â·  3Comments

dbpolito picture dbpolito  Â·  3Comments

jbardnz picture jbardnz  Â·  3Comments

lamberttraccard picture lamberttraccard  Â·  3Comments

ouun picture ouun  Â·  3Comments