I have raised this issue as an action point from a discussion that we had in the engineering enclave on May the 23rd.
Below is my "personal" experience of working on the re-organization of the button states.
"The current division of designs token is not working very well from a development experience point of view. The most problematic layer of the token has been the "codex-components". This seems to be very useful on paper, but its current usage of it turns out to create more headaches than development support.
A few issues that I have encountered while developing the above-mentioned task:
- Not all button states have a codex-component token: for example @border-color-progressive--hover
There is no distinction within the tokens to understand where the token comes from so @border-color-progressive--hover is from codex-base but @background-color-quiet--hover" is from codex-components`
- Good point. For context, -quiet was inherited from OOUI/WikimediaUI Base. All other tokens in 'codex-components.json' are already applying the component that they are used for in their name. We'll update to -button-quiet accordingly.
- Sometimes a codex-base token may not align with a component one, so a "progress-base--hover` may need to be overridden in codex-components just because the Progress-base-hover of the button is not the same as the base!
- VE: Not sure, I understand what's meant here.
- We try to avoid the creation of many tokens, so if a couple of states share a value we try to reuse it, but this turns out to be not very clean to read in the .vue files. You may find a "hover" in an active state or a "Normal" declaration in the progressive.
- VE: This is a problematic gap that should not happening with the full tokens nomenclature settled. Modifier tokens should be exclusive to states.
- The Figma designs are always (until now) being provided with the use of the codex-base, and it is time-consuming to decode what the colour meant at a "codex-component" level.. (lots of Find All)
Components could have a very nested level of requirements (eg button-normal-progressive-active). This is quite verbose to define in tokens and can be cleaner and easier to see within a full CSS declaration where.
- VE: That's not the case anymore with updated color tokens in place T296995
We are not making good use of the actual .vue file. These are supposed to include the full scope of the components, and I think we could remove the codex-component and actually declare component-specific token (or more specifically CSS declaration) directly within the component and just call the Codex-base file."
- VE: As much as this might make sense from a pure developer view, it's important to collect the component tokens in one place in order to see emerging patterns or be clear about the discrepancies of one-offs.