tinted-theming / home Goto Github PK

for example, how much approvals should be for merging

I think it's strange to attach this to the README so tightly.

Happy to make PR if this is approved.

Why do we encourage a proliferation of builders when the spec itself is so precise? Wouldn't a single canonical builder in a popular language be easier to maintain and push the spec forward with new features, etc? It seems like a lot of duplicated effort and destined to lead to "dead" builders... (which has already happened over the intervening years)

It seems easy to show how the community benefits from additional templates and themes, but much less so from having many fragmented builder implementations, each implementing a different version of the spec, and in slightly variant ways.

Recently the idea was floated of perhaps not letting older builders [old spec] into the new organization... that has it's own problems (IMHO) but only solves the problem today, not tomorrow when the maintainer of builder-xyz is hit by a bus and no one else really cares about xyz because abc/def/ghi builders work so well...

Obviously if someone really wants to build a builder it's a free world - but should we encourage this vs one official builder that works on all popular platforms? (OS X, Windows, Linux, etc)

I'm beginning to think that each should perhaps have their own repo:

• https://github.com/new-org-name/base24
• https://github.com/new-org-name/base17
• https://github.com/new-org-name/ansi16

That gives each spec room to spread out:

• README / marketing
• spec
• sample screenshots
• perhaps some simple example schemes / templates
• mini-builder (if we switch to mini-builder modules)

This is based on our new direction of supporting multiple style specs and empowering creators, etc... and it also easily allows specs to live wherever - in contrib, or even outside the organization. It seems obvious (after recent experience) that some spec owners would desire this - even if it's sub-optimal in some ways.

Thoughts?

This is the companion issue to #51. We're leaving the discussion here to avoid any heated discussion on that issue, which aims to describe what happened during the controversy, explain where we were coming from, and what we plan on doing next.

What we have done so far to eliminate any confusion that "we are base16":

• rename our main planning repo from base16 to home
• rewrite the README to make it clear we're an initiative that supports multiple style systems including Base16 (with links back to Chris's own repo)
• change the visible org name to "TBD (formerly Base16 Project)
• fully rename the organization (still in discussion to find the right name)

Well, I was hoping it wouldn't happen like this, but because there's no more base16-schemes-source repo (it seems to have been removed or deleted), backwards compatibility with previous builders is no longer possible.

If anyone has any backwards incompatible changes they feel like would be good to get in soon, let's discuss it here and see what we can do.

If possible I do think it would be best to still maintain compatibility with templates.

I'm posting this as a follow-up to #46. I think that issue is very broad so I'm suggesting we start a bit smaller, with a single piece of the puzzle. Lets find some agreement there, and then expand the scope. I'd choose to start with raw accessibility.

It seems the first critical matter would be the accessibility of our baseline FG/BG pair, I'm referring to:

• base00 - Default Background
• base05 - Default Foreground, Caret, Delimiters, Operators

If a theme was going to get one thing right, it should be this... my understanding is that this would be all text that isn't targeted for some more specific syntax coloring, ie, potentially a LOT of text.

So I'm just running a quick scan on the entire schemes repo using the APCA-w3 library... asking it for the Lc (contrast) value of our key base00/base05 pairing... the negative values just indicate a reverse pairing (ie dark mode, vs light mode)... the positive and negative numbers are comparable. If you decide 75 is good then you should be happy with -75 or +75 equally.

Here is how our themes currently breakdown:

• 6 themes < 30 Lc
• 24 themes < 45 Lc
• 63 themes < 60 Lc
• 133 themes < 75 Lc
• 199 themes < 90 Lc
• 232 themes total.

(this is not banded, so the < 45 includes the <30 etc)

Unlike WCAG the numbers must always be adjusted for font-size... so a 50Lc might be fine at 64px but terrible at 16px... (see the font table below)

So if we're going to have a rule (or guideline) at all we first need to decide on a "minimum text size and weight" that we're going to use... and that would tell us which Lc range we should be targetting.

APCA defines 30 as the "minimum contrast for any text" so I'd say 6 of our themes are failing terribly by any measure... For refernce:

Brogrammer - Lc -19.869322853654854 4e5ab7 / 1f1f1f
Icy Dark - Lc -15.169801465395219 095b67 / 021012
Pico - Lc -17.39516172313664 5f574f / 000000
summercamp - Lc -25.150557587757106 736e55 / 1c1810
Tokyo Night Terminal Storm - Lc -29.978792297475426 787C99 / 24283B
vulcan - Lc -28.231727048649518 5b778c / 041523

The most similar to WCAG 2.1 AA accessibility (for those familiar with such things) is APCA Lc 60... of which 63 of our themes fall below. The WCAG 2.1 AA "large text" is comparable to APCA Lc 45.

I had includes the tables here but GitHub zooms them hugely so I think it better to link to the APCA library:

https://github.com/Myndex/apca-w3#font-lookup-table

I've create a new repo for what I'm calling the Base17 style guide: https://github.com/base16-project/base17

Ref: #11

I'd love feedback, the spec itself can be found under style_guide.md.

In my opinion this is how we move forward - now that Chris has reasserted his ownership of Base16: by creating our own style systems - that are wholly our own and we can evolve and do with them as we like.

