Improve contrast of text

[maxkfranz]

(1) The background should be much closer to black

(2) The text should be high in brightness (e.g. default text should be white/#fff)

This is a large usability concern. Without high contrast, text is much more difficult to read.

Comparison to Sublime:

Atom:

Sublime:

[simurai]

One dark is originally based on "base16 tomorrow dark" and is a low contrast theme. Mostly meant for in a dark room or in the evening/night. I agree that at day time, especially if the sun shines through the window, it’s not that usable.

Now because there is actually already a "base16 tomorrow dark" bundled with Atom, having 2 that are similar, doesn't really make sense. So yeah.. I think it's a good idea to have One dark be more high contrast. So it fits more environments.

[brandonweiss]

@simurai Is this the change that just went out that brightened The One dark syntax? I'm having a really hard time using it. The contrast is so high it's causing eyestrain and the colors are so washed out they're harder to discern.

Is there a way to add an option to this to switch between a low contrast and high contrast version?

[simurai]

Right. See the PR's description https://github.com/atom/one-dark-syntax/pull/30#issue-78815384 for some more infos behind the reasoning.

I can see these options:

1. Keep the base16 tomorrow dark theme updated with the same "logic" as One dark, just a bit darker colors. Although it wouldn't be the exact same as in One 0.8.2.
2. Create a fork of One dark, change the colors back to 0.8.2 and call it something like "One dark night" or so. Maybe not officially bundled, but as a community theme.
3. Try to add an option to change colors in the settings. Maybe like this: https://github.com/atom/atom/issues/5903#issuecomment-106163826

I think I'll try option 1 anyways (but won't solve it 100%) and maybe at some point 3. Option 2 would be the easiest, short term.

[brandonweiss]

1. This doesn't interest me personally (because I want the colors exactly like in 0.8.2) but I'm sure someone would appreciate an improved version of Tomorrow Dark.
2. I can do that, although there are so many commits in this pull request I'm having a hard time figuring out exactly which parts to revert. Would you be willing to make a git patch that I could apply to a fork? I'd be happy to maintain the fork.
3. I would love this. The best would be if the theme could have a settings page just like the Atom UI does, where you could toggle between High Contrast (new) and Mid/Low Contrast (old). I don't know if that's possible or not.

[brendanfalkowski]

Not too pleased with this change either. Honestly, the tipping point that convinced me to switch from Sublime to Atom was because the One Dark theme had such nice (lower) contrast. I tried Atom on/off for a year before that and couldn't make the jump.

No offense @maxkfranz but near black background and pure white foreground isn't better for usability. That's too much contrast and makes readers bleary eyed. If you're working in a bright space, then "One Light" is a better choice.

The WCAG 2 guidelines suggest a minimum contrast of 4.5:1 for small text, and there are tools to evaluate this:

http://leaverou.github.io/contrast-ratio/#%23999-on-white http://snook.ca/technical/colour_contrast/colour.html#fg=33FF33,bg=646464

I'd agree that One Dark's contrast could have been slightly higher, but not as much as this update (below):

The problem isn't as exaggerated when viewed on GitHub because the page is white, but with Atom full screen it's too contrast-y (especially working at night).

Note: on a retina MBP I don't mind the change as much, but until Apple releases a 27" retina display (and a laptop that can actually run it) the chunkier and contrast-y text isn't very welcome.

I'd really like to see "One Dark" dialed back closer to how its contrast was (but maybe slightly more).

---

The "Base 16 Tomorrow Dark" syntax (below) isn't a substitute. It's colors are too similar (desaturated and washed out) and it has distracting double underlines all over the place.

I'd prefer keeping One Dark as it was (the way I fell in love with it) and have a separate high-contrast syntax. I thought that's what "Atom Dark" (below) was supposed to be although it's a different palette.

[brendanfalkowski]

Also not liking how PHP and HTML tags are slightly offset red hues in the new "One Dark". The PHP tags used to be all white (like "Atom Dark"), so they were easy to spot.

[brandonweiss]

@brendanfalkowski Agreed.

Obviously there's a little bit of subjectivity here, and I don't want to belabor the point, but I do think the usability is now worse. I did a bit of experimentation with different light sources and the only scenario in which the new version was better was in a very bright setting, and it was only marginally better. Arguably if you're using a dark theme and it's too bright out the real problem is that you're using a dark theme when you should be using a light theme.

[mnquintana]

Arguably if you're using a dark theme and it's too bright out the real problem is that you're using a dark theme when you should be using a light theme.

I totally agree with this. I've given the new color changes a chance for a long time now, but this time I really dislike the changes. The color saturation is so washed out now that the colors seem somewhat anemic and harder to discern, and the contrast is high enough so it's not quite as easy on the eyes. Of course, this is all still pre-1.0 so it can and should be tweaked, but I'm not so sure this tweak was for the best. Following the reasoning in https://github.com/atom/one-dark-syntax/pull/30#issue-78815384:

Since it's hard to tell in what environment you're are when opening Atom for the first time, it's better to have too high contrast than too low.

If the contrast is too low (because it's bright out) you shouldn't be using a dark theme. One of the main reasons I loved One Dark from the beginning was that it was low contrast. I don't think we should try to alter dark themes to appeal to users who should be using light themes – they serve different purposes, and we should let them serve their different purposes.

When taking a screenshot and adding to a white page, like the docs or here, the white surrounding makes the screenshot seem darker than it would be on a dark background. So making it brighter, counteracts that a bit.

I'm not sure I get this one – I've never found readability to be an issue for screenshots of One Dark Syntax on white backgrounds.

Atom already bundles the lower contrast base16-tomorrow-dark, so people can switch to that, if this one is too bright.

As stated above, base16-tomorrow-dark really isn't a suitable replacement for One Dark.

And if it comes to it, forking an older version of One Dark is always an option, but I don't think anyone really wants to have to maintain their own custom forked syntax theme just to revert a color scheme change – that's a lot of overhead.

I really hope you consider reverting these color scheme changes.

[maxkfranz]

No offense @maxkfranz but near black background and pure white foreground isn't better for usability. That's too much contrast and makes readers bleary eyed. If you're working in a bright space, then "One Light" is a better choice.

(1) The contrast in the original version is far too low, regardless of the ambient light level. One light also suffers from overly low contrast. Consider smaller font size usecases. Consider users who may be less visually abled than you are. Consider older users. Text contrast should be maximised as a rule, and only lowered for special cases -- especially for main body text, like the contents of a file.

(2) There is no such thing as too much contrast with respect to text, else black text on white backgrounds -- a natural standard -- would not make sense. Lower contrast means the text will not be readable at smaller font sizes, as you've even mentioned yourself.

(3) The real issue you are noticing is not contrast but vibration. As I mentioned in the top, the brightness of the text should be increased. It seems that the saturation is too high for a black background, creating a neon-like vibration effect similar to cyan on red.

Rather than reverting, the saturation just needs to be dialled down while maintaining the high contrast (via brightness). This will resolve the vibration issue.

[brendanfalkowski]

@maxkfranz — We're going to have very different opinions on this I think.

---

1) I was speaking to a smart default not designing for the extreme (either extremely low or high contrast are not smart defaults).

Text contrast should be maximised as a rule

This is better:

Text contrast should be balanced as a rule

---

2) There is too much contrast. In real life (i.e. books), true black on white doesn't exist. It's closer to #333 on #eee: http://leaverou.github.io/contrast-ratio/#%23333-on-%23eee

Screens that use #000 on #FFF strain the eye because the display is backlit (unlike paper). Many designers deliberately choose an off-white background and non-black text is reduce contrast. Focusing on a narrow strip of dark surrounded by swathes are light-emitting white causes eye strain.

Too little contrast is an equal problem, but I chose this theme because it wasn't high contrast. That shouldn't have changed.

---

3) The new colors look washed out (more pastel). To me that signals brightness was increased and saturation was decreased. The changes make it harder for me to distinguish constructs in the code because all the colors are now closer to white than the middle where they're most vivid.

My eyes didn't have a problem distinguishing them from the background, but now they're all blending together.

---

I don't think we need to keep debating high vs. low contrast merits. I appreciate that people see differently.

Current problem

1. "One Dark" was a lower contrast dark palette that people were choosing specifically for that reason.
2. Some people wanted higher contrast.
3. The lower contrast palette was removed.
4. A higher contrast palette took its place.
5. Some people are upset, and others are happy.

Better solution

Here's what should have happened:

1. Leave the "One Dark" theme alone.
2. Create a new "One Dark: High Contrast" theme.
3. Both groups are happy.

At the speed Atom constantly changes maintaining our own forks for old syntaxes isn't productive. I liked "One Dark" in the first place because it was 95% my sensibility. If providing a configuration for higher or lower contrast is a possibility that makes Atom a much better product.

[brandonweiss]

@maxkfranz Yes, you're probably right, in that issue isn't specifically contrast but vibrancy at that contrast level.

The problem, though, is that the rules of contrast you're talking about are framed around solid text on a solid background. Contrast/vibrancy behaves differently with lots of colors. It's even different between white text on black background and black text on a white background. None of those rules apply cleanly to syntax highlighted text.

