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.

Sign up for GitHub

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

Jump to bottom

Investigate making the invalid state of <button type> _not_ submit #10462

Open
keithamus opened this issue Jul 4, 2024 · 6 comments
Open

Investigate making the invalid state of <button type> _not_ submit #10462

keithamus opened this issue Jul 4, 2024 · 6 comments
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest topic: forms

Comments

@keithamus
Copy link
Contributor

keithamus commented Jul 4, 2024 •
edited
Loading

What problem are you trying to solve?

A <button type=invalid> today falls back to the submit behaviour. It would be useful to explore the possibility of making this fall back to type=button, which would allow future proposals to extend the type feature without ramifications.

What solutions exist today?

N/A

How would you solve it?

See how many type=invalid variants exist in the wild, assessing the compat risk.

Anything else?

This was discussed in the WHATNOT meeting
@keithamus keithamus added addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest labels Jul 4, 2024
@keithamus keithamus mentioned this issue Jul 4, 2024
Open
@annevk
Copy link
Member

annevk commented Jul 5, 2024

This seems like a good idea.

cc @whatwg/forms

@mfreed7
Copy link
Contributor

mfreed7 commented Jul 10, 2024

Aside from compat concerns (for which I have no data), this sounds like a good idea to me.

@keithamus keithamus mentioned this issue Jul 11, 2024
Open
@josepharhar
Copy link
Contributor

Would <button type=""> still be considered type=submit? Assuming yes, here is a usecounter: https://chromium-review.googlesource.com/c/chromium/src/+/5698215

@keithamus
Copy link
Contributor Author

I should probably know this but does the spec distinguish the attribute not being present vs it being an empty string? Both resolve to missing value for enumerated attributes, right? Either way type="" resolving to type="submit" seems fine to me.

@annevk
Copy link
Member

annevk commented Jul 12, 2024

Yes it does distinguish between them. An attribute whose value is the empty string is present. But we can make certain invalid values map to the Submit Button state as needed for compatibility, including the empty string.

@josepharhar
Copy link
Contributor

Ok, I'll add separate usecounters for invalid values and empty strings

aarongable pushed a commit to chromium/chromium that referenced this issue Jul 12, 2024
@josepharhar
Add UseCounter for button type attribute
47edcc8 
There is a standards discussion about changing the behavior for buttons
with invalid type attributes which needs compat data:
whatwg/html#10462

Change-Id: Ifb11a3a5db4365f22c872ac1b301628f221ac9db
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5698215
Commit-Queue: Joey Arhar <jarhar@chromium.org>
Reviewed-by: Keith Cirkel <chromium@keithcirkel.co.uk>
Cr-Commit-Position: refs/heads/main@{#1326892}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest topic: forms
Milestone
No milestone
Development

No branches or pull requests
5 participants
@keithamus @annevk @josepharhar @mfreed7 and others