[Proposal] Refactor frontend hide/hidden mechanism #10247

@silverwind commented on GitHub (Feb 10, 2023):

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.

@silverwind commented on GitHub (Feb 10, 2023): 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.

GiteaMirror commented

@wxiaoguang commented on GitHub (Feb 10, 2023):

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 commented on GitHub (Feb 10, 2023): > 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.

GiteaMirror commented

@wxiaoguang commented on GitHub (Feb 10, 2023):

Also call TOC here, go or no go.

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

@wxiaoguang commented on GitHub (Feb 10, 2023): Also call TOC here, go or no go. @lunny @techknowlogick @6543 @zeripath @jolheiser @wolfogre

GiteaMirror commented

@wolfogre commented on GitHub (Feb 10, 2023):

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

@wolfogre commented on GitHub (Feb 10, 2023): TBH, I don't have enough front-end development experience to judge this. In response, I abstain and respect the opinions of other TOC.

GiteaMirror commented

2025-11-02 09:02:05 -06:00

@silverwind commented on GitHub (Feb 10, 2023):

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.

@silverwind commented on GitHub (Feb 10, 2023): 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.

GiteaMirror commented

@wxiaoguang commented on GitHub (Feb 10, 2023):

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:

.ui.checkbox input.hidden { z-index: -1;}
.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?

@wxiaoguang commented on GitHub (Feb 10, 2023): > 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?

GiteaMirror commented

2025-11-02 09:02:05 -06:00

@silverwind commented on GitHub (Feb 10, 2023):

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.

