Dismiss color token

[aweell]

Description

In order to cover the new definition of dismiss color, and given the fact the components use internally the iconButton to display the dismiss action, we'll need a new category of tokens that point to component properties.

Token scope

The components that currently have a dismiss property in the system are:

• Cards
• Dialogs
• Popover
• Callout
• Snackbar (n/a)
• Drawer

Related to token category

We already have the category themeVariant:

"themeVariant": {
    "componentName": {
      "value": "default" | "inverse" | "alternative" | "media",
      "type": "themeVariant"
    }
  },

I see two potential solutions:

1. We can evolve this definition to support also buttonIcon types and rename the category, since the scope of the tokens is similar, define via skin the value of a component prop. First I thought creating different types, like variant, type etc...but the potential props that can fall into this category is so heterogeneous that i can wrap my head around a solution.

Another example, if we want the button group to have a token to allow aligning differently in our brands, the type would be align? is always the type the name of the prop?

Example of this:

"light": {...},
"dark": {...},
"radius": {...},
"componentProperty": {
    "successFeedbackVariant": {
      "value": "default" | "inverse" | "alternative" | "media",
      "type": "componentProperty"
    },
    "dismissIconButtonType": {
      "value": "brand" | "neutral" | "error",
      "type": "componentProperty"
    },
  },

Since the themeVariant tokens are still unused choosing this option shouldn't cause a breaking change.

2. Create a new category named componentProperty where we could have a structure like:

"componentProperty": {
    "componentName": {
      "value": "brand" | "neutral" | "error",
      "type": "componentProperty"
    }
  }

Example of this:

"light": {...},
"dark": {...},
"radius": {...},
"themeVariant": {...},
"componentProperty": {
    "dismissIconButtonType": {
      "value": "brand" | "neutral" | "error",
      "type": "componentProperty"
    },
  },

Related to values

What if a component has multiple props to be changed?

I see two options here:

1. Allow an array of values

"componentProperty": {
    "dismissIconButton": {
      "value": [
        {
         "property": "type",
         "value": "brand" | "neutral" | "error",
         },
        {
         "property": "backgroundType",
         "value": "transparent" | "soft" | "solid",
         },
       ]
      "type": "componentProperty"
    }
  }

2. Make different tokens (this is related to next section "Related to naming")

"componentProperty": {
    "dismissIconButtonType": {
      "value": "brand" | "neutral" | "error",
      "type": "componentProperty"
    },
    "dismissIconButtonBackgroundType": {
      "value": "transparent" | "soft" | "solid",
      "type": "componentProperty"
    }
  }

Related to naming

The structure I propose for these tokens is:

element name - component name - component property

where:

• Element name: Helps to describe the context of the component
• Component name: describes the component we will change the property of
• Component property: describes the property we are pointing at

For example if we want to tackle the dismiss of dialog, cards, popover, etc...the name would be:

dismissIconButtonType

If the scope for example is the alignment of the buttons of the media card

mediaCardButtonGroupAlign

Tasks

• [ ] Update specs
• [ ] Design documentation
• [ ] Add to mobile library
• [ ] Add to desktop library
• [ ] Add to UI Kit
• [ ] Android ticket
• [ ] iOS ticket
• [ ] Web ticket

[AnaMontes11]

Hi @aweell Given that Movistar already has a specific requirement and it is likely that similar cases will arise in the future, I believe that Solution 2 is the one that scales best. This solution allows for the addition of more customized properties in a flexible way, without compromising the global structure of the system. Additionally, it provides the ability to adapt to the specific needs of each brand.

On the other hand, Solution 1, which involves extending themeVariant, could become overly complex if more customized properties are added. This might make it difficult to maintain and could lead to confusion in the long term.

In my opinion, we should keep themeVariant focused on high-level themes (such as global variants) and use componentProperty to handle component-level customizations. This not only ensures a clear separation of responsibilities but also makes the system more scalable and easier to maintain.

[AnaMontes11]

If we go with solution 2, for the token structure, I would explore the possibility of using abbreviations. For example:

btn: button. bg: background. align: alignment.

This would reduce the length of the names, making them more manageable and easier to consume both in design (when consulting the Figma panel) and in development.

[aweell]

I believe that Solution 2 is the one that scales best.

I'm here too.. both for category and for value structures option 2 is more scalable

If we go with solution 2, for the token structure, I would explore the possibility of using abbreviations. For example:

btn: button. bg: background. align: alignment.

We don't use that format in current tokens, i suggest to discuss that topic with a broader scope

[AnaMontes11]

We don't use that format in current tokens, i suggest to discuss that topic with a broader scope

I understand that we currently don’t use this format for tokens. However, my suggestion to use abbreviations stems from the concern that including the component definition in token names might make them overly long. This could negatively impact the user experience in Figma, where lengthy names can become difficult to read and manage in the right-hand panel.

It would be interesting to discuss this further with a broader scope, as you mentioned!