It would be nice to let installs define custom tokens for "Award Token". Two general approaches to this are:
- extend them with extensions, so you can add tokens by installing extensions.
- create a database "token" object, so you can add tokens via the web UI.
The major technical issue with both approaches is that tokens currently generate a sprite map, and this is a manual, offline process:
Ideally, we would just generate this map (and the associated CSS) on demand through Celerity, so it could have as much stuff in it as we wanted without any performance penalty or need to run scripts.
We can't dynamically generate sprite maps through Celerity right now. This is probably not particularly difficult to build, although we will potentially lose optipng from the pipeline. We could still ship the default map as a cached resource on disk and accept a small reduction in compression effectiveness when installs extend the defaults, although this increases complexity.
We also don't really need to sprite these resources, and could stop doing them as a sprite map and accept the performance hit. Or we could sprite the defaults and accept that extensions eat a performance hit.
When I built tokens, I think we used a lot of sprite maps and it seemed inevitable that we'd need to modularize them eventually (e.g., for application icons). However, FontAwesome has replaced most uses and we use very few today, and it no longer seems inevitable that we must provide modular sprite composition. This reduces the attractiveness of sinking work into on-demand sprite composition infrastructure.