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

For the button element, make 'button' the default value for the type attribute (instead of 'submit') #9848

Closed
ni11c opened this issue Oct 11, 2023 · 5 comments

Comments

@ni11c
Copy link

ni11c commented Oct 11, 2023

What is the issue with the HTML Standard?

It seems that many developers find it weird that the default behaviour of a element is to submit the form when no type is specified. See this SO question as an illustration. Why not make the missing value default of the type attribute be 'button' instead of 'submit' as I feel it is more logical with the very nature of the button element ?

Now I appreciate that there is a backwards compatibility issue here, as it would break many websites which rely on the default submit behaviour, but medium to long term this makes more sense and is more consistent.

Sorry if this is a duplicate, I could not find any other one stating the same thing.

@annevk
Copy link
Member

annevk commented Oct 11, 2023

Unfortunately, I'm not sure you appreciate the amount of breakage end users would have to endure sufficiently. This is not a change we can make.

@annevk annevk closed this as not planned Won't fix, can't repro, duplicate, stale Oct 11, 2023
@dariok
Copy link

dariok commented Nov 3, 2023

Sorry to chime in on a closed topic, but I, too, have stumbled across this because I was looking for discussions about this (and I really don’t want to set type="button" on hundreds of buttons that are nowhere near a form). I think, it is still worth discussing this issue.
It is true that quite a lot of pages might break and that this will indeed cause trouble – and I agree that this means that changes here should not be taken lightly.

But then there are, in my opinion, a few other points to consider:

  • while I do not have figures, I am quite sure that the vast majority of buttons out there are not “submit” buttons in forms
  • the standard behaviour of “submit” only makes sense when the button is used in a form context (i.e. is placed within a form or associated with it) in the first place – which is not mandatory.

I think that having a default behaviour that is dependant on something that is not mandatory (here: that the default makes only sense for a form) is bound to surprise people and lead to other problems; it feels like bad design for a standard. The fact that there are quite a few blog posts and question (e.g. the one from SO posted above) shows that the default is rather surprising in and of itself.

The question, of course, is what could be done about this. As said, I appreciate the fact that actually globally changing the default behaviour as implemented in browsers will lead to a lot of problems.
But there could be 2 possible solutions to this:

  1. as the default of “submit” only makes sense when associated with a form, the standard could state that the default value is “submit” when associated with a form (and perhaps to make it illegal to have in a form more than one button with this behaviour, either through explicit assignment or through the default), and “button” otherwise;
  2. a new element could be introduced that is basically a clone of <button type="button"> which can be used in all contexts.

Personally, I think that while solution 2 would be cleaner – in that different default behaviours, too, fell like bad design –, solution 1 might actually be the way to go. Just guessing, but for > 99% of web pages out there, that’s actually what happens (and is expected to happen) anyway. That would be minimum impact while still making the standard clearer and easing confusion.
Of course, validators and linters would have to be adapted but that should be manageable ;)

@annevk
Copy link
Member

annevk commented Nov 3, 2023

Forms can have multiple submit buttons, that's quite normal. And I'm not sure what you mean to suggest that outside of a form it would not be a submit button. It seems that would still require implementation changes for the type getter and such. I don't think that's workable.

@ni11c
Copy link
Author

ni11c commented Nov 6, 2023

@dariok Yes there are definitely options available to mitigate the effects of a widespread breaking change. Thanks for your interesting suggestions. At the end of the day that is "just a breaking change", and one that is easy enough to fix. I mean since when does a bad design need to stay there forever because it breaks stuff ? That reminds me of microsoft back in the nineties not wanting to fix IE because it would "break the web". There is ample discussion on the internet that proves the default behaviour is not well known and used erroneously by many.
And @annevk thanks for closing the issue with a one liner no more than 3 hours after it was filed. Believe me I do appreciate the amount of breakage a change of default behaviour would incur. Please don't make assumptions about people you don't know. This make me dubious about the kind of governance that's going on at whatwg.

@dariok
Copy link

dariok commented Nov 9, 2023

@annevk Very well, forms may have multiple submit buttons – but that was just a side node.

And I'm not sure what you mean to suggest that outside of a form it would not be a submit button

Just what I say: when not in a form, the default for the type would not be "submit" but "button".

It seems that would still require implementation changes for the type getter and such. I don't think that's workable.

Hm...

function getTypeOfButton ( $button ) {
  if ( $button/@type ) then return $button/@type
  else if ( $button/ancestor::html:form ) then return "submit"
  else return "button"
}

Should not be too complicated.

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

No branches or pull requests

3 participants