Is it okay to use javascript in rich text fields in forms?

[Eben_Shapiro]

I tried it out and it looks like it's possible. Is there any reason I shouldn't do this?

[Anonymous]

Hi Eben

If your works well, there is not an issue. Only thing I have seen with more java script is, performance issues. Avoid having more code on forms, it may cause form to be loaded slowly also slow performance during data saving (submit click). Small amount of code should not have any issues.

[SanfordWhiteman]

Avoid having more code on forms, it may cause form to be loaded slowly

No, it won't.  Any script that affects form behavior must be executed before the form is used, anyway.

also slow performance during data saving (submit click)

No.

[SanfordWhiteman · Accepted solution]

There is no inherent problem with storing JS behaviors on the form.  But realize the following:

1. By definition, these behaviors are tightly coupled to this form, reducing reusability.  Depending on how you distribute responsibilities, this may be good or bad. (I tend to think bad but YMMV.) Using the RT area to inject a remote .js file is more maintainable.
2. You cannot prevent people with Form Editor access from deleting your code -- and, worse yet, it will look like an empty RT area.  It's not usually desirable to leave code vulnerable, but if you're the only user with access, it's fine.
3. If you add Visibility Rules, your code will run every time the RT area is rendered.  This can be really bad, though it can be avoided by setting a flag in a parent scope.
4. If you enable Known Lead HTML, the code in the RT area will not run for known leads. This may or may not matter depending on how you're enhancing the form; populating hidden fields, for example, is something you're likely going to want to do whether or not the lead is known.

Overall I've seen little reason to do this as opposed to serving forms-enhancing code separately, but you may have a niche case where it's useful.

[Eben_Shapiro]

Hi Sanford,

Thank you for the detailed information. I was tempted to use it for a form that's hosted by a partner so I don't have to reach out to them to add some javascript to populate a hidden field. But the form rarely gets changed, so I'm thinking I'll just put out a request to them to add the javascript. And if I want the ability to add javascript myself a better solution might be to ask them to include a script tag pointing to a location that I have access to.

Thanks again,

Eben

[SanfordWhiteman]

I think telling them to add something from the start like:

     <script type="text/javascript" src="//your.example.com/forms/behaviors.js"></script>

is a good idea.

Then you can start it with just a commented line and add stuff later:

     /* MktoForms2.whenReady() */

The more I think about this, as long as you duplicate the remote script include in both the RT area and the KL HTML, it might be quite convenient.

[SanfordWhiteman]

Another point which could be pro or con, depending on your goals: if you store JS behaviors on the form, the form must be approved in order for those behaviors to take effect, and when using Marketo LPs that means the hosting LP must also be reapproved.  In contrast, if JS is stored on the LP itself (either Marketo or non-Marketo) then only that hosting LP needs to be pushed to production; if JS behaviors are stored in a separate file, only that file needs to be updated.

And -- maybe this is obvious -- if you store JS on the form, you make showing your code to others for troubleshooting more difficult.  All of my forms demos show the code right in the main document so you can see what's going on.