• We leave the Base16 style spec alone - if our tools work with it (and I think they should) great, but we shouldn't be changing or evolving it under the "base16" auspice.
• We create a new forwards compatible spec, Base17 - so allow us to evolve the system. All Base16 schemes are valid Base17 schemes - just base17 allows you to start doing more (better control of syntax highlighting, etc).
• We rename base16-schemes to base17-schemes and then we can begin to evolve the base17 style system (that we own) - or introduce additional style systems (Ansi16, etc)
• Existing base16 templates can compile base17 (with slightly lower fidelity) and new templates can fully process the new features of base17.

I think getting our tooling to accept and work with the fact that there are real and divergent (the input files won't all look the same) style systems is the first step to making all of this more concrete.

Originally posted by @joshgoebel in #11 (comment)

I've been quite involved in the sous-chefs org, so I know the benefit of community orgs. I'd like to move over

• https://github.com/josephholsten/base16-mutt
• https://github.com/josephholsten/obsidian-base16 (which needs a complete rework)

It would be useful to know:

• what state may a project be in before being adopted
• what obligations should then maintainer agree to before moving over the repo
• any other concerns

Example: https://github.com/sous-chefs/meta/blob/main/docs/transfering-a-cookbook.md

Ref: tinted-theming/base16-builder-node#9

Lets take synth-midnight-dark.yaml:

scheme: "Synth Midnight Terminal Dark"

This means the generated slug will become: synth-midnight-terminal-dark. This has always been the behavior of the node builder.

It seems the spec (0.9.1) disagrees:

Where the slug is taken from the scheme filename made lowercase with spaces replaced with dashes and extension is taken from /template/config.yaml.

It seems the spec has always said this, so that's not optimal (for me), but still I feel this behavior is wrong (or at least concerning)... I'll try to lay out why. I'd like us to consider perhaps changing this behavior and rule that out before I take the time to patch node builder.

The issues I see:

• It causes confusion about the scheme name.
  • Is the name in scheme or is it the filename?
  • If the actual name is in scheme why should the filename not reflect the canonical name?
  • Are light and dark important parts of the name or not?
  • What does it mean when these conflict? Is this not problematic?
• It stores critical data about how to build the scheme outside the scheme... the filename is not part of the scheme's data.
  • Renaming a scheme's file should not change it's canonical name.
  • I should be able to store the scheme's data in a database and still generate correct themes (without any file system).
  • The fact that I can't do this means key data is missing from the scheme.yaml files.

I can understand why this decision was made (to use the filename) for convenience, but I think we should perhaps revisit the issue in light of the downsides.

Thoughts?

In the README and spec, we use base16, Base16, Base 16, and base 16 in different places. We should choose one to standardize on and stick to it.

I personally prefer either base16 or Base16 (without the space). I think Base16 would be better because having base16 in titles would look strange when the rest of the title/heading is in title case, but that's only a slight preference.

I almost feel like issues should perhaps be turned off on base16-schemes and those issues redirected here, where there is much more traffic - and plenty of general discussion about Base16 already. Several projects have policies like this to keep issues more focused.

Thoughts?

We wanted to briefly document the recent happenings for those of you who’ve been involved and expressed excitement about the new organization and our hope to renew development and excitement in and around the Base16 (and peripheral) ecosystems.

Who are we?

The core organization team are all contributors to Chris’s original Base16 project and/or its many pieces of spec, schemes, tooling, templates, etc… Some of us have more than 5 years of experience working with the project. Between us we actively maintain the:

• base16 Go builder
• base16 Node.js builder
• base16-emacs
• base16-highlightjs
• base16-vim
• base16-shell
• base16-fzf

The Original Plan

When we began this project, the original idea was to migrate the base16 project to a GitHub organization for community maintenance and to solve the bus factor. Originally, this had seemed like something Chris didn’t fully see the need for but was “fine” with (given community support), as discussed in an older issue:

Chris: If someone wants to go ahead and create an organization and gets everyone to agree to putting their builders, schemes and templates in there then fair enough. Personally, I'm not so keen on the idea of having a base16 organization as I don't see the need but as I'm only interested in sharing my idea and helping others take this idea further, whatever the community sees as the best way to do this is fine by me.

So a new GitHub organization (base16-project) was created, repos were forked/copied/moved, links were updated, issues were opened, some real progress was made - and a full month passed (without incident).

What went wrong?

Unfortunately, we’re still a bit confused about that. Chris returned and for some reason appears to have had a change of heart. Perhaps some particular aspect of the transition upset him? We have no idea. Several of us have attempted to reach out (via multiple channels). He has actively blocked members of the new organization on GitHub, ignored our invitation to join, and declined all requests to communicate.

This first came to our attention when all of his base16 repos disappeared from GitHub - we assume he deleted them. After someone commented on their absence he added them back the next day - but their lengthy Git history is gone and he has changed the spec licensing from MIT to CC-BY-SA-4.0. He’s also suddenly turned off issues on many of his repositories.

Until and unless he gets in touch we’re still unclear about what exactly is going on.

What now?

Given the progress we've already made (including the big move to community ownership) we still believe the organization can provide real value, so we press forward. There was never any intention to take the base16 name against Chris’s wishes - so over the next month we’ll work towards renaming the organization and pivoting our focus. This should help avoid the confusion between two different projects named base16.

Our build tooling will continue to support version 0.2 of Chris’s base16 styling spec as a first class citizen. We have forked and consolidated schemes over to this repo for convenience. We had some great ideas for improving the base16 style spec. Now we’ll be coming up with a new name and new style spec for those ideas. We also plan to look into supporting a number of additional color scheme families in the future (such as base24 and a new one based on 16 ANSI colors).

How can you get involved?

We want to get the community excited and involved in working on styles, schemes, and templates again. We’d like to imagine the best things are yet to come.

We plan to have a list of public concrete goals once we manage to get some more momentum and discussions on some GitHub “issues”. If you’re interested in being involved in any area, we encourage you to start making PRs or issues on the organization's repositories.

Editor's note: When this was written, the spec repo had been changed to CC-BY-SA-4.0, but it was later switched back to MIT.

If you have any questions, concerns, or ideas, please feel free to bring them up in this companion issue.

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

Hi

As discussed in #2, I would like to transfer the ownership of base16-qutebrowser to this project. I plan to further maintain it.

Can you please give me the required rights?

Thanks.

Feel free to take this issue and make it your own.

Following recent discussion on the Base17 proposal I have some concerns with how it's being perceived and how it fits into the broader plan/ecosystem.

@belak: Plus it would allow base17 color schemes to be loaded as "just" the colors and used with base16 templates, even if a builder didn't want to support the "full" base17 spec.

This is the core of my concern - the thinking that base17 schemes could just be "used as base16" if one just ignored the semantics/variables and use just the 16 colors... this is simply not possible once people start to use semantics. The base17 scheme that comes out of a base16 template will be downgraded at best, or worst completely broken/different. This is not a good experience for scheme designers or users. It's the Nord problem all over again - one of the key issues that Base17 is trying to solve - not make worse.

This thinking has implications for how we deal with existing base16 templates... continue to just "pretend" they support base17 (when they don't) gives scheme authors no reason to upgrade to base17 - if all their new changes won't show up in most apps... and worse now their scheme looks different in different apps. So they actually have reasonable reasons to NOT upgrade.

I think it might be better to just rip off the band-aid. If someone re-authors/remasters a scheme to support semantics, then it does so 100% - BUT only on new semantic aware templates. Base16 themes can be easily upgraded to semantics (given their fixed semantic scoping), but there is no going backwards once those semantics become disassociated from the basexx colors... ie, Base17 can't be "boxed" back into Base16 without seriously breaking.

These are all reasons why I don't think it would be good to encourage (or support) builders that "half support" the spec...

It's possible Base17 could still be a "transitional" format whose sole benefit is the ability to "correct" some of the worse semantic pairings of Base16... but even so this has all the disadvantages mentioned above of where and when these fixes would actually work.

I think the largest question here is how we get from a Base16 scheme/template ecosystem to a fully-semantic Base17 scheme/template ecosystem....

I personally see the future as semantics - we define a "minimal set" of scopes that a theme creator must define for a good result... for example most TextMate themes (used by many editors) one can define ~24 key scopes for very good results ... so the focus would switch from defining a base palette to defining key (independent) semantic scopes... I'd go so far as to suggest the base palette go away entirely. The # of colors restriction can easily be kept (or not) without having to define the palette explicitly.

Switching to full-on-semantics means the base17 ecosystem immediately becomes broadly compatible with so many other themeing systems - many(/most?) of which use independent semantics. Once base17 templates were in place it'd be easy to source themes from almost any ecosystem - and make those available - optionally providing a more "curated" list of themes that most users found the "best"...

And if someone wants just wants 16 colors and fixed semantics, they should simply continue to author using Base16 - the format has proven great for exactly that use case - and there are tons of templates... if they want more freedom of expression than that allows them they need to switch to semantics.

To be clear my proposal here:

• Base17 becomes even less "backwards" compatible to encourage a hard-break with base16.
  • Base16 themes can be upgraded to base17, but base17 cannot be downgraded (into base16 templates).
  • A tool can be provided to do this automatically (base16 -> base17).
• Base17 fully embraces variables/semantics and drops baseXX slots entirely.
• A scheme designer who prefers a fixed palette with tightly bound semantics can continue to use base16, and there is nothing wrong with doing so.
• Someone who wants full on semantics would use base17 (for all the flexibility it offers).
• The color limit of 16 should be reconsidered (or made optional) - personally I think it should be a constraint the scheme designers chooses rather than it being forced on them. (we could always have a "Category" for 16 color schemes if we thought that was "cool/retro")
• The ecosystem would need to provide new templates with full support for semantics.
• Base17 may no longer be the best name.

I once showed a few base16 text editor colourschemes to someone and they said that they would not use it because they all use the colour “red” a lot and “red” indicates an error to them (which is a reasonable).

Since then I haven’t really been able to get that out my head. BASE_08 is often used as the standard text colour but it’s also used for errors and is often red. Errors don’t stand out because it’s the colour of text and you need to understand the context in which errors are shows to understand it’s an error. Syntax highlighting is meant to convey meaning (it’s nice if it looks good too) and meaning is lost when it comes to errors compared almost any other editor theme I've used before. The base16 styling page mentions:

base08 - Variables, XML Tags, Markup Link Text, Markup Lists, Diff Deleted

I'm guessing it's used for errors due to the Diff Deleted colouring? Here is a side by side example of a sample piece of code from base16-builder-go with vscode using the top theme vscode extension for that specific theme:

Theme	Base16 version (vim)	VSCode extension version
Ayu dark
Gruvbox dark medium
Monokai
Nord
Solarized light

Below is an example of side by side typescript with errors in VSCode. I've included Gruvbox which is quite "red" heavy and nord which has basically no "red".

Theme	VSCode Base16-Theme-Generator	VSCode Nord extension
Gruvbox dark medium
Nord

I picked these themes because they're all very popular themes.

Conservatively, Base16 has at least double the amount of "red" in it's themes than the "official" or most popular VSCode equivalents when not displaying errors. I suspect this is a systemic problem, otherwise it wouldn't be so prevalent in basically ever theme (but I could be wrong).

@base16-project/base16-project-team what your thoughts are on this? Is there something we can do about it?

Reference: #11 #24

Rough plan:

• update builder specifications (if needed) - #47
• PR for node builder
• PR for Go builder
• when ready, ratify Base17 as v1.0
• work with a few editor template authors to see if we're missing any obvious slots
• finalize the list of built-in slots
• merge builder PRs
• Publish new specification and new editor templates
• Inform other template authors of new features

Identify and fix broken schemes:

• Nord
• look for other schemes mentioned in #10

https://github.com/base16-project/base16/blob/main/file.md

Should this not be versioned along with the rest of the spec?

I'd also be happy to work towards a potential merge and am happy to collaborate as I do not see the need to duplicate efforts. The reason I created base24 was to solve the following issues

• baseXX did not have an organisation with multiple contributors (now it does, and base24 wasn't exactly successful in attracting contribution)
• base16 does not deal with bright ansi colours

For me, once the following issue is resolved then there is no need for base24

Originally posted by @FredHappyface in #7 (comment)

Any graphics people on the team? I think it'd be much nicer if we could replace this white bg with transparent and remove the "base16" from the graphic... that way the colors/logo/whatever still looks good in light or dark mode in the browser.

TLDR: Many themes are impossible to represent in Base16 because we insist on binding multiple semantic meanings into singular colors: IE, "variables AND diff deleted MUST always be the same color". It's baked right into the spec. 🙁 You'll never find a Base16 theme where that's not true, but you'll find many themes in the larger world where that's not true.

This results in many themes ported to Base16 being broken or becoming "hollow shells" of what they intended to be. I think this is a bad outcome and we should be more flexible. Look at the Nord example at the top of #10... the Base16 Nord on the left honestly doesn't even look like Nord at all.

I think this deserves it's own topic though it's an offshoot of #10... I've quickly come to believe than many themes coming into Base16 from the "outside" can't possibly be properly represented in Base16 because of Base16's insistence on "semantic binding"... ie binding multiple semantic meanings into a single base16 color:

• "a variable MUST be the same color as Diff Deleted"
• "and also the same color as an XML tag"
• "and also the same color as..."

It's a bit larger problem than "too much red"... We don't have to look any further than the Nord examples given to see how fast this falls completely apart:

• https://github.com/chriskempson/base16/issues/162
• #10

Nord is very clear about the intention of it's palette (emphasis mine):

Nord4: (a very light grey) For dark ambiance designs, it is used for UI elements like the text editor caret.
In the context of syntax highlighting it is used as text color for variables, constants, attributes and fields.

Nord11: (a slightly subdued red) Used for UI elements that are rendering error states like linter markers and the highlighting of Git diff deletions. In the context of syntax highlighting it is used to override the highlighting of syntax elements that are detected as errors

So immediately Nord is impossible to properly represent in Base 16 because it's a violation of the "semantic binding" of base08.

base08 - Variables, XML Tags, Markup Link Text, Markup Lists, Diff Deleted

Proposal

I propose we entirely unbind the semantics with aliasing... and that all the current semantic labels become aliases. We many also need aliases for mapping colors into terminal color space... (if the desire is to TRY and match default terminal colors at all).

scheme: "Nord"
# our own user defined aliases for convenience
nord0: "#2E3440"
nord1: "#3B4252"
nord2: "#434C5E"
nord3: "#4C566A"
# now the "official" semantic alias
diff_added: nord14
diff_deleted: nord11
variable: nord4
error: nord11
# ... and finally, required for compability...
base00: nord0
base01: nord2
base02: nord4
base03: nord3
# terminal colors often have fixed meanings
term09: nord11  # terminal color 9 is bright red, etc...

For backwards compatibility all the "official" alaises could map to their "semanticly bound" colors, as they do now... so if you didn't specify error or diff_deleted or variable they would all point to base08 (redish in many themes).

This would certainly require the aid/assistance/buy in of the template maintainers (to benefit from this improvement), but I think they'd welcome it... I'll speak for myself as the maintainer of Highlight.js template that I'd love to see this - and Nord is just one example of why.

Originally posted by @joshgoebel in #10 (comment)

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.

Previous discussion was happening in https://github.com/chriskempson/base16/issues/74, but it would be best to continue discussion here if possible.

There are a number of things (at least in my mind) which still need to be figured out:

My TODO list (will be converted to issues or finished):

• Contact Github support to make the base16-project/* repos are the "primary" repos and the chriskempson ones show up as forks.
  • Decide on resolution - we may have to break into a separate "network" of forks.
• Add (more) new collaborators
• Improve the base16-builder-go to make the build process easier
• Look at adding CI for updating the schemes repo and maybe auto-updating template repos
• Clear a bit of the PR backlog
• Look at migrating existing issues and PRs (either automatically or by hand)
• Update the README of the original repos to point to the new location and mention the "archived"-ish status.

We need to figure out a number of things:

• Decide on acceptance criteria for PRs
• Decide on acceptance criteria for repos
• Figure out what to do about PRs on the original forks
• Maybe decide on a code of conduct
• How we want to update the readme to clean stuff up
• Decide how we want to reach out to "unofficial" base16 templates and other projects

I want to be clear I'm not speaking for the whole organization, these are definitely my thoughts, and feedback is welcome. - hence my tagging this discussion and help wanted. Though at the end I suggest that it could be beneficial if the entire organization decided on clear messaging around this topic. It's possible the choice of Base17 as a name was poor. To me it only implies "the next version", not "base16 original flavor is dead"...

So I've seen concern around the various direction/directions we're talking about regarding Base17/BaseNext DRAFT. It's for sure a more featureful vision that allows for a lot of additional flexibility, better application support, higher fidelity porting of existing themes, better interop with other theming formats, etc... and with that yes, it adds a bit of complexity - though I don't think too much. (given all the benefits) But I wanted to address concerns...

Some portion of these concerns boil down to:

Base16 is simple, it works great, I like it as-is. Don't change it or take it away from me!

Chris still owns base16, so we actually can't change it - only Chris can. I'm also not sure anyone is trying to take Base16 away from anyone.

I've personally never wanted to replace base16 - and I personally don't think that should be a goal for the organization either. Base16 is great for many use cases, it has evidently existed since 2012 largely unchanged (esp the style spec, the schema spec)... In places where it's already shines it's possible it will still be shining 10 years from now.

Anyone who wishes to continue to author base16 schemas and templates - or use the resulting themes: If you like exactly what base16 has to offer, great. I have no plans to drop support from the Node builder - and there are plenty of other base16 builders besides. Ever since Chris chose to keep Base16 separate the vision I (personally) have is of lots of theming systems that can interact and co-exist together... base9, base16, base24, ansi16, baseNext, [pick almost any outside theming system with semantic meanings tied to colors, insert here]...

I don't think it's a zero sum game. Vim and VS Code both exist, both with vibrant communities. I'd like to hope our first "next thing" is compelling and gets many people truly excited and chomping at the bit to upgrade - but if you aren't one of those people, that's ok. I'd encourage us as an organization to consider making a clear statement to the effect of:

• We aren't trying to kill base16 0.2 or take it away from anyone.
• We aren't trying to co-opt or replace base16 0.2.
• We'll continue to support base16 0.2 (as it's part of the broader theming community)
• Instead, we're trying to build next generation systems for those who desire more than what base16 offers.

Yes, fixing our naming issues will help with some of this, but I think it's one piece of the puzzle, not the entire puzzle.

Thoughts?

Edit: Replaced many places of base16 with base16 0.2 to clarify I'm talking about the style/schema/templating spec largely - though I'm not sure it helps. 😕 Another reason that the current way the spec is split out is confusing for referring to "point in time" versions of a style system. It really feels like base16 v0.2 should be sufficient but really I need to instead say : base16 0.2 style guide plus base16-builder 0.9 (schema/template details but not builder detail) Ugh.

Maybe be slightly more careful with anything that auto-publishes (Go, NPM, etc) but I'm not sure we have things that auto-publish yet?

Originally posted by @joshgoebel in #12 (comment)

Vim is actually an example of the auto-publishing I was getting at here... we should be careful because a single bad actor in the organization (or a compromise of their account) could perhaps insert executable code on a person's computer merely by hacking a color scheme (assuming some yet unknown builder vulnerability).

And if that seems unlikely (lets say we trust our builders implicitly) one could definitely cause issues if they had commit bits to both the builder and the color schemes...

• commit bad code to base16-builder-go
• commit a scheme to trigger rebuilding of base16-vim/colors
• Vim users install malicious code from our repos 🔥

Things worth considering... some of this is partly mitigated just by protecting the main branch and requiring PR review for builders.

Tangentially related to #13.

Idea, add a 3rd party builder section similar to the "other" section used for themes.

Include:

• https://github.com/InspectorMustache/base16-builder-python

With regard to the idea of using TM copes it'd been mentioned we may need extra UI scopes since TM is mostly covering code highlighting. Things like:

• UI (status bars, etc)
• Terminal stuff (cursor, selection, default text)
• ANSI (allow a theme author to map their colors into ANSI space)

Examples:

term.ansi.0
term.ansi.red
term.ansi.bright-red
ui.cursor.fg
ui.cursor.bg
ui.divider
ui.selection.fg
ui.selection.bg

Related: #11

I think the discussion of which semantic scopes to support (and how to name them) is separate from the technical discussion of how to add them to builders so I've created this thread... I suggested our initial pass might just start with the original semantic scopes from the spec.. I'll go ahead and write them out. I already see some gaps though.

This is me just trying to take the official list, copy the names, surmise a little bit of their intent (that class really means "class name"), and then group them better.

Terminals (written in scope form, but this could change)

(gathered from reviwing all terminal templates)

• Alacritty
• Blink
• ConCfg
• Console2
• ConsoleZ
• Crosh
• fish
• fish-shell
• Gnome Terminal
• kermit
• kitty
• Konsole
• MinTTY
• PuTTY
• st
• Termite
• Termux
• Tilix
• Windows Terminal
• XFCE4 Terminal
• Xshell
• Xresources

ui/term.cursor (bg/fg?)
term.dim_color (tilix)
ui/term.highlight (bg/fg?) (tilix)
ui/term.text
ui.selection.background (bg/fg?)
term.url_color (should this be diff from syntax highlight?)
# on many terminals fg/bg can be different from the ANSI palette
ui.foreground
ui.background
foreground/background intense (konsole) ???? (bold???)
reverse cursor (st) - is this just a way of saying bg color?

Questions

• Are text and foreground the same?

Background / Foreground / special

BG_default
FG_default
BG_lighter
BG_selection
invisible
line_highlight
FG_dark / BG_status_bar
FG_light
BG_light
BG_search_text

Markup

markup_link_text
markup_link_url
markup_list
markup_code
markup_italic
markup_bold
markup_quoted

Diffs

diff_inserted
diff_changed
diff_deleted

Source

name_class
name_class_inherited
name_function
name_method
name_support
name_variable
xml_tag
xml_attribute
integer
boolean
constant
string
regex (regular_expression)
escape_chars
attribute_id
heading
keyword
storage
selector
deprecated
embed_tag
caret
delimiters 
operator
comments

From the official list

Originally posted by @joshgoebel in #11 (comment)

Old URL: http://chriskempson.com/projects/base16

See right side: https://github.com/base16-project/base16

I've been using @Misterio77's version of the flatcolor GTK theme, and did a bit of work on extending it to use the full range of base16 colours.

As I understand, GNOME is now moving towards GTK4/Libadwaita, which has a nice small template for colour definitions that matches up fairly nicely with base16's definitions.

I haven't found any colour template for QT themes though. I did just find Oomox, and it seems to be able to manage something similar, although I haven't tried it out yet.

I'd like to consolidate methods of defining colours for these toolkits/frameworks, and then match them up to base16's definitions. Hopefully this would let the major DEs use base16 without much effort. Does anyone have any information/thoughts on this?

Lets take a look

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)

And 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

But this directly contradicts the list where base07 is listed as "Light Background"... should it not be "Brightest/very light Foreground"? Most of the published schemes (not all) seem to run with this lighest to darkest idea, paying attention to the instructions rather than the exactly base07 and base06 labels.

Proposal

base06 - Light Foreground (Not often used)
base07 - Brightest Foreground (Not often used)

Because we're a new org starting up, we're looking for more people who are willing to help maintain some of these projects, whether that's templates, the spec, or something else.

Please feel free to talk about what you're willing to help with here so we can get some more people added.

Ref #45.

• Node builder supports Base24
• Go builder supports Base24
• PR updating Base16 spec/README to go "multi-target": Base16/Base24/etc (shared build tools / multiple "platforms")
• Transfer Base24 repo
• Update Base24 README
• Redirect original Base24 url -> Base16
• Add issues config and redirect general Base24 issues => Base16 project issues
• Separate or joint repo for Base24 specific schemes?

I wanted to write-up my idea of how to support 16-color "classic" ANSI themes inside the Base16 banner... this involves semantic colors so that we can have all 16 of our named ANSI colors and then map them (as makes the most sense) back into the non-ANSI baseXX mappings - such that ANSI schemes could continue to be used anywhere that base16 is supported.

The mapping isn't perfect... it's not 100% clear which ANSI colors should by default map to the old "orange hue" (base09) or the old brown hue (base0F)... and the larger loss, the 8 shade BG/FG gradient now would now have to shift to only a 4 color ANSI gradient:

• ANSI 0, ANSI 7, ANSI 8, ANSI 15 - black, dark grey, grey, and white

Here is what a scheme might look like. Please ignore the rgb syntax. I'm not suggested it, it was just easiest to write up this sample without having to lookup a bunch of hexcodes.

scheme: "Default-ish Terminal"

ansi00: rgb(0,0,0) # black
ansi01: rgb(128,0,0) # red
ansi02: rgb(0,128,0) # green
ansi03: rgb(128,128,0) # brown / yellow
ansi04: rgb(0,0,128) # blue
ansi05: rgb(128,0,128) # purple
ansi06: rgb(0,128,128) # cyan
ansi07: rgb(128,128,128) # dark grey
ansi08: rgb(192,192,192) # grey
ansi09: rgb(255,0,0) # bright red
ansi0A: rgb(0,255,0) # bright green
ansi0B: rgb(255,255,0) # bright yellow
ansi0C: rgb(0,0,255) # bright blue
ansi0D: rgb(255,0,255) # bright purple
ansi0E: rgb(0,255,255) # bright cyan
ansi0F: rgb(255,255,255) # white

# here we map the black-white ANSI gradient into base00 - base 07
# note these defaults could be handled inside builder such that ANSI
# schemes only had to define the 16 ansi colors, not worry about the
# baseXX colors 
base00: ansi00 # black
base01: ansi00 # black
base02: ansi07 # dark grey
base03: ansi07 # dark grey
base04: ansi08 # grey
base05: ansi08 # grey
base06: ansi0F # white
base07: ansi0F # white
base08: ansi09 # bright red
base09: # whatever closest to orange???
base0A: ansi0B # bright yellow
base0B: ansi0A # bright green
base0C: ansi0E # bright cyan
base0D: ansi0C # bright blue
base0E: ansi0F # bright purple
base0F: ansi03 # brown / dark yellow???

Please note there are still only 16 colors here.

@belak and I spoke about this at length. It would require effort from template maintainers to support... mostly dealing with the 8 => 4 shade gradient reduction... but at the template level this could be supported via boolean flags:

{{#gradient4}}
# config for a 4 shade gradient
{{/gradient4}}

{{#gradient8}}
# config for a more traditional 8 shade gradient
{{/gradient8}}

For some app UI templates (usually app+terminal, such as Vim, Emacs, etc) this would require an investment to support both 4 and 8 color ramps... For a lot of templates (Terminal templates esp) supporting this new scheme format is even easier than what they were doing previously... since the new templates would just be mapping ansi0 - ansi15 directly to ANSI 0 to ANSI 15, no complex mappings at all.

I think an approach like this might be better than just a hard fork where we send the people who want 16 ANSI colors off to their own island to build all their own stuff... that assumes of course there are people here who are interested in actual 16 color ANSI support. For a time you might have some older templates that "don't support ANSI schemes"... it would be up to the community to fill those gaps - if they wanted ANSI everywhere".

I think going the other direction (older schemes into new templates) the ANSI palette could largely be auto-generated on the fly... so the 8 color ramp would be reduced to 4 colors (via blending) and the "hues everyone seems to use" would be mapped into the most appropriate ANSI slots and dark and light versions would be created. New templates should therefore support either BOTH (Base16ANSI and Base16) or just support ANSI and trust the auto-conversion.

So first, does anyone care about Base16 supporting 16 color ANSI light/dark/etc - just as the terminal gods originally decreed it to be? ;-)

Since we're merging File Details into the spec... should Styling go in as well so that there is a single spec instead of two separate specs?

Not sure, just asking.

It seems to me the organization is currently private and I can't figure out how to submit my repositories there:

https://github.com/DanManN/base16-xresources
https://github.com/DanManN/base16-rofi

Given the stranded history of base16, I wrote my own version of base16: base9...
Some of the differences, I think, are fundamentally incompatible with base16.
Here is the about page:

https://base9-theme.github.io/about#how-its-different-from-base16

As proof of concept, I made a vscode extension

The main incompatible difference is that base9 mixes user specified colors to produce more colors for templates to use. This way, users need to specify less colors (16 to 9, or potentially even less in future versions), but templates can be more flexible and modern.

On one hand, I like the improvement I made, and some of the incompatible changes are probably never going to be a part of base16.
On the other hand, now that we have base16 rebooted and base9, splitting the effort would be wasteful.

I basically want to know what are your thoughts?

Do you come to base9?

Do I come to base16?

Do we happily coexist, and have a healthy competition?

If base16 continues to move forward, do you think the improvement I made is good to be ported back to base9?

I just realized (in talking about security in the other thread) that our metadata fields are likely currently subject to code injection attacks via a malicious theme.

From vim template:

" base16-vim (https://github.com/chriskempson/base16-vim)
" by Chris Kempson (http://chriskempson.com)
" {{scheme-name}} scheme by {{scheme-author}}

Example of the attack vector:

(this is using a YAML multi-line string)

scheme: |
  trojan-horsey-unicorn

  [here is a huge
  glob of evil and
  malicious vimscript]
base00: "090300" #  ----

I'd guess this is exploitable for any templates where the output is an executable file... we could start by not allowing multiple lines (perhaps make it an error case) but how would you handle protecting all the possible templates since we don't know which characters might be used to escape commenting?

The assumption of course being that these metadata fields are only for use in comments... and should NOT be allowed to escape those comments.

Perhaps the ship has sailed, but do we need BOTH of these terms? It seems the distinction only exists so we can speak about the "scheme" (in the abstract) vs the app specific generated "theme"s... but not all applications call their themes "themes", so this is already a bit broken when it comes to clarity/correctness.

And if you say "that's just OUR name for it" I think that makes it even worse... so now we have:

• schemes generate...
  • themes which...
    • are really just themes/schemes/styles/colorsets

I don't see the value we're providing inserting that middle term "theme".

Could we simplify:

A Base16 theme is a set of 16 colors used as a base to build per application themes/schemes/styles.
A Base16 scheme is a set of 16 colors used as a base to build per application themes/schemes/styles.

I'm not even really suggesting which should win (I like theme a little better) just that I have ONE word to wrap my head around vs two (in the base16 context).

Having a clear governance model will ensure a clear vision for the project. Here is what I'm thinking:

Who has the final say about the project?

I think it's probably one or a group of people (Let's call it owners). If a group of people has disagreement, it's decided through a simple majority vote. Owners can always delegate decisions on certain areas to certain people, but owners can always take that back.

Do you guys agree?
If so, who are the owners right now? And when you say you are looking for collaborators, are you open to adding more owners?
This is a potentially dangerous decision, since if you add more owners, they are able to override your decisions and potentially even throw you out.

Who has the final say about each template and each repo under the org?

I think it should still be the base16 owners. Since the whole point of having an org is to centralize things and have a coherent vision. If that's the case, we should really be clear about that when a template wants to be in the org. If the original owner does not want to give up the ownership, we should advise them to continue to be "unofficial" base16 templates, etc.
Do you guys agree?

https://github.com/chriskempson/base16-textmate at

https://github.com/base16-project/base16/blob/c13a31c6a99b6921f0dd120277c142e52fc2d7b2/README.md?plain=1#L136-L138

https://github.com/chriskempson/base16-html-preview at

https://github.com/base16-project/base16/blob/c13a31c6a99b6921f0dd120277c142e52fc2d7b2/README.md?plain=1#L179-L181

https://github.com/chriskempson/base16-code-examples at

https://github.com/base16-project/base16/blob/c13a31c6a99b6921f0dd120277c142e52fc2d7b2/README.md?plain=1#L226-L228

are all dead...

It seems like most terminal files end up being fairly similar - maybe it would make sense to have a base16-terminal-templates (or some other similar name) which has all the terminals which we support in different folders.

In order to simplify the average builder (and allow them to focus on the building portion rather than git operations), we replaced the base16-schemes-source repo and all the sub-repos with https://github.com/base16-project/base16-schemes.

We also dropped the base16-templates-source repo for the same reason - most builders are focused on building a single template at a time.

Unfortunately, when I wrote spec 0.10.0, I didn't consider theme managers like themix and it wasn't brought up.

I'm not sure what the best course of action is - I don't like the old setup where multiple repos have to be updated for a template to be submitted (the old setup also doesn't allow for a repo to be replaced if the maintainer becomes inactive). Eventually, I hope most of the repos are transferred to base16-project and base16-project-contrib, but until then we can figure something out.

Does anyone have any suggestions?

CC @actionless

Ref: https://github.com/chriskempson/base16-textmate/

We're still referencing it in our documentation...

Are there links we need to check anywhere other than base16_schemes repo?

• update github issues links in base16_schemes repo

Pulling this out from a separate thread because it's easily what I'm been talking about a few places:

I imaging the north star is that base9 use base16 as a library. base9 handles color mixing magic, deciding what color to use for different semantics, including different shades, such as diff_added, diff_added_background, current_line_highlight. base9 then passes this information to base16 and uses base16 to generate actual themes for apps.

Originally posted by @lijiaqigreat in #7 (comment)

This is a perfectly valid request and not even that difficult. I imagine a executable builder rather than a library, but the effect is the same in either case. The simplest form of interop (with very little effort needed to support) with out ecosystem would be "masquarading as another supported style system"... ie base9 might FIRST generate a Base24 yml file, and then run that through builder - and would immediately have access to our ENTIRE ecosystem of targeted applications.

Ultimately we'll need a "open" interop format such as BaseX or Base99 or something that doesn't put any caps on the colors - some theming systems don't have arbitrary caps. Thankfully, none of our output templates care about color caps (once they go semantic) - that's a system/input concern... so it'd be easy to just say "this is an interop scheme" and that would mean that the number of colors would be ignored, and otherwise it would be treated as a valid Base17 system. We might call this system interop.

Also: A special system isn't even necessarily if builders had a --relax mode to turn off a few sanity checks... so if you ran Base17 in --relax mode and there happened to be 54 colors, the builder would just keep on doing it's thing as if that was normal. I think this is the simplest way to get builder support quickly to try this out.

And I think the builder usage complexity is still pretty high (having to setup an entire folder structure before you begin)... this thread can talk about both of these concerns together and how to improve things. (I'm assuming the desire to quickly build one scheme against many templates, perhaps a scheme being auto-generated of the flu, etc - not necessarily coming from a static collection of schemes).

Please label this issue as fit. Intentionally avoided any terminology around base16, as I'm still very confused about it.

This is yet another idea brought from base9.

We should use nested variable names (i.e. part1.part2) instead of - separated.

This has two aspects to it. The second builds on top of the first one, but both can be considered independently.

formatting

Use base03.hex instead of base03-hex

Advantage:

Instead of

<string>{{base07-dec-r}} {{base07-dec-g}} {{base07-dec-b}} 1</string>

we can write

{{#base07}}<string>{{dec-r}} {{dec-g}} {{dec-b}} 1</string>{{/base07}}

Which is much easier for template maintainer.

For more complicated templates, we could potentially use mustache partials

{{#base07}}{{>partial}}{{/base07}}

semantic aliasing

when defining semantic aliasing
instead of

button.foreground: "#{{button_foreground.hex}}"
button.background: "#{{button_background.hex}}"
terminal.red: "#{{ansi_red.hex}}"
terminal.green: "#{{ansi_green.hex}}"

we can say

{{#button}}
button.foreground: "#{{foreground.hex}}"
button.background: "#{{background.hex}}"
{{/button}}
{{#ansi}}
terminal.red: "#{{red.hex}}"
terminal.green: "#{{green.hex}}"
{{/ansi}}

For semantic alias override:

instead of

button_background: base09
button_foreground: base00

we can say

primary_normal:
  bg: base00
  fg: base09
primary_inverted:
  bg: base09
  fg: base00
primary_button: primary_inverted

or

button:
  bg: base09
  fg: base00

You get the idea. Which style/syntax/alias we support in the spec can be debated more in detail in follow up discussion, but I just want to introduce this idea first discuss why nested scopes are good.

Advantage:

1. easier to read the spec/aliases
2. easier for scheme developer to override the default if we decide to support something like in the primary_inverted example.
3. we can group domain specific semantics together for easier template development. (i.e. ansi, markdown)

All these are already implemented in base9, and in my experience, it works pretty well.
base9 alias config: https://github.com/base9-theme/base9-builder/blob/main/src/default_config.yml#L19
base9 template that uses nested variables heavily: https://github.com/base9-theme/base9-builder/blob/main/templates/preview.mustache

Reference #11. Essentially the user should be able to pick their own user-defined semantic names - and those would be variables:

$nord0: #2E3440
$polar_night_dark: $nord0
$aurura_red: #BF616A

diff_added: $aurura_red
base09: $aurura_red

Here $aurura_red is a variable denoted by the $... in my Node codebase this is just a variation of semantic names, there isn't really anything special about $red... though I do think it makes sense to use $ for variables for visual clues and so you can tell them apart from semantic tag names. (And avoid name collisions)

The base17 schema spec explains the rational briefly: https://github.com/base16-project/base17/blob/main/schema_spec.md#variable-slots Like everywhere else you have named variables, they are user convenience that makes building more complex schemes easier.