Broken gradient effect when hovering the thread summary

[janogarcia]

Steps to reproduce

Hover over a thread summary in the main timeline.

Outcome

The gradient effect underneath the caret icon is not rendered correctly.

Operating system

macOS Monterey

Browser information

Safari 15.3 (17612.4.9.1.8)

URL for webapp

develop.element.io

Application version

Element version: b79133c-react-371ccd78580f-js-b8321290f823 Olm version: 3.2.8

Homeserver

No response

Will you send logs?

No

[soumyag123]

@janogarcia can you please assign me this issue?

[germain-gg]

@soumyag123 this issue is not really up for grabs as threads is a project under active development

[kittykat]

@soumyag123 you may want to have a look at some of the issues labelled with "Help Wanted". Some of those are also marked as "good first issue", which means they're more suitable for newcomers to the project.

[t3chguy]

Cannot reproduce, tried in Safari 15.4

[janogarcia]

@t3chguy It can be fixed for Safari 15.3 and below by changing the declaration for the background gradient colors.

Apparently, there's a bug that is triggered when transitioning from a colored stop to a purely transparent one, just as we're currently doing:

linear-gradient(270deg, #F4F6FA 52.6%, transparent 100%)

To fix it change the color definitions to HSLa or RGBa.

---

Tested it with:

linear-gradient(270deg, hsla(220, 37%, 97% , 1) 50%, hsla(220, 37%, 97% , 0) 100%)
linear-gradient(270deg, rgba(244, 246, 250, 1) 50%, rgba(244, 246, 250, 0) 100%)

[t3chguy]

@janogarcia had to use rgba(255, 255, 255, 0) otherwise it'd require introducing a new variable - $system-transparent which serves no purpose other than to work around a bug in Safari 15.3 - from a quick stackoverflow search this should still work

Is the move from 52.6% to 50% intentional?

[janogarcia]

@t3chguy I'd recommend, if possible, using Sass change-color() function as a way of returning the expected color for this type of gradients in a systematic way that still doesn't require defining a new variable (rather than fading it to a different hue).

background: change-color($color, $alpha: 0);

As for the updated percentage value, I sort of rounded it / cleaned it up, as the 52.6% value came directly from Figma, where it's hard to have precisely positioned gradients without using plugins. It was meant to be 50% in practice.

[t3chguy]

@janogarcia

1. We don't use SASS but instead postCSS
2. We have to do this operation at runtime (not build time) due to how custom (JSON) themes work using css variables --system
3. Runtime CSS can do this with https://www.w3.org/TR/css-color-5/ but browsers do not support this yet

[janogarcia]

I'll need to learn more about our CSS and runtime theming setup.

[janogarcia]

I guess the hardcoded white transparent value you proposed using in the PR won't work with custom theming either.