Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

<button> shouldn't have activation behavior when it is not in a form #1567

Open
smaug---- opened this issue Jul 18, 2016 · 7 comments
Open
Labels

Comments

@smaug----
Copy link

data:text/html,<a href="data:text/html,link followed"><button>click me</button></a> follows the link in Gecko and Blink.

Spec says in https://html.spec.whatwg.org/multipage/interaction.html#nearest-activatable-element
"If target has a defined activation behaviour, then return target and abort these steps."

And button has activation behavior
https://html.spec.whatwg.org/multipage/forms.html#the-button-element:activation-behaviour
Even for state Button it has it, even though the activation behavior is to do nothing.

@smaug----
Copy link
Author

Looks like data:text/html,<a href="data:text/html,link followed"><form><button type=button>click me</button></form></a> follows the link too. So type=button shouldn't ever have action behavior defined, and type=submit and type=reset depend on whether the button is in form.

Don't know about type=menu. Does any engine even support it?

@domenic
Copy link
Member

domenic commented Jul 18, 2016

type=menu is tracked in #237.

Buttons in the button state already have an activation behavior of "Do nothing". Is the bug report here to be more explicit that "Do nothing" means "has no activation behavior" and thus fails to trigger the "If target has a defined activation behavior" clause?

@smaug----
Copy link
Author

It is hard to parse "Do nothing" as "does not have activation behavior" (since I can imagine cases when there is some valid activation behavior and it could be 'do nothing').
So yes, type=button always and if my testing is right type=submit and type=reset when they aren't in a form should not have activation behavior at all.

@domenic
Copy link
Member

domenic commented Jul 18, 2016

That makes sense. I am just imagining the intent was for it to be "does not have activation behavior" since that gives reasonable results, but it definitely could be clearer about this.

@domenic domenic added clarification Standard could be clearer topic: forms labels Jul 18, 2016
@smaug----
Copy link
Author

#1568 is related issue.

@zcorpan
Copy link
Member

zcorpan commented Jan 2, 2024

Testing with

data:text/html,<a href="javascript:alert('link followed');"><form onsubmit="alert('form submitted'); return false;"><button type=button onclick="this.type = 'submit';">click me</button></form></a>

now the form is submitted in Safari/Chrome/Firefox.

But without a form the link is followed:

data:text/html,<a href="javascript:alert('link followed');"><button type=button onclick="this.type = 'submit';">click me</button></a>

@annevk
Copy link
Member

annevk commented Jan 9, 2024

I would suggest we fix this as follows:

  • Make "activation behavior" and its legacy counterparts null by default.
  • Add "has activation behavior" which is an algorithm that returns true when "activation behavior" is non-null and can be overridden with a custom implementation.
  • Make everything that is conditional upon activation behavior use "has activation behavior" as the condition.
  • Give "button" its own "has activation behavior" algorithm that takes form into account. "input" might need one too?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

4 participants