Use unique IDs for top-level elements and any other elements that could be good testing/targeting candidates.

Anything immediately inside the body element should have a unique ID. If new elements are injected into the body and code moves around, at least the parent elements have an easier way to be recognized.

Adobe Target does not require IDs, but using IDs increases the reliability of experiences created with the experience composer. Target uses CSS selectors to modify your content when the experience is delivered. When you edit an experience, the Visual Experience Composer anchors the selector to the closest ancestor with a non-null id attribute to the HTML element being modified. It is, therefore, not advisable to use any mechanism, including JavaScript libraries, that sets or modifies HTML ID attributes. Although those IDs might be available to the Target experience composer for activity creation, if JavaScript modifies IDs, the ID that was used when the experience was created might not be available when the experience runs. If an ID is not available, the selector anchored to the ID fails.

Name CSS classes so they are easily identifiable.

When editing CSS classes in the Visual Experience Composer, it is helpful to make the classes easy to identify by using descriptive class names. This helps to ensure that you edit the right CSS classes, and your pages appear as expected.

Don’t use the !important CSS property when hiding or removing elements.

If the 1!important1 CSS property is present, changes made by target.js during delivery will be overridden by the site’s CSS rules.

Avoid using HTML tables for page layouts.

Target Standard and Premium uses JavaScript to format a page. It is difficult to modify table-based layouts with JavaScript. Also, table-based layouts might not display the same way in all browsers. For best results, use CSS to create page layouts.

Minimize the use of iFrames.

It is a good practice to minimize the use of iFrames, to simplify page and test management. The visual experience composer can apply some actions within an iFrame, but some actions, such as resizing, do not work properly. It is difficult to manage and resize pages that use multiple iFrames. As a result, testing iFrame-heavy pages can create problems.

Attempt to arrange all dynamic DOM modifications as soon after DOM ready as possible.

If your modifications fail to apply before the experience application by target.js, content delivery could be broken. This happens only when there is a DOM change in the hierarchy of a targeted element.

Use only plain text or an image tag in your anchor elements.

<a>Anchor Text</a>

OR

<a href=""> <img src=""> </img> </a>

Avoid block-level elements inside an inline element.

Block-level elements should not be used inside inline elements like anchor, span, and so on. Doing so causes inline elements to lose their height and width, so the overlay tool in Visual Experience Composer might not work as expected.

The VEC manipulates the website behind the scenes, using a proxy server that updated the links. If you add a base tag, the URLs used by the proxy server are resolved again by the browser and appear broken.

Using EDIT HTML to manipulate DOM structure can break selectors.

For example, if you have taken two actions:

  • Added a class to Element 1
  • Edited the HTML for Element 1

Each change creates a new element in the Visual Experience Composer. Because the second action modifies Element 1,if you delete Element 1, the second action no longer has anything to modify, so the change no longer works.

In other words, if you add an element with text, then in a separate action you edit that element with different text, the code editor shows both actions as separate elements. When you edited the element, you created a new element that modifies the original one you created, containing the edited text. If you then delete the original element, the edited text won’t be able to find the element that was edited, and will not display. The second element remains in the list of elements, but it does not affect the page because the element it changes no longer exists.

See Element Selectors Used in the Visual Experience Composer .

Use <b> and <i> tags when styling text elements with the rich-text editor.

  • For bold text, use <b> rather than <strong>.
  • For italic text, use <i> rather than <em>.

<strong> and <em> tags might cause unexpected results.

Be careful when removing form fields.

Certain form fields might be mandatory for submission. Removing those form fields could impact submissions.

Do not include mboxCreate inside scripts.

Because mboxCreate uses document.write, it is not recommended to include mboxCreate in scripts. Instead, use mboxDefine and mboxUpdate for the same purpose.

Don’t update an html snippet using Target Standard if it requires JavaScript code for its initialization.

When an action (Edit HTML) is performed on page components (such Sliders, Carousels and so on), delivery might appear broken. The Visual Experience Composer performs the action after the page component has been instantiated by JavaScript.

However, when the content of the page is delivered to visitors, the action is applied before instantiation of the component. Because of this, this component’s functionality may or may not break at the time of delivery. Functionality depends on the nature of the script used on his page to define the component.

If you test for delivery and it works the first time, it is not guaranteed that it will continue working. There may (or may not) be a race condition.

  • If there is a race condition, delivery will work intermittently.
  • If there is no race condition, it will always work.

Test your page multiple times to make sure delivery works as expected.

When you use the Enhanced Experience Composer, the website is manipulated behind the scenes by a proxy server that updates all link urls to make them work in the proxy. If you add a base tag, all these URLs are resolved by the browser so they appear broken.