Desaturating the colors more won't work because they were already heavily desaturated in order to make the new contrast work, and they're barely effective as is because of it. I experimented with lowering the saturation more and it does help with the vibrancy but the colors are then even less effective. If you do a quick sample of dark syntax themes you'll notice that most are mid to low contrast. I don't think it's because programmers are cave-dwellers who ply their trade at night by the light of the moon, it's because we generally figured out that the best balance for a dark theme is mid to low contrast.

Maybe I missed it, but I didn't see anyone complaining about the theme when it launched. Myself and many people I know specifically switched to it because it was so perfectly balanced. But in the last day most of the people I know that use Atom either rolled back to an old version of the theme or switched to a different theme because One Dark no longer works for them. That doesn't seem like a good improvement.

[mnquintana]

Also @maxkfranz you compare the contrast of One Dark Syntax to Monokai from Sublime Text in your initial post – why not just use Monokai for Atom?

[brendanfalkowski]

Agree with @brandonweiss:

Maybe I missed it, but I didn't see anyone complaining about the theme when it launched.

Seriously. Where was the fire? Not this one thread I hope.

That's why it feels wrong that the prior "One Dark" is gone, and the high contrast variation wasn't made an option or separate syntax.

[simurai]

Added a sm-low-contrast branch that has the same colors as the version before.

Just in case somebody needs it. What the default should be, still needs to be decided.

[eoin]

I've also found that using this high-contrast version has been pretty tiring on the eyes over the last two days. It seems to me that it might be more appropriate for high-contrast to be an option, and perhaps not the default.

[simurai]

I'll see how easy it will be to add a setting, maybe like this https://github.com/atom/atom/issues/5903#issuecomment-106163826 to override the variables. But regardless if there is a setting or a fork, I'm still torn what should be the default.

Personally, I prefer low contrast when actually using a theme for many hours. I agree that it's less jarring. Also that there is already Atom dark (high contrast) and base16 tomorrow (low contrast), so One dark should be mid contrast, is a very valid argument.

But when looking from the angle that it's the first theme that people see when they install Atom, then I think the high contrast fits better. For reasons mentioned in the PR, but also, and I know this is gonna sound stupid, but the more vivid colors make it stand out more when used in documentation or marketing.. like the screenshot on the https://atom.io site. So the purpose of "One dark" is to be used, but also to "show case" Atom. Think of it as the default wallpaper that makes an iPad look good in ads, but that probably most people are gonna change later. So having screenshots with a low contrast theme, might make it look too dull when used on top of a white background.

Then I think it's hard to know what most people prefer. The most downloaded syntax themes are Monokai and Seti, which are both high contrast. Counter argument could be that they got released early on. And since they are well known themes, people might download them anyways without even using them.

[maxkfranz]

The main issue here is regarding defaults and accessibility. Certainly, people will have their favourite personal colour schemes, but that can be addressed with forks, installing secondary themes, etc.

High contrast is a necessity for accessibility, not only in the editor area but also in the UI overall. Consider a user who may not be able to see as well as you in your regular setup; there are many examples -- and here are a couple: Maybe he or she is less visually-abled. Maybe he or she is using a projector in the daytime, making it more difficult to see.

If you default to a low contrast theme, you have made it impossible for users like this to use the app at all. They can't even change the theme, because they can't read the UI. You generally won't find users complaining about things like this, because it's far easier to give up and jump ship -- and users are generally quiet with respect to feedback.

[Astrophizz]

I think a bright default is fine, but a low-contrast one should be available and syntax themes should not have such drastic changes made to them. If it needed to be made brighter for new installs, make a new syntax theme and set that as the default for new installs. Problem solved.

[brandonweiss]

@maxkfranz Yes, of course, accessibility is very important. But no theme can serve everyone. Keep in mind that One Dark Syntax (and One Dark UI) were mid-contrast, not low-contrast like Tomorrow Dark. Someone would have to be incredibly visually disabled to not be able to even see the UI enough to change the theme. That's an extreme edge case. Ditto for a projector. I have never seen a dark theme that looked good on a projector in the daytime. Basically everyone switches to a light theme when presenting. Trying to solve those minority problems is going to make the theme unusable for most people.

[maxkfranz]

In design, it's very appropriate to accommodate use cases like these -- especially for disabled people. It helps to improve the overall usability, as is certainly the case here. It's called the curb cut effect.

[mnquintana]

Again, @maxkfranz, I pose this question – why couldn't you just use Monokai which apparently meets your requirements for a high contrast syntax theme? There was no compelling reason for One Dark Syntax to change to meet one person's demands.

[brendanfalkowski]

