Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Semantic Border-radius tokens #2287

Closed
1 task done
Febakke opened this issue Aug 20, 2024 · 9 comments
Closed
1 task done

Semantic Border-radius tokens #2287

Febakke opened this issue Aug 20, 2024 · 9 comments
Assignees
Labels
☂️ epic Issues ready 🧭 roadmap Used in roadmap

Comments

@Febakke
Copy link
Member

Febakke commented Aug 20, 2024

Tasks

Preview Give feedback
  1. $ tokens cli
    Febakke mimarz
    unekinn

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

  • I moved base radius out of primitives/globals and into themes/theme You can now change between themes and have different border radius.
  • Right now the ceiling is calculated in each theme set. But I think we can move it into semantic/style Less variables to think about.
    • Figma variables do not support calculations. That means we need to have the ceiling to be inside every theme set 🙃
  • 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 😄
  • Expanded up to 3xl(ceiling at 32)
  • How do we handle full border radius. Should the largest token go all the way up to 9999 and do we need a static token that is always 9999

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

  • Build tokens into theme collections
  • Create semantic names
  • Expand with more sizes (up too 32)
  • Discuss with developers if this is something we want to implement
    If yes
  • Define and document rules for tokens. (What are the usecases for each one)
  • Update Figma components to use correct new tokens
@Febakke Febakke converted this from a draft issue Aug 20, 2024
@Febakke Febakke self-assigned this Aug 20, 2024
@Febakke Febakke changed the title Border-radius Semantic Border-radius tokens Aug 20, 2024
@eirikbacker
Copy link
Contributor

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 😄
  • Not sure, but my initial thought is that 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 :)

@Febakke
Copy link
Member Author

Febakke commented Aug 26, 2024

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
Copy link
Member Author

Febakke commented Aug 26, 2024

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

  • We want to mirror this is Figma
  • We want to able to create a system for how this is handled instead of setting max values on components.

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
Copy link
Collaborator

mimarz commented Aug 27, 2024

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

@Febakke
Copy link
Member Author

Febakke commented Aug 29, 2024

Meeting with @mimarz

Meeting notes

  • Use same token names as before in the semantic set. This will minimize trouble when updating the file in Figma
    • Documentation and descriptions can help explain use cases for the different tokens
    • Description will also be displayed as a comment on the CSS variable

Design changes

  • Me and @Thunear need to test if we support all use cases with the proposed tokens
    • Update Figma components with new variables

Changes in code

  • Add option for border radius to token create script
  • Add tokens
  • Update token build script to support min/max calculation
  • Replace current min/max with new CSS variables in CSS package

@mrosvik
Copy link
Member

mrosvik commented Aug 30, 2024

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

@Febakke
Copy link
Member Author

Febakke commented Sep 5, 2024

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

  • Test on all components.

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

@Febakke
Copy link
Member Author

Febakke commented Sep 11, 2024

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
Copy link
Collaborator

mimarz commented Oct 31, 2024

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

@mimarz mimarz closed this as completed Oct 31, 2024
@github-project-automation github-project-automation bot moved this from ☂ Todo Epics to ✅ Done in Team Design System Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
☂️ epic Issues ready 🧭 roadmap Used in roadmap
Projects
Status: No status
Status: ✅ Done
Development

No branches or pull requests

4 participants