We should cover naming and lifecycle like https://github.com/openedx/frontend-plugin-framework/blob/master/docs/decisions/0003-slot-naming-and-life-cycle.rst does
We should also make it clear what application tokens are part of the API contract. openedx/frontend-app-authoring#2837 added a bunch of CSS vars purely from a DRY/avoiding hardcoded color hex values perspective. Brand packages can modify those now, but that doesn't mean we want to commit to supporting those CSS vars. We shouldn't prevent application developers from using CSS vars for cleaner style architecture out of fear that theme authors will rely on those and they'll become part of an API contract we need to support.
Another little thing to decide is how to handle fallbacks in var( vs having application stylesheets define values for vars on :root. In frontend-app-catalog we use the fallback method for the banner background color, and there's no downside there because it's consumed in one place. In the authoring PR example using fallbacks would defeat the purpose of using CSS vars to keep it DRY. I'm ok with having this be a judgement call thing, but if we want to standardize that's worth considering too.
We should cover naming and lifecycle like https://github.com/openedx/frontend-plugin-framework/blob/master/docs/decisions/0003-slot-naming-and-life-cycle.rst does
We should also make it clear what application tokens are part of the API contract. openedx/frontend-app-authoring#2837 added a bunch of CSS vars purely from a DRY/avoiding hardcoded color hex values perspective. Brand packages can modify those now, but that doesn't mean we want to commit to supporting those CSS vars. We shouldn't prevent application developers from using CSS vars for cleaner style architecture out of fear that theme authors will rely on those and they'll become part of an API contract we need to support.
Another little thing to decide is how to handle fallbacks in
var(vs having application stylesheets define values for vars on:root. Infrontend-app-catalogwe use the fallback method for the banner background color, and there's no downside there because it's consumed in one place. In the authoring PR example using fallbacks would defeat the purpose of using CSS vars to keep it DRY. I'm ok with having this be a judgement call thing, but if we want to standardize that's worth considering too.