EuiForm should render to form

[flash1293]

Currently the EuiForm component renders a div as container element. This is slightly confusing, I would have expected it to render an html <form> element, so onSubmit on EuiForm works:

<EuiForm onSubmit={sendToServer}>
   ...
   <EuiButton fill type="submit">Submit form</EuiButton>
</EuiForm>

[thompsongl]

@snide Looks like you built this to render a div back in the day. Any reason for that? Seems like form is the way to go.

[snide]

I think form makes sense and what I should have done in retrospect (I did it mostly in the assumption of people wanting to manage form tags on their own). Like the negative flex issue though it's harder to retroactively make that decision. Doing it will require everyone to change their usage of it and it would be a larger breaking change (for example, people might be using it in one component now, but then having the actual form field in a wrapper component). If we think it's worth the effort to dev happiness to make that change all through Kibana / Cloud / Swiftype...etc then it makes sense.

Otherwise it's just a quirky artifact that is odd, but mostly harmless.

I generally advise to let improper naming quirks live, but that's certainly skewed by not wanting to go through the conversion effort.

One way we could help is just by adding an additional prop that turns it into a form.

[flash1293]

Thanks for the explanation @snide - I think you are right and the benefits of this breaking change don't justify the effort.

One suggestion: The examples (e.g. https://elastic.github.io/eui/#/forms/form-layouts ) should wrap
EuiForm in a form to emphasize how it should be used.

[nomadhoc]

It took me a while to realize that EuiForm is not a real form, which is counter-intuitive. I agree that it should be a real <form> instead of <div>.

[nomadhoc]

One possible solution is to create another component, e.g. EuiHTMLForm, for people who prefer a real form without having to write wrapper. Then EuiForm can be gradually deprecated or shift to using form.

[anishagg17]

@snide should i start working on

One way we could help is just by adding an additional prop that turns it into a form.

[snide]

@anishagg17 Sure. Following convention I'd use a component prop that can take form, but defaults to div. Check EuiFlexGroup for an example.

[j-m]

What is the use case for div? Why is the default not form?
At the very least div should add the ARIA role "form"

See also #4416

[cchaos]

Yep, we understand, it's a legacy piece of code that would be a major breaking change if we changed the default. You can change it with component="form" or add the aria role.

[j-m]

Not what I wanted to hear but completely understandable, all breaking changes cost something. However, at the same time, this raises new concerns for me; I don't want import features, like accessibility, to be blocked by technical debt/cost from existing adopters. I choose EUI because it's "Accessible to everyone" so, regardless of the default element, I suggest adding the aria role as a minor bump

Just FYI, the use of form is pretty inconsistent throughout the doc demos, e.g. Form Layouts alone has an example that uses component="form", three that don't, one that uses Fragment, and two that use EuiFlexGroup (understandable for inline, but should still have a Form wrapper).

Yeah, I knew I'd fall for it a few times so one of the first things I did when I adopted EUI was create a component wrapper that used EuiFormProps and set component="form". Came across the wrapper again today during a refactor and wondered if it was still needed

[myasonik]

Thanks for feedback! It's really great to hear that folks outside of Elastic are choosing EUI because accessibility is one of it's primary goals.

Unfortunately, we're a small team and can't tackle everything. You can see a whole swath of a11y issues that we're aware of and would like to get to but haven't had the capacity to address.

We're constantly getting better though so keep these issues coming (PRs too, if you can!) and we'll keep moving forward.

[j-m]

Thank you for your candour, and for you and your team's great work!
I continue to be impressed by the EUI team's attitude and passion towards this project, and love how open you are to community feedback.

I know my comments and issues probably come across as gripes but I assure you that I'm not trying to be mean. I love EUI and want to see it get the attention it deserves. Thank you for your patience, everyone ❤