rx / presenters

A ruby presentation DSL for describing Material Design user interfaces.
MIT License
9 stars 3 forks source link

Eliminate Form tag #129

Open rx opened 5 years ago

rx commented 5 years ago

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:

tlemburg commented 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.

jadefish commented 5 years ago

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 commented 5 years ago

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

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.