Colour handling improvements #8702
Conversation
The replacement library from https://colorjs.io/ is much, much larger but I think we can develop a custom build that uses treeshaking to whittle the code down to the bits that we need. @linonetwo does that sound feasible? I intend the explore further improvements but I wanted to start by establishing a library that can do modern P3 and OKLCH colour calculations.
Really just syntactic sugar for the wikify widget
Using the new wikify operator. Currently has a bug whereby redirected colours (like "tiddler-background") do not work. Direct colours like "background" do work. Note the hacks needed to makeFakeWidgetWithVariables work
|
Confirmed: Jermolene has already signed the Contributor License Agreement (see contributing.md) |
| @@ -2853,19 +2867,22 @@ a.tc-tiddlylink.tc-plugin-info:hover > .tc-plugin-info-chunk .tc-plugin-info-sta | |||
| color: <<colour foreground>>; | |||
| } | |||
|
|
|||
| .tc-chosen > .tc-tiddlylink:before { | |||
There was a problem hiding this comment.
IMO we need to keep this configuration for backwards compatibility. We can add a "deprecated" comment, but plugin authors may use these styles.
I'll need to make some more tests, with the palette-manager edition.
There was a problem hiding this comment.
@Jermolene -- The tools-buttons: theme, layout, storyview and palette use this CSS. So IMO we can not remove it
There was a problem hiding this comment.
All the "chosen" indicators fail now.
| @@ -2,15 +2,18 @@ title: $:/snippets/paletteswitcher | |||
|
|
|||
There was a problem hiding this comment.
Can you add indentation, so it's easier to read
| "fields": { | ||
| "type": "application/javascript", | ||
| "title": "$:/core/modules/utils/dom/color.js", | ||
| "module-type": "library" |
There was a problem hiding this comment.
IMO we should add 2 more fields: version: 0.5.2 and repo: https://github.com/color-js/color.js to make it easier for us to maintain
There was a problem hiding this comment.
Hi @pmario if we were going to add those fields then we should do so consistently for all the 3rd party libraries in the core.
There was a problem hiding this comment.
I think that would be a good idea and we have to start somewhere.
|
Is there a demo to test colour handling improvement? |
Hi @kookma I've posted a preview to tiddlyhost |
These filtered palettes are still just experiments with the techniques, and not yet a serious palette
I think I might be building a programming language for writing palettes...
Via some future UI
Still a work in progress, but getting more coherent
|
Hi Jeremy, Thank you |
| For example, this filter expression will get the lightness of the colour current page background colour: | ||
|
|
||
| ``` | ||
| [function[colour],[page-background]colour-get-oklch:l[]] |
There was a problem hiding this comment.
I did test this: [function[colour],[page-background]colour-get-oklch:h[]] -> RSOD See suffix :h
Click for screenshot
There was a problem hiding this comment.
Hi @pmario I'm not able to reproduce this with the latest build. Could you kindly check?
|
Hi @kookma
I've been making a steady trickle of changes in the background – this is my current "low priority but fun" project :) You can see the latest changes here: https://deploy-preview-8702--tiddlywiki-previews.netlify.app |
|
@Jermolene -- To reproduce RSOD
|
Introduction
Preview build: https://deploy-preview-8702--tiddlywiki-previews.netlify.app/
We get persistent of feedback that the visual aesthetic of TiddlyWiki is old fashioned and dull. It's fair criticism: the default look and feel was intended to be muted so that the users content took centre stage but has ended up flat and lifeless.
The ultimate goal of this PR is to allow end users to easily devise their own colour schemes that match their tastes and work harmoniously together.
This will be accomplished with a new user interface that is presented in the empty "GettingStarted" tiddler, and in the control panel. The UI would have sliders and switches for the user to express their taste: colourful vs. muted, dark vs. light, saturated vs. unsaturated.
Underneath those controls would be displayed a grid of 9 random palettes generated to match the parameters. The user can choose one of them and either select it, or choose to use it as the basis to generate further variants.
The underlying mechanism is based on the idea of palettes defined as a small number of base colours, with rules for dynamically generating the full palette by dynamically lightening, darkening or otherwise manipulating an existing colour. This approach is similar to that of the colour system in Android for example.
This PR is highly experimental. It may not be merged in this form; I have already started cherry picking parts into separate PRs.
Colour Manipulation
We need a colour manipulation library that can calculate variants of colours. Only color.js met the requirements of being able to work with P3 colours and the OKLCH colour space. It also includes a CSS colour string parser which can replace the simple one that TiddlyWiki has always incorporated.
Static Palette Entries
The key idea underpinning these changes is a fundamental change to the way that TiddlyWiki handles palettes. At the moment, palette entries are named items that can contain either a CSS colour string, a CSS colour token like "inherit", or use the
<<colour>>macro to reference another colour palette entry. Thus, palette entries have to be wikified before they can be used. This has turned out to be extremely limiting.The idea of static palettes is that at the point of switching to a new palette, the colours within it are "compiled" to raw CSS colour values (typically but not necessarily in
#rrggbbaaformat). This allows palette entries to be used directly, without the requirement to wikify them.The static palette is created in a new system tiddler
$:/temp/palette-coloursby an action procedure that is invoked at startup and when switching to a new palette.The primary backwards compatibility issue is that any existing code that switches palettes by writing to the tiddler
$:/palettewill no longer cause a palette change because$:/temp/palette-colourswill not have been updated. Code that uses the core palette switcher will continue to work properly.This change will also allow us to change the
<<colour>>procedure to be a function, which will allow it to be used as the value for a style attribute:Modern Palettes
This PR also introduces a new type of palette referred to as "modern" which is exactly like the existing palette except that the entries are defined as functions that must be evaluated, rather than wikitext that must be wikified.
This makes it possible to create palettes that reference and modify other colours. For example:
Colour Palette Preview
Something I've wanted for a long time is to improve the colour palette chooser to include a preview. It is not finished yet, but has turned out to be quite easy and very effective:
References
Progress