chore: link light mode

[deboer-tim]

What does this PR do?

Adds light mode support to Link component, using color defined in design for #7149.

Screenshot / video of UI

No change on dark, looks like design on light - looks awful since I couldn't find a page with a Link that supports light mode, will look much better after #7149 has merged :) :

Screen.Recording.2024-05-14.at.1.42.07.PM.mov

What issues does this PR fix or reference?

Fixes #7215.

How to test this PR?

Manually add preference: "preferences.appearance": "light"

• Tests are covering the bug fix or the new feature

[deboer-tim]

@ekidneyrh I noticed in the design for #7149 that the color for the breadcrumb at the top left was defined, but this is a standalone Link component that is used everywhere we have links - dashboard, forms, deploy to Kube, etc. To support a hover effect on all background colors it currently uses 10% translucent white, so I've defined two colors: link and link-bg. The colors should be fine since the main ones come from #7149, but let me know if you prefer different names, e.g. maybe should be link-hover-bg?

[ekidneyrh]

@ekidneyrh I noticed in the design for #7149 that the color for the breadcrumb at the top left was defined, but this is a standalone Link component that is used everywhere we have links - dashboard, forms, deploy to Kube, etc. To support a hover effect on all background colors it currently uses 10% translucent white, so I've defined two colors: link and link-bg. The colors should be fine since the main ones come from #7149, but let me know if you prefer different names, e.g. maybe should be link-hover-bg?

That sounds good to me! I'm not too picky on the names.

[feloy]

To support a hover effect on all background colors it currently uses 10% translucent white, so I've defined two colors: link and link-bg

It would be nice to use this opacity technique in other places for hover, and also for disabled components and text emphasis (some examples here: https://m2.material.io/design/color/text-legibility.html). That would help reduce the number of colors in the palettes

[deboer-tim]

To support a hover effect on all background colors it currently uses 10% translucent white, so I've defined two colors: link and link-bg

It would be nice to use this opacity technique in other places for hover, and also for disabled components and text emphasis (some examples here: https://m2.material.io/design/color/text-legibility.html). That would help reduce the number of colors in the palettes

Agreed. Ideally I'd like to use RGBA values but I can't find any way of cleanly specifying them in the registry or how we use them/Tailwind. I checked and the following does work since colors are just strings, but it feels a bit ugly. Am I overreacting, or can you think of a better way to do this?

this.registerColor(`${link}-hover-bg-opacity`, {
    dark: '10',
    light: '10',
});

[feloy]

To support a hover effect on all background colors it currently uses 10% translucent white, so I've defined two colors: link and link-bg

It would be nice to use this opacity technique in other places for hover, and also for disabled components and text emphasis (some examples here: https://m2.material.io/design/color/text-legibility.html). That would help reduce the number of colors in the palettes

Agreed. Ideally I'd like to use RGBA values but I can't find any way of cleanly specifying them in the registry or how we use them/Tailwind. I checked and the following does work since colors are just strings, but it feels a bit ugly. Am I overreacting, or can you think of a better way to do this?

this.registerColor(`${link}-hover-bg-opacity`, {
    dark: '10',
    light: '10',
});

It has to be checked for the difference cases, but it seems to me the opacity would always be the same for dark and light modes (and even the same if one changes the theme colors). I would simply put a class="opacity-10" in the template.

This way, we could use, for example:

class="text-[var(--pd-link)] opacity-75 hover:opacity-95 disabled:opacity-20"

[benoitf]

and for some components, it relies on accent-color
https://tailwindcss.com/docs/accent-color

[deboer-tim]

I realized the background hover opacity (bg-opacity-10) wasn't working correctly, and the delay looking for a solution required a rebase to pick up Link move to UI package and changes to the color registry.

The only path I've been able to find to get the background hover opacity is by defining this one color as a Tailwind color using the rgb(from var(...)) syntax, which then allows us to use the new Tailwind opacity modifier (/10) instead.

https://tailwindcss.com/docs/upgrade-guide#new-opacity-modifier-syntax

@benoitf or @feloy would appreciate a quick comment to confirm this path is acceptable or if you can think of others. IMHO this path isn't too bad b/c we'll only have to define a couple colors this way.

[benoitf]

I would not add the color in tailwind as it won't be shared properly with other projects

[deboer-tim]

Any other ideas to set a hover bg opacity in Link? I haven't found any other path that allows you to use Tailwind's /10 syntax, and the only other working path is putting dark: colorPalette.white + '2' directly in the color registry.

[feloy]

Because the bg-opacity-* notation seems deprecated (tailwindlabs/tailwindcss#13703 (comment)), and because the /n notation does not work for now with the use of css var, and to not define a color in the tailwind config which is not accessible to extensions, it seems that the #rgba
(or #rrggbbaa) notation is the best choice for now

    this.registerColor(`${link}-hover-bg`, {
      dark: colorPalette.white + '2',
      light: colorPalette.black + '2',
    });

[deboer-tim]

... it seems that the #rgba (or #rrggbbaa) notation is the best choice for now

Yeah, it does seem to be the simpler option atm, and would allow another theme to change the opacity as necessary. I have repushed the branch with this change.

The closest value to 10% would actually be about hex 1A, but since black/white are three-hex values I tried both 1 (11) and 2 (22). Although it's slightly higher, I went with 2 because it is closer and 1 was not enough contrast for smaller fonts.