Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Typography Tools: Tracking defaults for blocks #35604

Closed
3 tasks done
Tracked by #33447
apeatling opened this issue Oct 13, 2021 · 15 comments · Fixed by #34064
Closed
3 tasks done
Tracked by #33447

Typography Tools: Tracking defaults for blocks #35604

apeatling opened this issue Oct 13, 2021 · 15 comments · Fixed by #34064
Assignees
Labels
[Feature] Design Tools Tools that impact the appearance of blocks both to expand the number of tools and improve the experi [Type] Tracking Issue Tactical breakdown of efforts across the codebase and/or tied to Overview issues.

Comments

@apeatling
Copy link
Contributor

apeatling commented Oct 13, 2021

Part of #34345

We want there to be consistency of typography tools across core blocks. This means making sure core blocks are opted into the correct typography tools, and have appropriate defaults set.

Active work related to this:

@apeatling apeatling added [Type] Tracking Issue Tactical breakdown of efforts across the codebase and/or tied to Overview issues. [Feature] Design Tools Tools that impact the appearance of blocks both to expand the number of tools and improve the experi labels Oct 13, 2021
@apeatling
Copy link
Contributor Author

@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?

@mtias
Copy link
Member

mtias commented Oct 13, 2021

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.

@ramonjd
Copy link
Member

ramonjd commented Oct 14, 2021

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

@mtias
Copy link
Member

mtias commented Oct 15, 2021

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

@kjellr
Copy link
Contributor

kjellr commented Oct 15, 2021

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?

@jasmussen
Copy link
Contributor

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.

@ramonjd
Copy link
Member

ramonjd commented Oct 23, 2021

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!

@andrewserong
Copy link
Contributor

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
image image

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

@jasmussen
Copy link
Contributor

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?

@andrewserong
Copy link
Contributor

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).

@ramonjd
Copy link
Member

ramonjd commented Oct 26, 2021

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.

@andrewserong
Copy link
Contributor

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.

@ramonjd
Copy link
Member

ramonjd commented Oct 28, 2021

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.

@aaronrobertshaw
Copy link
Contributor

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.

@jasmussen
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Design Tools Tools that impact the appearance of blocks both to expand the number of tools and improve the experi [Type] Tracking Issue Tactical breakdown of efforts across the codebase and/or tied to Overview issues.
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

7 participants