Dear web developers: set the font color, too
luu.io
luu.io
https://html.spec.whatwg.org/multipage/rendering.html#phrasi...
"The initial value for the 'color' property is expected to be black. The initial value for the 'background-color' property is expected to be 'transparent'. The canvas's background is expected to be white."
[0] https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
Your claim surprised me so much I went and re-read the latest HTML spec ( https://www.w3.org/TR/html52/rendering.html#rendering ) and it does indeed say:
> The initial value for the color property is expected to be black. The initial value for the background-color property is expected to be transparent. The canvas' background is expected to be white.
The CSS specs ( https://www.w3.org/TR/2018/REC-css-color-3-20180619/ and https://www.w3.org/TR/2011/REC-CSS2-20110607/colors.html#q14... ) say that the initial values depend on the user agent (hence deferring to the above quote):
> Name: color
> Initial: depends on user agent
> 'background-color'
> Initial: transparent
However, is this also the case for form fields? Scanning through the various CSS specs I can't find any mention of form fields (e.g. buttons, text inputs, etc.). The HTML specs don't seem to specify anything w.r.t. styling form fields either.
In my day, the default background color was #C0C0C0, as is laid down in the Book of Mozilla.
Just like the default border style is "none", but that's not what form controls do.
But even past that point, this is the _ua_ default. A user can always have a user stylesheet that sets whatever colors the user wants (e.g. for accessibility reasons).
And not setting background without setting color and vice versa is standard best-practice web development advice and has been for 2 decades or so now.
This seems to be what Apple is doing with Safari, and I feel like it's what provides the best user experience out of the box. (Even for pages that don't make this styling mistake, a single dark input field on a full light page is not a satisfactory dark mode experience)
That is, I kind of wish web developers couldn't control colors and such, so people could have consistent styling in their whole system.
That's a pipe dream though. Websites tend to be hosted by people that want a brand to protect, and as adoption of computers increase people on average don't want to invest time in learning how to use and configure their systems.
Maybe I should consider seriously switching to elinks or w3m for my style-consistent browsing.
From inspecting the CSS in the developer console, the cases in the screenshot either set the background color without setting the text color, or vice versa.
Web developers are just not terribly competent. It should be obvious that setting text color but not text background is erroneous. Since expecting basic competence from web developers seems to be a losing battle several things suggest themselves.
- provide a gui option to select the theme/style to use for firefox separate from the gui. This is already possible at the command line.
- Explicitly check for text that is to close to the background wherein only one attribute is set and adjust the smartest solution
- Just ignore the users colors like chrome does.
Personally I have a dark gtk theme but run firefox with a light one because otherwise the web is unusable.
or whatever your desired theme is
in fact I have the following fish shell function
function withtheme
env GTK_THEME=$argv[1] $argv[2..-1]
end
You can copy the firefox desktop file from /usr/share/applications to ~/.local/share/applications and edit the exec line as you please.
It's the same when you are using classic Windows theming and change the colors. The default background and font colors adjust accordingly (in Firefox, Chrome and Chromium-based things like Steam), which means that (many) pages that only alter the font color to say #333, but don't change the background color, become completely unreadable. Black on black.
In most examples, they're setting the background colour without corresponding font colour. In the Google example, they're making the opposite mistake.
One should set both or none.
Did you read the accompanying text? What you've said is literally the exact opposite of what is happening.
Google's CSS is not taking the default system colours into account. All of these sites seem to be assuming that the default system colours, implemented by the OS, are black text and white backgrounds. There is no reason to assume this, and indeed this is not the case on a minority of machines. The author's system happens to use white text and black backgrounds. So do I. Others are using low-contrast grey-on-grey themes, still others have a variety of multicoloured themes.
The author is trying to spread awareness that this seemingly common assumption about default colours is wrong. Hopefully this awareness has reached at least one person (yourself) ;)
I guess I could've made that point more clear in the post. Thanks for your replies in this thread :)
Browsers should be making this a prominent and first-class feature.
Users should be able to quickly and easily set their default styles for various elements and choose at what precedence level they apply.
The practice of users customizing their CSS isn't prevalent because modern sites are incredibly complex and the average user doesn't want (or know how) to spend the time necessary to reverse engineer a site's layout and rewrite its CSS - there is no "quick and easy" way to do that for any but the simplest sites. Just consider how often professional developers complain about CSS, and they get paid to put up with it.
It looks like Chrome removed these several years ago:
https://news.ycombinator.com/item?id=7329855
Plugins are a thing but why should you need a plugin for something that is a core part of the CSS specification?
https://www.w3.org/TR/CSS2/cascade.html#cascade
> the average user
This is (mostly) about accessibility. Even if the average user does not need it, some do. And those that do would be quite glad to have it easily.
> there is no "quick and easy" way to do that for any but the simplest sites
Just because user stylesheets have been ignored for many years doesn't mean they shouldn't be acknowledged. Design your site with them in mind.
Actually, yes:
https://www.w3.org/TR/CSS2/cascade.html#cascade
User stylesheets are supposed to be applied at a precedence level below the page author's style, so any time the page author did not specify a style, the user's style can be used as default.
Browsers should have made this an easily accessible feature, but they seem to instead like to remove access to it. Think "Developer tools window", but persistent.
But before I gave up I started collecting sites that either set background-color and not font color, or set color but not background-color: https://gist.github.com/mrspeaker/1846b6b0e12c76f7eeb2. There's a useless list for you!
it will also allow you to handle contrast reducing it at night and tuning up when the monitor is struck with some glare, without having to change the css! imagine the convenience!
software developer: using hammers for everything since 1842
The "bug" on these sites is that if devs set a default background-color they should also set a default font color: either set neither properties, or set both.
Setting one means the default of the browser will be used. Most of the time it's background=white, foreground=black, so no one notices, but it means the option is gone for people who do want to modify them.
> I tried to eliminate white backgrounds, because I find it tiring on my eyes and a bit painful.
yes, yes that's exactly what you want. besides you can tune both gamma and tone both in software and hardware on most platforms; this isn't rocket science people had the ability to tune the monitors to their liking since television had colors
0: IIUC
Other times, like if I'm entering text into the Name field for ports on my switch (Ubiquiti) the background is white, the text is white and so I can't see what I've entered until I select all.
These aren't such a big issue so much as an irritation, but, lets same I'm trying to login to something, at times I can't see the username/email I've entered until I highlight, not such an issue for passwords because we do this blindly anyway most of the time.
I'd prefer if Firefox wasn't using my system UI elements at all, but even toggling the hidden config doesn't seem to make any difference there.
https://docs.docker.com/engine/reference/builder/
(Note, the right hand bar and thus the toggle isn't visible on mobile or narrow windows)
There is a toggle, between day/night mode in the right hand bar on the page, it lets you toggle between the dark and light themes with a click.
I'd be perfectly happy with "just" Firefox not using system controls and using some default.
Asking for a site that can change themes seems to much to ask of a web developer (/jk)
It's nice to see more and more websites and operating systems providing dark theme toggles, but I hope one day that light-mode becomes a thing of the past.
Aside from the fact that many people prefer it?
Google Maps alternates between light and dark based on ambient light. That's the optional behavior I want for all apps. I use the Android feature to invert all colors at times.
But, every company wants their app be a glorified ad for the app I'm already using, and wants it to use their branding: their colors, their fonts, their precise level of rounded corners.
I just want to have a consistent UX that allows me to get shit done.
I achieve this by setting my display to higher contrast to blow out the grays, in bright light.
I actually think it’s more likely that many sites use very lightweight fonts, which means that in night mode there’s a lot of dark pixels showing.
If they're going to be doing such hackery, just style both at the same time. Use JavaScript or something to ensure both are styled. This really isn't the developer's concern.
> Though, that might be a problem for some users, especially those with a default dark theme on their systems.
It's a real issue, every time I set a dark theme, web pages become affected because the defaults get changed. I think the issue should be fixed by the browser vendor really. Eventually I get frustrated enough to just disable it altogether.
Yes, I agree. Or whoever built the dark theme. They should be checking whether inputs have been overrided with styles for both background/color or none.
> just style both at the same time
That's exactly the point. The system by default sets both colors, though most browsers I've used allow the website to override the colors. In these cases, the websites only override one but not the other.
You're using the word "override"; what do you think the order of these things is? As far as I'm aware:
- The user sets their system's colours (e.g. for me that's white text and black background). These are used by all applications, including the browser.
- Web sites may override these defaults by providing CSS, e.g. Google dictionary forcing the text to be black
These bugs are caused by Facebook, Dropbox, Google, Twitter, etc. shipping broken overrides. It's a pretty minor problem (as this post's author acknowledges), but it's not the user's fault.
If these sites didn't try to override things, i.e. by providing plain, semantic HTML, then this problem wouldn't occur (some might prefer such sites!)
I agree, but I think this could be phrased better: If the system is using a (light-foreground-on-)dark-background theme, it should force web pages to use a dark-background theme, no matter what CSS they have.
> The author is using something that manipulates the style of inputs to make them dark with light fonts
The author is setting his system theme to a dark one. Maybe you don't know what that is because such options seem to be disappearing, but a system theme controls the styling of (ideally) all GUI applications running in the OS. One of these applications is the web browser.
> but only if the input isn't explicitly styled with either background-color or color
No, themes set both. It's the web developer that overrode one but not the other and what the author is complaining about.
> If they're going to be doing such hackery, just style both at the same time.
This is precisely what the author wishes of web developers and their hackery. You're directing this suggestion to the wrong person. The author did set both when setting his system theme.
> Use JavaScript or something to ensure both are styled. This really isn't the developer's concern.
Again, the author did style both when setting his system theme. It's the web developer that is overriding the style of one but not the other.
This sets the users desktop colors. Firefox will pick this up and use these colors for elements on the page unless these elements are explicitly styled by the developer.
So say the users theme specifies a grey or black background and white text. The developer wants a slightly different grey on the text but is ok with the default light background that developer assumes will show up.
Since the user specified a default color for the background and the developer did not we get a grey background. Since the developer selected a text color that takes precedence over the users selected color so we get grey text.
End result grey text on the grey background. There is no hackery. The user can't just style both because by design the developers choices are supposed to override defaults.
The user didn't do anything wrong. It is 100% the developers fault for explicitly specifying the color of the text and assuming (making an ass out of you and me) that the background would be a certain color because it is on their install of chrome. This is no different than assuming the users screen is a certain size. If you set the color of text just go ahead and actually specify the background color as well.
It's a calculated risk to address 99% of users who don't have their browser change their default agent styles. Everyone else is assumed to know what they're doing.
Overriding one value and not the other isn't doing the user a favor it predictably results in broken behavior that you could 100% avoid by designing your page competently. The 2 colors are implicitly related and need to be chosen together to result in a readable result.
The fact that it works okay on most systems does not indicate that your work is correct.
100% broken code per standards that happened to work under internet explorer 6 wasn't correct under the principle that people could just use ie.
This is only different in that this debate is more nonsensical because the correct behavior is so easy to achieve.
The default background being light isn't an actual default and if you depend on it then it is no different than depending on the user speaking English having 3 names text being ltr.
Its calculated nothing because setting the background color increases how predictable your look and feel is. There are zero downsides to doing so.
For Linux you can setup Firefox to use a different theme for content widgets which can fix assumptions developers have about the default colors.
I've configured it in the about:config page like this:
widget.content.gtk-theme-override;Adwaita:light
Personally I set up an override in my browser. it's a mono, a sans and a serif, sizes 8-14 or so. All black.
The internet is readable again.
Good stuff, thank you for sharing.
That's done on purpose to discourage people from posting (or reading) them too often. PG was afraid letting people write text posts would lead to "blogging."
There was never any real chance of this forum going mainstream, not because it was too ugly and awkward but because it didn't have any mainstream appeal. Negative reinforcements like making the text purposely difficult to read mostly just punish existing users.
Still, I can't seem to be able to collapse thread branches because it requires javascript. That's a shame.
I wonder if w3m would recognize something like:
.collapse:checked + .content-and-replies-container {
display: none;
}This is for users who prefer dark themes who are overriding styles of websites incorrectly. It is a failing of the user's browser/OS for not explicitly overriding both background and color at the same time or neither. If every developer had to add in a color for the edge case that someone is overriding styles globally, then we'd be bloating stylesheets with extra unnecessary bytes.
WCAG doesn't specify implementation, but WCAG 1.4.3 does require a minimum contrast ratio[0]. If the site allows black text on a black background, it will fail that requirement.
0 - https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-cont...
As much as I'm a proponent of OS-native UX, CSS styling of form controls on the web has been a crapfest ever since IE(?) introduced it way back when. Whenever CSS touches a web form control it should just go completely custom-rendered. If you want to impose a dark theme on web content, you should use an intelligent browser extension that does things like verify text contrast.
There two main reasons here:
* Browsers don't support dark themes themselves.
* Browsers don't support @media(prefers-color-scheme).
Have they? I've been having this problem for around 15 years :(
Nice to see it brought up somewhere so prominent though!
It's just not as common anymore as it used to be back when you as a user could specify easily how you want your system to look.
I want to reproduce to understand what's going on better.
(For what it's worth, in 10 sec of testing Safari and Chrome on MacOS dark mode don't seem to have this issue... the font and background colors seem to still default to dark on white.)
input, button {
-moz-appearance: none !important;
background-color: white;
color: black;
}
textarea {
-moz-appearance: none !important;
background-color: white;
color: black;
}
select {
-moz-appearance: none !important;
background-color: white;
color: black;
}
Thanks again!
Then you could track it with http://srcoftruth.com/
The article even states: "Don't set the colors at all, let the browser use the system default color".
If a developer wants to express some intent maybe utilizing something else other than color would resolve some of these issues. If I can develop without color a user can read without color https://github.com/maio/eink-emacs
That’s just one of three options. Setting “both the background color AND font color” is another.
Also, the third option might give you a hint that the author’s tongue is in their cheek.
I'm excited by this one! Think I'll add dark mode support to my simple blog right now.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=889087
Why layer something like this on top of an override system, when devs can choose to just not override those things?
As an example, the only CSS colours I use on chriswarbo.net are either semi-transparent, or mid-grey (which work on light and dark themes, although I might revisit that since it would presumably not work on default-grey systems like AmigaOS).
For accessibility reasons, using the zoom feature is much more stable than increasing the default font size.
Which users choose according to their preferences (e.g. Firefox offers a preferences dialogue for this, and a bunch of about:config options). Whilst most users leave these as the OS/browser vendor's defaults, (in the words of Rush) "if you choose not to decide, you still have made a choice".
> When font changes are inherited from user's settings however, it basically just breaks everything.
> For accessibility reasons, using the zoom feature is much more stable than increasing the default font size.
So you're agreeing that all these sites are broken?
Of course, the majority of websites apply their own font styling so this doesn't often come up anymore. But those settings are just death traps at this point. Ineffective in 90% of cases, and hazardous in the 10% where they do work.
Not yet, although the API seems open enough to add this.
Now to wait for better browser support.