Create a free account

Blog

News, tips and all things Campaign Monitor

The Varying Landscape of Gmail: Versions Galore

Posted by Mark Wyner on December 12, 2007

Gmail logoThe Gmail landscape is changing. But that’s hardly news because we’ve been using a beta version for years now.

What is news is that there are four different versions of Gmail to consider when designing/developing an HTML email. If the four versions varied in simply GUI design or experience design there would be little to tell. However, as we discovered each version has its own way of handling HTML and CSS. First we’ll share the skinny on the different versions so you get a sense of what web designers are facing. Then we’ll show you some details about what’s happening under the hood.)

Note: no version of Gmail supports proper standards-based markup, so these reports are based on using compromised markup with inline styles and tables.

The Versions Defined

There are two core ways to use Gmail:

  1. As a gmail.com account. This entails signing up for a Gmail address (you@gmail.com) and then accessing the account at gmail.com with their webmail interface. (Alternately POP or IMAP access can be setup in a desktop email-client, but the rendering of emails in such a scenario is solely dependent upon the desktop client’s performance and is thus irrelevant to this post.)
  2. As a Google App. This entails setting up Gmail as a hosted webmail application for one’s personal domain. In this scenario, Gmail is used as a webmail interface to one’s own library of addresses (you@yourdomain.com).

Gmail.com Account

Google offers two different versions of their interface for those using a gmail.com account: “older version,” which is set by default, and “newer version” (these are the actual names). There are a few minor differences in the experiences moving from one to the other, most notably the addition of a chat feature in the Newer Version. Overall they're practically the same client, except for how they render HTML emails. Following are two screen shots of the same HTML email, one from each version:

[screenshot]
Newer version

[screenshot]
Older version

Then, whether in “older version” or “newer version” one has the ability to switch to something called “basic HTML” view. Google defines this as follows:

Standard view is what you’ll see when you sign in to Gmail from a fully-supported browser…In case you don’t have access to a fully-supported browser, we still want you to have access to Gmail—that’s why we’ve developed a basic HTML view of our service that is compatible with almost any browser.

Their fully-supported browser list comprises Safari, Firefox, Mozilla, Netscape and IE on Mac, Linux and Windows, but they mention that you’ll need Firefox 2 or IE 7 to“take advantage of the newest Gmail features.” The features they list as being unavailable in “basic HTML” view are:

  • Filter creation
  • Spell checker
  • Keyboard shortcuts
  • Address auto-complete
  • Custom from addresses

But “basic HTML” view offers something more: a different rendering of your HTML email:

[screenshot]

Google Apps

A screen shot of the test email from a Google App version of webmail pasted atop a screen shot of the same email in the “older version” of gmail.com is a pixel-for-pixel replica. At this time there is no way to toggle between “older version” and “newer version” in the Google App, though one can toggle between the standard version and “basic HTML view.” And the latter renders the same way as gmail.com in the same view.

Is There a Line of Defense?

The core differences (as far as we can tell) moving from one version to the next are how it renders padding, font sizes and bold formatting of headlines (h1–h6). Unfortunately, because of how the “newer version” renders messages there is little we can do to ensure consistent rendering across the various versions of Gmail. Following are some specific details about how each version handles the aforementioned styling.

Padding

In “newer version” both CSS- and table-padding are destroyed. Neither is supported, so padding is out. This is a fundamental problem in that any text inside of a box with a colored background will appear broken as it connects with the box’s sides. The “older version,” “basic HTML view” and Google App are all consistent with information we have reported in previous posts: padding is only rendered if it is used as an inline style.

Font Sizes and Headline Formatting

With font sizing, the “newer version” actually offers the closest accuracy. The “older version” and the Google App simply enlarge font sizes which, while has an unsightly result, isn’t nearly as bad as reducing font sizes regarding accessibility. The “basic HTML view” has the oddest rendering of all versions. Body text renders correctly but the headlines are stripped of bold formatting and are reduced to the size of surrounding body text.

In Closure

