All sorts of questions about colors 0-7

[joshgoebel]

Related: #34

Colors base00 to base07 are typically variations of a shade and run from darkest to lightest. ... In order to create a dark theme, colors base00 to base07 should span from dark to light. For a light theme, these colours should span from light to dark.

base00 - Default Background
base01 - Lighter Background (Used for status bars, line number and folding marks)
base02 - Selection Background
base03 - Comments, Invisibles, Line Highlighting
base04 - Dark Foreground (Used for status bars)
base05 - Default Foreground, Caret, Delimiters, Operators
base06 - Light Foreground (Not often used)
base07 - Light Background (Not often used)

So as we often see illustrated in yaml (commentary mine):

base00: "090300" #  ---- DARKEST BG
base01: "3a3432" #  --- less dark BG
base02: "4a4543" #  -- medium bg
base03: "5c5855" #  - brightest bg
base04: "807d7c" #  + dark foreground
base05: "a5a2a2" #  ++ default foreground
base06: "d6d5d4" #  +++ brighter foreground
base07: "f7f7f7" #  ++++ very bright foreground

So other than the #34 which seems entirely off I have a bunch of questions (and some of these stem from my conversation over in not all themes legible.

• base00/base01 - Why must my status bar always be lighter than the background? Perhaps i want a "jetblack" (#000) UI statusbar and #222 dark background. Why can't I have that?
• base03 - Why does base16 need to have an opinion on what shade my comments should be? By putting it in the middle of a gradient slope it seems to give me no choice. (not to mention if I want a different hue entirely for comments)
• base03 - How does one distinguish a line highlight from a comment? (or are we now implying an inversion of fg/bg usage [using a BG color as FG], this isn't clear at all)
• base06/07 - Perhaps these should go away long-term if we can't offer any more guidance...
• base01 - Why must line numbers and folding marks always be lighter? And is this referring to the line number/folding marks BG color or FG color?
• base02 Why must the selection always be brighter than the background... one could imagine using a darker shade for the selection.
• base05/base00 Why is "Default BG" the first/darkest color where as "default fg" is a middle color of the FG range? This seems inconsistent.
  • What choices do I have if I want my default foreground to be bright white?
  • Are base06 and base07 just useless then (also bright white now)?
• base05 So I can't ever colorize operators or delimiters? Some non-base16 syntax highlighting i've seen does a great job of coloring operators.

---

And now getting to a non-one liner...

are typically variations of a shade and run from darkest to lightest

If this is desirable (for UI purposes, shaded buttons, status bars, etc) then I'd consider (if the scheme allowed) letting templates perhaps choose their own shades of the BG/FG... (and then bare the responsibility for making them legible)

(yes I'm about to venture off into semantic colors and entirely diff ideas now)

background: "000000"
foreground: "ffffff"
allow_mix_FGBG: true

And then the templates would be able to request alpha blends of background and foreground... yes this opens us up to more than 16 colors, but NOT more than 16 hues.

Why do I ask this? I want to answer the question:

How can we support apps with UI bits (that need 8 shades of FG/BG) but also apps with no UI bits (like Terminal) that really would prefer 16 colors dedicated to ANSI.

I'd like to think (with care) we could expand our scope to support BOTH of these things.

I was going to try and figure out what to do about "legacy templates" but I think perhaps I'm overthinking it... if we add big new features and new templates to support them... perhaps if a scheme is "old" then that template just won't build it... if you're using say a new modern Terminal template that wants 16 ANSI terminal colors - but the scheme doesn't provide that - then that scheme would simply be skipped over... and only schemes compatible with that template would be built.

[MultisampledNight]

By the way, about the blending thing: Blending the RGB value linearly from 0 to 1 won't really fit the issue. If at all, I'd want to set LCH lightness stops for possible shades. Also background and foreground don't have to be the same hue.

[joshgoebel]

If at all, I'd want to set LCH lightness stops for possible shades.

Yes, exactly the kind of feedback we're looking for.

Also background and foreground don't have to be the same hue.

Of course not, but this also is really a concern of each individual style spec - they can be as forceful or lax as they wants in enforcing hues/color relationships in the palette. Personally I prefer more flexibility vs hard and fast rules. Base16 tends to be pretty flexible in this regard with it's liberal use of "typically" rather than "must".

More concern here has been expressed about legibility... schemes doing weird things with their colors such that a template can't be sure which fg/bg have contrast...

[belak]

I think it's unclear if/how this is actionable so I'm closing it for now. There's a possibility that most of these would be resolved by semantic aliases, but if there are other tickets or proposals which should come from this, please feel free to file them or let me know.