-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Investigate making the invalid state of <button type>
_not_ submit
#10462
Comments
This seems like a good idea. cc @whatwg/forms |
Aside from compat concerns (for which I have no data), this sounds like a good idea to me. |
Would |
I should probably know this but does the spec distinguish the attribute not being present vs it being an empty string? Both resolve to |
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. |
Ok, I'll add separate usecounters for invalid values and empty strings |
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 <[email protected]> Reviewed-by: Keith Cirkel <[email protected]> Cr-Commit-Position: refs/heads/main@{#1326892}
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 totype=button
, which would allow future proposals to extend thetype
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
The text was updated successfully, but these errors were encountered: