You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Custom themes currently cannot change some thread-status colours. Working stays blue, Done stays green, and Input uses hardcoded indigo, even when those colours clash with the selected theme. This is particularly noticeable with a warm theme such as Espresso.
PR #13371 moved many colours to semantic tokens and describes status colours as following custom themes. However, the theme mapping in index.css explicitly keeps info and success independent of themes, while error and warning are configurable. Is that distinction intentional, or is exposing the remaining status colours a reasonable follow-up?
Proposal
Expose the remaining thread-status colours through the existing theme system:
info and infoForeground for Working and informational indicators.
success and successForeground for Done and successful outcomes.
A semantic colour for threads awaiting user input.
Have both sidebar implementations consume the same theme roles.
Current colours would remain the defaults, so existing themes would keep their appearance. Theme authors could override them through the editor or theme JSON. As with the existing error and warning roles, other indicators using the same semantic tokens would follow those overrides too. Provider logos and channel identity colours would remain outside this scope.
Would you be open to a focused PR for this? I have a small local prototype for the info role, but would like to agree on the direction before expanding it.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Custom themes currently cannot change some thread-status colours. Working stays blue, Done stays green, and Input uses hardcoded indigo, even when those colours clash with the selected theme. This is particularly noticeable with a warm theme such as Espresso.
PR #13371 moved many colours to semantic tokens and describes status colours as following custom themes. However, the theme mapping in index.css explicitly keeps info and success independent of themes, while error and warning are configurable. Is that distinction intentional, or is exposing the remaining status colours a reasonable follow-up?
Proposal
Expose the remaining thread-status colours through the existing theme system:
infoandinfoForegroundfor Working and informational indicators.successandsuccessForegroundfor Done and successful outcomes.Current colours would remain the defaults, so existing themes would keep their appearance. Theme authors could override them through the editor or theme JSON. As with the existing error and warning roles, other indicators using the same semantic tokens would follow those overrides too. Provider logos and channel identity colours would remain outside this scope.
Would you be open to a focused PR for this? I have a small local prototype for the
inforole, but would like to agree on the direction before expanding it.All reactions