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.
> 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."
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.
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 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.
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.
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.
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.
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.
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".
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.
> 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.
> 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) ;)
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.
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.
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?
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.
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.
...what? Set the default color in your dumbass hacker theme too. This has nothing to do with accessibility, which is obvious because the author thinks a gray background with lower contrast for text reading is better.
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.
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- preciselybecause it was set in a "dumbass" scheme (I resent this term).
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
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 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".
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:
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.
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.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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:
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.
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.
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.
"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."
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.
> 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.
> 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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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?
150 comments
[ 3.5 ms ] story [ 193 ms ] threadGood 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:
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...
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
For my browser I run withtheme Adwaita:light aurora -P defaultYou can copy the firefox desktop file from /usr/share/applications to ~/.local/share/applications and edit the exec line as you please.
https://bugzilla.mozilla.org/show_bug.cgi?id=1283086#c7
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 :)
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.
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.
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.
[1] https://news.ycombinator.com/item?id=19056752
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.
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
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
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).
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.
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)
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
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.
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.)
Thanks again!
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=70315
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.
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.
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.
Then you could track it with http://srcoftruth.com/