Not all color schemes are legible

[baodrate]

A common problem I have when switching between color schemes is that many color pairs are not always legible. Text is often unreadable on certain backgrounds, or common assumptions about the relationships between colors is not consistent (making it difficult to set color rules in applications which correspond to each other; e.g. progressively darker backgrounds)

Common issues:

1. some color schemes don't properly have different values for each base16 color
   • blueforest, brogrammer, cupertino, edge, nova, etc.
   • or they're different but can't be visually differentiated (e.g. monokai)
2. relationship within background and foreground groups is not consistent
   • e.g. base04 ("Dark Foreground") is not actually darker than base05 ("Default Foreground")
   • brogrammer, gruvbox-material-light-hard, papercolor-light, ia-light, material-palenight
3. foreground/background colors are not different brightnesses of the same color
   • styling guidelines describes tehse as [Lighter/Darker] [Foreground/Background]
   • i.e. sometimes schemes use entirely different colors for base04-07 or base00-03
   • blueforest, codeschool, darkviolet, pico
4. base- 00-07 do not linearly increase in brightness (and reversed for light schemes)
   • most schemes follow this but it is not clear if it is a rule
   • heetch-light, ...
5. foreground colors are not legible against all background colors
   • tokyodark, ...
6. colors are not visually distinct
   • e.g. cyan too similar to blue
   • onedark, google-dark, one-light, ...
7. colors do not always match ansi colors
   • not sure how this can be enforced programatically, but some cases are obviously "wrong"
   • e.g. red (base08) yellow (base0a) and green(base0b) in pinky are swapped

ideas:

• set rules that define which colors should be legible against each other
  • amend styling guidelines
  • at the very least, foreground colors should all be visible against all background colors
  • ideally, all colors should have some minimum legibility when used as bg- fg- pairs
• write tests that programatically measure legibility/contrast ratio
  • W3 describes how to calculate contrast ratio from relative luminance
  • W3 Accessibility guidelines define a minimum contrast ratio; this would be a good reference
• determine distinctiveness programatically; ensure all color pairs are distinct
  • i.e. distance between color pairs in 3D perceptual color space (e.g. LAB)
  • more difficult to calculate than contrast, not included in e.g. python standard library; would need vendored algorithm or third-party library
• run these tests in github action

[joshgoebel]

Heads up: this would be affected by https://github.com/base16-project/base16/issues/11... it's not clear (at present) that all templates use the colors for the same purposes - despite what the styles spec says... for example Bash often prefers 16 colors in 2 sets of 8 colors with light and dark variants - and I think we should better cater to that possibility in the future.

I think this issue may be conflating different things though:

• accessibility
• personal preferences on what makes a good theme ("distinctiveness")

I don't see what's wrong with a "Black and White" theme that was #000 / #fff... You'd have only two literal (and very accessible) colors, etc... but not distinct (as in the 8 colors are distinct), yet I think that's would still be a totally valid and accessible theme. Perhaps I've misunderstood you though?

---

Other than (my perhaps misunderstood) requirement that themes have "multiple distinct colors" I can easily get behind all the rest of your ideas with regards to accessibility. I think APCA is the future here though: https://github.com/Myndex/apca-w3

And then you have to ask yourself what becomes of all the non-accessible themes?

Also (just to be clear) accessibility isn't a yes/no based on only color pairs... font-size matters a LOT... so someone might have a zany theme and if they use it at 52px font-size... it's perfectly accessible... so you can't TRULY talk about accessibility in terms of color alone. WCAG 2.1 recognizes this some and APCA goes even further in recognizing this explicitly.

So if we were to start mandating accessibility here we'd also have to decide a "minimum" font size in order for us to have any basis to declare many themes truly bad or good...

---

Often what is "accessible for all" at various sizes may start to seem overly high-contrast to many... so I'm not sure we should mandate accessibility. If someone wants to design a low-contrast theme, more power to them... but perhaps in our index of themes we should call out which are most accessible or have a flag for those that reach a certain standard of accessibility - to make it easier for users to filter.

[baodrate]

(For the purpose of this comment, I'll be referring to the set of 16 colors defined by these files as "palettes", for clarity)

Heads up: this would be affected by https://github.com/base16-project/base16/issues/11

I wasn't aware of this ticket, I haven't had a chance to read through it yet but I'll check it out in a bit.

it's not clear (at present) that all templates use the colors for the same purposes - despite what the styles spec says...

That approaches the problem I'm trying to illustrate. Without clear guidelines, the template authors cannot effectively use the colors. The styling guidelines are a "contract" that enable template authors and palette authors to design independently. Without them, how would the template author know to use base04 or base01 or base08 as the standard foreground color? Or whether base02 or base08 is more appropriate to use as the selection-bg when the fg is base0A? There must be some guidelines other than "any 16 distinct colors" otherwise there is no reasonable way to write a template that would work for all of the palettes defined in this repo.

for example Bash often prefers 16 colors in 2 sets of 8 colors with light and dark variants - and I think we should better cater to that possibility in the future.

1. How would a template be written that is agnostic of whether the palette is "standard base16" style (base00-03 backgrounds, base04-07 foregrounds, base08-0F colors) or standard ANSI colors (8-15 are bright versions of 0-7)? It can't. The colors must have some meaning, even if that meaning is only lighter than base03 but darker than base01 or one of the 8 distinct foreground colors.
2. The situation you're describing is specifically accounted for is the default terminal behavior. the base16 project is specifically designed to not follow this scheme. Instead it uses the 16-color space to represent an expanded set of background/foreground colors.
3. This is also why the '256' variant templates were made. (see any of the terminal emulator base16 repos). They're designed to retain the relationship of the 16 standard ANSI colors while moving base16-specific colors up into the 256 colorspace (now numbers 17-21)

I don't see what's wrong with a "Black and White" theme that was #000 / #fff... You'd have only two literal (and very accessible) colors, etc... but not distinct (as in the 8 colors are distinct), yet I think that's would still be a totally valid and accessible theme. Perhaps I've misunderstood you though?

Distinctiveness is an accessibility issue. The colors are used to represent semantically distinct things (e.g. "Comment" vs "Variable" vs "Keyword") as well as UI elements (e.g. status bars, tab colors, selected-text background, etc.). Your two-tone color scheme would render many UI elements literally indistinguishable from the background. To have a "statusbar" you would at least need three colors (application background, status bar background, text). Not to mention, you haven't described how a template author could be aware of which of the 16 belong to which of the two visibly distinct colors.

I think APCA is the future here though: Myndex/apca-w3

I haven't heard of this, I'll have to add it onto my color-theory research pile.

And then you have to ask yourself what becomes of all the non-accessible themes?

Personally? I would simply remove the ones that can't be corrected (and produce themes with e.g. foreground elements indistinguishable from the background), and deprecate the ones that are functional but inaccessible (for whatever "deprecate" might mean). But I wanted to leave the actual enforcement up to the maintainers/users. I'm mainly interested in establishing a clear, defined standard for what the 16 colors should actually represent.

Also (just to be clear) accessibility isn't a yes/no based on only color pairs... font-size matters a LOT... WCAG 2.1 recognizes this some and APCA goes even further in recognizing this explicitly.

I wasn't aware of ACPA, but I did read WCAG 2.1 and it specifies a minimum contrast ratio for "large-scale text and images of large-scale text" of 3:1. The only things that have no minimum contrast ratio are "incidental text" ("pure decoration") or "text that is part of a logo or brand name". All other text, according to the guidelines, have a minimum contrast ratio of 4.5:1. Either of those contrast ratios seem reasonable lower bounds to me (certainly, the base16-schemes itself has no control over the font size of the programs. there's no saying which colors e.g. iterm2 will decide to use for tiny text, so it would be reasonable to say that all colors combinations should clear the minimum contrast ratio requirement for regular text)

So if we were to start mandating accessibility here we'd also have to decide a "minimum" font size in order for us to have any basis to declare many themes truly bad or good...

