The frontend engineers at Monetate spend a lot of time modifying clients’ sites using Javascript.

Those modifications might be as simple as inserting a banner at the top of a page, or they might be more complex, requiring us to move, add, replace, restyle, or hide multiple page elements based on certain conditions. We perform these modifications by manipulating the DOM (Document Object Model), which is used by browsers to represent the structure of the elements on the page.

But before we can begin acting on the DOM, we first have to be able to identify the page elements we wish to interact with. For instance, if we want to place a badge on top of a product image, we have to be able to tell the browser which product image we’re referring to.

To do this, we can use native Javascript methods like getElementById() or getElementsByTagName() — or we can use a CSS Selector engine like Sizzle, which allows us to identify all of the page elements that match a specific CSS selector.

While we can always identify a page element somehow, whether your site is cutting-edge HTML5 or tables all the way down, certain ways are easier than others, and your site’s design largely determines which methods we can use.

So, if you anticipate that your website will rely heavily on DOM manipulation — either from internal scripts, to provide an app-like user experience, or external scripts (using Monetate’s suite of products, for instance) — here are some site-design tips on how to make the job easier:

Assign IDs to elements, where appropriate

Some site designers are reluctant to use element IDs, preferring instead to assign only classes. I’ve heard several explanations for this. One is that IDs should always be unique, and as a site grows larger, the chances of inadvertently assigning the same ID to multiple elements increases. Another is that if you only use classes, you’ll never have to change an ID to a class when you decide you need to add another element with the same styles.

But assigning unique IDs to elements, if done appropriately, can reduce complexity and increase speed when it comes to DOM manipulation, and the concerns about duplicate IDs and ID-to-class conversion, while worth considering, shouldn’t necessarily stop you from using IDs. (In fact, if it’s the first concern that worries you most, here’s a jQuery plugin that helps developers suss out duplicate IDs.)

Assign classes to elements, where appropriate

Some site designers think of classes solely in terms of CSS: They assign classes only to page elements that have the same CSS styles. But classes can also be useful as structural identifiers. For instance, you might have four elements on a page that have different styles, but they all belong to the same structural set (e.g. they’re all product containers, or they’re all images with rollovers).

If you can conceive of some set of page elements being logically grouped together for the purpose of DOM manipulation, even if they don’t have the same CSS styles, consider giving them a class anyway. There’s no rule that says all classes must have styles associated with them.

Design using the 5SC rule

As you design your site, consider ways to make each page element identifiable using a CSS selector string that contains no more than five selector components (tags, IDs, or classes) in it.

For instance:

#container (one selector component)

.smallImage (one selector component)

article td > .location (three selector components)

#result > .data > div + ul > li:first-child (five selector components)

If your site is designed in such a way that the simplest way to select a particular element looks like this, you’re making DOM manipulation a lot harder than it needs to be:

div > table td:last-child > table tr:first-child + tr > td > table + div + table td > a > img

Avoid using !important in CSS

Particularly when you’re planning to modify the DOM, an “!important” CSS declaration can really gum things up.

Adding “!important” to a CSS style rule allows it to override style rules that would ordinarily be given preference. For instance, suppose you have a stylesheet like this:

For most images on the page, the top margin will be 10 pixels, but for images with the featured class, the margin will be zero.

However:

Now, because we’ve added an “!important” to the first rule, the margin will be 10 pixels on all images, even those with the featured class. This disrupts the normal prioritization of CSS rules and can produce unintended consequences when page elements are shifted around.

There are, of course, cases when an “!important” might be appropriate or even necessary, but often, you can achieve your desired result simply by refactoring your CSS so that you don’t need to override styles higher up in the cascade.

Don’t use AJAX just for the sake of using AJAX

When you’re considering using AJAX to load new content into a page, rather than loading an entire new page, make sure to anticipate the potential downsides and weigh them against the potential upsides.

For instance, if you’re considering using AJAX for pagination, remember that (depending on your approach) it may be impossible for users to link to or bookmark a specific page. And in terms of DOM manipulation, you’ll have to deal with setting up callbacks that run when the AJAX events are completed, rather than simply being able to run when the page initially loads.

And if you’re using AJAX (or some other Javascript-based method) to render the initial content on a page, remember that this means certain page elements may not be immediately available to your DOM-manipulation functions. (Typically, this means that those functions will have to poll for page elements before proceeding.)

Sometimes, tables are the answer

Most web designers are on board with the idea that basic page layout should not be done using tables. There are other HTML elements that are much better suited for that job.

But tables do have a legitimate purpose in web site design, and just because they’ve gotten a bad reputation as the basis for page layout doesn’t mean that they should be avoided altogether. In fact, when used appropriately, tables can make DOM manipulation (and CSS styling) simpler.

For instance, imagine a table of structured data:

If I want to assign a CSS style any given column or row, I can do it in a single declaration without needing to assign extra classes to the HTML. Column widths expand to fit the content by default, so I don’t normally have to worry about defining them. And if I expand or shrink the size of the table (assuming I haven’t given its children overly rigid styles), the columns will expand or shrink accordingly.

It’s possible to try to replicate the functionality of an HTML table using non-table page elements — and believe me, I’ve seen it done — but the HTML isn’t going to be as clean, and you’ll be introducing certain complexities and limitations in terms of styling and DOM manipulation:

This is pretty much as bad as trying to use tables to do page layout!

What works for rendering may not work for manipulation

Suppose you’re creating an unordered list, whose immediate children should really only be list items. But suppose you decide to stick in a div tag or two:

Now, browsers can be very forgiving, and in most of them (even older browser versions such as Internet Explorer 7), that snippet is going to render just the way you would expect it to.

But what happens when you want to perform some DOM manipulation — say, by modifying the text of the first div?

You might be tempted to use a CSS selector string such as ul > div to grab both div tags, and then take the first result. That selector string will work in Firefox and Chrome, but in IE7, you’re going to come up empty, because the div nodes are treated as children of the li nodes, and the selector will only match the immediate children of the ul.

The takeaway: “Hey, it renders OK” is not a great standard for site design. Think not only about how a page will render, but how you’ll interact with page elements when it comes time to run scripts.