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.

• https://github.com/tinted-theming/home/issues/93
• https://github.com/tinted-theming/home/issues/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?