Giving the Visual Framework better space

The Visual Framework's Design Tokens v2.0.0 release has a new way of defining the spacing tokens used for padding and margins for components and content.

20 Oct 2020

This is a breaking change, so we have given this a ‘major bump’ in the npm package to v2.0.0.

tl;dr?

vf-u-margin__bottom--xs is now vf-u-margin__bottom--100


Where we were using ’t-shirt’ sizes to define a naming convention it stifled our ability to create newer spacing tokens. How do decide what to call the value that’s between ‘medium’ and ‘large’? We didn’t think vf-spacing—bigger-than-medium-but-smaller-than-large would work out so well.

Now we use an incremental number to determine the spacing tokens.

As we are moving closer to a more unified, consistent system of layout and spacing with multiples of 4px we start with 4px (or .125em) equally 50.

This way we can easily expand the spacing tokens as needed.

These changes:

Below is a table of what the tokens were, and what they are now so you can ‘find and replace’ as needed in your projects.

old class new class value (in rem)
.vf-u-margin—0 .vf-u-margin—0 0rem
.vf-u-margin—xxs .vf-u-margin—50 .125rem
.vf-u-margin—xs .vf-u-margin—100 .25rem
.vf-u-margin—sm .vf-u-margin—200 .5rem
.vf-u-margin—md .vf-u-margin—400 1rem
.vf-u-margin—lg .vf-u-margin—500 1.25rem
.vf-u-margin—xl .vf-u-margin—600 1.5rem
.vf-u-margin—xxl .vf-u-margin—800 2rem
.vf-u-margin—xxxl .vf-u-margin—1200 3rem

This also highlights the (so far, unwritten) rule that utility classes should be a last resort, and not an often used technique (we are trying to move components forward so they can accept things that might need to be ‘customised’ for your requirement).

Find an issue on this page? Propose a change or discuss it.