Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EDS 2.0 tokens in EDS 1.0 code components #23

Open
vnys opened this issue Mar 21, 2024 · 4 comments
Open

EDS 2.0 tokens in EDS 1.0 code components #23

vnys opened this issue Mar 21, 2024 · 4 comments
Labels
code foundation ga feature phase: generally available tokens

Comments

@vnys
Copy link
Member

vnys commented Mar 21, 2024

We need a strategy that encourages early adaptation of EDS 2.0. In order to do that we need EDS 1.0 components to use the EDS 2.0 tokens when they’re present. One way to do that is to insert CSS hooks in the token files with a fallback to the 1.0 tokens, so that if the application does not use the EDS 2.0 themes nothing happens, but if it does then the EDS 2.0 themes take precedence. I suggest focusing on colours and typography first and foremost. For the density modes we can consider saving that purely for EDS 2.0 apps.

@vnys vnys converted this from a draft issue Mar 21, 2024
@vnys vnys added code tokens foundation ga feature phase: generally available labels Mar 21, 2024
@oddvernes
Copy link

If the new typography components are to fetch their tokens from the new css tokens, and those components are to be used inside existing react components (especially the UIText to be used inside tabs etc), then this idea falls apart. The alternatives are to

  • release the new typography components but not use them ourselves in our components,
  • or hardcode the typography tokens inside react (like @torleifhalseth did in his pr)
  • or to make the new tokens a requirement from the moment we start using it

@torleifhalseth
Copy link

The last option makes sense to me, but I would hope that we could adjust the styling of our components to use this CSS setup (@vnys idea):

color: var(--eds-override-color, var(--eds-token-v2, --eds-tokens-v1))

This way we use the current v1 token if both the override variable and v2 token are undefined. This makes it optional for the application to start using/adding the new tokens. Do you think this makes sense or am I forgetting something?

@oddvernes
Copy link

If eds literally breaks without the v2 tokens (it becomes a requirement from the start), then the above fallback is meaningless waste of time since there would be no condition where v1 would be used

@torleifhalseth
Copy link

I get your point if we make v2 tokens a requirement and implement these tokens for all components, but I guess we want to do this gradually?

How would components break without the v2 tokens if we use the fallback @oddvernes?

I think we should separate the discussion regarding typography components and components using color tokens.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code foundation ga feature phase: generally available tokens
Projects
Status: No status
Development

No branches or pull requests

3 participants