Help us form a baseline for standards support

The response from my call to arms a few days back has been phenomenal. We saw some great comments, loads of inbound links from other designers and some very encouraging "how can I help" emails from many others.

As I mentioned in the original post, an important part of moving forward is first establishing a set of baseline standards that we can encourage email client manufacturers to meet. This baseline is crucial as it will form the crux of our recommendations and hopefully shape minimum standards for email rendering across the board. It's also something you can help with.

Working closely with our resident email design guru Mark Wyner, we have established what we think is the core set of features that will form this baseline. What's important to remember here is that we're not crossing our arms and demanding perfect standards support. We're simply asking for the more critical CSS standards to be supported so we can properly separate content from presentation and ensure a simple design will render consistently across all of the popular email clients.

With this in mind, here's the list so far:

  • margin
  • padding
  • float/clear
  • type-selector :hover
  • background-image a:hover
  • background/inline images
  • font inheritance/sizing/line-height
  • UL, OL, DL properties
  • List-style-image
  • background-image positioning
  • borders
  • different link colors
  • content centering

This is where you can really help make a difference. Please leave your own comments with anything you think is missing or might not be of crucial importance to standards support in email. Once we've received your feedback, we'll make any amendments and get stuck into the testing/recommendations for each manufacturer. A new site bringing all this together isn't far off either.

Posted by David Greiner

