
Dear web developers: set the font color, too - luuio
https://www.luu.io/posts/web-devs-font-color
======
rancyber
This is the browser's fault for violating the HTML spec. As per the
specification, the default font color is complete black and the default
background color is complete white. To my knowledge the only browser that does
not honor this is Firefox[1], and it is an eighteen year old bug which they
refuse to fix.

[1]
[https://bugzilla.mozilla.org/show_bug.cgi?id=70315](https://bugzilla.mozilla.org/show_bug.cgi?id=70315)

~~~
chriswarbo
> This is the browser's fault for violating the HTML spec. As per the
> specification, the default font color is complete black and the default
> background color is complete white.

Your claim surprised me so much I went and re-read the latest HTML spec (
[https://www.w3.org/TR/html52/rendering.html#rendering](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/](https://www.w3.org/TR/2018/REC-css-color-3-20180619/) and
[https://www.w3.org/TR/2011/REC-
CSS2-20110607/colors.html#q14...](https://www.w3.org/TR/2011/REC-
CSS2-20110607/colors.html#q14.0) ) 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.

~~~
jameshart
Huh, kids today with their modern web standards with their sensible, well
specified defaults.

In my day, the default background color was #C0C0C0, as is laid down in the
Book of Mozilla.

------
TheCoreh
Due to how widespread assumptions about "system" form field colors are
throught the web, the proper thing for browsers to do is probably to _not_
apply a dark theme to form fields, at least by default. Maybe instead allow a
CSS opt-in to support dark themes.

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)

~~~
jolmg
I agree that that is the simplest solution, and I've even configured Firefox
as such[1], but I kind of wish I could have ONE place to control styling of
_everything_.

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.

[1]
[https://news.ycombinator.com/item?id=19056752](https://news.ycombinator.com/item?id=19056752)

------
mikewhy
Sure it's not an issue with whatever is doing that (hacky) dark mode CSS?
Looking at the google example, they are setting the font color. It just
doesn't look good when dark-mode CSS doesn't take the existing colors into
account.

~~~
luuio
The dark mode is actually coming from the GNOME system colors, not browser
plugin.

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.

~~~
deckar01
I have a dark theme enabled on xfce, and this is not a problem for me in
chromium. The inputs in native apps are dark, but they are the default light
color in web pages on chromium.

~~~
robrtsql
Really? I might have to switch then.. I use Firefox and GNOME, and enabling
one of the dark themes causes most forms on the web to become unusable because
of this very issue.

~~~
deckar01
I just tested Firefox on xfce and it shows the problem. Safari, Firefox, and
Chrome on MacOS in dark mode do not have this problem. This appears to just be
a Firefox on linux issue.

~~~
michaelmrose
Firefox is doing what is technically the correct thing in using system colors
text color and background when not specified.

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.

~~~
dTal
I don't think you necessarily even have to check for colour similarity - we
agree that setting only one attribute is broken, so just detect when only one
attribute is set and either ignore it, or (if you feel like being clever) set
the other attribute to be its complementary colour.

------
no_protocol
What has happened to the concept of "User Defined CSS"? Is it totally gone?
Did Chrome kill it?

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.

~~~
krapp
Browsers have supported user defined CSS defaults since forever, and plugins
like Stylish have been around for a while.

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.

~~~
no_protocol
> Browsers have supported user defined CSS defaults since forever, and plugins
> like Stylish have been around for a while.

It looks like Chrome removed these several years ago:

[https://news.ycombinator.com/item?id=7329855](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](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.

------
mrspeaker
I hit this same same issue too. I tried to eliminate white backgrounds,
because I find it tiring on my eyes and a bit painful. These sites made it too
annoying to change the defaults, so I ended up giving up (and just always
having my screen brightness near minimum).

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](https://gist.github.com/mrspeaker/1846b6b0e12c76f7eeb2).
There's a useless list for you!

~~~
LoSboccacc
there's a contrast/brightness button on most hardware, why have low contrast
websites by design? just tune your monitor! it will then work for websites,
games and everything else.

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

~~~
mrspeaker
I don't want low contrast, I just wanted to swap my browser default
foreground/background colors (low brightness is just my hacky workaround).

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.

~~~
LoSboccacc
> I don't want low contrast

> 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

~~~
a1369209993
No, they want[0] _white_ text on a _black_ background. That's not low
contrast, that's high contast, unless you're suggesting a 'contrast' of -1.00,
which is not what most people think of as "low contrast".

0: IIUC

------
mtmail
As a lazy web developer (it's not my main job) I just hope there are tools who
mark those in a checklist. E.g. Google Lighthouse Accessibility Audit.
[https://developers.google.com/web/tools/chrome-
devtools/acce...](https://developers.google.com/web/tools/chrome-
devtools/accessibility/reference)

------
alias_neo
This is a real issue for me at times. I have a dark theme set in Gnome,
because I want dark system windows, but lots of sites don't bother setting
their colours properly, so if I open the Web UI for my Ubiquiti Router, or one
of my switches, and try to select a drop-down, the background of it is dark,
like my system theme, and the text is dark, so I can't see what I'm choosing.

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.

~~~
_trampeltier
Would be cool, if websites would ask, if you like bright or dark website.

~~~
michaelmrose
Do you want a pop up every time you browse a page?

~~~
jayd16
They can throw it in the popup that tells me about cookies.

~~~
michaelmrose
How about a global setting that the user can set once which is what we have
now.

------
anonytrary
Pretty tangential, but with AMOLED screens, I really hope society starts
embracing a dark-mode default for interfaces. There is no reason to use light-
mode with modern screens. It's taxing on the eyes, probably not good for kids
and teens who are using screens 4 hours a day and it doesn't seem to offer
benefits over dark-mode in terms of accessibility.

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.

~~~
gnicholas
I prefer day-mode when in bright light. Otherwise the black background ends up
reflecting the bright light. I often prefer night-mode when it is not bright
out, and at nighttime.

~~~
nomel
I think the problem is that many of the "dark themes" have grayish fonts that
give low contrast. If the font were pure white, the resulting contrast is much
more usable in bright light

I achieve this by setting my display to higher contrast to blow out the grays,
in bright light.

~~~
gnicholas
I’m not actually using night themes, but rather OS-level inversion. It might
be that it’s the same effect because the text is actually dark grey, which
ends up being inverted to light grey.

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.

------
jameslk
I don't understand this article. The author is using something that
manipulates the style of inputs to make them dark with light fonts... but only
if the input isn't explicitly styled with either _background-color_ or
_color_.

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.

~~~
michaelmrose
The hackery is literally opening the users control center and clicking the
icon for desktop theme and clicking on a different theme and clicking apply.

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.

~~~
jameslk
The developer was doing you a favor, by not overriding all your styles,
preventing you from potentially downloading a bunch of unnecessary bytes,
slowing down your browser with potentially unnecessary CSS rules and leaving
it up to you to use your best judgement not to fubar the site. Like I've
mentioned elsewhere, this is the old reset css debate.

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.

~~~
michaelmrose
There is no way for users to fix that you the dev decided to override one
value and not the other other than not using dark themes.

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.

------
mercora
I am not sure if web developers are to blame here. It would probably be way
more consistent to define default colors based on a standard instead of some
local settings. However, if you change the colors you should make sure to do
so for all related ones to avoid this.

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

------
superfamicom
For as long as I can recall, the CSS linting tools I have used always warn
when defining one and not the other, so it just became a habit for me.

------
paulie_a
I really don't get why front end devs/UI people are so crazy about fonts. It
doesn't add to the experience.

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.

------
droobles
Definitely agree accessibility is important going into 2019. Different users
are going to be viewing a site with more screen readers, dark theme, and other
alternative viewing options, very much like we saw with mobilegeddon and the
advent of responsive design. I've seen the argument that this hurts the
"intended web experience", but this can be solved by keeping up with modern
CSS practices and crafting the experience with screen readers in mind.

Good stuff, thank you for sharing.

~~~
jameslk
I agree we need to give accessibility more priority and we likely will once
the discrimination lawsuits start rolling in. But this isn't an accessibility
issue. Nowhere in WCAG 2 will you find anything that explicitly outlines both
color and background color need to defined in stylesheets.

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.

~~~
luuio
You got it backward. The custom CSS of the website is overriding the system
styles in this case. Let's take font-family for example. Just because you're
setting the font for your input[text] tags doesn't mean the browser will also
automatically set the font for other elements to match the style. If you want
the website to have uniform look, then you'll need to set the font-family for
other elements, too.

~~~
jameslk
This is really just the old debate of whether to use a reset css in disguise.
It has nothing to do with accessibility.

------
navbaker
Tangentially related question: is it up to the developer to make forms do
stuff like use the number pad on a phone instead of the QWERTY keyboard when
the user is asked for a zip code or telephone number? Is this not something
that is just auto-baked in to modern web dev frameworks?

------
kalleboo
Browsers on macOS appear to be smart enough to not pass through the system
dark theme to web content. I'm seeing white forms in Safari and Firefox
(Chrome doesn't seem to support dark theming at all).

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.

~~~
saagarjha
> Browsers on macOS appear to be smart enough to not pass through the system
> dark theme to web content.

There two main reasons here:

* Browsers don't support dark themes themselves.

* Browsers don't support @media(prefers-color-scheme).

~~~
kalleboo
Both Safari and Firefox support the macOS Mojave dark theme

------
supr4
I didn't think about this in that case. Thanks for the article. I especially
like using this color in my forms:
[https://hexcol.com/color/f9f9f9](https://hexcol.com/color/f9f9f9) and i'm
doing this really often. To be honest, I think those system architects should
take care of this bug more than web developers, but it's just one more line in
code for us, so it's worth to think about.

------
ccnafr
Never though about this before, but, dark themes have only recently become
widespread, so I'm not necessarily faulting web devs on this.

~~~
chrisseaton
It's not about dark themes - I don't think it was ever right to set one colour
without the other as I don't believe (may be wrong) that the CSS or HTML
standard ever said anything about default colours?

------
jmull
I'm curious: what is environment for these tests?

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

~~~
jolmg
It happens to me on Linux. I have GTK and QT configured with dark themes. To
overcome this, I have to configure Firefox with a default styling in
~/.mozilla/firefox/*/chrome/userContent.css:

    
    
        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;
        }
    

Now that I look at it, I wonder why I didn't join all 3. Whatever.

~~~
saghm
Thanks for this! I've been dealing with this issue for a while now and somehow
didn't think to use CSS to fix it (despite having a number of custom
stylesheets for various sites).

~~~
jolmg
I think it still needs some work. A couple of months ago I opened a webpage
with documentation. It had a table of contents in the sidebar, and it was
invisible. White on white. It was because these were simply links, and not
input field elements. Perhaps the solution is as simple as assigning these
rules to html or body instead of these elements, and letting it cascade. There
might also be stylesheets online meant to normalize styling across web
browsers that one could use.

~~~
saghm
Yeah, I'm definitely in the process of tweaking it; I'd rather still have the
inputs be dark with white text, but messing with things like buttons can make
some sites have some glaring differences. I think the main insight I got from
this is that I can at least use CSS to tweak this sort of thing; beforehand, I
was just opening up Gnome Tweak Tool and changing the theme whenever I needed
to do something like comments on a Google doc, and this is a much better
solution.

Thanks again!

------
janpot
Another one of those "dear web developer" blogs... I think it would make more
sense to direct your condescendence to the people who actually define the
products and those that decide on the priorities.

------
efnx
> Add yet another /* TODO */ in your codebase and call it a day. JK :-).

Then you could track it with [http://srcoftruth.com/](http://srcoftruth.com/)

------
zorronimous
Of You want to mix system colors with your own you can calc the contrast too!
(How i leave as an exercise for the reader)

------
aug-riedinger
How such uninteresting article can make it to the newsletter?

------
exploderwhale
Or you could entirely avoid this issue by using multi-font themes with
different weights, decorations, and ligatures.

~~~
iainmerrick
What does that have to do with color and backgroundColor?

~~~
exploderwhale
How does it not?

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](https://github.com/maio/eink-emacs)

~~~
iainmerrick
_The article even states: "Don't set the colors at all, let the browser use
the system default color"._

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.

------
aboutruby
Apple introduced Dark Mode expecting all major websites to maintain some CSS
just for a small percentage of macOS users. I don't think it's going to happen
(and it's not happening)

~~~
SquareWheel
This comment intrigued me, so I did some digging. Looks like "prefers-color-
scheme" is currently being considered by both Chrome[1] and Firefox[2]. A can-
I-use page was just created for it[3].

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](https://bugs.chromium.org/p/chromium/issues/detail?id=889087)

[2]
[https://bugzilla.mozilla.org/show_bug.cgi?id=1494034](https://bugzilla.mozilla.org/show_bug.cgi?id=1494034)

[3] [https://caniuse.com/#feat=prefers-color-
scheme](https://caniuse.com/#feat=prefers-color-scheme)

~~~
chriswarbo
Wow, what an awful thing to standardise! Are there equivalents for high/low-
contrast? Red themes, blue themes, multicolour themes, etc.?

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

~~~
kevin_thibedeau
How else should a site query for the user preference? Everyone is operating in
the blind right now.

~~~
chriswarbo
Sites are _already_ styled according to the user's preference, by default. If
you want to respect the user's preference, stop overriding things with CSS.

~~~
SquareWheel
Sites are styled by default browser stylings. 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.

~~~
chriswarbo
> Sites are styled by default browser stylings

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?

~~~
SquareWheel
No, it's just a lost cause. I've had people complain that their website looks
crazy on one specific PC, and after tons of debugging found it's because
somebody set their default font size to 200px.

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.

