search

whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
8.19k stars 2.72k forks source link

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

Open keithamus opened 5 months ago

keithamus commented 5 months ago

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

annevk commented 5 months ago

This seems like a good idea.

cc @whatwg/forms

mfreed7 commented 4 months ago

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

josepharhar commented 4 months ago

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

keithamus commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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