I'd appreciate feedback about the inconsistency I'm discussing here please:

https://www.tenforums.com/general-support/186386-font-colour-puzzle.html#post2312247

Terry

Terry Pinnell wrote:

> I'd appreciate feedback about the inconsistency I'm discussing here please:
>
> https://www.tenforums.com/general-support/186386-font-colour-puzzle.html#post2312247

What's the URL of the site (wokwi?) wit the issue?

Andy Burns <usenet@andyburns.uk> wrote:

> Terry Pinnell wrote:
>
>> I'd appreciate feedback about the inconsistency I'm discussing here
>> please:
>>
>> https://www.tenforums.com/general-support/186386-font-colour-puzzle.html#post2312247
>
> What's the URL of the site (wokwi?) wit the issue?

Yeah, he points to a web forum whose first post to open that discussion
has him pointing elsewhere again, which is:

https://github.com/wokwi/wokwi-features/issues/206

The issue is the Github project page uses what looks like gray on purple
for the text of a label/tag object in the web page. Apparently
discussions there can get labeled, like you can assign categories to
e-mails.

I don't go there, so I don't know how many labels they have that can be
assigned to a thread. Maybe they ran out of background colors, so
purple was what was left.

Don't know why he is bothering us here. We cannot change the HTML code
for the web doc that the web site delivers to visitors. When some site,
or even an e-mail, uses a poor choice of coloring making some text very
hard or impossible to read (some even have the foreground and background
colors the same), I highlight the text which often provide sufficient
contrast to make the text legible. Drag the mouse over the text to
highlight it. Changing web browser colors is of no use because it
wasn't the web browser's choice of coloring. The colors are set by
attributes in the HTML tags or CSS styling coded in the web doc stored
up on the server. Andy could send a message to the forum's moderator or
admin to get the colors changed. If the coloring is the choice of the
webhosting site (Github), unlikely Andy can complain to them, but him
complaining to the project owner, admin, or moderator can have that
customer of Github get Github to change coloring to improve contrast.

I'm not sure it is even a web browser issue. His URL here points to a
Github forum discussion which shows a screenshot from who knows where.
I don't know what is wokwi, and maybe it's that program he is using to
view wherever the screenshot was from. Maybe the screenshot is a Github
discussion on whatever is the wokwi project at Github.

