tinted-theming / home Goto Github PK
View Code? Open in Web Editor NEWStyle systems and smart build tooling for crafting high fidelity color schemes and easily using them in all your favorite apps.
License: MIT License
Style systems and smart build tooling for crafting high fidelity color schemes and easily using them in all your favorite apps.
License: MIT License
Having a clear governance model will ensure a clear vision for the project. Here is what I'm thinking:
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.
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?
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.
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:
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).
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.
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).
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.
I think it's strange to attach this to the README so tightly.
Happy to make PR if this is approved.
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.
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:
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).
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.
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?
https://github.com/base16-project/base16/blob/main/file.md
Should this not be versioned along with the rest of the spec?
for example, how much approvals should be for merging
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":
base16
to home
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:
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:
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
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)
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
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.
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)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)
Feel free to take this issue and make it your own.
I've been quite involved in the sous-chefs org, so I know the benefit of community orgs. I'd like to move over
It would be useful to know:
Example: https://github.com/sous-chefs/meta/blob/main/docs/transfering-a-cookbook.md
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:
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? ;-)
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.
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.
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}}
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:
primary_inverted
example.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
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:
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:
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.
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:
scheme
or is it the filename?scheme
why should the filename not reflect the canonical name?light
and dark
important parts of the name or not?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 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
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.
Tangentially related to #13.
Idea, add a 3rd party builder section similar to the "other" section used for themes.
Include:
Rough plan:
Identify and fix broken schemes:
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.
base06 - Light Foreground (Not often used)
base07 - Brightest Foreground (Not often used)
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?
Are there links we need to check anywhere other than base16_schemes repo?
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:
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)
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
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)
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?
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:
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:
(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:
Ref: https://github.com/chriskempson/base16-textmate/
We're still referencing it in our documentation...
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.
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.
Ref #45.
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'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
For me, once the following issue is resolved then there is no need for base24
Originally posted by @FredHappyface in #7 (comment)
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...
base16-vim/colors
Things worth considering... some of this is partly mitigated just by protecting the main
branch and requiring PR review for builders.
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:
blueforest
, brogrammer
, cupertino
, edge
, nova
, etc.brogrammer
, gruvbox-material-light-hard
, papercolor-light
, ia-light
, material-palenight
blueforest
, codeschool
, darkviolet
, pico
heetch-light
, ...tokyodark
, ...onedark
, google-dark
, one-light
, ...pinky
are swappedideas:
Old URL: http://chriskempson.com/projects/base16
See right side: https://github.com/base16-project/base16
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.
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?
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):
We need to figure out a number of things:
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.
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:
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?
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:
baseXX
slots entirely.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).
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.