Snippet Fields

Snippet Fields

Snippets may be static html (such as a branded header) but can also have parts that can be edited by a user.

This is achieved by defining fields for a snippet. The values for a snippet are then set by the user via the email editor. When an email is saved, these values are then combined with the snippet template to create the resulting HTML.

Fields can be of different types. The user will set the data for a field differently, depending on the field type. HTML fields have their values set via an inline HTML editor. Image fields have their values set via an image picker etc.

Some of the fields have example code built into the snippet management screen.

HTML Field

<div data-intilery-text="new field">
{{#notNull fieldValues.new field}}
    {{{fieldValues.new field}}}
{{else}}
    Text goes here
{{/notNull}}
</div>

HTML fields are editable inline via the email editor. Because of this, it's best that their top level element is an html element that supports inline editing. It's best to use  <h> <p> or <div> tags. We recommend using <div> tags as they will give you more visual options and do not have inbuilt margins or padding.

You can see  data-intilery-text="new field" has been included around the field container. This data attribute tells the email editor that the enclosed html is editable and that it's value is stored in a field called "new field".

{{ }} and {{{ }}} tags are used by the templating framework (handlebars.js). {{{ is the same as {{ but can display pure html, whereas {{ will escape tags and display them as plain text.

If in doubt, you can read more information here:  http://www.handlebars.js .

{{#notNull fieldValues.new field}} is a handlebars tag that works like an "if" statement. If "new field" has a value then use it. Otherwise, a default piece of text can be used as a placeholder.

This code is generated for you in the snippet screen, so if in doubt, you can copy and paste the code from there.

Fixed Size Image Field

Image fields are a little more complex that html fields because they are not just a single value.

Image fields store their data as a complex object that can can have sub fields. Here's an example of an image field value:

"fieldValues": {
   "image": {
       "url": "https://intilery-0-img.s3.amazonaws.com/0_13hgCmkOJ7KX97s4fHyWOQ.png",
       "link": {
           "title": "a title",
           "url": "www.example.com"
       }
   }
}

An image field will always have a url and then can have an optional link object. A link object has its own properties, title and url.

These fields can all be referenced by your template markup. Here's an example:

{{#if fieldValues.image}}
    <!-- use image if you have one -->
    {{#if fieldValues.image.link}}
        <!-- use image link if you have one -->
        <a href="{{{fieldValues.image.link.url}}}" title="{{fieldValues.image.link.title}}">
    {{/if}}
        <img data-intilery-image="image" src="{{{fieldValues.image.url}}}">
    {{#if fieldValues.image.link}}
        </a>
    {{/if}}
{{else}}
    <!-- default image placeholder -->
    <img data-intilery-image="image" src="https://intilery-0-img.s3.amazonaws.com/0_13hgCmkOJ7KX97s4fHyWOQ.png">
{{/if}}

The markup is checking if the field image exists. If it doesn't then a placeholder image is being used:  https://intilery-0-img.s3.amazonaws.com/0_13hgCmkOJ7KX97s4fHyWOQ.png

{{{ are being used instead of {{ to ensure that any special characters such as // are not being escaped.

If the image exists, then we also check if a link is associated with the image. If so, then the image is wrapped in an anchor tag. If not then we just display the image by itself.

If you never want an image to be linkable then the markup can be simplified like so:

{{#if fieldValues.image}}
    <img data-intilery-image="image" src="{{{fieldValues.image.url}}}">
{{else}}
    <!-- default image placeholder -->
    <img data-intilery-image="image" src="https://intilery-0-img.s3.amazonaws.com/0_13hgCmkOJ7KX97s4fHyWOQ.png">
{{/if}}

Container Field

Container fields contain child snippets.

For snippets to be usable in an email, the email itself has to have at least one container field. Without one of these fields, you have nowhere to put the snippets.

Containers can be used to break complex snippets up into smaller pieces that can then be reused.

For example, instead of creating two "text snippets" with different widths you can create a single "text snippet" (or use our text snippet) and put it into two containers that have different widths.

Having one snippet with the text markup, and one container with the layout markup means twice as many snippets but half the complexity. Smaller snippets are easier to change and maintain.

Here's an example container:

<table width="540" cellpadding="0" cellspacing="0" border="0" align="center" data-intilery-container="contents">
  {{#unless fieldValues.contents.length}}
    <!-- this is a placeholder that gives a visual queue to users that snippets need to be placed here -->
    <tr>
      <td width="100%" align="center" valign="middle" height="100px" style="border:1px solid black">
        CONTENT GOES HERE
      </td>
    </tr>
  {{/unless}}
  @@contents@@
</table>

The  data-intilery-container attribute is being used to define a container field called "contents"

There is a special syntax for the combined markup of all child elements:  @@fieldname@@.

If your container field has no child elements then you have to render a placeholder. Without a placeholder, you have no way to drag and drop snippets onto the containing field. It's a good idea to make the placeholder element large and explicit, so that users understand that they have to add child snippets here.

Once you have a few containers, and a few simple content snippets (text, image etc) you may find that you use them in different combinations to create different visual appearances.

The more granular your snippets, the more options you will create.

Custom Style Field

This is a more complex type of field. It contains information relating to css properties that you want users to be able to change.

For example, if you want a user to be able to change the height of a  <div> then a css field can be used to achieve this.

Once you have create a css field, you define one or more attributes that you want people to be able to control.

Here's an example:

<td width="{{parentWidth}}" data-intilery-custom-style="css" style="{{fieldValues.css.styleString}}"

    {{#if fieldValues.css.verticalAlign}}
      valign="{{fieldValues.css.verticalAlign}}"
    {{else}}
      valign="top"
    {{/if}}
>
    some content
</td>

Here's an example of the data that might sit behind it:

"fieldValues":{
    "css": {
        "styleString": "padding: 75px 75px 75px 75px;font-size:15px;line-height:15px;",
        "padding": 75,
        "paddingLeft": 75,
        "paddingRight": 75,
        "paddingTop": 75,
        "paddingBottom": 75,
        "verticalAlign": "top",
        "fontSize": 15,
        "lineHeight": 15
    }
}

So in this case, we've defined a field called "css" using the data-intilery-custom-style attribute . The field has then been defined via the snippets UI so that padding and verticalAlign can be changed.

Then some values are set for the snippet via the email editor to create the data structure shown above. You can see there's a special property called styleString. This is a calculated field, whose value is a css expression combined from all the css properties.

If you use this in the template then you have a way to inject custom style into your snippets.

Not all visual changes are best handled with inline styles, due to compatibility issues with different browsers. Sometimes older non-css attributes work better. For example, the valign attribute seems to work better than vertical-align.

So as well as using the styleString property, you can add your own attributes if certain css properties are set. This has been done for vertical align in the example above.

Still need help? Contact Us Contact Us