Something I'd like to point out that seems to be consistently missing from the present studies and the discussions that come up every time this topic gets poste

Something I'd like to point out that seems to be consistently missing from the present studies and the discussions that come up every time this topic gets posted again. Not only are the "decide if this string of characters is a word" tests showing a maximum difference of around 30% for dark v light mode in simulated night with small fonts but, that's not what most people are doing most of the time when reading things and it's certainly not what programmers are doing when reading code. So that almost certainly does not translate directly to X% slower reading performance in real world scenarios. This real world vs lab test difference alone can easily account for why so many people assert that dark mode is better for them even though the evidence sometimes suggests it shouldn't be. And that doesn't score a point for either camp. It means there's still much we don't know. So any conclusions are tentative at best. Studies on the mechanics of reading, especially on the web, have shown that much of the time people are actually scanning and identifying whole phrases or sentences as one pattern. Hence I can write and the cow jumped over the moom and more than half the people who read that will not notice the second m swapped in. Same trick applies with jumped over the room. Which many will literally see as jumped over the moon even though two letters are different now and it's an actual different word at the end. It's even harder to see correctly because I already primed your memory with the typical phrase. Of course, people unfamiliar with that phrase won't have a problem with it. They have to parse each word anyway. No bigger pattern in memory. This is even worse when people are scanning whole web pages looking for patterns that might match content they are interested in. And most of the time programmers are reading blocks of text, it is to find an answer or concept they need in order to continue coding. Quoting the same group as in the OP: https://creativehandles.com/blog-posts/79/4-types-of-eye-tracking-patterns-how-people-don-t-read-on-web https://creativehandles.com/blog-posts/79/4-types-of-eye-tra... People do this in speech too, try making a statement to some friends that sounds phonetically similar to a common catch phrase or something you know they'd be triggered by but actually be saying something different and benign. See how often they react as if you said the common or triggering phrase anyway. For extra fun, follow up later and see how many people swear they actually remember you saying the thing you didn't say. I suspect this pattern recognition trick is even more at play in reading and writing code. When one is fluent in a language, we don't actually need to read the symbols to know what a block of code is doing. Structures are so deliberately similar that one can recognize conditionals and loops for what they are without reading the words "if" or "while", this goes on to the content of those blocks and any function calls as well. Many functions use similar names for similar actions in code regardless of the program space because humans being humans. To spot this one in action, take notice of how certain ways of writing particular programming patterns are jarring every time you read them, to the point that you feel the need to change it even though it's perfectly functional. It's not the code per se, it's the readability. It's particularly egregious when someone gets a pattern around 70 to 80% correct but then does something different for one or two components of the overall pattern. You get annoyed reading it because it's like hearing someone mispronounce a word or change one word in a commonly used phrase. The pattern is there in your brain, it starts to match, you build up an expectation that the next parts will match. If it does, satisfaction; if it doesn't, frustration. Now your brain has to do more work to read in and learn what the non-matching parts are doing. This expectation tells you that you would rather be pattern matching large blocks of code than reading each syntax element. When reading in this manner, it's actually more important to have proper syntax highlighting than any specific contrast ratio between the background and the text. I could totally see light mode being a consistent hindrance here too. Not sure about that but it would explain a lot about the prevalence of preferences in general population vs programmers. For good syntax highlighting you want a lot of colors that contrast against both the background and the other syntax elements. Some shades of yellow and green probably don't do as well against a white background as a dark one for example, especially if used for similar shaped elements that often show up close to each other. Regardless of how that goes, or if we ever even find out whether this matters to the light v dark debate, the nuances around the way humans read differently in different situations are not even being addressed in the studies yet. That observation alone should give people pause before confidently claiming to know anything here and certainly before asserting that someone is wrong to have the preferences they have. Just something to think about.