The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: getdave <get_dave@git.wordpress.org>
Co-authored-by: jeryj <jeryj@git.wordpress.org>
Co-authored-by: mikachan <mikachan@git.wordpress.org>
Co-authored-by: MaggieCabrera <onemaggie@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Size Change: +26 B (0%)

Total Size: 2.58 MB

_{compressed-size-action}

This is better for me. I wonder if we have similar patterns in other places that we can align on.

This is better for me. I wonder if we have similar patterns in other places that we can align on.

Yes I was wondering about that. I looked in Storybook but didn't see anything in DataForms or anywhere that had a similar UI/UX.

I wonder if @jasmussen has come across anything or has any better ideas?

Flaky tests detected in 4c68f67.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/20162835667
📝 Reported issues:

• [Flaky Test] should open and edit templates correctly when active_templates experiment is disabled #73743 in /test/e2e/specs/site-editor/template-id-format.spec.js

We do:

I've no strong opinion on what button style it should be, just that it should ideally be the same, one or other direction. I'm leaning towards tertiary, but if @jameskoster has the capacity to chime in, he'd know with certainty.

Ok this is nice inspiration. I'm glad I asked!

I've no strong opinion on what button style it should be, just that it should ideally be the same, one or other direction.

So we shoudl follow the Custom implementation? It feels like it will need adapting because our selection and select_ed_ UIs are the same. I also think we should have

• Edit
• Create/New

...possibly communicated with the help of icons.

I like that it's a clear action rather than being hidden behind another menu.

I'm very keen to avoid the pattern of hiding critical UI elements. As you say it needs to be clear, obvious and always present.

I think what I'm saying is that design wise, there's an existing pattern, but if the existing pattern is poorly implemented, we can improve it here, but also ideally follow up and improve the existing implementation. Is that fair?

💯 This is an opportunity to

• address the immediate problem here
• improve wider patterns where applicable

It's just my 2c but I think it might make more sense to group the button with the input rather than the label. That would also create a more sensible keyboard flow. Though I acknowledge it's not quite as neat.

Since the action is navigational ideally I suppose we'd use a link (still styled to look like a button if desired).

If we're unable to use an actual link, then the link button variant would indeed be consistent with other UIs, but I don't like to recommend it because it's a bit of an a11y anti-pattern in most cases.

Engineering issue (designers can ignore): Attempting to implement this I got to the above. The problem is that I'm having to artificially add the Edit button outside the form control component which means that the help text doesn't span the full width.

I tried the suffix prop of SelectControl but that replaces the select control dropdown which is not what we want.

I think we should offer greater control over these form components by being able to pass custom Children.

@jasmussen noticed a "blink" of the admin when Edit is clicked. Something may be weird. We should check.

Steps to reproduce the "blink":

• Enable the experiment
• Create an overlay
• Edit a navigation block
• Save, reload the page
• Click the "Edit" button on the navigation block overlay

Crucially, you have to reload the page between applying and clicking edit on the overlay button, so there's probably some caching going on. Note also that this was inserting a navigation block in the post editor (which is already a rarity), not the site editor, that may play a role too.

@getdave I'd rather accept that the help text doesn't span than hack the component If the UI component is not meant to offer this UI.

I've discussed this away from Github with @mirka and the proposed design isn't compatible with our current forms components.

To implement the proposed would require rebuilding SelectControl using BaseControl and other lower level components. This is possible but has a lot of potential edge cases and introduces another piece of custom UI code to be maintained which is something I'd prefer to avoid.

It's not simple to modify the existing components with new extensions points so we may need to wait on the next iteration of form components to provide greater flexibility. @mirka may have more information on that.

I propose (as per @youknowriad's comment) that we merge this PR with the compromise layout (help text not wrapping) and then circle back later (pre release) to implement the fully refined design.

I've updated this:

• implement "compromise" version of new UI
• updated tests
• brought in fix from f4d87b4

Let's get these conflicts resolved and cleanup the final points that @jeryj suggested. We should bring this in.

I rebased with trunk and I'm not sure this design works well with the + create new template button. The create new template button seems very easy to get overlooked IMO:

I rebased with trunk....

Thank you for all the work on that rebase 👏

I'm not sure this design works well with the + create new template button. The create new template button seems very easy to get overlooked IMO:

I tend to agree. The current design could do with being refined. That said, this is behind an experiment so I'm in favour of merging and iterating on the Design. This will allow us to:

• ship the code level functionality for creating
• work more easily in other branches

I don't want to diminish the concern or loose sight of the need to refine this but I think that can come as part of feedback with the Gutenberg Design group.