Initializing design token system for sizes

[mrleemurray]

This pull request introduces support for a new category of CSS variables (sizes) and updates the codebase to use these variables for styling, improving maintainability and consistency.

Key changes include:

• creating sizeRegistry & sizeUtils to handle the registration of size tokens and provide utility functions for size-related operations
• refactoring CSS files in src/base/browser/ui to replace hardcoded values with the new sizes variables
• adding the sizes category to the known variables list, updating JSON data

Support for new sizes category:

• build/lib/stylelint/validateVariableNames.js and build/lib/stylelint/validateVariableNames.ts: Added the sizes category to the known variables set, allowing the use of size-related CSS variables. [1] [2]
• build/lib/stylelint/vscode-known-variables.json: Introduced a comprehensive list of size-related variables under the new sizes category.

Refactoring CSS files to use size variables:

The following CSS files in src/base/browser/ui have been updated to use the new sizes variables for improved consistency and maintainability:

• actionbar/actionbar.css
• button/button.css
• countBadge/countBadge.css
• dialog/dialog.css
• dnd/dnd.css
• dropdown/dropdown.css
• findInput/findInput.css
• hover/hoverWidget.css
• iconLabel/iconLabel.css
• icons/iconSelectBox.css
• inputbox/inputBox.css
• keybindingLabel/keybindingLabel.css
• list/list.css
• menu/menubar.css
• progressbar/progressbar.css
• radio/radio.css
• sash/sash.css
• scrollbar/media/scrollbars.css
• splitview/paneview.css
• splitview/splitview.css
• table/table.css
• toggle/toggle.css
• toolbar/toolbar.css
• tree/media/paneviewlet.css
• tree/media/tree.css

Moving forward, the design team will make incremental updates to tokens & styles during debt weeks.

[bpasero]

Adding also @aeschli

@mrleemurray for an easier review: is this change already changing dimensions that we had or is it taking the value it used to have and extract that into a variable?

[mrleemurray]

@bpasero no values are being changed - only converting current values into variables.

[aeschli]

Looks great.
Is there already a SizeTheme, or a color theme that has a 'getSize' method?

[mrleemurray]

@aeschli no SizeTheme yet - I'd like to have a full working set of tokens before creating themes, but I'm happy to start exploring that functionality now

[mrleemurray]

@aeschli I have just added a sizeFromId utility function to allow js to access the values

[mrleemurray]

@aeschli is there anything else you require for the review?

[bpasero]

@mrleemurray I am looking at this from a high level and I think you did a pretty good job in mimicking what we already have today for colors based on what @aeschli did. I defer to his 👁 for whether that integration into the theme story works for him.

I am having some question marks in my head around the naming of all the variables. I see that some widgets share the same variable (for example --vscode-base-spacing-xxs) but is there really also a logical relation between all the widgets sharing the same color?

To give an example:

• the dialog has a vscode-base-spacing-none for its blocking div (the one we use so that you cannot click behind the dialog) (here)
• but then this variable is also used for the dropdown widget as padding (here)

Changing the value of the variable will have a weird outcome: the dropdown has larger padding, but also the dialog now has parts where you can click through?

This is just one example, and I am sure there will be many more.

I believe we would actually have to begin with almost having a variable per widget specific size inside to have an overview of all the things before we can start to reuse things?

[mrleemurray]

@bpasero I think you are right - I was trying to limit the amount of unique tokens, but we will run into issues mentioned above. I will make more specific, per widget tokens. These granular tokens can inherit base values, which will help with overall consistency, but can also be updated individually if required. I have a couple of questions that will also help with logic:

• Do we need 0px tokens? In your dialog example it doesn't make much sense to have the ability to control the blocking element padding. Are there any instances where modifying a 0px value is required?
• Should we even expose the base tokens as CSS Variables? They might be useful for extension developers, but again might cause unintended side effects of changing them

[bpasero]

@mrleemurray yeah you bring up a good point that maybe not every size value should be controlled by a theme, there are sometimes reasons to have them at a fixed value, but then how do we track these in the CSS that we are not accidentally pulling them out?

Alternatively, a value like 0 could easily be a variable that we never allow to customise.

What specifically do you refer to as "base tokens"?

[mrleemurray]

@bpasero do you mean that a 0 variable would still appear in the stylesheet, but not in a theme?

What specifically do you refer to as "base tokens"?

I mean the 4px grid / generic values that all other sizes should be derived from e.g. --vscode-base-spacing-s (any variable with the word base in the name)

[bpasero]

do you mean that a 0 variable would still appear in the stylesheet, but not in a theme?

Either way, we need a solution to identify a size value in a CSS file as being externalised so that we know which values still need to be converted to a variable. If we leave some values around because they are not themeable then we need to mark them in some way.

mean the 4px grid / generic values that all other sizes should be derived from e.g. --vscode-base-spacing-s (any variable with the word base in the name)

I do not think that there should be base values like that that variables extend from, because changing them has impact that is not desired, as long as the variables are not correlated. I would have logical base variables that other variables can extend from. I am not sure the value of having variables like "grid-4px-variable"?

[mrleemurray]

Okay, let's go with adding "static" CSS variables that can't be updated by themes.

I do not think that there should be base values like that that variables extend from, because changing them has impact that is not desired, as long as the variables are not correlated. I would have logical base variables that other variables can extend from. I am not sure the value of having variables like "grid-4px-variable"?

Apologies, I was meaning from the design stage - in Figma we use inheritance to define the values of each granular variable, but every variable will be exported as a standalone variable with it's own value, for future updates.

[mrleemurray]

@bpasero I have created a much more granular set of tokens that allow fine tuning of specific components without affecting other parts of the UI. I have also created a new set of "static" tokens to represent values that will not be exposed in themes - these tokens currently represent 0px values.