Add merge arrow direction and update styling

[kdumontnu]

Close #28522

Adds some negative margin helper css classes using tailwind's prefix syntax

Before

After

[kdumontnu]

Unrelated CI failure

[wxiaoguang]

My thoughts: #28523 (comment)

ps: I also prefer to use something else, instead of tricky negative margin -- if possible.

1. I do not think it's good to introduce these tricky negative margin helpers.
   • At least, could it use the styles provided by the CSS class names?
2. Why not just simply show the "left arrow"? Then the layout could also be simple and clear.

---

(I won't block if most people would like to use the negative margin here)

[kdumontnu]

I don't see anything wrong with negative margion, and the way I've implemented it aligns with the tailwind-like schema we have committed to.

This PR is ready to go.

[kdumontnu]

If the negative margin definitions are weirding people out, I can use the old non-gt method for defining it, but what I've implemented is what we've agreed to.

[wxiaoguang]

If the negative margin definitions are weirding people out, I can use the old non-gt method for defining it, but what I've implemented is what we've agreed to.

I wrote these documents. But I would like to say "no" (personally) to these negative margins at the moment because I don't see they are "general" or "useful" helpers.

For the tailwind problem, maybe this issue could partially answer your questions: #23011

For example, I guess few people could understand this code:

<div class="code-comment-buttons gt-df gt-ac gt-fw gt-mt-3 gt-mb-2 gt-mx-3">

Why not just clearly define the styles for UI components/elements?

IMO these helpers are only for "fine-tuning" purpose: if some common/general/existing classes don't fit a special case, then use these helper functions to "fine tune".

---

I am not the frontend expert, nor a experienced tailwind library user. So as I said above: I won't block if most people would like to use the negative margin helpers here.

[kdumontnu]

If the negative margin definitions are weirding people out, I can use the old non-gt method for defining it, but what I've implemented is what we've agreed to.

I wrote these documents. But I would like to say "no" (personally) to these negative margins at the moment because I don't see they are "general" or "useful" helpers.

For the tailwind problem, maybe this issue could partially answer your questions: #23011

For example, I guess few people could understand this code:

<div class="code-comment-buttons gt-df gt-ac gt-fw gt-mt-3 gt-mb-2 gt-mx-3">

Why not just clearly define the styles for UI components/elements?

IMO these helpers are only for "fine-tuning" purpose: if some common/general/existing classes don't fit a special case, then use these helper functions to "fine tune".

I'm not an expert either, but I believe what you've described above is tailwind. So maybe that's not the direction we want to go? I'm just confused because I tried to follow the direction I believed we were moving the styling and I seem to have missed the boat. But that just seems to be where we're at with front-end right now.

I am not the frontend expert, nor a experienced tailwind library user. So as I said above: I won't block if most people would like to use the negative margin helpers here.

I wrote these documents.

I'm really glad you wrote & updated those docs (and your contributions in general). For better or worse though, it seems you are the owner of this document & strategy. Maybe we can work together to update it. Maybe gitea should put out a request for a front-end developer. Everyone who has looked at this has unfortunately said "I'm not the UI expert". It seems there is support for the feature - all I'm trying to do is overlap the two elements slightly so that they don't look terrible. Imo, that is why negative margin exists.

I've changed the implementation here to use a general CSS class. We could do something similar with fomantic with ui center aligned, but ironically it would still require a definition for negative margin helper class.

[kdumontnu]

There are two questions here I think I'm conflating:

1. Do we want to move to tailwind and use those definitions as the primary styling?
2. Do we want to avoid using negative margin (either in this implementation or general)?

Once I have these answers I can build a solution.

[wxiaoguang]

There are two questions here I think I'm conflating:
1. Do we want to move to tailwind and use those definitions as the primary styling?
2. Do we want to avoid using negative margin (either in this implementation or general)?
Once I have these answers I can build a solution.

For 2, I think they should be used if it is necessary, but maybe it is too early to introduce general helpers. There are already a lot of negative margins in code base, many of them are like "-1px" or some special values for hacking Fomantic UI margins.

For 1, I have no idea at the moment. If majority all agree to do so and have a clear&feasible plan and work together (to rewrite existing code & help new contributors to rewrite their PR), then it could go. Otherwise, I do not see why it would succeed.

[lunny]

There are two questions here I think I'm conflating:

1. Do we want to move to tailwind and use those definitions as the primary styling?

2. Do we want to avoid using negative margin (either in this implementation or general)?

Once I have these answers I can build a solution.

I personally agree we should move to tailwind.