As mentioned above, non-"Large-scale" text has a standard minimum-contrast-ratio requirement (per WCAG 2.1) so no minimum font size requirement would be required. (I haven't read ACPA yet)

so I'm not sure we should mandate accessibility. If someone wants to design a low-contrast theme, more power to them

Surely, there would have to be some minimum contrast requirement. Would a color scheme defined entirely between #243F4C and #2F5264 be merged? Even if I define base04 to be #2a4959? A contrast ratio of 1.16:1 seems low to me, for any standard of accessibility. Surely we can agree on some requirement for contrast, even if it's lower (or higher) than the W3's.

in our index of themes we should call out which are most accessible or have a flag for those that reach a certain standard of accessibility

That is mostly what I was alluding to in the OP. By "programmatic" and "tests" I only meant that this process should be defined in code (as tests run against each palette), rather than as a brittle, manual process. I didn't mean to suggest that failing palettes should be automatically denied or removed.

[joshgoebel]

How would a template be written that is agnostic of whether the palette is "standard base16" style (base00-03 backgrounds, base04-07 foregrounds, base08-0F colors) or standard ANSI colors (8-15 are bright versions of 0-7)? It can't.

Semantic colors help with that... template authors should TRUST the scheme authors... if we had the ability for a scheme to say:

• This is a bright terminal color 12.
• This is a dark background.

Then the template should trust that... one of the problems right now if that we don't give scheme authors enough ability to communicate intent to template authors. For example there is no great way to map our 16 colors to 16 color terminals - because our style spec doesn't speak to absolute hues at all...

Distinctiveness is an accessibility issue. The colors are used to represent semantically distinct things (e.g. "Comment" vs "Variable" vs "Keyword") as well as UI element

We may just have to disagree here... but I can at least tell you my understanding of these terms:

• accessibility is about legibility/visibility - is the font big enough, is the contrast good, is the font legible... if the content can literally be read word for word (think a written document, not software)
• distinctive syntax highlighting is starting to get more into "usability" or scanning "at a glance"... this can improves code readability sure... but it happens AFTER you reach BASIC readability/accessibility.

If I can't read it at all, it's inaccessible. If I can read it but it's just hard to tell a variable from a function that's less usable. I'm not interested in the argument, I just wanted you to understand my perspective - maybe it helps.

To have a "statusbar" you would at least need three colors (application background, status bar background, text).

Well obviously the status bar could be the application background.. I've seen this in several themes... so the TWO colors that matter are fg/bg... but I wasn't really arguing for "two colors" as much as I was that mono-thematic (greyscale, bluescale, etc) should still be entirely and I don't think they are "less accessible" than more colorful schemes - if the contrast from FG/BG was good.

At that point it's a preference - and I don't think we should deny people preference (in themes).

Not to mention, you haven't described how a template author could be aware of which of the 16 belong to which of the two visibly distinct colors.

Semantic colors solves that I think. This is also possible with the current guide... just set all FG items (and all 8 accent colors) to white and all "BG" items to black... if you wanted to support seach/selected you'd need a greyscale inbetween... I never suggested that the colors have zero semantic meaning- I'm aguing for the opposite - that they have MORE semantic meaning.

[joshgoebel]

and produce themes with e.g. foreground elements indistinguishable from the background),

Can you give me a few examples of the worst offenders here? So I can look them up...

n/m I went thru your original issues and see you often cited examples.

[joshgoebel]

