Styles panel content shift from "Browse styles" link

[ironprogrammer]

Description

In a block theme, after opening the Styles panel, there is a ~1 second delay before the "Browse styles" link appears, which shifts the Typography/Colors/Layout links down by 60+ pixels. This delay often (for me) results in an unintentional click on the newly materialized "Browse styles" link, instead of e.g. Typography.

I would expect the "Browse styles" link to appear more quickly (it's the only link in this panel with a delay), or if the delay is required for async processing, for there to be a placeholder or padding to prevent the resulting content shift.

Workaround: Slow down with the pointer when using this panel 😂 However, this is the only place in the UI that I encounter this regularly, and it's just slow enough of a delay to be frustrating.

Step-by-step reproduction instructions

1. With a block theme active, open Appearance > Editor.
2. Click in the editor area to activate it, then click the Styles icon to display its panel.
3. In under ~1 second, click the Typography link.
4. Observe that at a normal pointer movement speed, the click could activate "Browse styles" instead.

Screenshots, screen recording, code snippet

There is enough time to open Styles, wiggle around Typography, and then click -- which by this time Typography has shifted down and an unintended screen is loaded instead. Getting back to the Styles panel can take time due to latency in loading the style variations.

Environment info

• Hardware: MacBook Pro Apple M1 Pro
• OS: macOS 14.3
• Browser: Safari 17.3
• Server: nginx/1.25.3
• PHP: 8.3.2
• WordPress: 6.5-alpha-56966-src
• Theme: twentytwentyfour v1.0
• Active Plugins:
  • gutenberg v17.6.0

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[ironprogrammer]

Since updating GB trunk today (last commit 38fbc7f986df16545d31e0f21344cb1b22c42f06), this experience has improved greatly, though not completely mitigated.

In testing today, the display of "Browse styles" has ranged from "instant" to a barely perceivable delay. However, it's fast enough that mis-clicking is much harder. I've leave this open in case there are others who might share their experience.

Here is a demonstration that the appearance of the link is much faster:

[aaronrobertshaw]

if the delay is required for async processing, for there to be a placeholder or padding to prevent the resulting content shift

The UI component is rendered once there are theme style variations available within the core store. Those theme style variations are requested asynchronously via the REST API resulting in the delay and content shift seen.

I'm not sure we can get away with a placeholder as it could create dead space for themes that have no variations. Perhaps the presence of theme style variations is something that could be added to the editor settings sooner to avoid having to rely on the async check.

[ironprogrammer]

Thanks for taking a look at this, @aaronrobertshaw. Loading earlier to avoid the shift could work.

Another thought might be to integrate the styles options into the existing style sample div. This is purely decorative (non-interactive) at this time, correct? Because this div always displays with the default style (even when no variations are available), when additional styles become available, it could perhaps add or become the link to browse styles?

After the styles load, it could animate to move the "Aa" content upward, and add the browse link. OR, maybe better, just make this whole div the link when additional styles are available (presuming some added indicator for users to click/peruse)? It could become the style variation "button".

[aaronrobertshaw]

Another thought might be to integrate the styles options into the existing style sample div.

Could be worth exploring 👍

I've added the needs design label to the issue to get some broader input before diving in too deep.