Global styles interface with styling for v1

[karmatosed]

This issue builds on from #19255 and focuses on moving to a PR for this. As part of this I am going to list what is likely to be the defaults and for the paragraph block (as starting with that makes a lot of sense).

Plugin activation and sidebar

For v1 this is going to appear as a sidebar, activated by clicking. When this happens the sidebar becomes the global styles interface. You are now in global styles and once click again, you come out.

To style all of a type of block, you simply click that block and all 'select'. Notice, there is no toolbar as we aren't editing here. The sidebar will change to show block specific global styles.

All the way along you can 'reset', 'undo/redo' and save. Save sets any change live, it's the publish state. You can also close using 'x' or click the icon to come out of global styles.

This version has some noticeable existing styling over the iterations to color picker. This is on purpose, to focus and iterate once the experience can be used. Iterating components can and will happen in the near future.

Default global styles

By default, the following are my suggestions for being available:

Text:

• Scale: a simple range control
• Alignment: this applies across all text and includes justified (with a warning for accessibility)

Color:

• Background
• Text

Paragraph styles

As you can see in the gif posted, once you click in you get options that are just for the paragraph. Anything done here applies to all. Noticeably this includes line-height, see #20339. Also, the drop-cap wouldn't show as that really is per block, changing all paragraphs to drop-cap is a rare instance.

Next steps

Ideally, we can move into iterating the current PR work here. I am going to loop @ItsJonQ in to activate that. As far as feedback goes, that is of course welcome. The idea here though is to move this into prototype (actual interface) and then see what this feels like for everyone.

I plan to close out the long issue where the interface was explored so we can now focus. Thanks, everyone that has helped to get global styles as far as it's come. It's going to be great to experience this. The icon to activate is up for debate on this too, if anyone has ideas around that.

This is also part of the bigger checklist tasks you can find for global styles here #20331

[karmatosed]

I am also going to add a mock of what 3 default colors could look like. This would bring back the background, text and primary:

This would be 'global' so defaults. I suspect this is something we do as we go into later iterations, but adding here as a nice next step.

[richtabor]

@karmatosed I'm not quite following the "Colors" bit from your screenshot. Just for clarification, in this mockup, does the user click on the color to change it? Or on the "Custom" text? Or am I thinking too far ahead here ha :)

[karmatosed]

@richtabor in this mock they would click custom, which is the current behaviour. I would love to iterate this in later versions, for now that is the same as we have.

[karmatosed]

I spent some time today after discussions refining what will be the v1. The following is a good distillation of options and respects what themes might already have:

• Font family
• Base font size and type-scale
• Link color (default/hover|focus/active)

Along with this for v1, there will not be the ability to click any block, whether that comes or not is a little further off to visualise in the interface right now.

Here are a few versions of what that could all look like.

Simplified

This version has a simple colors option for the link and also just has one font family.

Heading and text

An iteration could be to allow a font family for header and text.

Notice, this also combines the base font size and scale into one line, compacting a little the inteface.

Adding line height

There could be a case to be made to bring in line height and weights if we are adding a scale. An idea for that is:

Removing sections

As we are starting off with smaller content, maybe we don't have sections at all.

Feedback

I would love to get some feedback on what we have here and there are some discussion points:

• Do we need sections?
• Do we need line-height if have a scale?
• Do we need separate fonts for heading and text?
• What copy could be done differently?
• What options might need adding either for v1 based on development work happening, or you'd like to have really soon available?
• What options I have shown just don't need to be in v1?
• Does the tabbed color picker work in this instance or should we go back to the single one and then just show colours for each color to choose?

I'd also love other input here.
cc @mtias and @jasmussen also.

[jasmussen]

This is coming together excellently, Tammie. It definitely feels like you're zeroing in on the right ingredients. I also think it's good to focus on what may be an obvious first version — just a list of items — because it's always possible to add sections and UI categorization later on as it becomes necessary.

Do we need separate fonts for heading and text?

Yes I'd say that seems a good way to group things. The question is whether you need font controls for each heading level, and I'm leaning towards not at this time, but maybe it becomes necessary in the future. Probably a bridge to cross when we get there.

Overall, I think https://user-images.githubusercontent.com/253067/76650869-59b9ce80-655b-11ea-8d41-379464b1483c.png is the one to work with.

Perhaps the controls inside need a little massaging to align in a good way, right now it looks as though it says "Lineheight: bold".

[ZebulanStanphill]

Do we need separate fonts for heading and text?

Yes I'd say that seems a good way to group things. The question is whether you need font controls for each heading level, and I'm leaning towards not at this time, but maybe it becomes necessary in the future. Probably a bridge to cross when we get there.

Agreed.

Perhaps the controls inside need a little massaging to align in a good way, right now it looks as though it says "Lineheight: bold".

Labeling the font weight dropdown would probably help a lot.

[munirkamal]

Hi Everyone,

I just want to share some of my feedback which may be useful as you are working for Global Styles. I've recently created 100+ templates/patterns in Gutenberg, and here is my experience with that.

---

What I can tell is that we have enough default blocks to create amazing designs in Gutenberg. But those blocks are missing some basic Options and therefore we have to use custom CSS for that.
Those basic styling options include:

• Typography: Font Family, Line Height, Font-size (some blocks has it some not).
• Box Shadow
• Border
• Max-Width
• Margin, Padding
• Vertical Content Alignment

If we can have a set of consistent basic styling options for the default blocks, users may be able to create pretty great & complex designs easily.

I opt to use custom CSS for most of the designs I created for templates.gutenberghub.com

But there is again an issue that we do not have a place to add custom CSS code which applies in Gutenberg editor. I know we can add that to the customizer, but that doesn't enqueue to the editor.
So another suggestion would be a custom CSS box accessible via the editor. I think it would be in the Global styles pannel/sidebar?

[mtias]

Thanks for sharing your experience, @munirkamal. That's the spirit of the design tools label, to start gathering the main shortcoming to express visual designs better. Feel free to add examples to those so that we can look at accounting for them.

Agree global styles should have access to a CSS editor, even if it's not the main suggested UI for people and can be disabled. (Same role as in the customizer, probably.)

[karmatosed]

@jasmussen here is an iteration on the font styling:

[karmatosed]

I also explored what adding the easiest form of custom CSS could be here by adding an input just to global styles:

There are of course other ways of doing this, just went for what could be most simple to start.

[jasmussen]

Nice iteration. The real estate still feels a bit out of balance. While generally Figma isn't necessarily a pattern to follow, there's something optically well balanced about their text panel:

• Text is always on the same line, whether in an input field or not.
• Much of the panel square feels well used.
• Things are grouped in horizontal rows.

From this it seems worth trying to:

• Put font weight and font size on the same line below the font itself. And use the same type of dropdowns for both.
• Maybe don't "bold" the text in the weight dropdown, the content on the left is probably sufficient as a preview.
• It seems like "body and heading" is enough for fonts for now, but it feels like it deserves a bit more separation. A border separator? Make it a separate panel?

Colors feels like it's in a good place to start from.

Custom CSS is going to be a bit of a doozy. I did superfluously see the conversations about supporting this, and I'm excited about what this can do for enriching designs as we await the editor growing in features. But can you share a bit more context around what role the field will serve? My first instinct was that each block pattern could come with a chunk of CSS to support it, though I wasn't quite sure how that would work.

[karmatosed]

All excellent questions :) I dove in a bit to experiment with what variations could look like.

Base font is text

Base font is meant to be where the scale moves up from. This could also be inferred to be body text. A variation of that could be this:

All in a line

If I moved style, line height and size to one line it could look like this:

Note: I just did a rough idea of what a line-height icon could look like.

Split lines

I found the 3 in one line a bit much, so what about changing that to be on 2?

I also felt lines did help visually, but we could increase spacing just as much:

Custom CSS

As an 'easy option' I was just going for text input, there are a lot of options here and maybe we should just focus this issue on the styling and bring that in at a later point? The more I ponder that the more I wonder if it isn't a better case to focus our discussions.

[ZebulanStanphill]

Remember that all controls should have labels. I'm not seeing any for the font weight or font size dropdowns in the current mockups, and I think it's important to keep those in mind when figuring out how to space out the controls.

[karmatosed]

I have now pulled out this into individual issues so closing the overarching one. You can follow along everything block styles here: #20331