search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.47k stars 4.18k forks source link

Typography Tools: Tracking #34345

Closed mtias closed 1 year ago

mtias commented 3 years ago

Tools:

Mockup:

Screen Shot 2021-09-24 at 2 00 42 PM

Components

When using predefined font-size value, the font size controls change depending on how many values need to be displayed

Predef (< 6 sizes) Predef (>= 6 sizes) Custom font size
image image image

Integration

Design

aaronrobertshaw commented 3 years ago

The letter spacing control is currently not working: #32577

I noticed this while testing changes removing custom prefixes from theme.json properties that didn't need it.

~A fix is included in that PR: https://github.com/WordPress/gutenberg/pull/34485~

Fixed in https://github.com/WordPress/gutenberg/pull/34515

TL;DR When the typography tools were grouped the letter-spacing support key wasn't updated as per the others.

pablohoneyhoney commented 3 years ago

Here's an update on some of the typography components and behaviors.

Screen Shot 2021-09-24 at 2 00 42 PM

In particular regarding the Size component. Below there's a bit more detail around aspects not considered before, like variants on number of values (segmented UI for 4 or 5 values, and dropdown for >5), types of values if we want to consider t-shirt, tooltip to contextualize abstracted values, and toggling to input custom values.

Size-component

Relevant to #34574

ntsekouras commented 3 years ago

👋 - I've started looking at the font size picker and my first issue that is missing the designs is the default value and the reset button. How do these two fit in the control? -cc @pablohoneyhoney

ciampo commented 3 years ago

👋 - I've started looking at the font size picker and my first issue that is missing the designs is the default value and the reset button. How do these two fit in the control? -cc @pablohoneyhoney

It would be great if you could coordinate with @mirka , she's also been looking at this.

ntsekouras commented 3 years ago

Regarding Letter spacing control that seemed important to have units, do we need to revisit something design-wise? I'm not sure if we have a control with +/- symbols and the unit select..

javierarce commented 3 years ago

@ntsekouras:

👋 - I've started looking at the font size picker and my first issue that is missing the designs is the default value and the reset button. How do these two fit in the control? -cc @pablohoneyhoney

Is there an expectation to be able to reset every control or just the font size one?

I think something like the following solution could work for components that span the entire column (in this example, 24 is the default value)

image

mtias commented 3 years ago

The resetting comes from the tools panel and allows resetting each item. You can see it in this video:

https://github.com/WordPress/gutenberg/pull/33744

javierarce commented 3 years ago

The resetting comes from the tools panel and allows resetting each item. You can see it in this video:

Oh, thanks, that makes sense… showing reset buttons for several components would make panels look very busy.

mirka commented 3 years ago

@pablohoneyhoney Are there public Figma links for these mockups, by the way? I see that the components are available, but I'm wondering if there's another mockup file I don't know about.

mtias commented 2 years ago

What's the status of this one?

ciampo commented 2 years ago

The status of the tracking issue seems quite up to date, meaning that we'd mostly need to refine/polish FontSizePicker and a few dependent components. The components squad hasn't had much capacity to move this forward, but we've been collaborating with folks like @ntsekouras @aaronrobertshaw @andrewserong and @ramonjd on PRs touching these components.

I also know that @mirka has worked/is working on aligning the design and behaviour of some of these components closer together.

ramonjd commented 2 years ago

Consider whether responsive options can be exposed in the UI: https://github.com/WordPress/gutenberg/issues/24480

Update: Wednesday, March 23 2022

I've endeavoured to dive into a backend option for fluid typography based on existing fontSizes presets in theme.json.

When fluid typography is "activated" in theme.json, we generate font-size values using clamp().

The resulting font sizes can be applied to any text block in the editor UI, and the preset CSS vars to any root element or block in theme.json.

It's still work in progress as I look at various approaches, and consider the constraints on such functionality for an initial version, taking into consideration future development and (future) backwards compatibility should we change clamp algorithms.

The intention is to make fluid typography an available option for themes initially, so that themes can switch seamlessly between the two leaving no CSS artefacts behind. 🤞

An editor-based exploration is also underway.

cbirdsong commented 2 years ago

image

The resetting comes from the tools panel and allows resetting each item. You can see it in this video:

Oh, thanks, that makes sense… showing reset buttons for several components would make panels look very busy.

