Add navbar personalization

[Zinkue]

closes: #53443

Bring back Airflow 2 side/navbar personalization based on a user provided color (theme configuration property)

Screenshoots

Input

Output

Input

Output

Input

Output

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[Zinkue]

It generates a custom color palette where:

• Luminosity comes from a list, e.g. output luminosity does not depend of input color
• Chroma is generated from to input color's chroma
• Hue is constant based in input color

Some doubts I have:

1. I used culori for color transformation. I can do the same with colorjs.io On which criteria you select one or another (Github stars, npm downloads, etc.)?
2. From UX (see yellow output in PR description above) does the output theme looks fine? I tried taking into account also imputed luminosity but maybe I am overthinking

For the future, when #55789 is merged we can add support for predefined themes and custom themes

[jason810496]

Nice! Thanks for the PR! LGMT for the API change.

The static check for spelling still need fix ( the CI failure will be handled in #56869, so no need to fix anything ).
We just need to add the missing words in docs/spelling_wordlist.txt. Thanks!

[pierrejeambrun]

Nice, thanks for the PR!

I think the customization should be a whole theme object that 'chakra UI` understands. Either a css file or an object definition, so we can go beyond just 'navbar' or one palette customization. (customizing border radius, or anything else in the app, for specific components too.)

[Zinkue]

Nice! Thanks for the PR! LGMT for the API change.

The static check for spelling still need fix ( the CI failure will be handled in #56869, so no need to fix anything ). We just need to add the missing words in docs/spelling_wordlist.txt. Thanks!

Sorry, do I need to do something from my end when you said "add the missing words in docs/spelling_wordlist.txt"?

[Zinkue]

Nice, thanks for the PR!

I think the customization should be a whole theme object that 'chakra UI` understands. Either a css file or an object definition, so we can go beyond just 'navbar' or one palette customization. (customizing border radius, or anything else in the app, for specific components too.)

I thought about two possible values for theme based on your comment:

1. { "type": "color", "value": "#123456"/existing color in the theme }
2. { "type": "file", "value": "path/to/theme.json" }

Agree for providing to the end-users full personalization of the UI but I think for the majority (I include myself here) changing only the color will be enough (DEV green, TST yellow, PRD red)

[jason810496]

Sorry, do I need to do something from my end when you said "add the missing words in docs/spelling_wordlist.txt"?

Yes, based on the error traceback in CI, we need to add the word grayscale in docs/spelling_wordlist.txt, thanks!

------------------------------ Error 2 ------------------------------
airflow-core/docs/howto/customize-ui.rst:78: (grayscale) will generate the same color palette (grayscale).
File path: /opt/airflow/airflow-core/docs/airflow-core/docs/howto/customize-ui.rst
Incorrect Spelling: 'grayscale'
Line with Error: ' will generate the same color palette (grayscale).'
====================================================================================================

[bbovenzi]

@odaneau-astro Would love your thoughts on this?

For me, I was thinking about allowing a larger theme json config element.

Also I am skeptical about us maintaining how color palettes are generated. I think that should be the domain of the person customizing the theme. We can still point them to useful tools. It also would be a slow development cycle to need to refresh the whole UI when you realize your base color wasn't just right.

[odaneau-astro]

I like the simplicity of this solution. The implementation expands on my original idea in https://playcode.io/2464307 and fixes obvious flaws in my POC.

I agree that we do want to expand customization options to other attributes, but we need to brainstorm a little more on what that would include. If we used a JSON env var with a single entry for navbar color for now, it would allow us to expand on it later.

Personally, I would not offer users the ability to customize things component-by-component. It would add a maintenance burden for end users when we add new components in the future.

I would also limit configuration attributes to essentials to avoid "config hell". Starting with accessibility requirements and corporate branding configs makes sense. Here are some that are top of mind:

• border width
• border radius
• background color
• default padding
• default margin
• header font family
• body font family
• default font size
• line height

Keep in mind that standardizing our existing codebase to use these will take time and effort.

FYI, I also have this draft PR in the works to centralize component semantic tokens and make them rely more on brand colors: #56347

[odaneau-astro]

@odaneau-astro Would love your thoughts on this?

For me, I was thinking about allowing a larger theme json config element.

Also I am skeptical about us maintaining how color palettes are generated. I think that should be the domain of the person customizing the theme. We can still point them to useful tools. It also would be a slow development cycle to need to refresh the whole UI when you realize your base color wasn't just right.

I don't have a strong opinion on maintaining the palette generation logic ourselves.
Users are already familiar with single hex values from Airflow 2 and it simplifies things for end users.
But at the same time, there's no escape hatch if the colors don't turn out to be readable.

We could very well use @Zinkue's generatePalette.ts logic in the playground (#55789) and output the hex color list for users to copy in their env var / airflow config. Then, only allow the long list of hex codes for 50-950 values in the JSON config.

[Zinkue]

Many thanks for all your feedback!

This how I understood the flow for changing the navbar color should be:

1. (Optional) User goes to playground and provides a color so we generate a color palette
2. User adds a color palette to the JSON config

From my end I will break this PR in two work items:

1. Add my generatePalette.ts logic into @odaneau-astro's playground proposal
2. Rework the theme config property/env var to be a JSON value and, for the time being, accept the navbar color

If there will be no more comments, I will close this PR in favor of above's work items

[pierrejeambrun]

Thanks for the follow up @Zinkue.

Sounds like a good plan. Indeed it will be easier to move forward with two different PRs for those two work items.

[Zinkue]

closes: #53443

Bring back Airflow 2 side/navbar personalization based on a user provided color (theme configuration property)

Screenshoots

Input

Output

Input

Output

Input

Output

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[Zinkue]

It generates a custom color palette where:

• Luminosity comes from a list, e.g. output luminosity does not depend of input color
• Chroma is generated from to input color's chroma
• Hue is constant based in input color

Some doubts I have:

1. I used culori for color transformation. I can do the same with colorjs.io On which criteria you select one or another (Github stars, npm downloads, etc.)?
2. From UX (see yellow output in PR description above) does the output theme looks fine? I tried taking into account also imputed luminosity but maybe I am overthinking

For the future, when #55789 is merged we can add support for predefined themes and custom themes

[jason810496]

Nice! Thanks for the PR! LGMT for the API change.

The static check for spelling still need fix ( the CI failure will be handled in #56869, so no need to fix anything ).
We just need to add the missing words in docs/spelling_wordlist.txt. Thanks!

[pierrejeambrun]

Nice, thanks for the PR!

I think the customization should be a whole theme object that 'chakra UI` understands. Either a css file or an object definition, so we can go beyond just 'navbar' or one palette customization. (customizing border radius, or anything else in the app, for specific components too.)

[Zinkue]

Nice! Thanks for the PR! LGMT for the API change.

The static check for spelling still need fix ( the CI failure will be handled in #56869, so no need to fix anything ). We just need to add the missing words in docs/spelling_wordlist.txt. Thanks!

Sorry, do I need to do something from my end when you said "add the missing words in docs/spelling_wordlist.txt"?

[Zinkue]

Nice, thanks for the PR!

I think the customization should be a whole theme object that 'chakra UI` understands. Either a css file or an object definition, so we can go beyond just 'navbar' or one palette customization. (customizing border radius, or anything else in the app, for specific components too.)

I thought about two possible values for theme based on your comment:

1. { "type": "color", "value": "#123456"/existing color in the theme }
2. { "type": "file", "value": "path/to/theme.json" }

Agree for providing to the end-users full personalization of the UI but I think for the majority (I include myself here) changing only the color will be enough (DEV green, TST yellow, PRD red)

[jason810496]

Sorry, do I need to do something from my end when you said "add the missing words in docs/spelling_wordlist.txt"?

Yes, based on the error traceback in CI, we need to add the word grayscale in docs/spelling_wordlist.txt, thanks!

------------------------------ Error 2 ------------------------------
airflow-core/docs/howto/customize-ui.rst:78: (grayscale) will generate the same color palette (grayscale).
File path: /opt/airflow/airflow-core/docs/airflow-core/docs/howto/customize-ui.rst
Incorrect Spelling: 'grayscale'
Line with Error: ' will generate the same color palette (grayscale).'
====================================================================================================

[bbovenzi]

@odaneau-astro Would love your thoughts on this?

For me, I was thinking about allowing a larger theme json config element.

Also I am skeptical about us maintaining how color palettes are generated. I think that should be the domain of the person customizing the theme. We can still point them to useful tools. It also would be a slow development cycle to need to refresh the whole UI when you realize your base color wasn't just right.

[odaneau-astro]

I like the simplicity of this solution. The implementation expands on my original idea in https://playcode.io/2464307 and fixes obvious flaws in my POC.

I agree that we do want to expand customization options to other attributes, but we need to brainstorm a little more on what that would include. If we used a JSON env var with a single entry for navbar color for now, it would allow us to expand on it later.

Personally, I would not offer users the ability to customize things component-by-component. It would add a maintenance burden for end users when we add new components in the future.

I would also limit configuration attributes to essentials to avoid "config hell". Starting with accessibility requirements and corporate branding configs makes sense. Here are some that are top of mind:

• border width
• border radius
• background color
• default padding
• default margin
• header font family
• body font family
• default font size
• line height

Keep in mind that standardizing our existing codebase to use these will take time and effort.

FYI, I also have this draft PR in the works to centralize component semantic tokens and make them rely more on brand colors: #56347

[odaneau-astro]

@odaneau-astro Would love your thoughts on this?

For me, I was thinking about allowing a larger theme json config element.

Also I am skeptical about us maintaining how color palettes are generated. I think that should be the domain of the person customizing the theme. We can still point them to useful tools. It also would be a slow development cycle to need to refresh the whole UI when you realize your base color wasn't just right.

I don't have a strong opinion on maintaining the palette generation logic ourselves.
Users are already familiar with single hex values from Airflow 2 and it simplifies things for end users.
But at the same time, there's no escape hatch if the colors don't turn out to be readable.

We could very well use @Zinkue's generatePalette.ts logic in the playground (#55789) and output the hex color list for users to copy in their env var / airflow config. Then, only allow the long list of hex codes for 50-950 values in the JSON config.

[Zinkue]

Many thanks for all your feedback!

This how I understood the flow for changing the navbar color should be:

1. (Optional) User goes to playground and provides a color so we generate a color palette
2. User adds a color palette to the JSON config

From my end I will break this PR in two work items:

1. Add my generatePalette.ts logic into @odaneau-astro's playground proposal
2. Rework the theme config property/env var to be a JSON value and, for the time being, accept the navbar color

If there will be no more comments, I will close this PR in favor of above's work items

[pierrejeambrun]

Thanks for the follow up @Zinkue.

Sounds like a good plan. Indeed it will be easier to move forward with two different PRs for those two work items.

[Zinkue]

closes: #53443

Bring back Airflow 2 side/navbar personalization based on a user provided color (theme configuration property)

Screenshoots

Input

Output

Input

Output

Input

Output

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[Zinkue]

It generates a custom color palette where:

• Luminosity comes from a list, e.g. output luminosity does not depend of input color
• Chroma is generated from to input color's chroma
• Hue is constant based in input color

Some doubts I have:

1. I used culori for color transformation. I can do the same with colorjs.io On which criteria you select one or another (Github stars, npm downloads, etc.)?
2. From UX (see yellow output in PR description above) does the output theme looks fine? I tried taking into account also imputed luminosity but maybe I am overthinking

For the future, when #55789 is merged we can add support for predefined themes and custom themes

[jason810496]

Nice! Thanks for the PR! LGMT for the API change.

The static check for spelling still need fix ( the CI failure will be handled in #56869, so no need to fix anything ).
We just need to add the missing words in docs/spelling_wordlist.txt. Thanks!

[pierrejeambrun]

Nice, thanks for the PR!

I think the customization should be a whole theme object that 'chakra UI` understands. Either a css file or an object definition, so we can go beyond just 'navbar' or one palette customization. (customizing border radius, or anything else in the app, for specific components too.)

[Zinkue]

Nice! Thanks for the PR! LGMT for the API change.

The static check for spelling still need fix ( the CI failure will be handled in #56869, so no need to fix anything ). We just need to add the missing words in docs/spelling_wordlist.txt. Thanks!

Sorry, do I need to do something from my end when you said "add the missing words in docs/spelling_wordlist.txt"?

[Zinkue]

Nice, thanks for the PR!

I think the customization should be a whole theme object that 'chakra UI` understands. Either a css file or an object definition, so we can go beyond just 'navbar' or one palette customization. (customizing border radius, or anything else in the app, for specific components too.)

I thought about two possible values for theme based on your comment:

1. { "type": "color", "value": "#123456"/existing color in the theme }
2. { "type": "file", "value": "path/to/theme.json" }

Agree for providing to the end-users full personalization of the UI but I think for the majority (I include myself here) changing only the color will be enough (DEV green, TST yellow, PRD red)

[jason810496]

Sorry, do I need to do something from my end when you said "add the missing words in docs/spelling_wordlist.txt"?

Yes, based on the error traceback in CI, we need to add the word grayscale in docs/spelling_wordlist.txt, thanks!

------------------------------ Error 2 ------------------------------
airflow-core/docs/howto/customize-ui.rst:78: (grayscale) will generate the same color palette (grayscale).
File path: /opt/airflow/airflow-core/docs/airflow-core/docs/howto/customize-ui.rst
Incorrect Spelling: 'grayscale'
Line with Error: ' will generate the same color palette (grayscale).'
====================================================================================================

[bbovenzi]

@odaneau-astro Would love your thoughts on this?

For me, I was thinking about allowing a larger theme json config element.

Also I am skeptical about us maintaining how color palettes are generated. I think that should be the domain of the person customizing the theme. We can still point them to useful tools. It also would be a slow development cycle to need to refresh the whole UI when you realize your base color wasn't just right.

[odaneau-astro]

I like the simplicity of this solution. The implementation expands on my original idea in https://playcode.io/2464307 and fixes obvious flaws in my POC.

I agree that we do want to expand customization options to other attributes, but we need to brainstorm a little more on what that would include. If we used a JSON env var with a single entry for navbar color for now, it would allow us to expand on it later.

Personally, I would not offer users the ability to customize things component-by-component. It would add a maintenance burden for end users when we add new components in the future.

I would also limit configuration attributes to essentials to avoid "config hell". Starting with accessibility requirements and corporate branding configs makes sense. Here are some that are top of mind:

• border width
• border radius
• background color
• default padding
• default margin
• header font family
• body font family
• default font size
• line height

Keep in mind that standardizing our existing codebase to use these will take time and effort.

FYI, I also have this draft PR in the works to centralize component semantic tokens and make them rely more on brand colors: #56347

[odaneau-astro]

@odaneau-astro Would love your thoughts on this?

For me, I was thinking about allowing a larger theme json config element.

Also I am skeptical about us maintaining how color palettes are generated. I think that should be the domain of the person customizing the theme. We can still point them to useful tools. It also would be a slow development cycle to need to refresh the whole UI when you realize your base color wasn't just right.

I don't have a strong opinion on maintaining the palette generation logic ourselves.
Users are already familiar with single hex values from Airflow 2 and it simplifies things for end users.
But at the same time, there's no escape hatch if the colors don't turn out to be readable.

We could very well use @Zinkue's generatePalette.ts logic in the playground (#55789) and output the hex color list for users to copy in their env var / airflow config. Then, only allow the long list of hex codes for 50-950 values in the JSON config.

[Zinkue]

Many thanks for all your feedback!

This how I understood the flow for changing the navbar color should be:

1. (Optional) User goes to playground and provides a color so we generate a color palette
2. User adds a color palette to the JSON config

From my end I will break this PR in two work items:

1. Add my generatePalette.ts logic into @odaneau-astro's playground proposal
2. Rework the theme config property/env var to be a JSON value and, for the time being, accept the navbar color

If there will be no more comments, I will close this PR in favor of above's work items

[pierrejeambrun]

Thanks for the follow up @Zinkue.

Sounds like a good plan. Indeed it will be easier to move forward with two different PRs for those two work items.

[Zinkue]

closes: #53443

Bring back Airflow 2 side/navbar personalization based on a user provided color (theme configuration property)

Screenshoots

Input

Output

Input

Output

Input

Output

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[Zinkue]

It generates a custom color palette where:

• Luminosity comes from a list, e.g. output luminosity does not depend of input color
• Chroma is generated from to input color's chroma
• Hue is constant based in input color

Some doubts I have:

1. I used culori for color transformation. I can do the same with colorjs.io On which criteria you select one or another (Github stars, npm downloads, etc.)?
2. From UX (see yellow output in PR description above) does the output theme looks fine? I tried taking into account also imputed luminosity but maybe I am overthinking

For the future, when #55789 is merged we can add support for predefined themes and custom themes

[jason810496]

Nice! Thanks for the PR! LGMT for the API change.

The static check for spelling still need fix ( the CI failure will be handled in #56869, so no need to fix anything ).
We just need to add the missing words in docs/spelling_wordlist.txt. Thanks!

[pierrejeambrun]

Nice, thanks for the PR!

I think the customization should be a whole theme object that 'chakra UI` understands. Either a css file or an object definition, so we can go beyond just 'navbar' or one palette customization. (customizing border radius, or anything else in the app, for specific components too.)

[Zinkue]

Nice! Thanks for the PR! LGMT for the API change.

The static check for spelling still need fix ( the CI failure will be handled in #56869, so no need to fix anything ). We just need to add the missing words in docs/spelling_wordlist.txt. Thanks!

Sorry, do I need to do something from my end when you said "add the missing words in docs/spelling_wordlist.txt"?

[Zinkue]

Nice, thanks for the PR!

I think the customization should be a whole theme object that 'chakra UI` understands. Either a css file or an object definition, so we can go beyond just 'navbar' or one palette customization. (customizing border radius, or anything else in the app, for specific components too.)

I thought about two possible values for theme based on your comment:

1. { "type": "color", "value": "#123456"/existing color in the theme }
2. { "type": "file", "value": "path/to/theme.json" }

Agree for providing to the end-users full personalization of the UI but I think for the majority (I include myself here) changing only the color will be enough (DEV green, TST yellow, PRD red)

[jason810496]

Sorry, do I need to do something from my end when you said "add the missing words in docs/spelling_wordlist.txt"?

Yes, based on the error traceback in CI, we need to add the word grayscale in docs/spelling_wordlist.txt, thanks!

------------------------------ Error 2 ------------------------------
airflow-core/docs/howto/customize-ui.rst:78: (grayscale) will generate the same color palette (grayscale).
File path: /opt/airflow/airflow-core/docs/airflow-core/docs/howto/customize-ui.rst
Incorrect Spelling: 'grayscale'
Line with Error: ' will generate the same color palette (grayscale).'
====================================================================================================

[bbovenzi]

@odaneau-astro Would love your thoughts on this?

For me, I was thinking about allowing a larger theme json config element.

Also I am skeptical about us maintaining how color palettes are generated. I think that should be the domain of the person customizing the theme. We can still point them to useful tools. It also would be a slow development cycle to need to refresh the whole UI when you realize your base color wasn't just right.

[odaneau-astro]

I like the simplicity of this solution. The implementation expands on my original idea in https://playcode.io/2464307 and fixes obvious flaws in my POC.

I agree that we do want to expand customization options to other attributes, but we need to brainstorm a little more on what that would include. If we used a JSON env var with a single entry for navbar color for now, it would allow us to expand on it later.

Personally, I would not offer users the ability to customize things component-by-component. It would add a maintenance burden for end users when we add new components in the future.

I would also limit configuration attributes to essentials to avoid "config hell". Starting with accessibility requirements and corporate branding configs makes sense. Here are some that are top of mind:

• border width
• border radius
• background color
• default padding
• default margin
• header font family
• body font family
• default font size
• line height

Keep in mind that standardizing our existing codebase to use these will take time and effort.

FYI, I also have this draft PR in the works to centralize component semantic tokens and make them rely more on brand colors: #56347

[odaneau-astro]

@odaneau-astro Would love your thoughts on this?

For me, I was thinking about allowing a larger theme json config element.

Also I am skeptical about us maintaining how color palettes are generated. I think that should be the domain of the person customizing the theme. We can still point them to useful tools. It also would be a slow development cycle to need to refresh the whole UI when you realize your base color wasn't just right.

I don't have a strong opinion on maintaining the palette generation logic ourselves.
Users are already familiar with single hex values from Airflow 2 and it simplifies things for end users.
But at the same time, there's no escape hatch if the colors don't turn out to be readable.

We could very well use @Zinkue's generatePalette.ts logic in the playground (#55789) and output the hex color list for users to copy in their env var / airflow config. Then, only allow the long list of hex codes for 50-950 values in the JSON config.

[Zinkue]

Many thanks for all your feedback!

This how I understood the flow for changing the navbar color should be:

1. (Optional) User goes to playground and provides a color so we generate a color palette
2. User adds a color palette to the JSON config

From my end I will break this PR in two work items:

1. Add my generatePalette.ts logic into @odaneau-astro's playground proposal
2. Rework the theme config property/env var to be a JSON value and, for the time being, accept the navbar color

If there will be no more comments, I will close this PR in favor of above's work items

[pierrejeambrun]

Thanks for the follow up @Zinkue.

Sounds like a good plan. Indeed it will be easier to move forward with two different PRs for those two work items.

[Zinkue]

closes: #53443

Bring back Airflow 2 side/navbar personalization based on a user provided color (theme configuration property)

Screenshoots

Input

Output

Input

Output

Input

Output

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[Zinkue]

It generates a custom color palette where:

• Luminosity comes from a list, e.g. output luminosity does not depend of input color
• Chroma is generated from to input color's chroma
• Hue is constant based in input color

Some doubts I have:

1. I used culori for color transformation. I can do the same with colorjs.io On which criteria you select one or another (Github stars, npm downloads, etc.)?
2. From UX (see yellow output in PR description above) does the output theme looks fine? I tried taking into account also imputed luminosity but maybe I am overthinking

For the future, when #55789 is merged we can add support for predefined themes and custom themes

[jason810496]

Nice! Thanks for the PR! LGMT for the API change.

The static check for spelling still need fix ( the CI failure will be handled in #56869, so no need to fix anything ).
We just need to add the missing words in docs/spelling_wordlist.txt. Thanks!

[pierrejeambrun]

Nice, thanks for the PR!

I think the customization should be a whole theme object that 'chakra UI` understands. Either a css file or an object definition, so we can go beyond just 'navbar' or one palette customization. (customizing border radius, or anything else in the app, for specific components too.)

[Zinkue]

Nice! Thanks for the PR! LGMT for the API change.

The static check for spelling still need fix ( the CI failure will be handled in #56869, so no need to fix anything ). We just need to add the missing words in docs/spelling_wordlist.txt. Thanks!

Sorry, do I need to do something from my end when you said "add the missing words in docs/spelling_wordlist.txt"?

[Zinkue]

Nice, thanks for the PR!

I think the customization should be a whole theme object that 'chakra UI` understands. Either a css file or an object definition, so we can go beyond just 'navbar' or one palette customization. (customizing border radius, or anything else in the app, for specific components too.)

I thought about two possible values for theme based on your comment:

1. { "type": "color", "value": "#123456"/existing color in the theme }
2. { "type": "file", "value": "path/to/theme.json" }

Agree for providing to the end-users full personalization of the UI but I think for the majority (I include myself here) changing only the color will be enough (DEV green, TST yellow, PRD red)

[jason810496]

Sorry, do I need to do something from my end when you said "add the missing words in docs/spelling_wordlist.txt"?

Yes, based on the error traceback in CI, we need to add the word grayscale in docs/spelling_wordlist.txt, thanks!

------------------------------ Error 2 ------------------------------
airflow-core/docs/howto/customize-ui.rst:78: (grayscale) will generate the same color palette (grayscale).
File path: /opt/airflow/airflow-core/docs/airflow-core/docs/howto/customize-ui.rst
Incorrect Spelling: 'grayscale'
Line with Error: ' will generate the same color palette (grayscale).'
====================================================================================================

[bbovenzi]

@odaneau-astro Would love your thoughts on this?

For me, I was thinking about allowing a larger theme json config element.

Also I am skeptical about us maintaining how color palettes are generated. I think that should be the domain of the person customizing the theme. We can still point them to useful tools. It also would be a slow development cycle to need to refresh the whole UI when you realize your base color wasn't just right.

[odaneau-astro]

I like the simplicity of this solution. The implementation expands on my original idea in https://playcode.io/2464307 and fixes obvious flaws in my POC.

I agree that we do want to expand customization options to other attributes, but we need to brainstorm a little more on what that would include. If we used a JSON env var with a single entry for navbar color for now, it would allow us to expand on it later.

Personally, I would not offer users the ability to customize things component-by-component. It would add a maintenance burden for end users when we add new components in the future.

I would also limit configuration attributes to essentials to avoid "config hell". Starting with accessibility requirements and corporate branding configs makes sense. Here are some that are top of mind:

• border width
• border radius
• background color
• default padding
• default margin
• header font family
• body font family
• default font size
• line height

Keep in mind that standardizing our existing codebase to use these will take time and effort.

FYI, I also have this draft PR in the works to centralize component semantic tokens and make them rely more on brand colors: #56347

[odaneau-astro]

@odaneau-astro Would love your thoughts on this?

For me, I was thinking about allowing a larger theme json config element.

Also I am skeptical about us maintaining how color palettes are generated. I think that should be the domain of the person customizing the theme. We can still point them to useful tools. It also would be a slow development cycle to need to refresh the whole UI when you realize your base color wasn't just right.

I don't have a strong opinion on maintaining the palette generation logic ourselves.
Users are already familiar with single hex values from Airflow 2 and it simplifies things for end users.
But at the same time, there's no escape hatch if the colors don't turn out to be readable.

We could very well use @Zinkue's generatePalette.ts logic in the playground (#55789) and output the hex color list for users to copy in their env var / airflow config. Then, only allow the long list of hex codes for 50-950 values in the JSON config.

[Zinkue]

Many thanks for all your feedback!

This how I understood the flow for changing the navbar color should be:

1. (Optional) User goes to playground and provides a color so we generate a color palette
2. User adds a color palette to the JSON config

From my end I will break this PR in two work items:

1. Add my generatePalette.ts logic into @odaneau-astro's playground proposal
2. Rework the theme config property/env var to be a JSON value and, for the time being, accept the navbar color

If there will be no more comments, I will close this PR in favor of above's work items

[pierrejeambrun]

Thanks for the follow up @Zinkue.

Sounds like a good plan. Indeed it will be easier to move forward with two different PRs for those two work items.

[Zinkue]

closes: #53443

Bring back Airflow 2 side/navbar personalization based on a user provided color (theme configuration property)

Screenshoots

Input

Output

Input

Output

Input

Output

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[Zinkue]

It generates a custom color palette where:

• Luminosity comes from a list, e.g. output luminosity does not depend of input color
• Chroma is generated from to input color's chroma
• Hue is constant based in input color

Some doubts I have:

1. I used culori for color transformation. I can do the same with colorjs.io On which criteria you select one or another (Github stars, npm downloads, etc.)?
2. From UX (see yellow output in PR description above) does the output theme looks fine? I tried taking into account also imputed luminosity but maybe I am overthinking

For the future, when #55789 is merged we can add support for predefined themes and custom themes

[jason810496]

Nice! Thanks for the PR! LGMT for the API change.

The static check for spelling still need fix ( the CI failure will be handled in #56869, so no need to fix anything ).
We just need to add the missing words in docs/spelling_wordlist.txt. Thanks!

[pierrejeambrun]

Nice, thanks for the PR!

I think the customization should be a whole theme object that 'chakra UI` understands. Either a css file or an object definition, so we can go beyond just 'navbar' or one palette customization. (customizing border radius, or anything else in the app, for specific components too.)

[Zinkue]

Nice! Thanks for the PR! LGMT for the API change.

The static check for spelling still need fix ( the CI failure will be handled in #56869, so no need to fix anything ). We just need to add the missing words in docs/spelling_wordlist.txt. Thanks!

Sorry, do I need to do something from my end when you said "add the missing words in docs/spelling_wordlist.txt"?

[Zinkue]

Nice, thanks for the PR!

I think the customization should be a whole theme object that 'chakra UI` understands. Either a css file or an object definition, so we can go beyond just 'navbar' or one palette customization. (customizing border radius, or anything else in the app, for specific components too.)

I thought about two possible values for theme based on your comment:

1. { "type": "color", "value": "#123456"/existing color in the theme }
2. { "type": "file", "value": "path/to/theme.json" }

Agree for providing to the end-users full personalization of the UI but I think for the majority (I include myself here) changing only the color will be enough (DEV green, TST yellow, PRD red)

[jason810496]

Sorry, do I need to do something from my end when you said "add the missing words in docs/spelling_wordlist.txt"?

Yes, based on the error traceback in CI, we need to add the word grayscale in docs/spelling_wordlist.txt, thanks!

------------------------------ Error 2 ------------------------------
airflow-core/docs/howto/customize-ui.rst:78: (grayscale) will generate the same color palette (grayscale).
File path: /opt/airflow/airflow-core/docs/airflow-core/docs/howto/customize-ui.rst
Incorrect Spelling: 'grayscale'
Line with Error: ' will generate the same color palette (grayscale).'
====================================================================================================

[bbovenzi]

@odaneau-astro Would love your thoughts on this?

For me, I was thinking about allowing a larger theme json config element.

Also I am skeptical about us maintaining how color palettes are generated. I think that should be the domain of the person customizing the theme. We can still point them to useful tools. It also would be a slow development cycle to need to refresh the whole UI when you realize your base color wasn't just right.

[odaneau-astro]

I like the simplicity of this solution. The implementation expands on my original idea in https://playcode.io/2464307 and fixes obvious flaws in my POC.

I agree that we do want to expand customization options to other attributes, but we need to brainstorm a little more on what that would include. If we used a JSON env var with a single entry for navbar color for now, it would allow us to expand on it later.

Personally, I would not offer users the ability to customize things component-by-component. It would add a maintenance burden for end users when we add new components in the future.

I would also limit configuration attributes to essentials to avoid "config hell". Starting with accessibility requirements and corporate branding configs makes sense. Here are some that are top of mind:

• border width
• border radius
• background color
• default padding
• default margin
• header font family
• body font family
• default font size
• line height

Keep in mind that standardizing our existing codebase to use these will take time and effort.

FYI, I also have this draft PR in the works to centralize component semantic tokens and make them rely more on brand colors: #56347

[odaneau-astro]

@odaneau-astro Would love your thoughts on this?

For me, I was thinking about allowing a larger theme json config element.

Also I am skeptical about us maintaining how color palettes are generated. I think that should be the domain of the person customizing the theme. We can still point them to useful tools. It also would be a slow development cycle to need to refresh the whole UI when you realize your base color wasn't just right.

I don't have a strong opinion on maintaining the palette generation logic ourselves.
Users are already familiar with single hex values from Airflow 2 and it simplifies things for end users.
But at the same time, there's no escape hatch if the colors don't turn out to be readable.

We could very well use @Zinkue's generatePalette.ts logic in the playground (#55789) and output the hex color list for users to copy in their env var / airflow config. Then, only allow the long list of hex codes for 50-950 values in the JSON config.

[Zinkue]

Many thanks for all your feedback!

This how I understood the flow for changing the navbar color should be:

1. (Optional) User goes to playground and provides a color so we generate a color palette
2. User adds a color palette to the JSON config

From my end I will break this PR in two work items:

1. Add my generatePalette.ts logic into @odaneau-astro's playground proposal
2. Rework the theme config property/env var to be a JSON value and, for the time being, accept the navbar color

If there will be no more comments, I will close this PR in favor of above's work items

[pierrejeambrun]

Thanks for the follow up @Zinkue.

Sounds like a good plan. Indeed it will be easier to move forward with two different PRs for those two work items.

[Zinkue]

closes: #53443

Bring back Airflow 2 side/navbar personalization based on a user provided color (theme configuration property)

Screenshoots

Input

Output

Input

Output

Input

Output

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[Zinkue]

It generates a custom color palette where:

• Luminosity comes from a list, e.g. output luminosity does not depend of input color
• Chroma is generated from to input color's chroma
• Hue is constant based in input color

Some doubts I have:

1. I used culori for color transformation. I can do the same with colorjs.io On which criteria you select one or another (Github stars, npm downloads, etc.)?
2. From UX (see yellow output in PR description above) does the output theme looks fine? I tried taking into account also imputed luminosity but maybe I am overthinking

For the future, when #55789 is merged we can add support for predefined themes and custom themes

[jason810496]

Nice! Thanks for the PR! LGMT for the API change.

The static check for spelling still need fix ( the CI failure will be handled in #56869, so no need to fix anything ).
We just need to add the missing words in docs/spelling_wordlist.txt. Thanks!

[pierrejeambrun]

Nice, thanks for the PR!

I think the customization should be a whole theme object that 'chakra UI` understands. Either a css file or an object definition, so we can go beyond just 'navbar' or one palette customization. (customizing border radius, or anything else in the app, for specific components too.)

[Zinkue]

Nice! Thanks for the PR! LGMT for the API change.

The static check for spelling still need fix ( the CI failure will be handled in #56869, so no need to fix anything ). We just need to add the missing words in docs/spelling_wordlist.txt. Thanks!

Sorry, do I need to do something from my end when you said "add the missing words in docs/spelling_wordlist.txt"?

[Zinkue]

Nice, thanks for the PR!

I think the customization should be a whole theme object that 'chakra UI` understands. Either a css file or an object definition, so we can go beyond just 'navbar' or one palette customization. (customizing border radius, or anything else in the app, for specific components too.)

I thought about two possible values for theme based on your comment:

1. { "type": "color", "value": "#123456"/existing color in the theme }
2. { "type": "file", "value": "path/to/theme.json" }

Agree for providing to the end-users full personalization of the UI but I think for the majority (I include myself here) changing only the color will be enough (DEV green, TST yellow, PRD red)

[jason810496]

Sorry, do I need to do something from my end when you said "add the missing words in docs/spelling_wordlist.txt"?

Yes, based on the error traceback in CI, we need to add the word grayscale in docs/spelling_wordlist.txt, thanks!

------------------------------ Error 2 ------------------------------
airflow-core/docs/howto/customize-ui.rst:78: (grayscale) will generate the same color palette (grayscale).
File path: /opt/airflow/airflow-core/docs/airflow-core/docs/howto/customize-ui.rst
Incorrect Spelling: 'grayscale'
Line with Error: ' will generate the same color palette (grayscale).'
====================================================================================================

[bbovenzi]

@odaneau-astro Would love your thoughts on this?

For me, I was thinking about allowing a larger theme json config element.

Also I am skeptical about us maintaining how color palettes are generated. I think that should be the domain of the person customizing the theme. We can still point them to useful tools. It also would be a slow development cycle to need to refresh the whole UI when you realize your base color wasn't just right.

[odaneau-astro]

I like the simplicity of this solution. The implementation expands on my original idea in https://playcode.io/2464307 and fixes obvious flaws in my POC.

I agree that we do want to expand customization options to other attributes, but we need to brainstorm a little more on what that would include. If we used a JSON env var with a single entry for navbar color for now, it would allow us to expand on it later.

Personally, I would not offer users the ability to customize things component-by-component. It would add a maintenance burden for end users when we add new components in the future.

I would also limit configuration attributes to essentials to avoid "config hell". Starting with accessibility requirements and corporate branding configs makes sense. Here are some that are top of mind:

• border width
• border radius
• background color
• default padding
• default margin
• header font family
• body font family
• default font size
• line height

Keep in mind that standardizing our existing codebase to use these will take time and effort.

FYI, I also have this draft PR in the works to centralize component semantic tokens and make them rely more on brand colors: #56347

[odaneau-astro]

@odaneau-astro Would love your thoughts on this?

For me, I was thinking about allowing a larger theme json config element.

Also I am skeptical about us maintaining how color palettes are generated. I think that should be the domain of the person customizing the theme. We can still point them to useful tools. It also would be a slow development cycle to need to refresh the whole UI when you realize your base color wasn't just right.

I don't have a strong opinion on maintaining the palette generation logic ourselves.
Users are already familiar with single hex values from Airflow 2 and it simplifies things for end users.
But at the same time, there's no escape hatch if the colors don't turn out to be readable.

We could very well use @Zinkue's generatePalette.ts logic in the playground (#55789) and output the hex color list for users to copy in their env var / airflow config. Then, only allow the long list of hex codes for 50-950 values in the JSON config.

[Zinkue]

Many thanks for all your feedback!

This how I understood the flow for changing the navbar color should be:

1. (Optional) User goes to playground and provides a color so we generate a color palette
2. User adds a color palette to the JSON config

From my end I will break this PR in two work items:

1. Add my generatePalette.ts logic into @odaneau-astro's playground proposal
2. Rework the theme config property/env var to be a JSON value and, for the time being, accept the navbar color

If there will be no more comments, I will close this PR in favor of above's work items

[pierrejeambrun]

Thanks for the follow up @Zinkue.

Sounds like a good plan. Indeed it will be easier to move forward with two different PRs for those two work items.

[Zinkue]

closes: #53443

Bring back Airflow 2 side/navbar personalization based on a user provided color (theme configuration property)

Screenshoots

Input

Output

Input

Output

Input

Output

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[Zinkue]

It generates a custom color palette where:

• Luminosity comes from a list, e.g. output luminosity does not depend of input color
• Chroma is generated from to input color's chroma
• Hue is constant based in input color

Some doubts I have:

1. I used culori for color transformation. I can do the same with colorjs.io On which criteria you select one or another (Github stars, npm downloads, etc.)?
2. From UX (see yellow output in PR description above) does the output theme looks fine? I tried taking into account also imputed luminosity but maybe I am overthinking

For the future, when #55789 is merged we can add support for predefined themes and custom themes

[jason810496]

Nice! Thanks for the PR! LGMT for the API change.

The static check for spelling still need fix ( the CI failure will be handled in #56869, so no need to fix anything ).
We just need to add the missing words in docs/spelling_wordlist.txt. Thanks!

[pierrejeambrun]

Nice, thanks for the PR!

I think the customization should be a whole theme object that 'chakra UI` understands. Either a css file or an object definition, so we can go beyond just 'navbar' or one palette customization. (customizing border radius, or anything else in the app, for specific components too.)

[Zinkue]

Nice! Thanks for the PR! LGMT for the API change.

The static check for spelling still need fix ( the CI failure will be handled in #56869, so no need to fix anything ). We just need to add the missing words in docs/spelling_wordlist.txt. Thanks!

Sorry, do I need to do something from my end when you said "add the missing words in docs/spelling_wordlist.txt"?

[Zinkue]

Nice, thanks for the PR!

I think the customization should be a whole theme object that 'chakra UI` understands. Either a css file or an object definition, so we can go beyond just 'navbar' or one palette customization. (customizing border radius, or anything else in the app, for specific components too.)

I thought about two possible values for theme based on your comment:

1. { "type": "color", "value": "#123456"/existing color in the theme }
2. { "type": "file", "value": "path/to/theme.json" }

Agree for providing to the end-users full personalization of the UI but I think for the majority (I include myself here) changing only the color will be enough (DEV green, TST yellow, PRD red)

[jason810496]

Sorry, do I need to do something from my end when you said "add the missing words in docs/spelling_wordlist.txt"?

Yes, based on the error traceback in CI, we need to add the word grayscale in docs/spelling_wordlist.txt, thanks!

------------------------------ Error 2 ------------------------------
airflow-core/docs/howto/customize-ui.rst:78: (grayscale) will generate the same color palette (grayscale).
File path: /opt/airflow/airflow-core/docs/airflow-core/docs/howto/customize-ui.rst
Incorrect Spelling: 'grayscale'
Line with Error: ' will generate the same color palette (grayscale).'
====================================================================================================

[bbovenzi]

@odaneau-astro Would love your thoughts on this?

For me, I was thinking about allowing a larger theme json config element.

Also I am skeptical about us maintaining how color palettes are generated. I think that should be the domain of the person customizing the theme. We can still point them to useful tools. It also would be a slow development cycle to need to refresh the whole UI when you realize your base color wasn't just right.

[odaneau-astro]

I like the simplicity of this solution. The implementation expands on my original idea in https://playcode.io/2464307 and fixes obvious flaws in my POC.

I agree that we do want to expand customization options to other attributes, but we need to brainstorm a little more on what that would include. If we used a JSON env var with a single entry for navbar color for now, it would allow us to expand on it later.

Personally, I would not offer users the ability to customize things component-by-component. It would add a maintenance burden for end users when we add new components in the future.

I would also limit configuration attributes to essentials to avoid "config hell". Starting with accessibility requirements and corporate branding configs makes sense. Here are some that are top of mind:

• border width
• border radius
• background color
• default padding
• default margin
• header font family
• body font family
• default font size
• line height

Keep in mind that standardizing our existing codebase to use these will take time and effort.

FYI, I also have this draft PR in the works to centralize component semantic tokens and make them rely more on brand colors: #56347

[odaneau-astro]

@odaneau-astro Would love your thoughts on this?

For me, I was thinking about allowing a larger theme json config element.

Also I am skeptical about us maintaining how color palettes are generated. I think that should be the domain of the person customizing the theme. We can still point them to useful tools. It also would be a slow development cycle to need to refresh the whole UI when you realize your base color wasn't just right.

I don't have a strong opinion on maintaining the palette generation logic ourselves.
Users are already familiar with single hex values from Airflow 2 and it simplifies things for end users.
But at the same time, there's no escape hatch if the colors don't turn out to be readable.

We could very well use @Zinkue's generatePalette.ts logic in the playground (#55789) and output the hex color list for users to copy in their env var / airflow config. Then, only allow the long list of hex codes for 50-950 values in the JSON config.

[Zinkue]

Many thanks for all your feedback!

This how I understood the flow for changing the navbar color should be:

1. (Optional) User goes to playground and provides a color so we generate a color palette
2. User adds a color palette to the JSON config

From my end I will break this PR in two work items:

1. Add my generatePalette.ts logic into @odaneau-astro's playground proposal
2. Rework the theme config property/env var to be a JSON value and, for the time being, accept the navbar color

If there will be no more comments, I will close this PR in favor of above's work items

[pierrejeambrun]

Thanks for the follow up @Zinkue.

Sounds like a good plan. Indeed it will be easier to move forward with two different PRs for those two work items.