We now enqueue the presets as CSS variables whether or not the theme uses theme.json.

Interesting, where this happens, do we have a dev note planned for this and a Core ticket to backport the change?

Also, it seems like the logical next step is to apply the block styles as inline styles using the CSS variable in this case. That way, we won't require any CSS from the theme author when defining custom presets.

It was done at #22722, because for link color we are referencing colors using preset CSS variables, and in that case, we need the variables even if the theme does not support theme.json.

I agree we need to update the current way to reference colors to be based on CSS vars like we are doing here. I had a PR for that #21490 so I guess we can reopen and continue that work.

Hi @youknowriad, @nosolosw This link requires the CSS var presets so we will need to include the global styles generation mechanism in core. It is a big step I guess may be able to do it but in case we don't want to do it, I guess a possible way to go would be to rely on condition "process.env.GUTENBERG_PHASE === 2" if the condition matches we reference the colors using the CSS variables otherwise we reference by value (for now), if we add this check into

, we avoid the need to backport global styles engine into the core (instead of reference we temporarily reference always by value on the plugin). I guess we don't need to make this decision now but it is a possibility we have. This possibility also does not causes problems with deprecations etc.

Is the "link color" pr something that is going to be included in 5.5 even if we don't have "theme.json" ready? If it's the case, we might need a dev note there too right?

(Just read the previous comment where you reply to the question)

I've expressed my conservative views on this topic before. However, I also appreciate how the link color feature is a great one to have in 5.5. What if we port to core only the functions that take presets from add_theme_support and the core defaults lib/experimental-theme.json (in case the theme doesn't define any)? Note that we also use the core defaults file for controlling the editor features. cc @gziolo

My thinking is that if we do that, and don't open it to third-parties (no hooks, no reading theme.json from themes, etc), we have leeway to modify the format in the next WordPress version. Is that correct? If it's not, I may suggest looking at alternatives (perhaps not using the core file and use inlined PHP variables within the specific functions or something like that). What do you think?