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: Mayank-Tripathi32 <mayanktripathi32@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: joedolson <joedolson@git.wordpress.org>
Co-authored-by: amberhinds <alh0319@git.wordpress.org>
Co-authored-by: carolinan <poena@git.wordpress.org>

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

Failing unit tests seems irrelevant

Thanks for the PR!

Looking at #63534, it seems like the discussion is still ongoing and there is no clear direction yet.

Additionally, I think simply exposing the UI to change elements may cause another problems. From #63534 (comment):

I do think that if we add the button option without the ability to create interactivity within the interface we are creating a confusing situation for the user, since they can't create a button that has functionality.

Personally, I would suggest further discussion before moving ahead with the implementation.

cc @amberhinds @carolinan @joedolson

Personally, I would suggest further discussion before moving ahead with the implementation.

I believe it will be better than the current experience where users are using # anchors as buttons. Furthermore, it's already a pattern we've used to change element types of groups. Users haven't really complained on it and according to #63534 (comment), we should move towards exposing it as it will improve developer experience.

While I think it's good to be able to create a button, I'm dubious about the value of having a UI that inserts an element that cannot do anything unless the user is able to additionally write custom scripting.

But for advanced users and custom cases like plugin usages, I think it can absolutely be beneficial.

I'm a little concerned about whether this might cause some support burden from users inserting a button then complaining because it doesn't work. Hard to know whether that's a real problem, however.

I also want to note that this PR only address one of the three subjects raised by @amberhinds in the original issue, so this should not close that issue.

I believe it will be better than the current experience where users are using # anchors as buttons.

I agree. There are a lot of popup plugins that allow non-devs to do this, and being able to name an actual button as a trigger would be helpful to these users.

I would also love to set the ability to change the wrapper markup to unordered lists and a nav tag, but just button functionality is a step in the right direction.

My biggest question is why expose elements as WordPress defaults if you have to rely on external plugins and code to make them work properly?

FWIW, the UI that this PR is trying to achieve can be added by consumers if necessary. See https://github.com/WordPress/gutenberg/blob/HEAD/packages/block-editor/src/components/inspector-controls/README.md#inspectoradvancedcontrols

I think we should move forward with this.
Lets say I have set up some settings with ACF, that loads a JavaScript file. Using the button block instead of also creating a custom ACF block with very similar output would still save me time.

I see, let's try this UI out. Is there any room for improvement in terms of help text?

Help text for the a element:

Help text for the button element:

That help text makes sense to me.