Skip to main content

Hello.

I highly appreciate the new feature allowing us to use the text-decoration simply with the keyboard shortcuts.


However, I’ve noticed that when applying text-decoration using shortcuts like cmd+b or cmd+u within components, the styling does not save properly. For example, if I bold the label in a button using cmd+b and later try use it and change the label text property, the bold formatting is removed. The same issue occurs with underline on hover effects - e.g. when I underline text for hover states using cmd+u, the underline is lost.


While it was a relief that I don’t longer have to create all possible text-decoration variations as the separate text styles in my design system (like: “Body/Bold, Body/Bold Underline” etc.), now I feel like I should go back to this more time-consuming approach.


Please consider this feedback or let me know if there’s a flaw in my workflow.

I’m running into this issue too. Did you ever find a solution to this, ​@Michal_Sikora?


I’m running into this issue too. Did you ever find a solution to this, ​@Michal_Sikora?

 

No, unfortunately, I didn’t


Same issue. If there is a text decoration applied to a component - e.g. Link, the decoration dissapears either already when you change the text in an instance of a link, or is shown in Design mode, but dissapears in Prototype mode. 

Any prognosis on when the bug will be fixed?


The only solution I’ve found is to create the underline using a shape or frame and then turning it off/on as needed in your variants. Unfortunately this is a bandaid solution and doesn’t have nice features the native underline does like skipping descenders for example.


Just ran into this today via a bug report from one of our design system consumers. We bold the field labels on all our form field components.

If the user changes the field label text using the text property (right panel), it will stay bold as long as they don’t change the component to a different state (ex: from ‘default’ state to ‘focus’… or any other state). If they do, which is common, it unbolds the text. Highly frustrating.

On the other hand, if they edit the field label text by directly selecting the text on the component itself, the bold stays put when/if they change to a different state.

So, this definitely seems to have something to do with the actual text property… at least in my case.

Until Figma fixes this, we’re forced to create an actual text style (token) specifically for field labels as a workaround which is something we wanted to avoid.


Okay, so I think this bug has been fixed, and Figma didn’t bother to announce it.

Today, I was about to modify all our DS components with a workaround to stop this from happening and, low and behold, the problem was gone.

I began asking other designers at the company to try and reproduce the bug, and they no longer could.

So, sometime between my previous post (above) and now, this bug has disappeared for me and everyone else in my company. Now, people can change the text label property in all our components, change the component’s state, etc. and the bolding stays put.

Can someone please confirm?


Reply