Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
8i8 opened this issue Dec 31, 2018 · 15 comments
Labels
FrozenDueToAge help wanted NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@8i8
Copy link

8i8 commented Dec 31, 2018

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:

screenshot from 2018-12-31 17-45-44
screenshot from 2018-12-11 18-27-54

Thank you for your attention.

Iain Hill.

@ianlancetaylor ianlancetaylor changed the title Text not legible on https://golang.org/ ~ Fix included. website: text not legible on https://golang.org/ Dec 31, 2018
@ianlancetaylor
Copy link
Contributor

CC @andybons

@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Dec 31, 2018
@ianlancetaylor ianlancetaylor added this to the Go1.13 milestone Dec 31, 2018
@bcmills
Copy link
Contributor

bcmills commented Jan 11, 2019

CC @cnoellekb

@andybons andybons changed the title website: text not legible on https://golang.org/ website: textarea text not legible on https://golang.org/ when using Adwaita Dark gnome theme Jan 11, 2019
@andybons
Copy link
Member

@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
Copy link
Author

8i8 commented Jan 12, 2019

@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
Copy link
Author

8i8 commented Jan 12, 2019

@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
Copy link
Member

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
Copy link
Member

@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
Copy link
Member

andybons commented Jan 13, 2019

@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
Copy link
Member

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
Copy link
Author

8i8 commented Jan 14, 2019

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
Copy link
Member

@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.

@andybons andybons added NeedsFix The path to resolution is known, but the work has not been done. help wanted and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jan 14, 2019
@8i8
Copy link
Author

8i8 commented Jan 15, 2019

@andybons Thank you for your kind consideration; After a little investigation of the setup, which has not yet reveled the origin of these styling options; I am lead to believe that they could be set further upstream, maybe the webserver gas a global template for page headers and styling?
In which case I don't think that altering them locally would be the best solution. I see that the Codewalk section of the site is styled locally, it also has a slightly different feel due to this, presumably another author, also that there is a test style.css document in the testing area; How would you recommend that I proceed; I am very to be of willing to help and could well be wrong in my assessment of an apparent solution?

Could I run a test version of the site locally so as to be able to see where the cascading effect of styling are taking effect, or not, as the case may be?

Thank you.

@8i8
Copy link
Author

8i8 commented Jan 16, 2019

@andybons Hi, I having finally found the correct place for this small modification, to the best of my knowledge this is where it be best placed to amend any occurrences of the issue; I have made a pull request:
golang/tools#70
Thank you.

@gopherbot
Copy link

Change https://golang.org/cl/158137 mentions this issue: godoc/static: inherit textarea color to avoid illegible text

@gopherbot
Copy link

Change https://golang.org/cl/160482 mentions this issue: godoc/static: update static.go

gopherbot pushed a commit to golang/tools that referenced this issue Jan 30, 2019
golang.org/cl/158137 was missing a corresponding update to static.go.

Updates golang/go#29482

Change-Id: I60e059c3f00408c0d41e5284cb3e154fc1515032
Reviewed-on: https://go-review.googlesource.com/c/160482
Reviewed-by: Katie Hockman <katie@golang.org>
@golang golang locked and limited conversation to collaborators Jan 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge help wanted NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants