search

tinted-theming / home

Style systems and smart build tooling for crafting high fidelity color schemes and easily using them in all your favorite apps.
MIT License
252 stars 12 forks source link

Base16 / Base17 compatibility with regard to templates #63

Closed joshgoebel closed 8 months ago

joshgoebel commented 2 years ago

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:

belak commented 2 years ago

To be clear my proposal here:

  • Base17 becomes even less "backwards" compatible to encourage a hard-break with base16.

  • Base17 fully embraces variables/semantics and drops baseXX slots entirely.

This would definitely be a hard break. It's also a pretty big departure from the base17 spec as it exists today. On a related note, I'd strongly encourage requiring the 16 ansi slots to make terminal schemes possible. That also means people might want to use terminal-only color themes for applications like vim, especially since we're looking at dropping the 16 color limit.

  • The color limit of 16 should be reconsidered (or made optional).

I think if you're dropping support for a fixed palette, there's no reason to limit how many colors you're using.

  • The ecosystem would need to provide new templates with full support for semantics.

Yes - this may take quite a long time. We'd need to provide some high-quality samples to make sure other people have a good example. I'm already working on extracting some of the common components of my emacs scheme so I can use them in ansi16 - they'd be useful here as well.

  • Base17 may no longer be the best name.

This would also free up the base17 name for the base16 improvements I've been doing. Maybe. It might also add to the confusion.

Other notes:

joshgoebel commented 2 years ago

On a related note, I'd strongly encourage requiring the 16 ansi slots to make terminal schemes possible

Absolutely, but whether they are "required" (must be specified) or merely "have defaults" is a worthwhile question... I'm also open to things like ansi: default or ansi: dos, etc... to be explicit about the desired defaults behavior... though it seems possible that users might want to divorce their ANSI terminal theme from their editor theme, but I guess they could do that by using two different themes?

Yes - this may take quite a long time. [ecosystem ... provides new templates]

That's the hard part, for sure. Though some template genres are much easier than others I think. For example done properly we could get terminals "for free"... it'd take me only an hour or so to PR all the terminals to add support for semantics ANSI/UI... do you not think the interop stuff that becomes possible will motivate some people a bit?

Does this mean that base17 would need an entirely new set of schemes?

Yes... (and there are potentially tons of places to source them). But if one merely wants to use their favorite base16 theme - they should use it... that has nothing to do with base17 - it'll work just fine as base16 forever... Many of the base16 themes (that aren't broken) don't NEED to be upgraded if people are happy with them. If someone wants to "port"/upgrade/fix a base16 theme then they could use the automated tool and tweak the result afterwards... and now we have a Base17 version of a Base16 theme - with all the associated benefits.

I presume eventually we will have base17 templates where there are no base16 templates, though that's a problem for another day. Then if someone REALLY wants to use Base16 with newer Base17 templates they could do so via interop (the upgrade tool we provide could be the interop component in that case)...

forrestli74 commented 2 years ago

If someone wants to "port"/upgrade/fix a base16 theme then they could use the automated tool and tweak the result afterwards...

One minor point: porting base16 to base17 is not automatable. Since when the base16 template uses one color in one place, we don't know its semantic.

forrestli74 commented 2 years ago

Sorry misclick.

joshgoebel commented 2 years ago

minor point: porting base16 to base17 is not automatable.

I was referring to schemes - not templates. Porting schemes is trivial (the basexx just expand to ALL their possible semantic meanings), porting (most) templates is impossible - since you have no idea which specific semantic meaning is desired.

Though again, there is no reason to do this unless one intends to go further and fully upgrade the scheme by changing some of those defaults to other values.

belak commented 8 months ago

At the moment, we've taken this approach:

What's next?

Because we're going to be moving towards a base17-style approach incrementally, I'm going to close this because it's more of a discussion than anything actionable.