App/website theming and editing colors
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 675
- Forks
- 18
- Avg merge
- 5h 11m
- Merged PRs (30d)
- 1
Description
In my app I have this config for colors atm:
/* Website colors */
--background: oklch(1 0 0);
--foreground: oklch(0 0 0);
--accent: oklch(0.21 0.034 264);
--accent-foreground: oklch(1 0 0);
/* Editing colors */
--svedit-brand: oklch(60% 0.22 283);
--svedit-editing-stroke: var(--svedit-brand);
--svedit-editing-fill: oklch(from var(--svedit-brand) l c h / 0.1);
--svedit-canvas-stroke: color-mix(in oklch, currentColor 25%, transparent);
But I realize that website colors and editor colors are somewhat tied together, like if you have lets say a purple background, you want to adjust your editing color (currently --svedit-brand) to something that stands out on that background. It's essentially another highlighted foreground color reserved for editing and custom-coloring selections in read-only mode.
I'd like to set this up in a more app-dev friendly way, so it's the same mechanism (e.g. background+foreground colorsets that always follow the same structure, currently i'm always mixing up things from webapp-theme-land and svedit-theme-land)
/* Website colors */
--background: oklch(1 0 0); /* white page background */
--foreground: oklch(0 0 0); /* black text */
--accent: oklch(0.21 0.034 264); /* e.g. accented CTA button */
--accent-foreground: oklch(1 0 0); /* foreground for fills in accent color */
/* Editing colors */
--editing: oklch(60% 0.22 283); /* e.g. cursor and selection rectangle color */
--editing-foreground: oklch(1 0 0); /* foreground for fills in editing color */
In addition to background/foreground pairs we might need additional variations for strokes or backgrounds like a background-variation (light grey) that some block layouts can use or the selection rectangle (semitransparent selection rectangle). Question here is if we should make them explicit (like --svedit-editing-fill), which gives you more control or derived (the app uses color mix etc), which makes the config simpler, at the risk of ending up with derived colors that don't really work.
Related question: Is there a reasonable way to automatically derive a suitable outline color by mixing a foreground/background color pair?
For example: you have a black-on-white colorset, and the strokes should be light grey, but when you set white-on-black the outline should become dark grey that just stands out enough from the black background to be noticable as an outline. I didn't manage to find a reliable algorithm for that.
Would be nice if Svedit 0.10.0 could lock-in a nice to use and good-enough color-scheme API/methodology for apps, so we don't break this in the forseeable future.
@johannesmutter thoughts?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the existing website and editing CSS custom properties shown in the issue, then compare explicit color variations with derived colors and outline-generation approaches. Done means agreeing on a consistent, documented theming API and methodology suitable for Svedit 0.10.0; no file or test is named in the issue.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- css, typescript
- Domain
- design, frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100