Jason Wehmhoener

wrote on September 11, 2007 3:05 PM

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

wrote on September 11, 2007 3:08 PM

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

wrote on September 11, 2007 3:50 PM

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

wrote on September 11, 2007 4:59 PM

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

wrote on September 11, 2007 5:33 PM

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

wrote on September 11, 2007 8:09 PM

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

wrote on September 11, 2007 11:57 PM

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

wrote on September 12, 2007 1:29 AM

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

wrote on September 12, 2007 3:40 AM

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

wrote on September 12, 2007 4:26 AM

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

wrote on September 12, 2007 8:06 AM

UL, OL, and DL are elements not properties.

Mathew Patterson

wrote on September 12, 2007 8:57 AM

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

wrote on September 12, 2007 9:31 AM

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.

Mark Wyner

wrote on September 12, 2007 11:19 AM

Thanks, everyone, for all of your support. It's nice to know we have the community behind us.

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

We're right there with you, Jason. But as David pointed out, it's a bigger challenge for webmail clients to support HTML than web browsers because we're rendering an HTML document within an HTML document. And this is why we are giving client developers the benefit of the doubt and being flexible about what's supported. I believe we'll get to a level of support parallel to today's browsers, but at a minimum we'd like to see a solid foundation of fundamental support.

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.

Thanks, Diana. This is exactly our point. We want to start with short-term goals which target fundamental support, while seeking improved solutions in the long-term. And your mention of proper ALT tag support is right on target. Excellent suggestion.

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).

Correct. We're talking about support for type selectors which are poorly supported across the board. But keep in mind that their lack of support is related to the fact that one used to be able to change a webmail client's appearance using type selectors. Most of the webmail clients today, however, have eliminated this threat by adding message DIVs and adding respective descendent selectors.

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

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.

Good point, Greg and Ben. We didn't make that clear, but it is indeed our intent to ask for support for IDs and classes. Inline styles aren't part of a good standards solution, so we're looking for support for embedded styles in the head of an email.

Megan

wrote on September 13, 2007 2:24 AM

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

wrote on September 13, 2007 3:08 AM

What about position: relative and absolute?

Mark Wyner

wrote on September 13, 2007 3:58 AM

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.

And THAT is the entire point of standards. Let's hope the email-client developers understand the necessity of this and are up to the challenge of making it happen.

What about position: relative and absolute?

While this would be lovely, Noah, it's not something we can expect any webmail client to support. This is because (as previously mentioned) enabling positioning in a webmail client would give someone the means to completely cloak an entire webmail client by positioning a new interface right on top of it.

Now, there may be some ingenious method for enabling positioning within the confines of a message window, but because I don't develop webmail clients I can't say for sure. And while previous conversations with Ryan Kennedy (former Yahoo! Mail developer) gave us some hope that this magic might be possible, don't count on this being something we see for a long time—if at all.

Annex

wrote on September 13, 2007 6:53 AM

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

wrote on September 13, 2007 3:22 PM

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

wrote on September 14, 2007 1:38 AM

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.

Mark Wyner

wrote on September 14, 2007 3:20 AM

What's the reasoning behind asking for the :hover pseudo-class to be supported?

Because it's simple, baseline interactivity. It enables us to add something lively to an email using only CSS without any client-side scripting. That's how I see it. Anyone else want to weigh in on this?

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.

I'm not sure I follow you here, Kevin. How is a simple background color change using li:hover related to reflowing/restyling content on the fly? This isn't scripting, it's CSS interaction. Know that I'm uncritical of your perspective; I'm simply not understanding why, amid such a modest list of requests, this one stands out as problematic.

I certainly won't pretend to understand the inter-workings of email clients, but I can say for sure that :hover on type selectors is a pretty simple property. Maybe the problem is that people might use this for showing/hiding content? I don't know. Again, I'd love for people to weigh in on this one.

:hover might be a nice thing to have but it's far from essential.

This brings up an interesting question: “what is essential?” We discussed the possibility of having a primary list of requests—properties we feel are essential. Then, having a secondary list of properties which would be gravy. This would invite email-client developers to weigh in on what's logical, sensible and technically possible.

So, do we split up a list into must-haves and nice-to-haves or do we lay down a single, core list?

Jim

wrote on September 14, 2007 11:23 AM

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

wrote on September 14, 2007 11:17 PM

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

Kevin McGuire

wrote on September 19, 2007 1:54 AM

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

wrote on September 19, 2007 2:32 AM

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

Chad CRoss

wrote on September 19, 2007 4:22 AM

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

Andrew Boardman

wrote on September 19, 2007 8:40 AM

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

wrote on September 19, 2007 8:47 AM

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.

Mark Wyner

wrote on September 19, 2007 10:41 AM

I am, like some other folks here, a little weary of making html email exactly like a web page.

Agreed. But keep in mind that we're not asking for this. We're asking for baseline standards support so that we may design/build HTML emails which render consistently across the board (on a fundamental level per our list).

By the time any of this work sees Gmail or Outlook, what will the state of the CSS browser support be like?

An excellent point, Kevin. Though given the snail-paced speed at which standards are enveloped by the browser community, I feel we're a long time from seeing CSS3 support across the board. And in the interim, it would be in everyone's best interest to have CSS2 support. Moreover, CSS3 is unfamiliar territory to email-client/browser developers, so I think it would be advantageous to take one step at a time.

Sorry for coming to the discussion so late.

Better late than never.

First, congratulations David and Mark for pulling this (and us) together.

Thanks!

Thanks for calling for a unique website and an acid test based on proposed baselines.

You bet. And we're already in production with this, so keep your eyes peeled.

GRH

wrote on September 21, 2007 3:55 PM

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

wrote on September 21, 2007 9:44 PM

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

Paul

wrote on September 25, 2007 1:23 AM

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.
http://www.whatwg.org/

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

Sorry for the rant.

Kevin

wrote on October 3, 2007 10:44 AM

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

wrote on October 3, 2007 6:59 PM

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

Gregg Oldring

wrote on October 18, 2007 4:47 AM

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

Davide

wrote on November 29, 2007 9:27 PM

What about a strict DOCTYPE?

Jared

wrote on December 1, 2007 5:25 AM

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

wrote on December 9, 2007 2:04 PM

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

wrote on April 9, 2008 12:57 AM

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 letsfightassholes@gmail.com

Dave Greiner

wrote on April 9, 2008 8:16 AM

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

wrote on April 15, 2008 1:00 PM

Useful site. Thank you:-)

Got anything to add?

Name

Web site

Your comments (basic HTML is fine)