It should be easy to see, what changing colours does to the wiki UI
1.1 All previews should show “live” UI elements (if possible) so interaction is possible
1.2 Especially hovering and selecting UI elements
1.3 There should be a visual connection between the colour and the UI elements
Users should be able to add new previews on their own
Existing previews should be easy to overwrite or hide
Replacing or hiding the whole existing system should be easy. So users can use their own code if needed
Search / Filter is possible
<<colour search is possible
Undo is possible
Focus on an element is possible
Known issues:
There is no undo yet
Some colours don’t have an effect in the UI yet. That’s not a new problem, but now it is obvious. Investigations are ongoing.
@TW_Tones I did update the OP with a link to the demo edition, to play with. No need to export import something. … More info about the plugin and the intended use can be found at the demo page
@pmario this is looking great. As I understand it, to make each example work you need some inside knowledge to make a custom preview. It seems to me at this point it would be worth capturing such information and provide it as additional info to the class in question. perhaps behind an icon eg;
Hi Mario,
Is there any benefit using color macro instead of css variables? I mean while you can use CSS standard like below
color: var(--somebasecolor)
Why still we use
color: <<macro somebasecolor>>
If it was possible to define a set of base colors and then use of calc+var in css to create all shades, colors for other elements, that would be great.
Hi Folks,
I did just update the OP with a new screencast and the plugin is live at the demo page
This is still experimental, but I think it’s pretty usable already. It would be nice if someone would have a look at the existing palettes … AND fix them. They have some flows. … most of them.
I appreciate your work on this. I think it’s great to have previews and annotations inline with the editor!
I am also working on making some adjustments to my wiki’s palette manager. I want to convert each definition’s hex code to HSL and be able to sort on each of the three components.
I’m having a bit of difficulty finding where the color macros output the actual hex code of the color input fields.
Anyway, I think it would be nicer if, for each entry in the index, it always showed just one color input field, and that it correspond to the actual color. There could be a little link icon that shows when it is referring to another style definition, with a link to that definition. If another color is selected via the color input field or the text box, that link would disappear. And if there could be three ways to specify a color: 1. input the hex etc code, 2. choose a color from the input field, 3. choose an already specified color – a little drop-down box with tiny swatches perhaps – I think that would be ideal.
Also I’d like to “plus plus” the idea of having LESS-style variables in play, which might be achievable now with pure CSS, wherein one can specify shades of colors easily, ala <<red lighter 20%>>
@JenniferS
I highly support improvement of current color/colour macro and palette. If they could work with hsl, then there is a huge flexibility to play with color.
Macro color can be extended to accept more parameters like alpha/filter, etc.
It is intended to be part of the core. .. In the meantime I did create a new colour-widget, that is specifically designed to be able to work with resolved colour values. … So instead of an initially “black” color-picker, it will start with the “real” colour given by any <<colour xx or any other future colour-macro.
