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

Consistently styling global vs local blocks #47348

Closed
SaxonF opened this issue Jan 23, 2023 · 14 comments · Fixed by #49428
Closed

Consistently styling global vs local blocks #47348

SaxonF opened this issue Jan 23, 2023 · 14 comments · Fixed by #49428
Assignees
Labels
Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json Needs Design Feedback Needs general design feedback.

Comments

@SaxonF
Copy link
Contributor

SaxonF commented Jan 23, 2023

What problem does this address?

image

Styling a button locally vs globally results in two very different experiences which adds to a users cognitive load. This also applies to how variations are listed and styled.

This work slots under the broad goal of reducing the editors overall complexity.

What is your proposed solution?

image

Use the same approach for both global and local contexts when styling a block. We would indicate whether a block was being styled globally. Variations are also listed the same way and in future this could include an "add variation" feature.
tldr inspector should look mostly the same when styling a block globally vs locally except for an added indicator.

This is partially a follow-up this issue.

cc @WordPress/gutenberg-design

@SaxonF SaxonF added Needs Design Feedback Needs general design feedback. Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json labels Jan 23, 2023
@jasmussen
Copy link
Contributor

It was a bit hard for me to grok the initial proposal, as it included a couple of separate enhancement suggestions (like breadcrumbs, or edge to edge preview), but if I get it right, the last two panels are meant to represent GS > Blocks > Button (global context) and the editor inspector with a Button selected (local context), is that right?

If yes, then I think the main take-away that I agree with is that right now the two are diverging especially in terms of context.

  • Editor inspector has Color / Typography / Layout panels, but also other panels like Border and Advanced.
  • Global styles has sections for Color, Typography and Layout, but no more. So any block controls, like border radius, that doesn't fit in those three, usually gets dumped in the Layout section.

The fact that the two are so close but still diverge, does suggest we should unify here as a first step. I mention this in the initial box shadow designs too. If need be we can do the ellipsis panel behavior too, but that seems like it can be explored separately.

@youknowriad
Copy link
Contributor

Some time ago I've created this related discussion #37064 which is basically the same thing but form a technical level.

@carolinan
Copy link
Contributor

Related: #47146
You expressed it better, so I can close 47146.
The main points from that issue is:

  • We need to call these variations the same thing on both screens.
  • I think both screens should use the wide display of the variation name that is used in global styles, since currently in the block editor, the names get truncated.

@SaxonF
Copy link
Contributor Author

SaxonF commented Jan 23, 2023

@jasmussen I've updated the issue to hopefully clarify. Will spin up breadcrumbs as a separate issue.

tldr inspector should look mostly the same when styling a block globally vs locally except for an added indicator.

@youknowriad
Copy link
Contributor

Looking at the proposed designs, I think there's an inconsistency in the first mockup (the top level global styles). "Typography", "Colors"... should also be the same as the ones that show up for a given element/block.

@SaxonF
Copy link
Contributor Author

SaxonF commented Jan 23, 2023

@youknowriad not sure I follow, could you please expand?

Pasting a related thought from a separate thread:


Quick thought. The current GS IA looks like:

  • Typography
    • Elements
  • Colours
    • Palette
    • Elements
  • Layout
  • Blocks

This has always felt a tiny bit strange to me because I often just want to focus on styling an element in its entirety as opposed to focusing on a single style first.

An alternative might be:

  • Presets
    • Typography
    • Colours
    • Spacing
    • Layout
    • etc
  • Styles
    • Elements
    • Blocks

Define your presets/foundation then apply them to your site.

@youknowriad
Copy link
Contributor

If you click on "Typography" in the top level screen of the global styles you'd see the same "screen" we have right now if you click "Typography" within "Button" block or "button" element. The only difference is that the top level updates the "body" element if you like.

So what I was saying is that these top level styles (typography, colors, layout) should also be combined in the same view that is similar to the one you're proposing for the "button" global view.

@youknowriad
Copy link
Contributor

Question about the proposed designs above. If you take a look a the "colors" panel in the paragraph block in both editor and global styles you notice this:

  • In the regular block inspector, it shows: "Text", "Background" and "Links"
  • In the global styles right now, it shows: "Text", "Background", "Links" and "Headings".

Should we support all the elements supported in global styles at the local block level as well?

Also, in the global styles panel we allow you to edit the palette which is technically a "setting" not a "style". How do we account for that in the proposed designs?

@jameskoster
Copy link
Contributor

Also, in the global styles panel we allow you to edit the palette which is technically a "setting" not a "style". How do we account for that in the proposed designs?

I've always found it a bit strange that palette editing is given so much prominence when styling a block. A contextual edit link in the color picker might work better.

Screenshot 2023-02-14 at 10 51 42

@youknowriad
Copy link
Contributor

Personally, I'd prefer to avoid it entirely there and separate "styles" and "settings" entirely if that makes sense.

@jameskoster
Copy link
Contributor

I think there are still occasions where you might want to hop from styling a block to editing a palette, but it's not common and probably needs some design exploration. Removing for now would be an enhancement imo.

@SaxonF
Copy link
Contributor Author

SaxonF commented Feb 24, 2023

@youknowriad @jameskoster the video here shows what editing block level palette might look like (at around 35 sec mark) and it is basically what @jameskoster proposed.

@youknowriad
Copy link
Contributor

In some global styles contexts (root context, paragraph block...) we can tweak the colors of "headings" within that context. And to do so, we choose a sub context (all headings, h1, h2,...) and then we can define either background color, or text color for this sub context. How would you represent that in a dropdown menu when you click "headings" (see the button in the following screenshot).

Note that, this needs to be a dropdown menu and not a "sub screen" like now, because we want to unify with how block inspectors render the buttons and a sub screen you navigate to can't work on the block inspector.

Screenshot 2023-03-08 at 8 55 41 AM

@youknowriad
Copy link
Contributor

@SaxonF In global styles, we have an "additional CSS" panel for blocks, how would that look like in the new unified global styles view?

@priethor priethor removed the [Status] In Progress Tracking issues with work in progress label May 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json Needs Design Feedback Needs general design feedback.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants