Hey @pablohoneyhoney, here are my considerations (and a few questions) after a brief investigation:

Adjust styles preview box size

This can be improved as you suggest with quick adjustment directly to the Global Styles preview in the sidebar.

Adjust color swatches size

This is also a quick adjustment that can be made similarly to the previous one.

When I look at what we currently have on trunk, the size of the color swatch appears to be 30 (and not 40). There may have been recent changes, compared to when the screenshots above were taken — this is what I see as of today when loading the latest version of the Global Styles sidebar on my local machine:

I'm happy to update the size of the color swatch to 32, but I wonder if the rest of the spacing (and the font size) would also need updating? It would be useful to have a complete design spec for the Styles Preview card

Smooth the corners of the styles box

Wrapping the <StylesPreview /> component inside <CardMedia /> should definitely improve the situation (🤞 ), although there's always the chance that browsers rendering engines can introduce some sub-pixel / anti-aliasing artefacts.

Correct labels colors

Worth reviewing them all but the elements seem to have a transparency or a slight grey. If I'm not mistaken the color code used is: rgba(0, 0, 0, 0.847).

I wasn't able to find elements with such transparent color, these elements seem to be black (#000000) for me.

The original idea was to leverage the G2 dark grey rgba(30, 30, 30) or #1E1E1E as the principle dark color

I can see the #1e1e1e color being applied to all contents of "complementary area" (a part of the codebase that I never worked on before). But currently, there are a few style rules with higher specificity that are basically applying the black color to all content — one of them is this style rule from the Surface component.

I'd be reluctant to make changes directly in the source components — instead, we can look into applying style overrides specifically to the global styles sidebar in order to change the text color.

Align icons with labels

This is an adjustment that can be easily applied as a "global" adjustment to all icons — it would be more complicated if we would need to tweak the alignment on an icon-by-icon basis.

Consider removing the heading separator

As you also mentioned, the header used in the Global Styles sidebar is a shared component called ComplementaryAreaHeader that lives in a separate package (@wordpress/interface).

The ComplementaryAreaHeader component gets most of its styles (including the bottom border) by using the components-panel__header classname (instead of using the actual PanelHeader component from @wordpress/components — this by itself is a dangerous anti-pattern!).

In short, we can't remove the border styles from the "source" (i.e. the styles of the PanelHeader component).

I see two choices — both feel slightly hacky, and I don't personally know the @wordpress/interface package well enough to be certain about what's the best one:

• manually override the styles of the header (and remove the border) only in the Global Styles sidebar
• add a prop to ComplementaryArea to be able to disable the header's bottom border

Maybe @jorgefilipecosta can help here?

Review spacings between all elements

The current spacing is a result of different paddings (mostly Card and ItemGroup) and a margin of 1.5em on the separator (which again, comes from the styles applied by the "complementary area").

Adjustments can be definitely made. It would be interesting to see which of these adjustments can happen at the "source" and which need to be applied as a style override specifically for Global Styles

I'll follow up shortly with a few PRs tackling the points highlighted above.

During the 6.0 walkthrough, the prominence of switching styles was raised and I wanted to flag here since this seems to capture an overview of current refinements to the Global Styles panel:

Currently, the "Browse styles" matches the design of the "Blocks" section below it, when perhaps it should be fairly distinct. I'll leave it to you all to figure out how best to proceed but wanted to close the loop here as it seems that the above designs existed before style variations were being worked on. cc @critterverse who has been working on the animation and previews. If you'd prefer this be an additional issue, I'm happy to open one.

Of note, you can use this gist (and the instructions in the comment) to recreate having style options locally.

I'll let @pablohoneyhoney and @jasmussen digest the feedback here, including whether this should be handed in a separate issue

Apologies @ciampo mind clarifying what you mean with this – I'm not sure I understand or link it to your notes above:

including whether this should be handed in a separate issue

Regarding the rest, all of those suggestions and tweaks are already good progress and worth doing as a next iteration. We can keep this issue open for further improvement notes, or create a separate one once all is addressed or nuanced.

Currently, the "Browse styles" matches the design of the "Blocks" section below it, when perhaps it should be fairly distinct.

I agree with this @annezazu and believe I mentioned it in the context of @critterverse iterations in that area.

mind clarifying what you mean with this – I'm not sure I understand or link it to your notes above:

including whether this should be handed in a separate issue

Sure! My reasoning here is that @annezazu's feedback is still quite at a high-level (differentiate the design of the "Browse styles" and the "Blocks" sections), and so I proposed that we may move it to a separate GitHub issue, where folks can discuss and work on a design spec until it's ready to be executed and tracked separately from the initial list of tweaks already suggested in this issue.

Relatively to this issue, @mirka and I have been progressively addressing most of the feedback. The only areas that we haven't tackled yet are:

• "Consider removing the heading separator" (this is a non-trivial fix — I left some more details in this comment, including a ping to @jorgefilipecosta in case he had any suggestions)
• "Review spacings between all elements" (not trivial, since we'll need to balance changes to the core components and tweaks specific to what's called the "complementary area" and the sidebar)

Agreed there are lots of small fixes we can make that will benefit the UI as it exists today and for the foreseeable future.

One additional consideration is how global styles can evolve in the future. For example, #36667#issuecomment-1087711883 suggests moving it to the left on a dark background and shown in context of other site-wide tools such as "Navigation". That would absorb the "Templates" item as well. Would that make room for "Browse styles" to live as a normal menu item next to Color and Typography, perhaps even Blocks? Or do they still need sectioning off and/or live in the context of the style card?

Shared a few ideas for iterating on the Browse styles button in #40478 :)

One quick note worth considering. The borderless heading as designed looks great and makes the whole panel feel a bit more like a cohesive unit.

Actually removing that border might require a little extra effort, however. On very small viewports, or as soon as you click into a sub-section, the header stays fixed at the top and a scrollbar can appear — in those cases keeping the border might be useful:

The borderless look works okay with scrollbars in the following experiment, but it might work better if the border would appear contextually with a scrollbar:

Given that #36667 explores global styles on a dark background, it may not be worth exploring such a border-behavior right at this point.

it may not be worth exploring such a border-behavior right at this point.

I agree — removing the border from the heading feels still very much an idea that needs more exploration before it can be implemented (plus, it wouldn't be a trivial change, as explained before).

I am in favour of delaying the work on this potential change until it feels ready for implementation.

Hi @ciampo,

"Consider removing the heading separator" (this is a non-trivial fix — I left some more details in #38934 (comment), including a ping to @jorgefilipecosta in case he had any suggestions)

For this task, I think the solution "manually override the styles of the header (and remove the border) only in the Global Styles sidebar" is the right one. We have a class for the global styles sidebar we can use specific styles to customize that sidebar specifically because it has very specific needs.

Update:

From the original issue description, @mirka and I tackled all points except the one about removing the heading separator. I kept the original description up to date with references to all of the PRs that we merged for each point.

Regarding the heading separator, I agree with @jasmussen 's message — in short:

it may not be worth exploring such a border-behavior right at this point.

This behaviour should be implemented (ideally by someone more knowledgeable about this part of the codebase than myself) only once it's in a more polished state design-wise.

For this task, I think the solution "manually override the styles of the header (and remove the border) only in the Global Styles sidebar" is the right one. We have a class for the global styles sidebar we can use specific styles to customize that sidebar specifically because it has very specific needs.

I agree that, in case we wanted to implement this change, manually overriding the header styles only in the Global Styles sidebar would be the quickest way. At the same time, it feels like we should still try to tidy these styles up more at the root (i.e. ComplementaryArea), rather than adding one more layer of style overrides.

In the light of the above, I believe that we can close this issue:

• "Browse styles" button explorations are already tracked in Global Styles panel: iterating on the "Browse styles" button #40478
• Introduce "Browser" and surface main navigation UI #36667 explores global styles on a dark background
• We can open a new issue specifically around the removal of the Global Styles heading separator if/when we see fit

Side note: in the upcoming weeks I'm going to try to partially rewrite ComplementaryAreaHeader so that it doesn't use hardcoded classnames from the Panel component — these changes won't really be related to what is being discussed in this PR, it's mostly a refactor to avoid this anti-pattern.