Use consistent woodpecker color scheme

[xoxys]

Fixes: #1079

What do you think about using a consistent woodpecker color scheme? Right now, the lime color scheme from windicss is used that does not really fit the primary color used for the documentation website. I have used the primary color #4CAF50 from the docs and created a color palette with https://palettte.app/:

JSON source

[
  {
    "paletteName": "New Palette",
    "swatches": [
      {
        "name": "New Swatch",
        "color": "166E30"
      },
      {
        "name": "New Swatch",
        "color": "248438"
      },
      {
        "name": "New Swatch",
        "color": "369943"
      },
      {
        "name": "New Swatch",
        "color": "4CAF50"
      },
      {
        "name": "New Swatch",
        "color": "68C464"
      },
      {
        "name": "New Swatch",
        "color": "8AD97F"
      }
    ]
  }
]

I have added this color scheme to the windicss config and replaced the use of lime in the UI. While woodpecker-300 would be the primary color that is used for the docs, I currently use woodpecke-400 as primary color for the UI to fix some contrast issues.

What do you think? If you would like to stay with the current colors, that's fine for me, I can just use the custom CSS feature in this case.

[pat-s]

I like it! Same adaption for the dark scheme?

(I personally didn't like the lime green that much so far 😅 )

[6543]

I'm a dark-theme user so it doesn't bother me at all 😅

[xoxys]

Same adaption for the dark scheme?

Yes, but there are probably still some parts missing. I didnt want to spend too much time before a decision was made.

[6543]

Well if we already go down this rabbitwhile what about using css-vars so we can have #1079

[xoxys]

Yes, that would help a lot. Happy to look into it.

[6543]

Or do windiCSS hve some theming feature build in?

[xoxys]

Windicss is another thing to reconsider as it is sunsetting https://windicss.org/posts/sunsetting.html. Just in a frozen state, but I don't know if this is a solid base.

[xoxys]

Nevertheless, I think we can implement it that way:

module.exports = {
  theme: {
    colors: {
      red: {
        medium: '#e53e3e',
        dark: '#742a2a'
      },
      blue: {
        medium: '#3182ce',
        dark: '#2a4365'
      },
      'th-primary': 'var(--primary)',
      'th-secondary': 'var(--secondary)'
    }
  }
}

# style.css
:root {
  --primary: theme('colors.red.dark');
  --secondary: theme('colors.red.medium');
}

The theme function is supported by windicss as well https://windicss.org/features/directives.html#theme

Ref: https://css-tricks.com/color-theming-with-css-custom-properties-and-tailwind/#aa-using-the-config-as-a-style-guide

[pat-s]

@xoxys ready?

[xoxys]

Technically this will work, but I'm not happy with this approach. The problem is, it's still very hard for users to create color themes because the custom properties are generic and don't have a contextual meaning. IMO, we should only expose and use meaningful properties. Example:

[root]
--wp-primary
--wp-secondary

--wp-pipeline-pending
--wp-pipeline-ok
--wp-pipeline-running
--wp-pipeline-error

--wp-links

...

Opinions?

[pat-s]

This sounds a bit like code refactoring which could go into a separate PR? I very much like the new color scheme and think it's a valuable change on it's own already.

[xoxys]

I would prefer to do it together as a lot of testing is required and would need to be done twice. I have started the rework to use meaningful css properties now and can hopefully finish it over the weekend. For examples, take a look at https://github.com/woodpecker-ci/woodpecker/blob/97e2eb2b74b3b740181768a00a0f324faeb822ac/web/src/style.css

Some more impressions:

[xoxys]

True, I have slightly adjusted some colors, and at least the Report from the Firefox Accessibility Tool looks good now.

[6543]

hey this pull should take #2052 into account and visa versa

[6543]

e.g. https://egghead.io/blog/write-a-plugin-for-tailwind-css ... https://tailwindcss.com/docs/configuration ...

[xoxys]

I had also mentioned this in #2003 (comment) without a reaction. As there are also some other design questions without a decision yet, I'll not put more time into this PR for now.

[pat-s]

hey this pull should take #2052 into account and visa versa

Can't we do it in small steps? This PR it big enough already and shouldn't do too many things at once.

I really like the current state and think it's good to merge.
The tailwind transition should be a separate PR imo.

[pat-s]

@anbraten There is still an open comment from you - would you mind you resolve it or continue commenting?

[lafriks]

Generally I like everything except do we really need so many colors - 100..900? I know it's "tailwind way" but it makes a mess as there is no really consensus as to where each is used in the end in UI when we should really be using probably 2-3 colors at max

[xoxys]

Generally I like everything except do we really need so many colors - 100..900? I know it's "tailwind way" but it makes a mess as there is no really consensus as to where each is used in the end in UI when we should really be using probably 2-3 colors at max

Don't know how to improve it... all exposed colors are in use to properly work in light and dark mode to provide the required contrasts. Only a minimal subset is exposed in https://github.com/woodpecker-ci/woodpecker/blob/89a250040da9f826a08abb60a2f077217e7495ac/web/src/style.css

For the primary and secondary color, a broader range is defined in https://github.com/woodpecker-ci/woodpecker/blob/89a250040da9f826a08abb60a2f077217e7495ac/web/windi.config.ts but those are not exposed to users.

[xoxys]

@woodpecker-ci/maintainers Please add any objections, otherwise I would like to merge it later.

[xoxys]

Will merge now, happy to add improvements/refactoring in a followup PR if needed.