suggested lexicon: `site.standard.color.palette` #4

Ok, this idea requires a bit of logical introduction. For the short version of things, visit the current site for palettes, 4bitcss

A while back, I wanted a bunch of palettes for some sites, but I didn't want to go thru the painful exercise of building/naming N number of palettes. In fact, I realized I didn't want most people to have to go thru that slight hell.

Imagine wanting to bring a selection of palettes to a client and trying to let them pick one. Without a formal name, this would be a nightmare to even communicate ("I like the purple-ish one.... which one?"). The ideal would be to pick a popular store for palettes and derive a palette from that store, thus keeping standardized names that are easy to communicate.

Next up was the desire to be able to render different major status types for conditions.

Think: standard named colors for "error", "warning", and "success".

We could reinvent the wheel here, or we could look to palettes that somewhat define these already.

The answer I ended up at was to take existing iTermColorSchemes palettes and generate a CSS version of each.

This ended up being very straightforward:

Each palette consists of a series of named colors that match their names in a Windows Terminal profile.

For example, if you wanted a palette that looks like Adventure Time you can just create a CSS variable for each name in the Windows Terminal Palette Json and almost call it a day.

Beyond being logically simple and getting hundreds of palettes right "out of the box", this approach also allows for cool synchronicity between a terminal and web ui experience.

It's possible to use any of the color palettes within a page and use the exact same color palette in the terminal.

Now I might be alone in thinking that's cool, but I don't think I am.

Last but not least, if site.standard.palette.terminal or any such lexicon was standardized, it would be possible to make palettes easy to edit / share / aggregate. This would allow any site to get a huge boon from using standard.site: an endlessly expanding set of palettes would come "for free".

To clarify the schema in Markdown form:

Property	Type	Description
`$type`	`[string]`	The type of the object. Must be `site.standard.color.palette`.
`name`	`[string]`	The name of the palette
`colors`	`[object]`	The named colors in the palette. Must contain 'foreground, 'background'. Should contain the standard 16 terminal colors
`luma`	`[number]`	The luma value of the palette background, expressed as a number between 0 and 1
`contrast`	`[number]`	The contrast value of the palette foreground and background, expressed as a number between 0 and 1.
colorscheme	[string]	Indicates if the palette is bright or dark. Could theoretically be any valid color-scheme

I hope I have made a compelling case for this type of palette declaration.

I'm open to suggestions on the name. Was originally thinking: site.standard.palette.(terminal|named|rich|colors), and then the very obvious logically NSID hit me:

site.standard.color.palette

this is a cool idea, and i appreciate how thorough you've been in your opened issues. the 4bitcss approach is clever. my hesitation is scope.

we created the site.standard.theme.basic lexicon to solve a narrow problem: giving apps enough information to render styled embeds or link previews. 4 colors, anything more complex and we're asking a lot for apps to implement.

we intentionally do not define the theme lexicon (other than this basic theme) because that is the publications or platforms job. existing platforms have their own needs and have not yet converged on similar enough implementations. also something to keep in mind, though we don't design our lexicons to be requirements, we have seen people that view a lexicons existence as a required implementation. we want to avoid unintentionally dictating solutions that may feel like overkill for most use cases.

for example, i am using daisyUI themes for @offprint.app, though limit it for my needs. daisyUI has 4 base colors, 2 colors for primary, secondary, accent and semantic colors plus border radius sizes and other options. but if i pushed that into standard.site, most publications would find it unnecessary or overly complex for that they are trying to do and some may even see it as a required implementation.

a richer palette system with 16 colors, luma, contrast, and color scheme is useful, just for different purposes than what we are solving here in my opinion.