[MOOSE-395] FE: theme.json settings extension

[GeoffDusome]

What does this do/fix?

This branch broadens editor customization by leaning on WordPress appearanceTools in theme.json instead of maintaining long lists of per-block settings. Editors get access to the standard block design controls (spacing, borders, typography where applicable, etc.) across blocks, aligned with the new Block Settings Support wiki page.

theme.json

• Sets appearanceTools: true so core appearance-related controls are available theme-wide.
• Removes many explicit settings.blocks.* entries that were selectively enabling things like blockGap, borders, or typography on individual blocks (e.g. buttons, columns, cover, group, navigation, lists, query pagination children, social links, etc.). Those behaviors are now covered by global appearance tools where appropriate.
• Keeps or tightens a smaller set of block-specific overrides where the design system should still limit the editor, for example:
  • core/button: additional restrictions on color, shadow, typography (e.g. custom font size, font weight, line height, letter spacing, text decoration), plus existing border/spacing/typography limits.
  • core/group: link/button color controls disabled.
  • core/post-template: blockGap disabled.
  • core/query-pagination: text/link color disabled.
  • core/table: background/text color disabled.
• Color: adds defaultDuotone: false, registers two theme gradients (simple-black-horizontal, simple-black-vertical) for overlays/fades, and adjusts the color settings object (e.g. drops some prior false flags that are redundant or superseded by appearanceTools).
• Typography: removes several global typography feature flags and dropCap from settings (handled or implied differently with the new setup).
• Shadow: sets defaultPresets: false so only the theme’s custom shadow presets apply.
• Spacing: removes explicit global margin / padding / blockGap flags from settings.spacing so spacing behavior follows the new appearance-tools configuration.

Styles / tokens

• assets/pcss/color/_variables.pcss: exposes CSS variables for the new gradient presets (--gradient-simple-black-horizontal, --gradient-simple-black-vertical) mapped from --wp--preset--gradient--*.

Misc

• blocks/core/embed/style.pcss: whitespace-only formatting (blank line after file header comment).

QA

Links to relevant issues

• Link to Issue

Screenshots/video:

• Link to Video

Testing environment:

• http://moose-dev-pr352.d1.moderntribe.qa/

Pull request checklist

• I've added a changelog entry for these changes.
• I've linked to a relevant Jira issue.
• I've captured a screenshot or screencast of the changes and linked it above.

[LayaTaal]

@GeoffDusome I love this direction overall. I think it is good that we open more up. It will allow us to explore and learn what works and doesn't. I also love the inclusion of the wiki 🌮 .

One thing that caught my attention was the new color settings for the group block. What would it look like if we dropped the color themes altogether and supported theming via the color settings in the group block? Do you think that is more complicated?

If we do want to keep the color themes, why do we want the other color settings at all for the group block?

[GeoffDusome]

@LayaTaal

One thing that caught my attention was the new color settings for the group block. What would it look like if we dropped the color themes altogether and supported theming via the color settings in the group block? Do you think that is more complicated?

This is how we originally were handling color theming for the Group block and we decided to go against this direction. For some specific situations, we want to be able to color theme a block, but change the background color to a slightly different color. Say, if there's a one-off pattern or section that uses a brand color, but it's not a brand color theme.

If we do want to keep the color themes, why do we want the other color settings at all for the group block?

I guess the answer to this is, "we probably don't", but I can see a scenario where a client would want all headings or all headings of a specific size to be a certain color for a section that varies from the design system.

---

Asking these types of questions is what led to us being so specific and locked down with our settings. Opening it up allows us to learn & understand how settings are being used, if they are being used at all, and if we need to turn anything off if it goes against what we want the client to have control over.

By no means is this the standard for every project. Andrew was discussing the possibility that there would need to be a discovery step at some point to determine the level of ability of the client editors and if we need to lock things down a little bit more to help keep them focused.

Sarah mentioned that "hey, we create so many patterns for clients during dev of a project, clients should be using those and not really editing too much, these settings would be extremely helpful for the design team's ability to make those patterns though."

[dpellenwood]

🍏 Thanks for tackling this, @GeoffDusome & team! I know we've gone around on this in specific cases/detail a few times. Appreciate the holistic pass!

[Vinsanity]

🟢 Love it! nice work @GeoffDusome Also, I love the WIKI update to track disabled settings. That's going to be massively helpful moving forward. 🌮