Tailwindcss: Negative insets?

[benface]

Sometimes it's useful to have negative values for top, right, bottom, or left. Should there be a negativeInset theme key, like negativeMargin, to generate those? The classes would be -inset-[key], -top-[key], etc.

[hacknug]

Can we use this as an excuse to discuss the possibility of also adding negativeZIndex or defining an alternative way of handling negative values?

[adamwathan]

Been thinking about this in general, I honestly hate that the negativeMargin plugin even exists, I wish it was just margin and supported negative values.

If classes like mx--6 didn't look so stupid I would just use those. We thought about mx-n6 but I kinda hate that too.

We could bake some logic into the plugins to detect negative values and add the - prefix but I'm not sure what that would look like in the config — what would the keys be for those values?

margin: {
  '-6': '-1.5rem',
  // ...
}

Seems sort of too magical for the plugin to parse that prefix, detect that it starts with a -, and move that dash to the beginning of the class instead.

In a perfect world though there would be some way to handle negative values elegantly without creating two separate plugins for each property. Anyone got any ideas on how that could look and not be awful?

[tlgreg]

I'm leaning towards the key naming convention of prefixing with a -, I wouldn't really miss the separate variants for negativeMargin.
One more way I'm thinking which wouldn't need anything major change in the config file would be to have a "negativeAnything" plugin which looks for negative prefixes on the plugin key level. The possible breaking change in this is with plugins which would otherwise use a key starting with negative.
But this is still "magical" just different structure...

[hacknug]

What I did for one of my plugins was checking if the first character of the value was a - and if so, prepend it to the class name. That never seemed a good idea to me.

I feel like treating negative as something special inside Tailwind itself just like what we're already doing with default could be the right move. Maybe adding negative: true inside the plugins config object would be enough?

[tlgreg]

I don't like relying on the value, because the user can put anything there (a calc for example) and this assumes you use a plain value.

[tehpsalmist]

I'd put in a vote for m--6. It might not look great, but I would say it gets the semantic job done, especially if you are aware of all the other conventions. Nothing else uses a double dash. It also saves us from having to do any javascript voodoo to prepend characters to class names. Just my two cents.

[manniL]

Seems sort of too magical for the plugin to parse that prefix, detect that it starts with a -, and move that dash to the beginning of the class instead.

If it's a "system-wide" convention I personally don't see an issue with it. But I understand that keeping as less magic as possible makes sense.

[VinSpee]

this might be a stretch, but here's a potential solution:

https://www.accountingcoach.com/blog/use-of-parentheses

A negative amount, such as a negative balance in your check register

so maybe something like:

m-(6)

it'd be easy for plugins to parse as well.

[leolanavo]

Leaving my 2 cents here. I really like a prefixed token, such as n (negative) or m (minus) , something like:

This is kinda idiomatic, the dev could read margin negative six.

Another alternative, was to add the token to at the first part of the class (before the hyphen), becoming mxn-6, but this is really ugly.

[MatanYadaev]

mx-n6 is the best convention for this utility

[regularlabs]

Why not add 2 characters so it is clear what is going on?
mx-min6 or mx-neg6.

Or maybe even mx-0-6.

[adnanbrq]

What about this:

1. -6m, -6mx, -6my, etc.
2. -6-mx, 6-mx
3. mx-6 (Negative), mx+6 (Positive)
4. mx-6-p (p: Positive), mx-6-n (n: Negative)

Personally I like (3) and (4) the most. It also forces the user to be explicit.
Some may say "-p" would be unnecessary but I think this lets the user intuitively figure out how to apply a negative margin.

[sandren]

I think we should evaluate this decision in the context of _all_ possible conventions for _all_ possible uses of negative values:

option a (existing convention)
-m-6
-order-6
-z-6

option b
m-n6
order-n6
z-n6

option c
m-n-6
order-n-6
z-n-6

option d
m-neg-6
order-neg-6
z-neg-6

option e
n-m-6
n-order-6
n-z-6

option f
neg-m-6
neg-order-6
neg-z-6

option g
m--6
order--6
z--6

When we evaluate the options in this context, I think that option G is the least awful choice because, in my opinion, it is the fastest to parse and accurately reflects the underlying values.

[Brainyac]

I'd lean towards the option B or G.
As a newcomer to Tailwind it seems the most intuitive for me.

[regularlabs]

Vote for option G

On Tue, Apr 23, 2019, 10:22 WellBrained [e-mail] wrote:

