This is a breaking change, so we have given this a ‘major bump’ in the [npm package](https://www.npmjs.com/package/@visual-framework/vf-design-tokens) to `v2.0.0`.
Where we were using [’t-shirt’ sizes](https://www.drupal.org/files/issues/2019-05-01/Bootstrap-4--v--Bootstrap-3.png) 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: - have already [been made in components](/updates/2020-10-20-component-updates) that made use of the original spacing design tokens so if you update your components to the latest version - you will get these updates ‘for free’. - also effects the naming of the utility classes that some are using in their sites and products. You will need to update those CSS classes accordingly to benefit from 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).
tl;dr?
vf-u-margin__bottom--xs is now vf-u-margin__bottom--100
Where we were using [’t-shirt’ sizes](https://www.drupal.org/files/issues/2019-05-01/Bootstrap-4--v--Bootstrap-3.png) 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: - have already [been made in components](/updates/2020-10-20-component-updates) that made use of the original spacing design tokens so if you update your components to the latest version - you will get these updates ‘for free’. - also effects the naming of the utility classes that some are using in their sites and products. You will need to update those CSS classes accordingly to benefit from 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).