Looks like the OP is using Google's Chrome web browser. Since the URL
to the wokwi disussion was not provided (I only scanned through the
Github discussion since I'm crunched for time right now), I cannot go
look at it using Firefox, my choice of web browser, to possibly
right-click on the object to view the HTML code for the element in that
web doc. In Firefox, I can override whatever fonts and coloring a web
doc uses by specifying what I want used; however, the option "Allow
pages to choose their own fonts, instead of your selections above" is
enabled, so the fonts delivered by the site, or those from a 3rd party
font resource (e.g., FontAwesome, Google Fonts), get used to render the
web doc. For colors, in Firefox, I can specify some coloring along with
Firefox trying to decide under which conditions to use them as overrides
(Always, Only with High Contrast Themes, Never), or even whether to use
the color specified in Firefox or use the system-specified colors.
Someone else would have to dig into Google Chrome to see what font and
coloring options are available in that web browser, how its fonts and
color overrides are defined in that web browser, and if it is configured
to use system defined colors (and what system colors or themes the OP is
using in his OS).

I don't let my web browsers use system colors. While some colors are
defined in the web browser, they're generic, like color for background
and text color, and links that the web browser thinks are URL
hyperlinks; however, those colors don't override the ones defined within
the web doc. For fonts, I have some selected, but allow web docs to
specify their own (which may try to use system fonts, fonts downloaded
from the site, or resourced and downloaded from a 3rd party font
foundary EXCEPT I have uBlock Origin configured to block remote fonts).

Until the site changes their coloring choices, try highlighting the text
to see if highlight mode gives better contrast.

"Terry Pinnell" <me@somewhere.invalid> wrote

| I'd appreciate feedback about the inconsistency I'm discussing here
please:
| |
https://www.tenforums.com/general-support/186386-font-colour-puzzle.html#post2312247
|

Same question as Andy. I can't seem to find any
github pages with a "Labels" category showing
"Enhancements" and "Open for Vote". Personally I
find github an especially bad website. Few explanations.
Terrible webpage code. But I also don't find those
words in the source code at your link. So I can't imagine
where you took that screenshot. Why didn't you just
link to that page?

On 10/15/2021 2:05 PM, Mayayana wrote:
> "Terry Pinnell" <me@somewhere.invalid> wrote
>
> | I'd appreciate feedback about the inconsistency I'm discussing here
> please:
> |
> |
> https://www.tenforums.com/general-support/186386-font-colour-puzzle.html#post2312247
> |
>
> Same question as Andy. I can't seem to find any
> github pages with a "Labels" category showing
> "Enhancements" and "Open for Vote". Personally I
> find github an especially bad website. Few explanations.
> Terrible webpage code. But I also don't find those
> words in the source code at your link. So I can't imagine
> where you took that screenshot. Why didn't you just
> link to that page?

"Members" or "Signed In peeps" see different decorations
than "mere visitors" like us ?

Maybe the usage of a dark theme in Windows, causes inversion
of the cited text ? Think about what kind of people would
normally hang there, and how their screens would be configured.

It could even be the web developer did this on purpose because
he happened to be a dark screen person.

Paul

"Paul" <nospam@needed.invalid> wrote

| "Members" or "Signed In peeps" see different decorations
| than "mere visitors" like us ?
| | Maybe the usage of a dark theme in Windows, causes inversion
| of the cited text ? Think about what kind of people would
| normally hang there, and how their screens would be configured.
| | It could even be the web developer did this on purpose because
| he happened to be a dark screen person.
|

Yes. But I find these issues interesting, as someone who
dabbles in both graphic arts and web design. It's also true
that peoples' eyes vary, OSs vary, graphic hardware varies,
etc. Remember the websafe colors? But they weren't really
websafe. It's deflating to work carefully on choosing just the
right wine tone with cream, only to find your friend sees
magenta and white, or black and tan. But it is all relative
that way.

Remember the case with the dress? I think some people
saw white and gold while others saw blue and black. If I
remember correctly that was down to vision differences,
not tech issues.

I think one of the people in the discussion talked about
a blue button. I saw bright purple. But I was curious to see
the actual code behind the difference. It could also, possibly,
be related to some remote CSS code being blocked for some
reason.

On Fri, 15 Oct 2021 at 14:56:38, Mayayana <mayayana@invalid.nospam>
wrote (my responses usually follow points raised):
[]
> Remember the case with the dress? I think some people
>saw white and gold while others saw blue and black. If I
>remember correctly that was down to vision differences,
>not tech issues.
>
> I think one of the people in the discussion talked about
>a blue button. I saw bright purple. But I was curious to see
>the actual code behind the difference. It could also, possibly,
>be related to some remote CSS code being blocked for some
>reason.
>
>
Have a look at "no red" and "no blue" here
https://twitter.com/G6JPG_/status/1447880762360016896 (scroll down and
look at no red first, no blue was just me rotating the wheel;
interestingly "no green" didn't work, for me anyway).

(No, I'm not making any point/response to what you say; I just thought
they were fascinating, and related to some extent to the subject of how
we perceive colo[u]r.)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"quidquid latine dictum sit, altum viditur". ("Anything is more impressive if
you say it in Latin")

"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote

| Have a look at "no red" and "no blue" here
| https://twitter.com/G6JPG_/status/1447880762360016896 (scroll down and
| look at no red first, no blue was just me rotating the wheel;
| interestingly "no green" didn't work, for me anyway).
| Sounds interesting, but I block Twitter, Facebook, etc in my HOSTS
file. Too many sites link to them.

In article <skcs81$qd$1@dont-email.me>, Mayayana
<mayayana@invalid.nospam> wrote:

> but I block Twitter, Facebook, etc in my HOSTS
> file. Too many sites link to them.

that's far many to manually manage it in a hosts file. facebook alone
has more than 2000 entries.

On Fri, 15 Oct 2021 18:26:41 -0400, nospam <nospam@nospam.invalid> wrote:

>In article <skcs81$qd$1@dont-email.me>, Mayayana
><mayayana@invalid.nospam> wrote:
>
>> but I block Twitter, Facebook, etc in my HOSTS
>> file. Too many sites link to them.
>
>that's far many to manually manage it in a hosts file. facebook alone
>has more than 2000 entries.

I believe he uses an app that supports wildcards.

"Char Jackson" <none@none.invalid> wrote

| >that's far many to manually manage it in a hosts file. facebook alone
| >has more than 2000 entries.
| | I believe he uses an app that supports wildcards.
|

Yes. Unbound. Even with wildcards I've got maybe 20
entries for Google and 10 for Facebook.

On Fri, 15 Oct 2021 13:49:21 +0100, Terry Pinnell wrote:

> I'd appreciate feedback about the inconsistency I'm discussing here please:
>
> https://www.tenforums.com/general-support/186386-font-colour-puzzle.html#post2312247
>
> Terry

My first comment is, Terry wants to make people do a lot of running
around.

* I click on Terry's link above.
* Then I have to scroll up and click on another link to see the
*alleged* issue.
* And when I get there, I see Terry's screen-shot image of the web
page but still no link to the actual web page itself to compare
for the requested feedback.

For other readers who don't want the run-around, the actual web page
with the *alleged* issue is here:
<https://github.com/wokwi/wokwi-features/issues/203>

When I go to the actual web page, the "open for vote" is a perfectly
readable white on dark blue in the current versions of Firefox, Chrome,
and Edge. Same as in urish's screen-shot.

--
Kind regards
Ralph

How To Ask Questions The Smart Way: http://www.catb.org/~esr/faqs/smart-questions.html#before

Ralph Fox <-rf-nz-@-.invalid> wrote:

> For other readers who don't want the run-around, the actual web page
> with the *alleged* issue is here:
> <https://github.com/wokwi/wokwi-features/issues/203>
>
> When I go to the actual web page, the "open for vote" is a perfectly
> readable white on dark blue in the current versions of Firefox, Chrome,
> and Edge. Same as in urish's screen-shot.

When I visit that URL in Firefox, right-click on the "Open for Vote"
element, and select Inspect, the Web Dev Tools pane opens with that
element highlighted. I see in the middle pane for styles that this page
has hundreds of attributes defined. Seem instead of using standard
colors (by name), they instead define dozens and dozens of colors using
6-digit hex codes. The <A> anchor tag for the hyperlink for this
element has 6 styles listed (I didn't bother to search for what each
style defines).

When I view that page in Firefox, the contrast is better than the
screenshot shown by the OP, plus the text looks bolded. The "Open for
Vote" element looks like bluish white text on a purplish background
(close to Northwestern purple or Spanish violet as shown at
https://www.colorsexplained.com/shades-of-purple-color-names/). That's
the best match to what I saw visually. Looking at the HTML code is like
looking at a Wordpress site: lots of garbage styles, because they're
defined but not used. I also loaded that page in Edge Chromium, and saw
the same as what I saw in Firefox. So the element's text was very
readable in both web browsers. The OP said he tested in Google Chrome,
Edge (but no idea if EdgeHTML or Chromium for the engine), and Waterfox.
Don't know if he doesn't have Firefox.

I guess next is to see what colors are defined in Google Chrome, and if
the web browser is used for coloring, if he used system colors, or what
theme he is using in his OS. With so many web browsers showing the same
lack of contrast to the OP, and if he tests Firefox to get the same bad
contrast, looks like colors are screwed up in his OS or his monitor.

I'm using a Synced Theme, though I thought I was using My Theme which
was me saving the tweaks to a theme save name. That's just because the
option is enabled to sync settings across devices, so My Theme became
Synced Theme, and are saved as separate themes. I have lots of tweaks
to my OS theme, so I'm not bothering to list them all. The OP might be
using a standard theme, but perhaps not a default one. I didn't bother
to test using High Contrast which, for example, could be a difference in
the OP's theme. I also have color filters /disabled/ in my theme. The
standard ones are: Inverted, grayscale, and grayscale inverted.
However, for the color-blind users, they can pick colors off a color
wheel to select what they see best.

Could be the OP's monitor. Mine has 5 different modes, like Gaming,
Theatre, and so on, and it also also changing the hue for the screen
(maybe that's also for color-blind users, or in trying to adjust the
monitor to show true colors).

On Sat, 16 Oct 2021 01:27:42 -0500, VanguardLH wrote:

> Ralph Fox <-rf-nz-@-.invalid> wrote:
>
>> For other readers who don't want the run-around, the actual web page
>> with the *alleged* issue is here:
>> <https://github.com/wokwi/wokwi-features/issues/203>
>>
>> When I go to the actual web page, the "open for vote" is a perfectly
>> readable white on dark blue in the current versions of Firefox, Chrome,
>> and Edge. Same as in urish's screen-shot.
>
> When I visit that URL in Firefox, right-click on the "Open for Vote"
> element, and select Inspect, the Web Dev Tools pane opens with that
> element highlighted. I see in the middle pane for styles that this page
> has hundreds of attributes defined. Seem instead of using standard
> colors (by name), they instead define dozens and dozens of colors using
> 6-digit hex codes. The <A> anchor tag for the hyperlink for this
> element has 6 styles listed (I didn't bother to search for what each
> style defines).

The text and background colours for the 'open for vote' are *not*
defined using *hex* codes. They use do use CSS variables [1] though.

Both the 'enhancement' and 'open for vote' buttons share this CSS
for the background colour:

background: rgb(var(--label-r), var(--label-g), var(--label-b));

Where these two buttons differ is in the values of the CSS variables
--label-r, --label-g, and --label-b. The 'open for vote' button uses
the *decimal* values below for --label-r, --label-g, and --label-b.

--label-r: 83;
--label-g: 25;
--label-b: 231;

Both the 'enhancement' and 'open for vote' buttons share this CSS
for the text colour:

color: hsl(0, 0%, calc(var(--lightness-switch) * 100%));

and these CSS variables:

--lightness-switch: max(0, min(calc((var(--perceived-lightness) - var(--lightness-threshold)) * -1000), 1));
--perceived-lightness: calc( ((var(--label-r) * 0.2126) + (var(--label-g) * 0.7152) + (var(--label-b) * 0.0722)) / 255 );
--lightness-threshold: 0.453;

Where these two buttons differ is in the values of the CSS variables
--label-r, --label-g, and --label-b used in the calculation of the
CSS variable --perceived-lightness. This calculation is what lets
the text stand out against the background.

When I view the page in SeaMonkey 2.49.5, the text on the 'open for vote'
button is grey and does not stand out. SeaMonkey uses an older version of
the Gecko rendering engine and that older version does not properly handle
all of the CSS calculations for the text colour.

___
REFERENCES

[1] CSS variables
<https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties>

--
Kind regards
Ralph

ζητεῖτε καὶ εὑρήσετε

On 10/16/2021 1:16 AM, Ralph Fox wrote:
> On Fri, 15 Oct 2021 13:49:21 +0100, Terry Pinnell wrote:
>
>> I'd appreciate feedback about the inconsistency I'm discussing here please:
>>
>> https://www.tenforums.com/general-support/186386-font-colour-puzzle.html#post2312247
>>
>> Terry
>
>
> My first comment is, Terry wants to make people do a lot of running
> around.
>
> * I click on Terry's link above.
> * Then I have to scroll up and click on another link to see the
> *alleged* issue.
> * And when I get there, I see Terry's screen-shot image of the web
> page but still no link to the actual web page itself to compare
> for the requested feedback.
>
>
> For other readers who don't want the run-around, the actual web page
> with the *alleged* issue is here:
> <https://github.com/wokwi/wokwi-features/issues/203>
>
>
> When I go to the actual web page, the "open for vote" is a perfectly
> readable white on dark blue in the current versions of Firefox, Chrome,
> and Edge. Same as in urish's screen-shot.

This is what I see with four different browsers.

Only Seamonkey has black text on Purple.

https://i.postimg.cc/j5PDgBcf/four-browser-white-black.gif

And Chrome/Edge have a slightly different font weight.

I haven't updated Seamonkey as much as I should, since
the updating behavior on more recent versions has become
obnoxious. (Didn't switch OSes to test, as I'm down to one computer.)

Seamonkey 2.49.5
Firefox 78.0ESR
Chrome 94.0.4606.81
MSEdge 94.0.992.50
Win7 SP1 x64 (11.6GB used, with the first two browsers still open)

Paul

"VanguardLH" <V@nguard.LH> wrote

| Could be the OP's monitor. Mine has 5 different modes, like Gaming,
| Theatre, and so on, and it also also changing the hue for the screen
| (maybe that's also for color-blind users, or in trying to adjust the
| monitor to show true colors).

I don't understand this system. HSL are just ways to adjust RGB,
but the code is showing all 6 factors as separate color qualifiers.
The color is 83-25-231, #5319E7. At your link, nothing
matches but Han Purple seems to be the closest, though it's
a bit brighter and more saturated. It sounds like your screen
is darkened. Or our eyes are different. Or we're different in
articulating color. I find that people vary a great deal in the
articulation of color, which makes it all the more difficult to know
what they see. If one person says purple and another says blue,
might they just be naming the same color differently? The two
colors you picked are much closer to black; muted. But you may not
make that distinction. Not everyone does. Just as one person might
see "white" while another sees "slightly greenish off-white with
touches of gray and yellow".

This shouldn't depend on browsers. I get the same color in
Paint Shop Pro with that hex code. But it's possible different
browsers are treating the HSL differently. But I see the color as
the as Terry's screenshot image. I see the whole thing the same as
his image. Interestingly, from the discussion at github it sounds
like it could possibly be related to graphics rendering. (On the
other hand, can you believe anything said by someone dumb enough
to use Chrome? :)

I then see gray text in FF 52 and New Moon. I wasn't aware that
CSS had become so complicated. Combining that with automating the
design through software is creating monstrosities. And despite all that
ridiculous complexity the link doesn't even respond to hover.

No usable browser should be confused by CSS for colors. The code on
that page is grotesquely overproduced. And now I see that CSS,
tragically, has become grotesquely overproduced. It used to be so
nice to use. And still is. But with excessive complexity, combined with
machine generated code, it's a mess.

Paul <nospam@needed.invalid> wrote:

>On 10/16/2021 1:16 AM, Ralph Fox wrote:
>> On Fri, 15 Oct 2021 13:49:21 +0100, Terry Pinnell wrote:
>>
>>> I'd appreciate feedback about the inconsistency I'm discussing here please:
>>>
>>> https://www.tenforums.com/general-support/186386-font-colour-puzzle.html#post2312247
>>>
>>> Terry
>>
>>
>> My first comment is, Terry wants to make people do a lot of running
>> around.
>>
>> * I click on Terry's link above.
>> * Then I have to scroll up and click on another link to see the
>> *alleged* issue.
>> * And when I get there, I see Terry's screen-shot image of the web
>> page but still no link to the actual web page itself to compare
>> for the requested feedback.
>>
>>
>> For other readers who don't want the run-around, the actual web page
>> with the *alleged* issue is here:
>> <https://github.com/wokwi/wokwi-features/issues/203>
>>
>>
>> When I go to the actual web page, the "open for vote" is a perfectly
>> readable white on dark blue in the current versions of Firefox, Chrome,
>> and Edge. Same as in urish's screen-shot.
>
>This is what I see with four different browsers.
>
>Only Seamonkey has black text on Purple.
>
> https://i.postimg.cc/j5PDgBcf/four-browser-white-black.gif
>
>And Chrome/Edge have a slightly different font weight.
>
>I haven't updated Seamonkey as much as I should, since
>the updating behavior on more recent versions has become
>obnoxious. (Didn't switch OSes to test, as I'm down to one computer.)
>
>Seamonkey 2.49.5
>Firefox 78.0ESR
>Chrome 94.0.4606.81
>MSEdge 94.0.992.50
>Win7 SP1 x64 (11.6GB used, with the first two browsers still open)
>
> Paul

Sorry I forgot to link the original site. As Ralph said it's
https://github.com/wokwi/wokwi-features/issues/203

I was trying to avoid duplication by discussing at one page:
https://www.tenforums.com/general-support/186386-font-colour-puzzle.html

As you may have seen, subsequent posts there suggested JPG compression and CSS
quirks as two possible causes.

Interestingly both Chrome and Edge now display correctly. Only the old versions
of Waterfox (2021.01) and Firefox (56.02) still display the unreadable text.

Last night WU took me from build 19042.1237 to 1288, so I'll conclude that as
identifying the cause.

Terry

Ralph Fox <-rf-nz-@-.invalid> wrote:

> On Sat, 16 Oct 2021 01:27:42 -0500, VanguardLH wrote:
>
>> Ralph Fox <-rf-nz-@-.invalid> wrote:
>>
>>> For other readers who don't want the run-around, the actual web page
>>> with the *alleged* issue is here:
>>> <https://github.com/wokwi/wokwi-features/issues/203>
>>>
>>> When I go to the actual web page, the "open for vote" is a perfectly
>>> readable white on dark blue in the current versions of Firefox, Chrome,
>>> and Edge. Same as in urish's screen-shot.
>>
>> When I visit that URL in Firefox, right-click on the "Open for Vote"
>> element, and select Inspect, the Web Dev Tools pane opens with that
>> element highlighted. I see in the middle pane for styles that this page
>> has hundreds of attributes defined. Seem instead of using standard
>> colors (by name), they instead define dozens and dozens of colors using
>> 6-digit hex codes. The <A> anchor tag for the hyperlink for this
>> element has 6 styles listed (I didn't bother to search for what each
>> style defines).
>
> The text and background colours for the 'open for vote' are *not*
> defined using *hex* codes. They use do use CSS variables [1] though.
>
> Both the 'enhancement' and 'open for vote' buttons share this CSS
> for the background colour:
>
> background: rgb(var(--label-r), var(--label-g), var(--label-b));
>
> Where these two buttons differ is in the values of the CSS variables
> --label-r, --label-g, and --label-b. The 'open for vote' button uses
> the *decimal* values below for --label-r, --label-g, and --label-b.
>
> --label-r: 83;
> --label-g: 25;
> --label-b: 231;
>
> Both the 'enhancement' and 'open for vote' buttons share this CSS
> for the text colour:
>
> color: hsl(0, 0%, calc(var(--lightness-switch) * 100%));
>
> and these CSS variables:
>
> --lightness-switch: max(0, min(calc((var(--perceived-lightness) - var(--lightness-threshold)) * -1000), 1));
> --perceived-lightness: calc( ((var(--label-r) * 0.2126) + (var(--label-g) * 0.7152) + (var(--label-b) * 0.0722)) / 255 );
> --lightness-threshold: 0.453;
>
> Where these two buttons differ is in the values of the CSS variables
> --label-r, --label-g, and --label-b used in the calculation of the
> CSS variable --perceived-lightness. This calculation is what lets
> the text stand out against the background.
>
> When I view the page in SeaMonkey 2.49.5, the text on the 'open for vote'
> button is grey and does not stand out. SeaMonkey uses an older version of
> the Gecko rendering engine and that older version does not properly handle
> all of the CSS calculations for the text colour.
>
> ___
> REFERENCES
>
> [1] CSS variables
> <https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties>

I saw a huge number of --color-* vars defined, and with values like
#f85149. I thought those were hex. That a value for a var is express
as a name-value pair (var: val) is still something I have to keep
remembering instead of var=val; however, to me, --label-g: 25 might be a
var, but doesn't smack of a color value. Not until I looked further to
see those vars were used to define color, background, and lightness in
hxIssueLabel did it make sense what those style vars were for.

So, the --label-* vars are decimal color values which get passed to
hx_IssueLabel for the background, color, and border-color properties
using rgba(), hsl(), and hsla() of which I know nothing of those
functions. I don't delve that deep into CSS. I can lookups this stuff,
like https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/rgba()
and https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/hsla(),
but it won't stick in my memory. I guessed rgba() had something to do
with RGB (red, green, blue) coloring, but hsl() is a stretch to guess
it's for hue, saturation, and lightness. I've never gotten into this
miniscule definition of a web doc. When I saw the lightness computation
crap, I left. I'm getting to really hate CSS. This site is an example
of extreme use of IDEs since only uber nerds would memorize this stuff.

VanguardLH wrote:

> he points to a web forum whose first post to open that discussion
> has him pointing elsewhere again, which is:
>
> https://github.com/wokwi/wokwi-features/issues/206

which is the gripe with a screengrab image

whereas

https://github.com/wokwi/wokwi-features/issues/206

is the actual web page

> The issue is the Github project page uses what looks like gray on purple
> for the text of a label/tag object in the web page.

for me, it renders legibly (if tastelessly) with white on purple

Andy Burns <usenet@andyburns.uk> wrote:

> VanguardLH wrote:
>
>> he points to a web forum whose first post to open that discussion
>> has him pointing elsewhere again, which is:
>>
>> https://github.com/wokwi/wokwi-features/issues/206
>
> which is the gripe with a screengrab image
>
> whereas
>
> https://github.com/wokwi/wokwi-features/issues/206
>
> is the actual web page
>
>> The issue is the Github project page uses what looks like gray on purple
>> for the text of a label/tag object in the web page.
>
> for me, it renders legibly (if tastelessly) with white on purple

That's what I get in Firefox 93 and Edge Chromium 94. From other
responses, looks like older versions of several web browsers cannot
handle the CSS calculations for lightness.

On Sat, 16 Oct 2021 14:57:03 +0100, Terry Pinnell wrote:

> I was trying to avoid duplication by discussing at one page:
> https://www.tenforums.com/general-support/186386-font-colour-puzzle.html

Does Terry get referral commissions for each new sign-up to Ten Forums?

> As you may have seen, subsequent posts there suggested JPG compression and CSS
> quirks as two possible causes.
>
> Interestingly both Chrome and Edge now display correctly. Only the old versions
> of Waterfox (2021.01) and Firefox (56.02) still display the unreadable text.

Oldware not handling modern CSS functions.

--
Kind regards
Ralph

On Sat, 16 Oct 2021 05:14:46 -0400, Paul wrote:

> Only Seamonkey has black text on Purple.

SeaMonkey uses a old version of the Gecko rendering engine.
The old version does not handle modern CSS functions.

--
Kind regards
Ralph

"Ralph Fox" <-rf-nz-@-.invalid> wrote

| SeaMonkey uses a old version of the Gecko rendering engine.
| The old version does not handle modern CSS functions.
|

Maybe. I don't find any color property set on the span
element that contains the text. Firefox inspector has interpreted
it as inside the A tag and dropped the span. Which actually makes
sense. An A has its own properties, so it's redundant to put the
A text in a span. So it may be a problem of how browsers decide
to interpret a span within an A. Either way, it's very bad code.

On Sat, 16 Oct 2021 17:30:40 -0400, Mayayana wrote:

> "Ralph Fox" <-rf-nz-@-.invalid> wrote
>
> | SeaMonkey uses a old version of the Gecko rendering engine.
> | The old version does not handle modern CSS functions.
> |
>
> Maybe. I don't find any color property set on the span
> element that contains the text.

The 'span' element has inherited 'color' from the parent 'a' element.
This is standard HTML/CSS behaviour.

Look for these attributes on the parent 'a' element
style="--label-r:83;--label-g:25;--label-b:231;--label-h:256;--label-s:81;--label-l:50;"
class="IssueLabel hx_IssueLabel width-fit mb-1 mr-1"

The class 'hx_IssueLabel' gives these additional CSS properties,
the same ones as in my earlier reply to VanguardLH

color: hsl(0, 0%, calc(var(--lightness-switch) * 100%));
background: rgb(var(--label-r), var(--label-g), var(--label-b));
--lightness-switch: max(0, min(calc((var(--perceived-lightness) - var(--lightness-threshold)) * -1000), 1));
--perceived-lightness: calc( ((var(--label-r) * 0.2126) + (var(--label-g) * 0.7152) + (var(--label-b) * 0.0722)) / 255 );
--lightness-threshold: 0.453;

The rest is CSS calculation. See my reply to VanguardLH.

SeaMonkey does not handle all of the CSS calculations required for
the 'color' attribute, because SeaMonkey is using an old version
of the Gecko rendering engine.

Current versions of Firefox, Chrome, and Edge do handle all of the
CSS calculations required for the 'color' attribute.

> Firefox inspector has interpreted
> it as inside the A tag and dropped the span. Which actually makes
> sense. An A has its own properties, so it's redundant to put the
> A text in a span. So it may be a problem of how browsers decide
> to interpret a span within an A.

No, it is a normal case of inheriting 'color' from the parent element.

<https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/Cascade_and_inheritance#inheritance>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ QUOTE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For example, if you set a color and font-family on an element,
every element inside it will also be styled with that color and
font, unless you've applied different color and font values
directly to them.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ QUOTE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--
Kind regards
Ralph

"Ralph Fox" <-rf-nz-@-.invalid> wrote

| The 'span' element has inherited 'color' from the parent 'a' element.
| This is standard HTML/CSS behaviour.
|

Thanks for that detailing. But there's no reason for the
span element. Even setting that issue aside, the color spec
seems to make no sense.

It should be <A CLASS="A1"> text here </A> The A tag
can accommodate all style specs by itself. SPAN is superfluous.
I didn't try to calculate all of that math for the color value,
but it's still Rube Goldberg code. The following would achieve
the desired result with no complications and without breaking
in any browser. It will even look fine in IE5. It just wouldn't
show the round corners.

<A STYLE="background-color: #5319E7; color: #FFFFFF; font-family:
sans-serif; font-size: 12px; padding: 5 20 5 20; border-radius: 20px;"> open
for vote</A>

As it's been specced, the color has to be grayscale
because hue and saturation are both 0. So while the
perceived lightness seems to be calculating an off-white
hue based on the purple, it can only be grayscale, no matter
what that calculation produces. Somewhere along the way, some
browsers are calculating a medium gray instead of white.

We could say their method is valid CSS but it's actually
sloppy and overly complicated. And it doesn't work in all
browsers. Technical accuracy is not of much value if
it produces brittle code. It wasn't so long ago that the
general idea was to make a page render as accurately as
possible in as many browsers as possible. To say some
browsers are not sufficiently modern is no excuse.