Unify look+feel for join.*, fonts.*, get-it-on.*, codeberg.org #20

hw commented 2020年08月31日 00:37:53 +02:00

Maybe we can use a common stylesheet?

Maybe we can use a common stylesheet?

lhinderberger commented 2020年08月31日 01:07:47 +02:00

Yes, I think that would be especially with codeberg/build-deploy-gitea#17 in mind.

It'll be a bit of a challenge to realize this in a clean way though given our diverse technological landscape and distributed projects. Maybe a npm package in a dedicated repository being included as a dependency when building our various sites might work? That would require that all our frontend projects use npm or yarn for dependency management though, which might or might not be a problem.

Yes, I think that would be especially with codeberg/build-deploy-gitea#17 in mind. It'll be a bit of a challenge to realize this in a clean way though given our diverse technological landscape and distributed projects. Maybe a npm package in a dedicated repository being included as a dependency when building our various sites might work? That would require that all our frontend projects use npm or yarn for dependency management though, which might or might not be a problem.

hw commented 2020年08月31日 18:56:49 +02:00

wouldn't a shared CSS solve something like 90+% of the issues?

wouldn't a shared CSS solve something like 90+% of the issues?

lhinderberger commented 2020年08月31日 18:58:58 +02:00

Yes. The question is where to put it.

Yes. The question is where to put it.

hw commented 2020年08月31日 19:00:13 +02:00

maybe here? https://codeberg.org/Codeberg/build-deploy-gitea/src/branch/master/etc/gitea/public

maybe here? https://codeberg.org/Codeberg/build-deploy-gitea/src/branch/master/etc/gitea/public

hw commented 2020年08月31日 19:00:45 +02:00

(served as https://codeberg.org/codeberg.css)

(served as https://codeberg.org/codeberg.css)

lhinderberger commented 2020年08月31日 19:06:06 +02:00

An alternative might be to provide a CSS file to customize the colors of an existing CSS framework, such as https://purecss.io/.

That customizing CSS could indeed be put on our webroot, with the CSS framework serving both as a common ground and a graceful fallback.

An alternative might be to provide a CSS file to customize the colors of an existing CSS framework, such as https://purecss.io/. That customizing CSS could indeed be put on our webroot, with the CSS framework serving both as a common ground and a graceful fallback.

hw commented 2020年08月31日 20:01:44 +02:00

We preferably might chose one that is part of gitea?

We preferably might chose one that is part of gitea?

lhinderberger commented 2020年08月31日 20:04:27 +02:00

That would be Semantic UI, at first glance when looking at Firefox's Network Analysis tab.

That would be [Semantic UI](https://semantic-ui.com/), at first glance when looking at Firefox's Network Analysis tab.

hw commented 2020年08月31日 20:14:32 +02:00

Fomantic (semantic fork), right? Nothing should get served from external networks?

Fomantic (semantic fork), right? Nothing should get served from external networks?

lhinderberger commented 2020年08月31日 20:16:35 +02:00

Yes, it's Fomantic. (I went by the filename only 🙈)

What's the relation to external networks though in this case?

Yes, it's Fomantic. (I went by the filename only 🙈) What's the relation to external networks though in this case?

hw commented 2020年08月31日 20:18:08 +02:00

I was misled by mention of the network analysis tab

I was misled by mention of the network analysis tab

lhinderberger commented 2020年08月31日 20:31:07 +02:00

Sorry 😉

Well, Fomantic should work well for Codeberg Documentation and regarding Codeberg Fonts I can imagine using Fomantic for fontJAM-gui to make theming easier. 👍

Sorry :wink: Well, Fomantic should work well for Codeberg Documentation and regarding Codeberg Fonts I can imagine using Fomantic for fontJAM-gui to make theming easier. 👍

n commented 2020年09月01日 14:59:41 +02:00

We should also look into implementing such a theme for the blog. The theme README there says it's based on the aboutwilson theme, which is not licensed.

We should also look into implementing such a theme for the blog. The [theme README](https://codeberg.org/Codeberg/blog/src/branch/master/themes/codeberg/README.md) there says it's based on the [aboutwilson theme](https://github.com/getpelican/pelican-themes/tree/master/aboutwilson), which is not licensed.

lhinderberger commented 2020年09月01日 21:35:51 +02:00

That's very bad - is there a license somewhere to be found for aboutwilson?

You might want to open an issue with Codeberg/blog.

That's very bad - is there a license somewhere to be found for aboutwilson? You might want to open an issue with Codeberg/blog.

ashimokawa commented 2020年09月02日 14:18:41 +02:00

@lhinderberger

The original source is here, and it does not seem to have a license :/

https://github.com/getpelican/pelican-themes/tree/master/aboutwilson

@lhinderberger The original source is here, and it does not seem to have a license :/ https://github.com/getpelican/pelican-themes/tree/master/aboutwilson

lhinderberger commented 2020年09月02日 16:18:58 +02:00

Yikes! Would reverting to the default theme and pasting our logo there be an acceptable quick fix? That should be under Pelican's license (AGPLv3), if I'm not mistaken.

Yikes! Would reverting to the default theme and pasting our logo there be an acceptable quick fix? That should be under Pelican's license (AGPLv3), if I'm not mistaken.

hw commented 2020年09月02日 17:05:24 +02:00

What's the best starting point for a clean-slate theme?

What's the best starting point for a clean-slate theme?

lhinderberger commented 2020年09月02日 17:17:39 +02:00

Do you mean for a quick-fix for the blog? There, slightly modifying the default theme found in Pelican's source tree would do I think.

For something more permanent, using a common framework (i.e. Fomantic) would work well, IMHO.

Do you mean for a quick-fix for the blog? There, slightly modifying the default theme found in Pelican's source tree would do I think. For something more permanent, using a common framework (i.e. Fomantic) would work well, IMHO.

mray commented 2020年09月05日 23:53:47 +02:00

As a start it would be reasonable to try adhering to this guideline: https://codeberg.org/Codeberg/Design/wiki/Branding

When colors and fonts are unified that would be a great first step, regardles of technical details on how that is achieved.

As a start it would be reasonable to try adhering to this guideline: https://codeberg.org/Codeberg/Design/wiki/Branding When colors and fonts are unified that would be a great first step, regardles of technical details on how that is achieved.

lhinderberger commented 2020年09月06日 12:11:11 +02:00

Yes, let's modify our existing stylesheets in the short term to adhere to the guidelines. In the long term, we can strive for more technical integration.

We can build new projects with this idea in mind and base them on Fomantic from the beginning. These new projects could then profit from having a pre-existing stylesheet (adopted from the first Fomantic-based project implementing the guidelines or maybe centralized e.g. in the design repo) and widget set so they can be with a unified look+feel and adherence to the design guidelines without additional effort.

Yes, let's modify our existing stylesheets in the short term to adhere to the guidelines. In the long term, we can strive for more technical integration. We can build new projects with this idea in mind and base them on Fomantic from the beginning. These new projects could then profit from having a pre-existing stylesheet (adopted from the first Fomantic-based project implementing the guidelines or maybe centralized e.g. in the design repo) and widget set so they can be with a unified look+feel and adherence to the design guidelines without additional effort.

lhinderberger commented 2020年10月22日 21:53:17 +02:00

Another thaught on this: It is worth mentioning that Fomantic relies on jQuery, which could make it challenging to use it together with e.g. Vue.js. My plan was to use Vue at least for fontJAM's viewer (which will be used for Codeberg Fonts), AFAIK the Gitea devs use Vue.js as well for new developments and there's also Codeberg/Community#288 which looks like it might use Vue.

So, seeing that Fomantic is more or less a legacy framework, I now think that - contrary to what I said earlier - it might not be a good idea to use it for new projects after all.

But I'm well aware that there aren't that many great alternatives either. For fontJAM-viewer I was looking at Inkline, which looks promising but is Vue.js only.

What are your thaughts on this?

Another thaught on this: It is worth mentioning that Fomantic relies on jQuery, which could make it challenging to use it together with e.g. Vue.js. My plan was to use Vue at least for fontJAM's viewer (which will be used for Codeberg Fonts), AFAIK the Gitea devs use Vue.js as well for new developments and there's also Codeberg/Community#288 which looks like it might use Vue. So, seeing that Fomantic is more or less a legacy framework, I now think that - contrary to what I said earlier - it might not be a good idea to use it for new projects after all. But I'm well aware that there aren't that many great alternatives either. For fontJAM-viewer I was looking at [Inkline](https://inkline.io), which looks promising but is Vue.js only. What are your thaughts on this?

hw commented 2020年10月22日 22:10:24 +02:00

Would it be possible to use more or less exactly the same dependencies we already maintain, the ones used by gitea?

Would it be possible to use more or less exactly the same dependencies we already maintain, the ones used by gitea?

lhinderberger commented 2020年10月22日 22:11:36 +02:00

TBH, I wouldn't want to couple additional project to technical decisions that likely reach back to Gogs...

TBH, I wouldn't want to couple additional project to technical decisions that likely reach back to Gogs...

hw commented 2020年10月22日 22:12:32 +02:00

Of course only those that would make sense in an independent setting

Of course only those that would make sense in an independent setting

lhinderberger commented 2020年10月22日 22:37:24 +02:00

Seeing that Gitea seems to be moving towards Vue.js, depending on Vue might be a very good start.

We could put custom components that we make for Codeberg (such as the navbar) into a custom component library that can be used from other Vue.js applications without much complication. For more basic/standardized components (buttons, dropdowns etc.) we may want to use and theme one of the existing component libraries for Vue.js.

I wouldn't recommend depending on Fomantic/Semantic, mainly because of the use of jQuery.

Seeing that Gitea seems to be moving towards Vue.js, depending on Vue might be a very good start. We could put custom components that we make for Codeberg (such as the navbar) into a custom component library that can be used from other Vue.js applications without much complication. For more basic/standardized components (buttons, dropdowns etc.) we may want to use and theme one of the existing component libraries for Vue.js. I wouldn't recommend depending on Fomantic/Semantic, mainly because of the use of jQuery.

lhinderberger commented 2020年10月22日 22:41:49 +02:00

@momar What are your thaughts on this? :)

@momar What are your thaughts on this? :)

momar commented 2020年10月23日 15:07:00 +02:00

That whole issue is basically the last TODO point in https://codeberg.org/Codeberg/Design/src/branch/master/navbar, and in general something I'm really looking forward to. :D

I think it's generally a good idea to ditch Fomantic because of jQuery, but only after Gitea ditches it as well (where have you read that? I could only find #11997, and #9374 where they specifically moved to Fomantic UI, so although the decision is based on Gogs using Semantic UI, Fomantic was specifically chosen by the Gitea project as a compatible successor).
Otherwise, it's really hard to maintain two versions of a design, and even though jQuery is old & not really neccessary anymore, it's not really bad, and only needs to be loaded once for all Codeberg sites.

Regarding frameworks, I'd prefer having Web Components instead of a specific framework - they can be used in Vue.js as well as most other frameworks without any issues, and I think they can even be built using Vue.js, although I don't think we really need it for that.

Generally, the best way will be to have a single stylesheet that provides all the styles for Codeberg in a structured & non-colliding way (so we can also use the navigation bar e.g. in Rocket.Chat), and then some Web Components for common design features.

That whole issue is basically the last TODO point in https://codeberg.org/Codeberg/Design/src/branch/master/navbar, and in general something I'm really looking forward to. :D I think it's generally a good idea to ditch Fomantic because of jQuery, but only after Gitea ditches it as well (where have you read that? I could only find [#11997](https://github.com/go-gitea/gitea/pull/11997), and [#9374](https://github.com/go-gitea/gitea/pull/9374) where they specifically moved to Fomantic UI, so although the decision is based on Gogs using Semantic UI, Fomantic was specifically chosen by the Gitea project as a compatible successor). Otherwise, it's really hard to maintain two versions of a design, and even though jQuery is old & not really neccessary anymore, it's not really bad, and only needs to be loaded once for all Codeberg sites. Regarding frameworks, I'd prefer having [Web Components](https://developer.mozilla.org/en/docs/Web/Web_Components) instead of a specific framework - they can be used in Vue.js as well as most other frameworks without any issues, and I think they can even be built using Vue.js, although I don't think we really need it for that. Generally, the best way will be to have a single stylesheet that provides all the styles for Codeberg in a structured & non-colliding way (so we can also use the navigation bar e.g. in Rocket.Chat), and then some Web Components for common design features.

lhinderberger commented 2020年10月24日 02:58:19 +02:00

where have you read that?

In this thread, Lunny talks about his future ambitions for Gitea's UI and the discussion has ended with a notice that the maintainer team wants to use Vue: https://github.com/go-gitea/gitea/issues/8174

Otherwise, it’s really hard to maintain two versions of a design

Agreed. Let's instead focus on maximizing compatibility and minimizing coupling.

If you ask me, we shouldn't go down the road of building our own custom, fully-featured Codeberg UI-framework with buttons, menus etc. - that would consume way too much time and resources, just to avoid the minor inconsistencies that occur when theming different off-the-shelf frameworks to look similar to each other.

Every project should be able to use the UI framework that makes most sense for them, while our few custom components (for example the navbar, maybe user "cards" etc.) can be reused but will play nicely with the existing software. To ensure a Codeberg-y look-and-feel, each project simply writes a theming stylesheet for their UI framework.

That way, Gitea can continue to use a themed Fomantic for the time being, Fonts can use a themed Inkline, RocketChat can use a themed React (from a quick glance at their package.json) etc.

Web Components

Interesting, I didn't know about these yet. Thanks for the link! :)

> where have you read that? In this thread, Lunny talks about his future ambitions for Gitea's UI and the discussion has ended with a notice that the maintainer team wants to use Vue: https://github.com/go-gitea/gitea/issues/8174 > Otherwise, it’s really hard to maintain two versions of a design Agreed. Let's instead focus on maximizing compatibility and minimizing coupling. If you ask me, we shouldn't go down the road of building our own custom, fully-featured Codeberg UI-framework with buttons, menus etc. - that would consume way too much time and resources, just to avoid the minor inconsistencies that occur when theming different off-the-shelf frameworks to look similar to each other. Every project should be able to use the UI framework that makes most sense for them, while our few custom components (for example the navbar, maybe user "cards" etc.) can be reused but will play nicely with the existing software. To ensure a Codeberg-y look-and-feel, each project simply writes a theming stylesheet for their UI framework. That way, Gitea can continue to use a themed Fomantic for the time being, Fonts can use a themed Inkline, RocketChat can use a themed React (from a quick glance at their `package.json`) etc. > Web Components Interesting, I didn't know about these yet. Thanks for the link! :)

momar commented 2020年10月24日 14:26:40 +02:00

So, we probably should be looking for a tiny CSS framework that's configurable using CSS variables and can be scoped to e.g. a codeberg-design class, together with a reset stylesheet, all hosted from a static domain (e.g. design.codeberg.org/style.css).

Then, people can decide if they want to build a codeberg-like site from scratch, or if they want to only use our components without touching the rest of the page at all, using the same stylesheet.

If we want an easy-to-use framework for our components, Vue 3 should be a good choice, especially as it also supports Web Components/Custom Elements (see https://v3.vuejs.org/guide/introduction.html#relation-to-custom-elements), should we want to switch to those at some point.

Would that be a good way to go about this? If someone knows a good tiny CSS framework that's using variables, that would be a great start.

So, we probably should be looking for a tiny CSS framework that's configurable using CSS variables and can be scoped to e.g. a `codeberg-design` class, together with a reset stylesheet, all hosted from a static domain (e.g. design.codeberg.org/style.css). Then, people can decide if they want to build a codeberg-like site from scratch, or if they want to only use our components without touching the rest of the page at all, using the same stylesheet. If we want an easy-to-use framework for our components, Vue 3 should be a good choice, especially as it also supports Web Components/Custom Elements (see https://v3.vuejs.org/guide/introduction.html#relation-to-custom-elements), should we want to switch to those at some point. Would that be a good way to go about this? If someone knows a good tiny CSS framework that's using variables, that would be a great start.

lhinderberger commented 2020年10月24日 14:38:40 +02:00

Please explain what the stylesheet would do - would it style our custom components or would it attempt to style the entire page?

Please explain what the stylesheet would do - would it style our custom components or would it attempt to style the entire page?

momar commented 2020年10月24日 14:49:16 +02:00

That would depend on the use case, it'd style everything with a parent with class="codeberg-design", and if that's the body element it could be used for the whole page. That's currently the most flexible approach I can think of.

That would depend on the use case, it'd style everything with a parent with `class="codeberg-design"`, and if that's the body element it could be used for the whole page. That's currently the most flexible approach I can think of.

momar commented 2020年10月24日 19:59:33 +02:00

Halfmoon would be a possibility for a relatively lightweight (~ 2 KB w/ gzip) but fully featured CSS framework that uses CSS variables.

[Halfmoon](https://www.gethalfmoon.com/) would be a possibility for a relatively lightweight (~ 2 KB w/ gzip) but fully featured CSS framework that uses CSS variables.

momar commented 2020年11月19日 11:00:06 +01:00

Have a look at https://codeberg.org/Codeberg/Design/src/branch/master/toolkit - it basically works that way, but we'll need some place to host it (like design.codeberg.org in the example)

Have a look at https://codeberg.org/Codeberg/Design/src/branch/master/toolkit - it basically works that way, but we'll need some place to host it (like design.codeberg.org in the example)

hw commented 2020年11月19日 14:59:42 +01:00

nice! Would you like to deploy some of these bits already?

nice! Would you like to deploy some of these bits already?

momar commented 2020年11月20日 09:34:11 +01:00

Uhm, yes, if they're working 🙈

There are still some issues with the scoping (mainly as Halfmoon depends using :root, html and body), and we'll need some components to use this on - I'm working on porting the navbar there and will also incorporate some solution to the whole notifications problem.

Uhm, yes, if they're working 🙈 There are still some issues with the scoping (mainly as Halfmoon depends using :root, html and body), and we'll need some components to use this on - I'm working on porting the navbar there and will also incorporate some solution to the whole notifications problem.

momar commented 2021年02月18日 00:23:25 +01:00

Huge progress update: scoping seems to be working now (albeit I haven't tested it much), and you can have a look at https://codeberg-design.momar.de to see what the Halfmoon sample page looks like with the Codeberg styles applied.

This means that the homepages for pages, fonts, get-it-on, blog, docs, and so on could theoretically be shifted over to Halfmoon CSS.

What is missing for this issue are the PRs for those services (it would be great if someone else could help here), as well as (most importantly) that design.codeberg.org is working and can serve the resources - I'll try to set that up on Codeberg-Test in the next couple of days.

The custom components themselves just got their own issue at #30 so they're separated from this issue.

Huge progress update: scoping seems to be working now (albeit I haven't tested it much), and you can have a look at https://codeberg-design.momar.de to see what the Halfmoon sample page looks like with the Codeberg styles applied. This means that the homepages for pages, fonts, get-it-on, blog, docs, and so on could theoretically be shifted over to Halfmoon CSS. What is missing for this issue are the PRs for those services (it would be great if someone else could help here), as well as (most importantly) that `design.codeberg.org` is working and can serve the resources - I'll try to set that up on Codeberg-Test in the next couple of days. The custom components themselves just got their own issue at #30 so they're separated from this issue.

hw commented 2021年02月19日 22:16:36 +01:00

design.codeberg.org

What would be hosted here? Is this basically intended as extension to fonts.codeberg.org?

> design.codeberg.org What would be hosted here? Is this basically intended as extension to fonts.codeberg.org?

momar commented 2021年02月20日 15:14:47 +01:00

Yeah, fonts ist only for fonts, while design would be for stylesheets, logo, components, etc. - basically anything design-related that's shared between different Codeberg services.

For fonts it would be awesome to provide a CDN like Google Fonts (maybe even directly replacing it) at some point, while design would only host resources directly related to Codeberg.

Yeah, fonts ist only for fonts, while design would be for stylesheets, logo, components, etc. - basically anything design-related that's shared between different Codeberg services. For fonts it would be awesome to provide a CDN like Google Fonts (maybe even directly replacing it) at some point, while design would only host resources directly related to Codeberg.

mray commented 2021年10月25日 00:33:50 +02:00

I feel this issue has become more of an attempt to optimize sharing resources.
As I noted, "Unify look+feel" happens when making use of the brand guideline https://codeberg.org/Codeberg/Design/wiki/Branding , irrespective of how that is achieved technically. In that regard this issue is solved.

Any effort to work on technical solutions should imho open a separate issue (not as "design" issue).

From a design perspective this issue is either not really actionable or clearly has timed out. Closing.

I feel this issue has become more of an attempt to optimize sharing resources. As I noted, "Unify look+feel" happens when making use of the brand guideline https://codeberg.org/Codeberg/Design/wiki/Branding , irrespective of how that is achieved technically. In that regard this issue is solved. Any effort to work on **technical solutions** should imho open a separate issue (not as "design" issue). From a design perspective this issue is either not really actionable or clearly has timed out. Closing.