JamyGolden
commented
2 years ago I'm going to tag @FredHappyface who created https://github.com/Base24/base24 since this topic quite related to them too.
Closed forrestli74 closed 2 years ago
JamyGolden
commented
2 years ago I'm going to tag @FredHappyface who created https://github.com/Base24/base24 since this topic quite related to them too.
actionless
commented
2 years ago i think it's also important to keep it backward compatible at the same time (so such changes wouldnt instantly make all existing but not actively updating themes or templates obsolete) as i understood from base24 page it's there:
actionless
commented
2 years ago as for base9 - i think instead of literally merging with them we could borrow the idea of having lightness/saturation/etc variations of colors, similar to existing: {{base01-rgb-b}} to add smth similar to scss filters
actionless
commented
2 years ago (both approaches would solve my personal concern of not able to generate full linux terminal palette from base16 color theme)
FredHappyface
commented
2 years ago 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
forrestli74
commented
2 years ago Just wrote vision for base9.
Based on the current discussion of base16, I think it's going towards a different direction. These are just based on my perceived vision of base16, let me know if I misunderstood.
Base16's primary audience is template writer and theme writer. It aims to provide a precise API for them to talk to each other.
While I want Base9 to really be for the end user and really enable the user to specify its own theme easily and apply them easily.
There is a conflicting need here:
The template developer need a lot more than 16 colors, and need a computer readable config file.
If an end user without background knowledge wants to design a new color theme, it certainly doesn't want to specify more than 16 colors. In my opinion, 16 is even too much, that's why I reduced it to 9, I'm also considering further reducing it to 4. You could also argue that writing a config file is too daunting for the end user.
Base16 tries to make sure all changes are non-breaking or have a smooth migration. Since it already has a large audience, we don't want things to stop working.
Base9 is a new project and tries to solve legacy problems that base16 by a new code base and standard.
In my opinion, most of base16 is very boilerplate and is far easier to rewrite than to migrate if there is a breaking change. So I'm not too worried about porting templates.
If this is accurate, I think both have reasons to exist. I'll keep my base9. And feel free to close the issue.
joshgoebel
commented
2 years ago I'm not sure Base9 (or something similar) couldn't be built on TOP of Base16... as a tooling/ease of use layer... Many base16 themes could likely easily be upgraded/downgraded to Base9 themes easily enough in an automated/computer color science way.
But I think we're also fine if the project has it's own goals/ideas and wants to be it's own thing. I don't think Base16 is trying to gobble up things just cause... only if we could perhaps solve the reason for the fork in the first place.
forrestli74
commented
2 years ago I'm assuming I understand the base16's vision correctly.
I'm not sure Base9 (or something similar) couldn't be built on TOP of Base16.
Makes sense, only if the second point is addressed. One of the hardest-to-address legacy problems is the name "base16". It has a few unused colors (BASE_0F for sure, arguably one of BASE06, BASE_07) And it implies that all you need is 16 colors, when a template clearly needs more than 16 unique colors.
For that reason, I'm considering changing the name from base9 to baseN or something completely different, like omnitheme.
I also think the legacy style guide is put in without enough thought. Probably because of the bad style guide, the list of base16 themes are almost a joke, they almost all have the same hue order. (See #10) It will be very painful to migrate once we have a better style guide.
Those legacies are more of a burden than an asset. I think the builder side of things are much better, but still has room to improve. But the "simple" builder is easy to rewrite. The only thing that's hard to port over is the universal builder.
By having base9, we can discard the legacy problems and only copy what's good. In my opinion, that's far easier than migrating base16 gracefully. (As I said, the only part of the effort that is wasteful is the universal builder)
P.S. I still have huge respect to @chriskempson since he is the one bootstrapped everything.
joshgoebel
commented
2 years ago when a template clearly needs more than 16 unique colors.
Wait, what? I thought you wanted 4 or 9? Or do you mean including computed variations? I'm personally ok with us having a few limited filters - esp like opacity... which could allow for easy "variants" of colors (light, dark), etc... though I'm not sure how anyone else feels about that. But I feel like we should stick to "max 8-16 hues" or else our names starts to mean nothing...
Yo I just installed this sick Base16 theme with 192 colors!
šµāš«
the list of base16 themes ... almost all have the same hue
This is indeed a serious legacy problem and I see no easy path here... other than to provide better style guide/better tools - and then let the theme maintainers come back and submit newer, better themes.
The only thing that's hard to port over is the universal builder.
Why? It could be like 20-30 line script/wrapper around simple builder...
By having base9, we can discard the legacy problems and only copy what's good. In my opinion, that's far easier than migrating base16 gracefully.
I'm really not expecting you to persuade us to close up the Base16 shop and come over to Base9... but no ill-will either. I think Base16 is the "established brand" so even if it's a slog we'll probably stick around and make an attempt to fix it proper... I think more than anything it just requires a good plan and some time... I totally agree with a lot of your critiques of Base16 and would like to think now that the project is active again we'll resolve many of them.
actionless
commented
2 years ago But I feel like we should stick to "max 8-16 hues" or else our names starts to mean nothing...
i think we should just allow any int in 255 range instead of having hardcoded hues
also would be nice to have some way to mix two colors together with a given ratio
joshgoebel
commented
2 years ago instead of having hardcoded hues
We don't have hardcoded hues... I was referring to that we only allow 16 colors/hues.
forrestli74
commented
2 years ago Wait, what? I thought you wanted 4 or 9? Or do you mean including computed variations?
Yes, including computed variations.
Why? It could be like 20-30 line script/wrapper around simple builder...
Ok. You just gave one more reason to go to base9.
I'm really not expecting you to persuade us to close up the Base16 shop and come over to Base9...
All it takes is to convince a few key members like you and the rest will follow š .
I agree that brand reputation is a huge issue. A lot of people already know base16 and it a huge asset for base16.
Another issue is ownership, I think a lot of people hate to say it (including myself), but we all like to have ownership over what we work on.
Assuming you agree that the legacy problems are technically easier to solve by having a completely new design than patching existing specs. Here is an idea:
actionless
commented
2 years ago We don't have hardcoded hues... I was referring to that we only allow 16 colors/hues.
base9 have hardcoded hues (or whatever are those modifiers, p125, p150, etc) - instead of being fixed they should just allow any integer value instead of 125 or 150
this will allow base16 to still have only 16 main colors, while will allow more color variations of them inside the templates
joshgoebel
commented
2 years ago All it takes is to convince a few key members like you and the rest will follow
Check back in a year... if Base16 is floundering around and hasn't really solved any of these problems or moved forward then we should talk... but that would certainly be a large disappointment to me. I have high hopes, and it seems we have a lot of interested/motivated people.
but we all like to have ownership over what we work on.
I don't think making a new project from scratch is the only way to get that... I feel like I have some degree of ownership here now (though the concept is always a bit nebulous)... but a year ago I didn't... first I decided to build Base16 themes into Highlight.js, then I built a template, then I hacked on a builder, then because it wasn't maintained I became maintainer, etc, etc, etc... and time goes by and now I'm involved in the reboot efforts.
without thinking about breaking changes
I don't think the things I've proposed require breaking changes... legacy debt of existing schemes isn't the same as breaking changes... and moving to a new BaseXYZ format doesn't solve that problem anyways. Unless you consider just throwing them away a solution - and we don't need a new format to adopt that "solution".
Assuming you agree that the legacy problems are technically easier to solve by having a completely new design than patching existing specs.
I guess I don't agree? Esp when we haven't even tried solving them yet... we just started the discussion days ago.
forrestli74
commented
2 years ago Fair, fair.
Assuming you agree that the legacy problems are technically easier to solve by having a completely new design than patching existing specs.
I guess I don't agree? Esp when we haven't even tried solving them yet... we just started the discussion days ago.
Fair, fair. My entire premiss depend on this. And the answer is not clear yet.
I think I've pitched for base9 enough and don't want to keep this issue open for too long. After weighing in everything mentioned here, I'm still leaning towards developing base9 for now. I'll still contribute to base16 here and there (sometimes by bringing my base9 ideas to base16)
I'll revisit this after a while and see where things are going.
Thank you for indulging me. Closing the issue in a few days unless there are other comments.
joshgoebel
commented
2 years ago I'm still leaning towards developing base9 for now.
Awesome. Having a project that's "all your own" is a fun thing for sure.
I'll still contribute to base16 here and there ... (sometimes by bringing my base9 ideas to base16)
Also awesome! I'd encourage you to perhaps pick your best idea (that we lack) and propose it as it's own discrete issue... or perhaps most compatible idea?... and see how that goes. :-)
belak
commented
2 years ago I would echo what @joshgoebel said - bringing up issues you see with base16 and proposing improvements would be a great place to start.
One other possibility would be sharing common tooling - we could start building out some common tooling which could be shared (rather than maintaining a separate fork of builders, CI setups, etc). I've already got a PR out adding support for base24 to base16-builder-go - is there anything like that we could do to help support base9?
forrestli74
commented
2 years ago Helps are great. One thing I really would like is to mention Base9 in base16 docs once Base9 reaches "1.0". The other thing is to make sure it's a MIT license, so I can copy code from base16 when I need to. I'm against supporting Base24 in base16 builder, unless we plan to officially support 24 colors as a part of base16. But that's a separate issue to discuss.
joshgoebel
commented
2 years ago @lijiaqigreat Since #51 we've pivoted a bit. It seems Base16 is Chris's baby and that he wants to keep it that way... so the organization is going broader/wider... we want to help develop alternative styles systems (so that the entire ecosystem can continue to grow) as well as more universal tooling. The end goal still being "all your favorite themes, in all your fav apps" or something like that.
I'd like someone to be able to use node-builder to build:
Base24 is planning to move into our org, but it will still be Base24. Obviously base16 is not interested in moving into the org, but our build tooling can still support it as a discrete format. Base9 could live here (we'd be happy to have it), or in your own repo, but I'm more interested than ever in "what is base9" and how might it fit into the larger ecosystem.
I'm against supporting Base24 in base16 builder,
First, there is no single "base16 builder" there are ~10 of them (including the two here)... and soon there will be no base16-builder-node... as it already supports both Base16, Base17 draft, and Base24 the base16 name is no longer appropriate and will be changed.
I also thing long-term this thinking is backwards (and a bit controlling)... I think in a perfect world style systems would support builders, not builders supporting style systems... it flips the power dynamic. If you want to invent Base9, you write a style guide, your write a builder module that understands how to build your system - then that plugs into the larger ecosystem.
IE, there would be no more "gatekeepers" of the builders. I don't know how to make that a reality yet, but that's the future I'd love to see.
So if you'd like to rejoin the discussion as part of the bigger picture, we'd love to have you!
forrestli74
commented
2 years ago I'm glad the vision is more clear now. Thank you for the invite. I'll probably move base9 once this universal tool reaches "1.0". But before that, I'll keep base9 independent. Here is what I'm thinking: It seems like this org is indeed aiming to be a tool for theme builders. base9 is targeting the average user who wants to set up a theme with minimum effort. In the long term, if both succeeded, Base9 should be built on top of this org (Assuming it won't be called base16 anymore). But before that happens, base9 should stay agile and not be tied to the tooling that has not been developed yet. It would also be good for this org, since I think the whole reason you guys are developing different sorts of themes (i.e. ansi16, base16, base24. I'm probably using the wrong term here) is that we want to explore different use cases for the users of this tool. By keeping base9 agile, it already has a working builder, website and a vscode plugin, and you guys can see how a theme can use a universal tool more easily.
Reopening. Will close once comments settle down, since I think this org already has too many open topics and should benefit from a more focused discussion.
joshgoebel
commented
2 years ago Well perhaps I've misunderstood what Base9 is (and I've read a lot of it too)... if it's just about "build one scheme you like" I'm not sure how it fits exactly - though that doesn't mean you're not welcome. Most people building theming systems are hoping people will show up - make themes for them - and then you have a theme database (all built around your theming system).
What I personally would like to see us do is help aggregate good style systems and good theme databases (when compatible)... so lets say you're looking for a terminal theme... you shouldn't be limited to just base16... you should be able to pick from a consolidated database of all the best: base16, base24, ansi16, iTerm2-Color-Schemes etc...
Yep I thru a source in there that has nothing to do with baseX at all... but if someone is looking for an ANSI terminal theme - why not draw from the best sources out there?
At the end of the day I think it's all about "all your favorite themes in all your favorite apps"... So if base9 has no theme database to share... I'm not 100% sure how it fits in that picture? Am I confused about base9?
I'm assuming that 98% of users are consuming the final themes, not authoring them.
forrestli74
commented
2 years ago I'm assuming that 98% of users are consuming the final themes, not authoring them.
That's because authoring theme is too hard, and base9 aims to make it so easy that average user can do it in a few minutes.
Most people building theming systems are hoping people will show up - make themes for them - and then you have a theme database (all built around your theming system).
It is anti-goal for base9. I want to make it as easy (if not easier) to design a new theme than to pick from a list of existing themes. Although I do plan to have some database, so that the user can pick a starting point.
but if someone is looking for an ANSI terminal theme - why not draw from the best sources out there?
Because color theme is a matter of personal taste and users could prefer to design its own theme than picking from existing ones.
I have finished implementing the user flow for vscode. I highly encourage you to try it and hopefully see what I mean:
base9.palette to the color code.Since base9 targets the end user rather than the theme developer, it prioritizes ease of use over the ability to customize. here is how it differs from base16: Here are some design choices I made that probably will differ from base16 and illustrates how base9 prioritizes ease of use. (Whether they are the right design choice is debatable and is a separate topic)
- separated color hex) instead of yamljoshgoebel
commented
2 years ago It is anti-goal for base9.
Ah, then yes I did understand properly - you're doing something very different (and quite ambitious) indeed. :-)
Another thing I'd like to work on long-term is interop (between style systems) but it also seems like currently that's probably a non-starter with base9 because there seems to be no easy way to map your 54 generated colors into 16, or 24... at least not unless we introduced a concept similar to your own p relative brightness system.
How does p work... I assume it works because you only have a single background color so it's merging with that? if you had 4 background colors it'd be a lot more complex, yes?
That said personally I'm still super interested to see where you take the project. If you think of a way we could help, let us know.
forrestli74
commented
2 years ago How does p work...
The p calculation is probably over-engineered. But I can happily explain:
Indeed, you mix the hue color with the background. (something like (1-p)*background + p * hue_color). But you do it in a different color space. If you are not familiar with lab color space, it's a different way of representing the colors. It still uses 3 numbers (L, A ,B), but they are scaled to match human perception. I more or less use the LAB color space to mix, but I rescale the L component again to tailor the wcag 2.0 standard. As a result, the mixed color matches the human perception of color mixing while equalizing the wcag 2.0 contrast. The contrast rescaling is hard to explain. A simpler implementation would just be mixing colors in lab color space. An even simpler implementation is mixing the rgb value.
Code link
if you had 4 background colors it'd be a lot more complex, yes?
Yes
If you think of a way we could help, let us know.
Yes. Here are a few things I can think of: (totally ok if the answer is no)
Sorry for keeping using base16, since we haven't decided on a new name yet.
forrestli74
commented
2 years ago One small correction, there are currently (9-1)*6+1=49 colors in base9, as background does not have p variants.
joshgoebel
commented
2 years ago Mention Base9 in base16 docs once Base9 reaches "1.0", as I want more users.
Well we aren't "base16" anymore.... and right now I'm not sure where we'd put you exactly, but I'm open to suggestions... right now we list all style systems we support as part of the larger ecosystem, but as already mentioned your kind of the odd duck in that regard as our tooling is kind of incompatible right now with what you're doing.
I'm not sure if there is some other list we could add you to in the README... perhaps. If you see a spot, point it out.
Chris's base16 is MIT (again) and all our key stuff is MIT AFAIK.
Contribute to base9. I'm planning to write a few open issues for contributers to pick up.
I have enough on my plate personally, but if you meant our community - sure... hopefully you'll find some other people who are interested to help out.
Steer base16 to a future where base9 can just switch the internal implementation to base16.
You'd have to elaborate... If you mean implement p style features in the spec/templates that's not currently a high priority... but I'm not opposed to the idea of such things theoretically. I'd like more modulal builders so you could just do this work yourself - teach our builders about how to build Base9 - but that's kind of a larger discussion right now between @belak and myself.
It's hard when we have multiple builders...
forrestli74
commented
2 years ago right now I'm not sure where we'd put you exactly, but I'm open to suggestions...
Based on current discussions, I think we have different goals and therefore should be two independent projects. (again assuming I correctly understood the goal of base16) As for how we fit together, I will explain in a few lines below.
I'm not sure if there is some other list we could add you to in the README... perhaps. If you see a spot, point it out.
I will send PR once base9 reaches "1.0".
Steer base16 to a future where base9 can just switch the internal implementation to base16.
You'd have to elaborate...
I have not been keeping up with base16's discussions. So I don't know how exactly base9 could fit in. Hopefully there will be a section in the readme to explain base16's goal better once things settle down.
Roughly, 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.
Again, intentionally incorrectly using the word base16 to mean whatever this org is building, since there is no new name for it yet. #38
joshgoebel
commented
2 years ago base9 then passes this information to base16 and uses base16 to generate actual themes for apps.
Of course! Thanks for sticking with me, now I can help. :-) I haven't given as much thought to interop as other things or I'd have realized this... we don't need to support you on the backend (templates) if you do the color mixing all yourself we could just support you on the front-end... you can "pretend" to be a regular old Base17 scheme (that's the only interop so far). And everything would "just work". Base17 is still draft but here's how you'd do it with node builder - just follow the instructions in the README, but first you need to generate a "cooked" base9 scheme...
When I say a "cooked" base 9 scheme I mean you take your base9 colors, do all your magic and you split out a valid base17 scheme... at that point we're just building a base17 scheme, same as we would any other. And any templates that support base17, now they support base9 as well...
joshgoebel
commented
2 years ago diff_added_background
I never even considered this, you should jump in on the semantic thread reading what we should support. #24
forrestli74
commented
2 years ago Closing. If/how to merge with base17 is not a concern in the short term.
joshgoebel
commented
2 years ago Merging was probably the wrong name all along, I've changed this to interop for future reference to reflect the later discussion points...
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?