I think conspicuous reset buttons would actually be useful since it allows you to know at a glance what values you've adjusted away from the default. Here is how Webflow lets you know something has been modified and lets you reset to the default: CleanShot 2022-06-16 at 08 24 18

ramonjd commented 2 years ago

Update on fluid typography June 22, 2022

The PR to add fluid font sizes to theme.json has been updated to support passing single values to the fluid type callback, and returning clamp() values based on a set of defaults: minFontSizeFactor, maxFontSizeFactor and scaleFactor.

This was the intention behind https://github.com/WordPress/gutenberg/pull/33543, which was testing converting custom font sizes to clamp() values.

I think it's a pretty good place to retest and hopefully get in!

ramonjd commented 2 years ago

Update on fluid typography August 4, 2022

The theme.json fluid font size API and a couple of follow ups have been merged 🎉

A follow up PR to add extra configuration to the fluid settings is underway:

jasmussen commented 2 years ago

For the segmented control of preset font sizes, we ended up going with numbers as a starting point:

Screenshot 2022-08-03 at 10 22 13

However I'm finding myself missing the t-shirt sizes as originally conceived. They seem much more descriptive and universal after all:

Screenshot 2022-08-03 at 10 24 45

I would love to work with someone to try going back to those. It seems like it could be a small PR to get a feel for it, and I'd love to collaborate with someone to try this. @ramonjd or @andrewserong would you have bandwidth to pair with me on this one?

mtias commented 2 years ago

Let's try it, should be just an appearance update with the system we have in place. (Note we should handle XXL as well, even if not included in the default set.)

ramonjd commented 2 years ago

would you have bandwidth to pair with me on this one?

I should have time to take a stab at it next week. 👍

ramonjd commented 2 years ago

@jasmussen Just in case I can't get to it next week, is there any further context (or better, an issue) in case someone else picks it up?

I think numbers are extracted from the theme.json size values (strips the units and uses the number values). So the 2 here is really 2rem in my theme.json:

Screen Shot 2022-08-05 at 3 30 46 pm

It would be interesting to hear how we'd map t-shirt sizes to arbitrary values, unless we just assume that the order of font sizes in theme.json will be from smallest to largest? The first thing that comes to mind is a sorting function before we print them.

mtias commented 2 years ago

@ramonjd aren't the slugs already mapped behind the scenes anyways?

ramonjd commented 2 years ago

aren't the slugs already mapped behind the scenes anyways?

@mtias If I'm interpreting things correctly, yes, the slugs that appear in setings.typography.fontSizes[].slug are mapped to the JS objects we use to build the fontsize controls.

I'm still catching up with all the feedback over at:

Here's an example option object that's used in the editor, where the name property contains the value of the font size's slug:

{
    "key": "medium",
    "value": "20px",
    "label": "20",
    "name": "Medium"
}

The font size picker parses the values and use the integers as the labels. So, yeah, we'd need to map the t-shirt labels before the controls are rendered I believe.

Maybe update the titles as well. Something similar to what @ntsekouras was doing in this commit.

It would be good to get an idea of the expectations. Here's a very basic implementation that labels the first 5 font sizes with t-shirt sizes, regardless of their values.

Font size picker with t-shirt sizes https://user-images.githubusercontent.com/6458278/183323896-49924d98-a9c1-4ecb-b311-a74888607a23.mp4
jasmussen commented 2 years ago

It would be good to get an idea of the expectations. Here's a very basic implementation that labels the first 5 font sizes with t-shirt sizes, regardless of their values.

Understanding that you could desync the custom labels from the t-shirt sizes, yes, that basic implementation, in my opinion, is exactly what I was thinking of. Worth putting in a PR and getting a feel for it.

My impression is that we shouldn't optimize towards mapping the t-shirt sizes for what a label might or might not be — mapping them sequentially, just like the numbers were, allows authors to map these on their own, and regardless as soon as you get more than 5 options, it becomes a dropdown.

noisysocks commented 2 years ago

Just doing a quick audit of how the Typography section in Global Styles looks compared to the design. I'll then try to fix some of this up.

Designs:

Panel Font size variations
Global styles typography design Size variations

What's in trunk:

Font size radio Font size dropdown Custom font size
Image Image Image
noisysocks commented 2 years ago
  • [ ] Letter spacing is missing
  • [ ] Letter case is missing

I'm trying to work out whether these two controls are supposed to be in Global Styles or not.

Global styles typography design

I can see that Letter spacing was added to block settings but not Global Styles in https://github.com/WordPress/gutenberg/pull/31118. Not sure if that was an intentional omission.

@aaronrobertshaw tells me that Letter case used to exist in Global Styles but was removed because it was felt that this shouldn't be something that is controlled at such a high level.

At any rate it would be good to revisit these decisions cc. @WordPress/gutenberg-design.

mtias commented 2 years ago

They should be available for headings in the global context

mirka commented 2 years ago
  • Heading level

As discussed in #42718, this heading level switcher needs to have tabpanel semantics. The easiest way would be to use the existing TabPanel component, but design-wise it won't fit seven items in a single row.

One possibility is to make a new TabPanel component (or style variant) that looks like a 32px height ToggleGroupControl — though there hasn't been a confirmed decision or prioritization on this yet from the design side. We can move forward with this if we can get confirmation that this is sufficient visual affordance for a user to distinguish between a radio and a tabpanel.

jasmussen commented 2 years ago

The tab-panel that looks like a segmented control, if it's super quick to build, seems like we should just knock it out! But with a freeze in a few weeks, of course it should have lower priority than anything that needs to go in 6.1.

talldan commented 2 years ago

As discussed in https://github.com/WordPress/gutenberg/pull/42718, this heading level switcher needs to have tabpanel semantics. The easiest way would be to use the existing TabPanel component, but design-wise it won't fit seven items in a single row.

Has there been an accessibility check on making it a TabPanel? If it changes a value, my instinct would be that TabPanel is the wrong thing. Usually tabs don't have such an effect, they're just a way to navigate through information. It may need to be another component that looks like a TabPanel.

mirka commented 2 years ago

If it changes a value, my instinct would be that TabPanel is the wrong thing.

In this case in the Global Styles (Typography ▸ Headings), it isn't changing a value, just flipping between views. (It does look like a value selector on first sight, which is exactly why we need to differentiate 😄)

jameskoster commented 2 years ago

which is exactly why we need to differentiate

I agree with this. If we have 'tabpanels that look like segmented controls' and/or 'segmented controls that look like tabs' then we risk creating an unpredictable UX. A style variation for tabs that is 'secondary' in terms of visual hierarchy might be good to explore. This would be useful in situations where we have nested tabs as well.

mtias commented 2 years ago

The semantic role of different heading levels is close to that of block variations:

image

So maybe the issue is both visual and hierarchical, and heading level should go above the preview with more context around it.

mirka commented 2 years ago

The semantic role of different heading levels is close to that of block variations

I don't think so. The block variation switcher behaves like a radio — its value is persisted, and the values of its sub-controls are discarded when you change the block variation to another one. The heading level switcher in GS is purely a tabpanel switcher — its value is not persisted, and the values of all their sub-controls are persisted regardless of which tabpanel you last see.

mtias commented 2 years ago

I mean the semantic role in terms of how they are represent from the block API perspective — we have registered heading levels as variations of headings — which means accessing them could be presented as separate blocks or the quick variations selection. This also goes for selecting the right heading element in the block inspector on a block instance.

bobbingwide commented 2 years ago

Re: #42782 I see that the code's been merged so I'm commenting here.

The changes to make the labels uppercase have introduced a problem with Jetpack's Field consent block.

In the block editor, the text is all uppercased, which makes it difficult to edit.

image

See also https://github.com/bobbingwide/bobbingwide/issues/77

Elsewhere it's been suggested that using text-transform: uppercase is bad for accessibility. Is it too late to revisit this issue?

mirka commented 2 years ago

Re: #42782 I see that the code's been merged so I'm commenting here.

Replied in https://github.com/WordPress/gutenberg/issues/42782#issuecomment-1251073331 👍

noisysocks commented 1 year ago

I've completed most of the items in https://github.com/WordPress/gutenberg/issues/34345#issuecomment-1217390408 and in the issue description. The remaining items are, I think, fairly marginal and not worth prioritising over https://github.com/WordPress/gutenberg/issues/33094 which is the key focus for the editor team.

Here's how the Typography panel now looks in trunk—things are very close to what's in Figma:

https://user-images.githubusercontent.com/612155/199615854-30124692-f194-4fc2-ae2c-136aa7c2ec74.mp4

I think we can close this overview issue out and use smaller bug/enhancement issues for any further iteration that's required.