Not every element needs to be included when building tables. For example, all content in a table data cell will automatically horizontally align left. If that’s what you want your content to do in a specific data cell, then you don’t need to include align=”left” when building that cell.
But when in doubt, write it out. Unfortunately, experience is the best instructor in this regard. It takes awhile, but it’s not too hard to figure out which elements need to be specified at all times.
Commonly used HTML elements at the table level:
Align: Horizontally aligns the table (just the table itself, not individual data cells). The outermost table in an email build should be set to “center.” It will keep the entire email centered in a user’s view no matter how what the screen resolution is set to. Values include “left,” “right” and “center.”
Bgcolor: Sets the background color for the entire table. Hexidecimal values should be used to specify colors. For example, #000000 is the hexidecimal value for black.
Border: Places a border around every data cell in a table. The thickness of the border depends on the value associated. If the border element is not included at the table level, web browsers will automatically set the value to “0.”
Cellpadding: Controls the amount of space between all content placed in data cells and the cell wall. The default setting for this is “1.”
Cellspacing: Controls the amount of space between data cells. Although there is no official default, browsers usually use “2.”
Height: Controls the height (in pixels) of the table. This value can also have a percent assigned to it. Assigning a value of say, 100%, will instruct the browser to display the table’s height at 100 percent of screen resolution. For example, if a user’s screen resolution is set to 800 x 600 pixels, the table will be 600 pixels tall. If the screen resolution is set to 768 pixels wide, the table will be 768 pixels tall. There is no default value. As a side note, it’s typically easier to control this at the data cell level. Values include “top,” “middle” and “bottom.”
Width: Controls the width (in pixels) of the table. A good rule of thumb is to try and keep your email designs in between 600 and 700 pixels wide. This value can also have a percent assigned to it. Assigning a value of say, 100%, will instruct the browser to display the table’s width at 100 percent of screen resolution. For example, if a user’s screen resolution is set to 800 x 600 pixels, the table will be 800 pixels wide. If the screen resolution is set to 1024 pixels wide, the table will be 1024 pixels wide. The default value is “100%.” I prefer using a pixel width (“700”) to maintain more control on how my email will display cross-screen.
Commonly used HTML elements at the data cell level:
Align: Horizontally aligns the data cell’s contents. The default is set to “left.”
Bgcolor: Sets the background color for the data cell. Again, hexidecimal values should be used to specify colors.
Colspan: Table cells can span across more than one column. Colspan indicates how many columns a cell should take up. The default value is “1.” In the above example, I used colspan=“2” to indicate that my main content cell should extend across the “headline” and “date” cells.
Height: Controls the height (in pixels) of the data cell.
Rowspan: Table cells can span across more than one row. Rwospan indicates how many rows a cell should take up. The default value is “1.” As a side note, rowspan isn’t 100 percent reliable when building emails. A more consistent solution is to use a nested table.
Valign: Vertically aligns the data cell’s contents. The default value is set to “middle.” Valign=”middle” should always be included if height is being controlled in the same data cell since Outlook will assign a default value of valign=”top” instead of valign=”middle.”
Width: Controls the width (in pixels or percent) of the table. It’s always a good idea to specify a data cell’s width, especially when building multiple cells into a single row. Make sure the width of all the cells in a row is equivalent to the table width when added together. Otherwise, the cells will resize themselves to compensate for the cell’s content and the remaining space not accounted for. At best, this will make for inconsistent rendering. At worst, this will break the whole table.
The below example shows how Adobe Dreamweaver keeps track of cell widths in relation to the table:
In future posts, I’ll continue to look at more complicated table builds.