I think the bottom line is we shouldn't destroy an existing syntax to take it in a different direction. Forking and changing the default doesn't disrupt existing users, but you need to decide what you're going to maintain.

I didn't realize Github even made the "One Dark" UI + syntax until months after it was released (I'd kept using Sublime because "Base16" looks bad in Atom). I only realized "One Dark" existed after I saw it in a package's screenshot on GitHub (and I switched to Atom full-time that day). I'd bet a large number of Atom's users are still using whatever was available when they installed Atom.

FYI, here's how my Atom and Sublime are configured:

http://manuals.gravitydept.com/workspace/mac-apps/atom http://manuals.gravitydept.com/workspace/mac-apps/sublime-text

@simurai I get the marketing need, but that affects one person making screenshots — not the other thousands using the software. Decision-wise I'd be really upset with Github if "One Dark" was changed permanently rather than Github maintaining a "screenshot" theme internally.

[brandonweiss]

@maxkfranz Yes, it is totally appropriate to accommodate for edge-cases like those whenever possible. A curb cut is a total win over a normal curb because both people who walk and people in wheelchairs can use a ramp equally well.

This scenario, however, is completely different. For most people mid-contrast was the perfect balance. There's a very small group that it doesn't work for because they have a disability, or they want to use it on a projector in the day time, etc. So the theme was change to high contrast and now most people can't use it because it causes eye strain. Objectively it is now less usable. This is a scenario where you design for the broadest possible case and then you make alternatives for the people who the main design doesn't work for.

[thomasjo]

now most people can't use it because it causes eye strain

Can you back this claim up? I'm happily using the theme, and I'm not victim of any eye strain as far as I'm aware. Making statements containing terms such as "most people" really need to based on more than the number of people participating in this issue.

Objectively it is now less usable.

What objective measures were used to reach that conclusion?

I'm not trying to be unnecessarily argumentative here, but some of the opinions and claims put forth so far in this issue, overall, really need to be challenged/tested.

[brandonweiss]

@thomasjo Empirically? Of course not. But based on the yeas/nays on the thread, everyone I've talked to in person, and the fact that nobody seemed to be complaining about it before and now lots of people are, I'm extrapolating that it's a problem for lots and lots of people—maybe even “most”. If it's a major problem now and it wasn't before then it is objectively less usable.

@simurai @brendanfalkowski Yeah, while I totally get wanting it to look good when you show it off, that's an extreme edge case. The primary purpose of a theme is for text editing. The percent of usage for marketing and whatnot is going to barely be a rounding error. It would make more sense to just have a special fork for screenshots or something. Also, for what it's worth, I think the screenshots of One Dark already look great.

[mnquintana]

I'm not trying to be unnecessarily argumentative here, but some of the opinions and claims put forth so far in this issue, overall, really need to be challenged/tested.

That is true, however, you've made your bias clear by only attacking one side of the argument.

But when looking from the angle that it's the first theme that people see when they install Atom, then I think the high contrast fits better. For reasons mentioned in the PR, but also, and I know this is gonna sound stupid, but the more vivid colors make it stand out more when used in documentation or marketing.. like the screenshot on the https://atom.io site.

Makes sense to me as a consideration, but I think there's one problem with this: the colors are significantly less vivid now. They're brighter, but much less saturated, which gives it a more washed out / anemic appearance to my eyes. So if that's a consideration for the default, then the high contrast version is falling short at the moment.

When One Dark Syntax started out I thought it was maybe a bit too low contrast, but I personally thought it had hit a sweet spot of contrast right before this update. We're not really comparing a low-contrast to a high contrast version here, in which case I'd tend to lean towards higher contrast than lower – we're comparing a mid-contrast version to a high-contrast version.

[maxkfranz]

@mnquintana I'm not advocating my preference. I'm advocating for what should be the default behaviour. If this theme should not change, then what theme is default should change -- i.e. a high contrast theme should be default. As I've reiterated: "The main issue here is regarding defaults and accessibility."

Whatever you choose to do or not do does not affect me personally, as I use a different theme to suit my personal preferences. I'm simply noting the accessibility and usability benefits of higher contrast text by default. I'm merely suggesting/commenting regarding an open source project -- as I work on them myself in the domain of UI -- and I know how defaults with respect to accessibility can have large effects on user adoption, satisfaction, et cetera.

[brendanfalkowski]

@maxkfranz So you don't even use this package, and you instigated a change that affects people who do use it and want it reverted...

How is that good open source contribution?

[maxkfranz]

@brendanfalkowski As I've reiterated several times before and as you must have read several times before: "The main issue here is regarding defaults and accessibility."

[simurai]

