digdir / designsystemet

Designsystemet
https://designsystemet.no
MIT License
81 stars 37 forks source link

Semantic Border-radius tokens #2287

Closed Febakke closed 1 week ago

Febakke commented 2 months ago
### Tasks
- [ ] https://github.com/digdir/designsystemet/issues/2476

We want better semantic border-radius tokens. Example: checkbox should always be square

Started doing some research on how we can solve this is Figma. Token Studio supports a set of math functions their might be a way to set max value to a token. This would help us in the short term. I have reach out to the Token Studio Slack for suggestions.

If we develop our own plug in, the logic to handle this must be solved in that plug in.

Success

We are able to use a min/max function in Token Studio and can create tokens with a max border radius value.

This means we can set a token on border radius for checkboxes that will have their square shape even though you set the base value very high.

Heres an illustration of what we want to create: image 2

Theming support

Semantic names

We want to give you a size and what max border-radius you will get from this token. So the suggested token name will be lg-12 If your base border-radius goes beyond 12, this token will be 12.

Image

Ful list of suggested tokens

Image

As you can see there is also a static full token. This will alway give you a circle. Made for components that should always have a circular form.

Tasks

eirikbacker commented 2 months ago

Great work @Febakke ! 🌟

  • Im still not sure about semantic naming. Is it enough with sm- md- lg or should the behavior be built into the name. Something like sm-up-to-4 But its not pretty πŸ˜„

And, so we need this many variations? I guess Input, Checkbox, Card, Button might have different needs, but then again - Mattilsynet will for instance want to have full on primary buttons only, but not on other buttons or inputs, as well as larger border radius only bottom right on cards πŸ˜… If providing multiple versions is to "please all needs", I think we are making it too complex as we will never cover all needs, and consumers will therefore probably make wrapper-logic anyway. For those organizations who do not have lots of resources and want to consume without any wrapping logic - maybe a simpler set is sufficient for them anyway?

This is indeed hard to answer, but I think it is nice to discuss as it touches the core of what Designsystemet should be, and it affects complexity and therefore both amount of work needed to create, maintain, and learning curve for consumers :)

Febakke commented 2 months ago

The max is set into the token so it wont go over no matter what you put as base radius. I agree sm and so on would be best. But if we could figure out a way to have the behavior as a part of the name, it would be better πŸ˜„

I think maybe a healthy next step is to define what we actually need.

Example:

full is always set to 9999 no matter what base radius is set to. Used for shapes that always should be circular. (radio is an example) extra-large - follow baseAlways the same as the base radius up to full Used for components that can be circular and have hard edges. For example input-fields and buttons. Large Max 24px radius. Used for panels modals and elements that can have a softer edge, but you do not want them to break by having to much border radius. medium Max 16px radius. Same as Large but for smaller components. (Popover for example) small - Square Have a low max radius. This is for components that should always have a clear square form. (Checkboxes)

@Thuneer What grades fo border radius am I missing? Ill do some research on what we actually use on our components today?

Febakke commented 2 months ago

The issue is not to please all needs, but to handle the expected behavior in the tokens instead of handling max border radius on components. The reason why we want max border radius is because we want users to be able to set a base border radius and change all components based on that. Its a simple way of changing the look of components to fit their design.

And I want to handle this is tokens because

That said... It wont handle all cases and it might be overly complex. As you said it might be easier to just have a static scale. We need to have a discussion if we want to include this or not before moving forward 😎

mimarz commented 2 months ago

This will affect both tokens build and create scripts in the CLI.

Febakke commented 2 months ago

Meeting with @mimarz

Meeting notes

Design changes

Changes in code

mrosvik commented 2 months ago

Example from radix: https://www.radix-ui.com/themes/playground

Febakke commented 2 months ago

Meeting with @mrosvik

We tested out the new border-radius tokens on our components and started documenting how they could be used.

Token Use cases Explanation
sm (max 4) Checkbox and maybe tag This token are made for components that need to keep a square shape
md (max 12) Text area Used for smaller surfaces. Could be used for button and textarea
lg (Max 24) Modal, card, accordion, alert, popover Bigger surfaces that can handle more border radius, but you dont want them to become circular
Dynamic (Max 9999) Button, textfield, search Components that can have any border radius and will follow the base radius from 0 to 9999
Full (Always 9999) Radio, helptext Mostly used by developers today, (round avatar)

To do

Edit Removed two steps in the scale. We do not have that many use cases.

Febakke commented 1 month ago

Update

I have tried to illustrate how this will work in a Figma prototype. Just change the border radius in the top left corner and see how it changes the components.

Smaller scale

We will use the scale in my last comment. This will only have 3 steps that have max values. These tokens have specific use cases. We also renamed the largest token dynamic this will follow the base value you set for your border radius. There is also a full token that will always be 9999

More controll

The max values used by sm, md, and lg is calculated based on a scale token. You can change this token if you want more control. We will set a default value that we believe will work in most cases.

It works by multiplying the scale token on a number set in the token. For example: base = 9999 scale = 4 border-radius-sm = min(scale * 1, base) border-radius-sm = 4

NB: We are still working on what the numbers we will multiply the scale token are.

"My design does not work with this border-radius system"

Well, i am sorry to hear that. But all is not lost. Its a little more work, but you can manually edit the border-radius values to whatever you need. And if you have a special case. For example everything except button has 0 border-radius you need change the token used by the component in both Figma and React. This will be documented when it is finished. As a sidenote if we expand into component tokens in the future, this might be easier to change for designers and be better connected to the components in code. But as for now it will be a more manual job.

mimarz commented 1 week ago

This feature has been implemented, further adjustments will be done in separate issues. #2681 #2455