[Compatibility] Figure out the form attribute for IE11 about dawn HOT 5 CLOSED

I'm curious what are the ups and downs of putting the

as the main container that wraps all form elements?

The main issue is that, if we wrap all the blocks types, we'll likely end with <form> (or a lot of unwanted element types) inside <form> because we have:

• Collapsible Tabs - which can use external page as source of content. And that page may contain a <form>
• Popup, also uses a page as source of content.
• App Blocks

So we decided to use this form attribute to link all the required fields to the product form, and creating multiple forms where needed (like product-installments being a separate form).

As the form blocks can be reordered freely, we can't even choose to have two {% for block in section.blocks %} loops in the page. So it looks like our only alternatives are wrapping EVERYTHING inside a <form>, which is an issue because of the things mentioned above, or using the form parameter :(

from dawn.

One thing to note is that this form attribute is causing some issues to third party apps, including shop installments, in which the product form doesn't receive change event because the variant dropdowns are not wrapped in the main <form action="/cart/add"> element. In my reply, I made a test and put the <form> as the main wrapper of every form elements and everything works fine.

I'm curious what are the ups and downs of putting the <form> as the main container that wraps all form elements?

from dawn.

cc. @LucasLacerdaUX

from dawn.

What we could do, though, is dispatch a change event on the form when the variant is changed. If that's what the installments app is listening for.

from dawn.

For the scope of this issue, I've assigned myself to take a look at it. I'm leaning towards using a polyfill to make it work for IE11, even though I really don't want to use a polyfill. I can't think of anything better. 🤔

If the polyfill works outright, it should be pretty low effort.

from dawn.