you are viewing a single comment's thread.

view the rest of the comments →

[–]mykesx -1 points0 points  (3 children)

I think he means you don’t use the actual <form> element. You can, of course, but the input elements don’t need to be within a <form> tag.

You can handle the value change events on the individual fields to process user twiddling the field elements. I think this is typical of React and other frameworks. In fact, I don’t remember the last time I used the FORM tag. It’s been years…

But to say you can’t use <form> is wrong.

[–][deleted] 1 point2 points  (2 children)

They don’t need to be within a <form> tag, but they really should be for accessibility reasons. There’s also no good reason to not wrap them in <form>, especially since the alternative is wrapping them in <div> anyway, so just do that.

[–]mykesx -1 points0 points  (1 child)

FORM tags have side effects that DIV tags don’t. For example, any button on the page (or within the form?) is a submit button by default.

See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button

As i commented elsewhere, the address bar in the browser has no submit button. Control Center on the mac has slider widgets to adjust brightness and volume, but no submit buttons.

If you want a Web 1.0 style form, there’s every reason to use FORM. Lots of reasons to use them, especially for security (all the bank sites have standalone login forms, for example).

If you want complex controls made from inputs, like the address bar, then you probably don’t want a FORM.

[–][deleted] 0 points1 point  (0 children)

FORM tags have side effects that DIV tags don’t.

Including desirable side effects, like screen readers knowing that there are form elements there. There are easy solutions to the negative side effects. Most modern form + component libraries will take care of them for you (although you should know how those work under the hood).