Ok, after some discussions, we decided to go back to mid-contrast.

We have 3 interest groups, each with their own priorities. But unfortunately, we have to make a choice.

Marketing:

Github maintaining a "screenshot" theme internally.

I was thinking about that too, but also thought that if people see a screenshot with vivid colors, but then after installing Atom the colors would look different, it would be confusing. On the other hand, cheating/altering stuff specifically for marketing purpose is maybe ok. Often stuff gets photoshopped or even rebuilt in 3D, just to make it look good as product shot.

Accessibility

I understand @maxkfranz's point about making it as accessible as possible. But I also agree with:

Someone would have to be incredibly visually disabled to not be able to even see the UI enough to change the theme.

Also, when you look how the OS does it, there are settings specially for accessibility. Like the option to increase contrast in iOS. In that sense, increase contrast is opt-in.

Active users

It's still hard to say what most users like, and the noise in this issue shouldn't be the only conclusion because most people only make noise if they don't like a change.

we're comparing a mid-contrast version to a high-contrast version.

Yeah, and also since there is already a high and low contrast theme. Having a mid contrast is a nice addition.

---

Settings

I'll still try to add some settings, maybe like this:

• High Contrast (for visually impaired, in bright environments or for projectors)
• Default (previous version)
• Vivid (current version, for marketing)

[djch]

:+1: I'm one of the ones who prefers the mid-contrast version and is struggling with the latest update somewhat.

Don't want to add any more noise, but just wanted to give some props to @simurai for carefully considering all the different (quite valid) opinions being argued here, working to come up with a good compromise and documenting his (or her) decision making process.

[brandonweiss]

:+1: Yes, definitely. We really appreciate all your hard work, @simurai!

[simurai]

Reverted. Will be in the next update.

Writing the actual code is so much easier than making decisions. :wink: But having these discussion in the open is great. Thanks everyone for chiming in. :bow:

[xlaywan]

+1 for setting to choose contrast.

[brendanfalkowski]

Glad the original (mid-contrast) version is sticking around. Just for reference, posting the two palettes that were being discussed. The high-contrast version does "pop" more — especially on this white page — but I'd still argue while using Atom it's too washed out and less comfortable than the original mid-contrast palette.

Thanks @simurai + others for debating. It'd be nice to see the "One Dark/Light" themes extend with some contrast adjustment tools built in, so this doesn't have to be multiple themes. Maybe like a "gain" control that acts as a multiplier for saturation and/or brightness. Then you could keep the base hues, and shift the appearance by degrees rather than units (like saturation x 0.06) not (like saturation + 10) to keep them in proportion. Possible?

[simurai]

Maybe like a "gain" control that acts as a multiplier for saturation and/or brightness. Then you could keep the base hues, and shift the appearance by degrees rather than units (like saturation x 0.06) not (like saturation + 10) to keep them in proportion. Possible?

There was once a working prototype where you could change hue/saturation/brightness in the settings: https://github.com/atom/settings-view/pull/275. But that had to be put on hold because there were issue when live updating.

One day I still wanna try to add a select so you can at least pick between a few presets.

[Astara]

I just want to add, not that anyone is likely to do anything useful about this issue, but that 'Vim' (gvim) allows user-color sheets (that can start from copies of included ones). Each area can be modified using X11-color names OR HEX #RRGGBB colors. This allows modifying the background and all colored fields to exact values for anyone's preference, limited by your display (and patience in choosing the exact right shade for a given purpose!).

I'll have the color file open in one window... make a change, and in the target window w/hilighted source code, after I've made a change, I hit ":" and "up arrow" and "return" (recalls previous line and executes it), to re-execute the "color FILENAME" that I'm editing in the other window. While it *could be an easier interface with color-pad and/or arrows to increase/decrease colors, at least it prevents problems like the above from being problems as anyone can create a color sheet and even submit it to the vim-website for inclusion in the color-sheet lib (and, based on popularity, make it into subsequent releases).

Vim's had this feature for ... oh, maybe 10-15 years? Would be so nice if everyone could know about everything that's already out there so ideas wouldn't have to be re-invented or discovered. How else can software progress?

Cheers! (and who knows, it's nearly 2 years after this was first reported; maybe the feature is already in the product and way better than vim's :-) .

[winstliu]

@Astara check out your ~/.atom/styles.less :wink:

[rahulcyadav]

Finally where do I get the high contrast theme?

[locofocos]

For anyone wanting a quick solution to raise the contrast of comments (my only nitpick):

Edit ~/.atom/styles.less and add a snippet like:

atom-text-editor .syntax--comment {
  color: #6d7585;
}

(I'm on Atom 1.28.2)