I'm not married to any part of this, but it seems like a reasonable first step that at least offers a solution to most of the clarity/consistency issues without requiring any new design.

The idea of using "no icon" to signify functions doesn't particularly resonate with me because:

• I think tokens with no icon also don't really stand out much in a field of other tokens. I'd like function tokens to stand out fairly well, since they can have surprising behavior and I think they merit calling the viewer's attention to as they write or review a query.
• I like using the icon to communicate the function return type (e.g., members() returns 'fa-users'). I think this makes functions easier to understand, since the icon helps suggest what the function does.
• Some token types have no icon right now (e.g., Almanac interfaces, almanac services, diffusion symbols, arcanist projects, I think task statuses and priorities, maybe others). We could give them all icons or give them a default icon, but it's easier to start here.

The biggest issue I see with this is that projects with colors render differently in different contexts:

• As a token in a typeahead: blue background with a colored icon.
• As a tag (for example, on a task detail page): colored background with a colored icon.

Some possible fixes:

1. Leave it as it is, maybe it's fine without changes.
2. Change the "tag" rendering to use a blue background and only color the icon, so both are "blue background with colored icon".
3. Color both the background and icon when rendering a token.

If we do (3), the issue is:

• Color is no longer a consistent indicator of token type, e.g. yellow tokens will either be a function or a yellow project.

Maybe that's fine; maybe we try to communicate type in some other way (e.g., change silhouettes).

Everything here seems ok, not a super fan of the colored icon, but happy to give it a test. Can I just patch this locally or are there dependents?

There are other treatments we could consider as well, like not rounded, full color w/ white text, etc.

This is on top of like 15 dependencies right now, but I think this stuff is pretty close to hitting HEAD.

Agreed that the just-icon-color-change isn't great. Maybe something really minor like putting a dropshadow or white outline around the icon would make it feel less color-clashey, though.

I'd say land it today if you're comfortable and I'll tweak over the weekend.

If I were to make more colors for the additional token states, how many are we looking at? Seems like... 3? Normal = blue, disabled = grey should remain the same. Then Custom, Function, Invalid get new colors.

Color is no longer a consistent indicator of token type, e.g. yellow tokens will either be a function or a yellow project.

I think I can solve this with just some new colors. I'd rather have project icons always retain the right color and have to come up with some new colors (cognitive load does increase) than use just an icon color which seems confusing (it's also the wrong color, too).

Is this stuff easy to me to change, is it all here in this diff?

"Custom" is just "something that already has colors", which only means "projects" right now (but might mean, e.g., "flags" in the future).

So really just two (invalid, function) and it's not really too important for "invalid" to look very special because it's purely an error state (for example, if you go to /query/?users=derpaderpderp() we'll render an "invalid" token, but you can never get an invalid token normally).

So arguably just one (function).

You have everything you need to change the color of "function" in this diff. We'll need to make some more adjustments to get the color to apply to the whole token for projects (the color class is just on the icon right now), but that's pretty easy.

I'm still partial to the button inside the element, with a tooltip. Do you have feelings here?

Yeah, I think that's way better. My implementation was just trying to get it working.

(Without cascading into a bunch of PHUI changes.)