NS2
Responsive Methods: Table Align vs TD Display: Block
I know of two different methods to create responsive layouts in emails, but I was hoping someone could enlighten me and help me decide which would be better for future use.
Method 1: Setting table alignments
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" name="viewport" content="text/html; charset=utf-8; initial-scale=1" />
<title>Method 1</title>
<style type="text/css">
@media only screen and (max-width:600px) {
table[class=container], table[class=responsiveTable] {width: 100% !important;}
}
</style>
</head>
<body>
<table class="container" border="0" cellspacing="0" cellpadding="0" width="600" align="center">
<tr>
<td>
<table class="responsiveTable" border="0" cellspacing="0" cellpadding="0" width="50%" align="left">
<tr>
<td bgcolor="#dddddd" align="center">FIRST COLUMN</td>
</tr>
</table>
<table class="responsiveTable" border="0" cellspacing="0" cellpadding="0" width="50%" align="left">
<tr>
<td bgcolor="#aaaaaa" align="center">SECOND COLUMN</td>
</tr>
</table>
</td>
</tr>
</table>
</body>
</html>
Method 2: Making TD block elements:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" name="viewport" content="text/html; charset=utf-8; initial-scale=1" />
<title>Method 2</title>
<style type="text/css">
@media only screen and (max-width:600px) {
table[class=container], td[class=responsiveCell] {width: 100% !important;}
td[class=responsiveCell] {display: block !important;}
}
</style>
</head>
<body>
<table class="container" border="0" cellspacing="0" cellpadding="0" width="600" align="center">
<tr>
<td>
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td class="responsiveCell" bgcolor="#dddddd" width="50%" align="center">FIRST COLUMN</td>
<td class="responsiveCell" bgcolor="#aaaaaa" width="50%" align="center">SECOND COLUMN</td>
</tr>
</table>
</td>
</tr>
</table>
</body>
</html>
I'm curious why Method 1 has better compatibility than Method 2, when with Method 2 you can use valign and have vertical borders that grow with the height of the TDs, unlike with Method 1 where you can't. With Method 2, you also don't have problems with one column dropping down in Outlook 2007+ like you do with Method 1. From my testing, Method 2 works just as well (if not better depending on the situation) as Method 1.
ETA: Thinking about this further, Method 1 has the capability of allowing us to control which column comes first in the stacking order on mobile (either the left or right col can be on top), whereas with Method 2, the left col or TD will always be on top on mobile.
However, reading here (https://litmus.com/community/code/261-td-display-block-not-working-on-android) and doing more research, it seems like Method 2 might actually be less reliable due to dropped support for CSS display on Android 4.4 (and even 4.3)? That sucks, because I can see both of these methods being useful depending on the scenario.
Adding
dir=rtlto the table will reverse the order of the columns, when there are multiple columns being displayed in a row. When it breaks down to a single-column layout, I believe it will display the columns in the order they appear in the code, so you do still have control in the order you want your content to be displayed.However, some newer Android devices not supporting the display block method made the decision for me. I really like using the 2nd method, but there's too many devices and clients that aren't supporting it.
Ah, very interesting about dir=rtl!
Yes, this Android thing is quite a pain - I've always used Method 1, but when I found out about Method 2 I was pretty stoked until I came across the issue in the other thread. Pretty much makes Method 2 useless unless there is a workaround, but I haven't found anything.
About method2: The "td { disaply: block }" doesn't work on Chrome in quircks mode. So people viewing the email in a webmail that stripe the doctype using Chrome and having a narrow screen won't see the "responsivity". You can't see that in litmus, but I found it happening on a couple of webmails here in italy.
You can test this by removing the doctyper and opening the email in Chrome and then narrow your screen.
alignhas better compatibility but is more limiting thandisplay. You'll need to navigate quirks in either case.Could you elaborate on their quirks? Most of the emails our company builds are done the exact same way, so perhaps some quirks wouldn't apply to us.