Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[IDEA] Ship Palette with Rendered Wikitext to Final Color Codes #8550

Open
kookma opened this issue Aug 24, 2024 · 7 comments
Open

[IDEA] Ship Palette with Rendered Wikitext to Final Color Codes #8550

kookma opened this issue Aug 24, 2024 · 7 comments

Comments

@kookma
Copy link
Contributor

kookma commented Aug 24, 2024

Is your feature request related to a problem? Please describe.
The palette uses wikitext to set color of some elements. This makes it difficult to reuse those wikitext. Instead having color codes, makes life for plugin developer much easier. For example, there are simple tools (wikitext and JS) to get a color code and generate different shades of it, or apply the alpha channel and opacity etc.

Describe the solution you'd like
To keep the backward compatibility, when ship palettes with TiddlyWiki, use the rendered palette i.e. the compiled color to their final values. It seems the old TiddlyWiki uses hex codes. The original palette can be kept with core code.

@kookma kookma mentioned this issue Aug 24, 2024
4 tasks
@pmario
Copy link
Member

pmario commented Aug 24, 2024

IMO the contrary is true. Using colour variables makes changing colours easy, without the need to change the configuration.

Also plugins should use TW colour codes. It should be possible to add an alpha parameter to the <<colour macro>>

Plugin authors also should use the <colour macro whenever possible. So the user can switch between light and dark mode and the plugin UI will still work.

Hardcoding all values will make palette switching impossible.

@kookma
Copy link
Contributor Author

kookma commented Aug 25, 2024

Would you please give an example to demonstrate using color wikitext as color value in palettes is better and simpler?

I am trying to create a lighter shade of blockquote-bar for my plugin usage? What I have to go now is like this where I have to call the $wikify and then I can store the color value!

<$let palette={{$:/palette}}
      selectedColor={{{ [<palette>getindex[blockquote-bar]]  }}}>
<$wikify name=colorValue text=<<selectedColor>> >		

<$text text=<<colorValue>> /><!-- for test purpose-->

call procedure gets color value and creates new shade..


</$wikify>
</$let>

Then in place I want to use the above code (stored inside a procedure, I have to use another $wikify.

@pmario
Copy link
Member

pmario commented Aug 25, 2024

Eric made a comment at: #8326 (comment) which points to a Talk discussion: https://talk.tiddlywiki.org/t/how-to-use-the-colour-macro-as-an-attribute-value/10051

This may be an option for plugin authors to add an alpha value to existing core values.

Erics code:

\define colorRegexp() <<(get)?[cC]olou?r .*>>

\function getColor(c) [{$:/palette}getindex<c>] ~[[$:/palettes/Vanilla]getindex<c>] ~[[$:/config/DefaultColourMappings/]addsuffix<c>get[text]] :map[function[recolor],<currentTiddler>]

\function getColour(c) [function[getColor],<c>]

\function recolor(c) [<c>regexp<colorRegexp>] :then[<c>split[ ]last[]trim[']trim["]trim[>>]] :map[function[getColor],<currentTiddler>] :else[<c>]

A myColour function that adds an alpha channel.

\function myColour(c alpha) [function[getColor],<c>] [<alpha>] +[join[]]

Be aware, that myColour can only handle hex-values or <<colour macros -- It can not be used recursively.

image

@kookma
Copy link
Contributor Author

kookma commented Aug 25, 2024

Thank you! but this is complex as you see!

@pmario
Copy link
Member

pmario commented Aug 25, 2024

Thank you! but this is complex as you see!

IMO not more than everything else. You need to create the macro once and then you can use is. The complexity is hidden away. That's true for most of the TW stuff.

The main advantage of our colour-macro and also of CSS variables is, that the assignments in the CSS code can stay the same. Only the variable definitions need to change to switch to a different palette.

I think it would be nice if our core colour-macro could allow us to assign an alpha value, if we need it. But I'm not sure if we can change the colour macro in a backwards compatible way. --

@ericshulman -- Did you ever run experiments with an alpha value added to the <colour macros. The code you mentioned at: #8326 (comment) looks very promising. (except the last issue)

But would it be possible to add an alpha value there?

@ericshulman
Copy link
Member

CSS colors that include an alpha value need to be specified using 8-digit hex: #rrggbbaa.

However, color palette values permit:

  • 3-digit hex: #ccc
  • rgb() decimal: rgb(192,192,192)
  • rgba() decimal: rgb(192,192,192,128)
  • X11 color names: lightgreen
  • colour macros: <<colour foreground>>
  • arbitrary wikitext that resolves to any of the above

Thus, simply appending an alpha value to a colour macro result is not sufficient. All of the above would need to be converted to #rrggbb first, before appending a hex alpha value.

@kookma
Copy link
Contributor Author

kookma commented Aug 26, 2024

Thank you all!
After this discussion my viewpoint still is to ship final palette with color value, say 6-digit hex or equivalent and keep the use of macro, wikitext, other color functions at programming/development stage, the overhead is compiling/rendering the palette raw text/wikitext to final values. We know due to backward compatibility still user can hack the palette colors and use wikitext at their own risk.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants