Base colors display and calculations off of the browser's engine when lch() gets available.

Allow folding of nodes in the tree.
Children should then disappear and be shown as inline color samples.

Instead of filtering via JS and rerendering potentially vastly different lists each time, always render the same whole list and filter it via CSS classes.

Provide a way to define a preset in the tree using available nodes, and use that preset from other nodes.
This could make it easier to reuse some parts of the tree.

When opening a custom color node, show the RGB panel instead of the CSS one.
RGB is the most widely known format, and range sliders are more inviting to play with than the text input from the CSS panel.

Provide some nodes as single page helpers.
For example, the page /helpers/states could let the user enter a color, and it would output a highlight and a shadow color.
As in the full app, the user could also tweak the results afterwards.

The most useful nodes would probably be:

• states
• semantic
• contrasting
• scale
• neutral
• material theme light/dark

The UI should be unified and only show a color input at first, then the resulting colors with every bit of info required (hex, hsl and other codes, contrasts, …), along with tweaking options.

In the style of Accessible Brand Colors, show all colors in a grid.
One could then enable only the cells one cares about to get a tailored contrast report.

As of now, there is 5 action buttons per node, and there could be more in the near future (see #13, #22).
Some actions could be moved to a pop up menu, but some of them should remain accessible at all times:

• the "add child" button, as it is the most basic action in schemist
• every togglable buttons, as their state should remain obvious, namely "info", "settings" and "don't compare color" (which could disappear if the comparison system changes, see #4)
  This would also include "fold" if is folding implemented (see #22)

If all aforementioned issues were to be implemented, actions could look like:

• info
• settings
• fold
• add child
• more…
  • swap
  • remove

There would then be 5 buttons instead of 7.
Maybe the "add child" button could be placed elsewhere to get down to 4, as it is a little bit different from the others.

They're shifting hues of semantic colors towards the source one to make them more harmonious.
See https://material.io/blog/dynamic-color-harmony

Use a readonly textarea instead of a pre, so the selection can be contained in it.
Currently, CTRL+A selects all text in the page.

Sometimes, the APCA calculation yields 0 although it clearly shouldn't.
For exemple here, when checking APCA and Tritanomaly https://schemist.fglt.fr/?preset=1@3@6725x1e,6825x63,!3425x5501,!012122@clr,color,00aff9,s,$,amount,l,$%20dark,$%20softest

Allow swapping a block for another.
This would help in case one needs to change a color that has children, say from "lightness" to "highlight", thus avoiding deleting the block and recreating all of its children.

https://exome.dev/
This could match the tree structure of schemist without too much overhead.

It is considerably faster and easier to setup than Jest.

Instead of opening a modal each time one wants to add a child node, put them all in a side panel so one can grab any of them and drop them in the tree.
This implies supporting drag & drop not only from the library, but also on each node so the tree can be rearranged easily.

Save snapshots of the current state every time the user is idle for a moment.
This would prevent data loss on accidental page refresh, and allow building an undo feature easily.

Some generated URLs can't be parsed back:

• https://schemist.fglt.fr/?preset=1@5@5667x288f9y28a,ab67x198f9y28a,0122401,5667x288f9y28a,ab67x198f9y28a,01223234@367591,clr,,color,d6084f,hlt,$%20light,amount,shift,temp,sdw,$%20dark

HCT is a color space created as a basis for Material Design color operations.
It may be close to the space used by schemist while being more robust.
https://github.com/material-foundation/material-color-utilities/tree/main/typescript

Add a switch to simulate color blindness, maybe with https://www.npmjs.com/package/color-blind
Contrasts ratio could be recalculated on top of it.

Provide a way to setup different variables, with a name and type.
Then allow connecting those to any input in the app.

For example, one might setup a lightness variable of type percentage, and then assign it to the LCH's lightness of many colors in the tree, thus making theme adjustable all at once.

The input expands user input when it is a valid 3-digit hex code, making it pretty unusable.

Store export options globally so they are persisted if the user closes and reopens the modal.

Allow one to change the color space used by all nodes to modify colors.
It would probably be impossible to add "all" of them, as they vary wildly in how they function, but it should be easy to add ones that rely on the same mechanics (i.e. ones that are based on a hue/saturation/lightness mechanic).

Consider an export format based on these specs https://design-tokens.github.io/community-group/format/

• HSL values don't match with HSL CSS values.
• LCH values and CSS values don't match with values in color sliders

Write a preset that follows MUI palette structure.
If possible, integrate with Material-UI Theme Creator by providing a pre-configured URL.

Provide a way to export the palette as a styleguide (HTML, PDF, …?).
This would probably require some tweaks, i.e. letting the user add descriptions to colors and combinations, so the styleguide ends up directly usable.

These buttons are located below the palette, which is potentially huge, pushing the buttons out of view.
Maybe they could be moved to the menu bar, given it is made visible at all times.

Find a spot to show color codes (hex, hsl, …) within the tree so they are instantly visible and copyable.
Maybe next to node types (highlight, shadow, lightness, …) as they don't take up much space.