46 Comments

  • Jason Wehmhoener
    11th September

    While I appreciate the sentiment behind “not crossing our arms and demanding perfect standards support” I’m concerned that the definition of each of the things on this simple list can be left open to a broad degree of interpretation.

    I feel that the use of the term “standards” implies specific definitions for each of the items in the list.  When contemplating what those definitions should be, I don’t see why existing web standards aren’t a useful starting point.  If we aren’t “demanding perfect standards support” then I’d like to know what the specific obstacles to doing so are. What are the specific constraints constraints guiding this journey towards standards compliant email CSS? What are email client vendors concerned about with regard to email CSS support?

    Absent this information, I see little reason not to “cross my arms and demand perfect standards support”.

  • Jason Wehmhoener
    11th September

    Also wanted to make a suggestion that one way to express the baseline requirements is to develop a test suite, similar to what ACID2 currently does for browser vendors:
    http://www.webstandards.org/action/acid2

  • Dave Greiner
    11th September

    Hey Jason, thanks for your thoughts.

    When contemplating what those definitions should be, I don’t see why existing web standards aren’t a useful starting point.

     

    I completely agree, and perhaps I didn’t do a good job of making my point. We’re certainly looking for accurate adoption of current standards. For example, by specifying padding and margin we’re basically saying we want standards based box model support.

     

    I guess my main point is that there are many, many CSS properties out there and it would be fantastic if they were all supported perfectly, but not even the browsers can get all of these right. We feel that by focusing on the most important areas initially, we can help manufacturers get the biggest wins with the least effort possible.

     

    What are email client vendors concerned about with regard to email CSS support?

     

    There are a number of CSS properties that web-based email clients won’t be supporting, purely because they are displaying a page within a page and want to ensure the email design can’t break out into their own interface. This can be solved by not supporting position and negative margins, which Yahoo! have confirmed when we discussed this issue with them in more detail.

     

    Also wanted to make a suggestion that one way to express the baseline requirements is to develop a test suite

     

    I completely agree, this is something I mentioned as the third thing we’re working on in my original post. We’ve actually got an initial test about 90% done, and will finalize it once we go through everyones feedback in these comments.

  • Wolf
    11th September

    We don’t need lists like these. If anything, showing HTML e-mail should just be like serving a webpage in let’s say, firefox.

  • Dave Greiner
    11th September

    Wolf, as I mentioned above, we think a much more effective way forward is to focus on the core features we all think are important for the future of HTML email. This is the same approach The Web Standards Project has taken with their Acid2 test. Here’s a quote from their site (emphasis mine):

    Acid2 tests features that web designers have been requesting. Everything that Acid2 tests is specified in a Web standard, but not all Web standards are tested. Acid2 does not guarantee conformance with any specification. After careful consideration, we have selected and are testing the features we consider most important for the future of the web.

     

    I think it’s even more important to take this approach with email because as mentioned in my previous comment, many web-based email client manufacturers like Yahoo, Hotmail and Gmail need to display a page within a page. This means some standards simply can’t be supported.

  • Mark Barnes
    12th September

    We do need lists like these. Dave is right. Although perfect standards support must remain the ultimate goal it is sensible to provide a priorities list that will help us to get there. What are the CSS properties email vendors must concentrate on getting right first of all? I think Dave’s list just about covers it. Frankly, the most important things for me have to be positioning, background image support and colours. Without those things elements don’t display at all, or are totally unreadable. I can live without hover classes, I can’t live with a DIV appearing in totally the wrong place or images not appearing.

  • Rick Whittington
    12th September

    This is such a great post.  For some time, I’ve thought of doing this also.  There clearly needs to be baseline standards for e-mail clients.  Anyone who’s ever coded an HTML e-mail with a CSS layout understands this.  I’m willing to help in whatever way possible.

  • Diana Potter
    12th September

    While the dream of pure standards support is email clients should certainly be the end goal I like the idea of at least starting somewhere. The list provided above contains everything that I find myself pulling my hair out over when it’s not supported and actually goes a little further. Personally, I see no need for the background-image a:hover. It would be a nice to have but it’s not as essential as something like margins or floats, or even just background images in general (or hovers in general). In fact it actually just brings to mind annoying ads that flash BUY ME! at you when you mouse over them.

    Another thing to add to the list is basically supported most everywhere already, defined widths and heights (width:3em;, etc). I’d hate to see that suddenly lost :). I’m sure that’s just assumed to be included already.

    I’d also like to add something to the list that’s just basic HTML, alt tag support! With most email clients disabling images by default I’d really like to see alt tag support in every client.

  • Gregg Oldring
    12th September

    Just to be thorough, noticably absent are id and class. We’re not talking about styling everything inline are we?

    In that same vein, I would love to be able to either link my stylesheet or put it in the header (only because I use Dreamweaver which can’t seem to handle it in the body). I can see that supporting linked style sheets while fending off phishing attacks will add overhead for email admins but it would reduce network traffic. So, failing linked style sheets, being able to put a stylesheet into an otherwise ignored head that would be great.

  • Steve
    12th September

    I tihnk that’s a great list to start with David. I’m not sure that there’s much more core CSS and HTML features that needed to be standardized acorss email software.

    (GREGG: Yes, DW can add your stylesheet into the body of your html page, when you create the stylesheet it’ll ask you if you want it external or if you want it in that page only. Optionally, you can hand code the begining and ending of the stylesheet in the head and DW will pick that up and allow you to add and use styles.)

  • Kevin
    12th September

    UL, OL, and DL are elements not properties.

  • Mathew Patterson
    12th September

    Kevin,

    You are right, but the list is actually referring to consistent support for the properties that apply to the UL, OL and DL elements (like padding and margin, for example).

  • Ben Holliday
    12th September

    I agree that this list is a really good starting point.

    When looking at standards of CSS support I think we should also be trying to get a standard way of attaching CSS styles within email HTML.

    ie. Maybe a further requirement alongside this list should be that CSS support needs to be available for linking to stylesheets through the document head.
    This way we can move away from both inline element styles and repeated styles in the head and body of email HTML pages to cover rendering in different email clients.

  • Megan
    13th September

    Good list - that’s even a little further than I would go right now. It would be great just to have background images, margins and padding, borders, and consistency between clients! The key for me is that whatever they support they have to do it in the same way and not one client supporting one part of CSS and another client supporting a different part.

    As you mentioned above, support for id’s, classes, and in the or linked to an external site is vitally important. It is ridiculous to have to duplicate your CSS in the head and body and rely mostly on inline styles because so many clients handle it differently.

  • Noah
    13th September

    What about position: relative and absolute?

  • Annex
    13th September

    Great discussion. My 2 cents:

    A standard is a standard. Let’s not fall short of demanding full standards support.

    However, I believe that this industry is market driven. If web-developers writing html/css emails can make enough of an impact then the client manufacturers/developers will have to listne.

    I vow to discourage any and all contacts I have from getting the new Office suite, in a desperate attempt to sway Microsoft NOT to use Word as the e-mail/Outlook rendering engine! I’ve already made some converts!

    But we are only strong in masses… Let email client developers and their companies FEEL that they NEED to support full standards. NOW.

  • Kevin Yank
    13th September

    What’s the reasoning behind asking for the :hover pseudo-class to be supported? This sticks out for me as a hard one to support, as it requires the email client to support dynamic rendering based on user events.

    Without that feature, an email client could have the luxury of rendering HTML email once, statically, and not having to reflow/restyle content on the fly.

    What crucial elements of email design hinge on support for :hover?

  • Diana Potter
    14th September

    Kevin,

    I agree. The same thing struck me while reading through the list. :hover might be a nice thing to have but it’s far from essential.

  • Jim
    14th September

    There are a number of CSS properties that web-based email clients won’t be supporting, purely because they are displaying a page within a page and want to ensure the email design can’t break out into their own interface.

    This is not true.  Put the body of the email into an inline frame and all problems of this nature disappear instantly.  No part of the email can escape the inline frame and everything is positioned relative to the frame, so positioning works exactly how the mail author wants, even if they use absolute positioning.


    The only downside is that you can’t have drop-down menus cover up the mail body or drag-and-drop between the mail body and the rest of the interface.  But no webmail works that way anyway to the best of my knowledge.

     

  • Peter Gasston
    15th September

    For what it’s worth, I think this is a fine baseline. I’ve put together a little more detailed response.

  • Kevin McGuire
    19th September

    Two points:

    1. I am, like some other folks here, a little weary of making html email exactly like a web page. The last thing I want is video in my email, like Peter said.

    However, I feel the technology should be open. For each person that pulls some shady tricks using :hovers, there will be just as many doing something worthwhile. Just because I hate flash-based ads in my browser doesn’t mean I want flash gone altogether.

    2. All this talk about floats and clears got me thinking about CSS3. By the time any of this work sees Gmail or Outlook, what will the state of the CSS browser support be like? I think we need to keep that in mind. It would be pretty bad if we have CSS 3 columns available to us in Internet Explorer,  but when we make an email we have to go back to using floats and clears. That would pretty much be exactly the way things are now - just one step removed.

  • Joel Harrison
    19th September

    RIGHT ON!  Keep up the sweet work… I’m excited about the possibilities!
    jharrisondesign.com

  • Chad CRoss
    19th September

    The only thing I see that is missing would be width and height which Diana already pointed out.

  • Andrew Boardman
    19th September

    Sorry for coming to the discussion so late. First, congratulations David and Mark for pulling this (and us) together. It’s heartening that a company as great as Freshview is calling for email standards.

    Which brings me to to two points. First, naming the campaign (pardon the natural pun) something like “Email Standards” would greatly help the public perception of the need. I’ve tried, until I think I was blue in the face, to explain to clients the problematics of email newsletter design. Pointing people to a cogent, user-friendly Email Standards website would be awesome. I’d be glad to help with this. Perhaps having a WASP-like website that showed a coalition of email newsletter providers, designers, and developers would demonstrate seriousness of purpose.

    Second, I wonder if it’s possible (technically) to create an HTML email acid test (or perhaps two different ones) based upon the essential baselines proposed above. This would go a long way towards demonstrating to the public and to companies what the obvious challenges and solutions are.

  • Andrew Boardman
    19th September

    Ah, I obviously had not read the previous post to this one. Thanks for calling for a unique website and an acid test based on proposed baselines.

  • GRH
    21st September

    It appears that <BLOCKQUOTE> is not supported in Outlook 2007, or at least not fully.  In exchanging e-mails w/ Mac users, there have always been a few minor issues, but e-mails using indentation worked pretty well in 2003.  When a Mac user indented portions of my message and responded outdented below, I saw the indentations in Outlook 2003; however, in 2007, all text is lined up on the left, ignoring the blockquote indentation.

    The following is an example of source from one e-mail where BLOCKQUOTE no longer works:

    <BODY style=“word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; “>
    <DIV><BR class=“Apple-interchange-newline”>
      <BLOCKQUOTE type=“cite”>
      <DIV><SPAN class=“375413401-17092007”><FONT face=“Arial” size=“2”>text that should be indented</FONT></SPAN></DIV>
      </BLOCKQUOTE>
      <DIV><BR class=“khtml-block-placeholder”>
      </DIV>
      response text (outdented)
    </DIV>

  • Dave Greiner
    22nd September

    Thanks for letting us know about that GRH, we’ll make sure we include that in our recommendations.

  • Paul
    25th September

    I would like to get to a point where i dont have to use inline styles and tables. Trying to support the lowest common denominator is so difficult. To test out a web page there are about 5 browsers to test, and some vendors dont update their products to bring them inline with standards that are 10 years old. Email is worse with 15 or more.

    Then to try to explain that to a client, nearly impossible. Just use the standard they say. It doesnt exist. Moving targets and deadlines dont mix well.

    Background images allowed me to create emails easier, now i have to slice image again, disgraceful. A fixed box model is a necessity.

    Perhaps backing from a standards group would be helpful, w3c or whatwg perhaps.
    <a href=“http://www.whatwg.org/” rel=“nofollow”>http://www.whatwg.org/</a>

    I long for the day where i can run the code through a validater. It shouldnt be this hard.

    Sorry for the rant.

  • Kevin
    3rd October

    What are the problems with requesting non-html based support, via XSLT/CSS. It seems to me that email wants to live gracefully in the dark ages of design with non-compliant clients (similar to browsers). If you moved on to an XML that wasn’t pre-formated, you could completely focus on the css/display features you “need” and, likely imo, skip to todays standards in web design (straight to CSS 3 or at least CSS2 fully supported). I think this because it means the client programmers no longer have to care about a UL, DIV, or STRONG block and what the “standard” display properties should be. They can, instead, focus on “display:inline means it should be next to each other until we hit the end of the page…like word-wrap!”

    Some things to think about I suppose.

    PS. Fix your tabindex for the replier…I almost lost this post when I was shot off into oblivion. ;)

  • Dave Greiner
    3rd October

    Thanks for the suggestions Kevin, that tabindex issues has been fixed too.

  • Gregg Oldring
    18th October

    I just thought of something else that would save lines and lines of repetitious urls - the BASE tag!

  • Davide
    30th November

    What about a strict DOCTYPE?

  • Jared
    1st December

    Alt tags - never replace my images with grey boxes and no alt text.
    :hover - +1 vote from me. 3D Button behavior in CSS please.
    display - dont let outlook 07 tak this from us.
    url() - fixes background images and list style image support
    z-index - nuff said.

  • Nisse
    9th December

    I would like to propose a slightly different starting point here. First of all, I believe a HTML/CSS formatted e-mail should be rendered exactly as a any HTML/CSS formated page. However, some elements could be considered security risks and some elements are not necessary.

    Thus, my proposal is to begin this task by starting with the existing web standards and omitting unnecessary/potentially harmful elements. In other words, instead of writing a wish list of elements on a blank piece of paper, we make a non-wish list (so to speak) of unwanted elements. My contribution to that list would be:

    1. Javascript - there is no reason to run scripts in an e-mail
    2. CSS positioning: absolute and fixed - for the sake of web mail, as stated above
    3. HTML forms - I can’t see why anybody would want to receive a form
    4. HTML target in href - redundant
    5. please add more… these were just the ones I came up with straight away

    By doing a negative list of elements that should NOT be supported, the future development of an e-mail HTML/CSS specification would become rather smooth. All new versions of “ordinary” HTML/CSS would become e-mail HTML/CSS except the ones in the proposed non-wish list. Of course, this list should be revised then too, but the benefits of beginning with what we have and removing what we don’t want is, in my opinion superior.

  • Chris
    9th April

    This is rather pointless. It would have been useful five years ago, but saying we need “email client developers” to support this-and-that is BS. It’s Microsoft. It’s only Microsoft. Thunderbird uses mozilla, Apple Mail uses webkit, and Outlook used to use IE. Problem solved. Microsoft changes to WORD rendering engine, and now we’re all going to act like this is an industry wide problem? It’s not, Microsoft sucks, and they fucked the community. Fix Outlook. Period. I just battled with it for hours, and I don’t really need to make a list of the support I need. I just need email clients to embed browser’s rendering engines. This is a waste of precious resources, why should anyone waste their intellectual capital explaining to Microsoft why Outlook with Word’s HTML rendering engine sucks? They already know it sucks. They suck, and frankly, I’d rather just fight someone at Microsoft than solve the problem. Any takers email me at .(JavaScript must be enabled to view this email address)

  • Dave Greiner
    9th April

    Chris, you’re actually a long way off with the Microsoft bashing, and it’s ironic that you list you are a Gmail user and can still make these claims.

    If you look at the results of our acid test, it’s Google and IBM that offer the worst support, with Microsoft not far behind. They all need to get their act together.

  • antique furniture information
    15th April

    Useful site. Thank you:-)

  • wakacje nad morzem
    23rd May

    Hi I have read your article and I will try use your opinion in my website wakacje nad morzem. We will see efects in future

  • casino
    19th June

    gjiso tldhxwa dayru isfn

  • Sindbad
    26th June

    it’s kind of hard to say what else may be the significant point ;-) I think it’s ok. you can proceed.

  • Darmowe ogloszenia motoryzacyjne
    17th July

    Something more….i think that makings 3d are coolest than making simple music tracks.

  • OFE Fundusz Emerytalny
    15th August

    Hehe Chris

    I think you get your point and I think your right. Its all about Microsoft/ They have monopoly and they lead this path. Even if they suck, they still on top.

  • analysis
    20th August

    BASELINE requires a few extra words of explanation. The baseline is the imaginary line on which rest all the letters in a line of text. BASELINE sets the row so that all the cells share the same baseline. Most of the time this has the same effect as BOTTOM, but if the fonts are different sizes then BASELINE is looks better.

  • Poker rules
    20th August

    Hello,

    I try to align the baseline of my title with a white line using CSS. The
    code does work with Safari Mac, Explorer Mac and PC, Firefox PC. But on
    Firefox 1.5 Mac and Opera 6.03, the text shifts from the line. I don’t
    understand where these pixels come from (all units are in pixels):

    Presentation

    Thanks for any help,

  • Pod Sosnami
    9th September

    Great job, interesting interview.
    Thank you from Poland

  • Gwara
    13th December

    Recently established website: Nasza Gwara
    Dialect page is devoted to the Polish people, you can find a friend from the past, who left in search of better jobs. I invite all.

Sign up for free.
Then send campaigns for as little as $9/month

Create an account