I'd lean towards the option B or G.
As a newcomer to Tailwind it seems the most intuitive for me.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/tailwindcss/tailwindcss/issues/848#issuecomment-485693965,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADHM4WUZW6P7BLNI37U6CSTPR3BIBANCNFSM4HGQK43A
.

[hacknug]

I've used both A and B in some of my projects. B because you don't need to change anything to generate negative utilities and A because it makes it look more Tailwind (given how negativeMargin works). I personally prefer how A looks but wouldn't mind settling for B or G.

[shivampaw]

As someone who hasn’t actually used tailwind much but is about to start (yay for me!) the double - seems simplest and the most obvious to me. The others break away from convention in my opinion and whilst I get that m-–6 might not look amazing for all I think it’s definitely clear as to what it’s doing

[jacobgraf]

I also vote for option G. It isn’t pretty, but makes the most sense.

[jalendport]

Option G is definitely out of the question for me. I think it would be way too easy to mistake the double hyphen -- for a single hyphen - in certain fonts and code editor settings. - is already serving another purpose in Tailwind (kebab-case class names); I don't think we should reuse it.

[foucist]

I'm a fan of option A. alternatively, could change tailwind to snake case? then you'd get m_-6

[librevlad]

I guess this is going to be controversial but let's try:

my:6 mx:-6 flex@md flex-row@lg bg-red@hover

bonus: using affixes with @ for variants makes them fit better semantically. Like 'flex at md, flex-row at lg'

[VinSpee]

@librevlad I love state/attr:val@mq, it's the syntax i use for shed.css (which you should not use, I don't make updates almost ever).

@adamwathan mentions here that dashes have become a bit of a challenge: https://twitter.com/adamwathan/status/1120698395499253761 - but changing the syntax like that would be a huge burden for consumers.

example:

hover/mx:-6@md

reads:

"under hover, margin-x should be -6 units, at medium widths"

[HellPat]

Mhh, has anybody ever used a negative Value without the corresponding positive one?
I'm thinking about something like this:

{
    margin: {
        '6': withNegative('1.5rem'),
    }
}

[ddevdreamer]

I guess this is going to be controversial but let's try:

my:6 mx:-6 flex@md flex-row@lg bg-red@hover

bonus: using affixes with @ for variants makes them fit better semantically. Like 'flex at md, flex-row at lg'

This looks so good.

[rverrips]

I missed the voting poll on this (if there was one) but would like to throw my hat into the "option g-Ring", i.e. m--6 / order--6 / z--6

For best evaluation, I think we need to add some context:

```html

Click me

[foucist]

@adamwathan mentions here that dashes have become a bit of a challenge: https://twitter.com/adamwathan/status/1120698395499253761 - but changing the syntax like that would be a huge burden for consumers.

Burden to which consumers though? Wouldn't most tailwindcss users find it easy to make the switch with a global search and replace? Might be more work for changing the utilities/plugins though I guess

[regularlabs]

Yeah, I agree. I would love to see the syntax changed before stable is released.
And going for the -mx-6 syntax seems like a compromise that doesn't need to be taken.

Grab the chance to change the syntax now, as it is probably the last chance you get (as we're still in beta).

So as mentioned by @librevlad and @VinSpee, a syntax like this would be great and way more readable and extensible:

my:6 mx:-6 flex@md flex-row@lg hover/bg-red hove/bg-green@md

Also, would it then also be flex:row instead of flex-row and bg:red instead of bg-red ?!

[librevlad]

Nice catch! Yeah, I meant

my:6 mx:-6 flex@md flex:row@lg bg:red@hover

Not sure about slash notation though.
I would like to say I'm pretty happy with the current -my-6 -z-1 convention, but if we're going to change syntax at some point, this one is what comes to my head first.

[regularlabs]

And @adamwathan loves it too, as far as I could tell.
He just wants to break B/C a little bit instead of going the whole way ;)

[VinSpee]

@foucist

“Wouldn't most tailwindcss users find it easy to make the switch with a global search and replace?”

If a user is working on a large or sprawling project, even that can be tricky. It’s also challenging in the (likely small) case where a user is changing parts of classnames with javascript.

That being said, I think a codemod would be helpful (and necessary) for most users.

If there were to be a large API change, now would probably be the time to do it, but the cost to the project can’t be ignored.

[adamwathan]

Yeah not making that change, way too extreme.

[adamwathan]

Negative insets and z-index will be supported in beta 6 which will hopefully be out this afternoon.