Closed Febakke closed 1 week 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 likesm-up-to-4
But its not pretty π
sm
, md
, lg
should be sufficient, but can the max change or is it always 4px
for the first column?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 :)
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 base
Always 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?
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 π
This will affect both tokens build and create scripts in the CLI.
Meeting with @mimarz
Example from radix: https://www.radix-ui.com/themes/playground
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.
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.
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
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.
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.
This feature has been implemented, further adjustments will be done in separate issues. #2681 #2455
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:
Theming support
primitives/globals
and intothemes/theme
You can now change between themes and have different border radius.But I think we can move it intosemantic/style
Less variables to think about.sm
-md
-lg
or should the behavior be built into the name. Something likesm-up-to-4
But its not pretty π3xl
(ceiling at 32)9999
and do we need a static token that is always9999
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.Ful list of suggested tokens
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