As I was exercising the forms designer, ran across two fundamental bugs in its output, one of which is bad enough, but the other results in invalid HTML markup being emitted, which means there's no guarantee it will actually work in any particular current or future browser. Right now it works simply because of Postel's Law. Spec changes could break it, and there's no guarantee future User Agent developers will support it, because it's never been supported in a spec. (Even the HTML4 spec prohibited it; the fact it works the way it does is merely an accident based on ease of implementation.)
Invalid HTML bug:
The forms designer locates the form inside a span element, and also inside a noscript element. Both locations are forbidden to a form according to the HTML 5 specification. The form element is type 'Flow Content', the span element is to contain only 'Phrasing Content' (and it's also invalid inside the noscript element, since the noscript element is located within a span, and the content type of noscript is 'Transparent,' meaning it takes on the content type of its parent).
The other bug is that it refuses to allow a submit button to be placed inside a fieldset, something which is both explicitly allowed by the HTML 5 spec (a submit button is merely a subclass of an input field or a button element, depending upon markup, and both are allowed within a fieldset) and extremely useful for setting a form apart from normal page content, both visually and for assistive technology, due to the legend element. This second bug can be compensated for visually with some creative CSS, but it loses its association with the form and the fields within it. Might be able to workaround it for assistive technologies with ARIA roles, but hey, that's right, you're also not allowed to assign ARIA roles to form elements in the forms designer, are you?
1) Add the id to the first form you want to load.
2) Call the Forms 2.0 loader, with a callback method added.
3) The callback method then clears the form id, handles any post-processing required, then adds the id to the next form to be loaded, and calls the loader with itself in the callback.
Even without this issue (and the potential for it can be looked for and limited with extensive browser testing to locate what other workarounds will be needed) that's still way too much work to go through for an ability that really required little more than the addition of a another argument to the forms loader in the first place (an argument that could have defaulted to the standard 'mktoForm_xxxx' if omitted, thereby causing no extra work at all for the folks not requiring this ability). Still, the existence of the workaround does make it a less severe bug than it might have been, dropping it down from blocking/frustrating to being merely annoying.
The single callback method needs to know all of the forms and the post processing details for each, if they happen to be different.
The whenReady chain only couples the form loads and has nothing to do with other forms behaviors. Those can be added separately to every form by ID.
Meaning the whenReady chain, before loading the next form, should trigger a custom, form-specific, event to which a listener is attached that will handle the rest of what we want to do with the form (such as removing the styles marketo embeds in the form it just loaded)? I'm afraid I don't see that as escaping the central conclusion (found at the end of the next paragraph, which begins "Even without this issue...") -- it's still more work than it should be.
Don't take this as saying your workaorund isn't any good. I quoted it because I thought it was the best idea I'd seen on it, and I've even built its central idea into some other code I'm using. But the ingenuity of a workaround doesn't make what it's working around anything other than a bug. It merely affects the severity level, not the nature of the beast.
I'm not interested in raking the library over the coals. I'm interested in bringing in leads and helping members of the Community do the same.
Chill out. My opinion on the forms system is about the design decisions that went into it, and therefore inherently subjective and not a part of this. I'd have filed the reports even if I loved the software. Bugs are about objective failures of software to perform up to standards, and are typically unintentional on the part of the developer. Unless you're proposing that deciding to emit HTML markup that doesn't comply with any known HTML specification is a decision that Marketo consciously made, rather than something that was simply overlooked and slipped through testing unobserved (which is my expectation of the circumstances behind it) I don't see what your issue is.
I was merely doing what I said in the subject, reporting bugs. No one, no matter how good, sees everything. All shipping software of more than trivial complexity has bugs, and bug reports are the way their number gets reduced.