Open rx opened 5 years ago
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.
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.
The more I consider this and use pseudo-form elements (e.g. cards), the more I think it's not the right path forward.
<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).<form>
element to determine which fields to decorate/upgrade. Although this is only one example, I would guess that other web extensions behave similarly.<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
imo, opting out of expected behavior and other <form>
freebies on behalf of users isn't the right move and provides a subpar experience.
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: