[Proposal] Refactor frontend hide/hidden mechanism

[wxiaoguang]

The Problem

There are at least 5 different "hiding" methods in code:

• Fomantic-UI's .hidden class
• Browser and Fomantic-UI's [hidden] attribute
• Gitea's .hide class
• Inline style="display: none"
• jQuery's hide() (show/toggle)

Some of these mechanisms just conflict:

• [hidden] is the weakest one, it will be affected by display: xxx
• Sometimes, it should use display: none !important to overwrite other style's display: block
• Fomantic-UI's .hidden has other definitions for different selectors
• jQuery's hide() may not work well with some display: none !important

The Solution

• Introduce our own .gt-hidden { display: none !important; }
  • the !important is necessary because there are always block or flex elements need to be hidden
  • done in Move helpers to be prefixed with gt- #22879
• Hijack jQuery's hide() and related functions to use our .gt-hidden
  • Extend jQuery with customized show/hide/toggle #22884
  • Update: replaced by our own showElem and related function, all-in-one step. Refactor hiding-methods, remove jQuery show/hide, remove .hide class, remove inline style=display:none #22950
• Drop all other classes/attributes, only use the .gt-hidden to hide

FAQ

Why the gu- prefix? (Or something else like gt-, etc...)

• It means "Gitea UI", it's time to have our own frontend framework and have a global design, instead of patching everything again and again.
• It is a clear style, won't be polluted by Fomantic UI
• It makes the refactoring clear, every changed line could be reviewed to check whether something is affected.
• It makes it easier to be searched from whole code base, since it's a dedicated name.
• It's widely accepted to add prefixes for frameworks. For example, tailwind also supports prefix: https://tailwindcss.com/docs/configuration#prefix

[silverwind]

Another problem with jQuery hide and show is that like any other inline CSS, it does not work without CSP unsafe-inline, so that is another reason to remove it. Als with the removal enable the eslint rules jquery/no-hide and jquery/no-show to detect cases and forbid them in future code.

I'm not sure about the classname prefix. I'm more of the opinion we should eventually migrate to tailwind or one of it's many "forks", and for this use case, we better match the helper names to those frameworks (thought I imagine we can not get around the !important requirement for the helpers until we remove fomantic-ui completely.

[wxiaoguang]

Another problem with jQuery hide and show is that like any other inline CSS, it does not work without CSP unsafe-inline, so that is another reason to remove it. Als with the removal enable the eslint rules jquery/no-hide and jquery/no-show to detect cases and forbid them in future code.

Really? I think unsafe-inline only forbids the style="xxx" in HTML, but it doesn't forbid changing style by JS, right? Correct me if I am wrong.

I'm not sure about the classname prefix. I'm more of the opinion we should eventually migrate to tailwind or one of it's many "forks", and for this use case, we better match the helper names to those frameworks (thought I imagine we can not get around the !important requirement for the helpers until we remove fomantic-ui completely.

About "eventually migrate to": I am not sure how long does "eventually" mean. If it means years, I wouldn't say that's practicable or feasible. I have explained the refactoring problem in the jQuery-dropping discussion: if there is no plan to guarantee that the refactoring can succeed in short time, people come and go, code using old framework always comes, then it will become a endless whack-a-mole game.

The prefix is a must.

• Your .hidden from #22845 is different from tailwind or other frameworks. They would conflict in the end.
• The prefix makes it easier to be globally searched and replaced.

---

Update: one more thing, the !important seems necessary in Gitea's frontend framework, because there are always some block or flex elements need to be hidden.

[wxiaoguang]

Also call TOC here, go or no go.

@lunny @techknowlogick @6543 @zeripath @jolheiser @wolfogre

[wolfogre]

TBH, I don't have enough front-end development experience to judge this. In response, I abstain and respect the opinions of other TOC.

[silverwind]

It seems needlessly complex to me to introduce a gitea-specific class prefix. Some people are accustomed to tailwind classes, so I would make it easy for them and use the original class names (which may conflict with fomantic, but fomantic needs to go sooner or later anyways).

If possible, I'd like us to implement tailwind-compatible classes, but I'm not sure how the tooling can be made to parse the golang templates so their tree-shaking of classes can work. I imagine a special parser will be necessary to extract classes in-use from the go templates. Also, I'm pretty sure we will need the !important suffix on all rules, at least until we get rid of fomantic.

[wxiaoguang]

Some people are accustomed to tailwind classes,

Most people just copy & paste the existing code in project. They do not care what are the details behind it.

so I would make it easy for them and use the original class names (which may conflict with fomantic,

Your .hidden with !important is not really tailwind style. Tailwind's hidden doesn't have the !important, the different behavior may surprise developer much more.

You can see there are:

1. .ui.checkbox input.hidden { z-index: -1;}
2. .ui.menu .hidden { visibility: none;}

Maybe more.

but fomantic needs to go sooner or later anyways). .... at least until we get rid of fomantic.

When?

[silverwind]

Your .hidden with !important is not really tailwind style. Tailwind's hidden doesn't have the !important, the different behavior may surprise developer much more.

Yes, tailwind by default assumes it is the only style system in use and in such a happy world, there is no need for !important, but as soon as you add another, specificity issues are bound to happen and can only be remedied by !important.

[wxiaoguang]

So , do not make the .hidden harder to understand.

Even with the .gu- prefix, after removing the fomantic, you can do a global replace to rename it to anything you like. That's the good side of the prefix.

[silverwind]

BTW I'm tired of having to discuss this !important topic again and again. It is a necessary evil that can not be removed unless you have a single style system which will not happen until at least fomantic is out.

[wxiaoguang]

I have said !important is necessary for this case (many times in this issue). My point is clear: do not make surprise for developers. Make every name clear and unique/dedicated.

[wxiaoguang]

OK, let's focus on this problem. Could you agree with:

• If most people like the .hidden style, you do the refactoring (you choose the time)
• If most people like the .gu-hidden style, I do the refactoring (I will try to finish it in a few days)
• If few people like this proposal, let's close it (in 7 days)