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

Closed
opened 1 year ago by hw · 39 comments
hw commented 1 year ago
Owner

Maybe we can use a common stylesheet?

Maybe we can use a common stylesheet?

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 1 year ago
Poster
Owner

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

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

Yes. The question is where to put it.

Yes. The question is where to put it.
hw commented 1 year ago
Poster
Owner
maybe here? https://codeberg.org/Codeberg/build-deploy-gitea/src/branch/master/etc/gitea/public
hw commented 1 year ago
Poster
Owner
(served as https://codeberg.org/codeberg.css)

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 1 year ago
Poster
Owner

We preferably might chose one that is part of gitea?

We preferably might chose one that is part of gitea?

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 1 year ago
Poster
Owner

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

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

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 1 year ago
Poster
Owner

I was misled by mention of the network analysis tab

I was misled by mention of the network analysis tab

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 1 year ago
Collaborator

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.

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

@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

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 1 year ago
Poster
Owner

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

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

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 1 year ago
Collaborator

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.

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.

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 1 year ago
Poster
Owner

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?

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 1 year ago
Poster
Owner

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

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

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.

@momar What are your thaughts on this? :)

@momar What are your thaughts on this? :)
Collaborator

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.

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! :)
Collaborator

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.

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?
Collaborator

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

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

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 1 year ago
Poster
Owner

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

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

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

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.
Poster
Owner

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?
Collaborator

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.
n added the
Part: Design Kit
label 4 months ago
n added the
Kind: Web Design
label 4 months ago
Collaborator

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.
mray closed this issue 1 month ago
Sign in to join this conversation.
No Milestone
No Assignees
6 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.