Allow click events within dropdown

[719media]

I have dropdowns that also have links inside them (the links changed based on what is selected inside the dropdown)
This allows links to be clickable within a dropdown toggle to avoid problems like this:

https://jsfiddle.net/jr3eb15g/

I'm not sure why you'd want to avoid the behavior of having links not work inside of the dropdowns?

closes #34400

[719media]

Closing pending further testing

[719media]

I'm not sure why the toggle elements have "preventDefault()" on them. No tests are using such behavior. Is there a clarifying reason? From my viewpoint, it just prevents dropdown toggles from having additional functionality (e.g. inside of the dropdown)

[alpadev]

Using <a/> elements within <button/> elements is invalid markup. (https://html.spec.whatwg.org/multipage/form-elements.html#the-button-element)

You can use a split dropdown for this like so https://jsfiddle.net/wguzqj8L/

[alpadev]

@XhmikosR should we close this as won't fix or do we want to risk undesirable side effects like changing the url hash when using <a/> elements as the dropdown toggle?
Another problem that comes into my mind. If people use it within a <form/> and forgot to add the type attribute on the <button/>, without preventDefault the dropdown toggle may submit their form, so this might be some BC.

[719media]

@alpadev

1. Agreed on invalid markup to have <a> inside <button>, but you can also have <a data-bs-toggle="dropdown">Foo <a href="/another-page">Bar</a></a> or even <div data-bs-toggle="dropdown">Foo <a href="/another-page">Bar</a></div>, which is valid markup.

2. I had the same thought in regards to forgetting type="button" when I was trying to come up with reasons why preventDefault() would even be necessary, but I thought that seemed like a silly reason to have preventDefault() given the functionality you are preventing. IMO, you're covering bad practice at the expense of flexibility. Additionally, the <a> element would only have an affect on the URL hash if someone actually had <a href="#" data-bs-toggle="dropdown">, which seems, well, like bad HTML :).

3. The split dropdown visually looks different, and doesn't work when the selected option has multiple hrefs (e.g. Order ABCD-EFGH | bob@email.com with two href, one to an order page, and one to a customer page).

Perhaps another option is controlling this with a new parameter data-bs-prevent-click default true? Ya, I already hate this idea, and I'm sure you will too. Just trying to come up with a method to allow this component to actually be useful to me...

I still think that the preventDefault() is unnecessary as, at best, it just fixes bad HTML which can just be rewritten to valid HTML, but at the expense of flexibility.

Thanks for taking the time to provide feedback.

[719media]

Using your idea of split button, I made an option with multiple href, and still maintain "showing" the dropdown when clicking on the main input area, which means I was incorrect on my third assumption above:

https://jsfiddle.net/jwh02qd3/

Looks ugly, but just going for proof of functionality, and the visuals can be cleaned up. That was a good idea, thanks.

https://jsfiddle.net/bphsj5ar/ uses reference="parent" to get the positioning right.

[alpadev]

About 1. - Sorry to say this, but nested <a/> are invalid too..

About 2. - Using <a/> for a the dropdown toggle is mentioned in the docs, so I assume that's a valid use case and could mess with SPA routing. For example when the url fragment is altered, because of the absence of preventDefault. Not using the type attribute properly shouldn't be our concern, I agree on that. But like I said, if we're going to remove preventDefault things may break, while we covered this before. And we have to take care of breaking changes, IMO.

I can't really argue about why or how preventDefault ended up there, as this was already done a long time ago. My guess is to make sure that there would be no side effects when interacting with the toggle, as the sole intended behaviour is to toggle the dropdown menu. I guess one of them is redundant, because both are used for the click on the toggle. One thing that preventDefault also does, is to prevent the selection of text when the toggle is clicked multiple times but I assume that wasn't the reason to add it.

About the data attribute, I think that could be some realistic option to disable the preventing behaviour in case it turns out to be a problem. It's indeed a bit awkward but to handle edge cases, maybe we should consider this, as this could be done without breaking things, while allowing more flexibility.