@mtias To be clear, should we be opting all core blocks above into all typography tools where it makes sense (counter example being font family for the code block), and then using the Tools Panel to set the smart defaults that show to users as per #34064?

Yes, all text blocks should be supporting all tools (unless one doesn't make sense for some reason in a specific context, but I can't think of one right now) and we should use the defaults to emphasize the appropriate initial states for each. The lack of that control has been the main blocker to expand the tools to all blocks because it just made things a bit overwhelming. Now that we have the control we can support the tools while remaining lean.

Just to confirm the full suite of typography tools for text block block.json files:

"supports": {
   ...
    "typography": {
       "fontSize": true,
        "lineHeight": true,
        "__experimentalFontFamily": true,
        "__experimentalFontStyle": true,
        "__experimentalFontWeight": true,
        "__experimentalLetterSpacing": true,
        "__experimentalTextTransform": true,
        "__experimentalTextDecoration": true
        ...
}

• Font size
• Line height
• Font family
• Font style
• Font weight
• Letter spacing
• Text transform
• Text decoration

I believe text-decoration has been a bit challenging before? Also font-family is one I'm not sure we should be exposing in local contexts, only in global styles.

If we can divide it in two passes, an initial set would be:

• Font size
• Font style
• Font weight
• Line height
• Text transform
• Letter spacing

With this other list probably needing a more specific revision:

• Font family
• Text decoration

With this other list probably needing a more specific revision:

Font family
Text decoration

In WordPress/twentytwentytwo#108, we've been discussing strategies for styling hover/focus states for text links (which is more #27075 territory). Part of that discussion involves implementing more specific text-decoration polish. For example, text-decoration-thickness and text-underline-offset.

Do we think specific rules like those will end up as part of these tools, or should we stick to CSS?

I believe text-decoration has been a bit challenging before?

To expand on this: text-decoration is inherited all the way down the stack, and cannot be unset on an ancestor. So for example if an underlined text decoration is applied to the navigation block, every child element including everything from search fields and other items, get underlines that cannot be unset.

So text-decoration should only ever be enabled for individual non-container blocks at the end of the hierarchy.

Also font-family is one I'm not sure we should be exposing in local contexts, only in global styles.

Can anyone expand on this point?

The question came up as to whether we should be removing font-family from blocks that have already opted in, e.g., Buttons in #30394

If we remove to remove font-family opt ins I think we'll need to update the deprecations for the following blocks (based on E2E failures we saw when we first removed it):

• Verse
• Site Title
• Query Title
• Site Tagline
• Post Date
• Post Comment Date
• List
• Navigation Blocks

Happy to go ahead to do this if folks think we shouldn't be opting in.

Thanks!

Also font-family is one I'm not sure we should be exposing in local contexts, only in global styles.

I can see a good argument for hiding in local contexts to avoid inconsistent styles across a site. However, with folks building a variety of different patterns and template parts into sites, I could imagine a site using different font families for Heading blocks (for example) within post content versus within a large footer or a banner-ad style Cover block used for subscriptions. (Think a more decorative serif font for headings in post content or big cover blocks, sans-serif for small footer headings).

I guess what I'm thinking is that we have a need for an intermediary kind of "global" style, which is a style that's suited for a template part or pattern used across a site, but maybe not all instances of a particular type of block. Local context is our current way of enabling that kind of styling within the editor. For a tiny example of what I mean, here's the Hollywood Reporter's footer, which uses a sans-serif font for its footer headings. And a couple of headings from elsewhere on the page:

Footer heading	Normal heading

I'm not sure how important it is to optimise for that use case, though!

Keeping in mind that it's very easy to flip the switch from hidden to surfaced, and that users can always click the ellipsis to add the control on a per-block basis, I do like the idea of starting simple and with as little as possible, then we can always revisit and toggle controls if we find it to be necessary.

In the case of the heading block, it reminds me of a separate issue that we really should find a solution to. Right now it appears that you can only really set a global style for the Heading block itself, not individual configurations on a per level basis. In the use case above I would imagine they have assigned different fonts to different heading levels perhaps?

Good point, Joen! Yes, being able to set font family (or other styles) by heading level would likely resolve that use case in many instances of it, I’d imagine. (The cases I’ve found on a couple of different sites used h3/h4 in the footer but h2 in the post content, so they’re a good fit).

I can see a good argument for hiding in local contexts to avoid inconsistent styles across a site. However, with folks building a variety of different patterns and template parts into sites, I could imagine a site using different font families for Heading blocks (for example) within post content versus within a large footer or a banner-ad style Cover block used for subscriptions.

From a theme designer perspective, I guess it would be a comforting baseline to be able to dictate heading and other element styles in theme.json without fear of "rogue" inline styles corrupting my beautiful designs 😄

Still, opting in to font support is also something that theme developers can enable and disable – even on a per block basis – in theme.json if they wanted to restrict things.

On the specific question of whether we should remove opt-in supports for blocks that already support it for 5.9, I'm tending towards "no, for now". We can handle the changes in deprecations but I fear there wouldn't be enough time for testing regressions.

On the specific question of whether we should remove opt-in supports for blocks that already support it for 5.9, I'm tending towards "no, for now".

I agree. Given that themes can switch off support as you mentioned, it sounds like a good one to leave for the moment, at least.

I agree. Given that themes can switch off support as you mentioned, it sounds like a good one to leave for the moment, at least.

👍

I think #34064 is ready for another round of review in that case.

In the case of the heading block, it reminds me of a separate issue that we really should find a solution to. Right now it appears that you can only really set a global style for the Heading block itself, not individual configurations on a per level basis. In the use case above I would imagine they have assigned different fonts to different heading levels perhaps?

The Elements API via theme.json allows for some styling of the various heading elements <h1-6>. These elements can also be targeted within a block context e.g. core/cover etc.

From a theme designer perspective, I guess it would be a comforting baseline to be able to dictate heading and other element styles in theme.json without fear of "rogue" inline styles corrupting my beautiful designs 😄

A theme designer should be able to do something like this. They can style elements via the theme.json and then use the theme.json settings to disable the UI for styles/features they don't want the user to override.

Oh right, the elements, nice. But it would be nice to also pair that with a UI. I could imagine a collapsed singular Heading interface, but with option to "unfold" it to individual levels. Not something for the near future, but a thought.