Theme.json var:preset:color... formatting not working for settings.custom object

[richtabor]

Description

I'm trying to reference colors like var:preset|color|black using the new formatting within the theme.json's settings.custom object, but I am not able to do so. Is this an oversight, or a purposeful limitation?

It seems like the new formatting doesn't work within custom.

Step-by-step reproduction instructions

1. Add a custom property to a theme's theme.json file.
2. Use the new formatting for the variable, see below:

{
  "settings": {
    "custom": {
            "test": "var:preset|color|white",
    }
  }
}

3. See front-end, where the CSS variable is not used.
4. Use the var:preset|color|white anywhere else and it'll be converted to ``var(--wp--preset--color--white);`

Screenshots, screen recording, code snippet

Environment info

WordPress 6.0
Gutenberg 13.6.0
Any theme

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[oandregal]

👋 The vertical bar syntax (var:preset|color|black) is an internal format used in some situations (user data: inline styles and global style) to bypass kses restrictions. It's not intended to be used by 3rd parties.

I don't remember that we have document it anywhere. Reviewed the how to guide and the reference and it's not there.

There were some changes to kses since this was introduced (support for CSS Custom Properties and fallback CSS Custom Properties) so we might actually be able to remove the vertical bar syntax. I vaguely remember that I had prepared a PR to do so a while ago (can't find it now) but we couldn't do it at the time. cc @jorgefilipecosta as he may have more context.

[cr0ybot]

@oandregal FYI this vertical bar syntax is being output when I export changes made to Global Styles, so I had assumed it was going to become a recommendation at some point. I was also looking for documentation about it and Anne McCarthy in the Post Status slack pinged you as I understand.

[colorful-tones]

I feel like I've seen questions around this syntax surface a few times lately in a variety of theming contexts. It seems like it would be super helpful to extend the support for it, as opposed to deprecating or removing support for it. 🤔

[jorgefilipecosta]

is an internal format used in some situations (user data: inline styles and global style) to bypass kses restrictions

It was not kses restrictions that were the main concern. It was because when serialized as a var would be:

>var(\u002d\u002dwp\u002d\u002dpreset\u002d\u002dcolor\u002d\u002dwhite);

So to void the unreadable markup, we decided on that format.

There were no issues found with the format. Some people even prefer it. I think we could consider this case of not supporting it a bug and include support for it. If there is no one against the change I can try to propose a PR.

[colorful-tones]

If there is no one against the change I can try to propose a PR.

@jorgefilipecosta I think it would be great to open up support for this type of vertical bar syntax and there is a somewhat related issue (nice to have) for the upcoming Twenty Twenty-Three theme. #43627

I'm tagging in @WordPress/block-themers for more input on how useful this syntax is perceived. Thanks!

[MaggieCabrera]

@jorgefilipecosta I think it would be great to open up support for this type of vertical bar syntax and there is a somewhat related issue (nice to have) for the upcoming Twenty Twenty-Three theme. #43627

I'm tagging in @WordPress/block-themers for more input on how useful this syntax is perceived. Thanks!

I think it's a matter of preference for the syntax but it's important to note that using the CSS variable will allow you to do things like linear-gradient(var(--wp--preset--color--base), var(--wp--preset--color--contrast)) while the other syntax will not

[XedinUnknown]

Indeed, when you actually need to use the value in CSS - then the CSS (var(--wp...)) is the way to go. However, I noticed that when I set it this way in theme.json, block settings don't recognize the selected colour as one of the presents - but just simply as the value. They doesn't even always correctly display the colour itself on the button. I assume that if you give a CSS variable an e.g. styles.elements.h3.color.text, it can only use it verbatim, but cannot resolve it to one of its own enumerated presets.