Export options HEX + HSLA

Regarding your last point: These options only apply to the classic editor, that is before the new block editor got introduced (pre WP 5) or if you are using the classic editor plugin. It does not do anything to the presentation of the palette.

Re HEX and HSLA: Yup, can add a select box giving you the choice what colour format the CSS export should have.

Check out version 1.14.1. I’ve added a select box for choosing a colour format for a CSS/SCSS export and updated the preview box accordingly.

Hi Daniel, I installed the latest version, deactivated and reactivated it, cleared cache.. Whatever I do I don’t see a difference, or at least I see the the preview for CSS variables is set to RGBA, not HSLA, while the exported document uses HEX
There is no additional select box.

+ For the second point palette presentation, the issue was seen in the elementor WSIWYG text editor.

I’m not talking about the current published version 1.14, but 1.14.1 which I’ve submitted to the plugin repo. Earlier I’ve posted a link to the zip which you need to download and manually add to WordPress, preferably not a live but a development site. Then have a look at the Backup box, select CSS and there should be a select box saying Color Format.

• This reply was modified 4 years, 12 months ago by Daniel Men?ies.

I used the good version but tried with the CSS variables since it was the subject. I gave it a new try with CSS and yes, it worked well, with both values, hex & hsla. Are both needed for compatibility ?

Can you please add this to all exports, especially variables ?

CSS Variables, right. Did miss that. Yes, can do. Well, first assiging a hex and then a rgb/rgba/hsl/hsla value increases backwards compatibility. Can add an option to add or leave it out for an export.

Ok, that should do it. Just download the version 1.14.1 again and reinstall it.

Awesome !
The full compatibility option is not there yet :

a rgb/rgba/hsl/hsla value increases backwards compatibility. Can add an option to add or leave it out for an export.

but it work as I need it for now.

Big thx.

by the way, it would be wonderful if the color setups would propagate any changes to old entries. Let me explain : While I think this is not achievable, it would be awesome to change any old color values to new values, where any colors used by this color setup would be updated using the new colors.
Enabling this would then update all colors used with the same ID or color name by the new ones.

This is probably far behind the scope of this plugin, but a subject of reflection.

Regards.

A’righty then. Please have another look at 1.14.1. There should be compatibility hexa values for CSS/SCSS exports, though none for SCSS variables as they are run through a preprocessor.

Yes, it would be great if each “thing”, for want of a better word, that got a colour assigned could be updated afterwards. Unfortunately most of these things don’t keep a log how they got their colour. For that to happen WordPress needs to offer a palette, but keep palette, “things” and thing-colour-relationship separate. A first step has been done within the new block editor where colours are assigned as CSS classes on a per block basis. As long as one keeps those classes in good health theoretically you could change all colours retrospectively. The theme customizer and pretty much any other plugin/theme that I had a look at in terms of palette support does not maintain such a thing-colours-relationship, except Elementor for example.

When you are importing a colour palette my plugin actually tries really hard to re-use existing colours to minimise chaos. Have a look at the API docs for further details.

• This reply was modified 4 years, 12 months ago by Daniel Men?ies.

– Super cool update !

– Thx for the clarification about the new class-relationship added in the Gutenberg editor. This sounds promising and maybe could you ensure that you update those class colors, without changing the class names.

I’m not sure to understand what you ment with :

When you are importing a colour palette my plugin actually tries really hard to re-use existing colours to minimise chaos.

I have no colors set in my theme options, so maybe that’s why I don’t see “imported colors”.

About the API (link is wrong), this is probably over my capabilities since I have only designer’s capabilities (no PHP & JS).

Version 1.14.1 is out.

Re: imported colours. I was talking about my plugin.

Generally, if you made a palette and checked Add to block editor my plugin does exactly that. Themes can support various features and one of those is called editor-color-palette. It expects a list of colours with each entry having an actual colour code, a name and an internal name (so called slugs). These slugs are used to generate CSS classes that get assigned to blocks inside the new editor. My plugin simply adds the palette to that feature and generates corresponding CSS for these slug-CSS classes by assigning each colour of the palette an unique number, i.e. .has-central-palette-12-color { color: #223399; }.

Now, let’s assume you’ve got a nice site up and running, used my plugin and are quite pleased with the palette you’ve chosen. You decide to export the palette and reuse it on another site that uses my plugin as well. At that moment when you import the new palette from your first site, the one on the second site gets overwritten. What would happen to your colours inside the block editor? Chaos – some would be replaced while others just revert to whatever is set via your theme’s stylesheet.

In order to avoid such chaos my plugin tries to merge an imported palette with the current one by comparing each colour. That comparison is a bit elastic meaning colours don’t need to match exactly, i.e. #CCCCC would replace #CFCFCF because visually one can’t really distinguish them anyway.

Does this answer your question?

Hey, that’s a nice explanation, slightly behind my actual needs, so I’ll have to give it some trials later on.
As said for now, I try to stick with only custom CSS theming (variables) without entering the theme options, using one and single theme for all projects and for now starting with a single site builder to. Trying to stick with a kind of KISS approach.

I hope once to have time to address your interesting approach.

For the best UX, please add the new features and deep explanations to the plugin’s home-page so that anyone can benefit of it.

Best regards.

• This reply was modified 4 years, 11 months ago by tdechangy.
• This reply was modified 4 years, 11 months ago by tdechangy.

Hi Daniel,

firstly thanks for your latest update to include hsl(a) colors to variable exports.
I had sadly to see that the hsl(a) values are missing their “%” character after second and third value, which makes it near useless until manual update for each export… this must absolutely be fixed, especially when having long theming files.

+ As additional updated request I would love to see a real hsla color selector. YES, hsl(a) are the only human values, so why sticking to obscure hex or hazardous visual pickers only ?
NB: it would be awesome to respect the chosen color type (hex, hls or rgb) to be the default value. This is really to go deep in the color selection but for some colors, even small changes can be annoying. For instance, having my exported colors to hsl(a) gives values decimals (ex: 12,34) which are not super fancy. By the way, using hsl(a) is not only more human centered but have also a slightly wider array of colors.

Yes, you’ve seen my underlying point, I LOVE HSL(A) colors, and should become just standard to easy everyone’s life on this… One thing at a time.

Waiting to continue nice work with all this ?? !

• This reply was modified 4 years, 10 months ago by tdechangy.