[OUDS] Add "Dimension" tokens, utilities and documentation

[louismaximepiton]

Related issues

Closes #2605.

Description

Remaining tasks and questions

Questions:

• Should we introduce an easy way to get all utilities in px and in rem. I mean not only a function px-to-rem but an option like $enable-rem-utilities that make a dupe of each utility but in rem? IMO, we should but it will probably make the bundle size raise a lot. Not done yet.
• What scenario to follow inside the _utilities.scss for utilities priority? IMO we should stick to the one proposed for the doc implementation.
• What to do with the $spacer and $spacers variables? IMO, $spacer should take the value $ouds-dimension-base * 5. Not done yet. It's the base of many calculations inside Boosted/Bootstrap. Do we replace them with our $ouds-dimension-base and $ouds-dimension-space-fixed? IMO, we should keep the Bootstrap ones.
• Do we keep the same size utilities .w-100, etc.. ? IMO, we should since the tokens don't look like they are done for it.

Done list

The following was done in the PR:

• Revert [OUDS] feat: Add "Elevation" tokens, utilities and documentation - new version #2741 changes about _ouds-maps.scss and rather introduce tokens/_composite.scss. Change all the related files.
• Introduce new Sass maps that contain all the fixed and scaled values for utilities.
• Introduce new CSS variables in the _root.scss file for the scaled utilities.
• Introduce all the new utilities (fixed and scaled).
• Introduce all new design tokens in tokens/_raw.scss and in tokens/_semantic.scss
• Checked all the new provided options.
• Quite complete migration guides.
• Introduce the documentation of sizing.md and spacing.md utilities.
• Introducing the tests of the spacings.

To be done after the PR is merged

• .

Motivation & Context

Types of change

• New feature (non-breaking change which adds functionality)

Live previews

• https://deploy-preview-2754--boosted.netlify.app/docs/layout/gutters
• https://deploy-preview-2754--boosted.netlify.app/docs/utilities/sizing
• https://deploy-preview-2754--boosted.netlify.app/docs/utilities/spacing
• https://deploy-preview-2754--boosted.netlify.app/docs/migration
• https://deploy-preview-2754--boosted.netlify.app/docs/migration-from-boosted

[netlify]

✅ Deploy Preview for boosted ready!

Name	Link
🔨 Latest commit	7c95b64
🔍 Latest deploy log	https://app.netlify.com/sites/boosted/deploys/67335e884cc8d7000758886f
😎 Deploy Preview	https://deploy-preview-2754--boosted.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[julien-deramond]

Please don't take this comment for granted and don't modify the PR. This is a complex one to review, so I'll put some comments here and there with my 2 cents. Hopefully, in the end, with your rules, some comments, and the designers inputs, we might create a cool mapping table for usage, but also for migrations.

Here, the previous value is 60px. So I would rather use as a real project "huge" (56px) or "jumbo" (64px) to have the same rendering.
The previous rule is that the values doubled between 0,1, 2, 3, 4, 5 → 0, 5px, 10px, 20px, 30px, 60px.
If we keep this rule I would rather use for equivalent usages and easier migration none, shortest, shorter, medium, taller, jumbo instead of the current none, shortest, shorter, medium, tall, spacious.

[louismaximepiton]

The rule that was set as follows;
0: none,
1: shortest, (4px)
2: short, (12px)
3: tall, (24px)
4: tallest, (40px)
5: huge (56px)

[julien-deramond]

Should we introduce an easy way to get all utilities in px and in rem. I mean not only a function px-to-rem but an option like $enable-rem-utilities that make a dupe of each utility but in rem? IMO, we should but it will probably make the bundle size raise a lot. Not done yet.

In most cases, while building a page with the layouts, it makes more sense most of the time to use pixels for paddings and margins as we don't want them to change while zooming out. In the components, we might use both depending on the use cases, but we're not supposed to use utilities to build components.
So I'd say, we should be fine with utilities in pixels by default, and having them in rem might be something done on the projects' side. We could start without this $enable-rem-utilities and wait for projects' feedback.

[julien-deramond]

What to do with the $spacer and $spacers variables? IMO, $spacer should take the value $ouds-dimension-base * 5. Not done yet. It's the base of many calculations inside Boosted/Bootstrap. Do we replace them with our $ouds-dimension-base and $ouds-dimension-space-fixed? IMO, we should keep the Bootstrap ones.

IMO, $spacer(s) should be defined from the $ouds-dimension-* Sass variables. And $spacers values should correspond to the migration matching table from Boosted. For instance, if we consider that p-1 must be p-shortest, then $spacers[1] should be defined with $ouds-space-fixed-shortest, etc.
Then, for all OUDS Web utilities, components, layouts, etc. we should use values depending on $ouds-space or $ouds-dimension semantic variables. In the end, $spacer(s) would be used only to define the Bootstrap compatibility utilities, and be ther for plugins and libraries depending on that.

[julien-deramond]

Do we keep the same size utilities .w-100, etc.. ? IMO, we should since the tokens don't look like they are done for it.

It concerns only icons and typos, so let's postpone it.