website: textarea text not legible on https://golang.org/ when using Adwaita Dark gnome theme

[8i8]

What version of Go are you using (go version)?

$ go version go1.11.2 linux/amd64

Does this issue reproduce with the latest release?

The issue is with the website.

What operating system and processor architecture are you using (go env)?

Using debian 9.9 with the gnome 3 settings from the standard tweaks menu and firefox-esr.

go env Output

$ go env

What did you do?

I have the advaita dark theme activated which sets the text background default to a dark colour and the foreground text to a light colour, white.
All text area text, particularly the examples and runnable code on the website is unreadable without my changing my OS setup.

What did you expect to see?

Text.

What did you see instead?

Nothing, unless selected with the mouse.

Fix

This can be easily fixed by adding the following css to style.css:

textarea {
color: #222;
}

I would be very grateful for your attention in this matter, I did take a look for the style sheet but have not managed to find it. Here are two screen shots of the way that the site currently appears in my browser:

Thank you for your attention.

Iain Hill.

[ianlancetaylor]

CC @andybons

[bcmills]

CC @cnoellekb

[andybons]

@8i8 how many other sites are broken for you? If you visit https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_textarea do you see the same issue?

[8i8]

@andybons Yes that is broken too; There is a surprisingly large percentage of the web, for whome the issue is present. Any website that override only one of the default pair, the textarea background colour or the text itself is rendered illegible. The user settings are just that, the user settings; This is OS widgit colour not web specific. I have stopped using the adwaita dark setting whilst working with the documentation, but this is not ideal.

The issue occurs in firefox but not in chromium, it would appear that the chromium browser has done something to either detect or simply rectify when this occurs.

I personally like the setting, as it keeps the white glare down in what wouldbe low light environments; There is far to much contrast, in any dark theme, when large text areas are #ffffff white.

Thank you for your consideration.

[8i8]

@andybons I have just been investigating the firefox settings and found a force system colours checkbox; This has resolved for the w3schools site but not for golang.org; Still White text on beige.

... I have just reverted firefox back to the default settings as due to attempting to make the go doc's legible i had switched on a theme colour profile; firefox now standard colours and the system set to advaita dark; the w3school's site is readable where as the golang is still light on light.

[andybons]

Firefox Quantum (64.0.2 (64-bit)) and Chrome both apply their own default styles to the textarea on golang.org. I don’t believe directly stying the textarea is the right solution. Without knowing how gnome’s skinning works it’s difficult to know the best next step. Given that things were broken for a large part of the web until settings were fiddled with, I’m inclined to believe that something is misconfigured or there’s a bug in gnome’s skinning code.

[jimmyfrasche]

@andybons UA stylesheets explicitly set a foreground and background color on form inputs. If you leave both as they are, it doesn't matter what those colors are. If you set both explicitly, it doesn't matter what you set them to. If you set one but not the other, it's possible that the two colors fail to contrast. Even if you don't consider this a bug in godoc, you can consider it a feature as setting an explicit color on the textarea makes the site more robust in the face of the myriad ways UA stylesheets can be altered.

[andybons]

@jimmyfrasche you’re right, and given we explicitly set the background color but not foreground it may be that the gnome skinning is altering the UA stylesheet and causing this issue. Is this how gnome skinning works?

[jimmyfrasche]

I don't know how the gnome skinning works.

The skin could be replacing the UA stylesheets or installing a custom FF theme or it could be setting some color values in the skin that FF gets reads to compute -moz-FieldText, which is the default color for textarea in the default FF UA stylesheet. It could be a bug in the skin, the theme that can contain basically arbitrary JS (hooray?), the interface between gnome skins and FF, or the hypothetically modified UA stylesheet. Possibly some interaction between a mix of those scenarios.

There are a lot of ways for it to have gone wrong but adding something like textarea { color: inherit; } would protect against all of those scenarios and more by ensuring that the correct colors are always used.

[8i8]

Yes very few devs pay attention to these defaults UI, is not cutting edge for some reason, which is a shame as it ought to be. Of note: this debian/GNOME setup has extremely good accessibility configurations, clearly a premier concern.
Is the GNOME styling done here?
https://github.com/GNOME/gtk/blob/master/gtk/theme/Adwaita/_colors.scss
From the looks of it, it is cascading css.
Yes I can confirm that adding textarea { color: inherit; } to the styling rectifies the oversight.

[andybons]

@8i8 if you’d like to send a change with the fix (including a comment about why we’re explicitly setting a color), I am happy to review.