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.

[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.

.

[silverwind]

I guess I won't block any more because the changes are needed for later work, but I won't approve it either until it's changed to use :root.

[silverwind]

Another we should just put put it into a "legal comment" block at the start, arguably better then a CSS block that never matches anything.

/*!
name: My Theme
url: https://gitea.com/my/theme
*/

Or even simpler:

/*! My Theme - https://gitea.com/my/theme */

[jolheiser]

Another we should just put put it into a "legal comment" block at the start, arguably better then a CSS block that never matches anything.

/*!
name: My Theme
url: https://gitea.com/my/theme
*/

Or even simpler:

/*! My Theme - https://gitea.com/my/theme */

I agree
But #30671 (comment)

[silverwind]

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.

By putting a ! first character into a comment, it becomes a legal comment which by default many minifiers retain in the output.

[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.

By putting a ! first character into a comment, it becomes a legal comment which by default many minifiers retain in the output.

Then it sill needs some "tag" to help the locate the comment block.

Does this look good to you? Or other ideas?

/*!gitea-theme-meta-info
display-name: My Theme
*/