Tailwindcss: [Feature Proposal] transform: translate

Created on 24 Jun 2019 · 7Comments · Source: tailwindlabs/tailwindcss

I find myself copy and pasting the same code-snippet from project to project, which is:

.pullout-b {
  transform: translateY(100%);
}

.pullout-t {
  transform: translateY(-100%);
}

.pullout-l {
  transform: translateX(-100%);
}

.pullout-r {
  transform: translateX(100%);
}

.pullout-reset {
  transform: translate(0, 0);
}

This allows the element that gets this class applied to be moved in any direction _by its exact, outer size_.

I have used this technique a lot over the last few years and I think it would be a great addition to tailwind.

That said: I don't think the classnames are really all that good. Thoughts?

Source

mradke

👍2

Most helpful comment

As I am designing, I find I am routinely adding translate utilities. Some defaults would be nice. Maybe translate units could be consistent with padding utils. For clarity, it might be nice to use up, down, left, right, in, and out to define the direction.

For example:

In practice, the units from .padding may not be ideal, but I think they would serve as a good starting point. Scale & rotate utilities could also be useful.

type1fool on 10 Aug 2019

👍3

All 7 comments

@mradke I definitely also create classes like this. Another useful value is translateY(-50%) which will vertically center an element when combined with inset-t-1/2 i.e. top: 50%

Re: class names, I usually prefer to keep it more abstract with something like move-y-100, or even stay true to the CSS value and use translate-y-100.

I think that before we see any transform values integrated into Tailwind as a core plugin, the scope of Tailwind's design system has to expand. In my mind, the current design system answers these key questions:

How big should things be?
What color should things be?
How should typography look?
How should children elements be laid out/positioned/overflowed?
What should user interaction feel like (e.g. cursor, pointer-events, user-select)

transform values answer the question "How far should things be allowed to move?" which is a question better answered by a motion design system.

An official Tailwind motion design system would dictate how far things are able to move, and would also pave the way for utilities for transition duration & easing (see #14), and for other transform values like scale and skew.

Some background reading on building motion design systems: https://www.designsystems.com/5-steps-for-including-motion-design-in-your-system/

AlexVipond on 25 Jun 2019

❤1

I think staying true to the CSS value would be a wise choice here.

mradke on 25 Jun 2019

👍1

.translate-y-50 (50% down)
.-translate-y-50 (50% up)

Would be my preference to keep with the current way negative margins are handled for example.

TheDutchCoder on 9 Jul 2019

👍3

For example:

In practice, the units from .padding may not be ideal, but I think they would serve as a good starting point. Scale & rotate utilities could also be useful.

type1fool on 10 Aug 2019

👍3

For clarity, it might be nice to use up, down, left, right, in, and out to define the direction.

For consistency with the padding and margin utilities I would say negative and positive x and y values would be easier to remember.

Class|Properties
------|-----
.translate-x-1 | transform: translateY(0.25rem);
.-translate-x-1 | transform: translateY(-0.25rem);
.-translate-y-1 | transform: translateX(-0.25rem);
.translate-y-1 | transform: translateX(0.25rem);
.translate-z-1 | transform: translateZ(0.25rem);
.-translate-z-1 | transform: translateZ(-0.25rem);
... | ...
.translate-x-px | transform: translateY(1px);
... | ...
.translate-x-1/2 | transform: translateY(50%);

In practice, the units from .padding may not be ideal, but I think they would serve as a good starting point. Scale & rotate utilities could also be useful.

Whenever I use translate it's usually just with percentages. I think rem or px should be optional via the config file.