Hacker News new | more | comments | ask | show | jobs | submit login
Dear web developers: set the font color, too (luu.io)
180 points by luuio 22 days ago | hide | past | web | favorite | 142 comments



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


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


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.


It seems that chrome and chromium may also ignore the spec, as https://news.ycombinator.com/item?id=19056637 says. Hopefully prefers-color-scheme[0] will take over soon.

[0] https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...


Additionally, the “prefers-color-scheme” media query exists, which is the standard way to bring dark mode to the web and solves all the issues listed in the article by being opt-in. Firefox hasn’t implemented it, but neither has anybody but Safari yet.


What you say is true for the default, but form controls have additional UA styles applied to them that can override the default.

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.


I looked through the bug report and couldn't find the specification you're referencing. Do you have a link to it by any chance?


Just found it!

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


If I read it correctly, what you just quoted is within the context of the <ruby> element.


I'm not really sure, but the thematic break element (<hr>) after the last paragraph mentioning ruby makes me believe its not.


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)


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


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.


> Looking at the google example, they are setting the font color

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.


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.


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

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.


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.


It was a problem for me using Firefox, but there's a workaround: You can set the GTK theme Firefox uses for inputs to a light theme.

https://bugzilla.mozilla.org/show_bug.cgi?id=1283086#c7


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.


There's nothing special about Chrome's implementation here. You can override the widget GTK theme in Firefox by setting the "widget.content.gtk-theme-override" configuration option to something like "Adwaita" or "Arc".


env GTK_THEME=Adwaita:light firefox

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
For my browser I run withtheme Adwaita:light aurora -P default

You can copy the firefox desktop file from /usr/share/applications to ~/.local/share/applications and edit the exec line as you please.


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.


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.


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.


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

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


> The author is trying to spread awareness that this seemingly common assumption about default colours is wrong.

I guess I could've made that point more clear in the post. Thanks for your replies in this thread :)


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.


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.


> 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

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.


Not disagreeing, but why is this a good thing? Apart from that it's fun, are users really expected to be able to improve their browsing experiences with custom CSS?


> are users really expected to be able to improve their browsing experiences with custom CSS

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.


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. There's a useless list for you!


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


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.


> 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


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


Try the firefox plugin "dark background light text"


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


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.


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


I'm not so worried about the theme of the site as I am about being able to read and enter text.

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 too much to ask of a web developer (/jk)


Perhaps @media(prefers-color-scheme)?


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


Something like the Docker solution would be fine;

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.


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


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


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.


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

Aside from the fact that many people prefer it?


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.


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.


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.


I prefer reading black text on white screens, thank you very much. Code in an editor is different because syntax highlighting is better on black.


I prefer syntax highlighting on a white background, thank you very much.


I happen to agree with you, but others might not. I'd rather the system just let the user decide, and that preference get propagated into the appropriate place.

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.


Dark mode on any Mac display results in massive reflections -- like a mirror -- unless you work in a near-dark office.


Best counterargument I've seen on this matter. Until low reflectivity on screens becomes the norm, I doubt we'll ever see a default dark mode or the riddance of the light mode.


Honestly this is only true when I'm in my basement cave. When I'm in the normal world with sunlight I need the standard brightness and white backgrounds.


Hmm... no.

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.


Inverting colors is not the right solution yet as it affects colors for everything, including things that you don't mean to invert. Browsing Twitter? All of the videos and images are now inverted. Anything that is nice enough to be in dark mode now appears super bright. Inversion would be better if it was "smart" and applied to interfaces, not content.


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.


I think you're misunderstanding something, though I can't pinpoint what it is.

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


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.


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.


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.


It is the developer's concern. If one layer of presentation sets either the foreground or background color, it also must set the other. The C in CSS is cascading. Different sets of rules can be applied with differing precedence. There's no spec that I'm aware of the states that black on white is the default user-agent styling. If your site is unusable with inverted colors, it's your site that's broken.


No, it isn't the developer's concern. You use cascading styles for a reason: so they can cascade. If I had to explicitly set the color, background color, font size, font weight, etc. everywhere, this would defeat the purpose of using CSS. It would bloat up stylesheets into giant download-speed-killing blobs.


Your website CSS is inheriting the system default CSS in a sense. If you're going to override one color, you should also override the other--or override neither.


There is a special relationship between foreground and background color that doesn't exist between any of the other things you mentioned. If one layer sets a foreground color, and another layer sets the background color to the same thing, the result is invisible text. That can happen with independently sane values for each. That cannot happen with any combinations of the other properties you mentioned.


