-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Comments
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.
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. |
Some time ago I've created this related discussion #37064 which is basically the same thing but form a technical level. |
Related: #47146
|
@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. |
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. |
@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:
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:
Define your presets/foundation then apply them to your site. |
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. |
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:
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? |
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. |
Personally, I'd prefer to avoid it entirely there and separate "styles" and "settings" entirely if that makes sense. |
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. |
@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. |
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. |
@SaxonF In global styles, we have an "additional CSS" panel for blocks, how would that look like in the new unified global styles view? |
What problem does this address?
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?
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
The text was updated successfully, but these errors were encountered: