Bug report: Two fundamental bugs in Forms Designer

[Anonymous]

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).

Annoying Bug:

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?

A potential defect I have observed but haven't tested yet: It forces the same form to always have the same ID, apparently. If true, that will also result in both invalid HTML and undefined behavior should you have a single page with a tabbed interface including the same form within two or more tabs. (Particular use case of ours that brought this possibility to my attention is the case of having two sales locations, both served by the same contact form but appearing on different tabs in a contact page that also includes other, non-sales-and-marketing departments with different forms. I've no idea what will happen, but I know if I simply copy the insertion javascript I'll have the duplicate ID issue rise up. I haven't tried to create a workaround yet -- that's why I only claimed two bugs in the subject; count this as a suspected but unverified third one. I may be back with this one as a verified bug if I can't get past it.)

[Anonymous]

And yes, upon verification, the third bug is real. There's a javascript workaround for it ( the one I built off of was http://codepen.io/figureone/pen/ENxBNd) but it brings its own baggage. The process for the js workaround is, in a nutshell:

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.

The philosophical issue this causes is it now tightly couples all the code for all the forms together. 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 practical manifestation of this comes when there is a browser incompatibility in the callback method that causes a javascript error (most commonly that will be an object or a method not being supported in a particular JS engine). The error will stop the entire chain, so that while the first form will load, and only be without benefit of the post-processing that occurs after the error, any further copies of the form will not even be displayed.

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.

[SanfordWhiteman]

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.

[Anonymous]

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.

[SanfordWhiteman]

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.

[Anonymous]

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.

And yes, many, maybe most, bugs in any software can be worked around. ("It crashes when I do this." "Then don't do that.") I could fix every one of these mentioned issues in a javascript on my end. And every extra step taken around a bug creates one more opportunity for another problem to creep in from another direction. It's not guaranteed failure, people do get high scores in games of whack-a-mole. But again, that's not the point. The point is the bugs exist, should be addressed, but can't be addressed without being reported.