> he author is using something that manipulates the style of inputs to make them dark with light fonts

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


The system is failing to override the styles. This is an issue with the system not using more explicit selectors or not taking into account that their selectors will be overridden. In other words, the system has failed you.


> The system is failing to override the styles.

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


User may not want the system to override styles, though. The system is providing defaults. The CSS overrides the defaults. The web developer has decided to override one default, but not the other default.


> The system is failing to override the styles.

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.


From the article:

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


> I think the issue should be fixed by the browser vendor really.

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.


Funnily enough I think this is specific to Linux, I've not encountered this issue under Windows, and I don't think macOS has a dark mode.


It does, since Mojave.


It does, but Chrome ignores it. I have no idea about FF, since I have developer FF, and it had dark mode before OS X did. (So, I presume it also "ignores" it, since it was dark when the system wasn't.) But AFAIK, FF dark mode doesn't apply to the controls within the page, only the browser chrome.


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


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.


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.


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.


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.


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.


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


Nowhere in WCAG 2 will you find anything that explicitly outlines both color and background color need to defined in stylesheets.

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


How does HN stack up in terms of accessibility? Anyone using a screen reader with HN? What do you wish was different?


I struggle with how low contrast it is. I skip 'Ask HN' style posts because they are too hard to read.


> I skip 'Ask HN' style posts because they are too hard to read.

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


Interesting. I mean, it works, I don't read those posts at all...


Can we get a source on this? Not disputing but I had never heard that before and it's interesting.



Wow, that's a ridiculously user-hostile approach to the problem.


HN was designed for a small audience, and it intentionally did things to discourage growth. The goal was to preserve the community for longer.


I understand the reason. That doesn't make it any less hostile to users with poor eye-sight.


If Hacker News wanted to discourage growth, they should have made the forum private and invite only.

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.


Are you sure HN isn't mainstream? It's up to 19 million items.


How many millions of users does it have?


I suggest highlighting the text to read in reverse video.


I wish the nesting of replies were visible in elinks. I just see one post after another in a linear fashion. I can't tell which post is a reply to which. That nesting is visible on w3m, though, so that's neat.

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


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?


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.


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


Both Safari and Firefox support the macOS Mojave dark theme


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


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


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?


Dark themes are just exposing these bugs in sites. They're still bugs, dark theme or not—this only occurs when a developer explicitly sets the BG/FG colour without setting a corresponding FG/BG colour—which would always be an oversight/accident. This doesn't occur if a developer does nothing.


> dark themes have only recently become widespread

Have they? I've been having this problem for around 15 years :(

Nice to see it brought up somewhere so prominent though!


I've seen people that had their default background colours to dark green since the Windows 95 era. This is not a new trend.

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.


It's always been there, just called something like "High Contrast" or "Plasma".


I'm pretty sure dark (or at least custom) themes came before the web.


How such uninteresting article can make it to the newsletter?

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


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.


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


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.


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!


I'm using GNOME 3 on Fedora 29 with the Adwaita-dark theme.


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.


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

Then you could track it with http://srcoftruth.com/


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)


[flagged]


This is not the problem. The parts of a HTML form control that are not defined through CSS are taken from the system default theme by the browser. Usually this is white on black, but this is NOT guaranteed (e.g. high contrast schemes for vision impaired users). Web designers tend to use these default schemes when writing the CSS for a web site. So they write only the attributes they need to make it work on their setup. So if the textbox background or text color is already what they want, they don't define it. This the browser takes the non-matching system color instead- precisely because it was set in a "dumbass" scheme (I resent this term).


Agree with the low contrast complaint, but the OP article is right. The web developers have assumed what the text field colors will be. So when they override one color (either FG or BG), they need to set the other one as well, and not assume that it will match what's on their own screen.


By "dumbass hacker theme" you mean "the dark theme that ships with MacOS", right?


Do you think mojave dark mode changes the colors of inputs on web browsers??


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


What does that have to do with color and backgroundColor?


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


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.


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)


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

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

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


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


I would say it's because light mode and dark mode are being inherited from system settings. Windows, Android, and iOS all have a concept of dark mode. The browser can pass these settings along (or allow an override).


> Are there equivalents for high/low-contrast? Red themes, blue themes, multicolour themes, etc.?

Not yet, although the API seems open enough to add this.


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


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.


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.


> 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?


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.


Finished now! I ended up switching my SASS variables over to CSS4 variables so I could override them with media queries.

Now to wait for better browser support.


I've migrated my website, FWIW, and I've seen a couple of other websites already adopting it. This is even considering the fact that no stable browser has enabled this feature.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: