Closed JamyGolden closed 1 year ago
I think variant
seems good!
Yeah I also prefer variant
.
If you want to automate adding variants to existing themes here's the code I use to automatically determine if the theme is light or dark
return (5 * c.green() + 2 * c.red() + c.blue()) <= 8 * 128;
And the original source is from here
However this doesn't work in all cases I think, as evidenced by this issue so manual review might be needed.
I like the idea of it being variant in the scheme files as well.
One other thing worth noting - there's no way to check if scheme-variant == dark
in the mustache files. Would exporting is_{{ scheme-variant }}_variant
in the builder be worthwhile to fix that? Values should default to falsey, so that should allow checking against specific variants if necessary.
Also, could you bump the version to 0.11.0-dev rather than 0.11.0? I'd like to bundle changes together if possible, especially because the scheme system changes should be close.
Yeah I think exporting is_{{scheme-variant}}_variant
is a good idea. I've updated the template variable information. We don't have a dynamic property-name in there yet so I wasn't able to follow any example information for it. If something is unclear or should be changed just leave a change request.
There are times when the generated colorschemes requires a dark/light variant, such as for VSCode: https://github.com/golf1052/base16-generator/blob/master/themes/base16-apathy-dark.json#L4. Until we add this support to the spec, vscode templates can't use any of our official builders.
type
isn't an amazing property name, maybevariant
would work better? My thought was to go for a string value instead of a boolean variant since one day we may have light, dark and medium for example :shrug:We'd have to add this field to each scheme, but I could do that after we merge this. There may be several things I'm missing here, but I just wanted to get a PR out so we could discuss.