Inconsistent shade spanning for some schemes

[musjj]

In order to create a dark scheme, colors base00 to base07 should span from dark to light.

It looks like that most of the tokyonight-* schemes breaks this rule, creating inconsistent coloring.

tokyodark.yaml is a particularly egregious example:

The colors base08 - base0F is also kind of random. There are probably other non-compliant themes, but these are the ones I found.

Tbh, I wish that the spec makes it so that the color values are prefixed with a #, to make it easier to inspect and edit in editors that supports color highlighting/manipulation.

[TheNeverMan]

It seems that this rule is only an advice. There are multiple themes that don't follow it and use colors in unorthodox ways.

[MOIS3Y]

I thought about asking this question in a separate thread or asking with a commit of a new topic, but I'll ask here anyway.

Base16 is about the specification (unification)? I think so.
And in fact, this is an ideal standardization option for fans of distributing a single color scheme throughout their entire system.

I also noticed that some color schemes do not maintain a consistent style when composing fields:
synth-midnight-light has slug, tokyodark hasn't etc...

The same is true for the author field (there is a name somewhere and a link somewhere, an email)

Maybe it’s worth considering a unified design style when all attributes must be present in the .yaml description:

field	value	description	unique
system	"base16"	base16/24	false
name	"tokyodark"	lower case	true
variant	"dark"	dark/light	false
meta	include fields	see below	false
palette	base00 - 0F	hex colors list	false

meta:

field	value	description
author	"name"	creator name
maintainer	"name"	PR name
url	"https://url"	orign url
slug	"tokyodark"	slugify field
consistent	true	true/false
description	description	useful info

What can this actually do?

Well, if you use any builders, you can be sure that when iterating through the fields you will not get an exception that a key is missing.
Or, for example, you set a color to a button and it is important for you that the close button has a red shade.
If the theme doesn't follow the rainbow style you may end up with an unexpected color.
Before use, you can check whether the theme style is adhered to or not.
If not, use a backup color.

If it's really useful, I can take the time to rework the schemes.
I just need to know if it's really useful, if it won't break anything, and what fields approve.

[belak]

@musjj

Tbh, I wish that the spec makes it so that the color values are prefixed with a #, to make it easier to inspect and edit in editors that supports color highlighting/manipulation.

I meant to do this when we switched to a separate schemes repo and updated the spec. I'll look at doing this soon.

For what it's worth, the original reason for not requiring the # is because many PRs were getting submitted with stuff like base00: #000000 which won't work because the # starts a comment. You have to use the quotes. That being said I think the trade-off is worth it.

[belak]

@MOIS3Y

I thought about asking this question in a separate thread or asking with a commit of a new topic, but I'll ask here anyway.

In my mind, there are a few parts of this - consistent metadata and consistent colors.

Consistent Metadata

I also noticed that some color schemes do not maintain a consistent style when composing fields: synth-midnight-light has slug, tokyodark hasn't etc...

For missing fields, we've done it this way to stay as backwards compatible as possible and allow older builders to build newer schemes. However, with the direction we're going in, making more fields required might be an option. The current spec is defined in the home repo.

Slug in particular is essentially a workaround for a workaround. Pre-fork the filename was used as the scheme's name, however we wanted to make each scheme file self-contained, so we defined a way to "slugify" the name. Unfortunately, that resulted in a few output files being renamed, so we added the "slug" field as a way to override the "slugify" method of determining the scheme name. I'd love to deprecate this and move to requiring the slug. I've filed an issue to this effect.

Consistent Colors

For consistent colors (which I think is what you called meta.consistent), I'd like to see that more clearly defined before it's added to the spec.

If you have specific schemes you like which you think you can fix (as mentioned in the original comment, tokyodark is particularly egregious), we're open to merging improvements to existing schemes.

[belak]

Also related to consistent colors: there have been a number of proposals around how to better handle styling in base16 theme templates.

• Style guide: lighter shade for comments and ANSI colour 8 home#93
• More explicit specification/guidelines for base08 - base0F home#89

[JamyGolden]

We've added clearer information to the styling spec, so while it still doesn't absolutely require the suggested colors, it's at least clearly suggested. As for situations like the color disparity in tokyonight, I think we can adjust these schemes to more closely match the styling spec. In the case of tokyonight, it's quite easy to go to non base16/24 themes and see that they contain red,yellow,green,cyan,etc and put them in the suggested places.

@MOIS3Y what ideas did you have for the meta property?

[clach04]

It seems that this rule is only an advice. There are multiple themes that don't follow it and use colors in unorthodox ways.

I'm a bit late to this conversation but this is 100% true :-) For both base00-base07 and base08-base0F. The base00-base07 suggestion seems reasonable for dark color schemes but not light ones.

A great example of this is the Tomorrow color scheme - specifically the light scheme (dark is consistent) - however locating original source base16 files for this is tricky. I ended up reverse engineering them. https://github.com/chriskempson/base16-default-schemes/tree/306f2df2f8a6177846830101bfb37d7945929ef7 has non linear gray - which is required if selection and current line are to be distinguished.

It took me a while to figure this out. My current experiments are in https://github.com/clach04/base16-tomorrow-schemes - I need to make time to open an issue here with PR(s).

[musjj]

@clach04

I think the discussion is becoming a bit muddied here. Non-linearity is perfectly fine (the original spec never disallowed it), but every successive step should be either lighter or darker than the previous one. For example, the Tomorrow Day theme you linked perfectly follows this principle:

As you can see, every consecutive base0{0..7} is darker than the previous one. The problem here is that there are some color schemes (like the one I posted above) that essentially treats every slot as free spot to place any random color they like:

My concern wasn't stemmed from a theoretical fear of diverging from the holy spec, but from the fact that these color schemes genuinely looks bad and unreadable when applied to all the popular base16 themes out there. Which makes sense, since they essentially breaks all expectations you could have for a base16 color scheme.

My theory is that the original authors made these color schemes for their own set of free-styled themes (without following any of the principles defined by the base16 spec), so they weren't concerned about it being suitable for other people.

That is perfectly fine for personal usage. But if you want to design a theming framework that can potentially support thousands of different color schemes and have them all look decent, you need to have a rock-solid spec and the discipline to consistently follow it all the way to the end, even if you end up stifling a bit of creative freedom. Or else you'd just get an inconsistent mess.