I believe the inconsistent rendering across the various versions of this one email client further supports a best practice of using standards-based markup. Doing so will ensure your emails look the same in any version of Gmail, in addition to supporting all the benefits of web standards. Using tables and inline styles will result in some headaches when it seems unlikely that one will achieve consistent rendering anyway.

As we recently pointed out in the Email Standards Project blog, it might be time for a Gmail intervention. If supporting web standards is something you think the Gmail team should be aware of, show your support by commenting on the post in the ESP blog, adding your thoughts to this Google Groups thread and sending your feedback directly to the Gmail team. They're listening, let's make sure we're heard.

Update: Clarification about Padding

As hcabbos pointed out in the first comment below, my reports about “inline padding” are somewhat ambiguous. To clarify, the newer version of Gmail does not support either CSS padding or inline padding via the cellpadding tag. So in the “newer version” padding is not possible at all. The following screen shots will help illustrate this:

[screenshot]
Newer version

[screenshot]
Older version

7 comments so far

hcabbos

wrote on December 12, 2007 3:33 PM

When you say table padding is ignored in the "newer" version, do you mean it doesn't recognize cell padding applied inline?

Dave Greiner

wrote on December 13, 2007 10:28 PM

hcabbos, just a quick comment to let you know that Mark updated the post to answer your comment. Thanks for letting us clarify.

hcabbos

wrote on December 14, 2007 6:40 AM

Thanks for clearing that up. Wow, no cellpadding...that's a huge omission if you ask me.

Dave Bar

wrote on December 15, 2007 11:40 AM

How About Cell Spacing?
Is that being stripped out as well?

I can't find the logic for stripping out the most common HTML 1.0 Table attribute.

I wonder if this is really just a bug that is being recognized, and the folks at gmail are on the case. If not, then it seems like a move to make them a huge negative in the email marketing community.

-D

Mark Wyner

wrote on December 18, 2007 10:40 AM

You know, I never checked cell spacing. One way of looking at this is that cell padding is to CSS padding as cell spacing is to CSS margin. When we're talking about things becoming less readable as colors blend together and text hits the "walls" of its block-level "box," we're really talking about padding.

However, you could, technically, use cell spacing to achieve the same result if you were to nest tables. But as an advocate for web standards I obviously can't recommend or support that type of markup. Still, if you have no say in the matter of design integrity versus web standards, this might be an option. That is, if Gmail fully supported cellspacing, which it does not.

I went ahead and ran the tests again using cellspacing instead of cellpadding. Support for cellpadding and cellspacing are parallel. So for those of you looking to this as a possible alternative, I am sorry to report you're out of luck.

Brian

wrote on December 22, 2007 8:01 AM

Can anyone explain why web-based email clients are messing with my HTML and CSS to begin with? I understand that they have to put some limits on the space an email can use render, but couldn't that be done with an iframe or something a little more clever than just butchering my content and design? Why don't they just use the web browser's rendering? This is ridiculous. No padding? A fucking joke.

Sean B

wrote on February 26, 2008 7:57 AM

Seems like LiveMail and Gmail are opposing one another. LiveMail doesn't like margins (see: partial support for margins in LiveMail) and Gmail doesn't allow for any type of padding. Are there any thoughts from the CampaignMonitor team on these two conflicts of interest?

Sean

Got anything to add?

Name

Web site

Your comments (basic HTML is fine)

Search all posts

Dig into a category

Stay in the loop

Subscribe to our RSS feed

Prefer updates via email? Sign up below and we'll send you all the good bits each month.

Popular articles

Why we need standards support in email
Read why standards in HTML email are so important, and what we're doing about it.

Email design guidelines
Learn how to design for images being turned off, preview panes and other useful tips.

CSS support in email in 2007
The CSS support of every popular email environment with recommendations to boot.

Image blocking in email
A roundup of how each of the popular email clients suppress images in HTML email.

Can I use flash in email?
We test flash support in all the popular email clients. The verdict - don't do it.

Email design gallery

Our email design gallery showcases more than 150 amazing email designs sent by our talented customers.