feature: Per Scope Context Management and Variables

[jbltx]

Is your feature request related to a problem? Please describe.

I currently work on a Design System and I would like to be able to switch between color schemes and other factors that are taken into account in my system.

Describe the solution you'd like.

As with other competitors, defining variables on any styling aspect of elements in a file could open the door to more dynamic designs. Those will be able to react to "context" changes.

Context

Now it is important to explain the concept of Context. A Context can be defined as a simple dictionary of key/values. Each entry will fine-tune the final Context used in a certain Scope.

{
  "color-scheme": "dark",
  "scale-factor": 1.0
}

Scope

A scope is an entity where a Context will be provided. In Penpot, I can imagine these different scopes:

- Project level
  |- File level
    |- Page level
      |- Layer level

As these scopes could be visually defined in a tree, you guess that by providing a Context at a certain level (Scope), this context will be propagated to its descendants.

Also, even if an entity provides a Context, descendants can still be able to provide another one (principle of Context override).

For published Libraries, the same principles apply: if an entity of the Library uses a Variable, it should react to any Context changes inside the project where the entity has been instantiated.

Variable

A variable should be able to have a different value based on the Context it is used.
The variable is not bound to a single entry of the Context (the value can evaluate multiple parts of the Context to determine its value).

We can imagine having bare Variables stored as assets and could be published inside Libraries too (which will join the definition of what a Design Token is).

Describe alternatives you've considered.

Figma Variables

In Figma, Variables' Modes can be relatively similar to Contexts. However I found the way they arranged Variables in a table (Variables as rows and Modes as columns) is quite limited, and not having homogenous overrides between Modes end up with some issues.

Here is an example of the limitation:

Base Collection

Variable Name	Base
text-size	14px
heading-size	20px

Scale Collection

Variable Name	Smaller	Just Text Bigger
text-size	12px	15px
heading-size	16px	-

In Figma, when you want to bind a variable to an element's property, you will need to provide a variable coming from one specific Collection. That is because Figma does not see variables with the same name in different Collections as "overrides",
but unique variables.

Since in the Mode Just Text Bigger we didn't provide a value for the variable heading-size, we would expect that this value will be solved as 20px by taking into account the order of overrides (Base then Scale). Instead, Figma does not override, as the variables in the collection are considered new variables. In this case, the heading-size for Just Text Bigger is 0.

Tokens Studio

I use a lot Tokens Studio in Figma, and I think some concepts are similar (their Themes can be seen as Context, and the value of tokens can be overridden when switching Themes based on token sets order). You can also apply the current Theme configuration at different levels in your working file. Being able to sync tokens in external storage such as GitHub repositories is a must.

StyleDictionary

A bit out of context, but since Tokens Studio JSON files work well as StyleDictionary inputs (with some custom transformers), we can imagine an integration of this tool to export Variables from Penpot for different platforms. People could even be able to bring their own SD configuration with custom transformers etc...

Additional context

No response