That’s not the case anymore. HTML syntax has seen a number of updates since the late 1990s, and tables are now relegated to doing what tables were originally meant to do – to display tabular data.
Except in emails. Most email clients lack support for recent HTML and CSS technologies, which is why tables are the best way to build entire HTML emails. Tables are bulletproof. Every Web browser and email client can read them.
With that in mind, let’s take a look at basic HTML table construction. Even though most self-service marketers are probably using Concentri’s design view/WYSIWYG editor to build their emails, it’s still important to understand how the basic building blocks come together to form the bulk of the content. After all, sometimes a problem can only be fixed by working with the code.
An HTML table works and displays the same way as a table built in any word processing program. Tables are divided into rows with the tr tag, and each row is divided into data cells with the td tag. A td tag can contain any type of content – even other tables. The /td, /tr, /tbody and /table tags close each respective element.
A complete HTML table looks like this:
While programmers can write any type of code in any way they like, they tend to format everything in the hierarchical manner displayed above. It’s a great practice to adopt. Keeping the code base clean and easy to read makes it easy to edit.
One of the problems with tables is that the markup can get very convoluted very quickly. It’s one reason why they aren’t in use outside of email design. The above example is probably the most basic table a programmer could build, and it takes nine lines of code. A complicated email build can take up to 300 lines of code and require numerous tables nested inside one another. That’s a lot to keep track of, and another reason why it’s important to keep a clean code base. It also speaks to another personal rule I like to follow when building emails – work outside in.
Always finish building the entire skeleton of a table before filling in an individual table cell. That includes setting cell widths, heights and spacers (all of which will be covered in a future post) and making sure all tags are properly closed. All open tags must be closed at some point in the code base. It only takes one missed tag to break an entire table. Working outside in is a quick way to make sure that doesn’t happen during the build. After all, it’s significantly easier to catch a mistake within nine lines of code than 300.
In future posts, I’ll highlight the specific advantages of working outside in as we look at more complicated table builds.