DRAFT: Add Tinted8 specification #145
Conversation
ayu-dark.yamlStep 0: Displaying original ANSI8 YAML
system: "ansi8"
name: "Ayu Dark"
author: "Khue Nguyen <[email protected]>"
variant: "dark"
# bright_adj_hsl optional showing current defaults
bright_adj_hsl:
hue: 0
saturation: 0
lightness: 0.25
palette:
ansi0: "#0f1419"
ansi1: "#f07178"
ansi2: "#b8cc52"
ansi3: "#ffb454"
ansi4: "#59c2ff"
ansi5: "#d2a6ff"
ansi6: "#95e6cb"
ansi7: "#e6e1cf"at this point ANSI8 transforms into Base16 (+8Bright extension), so it would be 100% compatible with existing base16 templates. draft for the extension here: example demo: 
fully computed base16 (+bright extension) internal yaml file system: "base16"
name: "Ayu Dark"
author: "Khue Nguyen <[email protected]>"
variant: "dark"
bright_adj_hsl: # optional defaults dark (0,0,0.25) light (0,0.25,0.25)
hue: 0
saturation: 0
lightness: 0.25
palette:
base00: "#0f1419"
base01: "#3a3e3d"
base02: "#606763"
base03: "#888f87"
base04: "#b4b5b0"
base05: "#e6e1cf"
base06: "#e3e3e3"
base07: "#e6ebf0"
base08: "#f07178"
base09: "#f78863"
base0A: "#ffb454"
base0B: "#b8cc52"
base0C: "#95e6cb"
base0D: "#59c2ff"
base0E: "#d2a6ff"
base0F: "#df5836"
bright08: "#f4949a"
bright09: "#f9a68a"
bright0A: "#ffc77f"
bright0B: "#cad97d"
bright0C: "#afecd8"
bright0D: "#83d1ff"
bright0E: "#ddbcff"
bright0F: "#e78268" |
|
I appreciate the energy! Let's talk about what the spec should be and not the code you've worked on, since that should be unrelated to this spec. Instead of pasting images and links outside this draft PR, could you comment on the pieces of the draft spec you have questions/comments about? |
0bc3c3e to
7143235
Compare
clach04
left a comment
There was a problem hiding this comment.
There is a lot going on this proposal. I may have missed some pieces but I think there are there main things:
- eight colors to X color conversion - ala Base16, Base24, and potentially Base16++.
- TOML format
- the concept of named attributes not just baseXX, e.g. Comments
override.commentinstead of relying onbase03which handles Comments but also other stuff - This has (massive) implications for template writers to support. For new templates it will be significantly more obvious what the mappings are but existing templates would need update to benefit (albeit would continue to work fine as-is).
Quick thoughts:
- I love number 1! I'm super enthusiastic about this idea :-)
- I'm less enthused about TOML, I believe the creator of TOML is no longer advocating it but I can't locate a reference for this 😿 . The best I can do is point at https://en.wikipedia.org/wiki/TOML#Criticism (there are longer blog/posts with TOML critics) - I would recommend sticking with YAML for consistency with existing tined-theming specs
- I like number 3 - but I don't think it should be part of ANSI8 - this would benefit both base16 and base24. I keep meaning to open a discussion topic (but haven't made the time) to point out most templates do not use base03 for current line highlighting but instead consistently use base01 - this would resolve that.
I don't have good recommendations for number 3 other than break this out elsewhere. Maybe focus on ansi8 to base16//base24? Another idea to consider, have a working template example for this (maybe using vim, etc.) with that part of the proposal.
|
First I'll address some things and then speak about ansi8 more generally:
This concept is a tool, not a scheme system. We could create a website where a user picks 8 colors and we generate a base16/base24 scheme and it would satisfy what you mentioned here.
Yaml also has it's problems, I think one of the big confusing ones being what is and isn't considered a boolean. For example "Yes"/"No"/"y"/"n" strings are converted to booleans. But yeah I agree this doesn't need to be a discussion here. I'll switch the PR out to reference YAML instead. More generallyWith creating a new spec we should be considering all the issues we could foresee with the spec, at least within reason of course. When creating a new spec we could create a superset of base16 (like base24) or create something new that doesn't have any ties to base16. It would be nice to be able generate an ansi8 scheme from base16 or to base16, but it's not something that I think should be at the forefront of our minds since we have the opportunity to create something better, not base16++ (which is base24 since it's a superset). Some things we can take from base16/base24 is what was learnt along the way and not make the same mistakes. Some of the issues include:
Adding the variables to base16/base24 is something I think should be done and probably will be done in future, but it's difficult to try out something new like this with a well established and widely used spec which is out of our control a lot of the time (since it's being used by template authors outside of the Tinted Theming org). Working on it in ANSI8 both allows us to fix something we know will be an issue with ANSI8 and allows us to spearhead the scheme variable concept and add it to base16/base24 in future once it's stable. But let me know if this isn't making sense 😅 I'm not sure if I've been to close for this for too long that I'm skipping important points. |
bezhermoso
left a comment
There was a problem hiding this comment.
I have one comment re: variant which is very likely out-of-scope, so feel free to dismiss as such.
Re: TOML vs YAML. Neither of these formats are perfect, each having glaring quirks or unfortunate limitations. With that said, I think something can be said about the ubiquity of YAML. I've found that a lot of its limitations can be mitigated by tools that are more available, like JSON Schema.
specs/ansi8/builder.md
Outdated
| * `author` - the scheme's author. | ||
| * `variant` - optional, but recommended. Which variant of a given color scheme | ||
| this qualifies as. Currently only "light" and "dark" are used, but this value | ||
| could be anything. |
There was a problem hiding this comment.
I suppose the original intent of variant is less about differentiating light themes from dark themes, although that is by far the most common case, but on actual variations. In reality we have used this to really just differentiate between light themes and dark themes. At least, tinny-delta use it that way.
I do like the actual intention: this would flatten some of the schemes down to some extent that I think is good e.g. gruvbox-*, tokyo-*, but in practice its often different people coming up w/ new variants to themes they like. Unless we make authorship a variant-level property, it's unlikely this will be used as intended.
Perhaps this is out-of-scope for this particular specification, but this strikes me as something that isn't going to be used as written and this might be something worth reconsidering.
There was a problem hiding this comment.
At least initially we can lock it down to light and dark (or maybe permanently). We could potentially have a is-dark boolean and then variant on top of that which they could use freely.
This is off topic, but as for variants created by different authors which are different plays on one theme, I think we can talk about being more strict with that in the schemes repo. If people want a custom scheme they can create one and add it to Tinty and style their system. It doesn't have to be part of the schemes repo.
specs/ansi8/builder.md
Outdated
| | `override-string-quoted-{{template-variable-color-type}}` | default value derived from `green_default` | | ||
| | `override-string-regexp-{{template-variable-color-type}}` | default value derived from `cyan_default` | | ||
| | `override-constant-language-boolean-{{template-variable-color-type}}` | default value derived from `yellow_bright` | |
There was a problem hiding this comment.
Having string seperate from constants seems wierd.
I recommend move string(s) under constants.
What about numerics (int, float, exponentionl, hex,)?
There was a problem hiding this comment.
I've pushed a few commits which changes things a bit. override variables inherit their colours from their parents. This helps reinforce why string and number shouldn't be under the same parent. I've based almost everything off the widely used TextMate Theme structure: https://macromates.com/manual/en/language_grammars#naming_conventions. Keeping them separate and in inline with TmThemes allows us to also build a tool which can port TextMate themes to tinted8.
I've added a few more vars here. This setup also allows us to add variables in future under one of these parent groups.
There was a problem hiding this comment.
Modeling on an existing theme structure (and documenting heritage) is a good idea 👍. I'll take another look
There was a problem hiding this comment.
I'm not a TextMate user but I took a look at that spec, it looks like it keeps all literals underneath the constant tree - which seems reasonable to me. I'm not sure I understand your reasoning for keeping them separate. What are the benefits you are seeing? The negative I think you mentioned was inheriting from constants (which seems like a positive to me), so I may have misunderstood.
High level, I'm all thumbs up :-)
There was a problem hiding this comment.
Haha I think I'm misunderstanding too. constant and string are sibling properties in the TmTheme spec, so I've kept them separate here too. I'm not intentionally changing anything from the TmTheme spec, aside from adding the ui property to style UI and not just code.
There was a problem hiding this comment.
I've pushed a commit which fixed some override properties in builder.md since it was out of sync with styling.md
There was a problem hiding this comment.
@clach04 here's a screenshot of them being siblings. At least this is where my misunderstanding of your comment is coming from.
- Replace `overrides` property with `syntax` and `ui` properties - Rename `flavor` property to `style` to match css naming convention - Other small changes to make the documents easier to read
|
@JamyGolden looks good to me for first draft. I reckon this is a good starting point for initial builder implementation so we can play with it and iron out any issues. The Nord theme would be a good one for checking out the overrides. I recommend testing before finalizing version 1, alternatively be aggressive about bumping the version and be prepared to make breaking (not backwards compatible) changes based on real experience. EDIT possible test schemes to implement in tinted8:
|
|
For 3 we could do gruvbox or any scheme we won't use the theme/ui override values, since default should look nice too. Yeah we'll use semver for versioning and since we're on a I also want to add a |
|
Pinging @belak @FredHappyface @bezhermoso for any feedback before squashing and merging |
|
|
||
| ## Inputs | ||
|
|
||
| ### Scheme Inputs |
There was a problem hiding this comment.
On a side note, we may want to start defining the "scheme format" and the variables each builder exports differently.
I believe most of this has been copied from the base16 one.
There was a problem hiding this comment.
I forgot to add some of the inputs there (they were mentioned throughout the styling.md doc though) just pushed a commit. Base16 and 24 have 7 root scheme properties available, while there are now root 13 properties available here. What do you mean by defining the scheme format and and the vars they export differently?
There was a problem hiding this comment.
Ah, I meant that the scheme format itself lines up almost entirely with base16 - it would be nice to have a single place for the format and a single place for the theme-family-specific components.
| - `bright` - A lighter variant (e.g. `cyan-bright`) | ||
| - `dim` - A darker variant (e.g `green-dim`) |
There was a problem hiding this comment.
How are these actually generated? This seems to be designed around specifying base colors and generating in-between colors, but "bright" and "dim" seem a bit under-defined.
| - `orange` - Hue-shifted variant of `palette.yellow` | ||
| - `brown` - A deeper desaturated variant of `palette.red` |
There was a problem hiding this comment.
Similarly, how are these generated? Hue-shifted by how much? Deeper saturated by how much?
There was a problem hiding this comment.
I think this is a good step towards supporting other scheme systems.
I've got 2 main comments:
- I'd love to see us split out the scheme file format, so it can be shared between builder specs (nice to have, not a blocker)
- There are a few things where it's mentioned that color variants would be automatically generated if missing, but no information about the method used to generate them - those should be more clearly defined. In my eyes this is probably a blocker because it leads to undefined behavior.
faaa20e to
19182f0
Compare
Related to #140
Draft PR where we can define the styling specification. I'll add the
builder.mdspecification once we're a bit more clear on the direction of this without builder limitations.Add comments/questions/etc and we can discuss and edit. Something big that's missing is what the colors are used for styling. We have a lot more colors so we can style more. It comes down to also adding color variables in the spec, similar to what this draft PR is attempting to do #99. This will allow template creators to overcome color limitations the spec will ultimately still have.