Thanks Josh Hill. This is an area I haven't pushed too much because the API doesn't let you hook the native validation logic. You can replace the native validation logic easily, but if you want to use the rules as entered in the Form Editor yet have full control over where the error messages are injected into the DOM, it's tough.
As an example, the error message and wrapper HTML can look like this:
<div class="mktoError">
<div class="mktoErrorArrowWrap">
<div class="mktoErrorArrow"></div>
</div>
<div class="mktoErrorMsg">Must be valid email. <span class="mktoErrorDetail">example@yourdomain.com</span></div>
</div>
Now, the widget itself is easy to customize with !important. The problem is it'll still be injected after (i.e. next sibling) the corresponding INPUT. As a result, there's only so much magic you can put into the layout if you keep the native DOM elements. Tomoe Morimoto's example suggests the error message is just before the INPUT, inside a wrapper that encloses both elements. While you can simulate this arrangement to some degree with absolute positioning, it'll end up driving you crazy, and I say this as someone who usually likes crazy. For this objective I would recommend turning off the native validation (don't set any fields required within Form Editor) and using a custom onValidate listener instead (check if form.getValues().Company !== '' ).
With some extreme JS trickery it would be possible to use Form Editor-managed rules with custom styles, but unless a client insisted on this tight integration, we'd (re)build the validation rules and error messages both in custom code.
.png)