so no minimum font size requirement would be required. (I haven't read ACPA yet)

You have to read ACPA... all the scores there have no meaning without adjusting for the font size... so to have a scale and give thumbs up / thumbs down we have to specify a specific "blessed" font size... That can be decided, I was only pointing out it's not exclusively about color pairs.

[joshgoebel]

Surely, there would have to be some minimum contrast requirement.

I don't believe in policing (with rules) the stupidly obvious. People should submit a snap or two when submitting new themes... if it's all a single color-ish and we can't read anything, we reject that theme. We don't need a rule for this, it's just common sense. IMHO.

I haven't really seen this though, so this feels like a strawman unless you're about to provide examples?

[joshgoebel]

A realized it might be more helpful if I addressed yoru common issues:

some color schemes don't properly have different values for each base16 color

As already stated I think this is a schemes choice. I don't think we should mandate that base09 is different than base10

base04 ("Dark Foreground") is not actually darker than base05 ("Default Foreground")

I think this is a guideline, not an absolute. If they were the same, that's fine. If a theme only has a singular BG/FG, that's fine.

Now if dark foreground is lighter, that's a bit strange and more worthy of discussion. I'm not sure (at first blush) if we should enforce this though as perhaps a theme is an "inverted" theme where it's purposely doing the opposite of what you expect.

foreground/background colors are not different brightnesses of the same color

It is not my understanding that this is mandated at all. I don't believe it should be.

base- 00-07 do not linearly increase in brightness (and reversed for light schemes)

I think it's a guideline, not a rule.

5. foreground colors are not legible against all background colors tokyodark, ...

We don't make this guarantee (other than perhaps default fg/bg)... though it's a fair question if we should... I think it's not clear at all what the rules for "Light Foreground (Not often used)" and "Light Background (Not often used)" are...

colors are not visually distinct

This is not mandated. Some people like this "look".

colors do not always match ansi colors

Hues are not mandated by the style at all (though they are sadly, remarkably consistent). I think this should be solved with semantic colors instead to allow the theme designer to specify how they feel their theme should be mapped to terminal colors. Matching is not always the goal. It's entirely possible a terminal scheme wishes to not match ANSI colors at all intentionally.

[joshgoebel]

If I had a suggestion here it would be to start with something simple, say measuring baseline accessibility... and write an automated tool for that... and then you could slowly add "optional" checks to that tool and as a community we could then decide which of the "optional" checks was worth making mandatory (whatever that means) and which weren't...

But work on the tool itself could being before any of the tiny details was decided... what about a few rules for starters:

• contrast: default FG / default BG
• contrast: most colors on top of default BG

And immediately you'd have something super useful for measuring the baseline accessibility of the entire ecosystem...

I'd want to have a tool like this in place before we starting making changes to the style guidelines to address this kind of thing... I'd want to know how many of our existing themes meet the new proposed guideline, etc... as I think that might give us pause or at least educate our decisions.

IE, if we have a great new idea but then we look and 99% of our themes would be in violation of the new rule, then either the new rule is bad or we need to have a version serious discussion about all those themes.

[baodrate]

(tl;dr at the end)

Semantic colors help with that... template authors should TRUST the scheme authors...

It wasn't clear to me that's what you were referring to. I see now you're proposing that additional aliases be allowed going forward so that templates can more accurately map colors to relevant elements.

I won't comment on that proposal for now, but it would not substantially change this issue (re: invalid/illegible schemes), beacuse this is referring to schemes that currently misbehave, and would still need to be corrected. In the case that the proposal in base16-project/base16#11 is accepted, this issue (base16-project/base16#46) can be simply understood to affect existing schemes for the "backwards compatibility" adaptations mentioned

but I wasn't really arguing for "two colors

Sorry, but you said "two literal colors" and specified "#000 and #fff" so I took it at face value.

greyscale, bluescale... I don't think they are "less accessible" than more colorful schemes

...

distinctive syntax highlighting... but it happens AFTER you reach BASIC readability/accessibility... If I can't read it at all, it's inaccessible. If I can read it but it's just hard to tell a variable from a function that's less usable

Perhaps you misunderstood what I was referring to as "distinct colors". I wasn't talking about hues, I meant literally 16 visually distinguishable #XXXXXX. A "mono-chromatic" palette with 16 visually distinguishable tones is fine (for the purposes of legibility, there are separate concerns with semantics).

My point was that:

• it should be (at the very least) physically possible for an average user to visually distinguish foreground colors from background colors (i.e. min contrast ratio)
• if no clear, enforced relationship exists between the baseXX designations and their prescribed usage in templates ("base00-base03 are background colors"), all color pairs must be treated as possible fg/bg pairs, and all 120 pairs must meet the minimum threshhold for legibility.

Well obviously the status bar could be the application background... so the TWO colors that matter are fg/bg

Sure, in the very specific case of a status bar, it's possible to substitute the status bar background for the application background. But obviously this is not the only thing base01 is used for. base16-rofi, for example uses it to differentiate selected menu items from the rest. Having base00==base01 literally breaks that template.

So that is a big assumption that is very obviously wrong for many templates. Many of the UI elements in base16-vim would be unusable.

I never suggested that the colors have zero semantic meaning- I'm aguing for the opposite - that they have MORE semantic meaning.

Again, I had not actually read your proposal at the time I wrote my reply (which I mentioned). But having read it, the "unbinding of semantics with aliasing" would only be relevant for schemes and templates going forward. All current templates expect base00-03 to be background colors, base04-07 to be foreground colors, etc. So the "backwards compatibility" you mentioned would still need to be established for the currently existing color schemes. In which case, we still have to actually codify what those relationships actually are, and correct the schemes that violate those assumptions.

I don't believe in policing (with rules) the stupidly obvious... We don't need a rule for this, it's just common sense

"Common sense" requires some mutual agreement as to what the basic parameters are. We can't seem to agree on what those parameters even are so I'm skeptical of deferring to "common" sense.

---

As already stated I think this is a schemes choice. I don't think we should mandate that base09 is different than base10

I don't understand what this means. A "scheme" (referring to the palette of 16 colors) has no control over how the colors are used downstream, and it's not clear to me (perhaps even less clear, after this discussion) what exactly a template can rely on, so how could the color scheme* possibly know what they are "choosing"?

Is the template not free to use base0A as a foreground color while using base09 as the background color? Should it be acceptable that (unknown to both the template author) that arbitrary UI elements be rendered invisible? Or should some requirements be set, e.g. "base09 and base0A should not be used to represent contrasting elements"?

foreground/background colors are not different brightnesses of the same color...

If that is the case, it should be clear. Because there are templates that use the graduations in perceived lightness to communicate information. If we can't promise that it should be made clear to consumers of the color schemes that they can't depend on this.

I think it's a guideline, not a rule.

To be frank, it should either be a rule or not mentioned at all. What is the point of an optional "guideline" if the consumers of the schemes can't actually depend on them?

If a theme only has a singular BG/FG, that's fine.

colors are not visually distinct

This is not mandated. Some people like this "look".

I'm not just talking about preference. I'm saying that consumers of these color schemes (i.e. application templates), expect that colors be visually distinguishable.

There's currently no requirement that app templates be functional in the case that base00-03 have exactly the same value. Many (most?) templates depend on them being actually distinct colors to render their UI correctly, breaking that assumption produces user interfaces that are quite literally broken. How is this fine?

If we're not going to guarantee that certain colors actually be distinguishable (even by a computer! not even talking about human perception!), then that should be made clear so that consumers of the schemes can know to avoid those color pairs, or those specific color schemes

---

tl;dr:

And immediately you'd have something super useful for measuring the baseline accessibility of the entire ecosystem... I'd want to have a tool like this in place before we starting making changes to the style guidelines to address this kind of thing

Perhaps I derailed this discussion from the beginning by mentioning the "accessibility" issues and associated tests. We can't begin to approach that issue when there are basic aspects that are functionally broken

Downstream consumers of these color schemes (i.e. templates) need to know which pairs of colors they can use to represent things that not only should but need to contrast. e.g.: foreground text from background text, selection from background, search result

We need to establish that either:

• base0A and base09 should have different values
• no template should ever use base0A and base09 to represent contrasting elements

At the moment, the only schemes that work consistently across most of the templates I've found look like this:

Color
base00	---- (darkest)
base01	---
base02	--
base03	-
base04	+
base05	++
base06	+++
base07	++++ (lightest)
base08-0F	8 distinct* values*

* (i.e. can be distinguished from each other by the human eye) ** with the added condition that, any color pair be at least legible when used as foreground and background.

any deviation may result literally broken interfaces.

My main suggestion is that the actual requirements be codified so that template authors can design the interfaces of their applications whithout making invalid assumptions.

[joshgoebel]

A "mono-chromatic" palette with 16 visually distinguishable tones is fine (for the purposes of legibility, there are separate concerns with semantics).

I'm saying more than that though... I've seen some themes that purposely only want to highlight specific syntactic elements, like only strings, keywords, and comments... they are very minimal on purpose... so that would only require 3 of the 8 "distinct" values and if a theme wanted to do that, I think that would be their choice. If someone didn't like such minimalism, they shouldn't use that theme.

At the moment, the only schemes that work consistently across most of the templates I've found look like this:

Yes, but I'm not sure this is the huge point you think it is. It seems impossible to be any other way. If some templates follow some of the guidelines and some themes follow some and then you aggregate ALL the templates - yes, you're going to be left with a case where the only schemes that look good in ALL templates are the "lowest common denominator" - ones that tried to read every guideline as a rule.

I'm not so sure that (with the current spec) that all schemes should look good in a all templates.

Again, the example of someone using Base16 to craft true 16-color terminal schemes (which don't have 8 foreground and background colors)... that is very likely to only work well (at the moment) with a singular template. Should we then say these aren't Base16 schemes and the template is not a Base16 template? I'm not sure. I think you'd lean towards yes and I'd lean towards no.

This is a big question that needs to be answered... are people pushing the boundaries welcome in the community or are they outside the spec?

I do think some of this can be solved with semantic colors... (but think we may have to let go of requiring 8 fg/bg colors per palette).

---

Is the template not free to use base0A as a foreground color while using base09 as the background color?

No, clearly that shouldn't be allowed in the short-term... but I think it wouldn't matter in the LONG term.... in the long term (if we go semantic aliases) then 1-16 are just numbers of the palette, no slot would have any specific meaning at all... if you wanted the base background color you'd say base_background_color in your termplate, not base00...

To be frank, it should either be a rule or not mentioned at all. What is the point of an optional "guideline" if the consumers of the schemes can't actually depend on them?

I do see your point but I'll point out again just one dimension: creativity... you could say in the spec: "for the best usability colors 8-16 should be visually distinct and often use different hues"... and I think that's a GREAT idea/guideline for most themes... but someone who WANTS a very minimal theme with only a few colors...

I think if they do that they shouldn't be "kicked out" or "not base16"... perhaps we need a new word or phrasing to describe schemes that follow ALL the guidelines perfectly...?

but it would not substantially change this issue (re: invalid/illegible schemes), beacuse this is referring to schemes that currently misbehave

True, but what is your suggestion again for those themes? I don't think either of us can fix them all overnight (short of removing them, which I don't think is practical)... I'm merely trying to work on the path forward so if someone said "hey this theme is broken" they would have the tools available to make a PR and fix it, etc...

I think there may be more agreement than disagreement but I feel like you're saying/implying:

Tighten up the spec, and lets kick out/penalize people who can't follow the rules.

And I'm more like:

Leave the spec alone (mostly), but lets promote those schemes that are the best examplars of Base16.

The latter feeling less "legalistic" to me... and doesn't require any immediate action against all the legacy themes...

Downstream consumers of these color schemes (i.e. templates) need to know which pairs of colors they can use to represent things that not only should but need to contrast.

Yes, I gave you a few minimal starter rules... I think the only things you can (minimally) GUARANTEE contrast against are:

• FG/BG
• 8 "accent colors" (base08-base0F) vs BG

I'm tempted to add some more of the other FG/BG variants, but I think it's important to first have a starting point... if we wrote (and ran) the test above and found out 99% of themes are in compliance, then we could add more rules...

But if only 80% are in compliance with such a simple expectation then I think we need to stop and say: Is this a rule or not? IE, add one rule at a time vs "making everything that's mentioned now a solid rule".

---

I'll try to drop off here a bit though and we should allow for some more voices here... these are just my and your opinions... we need more input.

[baodrate]

I'm not so sure that (with the current spec) that all schemes should look good in a all templates.

I'm not saying that all schemes should "look good", that's purely subjectively. I'm not even saying that they should all strictly accessible. My point is that, when a user decides to install the base16 schemes for their IDE/editor/utility/etc., they should never completely break the user interface. I figured it was reasonable to expect that switching to a color scheme would not make it impossible to read the app's menu items, but apparently that's too high a bar?

I'm saying more than that though... I've seen some themes that purposely only want to highlight specific syntactic elements, like only strings, keywords, and comments... they are very minimal on purpose... so that would only require 3 of the 8 "distinct" values and if a theme wanted to do that, I think that would be their choice. If someone didn't like such minimalism, they shouldn't use that theme.

A scheme doesn't get to choose how the colors are used! The project, by design, does not give the color schemes any tools to designate that X color should be used for Y elements. They literally cannot provide that information as is. So I really don't understand what you mean when you talk about "choice". How can a color scheme possibly know that "specific syntactic elements" are going to be conflated? As you said, they're only "guidelines", so there's no possible way for the color scheme to know that "base08 is used for strings and base0A is used for comments so those two can be the same color". That is simply not something it can guarantee.

I think if they do that they shouldn't be "kicked out" or "not base16"... perhaps we need a new word or phrasing to describe schemes that follow ALL the guidelines perfectly...? ... The latter feeling less "legalistic" to me... and doesn't require any immediate action against all the legacy themes...

I don't actually care about how things are enforced. I just want the standards to be clear. That's literally it. You could choose not to enforce it!

If the standard is "anything goes really", then there's absolutely no point to any of this. A template author that has to write individual templates for each color might as well just write their app configurations manually. Which is what everyone does anyways (e.g. solarized, gruvbox, dracula, etc.)

[joshgoebel]

it was reasonable to expect that switching to a color scheme would not make it impossible to read the app's menu items, but apparently that's too high a bar?

Well, obviously that's a pretty poor outcome... I think our difference may be in how do we prevent that. I wonder if some of these checks shouldn't be at the TEMPLATE level, not the scheme level... if Base16 stays so generalized (as it is now)... it may be that some schemes just aren't suited for application X or Y... we could detect that at build-time and exclude those themes from those applications.

It's possible one of the schemes that tears up your application makes a great Terminal theme...

This would be an entirely different approach, solving the problem from a different angle... the template can assume a LOT of fg/bg pairing that may not be guaranteed, but then it's the templates job to "bow out" if it seems that the final product it's building it just ridiculous.

A scheme doesn't get to choose how the colors are used! The project, by design, does not give the color schemes any tools to designate that X color should be used for Y elements.

Sure it does (even if not perfectly). The spec itself does that by assigning semantic meaning to certain colors (I'm largely speaking about 8-16).

As you said, they're only "guidelines"

Is that what we're getting hung up on - the absoluteness of it all? Obviously many/most themes follow the "guidelines/rules/whatever" regarding the semantic meaning of 8-16...Other than fg/bg mostly all your left with is 8-16... and I'd say those trend more into "rules" territory than "lighter FG must be lighter than FG" does.

They kind of have to since otherwise templates are mapping nothing other than fg/bg colors... So in those (majority) cases those themes are absolutely choosing how the colors are used.

Well, the spec is - if we're being pedantic... not everything I say should be taken 100% literally... obviously a template is 100% in control of output... but the spec itself gives the schemes power to say "i want diff deleted to be GOLD!"... by virtue of the contract (even if not absolute) with templates via the spec.

[joshgoebel]

Do you code in Javascript? If I open up the work I've done over in https://github.com/base16-project/base16/issues/26 would you be interested in adding in rules you feel as "important" and then we could start to get a better picture of where everything stands other than one-off examples?

We'd need to figure out how to "score" a scheme, but as soon as we did that you could start collecting higher-level stats on which schemes matched which set of rules, etc... might be helpful for a discussion of which guidelines to tighten or loosen...

A common problem I have when switching between color schemes

Out of curiosity which app/apps are you using?

[joshgoebel]

they should never completely break the user interface.

This seems wholly reasonable, but I don't see an example of this listed in your common issues (sorry if I miss it)... It's obvious that the potential (of all these individual issues) might lead to this (and I understand the desire to attack the problem at a high level)... but do you have some examples of a scheme/template combo that's literally "completely broken" because of these issues?

I think it could be helpful to open a few individual issues of such [terrible] brokenness and see what could be done to fix them on a case-by-case basis (while this larger issue simmers). And screen shots might help for those of us that don't have the specific applications in question installed so we can't just easily open up the themes and see how they look, etc...

This would also help educate us about how we should deal with such cases when we do have a way to discover them in a more automated fashion... (as you're suggesting here)

Update: It seems clear that just saying "this scheme doesn't follow all the guidelines of the spec" alone doesn't create a "completely broken" experience... that's only possible when a template assumes a guideline is a MUST and then uses a fg/bg combo that breaks (with certain schemes)... hence the request to identify individual broken scheme/template combos.

[belak]

I'm going to close this for now, because I don't think we have much of a plan to fix this at the moment - schemes have been user provided for a long while, and some of them just end up being more legible than others.

If there are issues with specific schemes, I think it would be great to bring those up with the scheme authors, or show examples and fix them in the schemes repo.