@silverwind commented on GitHub (Feb 10, 2023): > 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`.

GiteaMirror commented

@wxiaoguang commented on GitHub (Feb 10, 2023):

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.

@wxiaoguang commented on GitHub (Feb 10, 2023): 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.

GiteaMirror commented

@silverwind commented on GitHub (Feb 10, 2023):

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.

@silverwind commented on GitHub (Feb 10, 2023): 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.

GiteaMirror commented

@wxiaoguang commented on GitHub (Feb 10, 2023):

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 commented on GitHub (Feb 10, 2023): 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.

GiteaMirror commented

@wxiaoguang commented on GitHub (Feb 10, 2023):

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)

@wxiaoguang commented on GitHub (Feb 10, 2023): 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)

GiteaMirror commented

@jolheiser commented on GitHub (Feb 10, 2023):

Tailwind or not, is there any way to do a gradual transition? And which style do you think would make that hypothetical transition easier?

If parsing the templates is doable, and we can post-process to add !important, maybe that's feasible?

@jolheiser commented on GitHub (Feb 10, 2023): Tailwind or not, is there any way to do a gradual transition? And which style do you think would make that hypothetical transition easier? If parsing the templates is doable, and we can post-process to add `!important`, maybe that's feasible?

GiteaMirror commented

@wxiaoguang commented on GitHub (Feb 10, 2023):

Tailwind or not, is there any way to do a gradual transition? And which style do you think would make that hypothetical transition easier?

The transition plan is: removing Fomantic modules one by one, for example, the tooltip, image, ... modules have been removed, customized dropdown has been reverted to the official one, etc. Maybe the checkbox module could be removed next.

But this style discussion is not related to the transition. The hidden class is an essential CSS class, it's the lowest-level design.

The divergence is:

silverwind prefers to re-use the .hidden name from Fomantic UI, which is (in my mind):
- looks like a tailwind class name but it's different from the tailwind's one
- has been polluted by the Fomantic UI framework in some cases
I prefer to use a totally new/dedicated name with prefix: .gu-hidden, then:
- new developers should get used to it (they could just copy & paste existing code)
- is a clear style without any pollution, won't cause surprises for developers of tailwind or other frameworks
- could be replaced to any new name after removing Fomantic

If parsing the templates is doable, and we can post-process to add !important, maybe that's feasible?

There is nothing with the !important indeed, it is necessary for either .hidden or .gu-hidden.

Above is just my opinion, and I am open for TOC's final decision.

@wxiaoguang commented on GitHub (Feb 10, 2023): > Tailwind or not, is there any way to do a gradual transition? And which style do you think would make that hypothetical transition easier? The transition plan is: removing Fomantic modules one by one, for example, the tooltip, image, ... modules have been removed, customized dropdown has been reverted to the official one, etc. Maybe the checkbox module could be removed next. But this style discussion is not related to the transition. The `hidden` class is an essential CSS class, it's the lowest-level design. The divergence is: * silverwind prefers to re-use the `.hidden` name from Fomantic UI, which is (in my mind): * looks like a tailwind class name but it's different from the tailwind's one * has been polluted by the Fomantic UI framework in some cases * I prefer to use a totally new/dedicated name with prefix: `.gu-hidden`, then: * new developers should get used to it (they could just copy & paste existing code) * is a clear style without any pollution, won't cause surprises for developers of tailwind or other frameworks * could be replaced to any new name after removing Fomantic > If parsing the templates is doable, and we can post-process to add `!important`, maybe that's feasible? There is nothing with the `!important` indeed, it is necessary for either `.hidden` or `.gu-hidden`. ---- Above is just my opinion, and I am open for TOC's final decision.

GiteaMirror commented

@wxiaoguang commented on GitHub (Feb 10, 2023):

One more thing worth to be mentioned: it's widely accepted to add prefixes for frameworks. For example, tailwind also supports prefix: https://tailwindcss.com/docs/configuration#prefix . If we want to introduce it, the prefix is always the best choice, to avoid unnecessary conflicts: .tw-hidden, .tw-text-left, etc.

@wxiaoguang commented on GitHub (Feb 10, 2023): One more thing worth to be mentioned: it's widely accepted to add prefixes for frameworks. For example, tailwind also supports prefix: https://tailwindcss.com/docs/configuration#prefix . If we want to introduce it, the prefix is always the best choice, to avoid unnecessary conflicts: `.tw-hidden`, `.tw-text-left`, etc.

GiteaMirror commented

@zeripath commented on GitHub (Feb 10, 2023):

I guess the question is do we have any other things that would have this proposed gu- prefix?

At present, this would stand out completely separately from the rest of our class names - and I'm not sure of the benefit when we could just use .hide which is essentially your proposed style just lacking the !important.

I think fomantic's .hidden has different definitions for different selectors because the proposed display: none !important; is a bit of blunderbuss and fomantic has its own semantics related to hidden that are not completely about making things absolutely invisible. Thus I think overloading that will be a bad idea.

Of course I guess we could actually prefix all of those other !important class modifiers that we have, e.g. mr-2 becomes gu-mr-2 that would at least make them less likely to conflict with things and make us more likely to just move them into classes - like they should be.

In fact if we can just drop all of our modifications from base fomantic, and begin moving code on to gitea- classes that might, just might, make extracting out fomantic easier.

So:

👎 to overloading .hidden - it will conflict with fomantic. We're already seeing issues where we've broken fomantic's styling and we blame it when it's often due to styling we've imposed on top of it.
〰️ I'm uncertain about the gu- prefix - having only one class with the prefix is janky as hell. If there are others then it makes more sense.
〰️ I think just using .hide might be the answer - leave .hidden for fomantic.

What's motivated you into looking in to this? Why now? Why this particular weirdness?

@zeripath commented on GitHub (Feb 10, 2023): I guess the question is do we have any other things that would have this proposed `gu-` prefix? At present, this would stand out completely separately from the rest of our class names - and I'm not sure of the benefit when we could just use `.hide` which is essentially your proposed style just lacking the `!important`. I think fomantic's `.hidden` has different definitions for different selectors because the proposed `display: none !important;` is a bit of blunderbuss and fomantic has its own semantics related to hidden that are not completely about making things absolutely invisible. Thus I think overloading that will be a bad idea. Of course I guess we could actually prefix all of those other `!important` class modifiers that we have, e.g. `mr-2` becomes `gu-mr-2` that would at least make them less likely to conflict with things and make us more likely to just move them into classes - like they should be. In fact if we can just drop all of our modifications from base fomantic, and begin moving code on to `gitea-` classes that might, just might, make extracting out fomantic easier. --- So: * :-1: to overloading `.hidden` - it will conflict with fomantic. We're already seeing issues where we've broken fomantic's styling and we blame it when it's often due to styling we've imposed on top of it. * :wavy_dash: I'm uncertain about the `gu-` prefix - having only one class with the prefix is janky as hell. If there are others then it makes more sense. * :wavy_dash: I think just using `.hide` might be the answer - leave `.hidden` for fomantic. --- What's motivated you into looking in to this? Why now? Why this particular weirdness?

GiteaMirror commented

@lunny commented on GitHub (Feb 11, 2023):

I learnt something from introducing #21986 . If we want to do a big refactor, introduce a new method/mechanism is easier than replacing the old method/mechanism. If this is the beginning of the refactor from Fomantic-UI to Tailwind, I agree to have a prefix will be better for the progress of migrating. For the prefix name, we could have more thought than gu.

@lunny commented on GitHub (Feb 11, 2023): I learnt something from introducing #21986 . If we want to do a big refactor, introduce a new method/mechanism is easier than replacing the old method/mechanism. If this is the beginning of the refactor from Fomantic-UI to Tailwind, I agree to have a prefix will be better for the progress of migrating. For the prefix name, we could have more thought than `gu`.

GiteaMirror commented

@wxiaoguang commented on GitHub (Feb 11, 2023):

Answer to:

What's motivated you into looking in to this? Why now? Why this particular weirdness?

I have been thinking about this problem since my first frontend refactoring plan (the time I started spending time on Gitea), see #17149 (I would suggest people to read it again .... those are all mistakes Gitea had made in history) and related https://docs.gitea.io/en-us/guidelines-frontend/#gitea-specific-guidelines :

CSS styling for classes provided by frameworks should not be overwritten. Always use new class-names with 2-3 feature related keywords to overwrite framework styles.

I have realized at that time:

the frontend is becoming more and more messy
the messy code causes more and more problems
sometimes people complains Fomantic but actually the problem is cauesd by Gitea itself

But there were a lot of obstructions for doing refactoring. Recently there is TOC for Gitea, I'd like to see whether it's possible to push the refactoring and make the codebase more healthy.

For the hiding problem itself:

there are not only one hiding-related bugs (maybe a lot), it wastes a lot of time (details in the The Problem section)
some recent PRs are still related to this problem:
- I can not find a good method to remove inline style for my PR #22807
- the new regression-fix PR #22845

@wxiaoguang commented on GitHub (Feb 11, 2023): Answer to: > What's motivated you into looking in to this? Why now? Why this particular weirdness? I have been thinking about this problem since my first frontend refactoring plan (the time I started spending time on Gitea), see #17149 (I would suggest people to read it again .... those are all mistakes Gitea had made in history) and related https://docs.gitea.io/en-us/guidelines-frontend/#gitea-specific-guidelines : > CSS styling for classes provided by frameworks should not be overwritten. Always use new class-names with 2-3 feature related keywords to overwrite framework styles. I have realized at that time: * the frontend is becoming more and more messy * the messy code causes more and more problems * sometimes people complains Fomantic but actually the problem is cauesd by Gitea itself But there were a lot of obstructions for doing refactoring. Recently there is TOC for Gitea, I'd like to see whether it's possible to push the refactoring and make the codebase more healthy. For the `hiding` problem itself: * there are not only one `hiding`-related bugs (maybe a lot), it wastes a lot of time (details in the The Problem section) * some recent PRs are still related to this problem: * I can not find a good method to remove inline style for my PR #22807 * the new regression-fix PR #22845

GiteaMirror commented

https://dev.carsonbain.com/blog/migrate-project-to-tailwind-css

@zeripath commented on GitHub (Feb 12, 2023):

OK, the #22845 farago has absolutely convinced me.

The helpers MUST have a prefix.

I've just looked at tailwind and now it's clear to me what's happening to our styling over time... and it's clear to me that we're going to have more and more conflict with fomantic over time and if we're going to do that, we should do it using a prefix. I guess the intention is that a tailwind website has no separate less/css and everything is just done with classes in the html? Well if we want to do that - it should be easy to just double add classes for fomantic and tailwind with the tailwind classes prefixed with tw- and you can turn on and off styling with fomantic by switching in and out style file loading.

(It would of course be better if we could get all fomantic classes to have a prefix too - e.g. .fo-ui but that would any and all of the downstream themes and stylers, or get the fomantic classes to only fire if there is some root class but I don't think it can be done.)

Therefore, in addition, we should start putting a prefix on all of own document-semantic classes because otherwise it's just too hard to separate them from fomantic's.

One thing that's clear to me is that as people are moving to tailwind one of the things we're going to lose is the ability to use fomantic's documentation as descriptors for prototyping. So if the intention is tailwind we're going to need common examples of what we we're going to use.

I do think it's worth saying again - our overloading of fomantic styling has and is causing a number of problems, for example, at some point we had in our less files: .right { float: right;} (we may still have this), unsurprisingly this breaks lots of fomantic styling which uses/used .right in a more complex and subtle way.

This problem with .hidden above is similar.

Far too often we're not working with fomantic styling - we're working against it by treating it as if its tailwind when it is not - and this is at least partially due to the fact that we've already broken fomantic's styling in many places so when things are broken we're not aware of why and we blame fomantic unfairly.

However, I don't think we can go back to a situation where we can fix our styling to be compatible with plain fomantic anymore - certainly I don't think people want to. The fragility we have isn't going to get any better until we've got the templates not dependent on fomantic - so lets just do that.

Let's just follow the plan in here:

Markup the templates with non-tailwind helpers having ~~g-h- prefix~~ gt- has been chosen and tailwind classes with a tw- prefix and then get it to a point where we can drop fomantic. Consider using js- class for hooks for javascript or id where appropriate and stick gitea- prefixes on specific components.

But let's be honest about what's happening to our styling - it's being turned into tailwind - so let's just do that.

@zeripath commented on GitHub (Feb 12, 2023): OK, the #22845 farago has absolutely convinced me. ## The helpers MUST have a prefix. I've just looked at tailwind and now it's clear to me what's happening to our styling over time... and it's clear to me that we're going to have more and more conflict with fomantic over time and if we're going to do that, we should do it using a prefix. I guess the intention is that a tailwind website has no separate less/css and everything is just done with classes in the html? Well if we want to do that - it should be easy to just double add classes for fomantic and tailwind with the tailwind classes prefixed with `tw-` and you can turn on and off styling with fomantic by switching in and out style file loading. (It would of course be better if we could get all fomantic classes to have a prefix too - e.g. `.fo-ui` but that would any and all of the downstream themes and stylers, or get the fomantic classes to only fire if there is some root class but I don't think it can be done.) Therefore, in addition, we should start putting a prefix on all of own document-semantic classes because otherwise it's just too hard to separate them from fomantic's. One thing that's clear to me is that as people are moving to tailwind one of the things we're going to lose is the ability to use fomantic's documentation as descriptors for prototyping. So if the intention is tailwind we're going to need common examples of what we we're going to use. --- I do think it's worth saying again - our overloading of fomantic styling has and is causing a number of problems, for example, at some point we had in our less files: `.right { float: right;}` (we may still have this), unsurprisingly this breaks lots of fomantic styling which uses/used `.right` in a more complex and subtle way. This problem with `.hidden` above is similar. Far too often we're not working with fomantic styling - we're working against it by treating it as if its tailwind when it is not - and this is at least partially due to the fact that we've already broken fomantic's styling in many places so when things are broken we're not aware of why and we blame fomantic unfairly. However, I don't think we can go back to a situation where we can fix our styling to be compatible with plain fomantic anymore - certainly I don't think people want to. The fragility we have isn't going to get any better until we've got the templates not dependent on fomantic - so lets just do that. Let's just follow the plan in here: https://dev.carsonbain.com/blog/migrate-project-to-tailwind-css Markup the templates with non-tailwind helpers having ~~`g-h-` prefix~~ **`gt-` has been chosen** and tailwind classes with a `tw-` prefix and then get it to a point where we can drop fomantic. Consider using `js-` class for hooks for javascript or id where appropriate and stick `gitea-` prefixes on specific components. But let's be honest about what's happening to our styling - it's being turned into tailwind - so let's just do that.

GiteaMirror commented

@wxiaoguang commented on GitHub (Feb 12, 2023):

I'm afraid we can not just follow everything in https://dev.carsonbain.com/blog/migrate-project-to-tailwind-css. It only works for a team with strong leadership.

TLDR: The migration needs detailed plan and guideline for Gitea.

There are some problems for Gitea:

How to "freeze" old code? Especially when new PR comes? Suggest contributors to rewrite? Maintainers help to rewrite?
I do not feel that Gitea can introduce tailwind with !important, otherwise some Gitea's styles may need doube-important to overwrite the tailwind styles. So it requires that the new code should be clear on Gitea side.
There should be a detailed plan and guideline to guarantee the migration could succeed in predictable time and the work could be pushed to move on regularly, otherwise, the mixed code will become the next DashboardRepoList or RepoBranchTagDropdown -- which mix Go Template/Fomantic UI/Vue3/jQuery together. Maybe nobody wants to touch them (maybe except me because I had plan to refactor them ....)

@wxiaoguang commented on GitHub (Feb 12, 2023): I'm afraid we can not just follow everything in https://dev.carsonbain.com/blog/migrate-project-to-tailwind-css. It only works for a team with strong leadership. TLDR: The migration needs detailed plan and guideline for Gitea. There are some problems for Gitea: 1. How to "freeze" old code? Especially when new PR comes? Suggest contributors to rewrite? Maintainers help to rewrite? 2. I do not feel that Gitea can introduce tailwind with `!important`, otherwise some Gitea's styles may need doube-important to overwrite the tailwind styles. So it requires that the new code should be clear on Gitea side. 3. There should be a detailed plan and guideline to guarantee the migration could succeed in predictable time and the work could be pushed to move on regularly, otherwise, the mixed code will become the next `DashboardRepoList` or `RepoBranchTagDropdown` -- which mix Go Template/Fomantic UI/Vue3/jQuery together. Maybe nobody wants to touch them (maybe except me because I had plan to refactor them ....)

GiteaMirror commented