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

[AndreasHeintze]

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.

[benface]

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.

[AndreasHeintze]

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.

[adamwathan]

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 ***@***.***> 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 <#800 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEH3bDg2H0Pfa3vWhLevsJvLOghdFb70ks5vZUtYgaJpZM4cEa-n> .

[AndreasHeintze]

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. :)

[ghost]

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.

[andynunes]

I'm just getting started with tailwind, and I already love it. You guys rock.

In building my first 3 components from pixel-perfect wireframes, I have also encountered similar scenarios to what @19peaches described above.

To use values in pixels that aren't multiples of 4, I've extended the theme, like:

      padding: {
        '3px': '3px',
        '5px': '5px',
        '15px': '15px',
        '17px': '17px'
      },

I can then use classes like px-15px.

But this just feels wrong and I'm trying to avoid defining custom classes in my components if possible.

I too would be excited to use an option that outputs classes explicitly using pixels as units, something like described above. I would even be willing to help build and/or test the feature.

[vukadinFE]

#4035

I am leaving adjustment suggestion here because this "issue" is most relevant

[s-ol]

Using rem is great when you are working on a self-contained website, but can be a big problem otherwise. For example I am trying to use tailwindcss in a web extension right now, and the rem-based-ness means that my UI (although insulated in a div with all: initial and a shadow root) randomly gets scaled when websites set font-sizes other than 16px on the HTML element, which is unacceptable.

There is no way to reset the rem unit / document root, or otherwise encapsulate my extension elements from the websites that can prevent this; the only solution would be to change the base unit used by the tailwindcss default styles.

[owex]

I would like to add my support for an optional flag to generate tailwind with pixel, although i usually would defer to using rem recently i've been doing allot of work where i'm building embeddable components using Tailwind.

To insulate the component from being impacted by a rogue root font size having the option to generate Tailwind output with pixels rather than rem would be very helpful.

[s-ol]

Here's a snippet from a tailwind.config.js that I'm using to deal with this at the moment:

const plugin = require("tailwindcss/plugin");
const theme = require("tailwindcss/defaultTheme");

const deepMap = (val, fn) => {
  const it = (val) => {
    if (Array.isArray(val)) return val.map(it);

    if (typeof val === "object") {
      const res = {};
      for (const key of Object.keys(val)) {
        res[key] = it(val[key]);
      }
      return res;
    }

    return fn(val);
  };

  return it(val);
};

const pxify = (val) => {
  if (typeof val === "string")
    val = val.replace(/((\d*\.)?\d+)rem\b/g, (match, num) => `${16 * +num}px`);

  return val;
};

const emify = (val) => {
  if (typeof val === "string")
    val = val.replace(/((\d*\.)?\d+)rem\b/g, (match, num) => `${num}em`);

  return val;
};

const suffixKeys = (obj, suffix) => {
  return Object.fromEntries(
    Object.entries(obj).map(([k, v]) => [k + suffix, v])
  );
};

const pxifyDefaults = (theme, keys) => {
  const res = {};
  for (const key of keys) res[key] = deepMap(theme[key], pxify);
  return res;
};

module.exports = {
  theme: {
    ...pxifyDefaults(theme, [
      "borderRadius",
      "lineHeight",
      "maxWidth",
    ]),
    spacing: {
      ...deepMap(theme.spacing, pxify),
      ...deepMap(suffixKeys(theme.spacing, "-r"), emify),
    },
    fontSize: {
      ...deepMap(theme.fontSize, pxify),
      ...deepMap(suffixKeys(theme.fontSize, "-r"), emify),
    },
  }
};

This will change most classes to use px values, but also add *-r classes with em units.

[BenLorantfy]

Isn't it surprising that changing your font size in the browser setting also changes the padding? If a user changes the font size, I would figure they wouldn't expect spacing and other dimensions to change.

Usually people use the browser zoom to change the CSS reference pixel. Doing everything in rem means zooming + changing browser font size does the same thing, which feels redundant. If everything is in REM, the user has no way to increase the font size without also zooming everything else.