Tag text unreadable

[MGChecker]

Gitea Version

1.16.1

Operating System

Linux

Browser Version

Firefox

Can you reproduce the bug on the Gitea demo site?

Yes

Description

After the tag design change done in 1.16.x, many tag texts are rendered in black which were rendered in white before. For some colors, for example #207de5, this leads to text which is barely readable at best, especially if the tag is seen on white background.

In my opinion, an (at least) partial rollback of this text color change would be helpful.

Screenshots

[wxiaoguang]

It should have been fixed in 1.19/1.20

[MGChecker]

In 1.19.1, there is no improvement of the situation.

[wxiaoguang]

The improved code is here, do you have ideas about your case?

gitea/modules/templates/helper.go

Lines 543 to 568 in eea23bb

	if r, g, b, err := label.ColorRGB(); err == nil {
	// Make scope and item background colors slightly darker and lighter respectively.
	// More contrast needed with higher luminance, empirically tweaked.
	luminance := (0.299*r + 0.587*g + 0.114*b) / 255
	contrast := 0.01 + luminance*0.03
	// Ensure we add the same amount of contrast also near 0 and 1.
	darken := contrast + math.Max(luminance+contrast-1.0, 0.0)
	lighten := contrast + math.Max(contrast-luminance, 0.0)
	// Compute factor to keep RGB values proportional.
	darkenFactor := math.Max(luminance-darken, 0.0) / math.Max(luminance, 1.0/255.0)
	lightenFactor := math.Min(luminance+lighten, 1.0) / math.Max(luminance, 1.0/255.0)
	scopeBytes := []byte{
	uint8(math.Min(math.Round(r*darkenFactor), 255)),
	uint8(math.Min(math.Round(g*darkenFactor), 255)),
	uint8(math.Min(math.Round(b*darkenFactor), 255)),
	}
	itemBytes := []byte{
	uint8(math.Min(math.Round(r*lightenFactor), 255)),
	uint8(math.Min(math.Round(g*lightenFactor), 255)),
	uint8(math.Min(math.Round(b*lightenFactor), 255)),
	}
	itemColor = "#" + hex.EncodeToString(itemBytes)
	scopeColor = "#" + hex.EncodeToString(scopeBytes)
	}

[MGChecker]

To me, this is not really related to scoped labels. It's just about using white text on dark labels more aggresively.

[MGChecker]

I would expect an improvement from a change in

gitea/models/issues/label.go

Line 182 in 58b4143

return brightness < 0.35

increasing this number slightly to 0.4 or something.

[wxiaoguang]

To me, this is not really related to scoped labels. It's just about using white text on dark labels more aggresively.

Yup, it's not really related "scoped label", I mentioned that because the algorithm was changed (improved) again in that PR

[wxiaoguang]

I would expect an improvement from a change in

gitea/models/issues/label.go

Line 182 in 58b4143

return brightness < 0.35

increasing this number slightly to 0.4 or something.

Since it was contributed by #22585 .... @brechtvl do you have some ideas about this issue? I am not color expert 😁

[wxiaoguang]

After #24586 , #207de5 looks good now

https://try.gitea.io/wxiaoguang/test/labels

[brechtvl]

On that same page, this one is still not readable:

But I think this issue can't be fully solved by tweaking the logic to decide between black and white text. For some label color neither of those will be have good contrast. This can be seen playing around with:
https://www.myndex.com/APCA/

Another thing is that the theme background color matters quite a bit for readability, something that's readable with a dark background may not be on a light background. GitHub uses a completely different rendering style in dark themes. To fully solve the problem I think either that is needed, or the label color should be automatically darkened or lightened and not be exactly what the user chose.

[MGChecker]

For me, this seems to be due to the fact that the color of the text is not white, but grey for some reason (only really noticable with white background). The greyness reduces the contrast significantly. Still, generally it is an improvement over the status quo ante.

On dark background, the label is fine.

[wxiaoguang]

The latest code in #24586 is GetLuminance(r, g, b) < 0.453 (quote: " increasing this number slightly to 0.4 or something.")

So I guess this issue as a regression bug report it could be closed? It could have new issues to make detailed plans for the further improvements, to make the discussion more focused.

[wxiaoguang]

I think this issue could be closed. Thank you all.