Improve theme display

[wxiaoguang]

[silverwind]

Need to move variable to :root.

[wxiaoguang]

Need to move variable to :root.

I won't do it, unless you could write clear code to implement it, but I think it is impossible (not feasible in my mind)

[silverwind]

I don't see why a regex like --theme-display-name:\s?(\S+) wouldn't work.

[silverwind]

Easy match: https://regex101.com/r/nJEo79/3

[wxiaoguang]

I don't see why a regex like --theme-display-name:\s?(\S+) wouldn't work.

Just do it.

[silverwind]

Working on new regex.

[silverwind]

Ugh thanks for the merge conflict.

[wxiaoguang]

Ugh thanks for the merge conflict.

It's the same time as answering #30671 (comment) ... the conflict could be simple because I didn't change much, only removed PreferColorSchemes and added some comments

[silverwind]

New version is up. It parses for the last occurence of a variable in a file. If that does not suit you, we install a full CSS parser.

[wxiaoguang]

please show me how this would look in your format. You will see that your method simply does not scale to multiple media features.

I have shown my format in #30671 (comment) , my method does work well, for your new case:

@media (prefers-color-scheme: dark) { :root { --is-dark-theme: true; } }
@media (prefers-color-scheme: light) { :root { --is-dark-theme: false; } }
@media (prefers-color-contrast: no-preference) { :root { --is-contrast-theme: false; } }
@media (prefers-color-contrast: more) { :root { -is-contrast-theme: true; } }
@media (prefers-color-contrast: less) { :root { -is-contrast-theme: true; } }
@media (prefers-reduced-motion: no-preference) { :root { -is-reduced-motion-theme: false; } }
@media (prefers-reduced-motion: reduce) { :root { -is-reduced-motion-theme: true; } }

gitea-theme-meta-info {
  --theme-name: "My Theme";
  --theme-author: "silverwind";
  --theme-url: "https://gitea.com/silverwind/mytheme";
  --theme-media-features: color-schema, color-contrast, reduced-motion;
}

[silverwind]

I have shown my format in #30671 (comment) , my method does work well, for your new case:

Your method would needlessly duplicate stuff like --theme-name and --theme-author into every @media block, so in total you would have each variable 6 times. Such repetition is simply unacceptable. Also I have no idea what you are showing, you just copy-pasted my example.

[wxiaoguang]

I have shown my format in #30671 (comment) , my method does work well, for your new case:

Your method would needlessly duplicate stuff like --theme-name and --theme-author into every @media block, so in total you would have each variable 6 times. Such repetition is simply unacceptable.

No, I don't! I have told you that these --theme-xxxx are from other CSS files imported, your method also has these if they are built from imported CSS files.

My method do not need any extra --theme-author for each media block. See #30671 (comment)

[silverwind]

My method do not need any extra --theme-author for each media block. See #30671 (comment)

What's the difference in yours? It looks exactly the same to me.

[wxiaoguang]

What's the difference in yours?

I have explained above.

It looks exactly the same to me.

Then why not use my method?

[silverwind]

Your only difference is gitea-theme-meta-info and I'm still against it as it's a dead selector and therefor inaccessible to JS getComputedStyle and completely inaccessible to CSS. It does seem we agree on the other parts thought, so this selector is the only contentious part.

[wxiaoguang]

Everything I have explained many times. I am sure my method is the right method, while yours will cause problems.

• gitea-theme-meta-info is not bad, it is only privately defined and used by backend code, and it is VALID CSS.
• gitea-theme-meta-info should never be used directly in frontend (no such use case), using it in frontend will definitely cause problems (uncontrollable overriding, an "auto" theme would inherit incorrect meta info from other imported themes).

I am 100% sure I will never agree with putting them into :root.

I reset the branch to my method. Your work is saved in https://github.com/wxiaoguang/gitea/commits/theme-meta-info-silverwind/

[lunny]

I think the difference between the two solution is not big. But for @wxiaoguang 's solution, all the theme meta info will be under a private namespace gitea-theme-meta-info which is better than putting them in a public :root namespace to avoid mistake usage.

[jolheiser]

Why not some form of parse-able frontmatter contained within a defined CSS comment? (Perhaps I missed some prior discussion. Sorry if so.)

/** gitea-meta
display-name: Dark
**/

and parse it as YAML (or JSON, INI, etc.)

[wxiaoguang]

Why not some form of parse-able frontmatter contained within a defined CSS comment? (Perhaps I missed some prior discussion. Sorry if so.)

Because many frontend compilers remove all the comments.

[jolheiser]

I have no real preference between the two proposed solutions.

I don't love magical CSS being parsed/scraped for metadata. I don't want to "concern stall" this PR into the ground, though, so if no one else has similar concerns I will leave it at that.

[silverwind]

Needs example how to implement a "auto" theme.

[wxiaoguang]

I do not think it needs an example, just copy the "gitea-auto.css"

We can't teach everything here, just like we don't need to explain the --color-xxx one by one.

If you have ideas about how to implement an "auto" theme, feel free to edit the documents.

[wxiaoguang]

Update the document fdfd440

[silverwind]

I still want it in :root. One usage example might be if the theme wants to display it's name in the footer. This is impossible with that non-existant selector:

footer .left-links::after {
  content: var(--theme-name);
}

As CSS gets more advanced, more such use cases will arise and we are blocking us out of them by making the variables unavailable to CSS.

I find it insane that we declare variables that are out of variable scope. It's like a unused variable.

[wxiaoguang]

I still want it in :root. One usage example might be if the theme wants to display it's name in the footer. This is impossible with that non-existant selector:

footer .left-links::after {
  content: var(--theme-name);
}

As CSS gets more advanced, more such use cases will arise and we are blocking us out of them by making the variables unavailable to CSS.

I find it insane that we declare variables that are out of variable scope. It's like a unused variable.

I have also explained the problem above: it is absolutely an abuse. The "display name" should be prepared by backend code and provided by data-theme-display-name=xxxx, but not directly read by JS/CSS.