Eliminate Form tag

[rx]

Question: Should we continue to use the form html element anymore?

Background: You can submit grouped input in a number of ways from the POM.

1. Using a Form block around the input
2. Using another container element - Content, Dialog and Card
3. Using tagged input

Content, dialog and card behavior does not use html forms.
One of the biggest issues is that nested forms on chrome (and possibly other browsers) are collapsed in the markup, the result is that the inner form tag is discarded.
To be more consistent, and not have special case for forms, we should eliminate the form behavior and alias the form POM keyword to content.

Other notes:

• Form validation should be done at the component level and not rely on form html tag implementation.
• Default button submit behavior should be driven by the first 'raised' button in the POM.
• Focus and Tab should work across any container type.

[tlemburg]

I think this is OK, not perfect but it would work. I'm a little worried about other implications of getting rid of the form tag, e.g. screen readers, other sorts of accessibility, etc. I think it's definitely unfortunate that in a world where we'd like to have a generic "submit data to the server" that the semantic web kind of locks you into that paradigm, but there it is.

I think a more correct implementation would be if presenters web client saw a form within a form and rendered it as a div/content instead. However, I can respect the other issues forms are giving us, and having a more consistent, one-behavior one-style-of-code to do the thing is a good thing. Others are always welcome to slap on a different form implementation in a plugin.

[jadefish]

Agree with @tlemburg. Browser implementations of the form element provide a lot of utility and consistency for "free", and moving to a model where we maintain our own approximation could become hard to maintain as the HTML specification changes. Also: it is likely that any consumer of POM (e.g., the web client) will have a platform-native implementation of some sort of form element.

[jadefish]

The more I consider this and use pseudo-form elements (e.g. cards), the more I think it's not the right path forward.

• Chrome's autofill functionality looks for <form> as a boundary when determining how many fields to autofill with a composite autofill entry (such as an address). If no <form> is present for the focused element, autofill will populate every element on the page that isn't contained within a <form>. If no <form> elements exist, all elements on the page get autofilled (where possible).
• LastPass's web extension looks for elements parented by a <form> element to determine which fields to decorate/upgrade. Although this is only one example, I would guess that other web extensions behave similarly.
• Client-side validation errors ("Please fill out this field") do not appear near the invalid element if the element does not belong to a <form> (in fact, they do not appear at all).

Decorating the pseudo-form element with a role="form" attribute does not mitigate the above issues.

MDN offers a cautionary warning which I think we should honor:

Important: Use an HTML <form> element to contain your form controls, rather than the ARIA form role, unless you have a very good reason. The HTML

element is sufficient to tell assistive technologies that there is a form.

imo, opting out of expected behavior and other <form> freebies on behalf of users isn't the right move and provides a subpar experience.