I'm wondering ifpermission should be treated as a theme or not as a design token in this case, but I'm okay with it for now. Perhaps having a 'muted' pill variant could be better. 🤔 Wdyt@aslilac ?

Imho, this is way too specific of a thing to add to the theme. We've been missing a clear "neutral"role choice for a while, and I've been meaning to resolve that for a while but it just hasn't come up recently. That being said, you got me thinking about it again today and I have proposed a fix in#14356. If that PR gets merged, I'd much rather usetheme.roles.info colors for these than complicate the globalTheme for this one specific use case.

I really just added the Permission theme to have a short discussion about it. I was originally going to use or modify role but semantically permissions are not roles (roles are assigned permissions) and if we are using a feature concept such as roles in the theme it would make sense to add permissions as well. And this will also make it more likely for others in the future to have the idea to add theming for features (like I did) then adding theming for UI concepts. For example, this could happen with other elements that have a lot of variations such as avatars, buttons, cards, status indicators, etc.

The other way to do it is more like in mui.ts where its about UI elements and tags. If we following that line of thinking then we could use the name pills in the theme instead of roles. In this case we are thinking more about the UI component itself than the feature it is used for.

Sorry about the confusion. Thetheme.roles property is entirely unrelated to the "Roles" feature in the product. 😄#14356 has been merged now though, sotheme.roles.info is there to use as a neutral color set.

theme.roles.info.background and theme.roles.info.outline are different than the colors I want to use. Where would you suggest placing the colors I wanted to use from theme.roles.default?

I'm gonna be defensive about this because I put a lot of thought into the design of this bit of our theme:default, the way that you are using it, is not a UI role. As a user, when the app uses theerror colors I can say "The UI is showing me something is wrong", but I can't say "The UI is showing me a default color role for general use". I think the intent of these roles is really important for consistency throughout the product.

I'm also not convinced thatColorRole is a better name. The colors they represent are a consequence, not the primary motivation. Otherwise they'd just be namedred,orange, etc. You're supposed to think about what you're trying to communicate with the color first, and then the colors come from that naturally. MaybeUiRole or something if you really think it needs to be changed.

default could potentially be an appropriate role name if it was identifying things in the UI as a default target. The default org, the default template version, so on. But there isn't anything about the permissions given to an org role that makes them "default" of that role, especially not when used to highlight all of them.

What I want is a way to define styles for a default pill, and although info can work, the name feels like its a special case and not the standard/default color. I would ideally like to keep defaults in palette or someplace outside of roles in case it doesn't fit into background, outline, text, or the fill colors.

is this type annotation here still necessary? maybe if TypeScript is having trouble inferring the type here you could add: string[] to the function declaration

not necessary, just leftover from implementation work.