Preset controls need the preset CSS variables in scope

[oandregal]

Reported at https://github.com/Automattic/themes/pull/2659/files#r512186187

Theme authors can use CSS Custom Properties to define the presets, for example, to make the gradients depend on the solid colors:

{
  "color": {
    "gradients": [
      {
        "slug": "some-gradient",
        "gradient": "linear-gradient(to bottom, transparent 20%, var(--wp--preset--color--secondary) 20%, var(--wp--preset--color--secondary) 80%, transparent 80%)"
      }
    ],
    "palette": [
      {
        "slug": "primary",
        "color": "#000000"
      },
      {
        "slug": "secondary",
        "color": "#3C8067"
      }
    ]
  }
}

These definitions end up attached to the user-facing UI tools. The problem is that these tools aren't part of the editor canvas (wrapper by the .editor-styles-wrapper class), so the CSS Custom Properties aren't defined, hence it doesn't work. See what would happen in this case:

This is because, both in the post-editor and the site-editor, the global styles are prefixed by the editor wrapper, hence its scope doesn't reach the UI controls.

[oandregal]

Some thinking out loud:

• In the post editor, we pass the styles via the styles key of settings, so they are processed (added the .editor-styles-wrapper) as if they were theme styles. In the site editor, we add the wrapper ourselves.

• Presets defined at any level (global, but also core/paragraph, etc) create CSS Custom Properties. For them to be in the scope of the UI controls they have to be outside the editor wrapper.

One thing we can do to fix this is to separate how we embed styles and presets in the HTML document: the presets are always enqueued by the server as an inline stylesheet (no style rule mangling in the client) and the styles continue to work as they are now (processed by the client, as to only affect the editor canvas).

So, we'd have:

/* inline stylesheet enqueued by the server for the presets */

:root { /* global context */
    --wp--preset--color--primary: 'value';
    --wp--preset--color--secondary: 'value';
}

p { /* core/paragraph context */
    --wp--preset--color--primary: 'value';
    --wp--preset--color--secondary: 'value';
}

/* inline stylesheet created by the editor (post-editor, site-editor) for the styles */

.editor-styles-wrapper { /* global context */
    background-color: 'value';
}

.editor-styles-wrapper p { /* core/paragraph context */
    background-color: 'value';
}

cc @jorgefilipecosta in case you have any thoughts.

[jorgefilipecosta]

Hi @nosolosw, I think the path you are suggesting is correct. We should not make presets and custom variables inside editor-styles-wrapper. This includes the preset classes. The code that generates the presets on the client should also reflect that and not generate the presets inside the .editor-styles-wrapper tag.