theme.json spec: document link color feature #22929
Conversation
|
I've built this on top of #22622 When that lands I'll rebase. |
|
Size Change: 0 B Total Size: 1.12 MB ℹ️ View Unchanged
|
201dab4
to
6e3cf0b
Compare
| @@ -16,8 +16,6 @@ The Block Editor surface API has evolved at different velocities, and it's now a | |||
|
|
|||
| This describes the current efforts to consolidate the various APIs into a single point – a `experimental-theme.json` file that should be located inside the root of the theme directory. | |||
|
|
|||
| When this file is present a few Block Editor mechanisms are activated. | |||
There was a problem hiding this comment.
We now enqueue the presets as CSS variables whether or not the theme uses theme.json.
There was a problem hiding this comment.
Interesting, where this happens, do we have a dev note planned for this and a Core ticket to backport the change?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.There was a problem hiding this comment.
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?
There was a problem hiding this comment.
(Just read the previous comment where you reply to the question)
There was a problem hiding this comment.
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?
Depends on #22622
Documents the changes introduced at #22722