Font isn't set to Inter in some languages #41

Closed
opened 2 years ago by n · 16 comments
n commented 2 years ago
Collaborator

In Japanese, Korean and Chinese languages, --fonts-override has values set to their respective system-ui fonts.

It might be better to override the --fonts-proportional values instead.

In Japanese, Korean and Chinese languages, `--fonts-override` has values set to their respective system-ui fonts. It might be better to override the `--fonts-proportional` values instead.
n added the
Kind: Bug
Part: Fonts
labels 2 years ago
mray commented 1 year ago
Collaborator

Not sure this is a design related issue. As there is no design decision involved it seems to be a pure technical issue. Can somebody move this to a more appropriate place?

Not sure this is a design related issue. As there is no design decision involved it seems to be a pure technical issue. Can somebody move this to a more appropriate place?
fnetX commented 1 year ago
Owner

I think the problem is that this repository also serves some technical purpose, with the content being deployed on design.codeberg.org and these resources being responsible for several things (and probably also setting the Inter font). Maybe we can split this up, but AFAIK this is the best place for this issue for now.

I think the problem is that this repository also serves some technical purpose, with the content being deployed on design.codeberg.org and these resources being responsible for several things (and probably also setting the Inter font). Maybe we can split this up, but AFAIK this is the best place for this issue for now.
mray commented 1 year ago
Collaborator

What exactly is the issue here? Inter seems to not cover those languages, maybe that's the issue?:

image

Maybe there needs to be a "devops" repository hosting those issues? As a designer I can't even start to think about how design work can possibly help solve an issue like that.

What exactly is the issue here? Inter seems to not cover those languages, maybe that's the issue?: ![image](/attachments/9a186ddb-6e3d-4e90-ae2e-95cc119cea39) Maybe there needs to be a "devops" repository hosting those issues? As a designer I can't even start to think about how design work can possibly help solve an issue like that.
154 KiB
n commented 1 year ago
Poster
Collaborator

What exactly is the issue here? Inter seems to not cover those languages, maybe that's the issue?

Inter doesn't cover those languages, but when you switch Gitea to use those languages, then Inter is not applied to text in English and other supported languages. For example, this comment wouldn't use Inter at all in those languages.

Maybe there needs to be a "devops" repository hosting those issues? As a designer I can't even start to think about how design work can possibly help solve an issue like that.

+1. Could fit into a new repo under Codeberg-Infrastructure

> What exactly is the issue here? Inter seems to not cover those languages, maybe that's the issue? Inter doesn't cover those languages, but when you switch Gitea to use those languages, then Inter is not applied to text in English and other supported languages. For example, this comment wouldn't use Inter at all in those languages. > Maybe there needs to be a "devops" repository hosting those issues? As a designer I can't even start to think about how design work can possibly help solve an issue like that. +1. Could fit into a new repo under [Codeberg-Infrastructure](https://codeberg.org/Codeberg-Infrastructure/)
mray commented 1 year ago
Collaborator

Inter doesn't cover those languages, but when you switch Gitea to use those languages, then Inter is not applied to text in English and other supported languages. For example, this comment wouldn't use Inter at all in those languages.

That is strange. Sounds like it could easily be fixable by the cascading nature of CSS and adding "Inter" as an additional font after whatever gets defined for Japanese, Korean and Chinese languages.

I'd appreciate if you anybody moved this issue elsewhere.

> Inter doesn't cover those languages, but when you switch Gitea to use those languages, then Inter is not applied to text in English and other supported languages. For example, this comment wouldn't use Inter at all in those languages. That is strange. Sounds like it could easily be fixable by the cascading nature of CSS and adding "Inter" as an additional font after whatever gets defined for Japanese, Korean and Chinese languages. I'd appreciate if you anybody moved this issue elsewhere.
vhs commented 1 year ago

If the issue isn't occurring upstream in Gitea then I'd look into what existing changes need to be removed in order to leverage the existing feature. I do agree with @mray in that it's probably just a CSS font-family setting for CJK or RTL languages. But if it's already addressed in Gitea I don't see a need to solve it twice.

If the issue isn't occurring upstream in Gitea then I'd look into what existing changes need to be _removed_ in order to leverage the existing feature. I do agree with @mray in that it's probably just a CSS font-family setting for CJK or RTL languages. But if it's already addressed in Gitea I don't see a need to solve it twice.
fnetX commented 1 year ago
Owner

@vhs Inter is a codeberg-specific font, and a desired patch. Gitea doesn't have this issue, because it's added to Codeberg via this design repo. But our patch is obviously incomplete.

@vhs Inter is a codeberg-specific font, and a desired patch. Gitea doesn't have this issue, because it's added to Codeberg via this design repo. But our patch is obviously incomplete.
mray commented 1 year ago
Collaborator

Maybe it is useful to open a feature request in gitea for getting the option to set a font as part of the theming (I would have expected this to be the case anyway)?

Maybe it is useful to open a feature request in gitea for getting the option to set a font as part of the theming (I would have expected this to be the case anyway)?
n commented 1 year ago
Poster
Collaborator

Font customization is already supported in Gitea.
https://docs.gitea.io/en-us/customizing-gitea/#customizing-fonts

The stylesheet is modifying an unsupported CSS variable (--fonts-override) instead of one of the supported ones, which is why the issue occurs. Gitea overrides --fonts-override to provide fonts for the language, which also overrides Codeberg's stylesheet.

Font customization is already supported in Gitea. https://docs.gitea.io/en-us/customizing-gitea/#customizing-fonts [The stylesheet is modifying](https://codeberg.org/Codeberg/Design/src/branch/main/design-kit/style/brand.css#L3) an unsupported CSS variable (`--fonts-override`) instead of one of the supported ones, which is why the issue occurs. Gitea overrides `--fonts-override` to provide fonts for the language, which also overrides Codeberg's stylesheet.
mray commented 1 year ago
Collaborator

Hard for me to put into perspective without knowing any more details, but:
HOLY FUCK. I just quickly searched for "!important" in the minified CSS that is currently live and found…

38 MATCHES!

As long as this faux-pas is in place I would not be surprised to run into all kind of issues!

Hard for me to put into perspective without knowing any more details, but: HOLY FUCK. I just quickly searched for "!important" in the minified CSS that is currently live and found… **38 MATCHES!** As long as this faux-pas is in place I would not be surprised to run into all kind of issues!
mray commented 1 year ago
Collaborator

OK guys, apart from the !important property clearly being used a non-zero amount of time, I took the liberty and downloaded "/assets/css/index.css".

it is almost a Megabyte of CSS !!!!

maybe my attempts to open it in a text editor fails ebcasue it is allin one line?
Gedit, Builder and Text Editor can't even load it. (I have a decent PC)

What really got me though was that Firefox gives me another number of "!important" properties:

image

More than 1000? At this point everything is credible. I'm a bit shocked about what is happening behind the scenes here.

Do we know what we are doing? Is this normal to you? Does Gitea do all this? Do they know? Are they OK with that? Why? How? This is madness.

Please tell me I'm getting all wrong and this is me overreacting because I got the wrong file or something like that…

OK guys, apart from the !important property clearly being used a non-zero amount of time, I took the liberty and downloaded "/assets/css/index.css". # it is almost a Megabyte of CSS !!!! maybe my attempts to open it in a text editor fails ebcasue it is allin one line? Gedit, Builder and Text Editor can't even load it. (I have a decent PC) What really got me though was that Firefox gives me another number of "!important" properties: ![image](/attachments/cb1ef3c5-f055-42b7-a551-0bb8f387582e) More than 1000? At this point everything is credible. I'm a bit shocked about what is happening behind the scenes here. Do we know what we are doing? Is this normal to you? Does Gitea do all this? Do they know? Are they OK with that? Why? How? This is madness. Please tell me I'm getting all wrong and this is me overreacting because I got the wrong file or something like that…
9.7 KiB
fnetX commented 1 year ago
Owner

cc @momar

cc @momar
Gusted commented 1 year ago
Collaborator

@mray

Try to use a CLI text editor or disable syntax highlighting temporarily on your GUI editor.

What really got me though was that Firefox gives me another number of "!important" properties:

image

More than 1000? At this point everything is credible. I'm a bit shocked about what is happening behind the scenes here.

Is using !important bad then? They are required in situations in order to have a priority over other CSS rules.

Do we know what we are doing?

Trying to fix a issue.

Is this normal to you?

Normal? Nah not really, but there's no other option.

Does Gitea do all this?

Yup the index.css is provided by Gitea as-is.

Do they know? Are they OK with that? Why? How?

Well, they know and they are perfectly happy with it! Because Fomantic will stay(which causes the majority of this CSS). Because the Gitea maintainers cannot come to a agreement so they just stick to what they are using.

This is madness.

Is it madness? Yes. Can you fix it? No, because this require a major rewrite of the gitea frontend, which isn't done within a weekend.

Please tell me I'm getting all wrong and this is me overreacting because I got the wrong file or something like that…

Well, are you currently having a negative experience on codeberg, because of the size of this file or due to the 1212 occurences of !important? If not, then it's likely a overreaction.

PS. simple warning that we're going off-topic here, this has no correlation to the original issue.

@mray Try to use a CLI text editor or disable syntax highlighting temporarily on your GUI editor. > What really got me though was that Firefox gives me another number of "!important" properties: > > ![image](/attachments/cb1ef3c5-f055-42b7-a551-0bb8f387582e) > > More than 1000? At this point everything is credible. I'm a bit shocked about what is happening behind the scenes here. Is using `!important` bad then? They are required in situations in order to have a priority over other CSS rules. > Do we know what we are doing? Trying to fix a issue. > Is this normal to you? Normal? Nah not really, but there's no other option. > Does Gitea do all this? Yup the index.css is provided by Gitea as-is. > Do they know? Are they OK with that? Why? How? Well, they know and they are perfectly happy with it! Because [Fomantic](https://github.com/go-gitea/gitea/issues/18302) will stay(which causes the majority of this CSS). Because the Gitea maintainers cannot come to a agreement so they just stick to what they are using. > This is madness. Is it madness? Yes. Can you fix it? No, because this require a major rewrite of the gitea frontend, which isn't done within a weekend. > Please tell me I'm getting all wrong and this is me overreacting because I got the wrong file or something like that… Well, are you currently having a negative experience on codeberg, because of the size of this file or due to the 1212 occurences of `!important`? If not, then it's likely a overreaction. PS. simple warning that we're going off-topic here, this has no correlation to the original issue.
fnetX commented 1 year ago
Owner

Try to use a CLI text editor

(!) 😂

> Try to use a CLI text editor (!) 😂
fnetX commented 1 year ago
Owner

@Gusted and yes, initially loading Gitea is a little too slow for my taste, especially when on mobile.

Also see https://forgeperf.org/, Gitea doesn't exactly do a green job there. Codeberg is usually at the second worst ranking in terms of size.

Anyway, unrelated to the original issue, but I kinda think that this comment indicates what we need to do.

@Gusted and yes, initially loading Gitea is a little too slow for my taste, especially when on mobile. Also see https://forgeperf.org/, Gitea doesn't exactly do a green job there. Codeberg is usually at the second worst ranking in terms of size. Anyway, unrelated to the original issue, but I kinda think that [this comment](https://codeberg.org/Codeberg/Design/issues/41#issuecomment-417691) indicates what we need to do.
mray commented 11 months ago
Collaborator

Is using !important bad then?

In my book IT IS. And I doubt I'm alone.

Still I think this issue needs to be moved elsewhere. The design decision to use Inter for all suported languages is clear. A question of what fallback to use, or the question of which font to use for unsupported languages may be interesting.

This seems more like a bug in the code. Not in design.

> Is using !important bad then? In my book IT IS. And I doubt I'm alone. Still I think this issue needs to be moved elsewhere. The design decision to use Inter for all suported languages is clear. A question of what fallback to use, or the question of which font to use for unsupported languages may be interesting. This seems more like a bug in the code. Not in design.
mray closed this issue 10 months ago
Sign in to join this conversation.
No Milestone
No Assignees
5 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Codeberg/Design#41
Loading…
There is no content yet.