Kaizen Component Library is completely unopinionated about link/anchor styles, but it probably should be

Every time you need to render a humble link/anchor in a paragraph or otherwise (which is often), you need to look up the Kaizen docs and Kaizen Design Kit (figma) for the latest design rules and either:

• write some custom scss
• or set a global style on the a element within your app

The Kaizen site itself has a custom rule for a: https://github.com/cultureamp/kaizen-design-system/blob/master/site/src/styles/global.scss#L31

This seems like a basic fundamental thing that Kaizen the codebase should provide to consumers in a way that requires little effort. I think a reason we’ve shied away from this is that there are so many different ways we could do it:

• The Paragraph or Heading components could automatically style children a elements (also suggested in https://github.com/cultureamp/kaizen-design-system/issues/908, a closely related issue)
• provide a base style sheet with a global rule for the a tag that all Kaizen consumers should include in their build step
• provide a “link” component (eg: <Link ...> or <Anchor ..>, <A ...>, <Hyperlink ...> or whatever we wanted to call it)
• provide at least link tokens for colour and underline style in @kaizen/design-tokens (which would make it a “decision token”, something we’ve held off on doing, because the problem space for decision tokens is vast compared to the problem space of option tokens)
• any other suggestions?

It’s worth pointing out a couple of things from the Kaizen docs and Kit:

• There are two different link styles (underlined or not) depending on whether the link is in a paragraph or standalone: https://www.figma.com/file/eZKEE5kXbEMY3lx84oz8iN/❤️-UI-Kit%3A-Heart?node-id=1929%3A1289
• links that open in a new tab must include an “opens in new tab” tooltip: https://cultureamp.design/guidelines/link-vs-button/

[ActuallyACat]

From where I stand, both the Link component and the default styling of anchor tags within Paragraph components seem like the best approach. Bonus is this makes the design rule of underline text within paragraphs quite clear. We’d need suitable guidance for both approaches though - I can see this as being a gotcha.

I’m very hesitant to add any (more) “decision token” type tokens to design tokens without rethinking tokens… The current setup is optimised for option tokens and it’s missing the ability for token inheritance. E.g. border color (decision token) being derived from ash-300 (option token).

[mbylstra]

That’s a really good consideration about translations. I’ve noticed linguiJS is our least “contained” technology on our list after having issues with i18next and react-intl: https://cultureamp.atlassian.net/wiki/spaces/TV/pages/933429612/Front+End+Technology+List. The current most favored approach seems to be linguiJS (I’m not sure if it’s capable of passing custom components). I wonder if we could do both: provide a <Link> component (favored) but also have the Paragraph style children a tags, for consumers where translation is an issue (I believe react-intl is being used in our product, even though it’s “contained”).

So, you could do either <Paragraph><Link href="xxxx">a link</Link></Paragraph> or <Paragraph><a href="xxxx">a link</link>. I’m not sure if it would be confusing having two different ways to do the same thing.

I also think there’d also be a big benefit in providing the “opens in new tab” tooltip functionality in a link component which is always a pain to do (and comes up a lot). This could look like <Link href="xxxx" opensInNewTab>a link<Link>